Instituto Superior de Ciências do Trabalho e da Empresa

Departamento de Ciências e Tecnologias da Informação

SISTEMA DE AQUISIÇÃO E GESTÃO DE INFORMAÇÃO

CONTEXTUAL INDEPENDENTE DO DOMÍNIO

Paulo Roberto Almeida Moreira Costa

Dissertação submetida como requisito parcial para obtenção do grau de

Mestre em Engenharia Informática e de Telecomunicações

Orientador:

Prof. Doutor Luís Miguel Botelho

Julho 2006
 Agradecimentos

Ao coordenador da tese, Luís Botelho, pela coordenação, orientação e entusiasmo na

elaboração do trabalho de investigação que deu origem a esta tese de mestrado.

Aos colegas do projecto CASCOM pelo apoio, motivação, material disponibilizado e pelo
excelente contributo dado nas discussões diversas sobre deste trabalho: António Lopes, Fábio
Calhau, Lino Pereira, Luís Mota, Pedro Pais e Tiago Santos.

À ADETTI no geral pela disponibilização dos meios materiais usados na tese e pelo apoio
dado em diversas ocasiões, e em particular à Ana Rita, Fátima Estevens e Sónia Ferro, por
estarem sempre dispostas a dar apoio aos colegas.

À minha família e aos meus amigos pela compreensão e por estarem sempre ao meu lado
nos momentos cruciais.

A uma pessoa especial que me acompanhou ao longo do desenvolvimento desta tese.

ii
 Resumo
Esta tese de mestrado foca-se sobre a problemática do contexto nas aplicações,
apresentando uma solução para os problemas relacionados com a captura e processamento de
informação de contexto.

Uma nova visão da problemática da computação ciente do contexto é introduzida pelo

sistema desenvolvido. Este aplica soluções de várias plataformas para resolver diferentes
aspectos da problemática do contexto. Isto torna o sistema numa aplicação mais abrangente
que as anteriores.

O sistema desenvolvido comporta-se como uma camada de interacção entre produtores de

informação de contexto e os consumidores de informação de contexto. Esta camada é
independente do cenário onde o sistema é aplicado pois a informação de contexto é tratada
com uma estrutura de alto nível definida por ontologias.

Todo o processo de captura de informação proveniente dos produtores de contexto já se

encontra resolvido no sistema. Durante o desenvolvimento das aplicações apenas é necessária
a preocupação com o tratamento a dar à informação de contexto obtida.

Através do uso de várias interfaces para a mesma funcionalidade o sistema desenvolvido

consegue usar protocolos de outras aplicações tais como sistemas de agentes, serviços Web ou
aplicações baseadas em componentes. Com o uso destas interfaces não há necessidade de
produzir mecanismos de tradução ou de adaptação dos pedidos efectuados ao sistema e das
respostas obtidas.

O processo de desenvolvimento do sistema encontra-se descrito ao longo desta tese.

Palavras-chave: sistema de contexto, computação ciente do contexto, problemática do

contexto, sensores, informação de contexto, ontologias

iii
 Abstract
This master’s thesis focuses on the problematic of context on applications and presents a
solution for the context information capture and processing problems.

A new vision of context aware computation is introduced by the developed system. This
system applies solutions provided by several platforms to solve different aspects of the
context problematic. All of these solutions are gathered in one single application making the
system response wider than all the rest.

The developed system behaves as a layer of interaction between context producers and
context consumers. This layer is domain independent since context information is dealt with a
high level ontology defined structure.

All the information capture process is solved inside the system. Application development
is simplified since the only concern applications have is what to do with the received context
information.

Through the use of several interfaces for the same functionality, the developed system uses
communication protocols defined by other applications such as agent platforms, Web services
or component based applications. By using these interfaces, the production of translation
mechanisms to adapt application requests and system replies is not necessary.

The system’s development process is described throughout this thesis.

Keywords: context system, context aware computation, problematic of context,

sensors, context information, ontologies.

iv
 Glossário
B
Blackboard – Modelo de arquitectura baseado num repositório central proposto por
Winograd [Winograd 2001]

C
CAP – Context-Aware Packet – Pacote trocado numa rede de sensores cientes do contexto

CoBrA – Context Broker Architecture – Arquitectura de sistema ciente do contexto

baseada em agentes

Context Aware Computing – Área da computação que trabalha com informação de

contexto

F
FIPA – Foundations of Intelligent Physical Agents – Fundação que emite standards de
interoperabilidade em plataformas de agentes

FIPA-ACL – FIPA Agent Comunication Language – Linguagem de comunicação entre

agentes definida pela FIPA

FIPA-SL – Linguagem de descrição de conteúdos definida pela FIPA

G
CGMAS – Generic Context Management and Acquisition System – Sistema ciente do
contexto desenvolvido nesta tese

J
JENA – Framework em Java para desenvolvimento de aplicações semânticas

JINI – Plataforma de desenvolvimento de componentes Java com uma arquitectura baseada

em serviços

M
Middleware – Camada intermédia de uma aplicação

MoCA – Mobile Collaboration Architecture – Arquitectura de um sistema ciente do

contexto adaptado a ambientes móveis.

v
 O
OWL – Web Ontology Language – Linguagem de descrição de ontologias

OWL-S – Linguagem de descrição de ontologias de serviços Web baseada em OWL

P
Peripheralware – Camada que se situa entre a camada superior e a camada intermédia, e
entre a camada intermédia e a camada inferior de um sistema.

S
sCAP – Smart Context-Aware Packet – Pacote trocado numa rede de sensores cientes do
contexto

SCB – Schema Class Builder – Ferramenta de construção de classes Java a partir de

descrições em XML Schema. Ferramenta desenvolvida pelo laboratório de investigação "We,
the Body, and the Mind" da ADETTI em colaboração com a empresa Accedo

SDC – Sistema de Dependência no Contexto – Conjunto de serviços que se adaptam de

acordo com factores ambientais tais como a localização.

SEM – Sistema de Emergência Médica – Serviço responsável por tratar das emergências
médicas de um país

SIEM – Serviço de Informação de Emergência Médica – Serviço de informação do SEM

Smart-it – Arquitectura ciente do contexto baseada em sensores

SOAP – Simple Object Access Protocol – Protocolo para intercâmbio de mensagens entre
programas. Geralmente usado para serviços Web (“Web Service”).

U
USDP – Unified Software Development Process – Processo de desenvolvimento de uma
aplicação desenvolvido por Jacobson e seus colegas [Jacobson et al 1999].

Use Cases – descreve a funcionalidade proposta para o novo sistema. Um caso de

utilização representa uma unidade discreta da interacção entre um utilizador (humano ou
máquina) e o sistema.

vi
 W
W3C – World Wide Web Consortium – consórcio de empresas de tecnologia para levar a
Web para o seu potencial máximo, através do desenvolvimento de protocolos comuns e
fóruns abertos que promovem sua evolução e asseguram a sua interoperabilidade

WASP – Web Architectures for Service Providers – Arquitectura de um sistema ciente do

contexto

Web Service – Solução utilizada na integração de sistemas no domínio da Internet e na

comunicação entre aplicações diferentes

Widget – Modelo de arquitectura baseado na representação de sensores por componentes,

definido por Dey e seus colaboradores [Dey et al 2001]

Y
Yellow Pages – Serviço de registo e localização de componentes por propriedades

YR-SOC – First European Young Researchers Workshop on Service Oriented Computing

Conferência onde foi apresentado o artigo sobre o sistema desenvolvido na tese

X
XML Schema – Linguagem que descreve a estrutura e conteúdo de documentos XML.
Usada nesta tese para definir objectos

XSP – eXtended Service Platform – Plataforma de gestão de componentes Java.

Ferramentas desenvolvidas pelo laboratório de investigação "We, the Body, and the Mind" da
ADETTI em colaboração com a empresa Accedo

vii
Índice

Vol I – Corpo da Tese

Capítulo 1. Introdução································································································ 1

1.1 Problemática do contexto e motivações ·············································································1

1.2 Inovações introduzidas pelo sistema de contexto·····························································3

1.3 Descrição da abordagem usada para o desenvolvimento do GCMAS ·························5

1.4 Critérios de avaliação e cenário de demonstração···························································7

1.5 Resultados da avaliação ·······································································································8

1.6 Organização da tese ··············································································································8

Capítulo 2. Estado Actual dos Conhecimentos····························································10

2.1 Definições de contexto ········································································································11

2.1.1 Análise crítica····························································································································12

2.2 Análise às abordagens de modelação do contexto··························································13

2.3 Arquitecturas de dependência do contexto ·····································································16

2.3.1 Arquitectura Smart-its e de pacotes cientes do contexto ···························································17
2.3.2 Arquitectura Merino ··················································································································18
2.3.3 Arquitectura proposta por Cortese e seus colaboradores···························································18
2.3.4 Arquitectura WASP···················································································································19
2.3.5 Arquitectura CoBrA ··················································································································20
2.3.6 Context Tailor····························································································································22
2.3.7 Análise crítica····························································································································23

2.4 Conclusões finais ·················································································································24

Capítulo 3. Análise do Sistema ··················································································26

3.1 Cenário proposto·················································································································27

3.2 Descrição dos elementos constituintes da aplicação ······················································28

3.3 Diagrama de Casos de Utilização ·····················································································29

3.4 Requisitos do Sistema ·········································································································31

Capítulo 4. Ontologia do Contexto·············································································32

4.1 Solução para representar o modelo de contexto ····························································33

viii
 4.2 Descrição da ontologia de contexto ··················································································35
4.2.1 Ontologia base de contexto ·······································································································37
4.2.2 Ontologia de distribuição ··········································································································40
4.2.3 Ontologia de dados ····················································································································40

Capítulo 5. Descrição do Sistema···············································································43

5.1 Arquitectura do GCMAS···································································································44

5.1.1 Interfaces externas do GCMAS·································································································47
5.1.2 Diagrama de componentes do GCMAS ····················································································49
5.1.2.1 Componente de adaptador de sensor················································································50
5.1.2.2 Componente de repositório ······························································································53
5.1.2.3 Componente de pesquisa de contexto ··············································································55
5.1.2.4 Componente de subscrição de eventos·············································································57
5.1.2.5 Serviço de páginas amarelas ····························································································58
5.1.2.6 Núcleo do GCMAS··········································································································59
5.1.2.7 Componentes do módulo de aplicação·············································································61

5.2 Considerações de desenho··································································································63

5.3 Desenvolvimento do GCMAS····························································································65

5.3.1 Adaptação de sensores e pesquisa de informação ·····································································67
5.3.2 Introdução do conceito de ontologias e componente de pesquisa de contexto ··························67
5.3.3 Armazenamento de contexto ·····································································································70
5.3.4 Componentes e interfaces não implementados no GCMAS······················································72
5.3.5 Problemas encontrados no desenvolvimento·············································································73

Capítulo 6. Avaliação do Sistema Definido e Implementado ·······································77

6.1 Descrição dos critérios de avaliação·················································································78

6.1.1 Comparação com outros sistemas de contexto ··········································································78
6.1.2 Funcionalidades do GCMAS·····································································································78
6.1.3 Avaliação do funcionamento e dos tempos de resposta do sistema···········································78
6.1.4 Robustez ····································································································································79

6.2 Avaliação dos critérios ·······································································································79

6.2.1 Comparação com outros sistemas de contexto ··········································································79
6.2.2 Funcionalidades do GCMAS·····································································································83
6.2.3 Avaliação do funcionamento e dos tempos de resposta do sistema···········································85
6.2.4 Robustez ····································································································································87

Capítulo 7. Conclusões e Trabalho Futuro··································································90

Capítulo 8. Referências Bibliográficas ·······································································92

ix
Vol II – Anexos

Anexo I. Análise do Conhecimento Actual ······························································· I

1.01 Definições de contexto ·········································································································· I

1.02 Abordagens de modelação do contexto·············································································II

1.03 Visões conceptuais de arquitecturas ··············································································XV

1.04 Arquitecturas de sistemas de contexto··········································································· XX

Anexo II. Descrição do Cenário de Aplicação do Sistema···································· XXV

2.01 Identificação das Interacções do Cenário ··································································XXV

2.02 Descrição detalhada dos casos de utilização ···························································XXVII

2.03 Requisitos do sistema desenvolvido··········································································XXXII

Anexo III. Descrição da Ontologia do Sistema ··············································· XXXVIII

3.01 Identificação das entidades fornecedoras de contexto ····································· XXXVIII

3.02 Informação contextual de cada entidade······························································· XXXIX

3.03 Representação gráfica da ontologia de distribuição do contexto ··························XLVI

Anexo IV. Considerações de desenho································································ XLVIII

4.01 Linguagens usadas no sistema················································································· XLVIII

4.02 Características das interfaces do sistema ········································································· L

4.03 Mecanismos de comunicação interna···············································································LI

Anexo V. Manual de utilização············································································· LIII

5.01 Adaptadores de sensor ··································································································· LIII

5.02 Núcleo do sistema ·············································································································LVI

5.03 Pesquisa de contexto ········································································································LIX

5.04 Repositório de contexto ···································································································LXI

5.05 Eventos de contexto······································································································ LXIII

5.06 Interfaces de agentes······································································································ LXV

Anexo VI. Protocolos do GCMAS ······································································ LXIX

Anexo VII. Convenções usadas no desenvolvimento············································ LXXII

x
 7.01 Nomes····························································································································LXXII

7.02 Pacotes···························································································································LXXII

Anexo VIII. Comparação do sistema desenvolvido com outros sistemas················LXXIV

8.01 Abordagem geral do contexto ··················································································LXXIV

8.02 Melhorias introduzidas pelo sistema ······································································LXXVI

8.03 Separação do mecanismo de captura e do mecanismo de tratamento da informação

de contexto······································································································································ LXXX

8.04 Abrangência do GCMAS ··························································································LXXXI

8.05 Disponibilização imediata da informação de contexto·······································LXXXII

Anexo IX. Apresentação dos resultados dos testes ao sistema··························· LXXXV

9.01 Pesquisa de informação no GCMAS····································································· LXXXV

9.02 Independência da captura da informação de sensores ············································· XCI

9.03 Diversidade de ligações ao sistema ··············································································XCII

9.04 Armazenamento de histórico de contexto ·······························································XCVII

9.05 Pesquisa de informação por propriedades de sensores················································ CI

9.06 Actualização da ontologia do sistema ·········································································· CIII

9.07 Disponibilidade da informação de contexto····························································· CVIII

9.08 Tempos de acesso ao sistema ··························································································· CX

9.09 Ontologia definida para os testes··············································································· CXIII

Anexo X. Artigo publicado na YR-SOC ··························································CXVIII

xi
 Índice de figuras
Vol I – Corpo da Tese

Figura 1 – Arquitectura do sistema de contexto integrado numa plataforma orientada para serviços ................. 6
Figura 2 – Estrutura hierárquica das arquitecturas..............................................................................................16
Figura 3 – Arquitectura Merino ............................................................................................................................18
Figura 4 – Arquitectura WASP ..............................................................................................................................19
Figura 5 – Arquitectura COBrA ............................................................................................................................21
Figura 6 – Arquitectura Contex Tailor ..................................................................................................................23
Figura 7 – Diagrama de casos de utilização da aplicação de emergência médica...............................................29
Figura 8 – Diagrama de use cases do GCMAS .....................................................................................................30
Figura 9 – Classificação do contexto ....................................................................................................................37
Figura 10 – Ontologia base de contexto ................................................................................................................38
Figura 11 – Visão geral da arquitectura do GCMAS ............................................................................................45
Figura 12 – Componentes da arquitectura do sistema ..........................................................................................49
Figura 13 – Comunicação interna entre componentes ..........................................................................................64

Vol II – Anexos
Figura 14 – Noções de Contexto.............................................................................................................................. I
Figura 15 – Classificação do Contexto...................................................................................................................II
Figura 16 – Representação tridimensional do contexto ...................................................................................... VII
Figura 17 – Contextor......................................................................................................................................... VIII
Figura 18 – Modelo de contexto com associações e dependências ........................................................................ X
Figura 19 – Representação do modelo conceptual num diagrama de use cases ...................................................XI
Figura 20 – Exemplo de contexto centrado na actividade.................................................................................. XIV
Figura 21 – Exemplo de contexto geral e contexto específico de uma actividade ................................................XV
Figura 22 – Localização do "Peripheralware" numa arquitectura baseada em serviços ................................XVIII
Figura 23 – Blocos de pré e pós processamento................................................................................................. XIX
Figura 24 – Modelo de contexto do cenário ....................................................................................................XLVII
Figura 25 – Exemplo de um ficheiro de configuração........................................................................................ LIV
Figura 26 – Interfaces do adaptador de sensor para pesquisas de contexto ........................................................LV
Figura 27 – Ficheiro de configuração do arranque do sistema ......................................................................... LVI
Figura 28 – Interface de ontologias..................................................................................................................LVIII
Figura 29 – Objectos genéricos de pesquisa de informação ................................................................................LX
Figura 30 – Interfaces de pesquisa .......................................................................................................................LX
Figura 31 – Interfaces do repositório ...............................................................................................................LXIII
Figura 32 – Interfaces do componente de eventos............................................................................................ LXIV
Figura 33 – Protocolos de interacção de pesquisa e armazenamento de contexto .......................................... LXVI
Figura 34 – Protocolo de subscrição de eventos .............................................................................................LXVII
Figura 35 – Protocolo de pesquisa de contexto, visão de alto nível.................................................................. LXX

xii
Figura 36 – Protocolo de pesquisa de contexto, comunicação real entre componentes .................................. LXXI
Figura 37 – Árvore de pacotes....................................................................................................................... LXXIII
Figura 38 – Registo da aplicação de armazenamento de contexto no sistema...........................................LXXXVII
Figura 39 – Registo da aplicação de pesquisa de informação ..................................................................LXXXVIII
Figura 40 – Registo mostrado pelo adaptador de sensor aquando uma pesquisa ....................................LXXXVIII
Figura 41 – Código da aplicação de pesquisa usada no teste............................................................................ XCI
Figura 42 – Registo da aplicação de pesquisa de informação ........................................................................... XCI
Figura 43 – Registo mostrado pelos adaptadores de sensor aquando a pesquisa ............................................XCII
Figura 44 – Registo da aplicação XSP de armazenamento de contexto no sistema ..........................................XCII
Figura 45 – Registo da aplicação XSP de pesquisa de informação ................................................................ XCIII
Figura 46 – Registo da aplicação de pesquisa de informação usando a interface JINI.................................. XCIII
Figura 47 – Código da aplicação de armazenamento em XSP.......................................................................... XCV
Figura 48 – Código da aplicação de pesquisa em XSP .................................................................................. XCVII
Figura 49 – Pesquisa inicial à informação dos sensores............................................................................... XCVIII
Figura 50 – Registo da aplicação que faz pesquisa sobre histórico de contexto..............................................XCIX
Figura 51-Extracto do código da aplicação de pesquisa de histórico.................................................................. CI
Figura 52 – Registo da aplicação que faz a pesquisa a dois sensores ...............................................................CIII
Figura 53 – Registo mostrado pelos adaptadores de sensor aquando a pesquisa .............................................CIII
Figura 54 – Registo obtido pela aplicação de pesquisa ...................................................................................... CV
Figura 55 – Registo dos adaptadores de sensor aquando a sua inserção no sistema e durante a pesquisa ...... CVI
Figura 56 – Definição da classe de sensor de localização por agenda.............................................................CVII
Figura 57 – Representação do objecto devolvido pelo sensor de localização por agenda ...............................CVII
Figura 58 – Registo das aplicações usadas para o teste de disponibilidade de informação no sistema ............ CIX
Figura 59 – Exemplo do lançamento de um sensor para teste de tempo de acesso............................................ CXI
Figura 60 – Resultados do teste ao tempo de acesso para um sensor sem histórico .......................................... CXI
Figura 61 – Resultados do teste ao tempo de acesso para dez sensores sem histórico ...................................... CXI
Figura 62 – Resultados do teste ao tempo de acesso para vinte sensores sem histórico...................................CXII
Figura 63 – Resultados do teste ao tempo de acesso para um sensor com histórico ........................................CXII
Figura 64 – Resultados do teste ao tempo de acesso para dez sensores com histórico.....................................CXII
Figura 65 – Resultados do teste ao tempo de acesso para vinte sensores com histórico ..................................CXII
Figura 66 – Ontologia de distribuição do contexto usada nos exemplos .........................................................CXVI
Figura 67 – Ontologia de dados do contexto usada no GCMAS .................................................................... CXVII

xiii
 Índice de tabelas
Vol I – Corpo da Tese

Tabela 1 – Requisitos do sistema desenvolvido .....................................................................................................31

Tabela 2 – Tipos de resposta da pesquisa de contexto ..........................................................................................56
Tabela 3 – Descrição dos objectos base da ontologia ...........................................................................................69
Tabela 4 – Comparação de funcionalidades com outros sistemas e arquitecturas ...............................................80
Tabela 5 – Funcionalidades do sistema desenvolvido ...........................................................................................84
Tabela 6 – Demonstração do funcionamento do sistema.......................................................................................85
Tabela 7 – Tempos de acesso ao sistema ...............................................................................................................86
Tabela 8 – Tempos de resposta do sistema ............................................................................................................87

Vol II – Anexos
Tabela 9 – Descrição dos Use Cases da aplicação do cenário e do sistema desenvolvido ........................... XXVIII
Tabela 10 – Descrição das entidades identificadas .....................................................................................XXXVIII
Tabela 11 – Relação entre pacotes e componentes........................................................................................ LXXIII

xiv
 Capítulo 1. Introdução

As pessoas possuem a capacidade de passar facilmente uma ideia entre si e de reagirem de

acordo com essa ideia. Isso deve-se a vários factores tais como a riqueza da linguagem que
usam para comunicar, o entendimento comum de como o mundo funciona e a forma implícita
como as pessoas entendem as situações do dia a dia.

Quando duas pessoas comunicam entre si existe uma quantidade de informação implícita
que nunca é transmitida directamente entre os intervenientes. Essa informação é denominada
de contexto.

A temática do contexto é abordada desde o tempo dos filósofos gregos que tentaram criar
uma definição no campo da linguística. Contexto é o conjunto de condições que influenciam a
compreensão e geração do comportamento linguístico. A conversação entre pessoas tem como
base um determinado contexto que será alterado ao longo desta.

A utilização de informação contextual permite assim um melhor desempenho dos

participantes na interacção. Este desempenho é melhorado pois as acções tornam-se mais
adaptadas à situação que se desenrola. A utilização de informação contextual permite também
aumentar a riqueza da comunicação sem sobrecarregar a informação explicitamente contida
nas mensagens trocadas.

1.1 Problemática do contexto e motivações

Na área da computação ciente do contexto (“context aware computing”) pensa-se que a
interacção entre pessoas e sistemas computacionais, ou entre sistemas computacionais, pode
beneficiar da utilização de informação contextual, tal como beneficia a interacção entre
pessoas.

1
 No entanto, a passagem desta definição para o domínio da informática não pode ser feita
de maneira simples, visto que as formas de comunicação entre os vários componentes da
aplicação e entre a aplicação e o exterior são muito limitadas. Para aumentar a capacidade de
uma aplicação aceder a informação contextual são usados sensores que fornecem vários
parâmetros do meio onde a aplicação e os seus utilizadores se encontram.

Para facilitar a comunicação entre sensores e aplicações são usados sistemas que adaptam e
modelam as informações retiradas destes. Por modelação entende-se a forma como os
sistemas representam a informação extraída dos sensores ou de outras fontes. Essa
representação pode ser feita por intermédio de uma ontologia que demonstra a estrutura dessa
informação.

Este processo permite que as aplicações que necessitam de informações de contexto não
precisem de se preocupar com a forma como este é obtido. Os sistemas de captura e
eventualmente de gestão de informação de contexto tratam de todo o processo de aquisição de
informação de contexto e de registo de sensores.

Ao se usarem tais sistemas, o desenvolvimento de aplicações mais adaptadas ao contexto

do utilizador e da própria aplicação torna-se mais simples. Os programadores terão de se
preocupar apenas com qual a informação que necessitam de trabalhar e aquilo que deverão
fazer com ela. O sistema de contexto tratará da forma como a informação é retirada dos
sensores, mantida e disponibilizada.

O uso de aplicações dependentes do contexto está-se a tornar numa área em

desenvolvimento visto que estas aplicações adaptam-se mais facilmente ao meio que as rodeia
do que as restantes. A interacção entre componentes da aplicação e entre esta e o exterior
pode ser simplificada na medida em que esta não necessita ser sobrecarregada com
informação contextual. Isto permite tornar os processos mais eficientes e mais adaptados ao
utilizador.

Esta tese de mestrado tem como objectivo a criação de um sistema de aquisição,

manutenção e disponibilização de informação contextual que possa ser usado por toda e
qualquer aplicação que dela necessite. O sistema desenvolvido irá facilitar e enriquecer o
acesso das aplicações ao contexto.

Este sistema irá disponibilizar o acesso a sensores e repositórios de informação às

aplicações que usem os seus serviços. Aplicações que necessitem de guardar informações de
contexto também podem utilizar o sistema para tal efeito. Isto permite não só o acesso à

2
informação sensorial por parte das aplicações como também o acesso a informações
fornecidas ao sistema por essa ou por outras aplicações. O sistema será denominado como
GCMAS (“Generic Context Management and Acquisition System”)

1.2 Inovações introduzidas pelo sistema de contexto

Vários modelos para desenvolvimento de sistemas de contexto foram propostos,
apresentando várias soluções para os problemas relacionados com a computação ciente do
contexto. Alguns destes modelos encontram-se ainda em fase de desenvolvimento e outros
apenas lidam com parte da problemática do contexto. Visto tratar-se de uma matéria bastante
recente, grande parte das ideias propostas pelos vários autores são apenas conceptuais.

Outro dos problemas é o facto de haver várias soluções diferentes para a problemática do
contexto, tal como é demonstrado no Capítulo 2. Cada autor apresenta uma solução para
resolver os problemas encontrados no desenvolvimento dos sistemas de contexto que
funcionam de acordo com a sua visão do problema. Ao se fazer isto está-se a ignorar partes da
problemática geral do contexto. Não foi ainda possível, no entanto, integrá-las todas, para que
se crie um sistema de contexto que aborde todos os aspectos da problemática da computação
ciente do contexto.

O GCMAS usa propostas de vários autores, integrando-as num sistema genérico, adaptável
a vários cenários onde o uso de contexto seja essencial para o aumento da eficiência e eficácia
das aplicações. Aspectos inovadores são também introduzidos pelo sistema.

A mais importante inovação é o uso de uma nova definição de contexto que melhor se
adapta àquilo que se entende como contexto numa aplicação. Esta tem em conta que as
informações de contexto são obtidas por um mecanismo que fornece uma quantidade limitada
de informação contextual referente a uma entidade. Esta limitação é imposta pelo número de
sensores ou informações fornecidas pela aplicação ou por terceiros para essa entidade.

O acesso a informação de contexto disponibilizada por sensores ou armazenada em

repositórios recorre a uma interface de pesquisa de informação. A possibilidade de subscrição
de eventos permite também a aplicações receber notificações sempre que o contexto sofra
alterações.

A introdução de extensões que aumentam o nível de abstracção da informação recolhida

permite o alargamento das funcionalidades do sistema. Estas possibilitam a organização,
agregação e inferência das informações de contexto.

3
 O uso de ontologias permite que se possa aceder a informação de contexto de forma
independente dos sensores e de outras fontes de informação, e facilita a introdução de vários
tipos de sensores sem que seja necessário redefinir o sistema ou as aplicações que o
consultam.

Para a criação de sistemas interactivos que colham, da utilização de informação de

contexto, as vantagens colhidas na interacção entre pessoas, tem de se entender em primeiro
lugar o que é o contexto e como este será utilizado nas aplicações [Dey e Abowd 1999]. Este
entendimento é introduzido na análise do sistema (ver Capítulo 3).

A compreensão do que é o contexto permite aos programadores definir que informações

são consideradas como contexto. A compreensão de como as aplicações vão usar este
contexto permite definir qual o comportamento das aplicações quando recebem essa
informação [Dey e Abowd 1999].

Vários autores propuseram definições de contexto ao longo do tempo. Algumas destas

eram muito específicas e outras muito abrangentes. A definição hoje em dia mais aceite é de
que o contexto é toda a informação que caracterize a situação de uma entidade. Entende-se
como entidade a pessoa, objecto ou aplicação relevante numa determinada interacção [Dey et
al 2001].

Esta definição de contexto é no entanto muito genérica fazendo com que seja impossível
logo ao início separar o contexto da restante informação de estado que deve ser transmitida na
interacção. A definição também não permite distinguir a informação de contexto de outra
informação, em termos do tipo de processamento adequado para cada uma delas.

A definição proposta nesta tese tem como base o contexto relativo a uma determinada
interacção entre duas ou mais entidades. Cada entidade está associada a um sistema de
contexto onde a informação contextual pode ser obtida.

O contexto dessa interacção é a informação que esteja definida na ontologia do sistema de

contexto para cada uma das entidades presentes e que seja relevante para essa interacção, em
conjunto com a informação de contexto relevante das entidades que não participem na
interacção mas que estejam mencionadas nas mensagens trocadas na interacção. Todas estas
informações não são essenciais para o funcionamento da aplicação, sendo elementos
adicionais à interacção mas que contribuam para a melhoria do seu desempenho.

4
 O tema desta tese de mestrado deu origem a um artigo publicado na YR-SOC (“First
European Young Researchers Workshop on Service Oriented Computing”), o qual está
apresentado no Anexo X.

1.3 Descrição da abordagem usada para o desenvolvimento do

GCMAS
Uma das inovações introduzidas pelo GCMAS é a sua interligação com outras aplicações.
Para poder comunicar com o exterior, o sistema possui várias interfaces. Estas permitem a
comunicação entre o sistema e as aplicações que pesquisam ou fornecem contexto.

Dois tipos de interfaces são distinguidos no sistema, as interfaces para os sensores e as

interfaces para as aplicações. As interfaces para as aplicações permitem a estas comunicar
com o sistema de contexto. As interfaces para os sensores permitem o registo e transmissão de
informação de contexto dos sensores. Estas interfaces implementam funcionalidades
genéricas que permitem a comunicação com qualquer tipo de sensor.

As interfaces para as aplicações definem as funcionalidades que o sistema de contexto

apresenta às aplicações que o utilizam. Estas funcionalidades são a pesquisa de informação de
contexto, a subscrição de eventos de contexto e fornecimento de informação de contexto.

Do lado dos sensores, as interfaces de comunicação com o sistema de contexto são

disponibilizadas em conjunto com pacotes de desenvolvimento de sensores. Estes pacotes
possuem os mecanismos necessários à interacção dos sensores com o sistema. A existência
destes mecanismos permite ocultar o funcionamento interno do sistema.

O sistema desenvolvido nesta tese será integrado numa aplicação de agentes baseadas em
serviços electrónicos disponíveis através da Internet (“on-line”). Esta integração permite a
introdução do contexto na área dos serviços electrónicos.

Relativamente à ontologia a ser usada, esta pode ser actualizada quando novos sensores são
adicionados ao sistema ou pelas aplicações que guardam informações de contexto no
repositório. Isto permite a actualização da ontologia enquanto o sistema está em execução.

Na Figura 1 encontra-se representada uma visão geral da arquitectura do GCMAS,

integrado numa plataforma de serviços. Esta integração recorre às interfaces definidas pelo
sistema.

5
 Como este é acedido por várias aplicações, torna-se necessário definir várias interfaces,
adequadas aos vários tipos de aplicações. O leque de aplicações varia desde agentes até
aplicações baseadas em componentes. Cada uma das interfaces definidas traduz os pedidos de
pesquisa, registo e fornecimento de contexto enviados pelas aplicações para uma linguagem
interna do sistema de contexto. Para além do leque de aplicações abrangido pelas interfaces
desenvolvidas nesta tese, outras interfaces podem ser facilmente adicionadas.

Figura 1 – Arquitectura do GCMAS integrado numa plataforma orientada para serviços

O tratamento da informação de contexto proveniente dos sensores é relativamente pouco

sofisticada. Considera-se mais importante a simplicidade do sistema, para que este seja
genérico e tenha interfaces fáceis de usar.

Aplicações que solicitem informações que requeiram, por exemplo, uma agregação
complexa de informações de vários sensores não o poderão fazer directamente no sistema.
Para tal recorre-se às extensões definidas para o sistema.

Uma das extensões definidas trata-se do módulo de interpretação de contexto. Denominado

de interpretador de contexto, é específico de uma determinada aplicação e permite que esta
faça operações de alto nível sobre o contexto.

6
 O interpretador de contexto possui ferramentas de adaptação da informação de contexto,
raciocínio e agregação de contexto, implementadas do lado da aplicação que usa o sistema.
Sendo um módulo adicional, o interpretador de contexto comunica directamente com os
elementos internos do sistema.

O uso deste módulo permite garantir a permanência da estrutura genérica do sistema. A

adaptação da informação à estrutura de uma aplicação é feita exclusivamente nos módulos de
interpretação de contexto. Outras funcionalidades mais específicas podem ser acrescentadas
ao sistema através destas extensões.

O contexto é não só a informação actual proveniente de um sensor ou fornecida por uma

aplicação cliente. O histórico dos valores anteriores medidos nos sensores ou fornecidos ao
sistema por terceiros também fazem parte da informação de contexto relevante para as
aplicações clientes.

O GCMAS possui um mecanismo de gestão de histórico que permite guardar um

determinado número de amostras da informação capturadas do mundo exterior; tanto estas
sejam provenientes de sensores como de aplicações que queiram armazenar informações de
contexto. A pesquisa sobre este tipo de informação tem de ser especificado pelas aplicações.

A arquitectura do GCMAS é baseada em componentes. Cada sensor é considerado pelo

sistema como sendo um componente. O acesso às funcionalidades é feito apenas através das
suas interfaces. Estas são implementadas por alguns dos componentes internos do sistema.

Isto permite que a organização interna e os mecanismos de registo de sensores possam ser
alterados sem afectar as aplicações que acedem ao sistema.

1.4 Critérios de avaliação e cenário de demonstração

O sistema será testado numa demonstração do cenário proposto no Capítulo 3. Este cenário
trata-se de um exemplo de uma situação de emergência médica onde a informação de
contexto é aplicada a uma aplicação de resolução de problemas de auxílio em situações de
emergência médica.

Para avaliar o sistema desenvolvido nesta tese e verificar a sua aplicação ao cenário
proposto são considerados vários critérios de avaliação. Estes são definidos para demonstrar
vários aspectos do sistema aplicados ao cenário proposto. Os critérios serão avaliados usando
exemplos retirados do cenário de demonstração que provem a satisfação do critério. Os
critérios definidos para avaliar o sistema desenvolvido são os seguintes:

7
 • O GCMAS deve trazer melhorias à computação ciente do contexto relativamente a
outros sistemas similares.

• O GCMAS deve de implementar as funcionalidades descritas nos requisitos dos

sistemas cientes do contexto.

• Os tempos de resposta do GCMAS relativos a várias situações de carga não devem

limitar o seu uso por aplicações mais exigentes.

• O GCMAS deve ser robusto relativamente à falha de sensores e á falha de alguns

dos componentes internos.

1.5 Resultados da avaliação

Da avaliação feita ao GCMAS chegou-se aos seguintes resultados:

• O GCMAS permite abranger a problemática do contexto de uma forma mais

completa que as arquitecturas concorrentes. Este possui as características
fundamentais de várias arquitecturas que se centram num só aspecto desta
problemática.

• Foi implementada grande parte das funcionalidades descritas como requisitos de

um sistema de contexto, estando a restante parte já determinada na fase de desenho
do sistema.

• Os tempos de resposta obtidos pelos testes ao sistema comprovaram que os atrasos

no acesso ao sistema são poucos significativos.

• O sistema é suficientemente robusto para suportar falhas de sensores e de alguns

dos seus componentes internos sem que isto afecte o funcionamento das
funcionalidades não implementadas por esses componentes.

1.6 Organização da tese

Esta tese encontra-se organizada na seguinte forma:

Após o capítulo introdutório segue-se o capítulo 2 (Estado Actual dos Conhecimentos),

onde são descritos algumas das soluções propostas por diversos autores relativamente a
assuntos relacionados com o contexto tais como a sua definição, modelação e processamento.
São também apresentadas algumas arquitecturas de dependência de contexto.

8
 No capítulo 3 (Análise do Sistema) procede-se à descrição do cenário proposto nesta tese e
posterior identificação das interacções existentes no cenário. A análise do sistema continua
com a descrição dos diagramas de casos de utilização (“use cases”) criados a partir do
cenário. Apresenta-se o diagrama com a visão geral do cenário da aplicação, seguido do
diagrama de casos de utilização do GCMAS. O capítulo termina com a apresentação dos
requisitos recolhidos dos diagramas de casos de utilização.

O capítulo 4 (Ontologia do Contexto) identifica os elementos de contexto presentes em

cada interacção e define quais as informações que os caracterizam e que são consideradas
como contexto. O capítulo inicia-se com uma análise do tipo de ontologia a ser usado para o
sistema, onde são descritas as soluções encontradas. O capítulo termina com a descrição
pormenorizada da estrutura da ontologia do contexto.

O capítulo 5 (Descrição do Sistema) trata dos aspectos de desenho e implementação do

sistema. Aqui encontra-se a descrição detalhada de cada um dos componentes da arquitectura
e a forma como estes comunicam. O capítulo inicia-se com uma visão geral da arquitectura,
onde são apresentados os aspectos fundamentais e são identificados os componentes do
sistema. Segue-se a descrição pormenorizada de cada um dos componentes e a indicação de
quais que foram desenvolvidos. Seguidamente são apresentadas as várias fases de
desenvolvimento do sistema. Nesta secção são apresentadas as decisões tomadas nas várias
fases de desenvolvimento do sistema. O capítulo termina com a descrição de alguns dos
problemas encontrados no desenvolvimento.

O capítulo 6 (Avaliação do Sistema Definido e Implementado) apresenta uma descrição

pormenorizada de cada um dos critérios que irão avaliar o desempenho da aplicação. Os
resultados dos testes feitos à aplicação e comparação dos mesmos com os critérios são
também apresentados. O capítulo inicia-se com a descrição de cada um dos critérios. Termina
com os resultados dos testes feitos ao sistema.

O capítulo 7 (Conclusões e Trabalhos Futuros) apresenta as conclusões do

desenvolvimento e utilização do GCMAS. Este é o capítulo conclusivo da tese de mestrado.
Neste capítulo é também apresentada uma perspectiva dos trabalhos futuros a serem
desenvolvidos.

9
 Capítulo 2. Estado Actual dos Conhecimentos

A dependência no contexto tem vindo a ganhar grande importância na comunidade

científica com o surgimento de cada vez mais aplicações que usam informações provenientes
de sensores tanto físicos como de software. A primeira ideia que se tem de informação de
contexto é a localização do utilizador, no entanto, com o alargamento da definição deste
conceito [Anagnostopoulos et al 2004, Dey 1998, Dey e Abowd 1999, Schilit e Theimer 1994]
foram consideradas outras informações como o estado das ligações numa rede, equipamento
existente nas redondezas do utilizador e ambiente social.

Existem várias definições para contexto, o que torna complexo o desenvolvimento de

aplicações baseadas nesse conceito. Segundo Anagnostopoulos e seus colaboradores
[Anagnostopoulos et al 2004] a definição de contexto mais aceite pela comunidade científica
é dada pela seguinte afirmação: “Contexto é a informação que pode ser usada para
caracterizar a situação de uma entidade. Uma entidade é uma pessoa, objecto ou lugar que
sejam considerados relevantes para a interacção entre o utilizador e a aplicação, incluindo eles
próprios” [Dey e Abowd 1999]. De acordo com estes autores o contexto pode ser circunscrito
como um conjunto de situações que descrevem pessoas, aplicações e o meio onde se realizam
as actividades.

Numa visão geral, um sistema de dependência no contexto (SDC) é um conjunto de

serviços que se adaptam de acordo com factores do ambiente tais como local de utilização,
pessoas e objectos ao seu redor, assim como as mudanças nesses objectos ao longo do tempo.

Com o aparecimento dos dispositivos móveis, o contexto passou a ser um elemento

importante para a melhoria da performance das aplicações destinadas a estes dispositivos
[Gold e Mascolo 2001]. Existem vários projectos [Ambi04, Chalmers e Sloman 1999, Chen et
al 2000, Capra et al 2001, Capra et al 2003, Gellersen et al 2002, Korpipää e Mäntyjärvi 2003,

10
Yau e Karim 2001] que investigam a forma como o contexto pode ser útil no melhoramento
de serviços e na criação de novos serviços nas redes móveis das próximas gerações.

Um desses projectos é o WWI Ambient Networks [Ambi 2004]. Este projecto irá criar
soluções para além da terceira geração, promovendo uma rede escalável e de baixo custo que
permite um acesso fácil aos serviços disponibilizados. Estas soluções incluem o uso da
dependência no contexto para a selecção da melhor ligação, serviços de localização e
orientação geográfica entre outros.

Um outro projecto apresentado por Chalmers e seus colaboradores [Chalmers e Sloman

1999] propõe o uso de uma plataforma (“framework”) que permite a gestão da qualidade de
serviço em redes móveis usando a dependência no contexto para analisar as características do
utilizador.

Várias arquitecturas e abordagens [Anagnostopoulos et al 2004, Cortese et al 2004, Costa

et al 2003, Chen et al 2003, Davis et al 2003, Davis et al 2003a, Kummerfeld et al 2003,
Michachelles e Samulowitz 2001, Rubinsztejn et al 2004, Samulowitz et al 2001] para lidar
com o contexto foram discutidas ao longo do tempo mas no entanto ainda não existe uma
solução normalizada que satisfaça todas as suas possíveis utilizações.

Neste capítulo são apresentadas em primeiro lugar algumas das definições de contexto
dadas por vários autores. Segue-se uma descrição das soluções encontradas para a detecção de
contexto, a sua modelação e processamento. Seguidamente, descrevem-se algumas das
arquitecturas desenvolvidas para lidar com contexto. Finalmente, apresentam-se comentários
finais sobre a matéria.

2.1 Definições de contexto

A definição de contexto nas aplicações informáticas foi adaptada da sua utilização na
linguagem corrente. No entanto, ainda não existe uma definição exacta para o que é o
contexto de uma aplicação. O seu significado na linguagem corrente está relacionado com a
interpretação do texto escrito ou falado. O texto não é uma representação encapsulada de um
determinado significado mas sim uma indicação que permite a construção antecipada de um
significado. Essa construção é baseada naquilo que vem com o texto, ou seja o contexto.
Numa frase, cada palavra tem um significado mas o significado global da frase apenas pode
ser determinado fazendo inferências sobre o seu contexto [Winograd 2001].

11
 Linguistas e filósofos fizeram um grande esforço para identificar os vários elementos do
contexto que dão significado às palavras. Ao se tentar passar o contexto para o domínio da
informática está-se a trabalhar com a complexidade do conhecimento humano [Winograd
2001]. Por essa razão, vários autores criaram as suas próprias definições do que é o contexto
nas suas aplicações, o que levou a diferentes abordagens para adquirir informação do meio
ambiente.

Winograd [Winograd 2001] define o contexto como sendo não só as estruturas de dados no
sistema operativo (tais como janelas ou aplicações), como também algo mais para além da
aplicação que está a ser usada. Contexto é um termo operacional; algo é considerado contexto
se for usado em alguma iteração.

Para Schilit e Theimer [Schilit e Theimer 1994] o contexto consiste das identidades das
pessoas, dos objectos próximos da aplicação assim como as suas mudanças para além da
simples localização.

Dey [Dey 1998] adiciona à definição de contexto os estados emocionais, a atenção do

utilizador, localização e orientação, data e hora, objectos e pessoas no ambiente do utilizador.

Para Anagnostopoulos e seus colaboradores [Anagnostopoulos et al 2004] contexto é

conjunto de situações que descrevem pessoas, aplicações e ambiente relacionados com uma
determinada actividade.

A definição de contexto mais aceite pela comunidade científica é a de Dey e Abowd [Dey
e Abowd 1999] onde se refere que o contexto é definido como qualquer informação que
caracterize uma situação ou entidade.

Segundo Schmidt e seus colaboradores [Schmidt et al 1998]., o contexto pode ser dividido
em duas categorias, factores humanos e ambiente físico. Cada uma destas categorias pode ser
por sua vez dividida em três subcategorias: Utilizador, ambiente social e tarefa, para os
factores humanos; e localização, infra-estrutura e condições, para o ambiente físico.

Descrições pormenorizadas de algumas destas definições podem ser observadas na secção

1.01 do Anexo I.

2.1.1 Análise crítica

Das definições apresentadas conclui-se que o conceito de contexto é muito vasto. A
definição da informação de contexto necessária irá depender da aplicação que a requer. A
categorização da informação de contexto proposta por Schmidt e seus colaboradores permite

12
uma melhor compreensão e limitação daquilo que é realmente a informação de contexto. As
restantes definições introduzem factores importantes que podem ser considerados como
contexto para além da simples localização. No entanto, sozinhas não conseguem abranger
toda a dimensão do contexto excepto a definição proposta por Dey e Abowd. Esta abrange a
dimensão do contexto mas no entanto peca por ser demasiado generalista, considerando quase
toda a informação como sendo de contexto. Nem sempre toda a informação do ambiente que
envolve a aplicação é contexto. Muitas das vezes a decisão de considerar ou não uma
determinada informação como contexto é uma tarefa de desenho.

Tal como existem várias definições para o contexto também existem várias
implementações e modelos para lidar com este.

2.2 Análise às abordagens de modelação do contexto

O que quer que seja considerado contexto numa aplicação terá de passar por um processo
de recolha, modelação e processamento, transformando o contexto em algo útil para ser usado
[Anagnostopoulos et al 2004], [Laamanen e Helin 2004].

A fase de recolha normalmente está associada aos sensores. Grande parte da informação de
contexto é adquirida de sensores implementados em hardware e software. Várias abordagens
lidam com a informação adquirida por estes sensores, trazendo o entendimento da natureza da
informação de contexto em primeiro lugar. Uma visão mais aprofundada destas abordagens
encontra-se descrita na secção 1.02 do Anexo I.

Destas identificam-se vários aspectos importantes para o desenvolvimento desta tese. Em

primeiro lugar há que distinguir entre a captura de informação de contexto e a sua modelação.
O primeiro pode ser obtido por sensores de hardware ou software. O segundo normalmente
envolve ferramentas e ontologias definidas num sistema de contexto.

O contexto capturado pode ou não variar ao longo do tempo. Segundo Henricksen e seus
colaboradores [Henricksen et al 2002], a informação de contexto é considerada estática
quando não varia muito ao longo do tempo. A relevância da variação do contexto diz respeito
aos métodos utilizados no seu armazenamento.

Outros aspectos relacionados com a captura e armazenamento, tais como a reutilização da

informação capturada, permitem a criação de contexto mais rico. Este é, para além da
informação recolhida no momento, todo o histórico de alterações dessa informação ao longo
do tempo [Henricksen et al 2002].

13
 Durante a captura, há que ter em conta os erros e os atrasos introduzidos pelo
processamento desta informação. Uma forma de evitar esses erros é recorrendo à fusão de
dados [Gellersen et al 2002].

Em aspectos de organização do contexto, as ontologias são a forma mais indicada de

representar esta informação, visto que permitem impor-lhe uma estrutura e um nível de
abstracção independentes dos sensores de contexto e de outras fontes usadas. Qualquer
entidade que receba essa informação consegue entendê-la desde que conheça a sua ontologia
[Filho e Sinderen 2003].

A organização do contexto pode ser realizada segundo vários aspectos. O contexto pode
ser visualizado em várias dimensões tais como o ponto de vista dos dispositivos, das
aplicações, da localização, entre outros. A forma como o contexto é extraído (de sensores de
hardware ou de software) também representa um aspecto do contexto [Goslar et al 2003].

A proposta de Cortese e seus colaboradores [Cortese et al 2004] demonstra-nos a

complexidade de gestão de um grande número de sensores. O modelo proposto por estes
autores assume que toda a interacção com o utilizador passará a ser feita através de sensores.
Isto implica que o modelo de contexto a aplicar seja extensível para que possa abranger cada
situação em que é aplicado.

Estes autores definem também dois métodos de extracção de informação de sensores, o

método receber (“push”) e o método buscar (“pull”). Estes métodos demonstram que os
sensores tanto podem ser activos, enviando sempre informação para um sistema, como podem
ser passivos, enviando a informação apenas quando são feitos pedidos.

Prekop e Burnett [Prekop e Burnett 2002] definem um modelo de contexto centrado na

actividade. Este modelo considera o contexto que cobre a actividade de um utilizador, só
tendo significado quando se realiza essa actividade. Esta visão difere bastante das visões
anteriores mas no entanto está limitada a actividades de utilizadores. Uma análise mais
pormenorizada deste conceito encontra-se no final da secção 1.02 do Anexo I.

Das soluções propostas nas abordagens descritas na secção 1.02 do Anexo I, conclui-se
que propostas como as de Anagnostopoulos e seus colegas [Anagnostopoulos et al 2004] e de
Christopoulou e os seus colaboradores [Christopoulou et al 2004] podem servir como ponto
de partida para o desenvolvimento de um sistema ciente do contexto. Estas identificam os
principais aspectos a focar num sistema deste género.

14
 A proposta de Anagnostopoulos e seus colegas define que o contexto deve ser representado
num esquema de classes com associações. Estas ligam os elementos de contexto e lidam tanto
com contexto dinâmico como com contexto estático. A proposta define que para além destas
associações o modelo de contexto deve permitir dependências.

O uso de dependências permite associar relações entre elementos de contexto. Estas

associações determinam por exemplo a dependência de elementos de contexto numa
actividade, tal como demonstrado na Figura 18 presente no Anexo I.

Christopoulou e os seus colaboradores apresentam um tipo de associação semelhante, a

sinapse. Estas representam preferências e necessidades dos elementos associados. A proposta
define também que o contexto deve ser representado por uma ontologia com vários níveis.

Da proposta de Anagnostopoulos e seus colegas retira-se que um sistema de contexto deve

implementar um determinado conjunto de funcionalidades. Funcionalidades como a aquisição,
a agregação, a descoberta, pesquisa de contexto e outras, estão demonstradas na Figura 19
presente no Anexo I.

As visões conceptuais de arquitecturas para um sistema de contexto, descritas na secção

1.03 do Anexo I, apresentam algumas vantagens e desvantagens. Uma combinação destes
conceitos ajudaria a eliminar as desvantagens que cada um deles apresenta isoladamente.

Um sistema pode ser apresentado às aplicações e sensores como um bloco de captura de

contexto. Interfaces definem os seus serviços e o acesso por parte de sensores. Isto permite
usufruir das vantagens de manutenção, actualização e de independência do hardware do
modelo de infra-estrutura [Hong e Landay 2001].

O interior da infra-estrutura pode ser constituído por componentes que implementam as

funcionalidades do sistema. Cada sensor pode também ser tratado como componente que
implementa uma interface abstracta. Isto permite usufruir das vantagens do modelo de
componentes tais como a modularidade e a unificação do acesso a sensores numa só interface
[Dey et al 2001].

Ao armazenamento de informação de contexto num sistema pode ser aplicado o modelo de

repositório. Este permite um acesso centralizado ao contexto tanto por parte de produtores de
informação de contexto como por parte de consumidores. As vantagens obtidas pela
utilização deste modelo prendem-se com a facilidade da gestão da informação de contexto
[Winograd 2001].

15
 Um sistema pode ser também apresentado como uma camada intermédia numa rede de
serviços [Ritchie 2002]. Isto permite aplicar a dependência do contexto em serviços que não
estejam preparados para lidar com o contexto tal como demonstrado na Figura 22 presente no
Anexo I. Toda a parte do processamento de informação de contexto será feita por essa camada
intermédia de forma transparente para os serviços. Os processos relativos ao contexto são
efectuados pela camada intermédia.

A estruturação do contexto é um aspecto que tem de ser abordado antes da implementação.

Os modelos de informação de contexto apresentados por Anagnostopoulos e seus colegas, e
por Christopoulou e os seus colaboradores são bastante completos (ver secção 1.02 do Anexo
I). Tanto as sinapses como as dependências são aspectos importantes a serem focados durante
a identificação dos elementos do contexto.

Várias arquitecturas que lidam com a dependência do contexto foram desenvolvidas a

partir dos modelos descritos nesta secção.

2.3 Arquitecturas de dependência do contexto

O ponto comum de todas as arquitecturas de dependência no contexto é a sua estrutura
hierárquica. Esta estrutura cobre dois níveis: operacional e informativo, tal como apresentado
na Figura 2. No nível operacional, têm-se os módulos do sistema que poderão ser sensores,
mediadores que transformam os dados dos sensores em dados de alto nível, agentes
inteligentes que reúnem o conhecimento no sistema e aplicações que oferecem serviços de
dependência no contexto aos utilizadores. No nível informativo, tem-se a representação do
conhecimento adquirido no contexto.

Figura 2 – Estrutura hierárquica das arquitecturas

16
 Este pode ser representado num modelo de dados simples, num modelo semelhante ao
orientado por objectos ou numa ontologia [Anagnostopoulos et al 2004]. A Figura 2
representa de forma genérica estes dois níveis das arquitecturas de sistemas de contexto.

A informação de contexto é recolhida por redes de sensores e posteriormente modelada

para se adaptar essa informação às aplicações que dela necessitem. Os sensores podem ser
usados simplesmente como mecanismos de recolha de dados, no entanto podem também ser
usados como um mecanismo mais sofisticados para determinar a situação de um utilizador.
As arquitecturas de sensores possuem apenas o nível operacional, visto que não há definição
da forma como a informação de contexto é apresentada.

2.3.1 Arquitectura Smart-its e de pacotes cientes do contexto

Arquitectura descentralizada proposta por Michachelles e Samulowitz [Michachelles e
Samulowitz 2001] e ideal para ambientes móveis e redes ad-hoc. Armazena a informação de
contexto recolhida por sensores (“Smart-it”) em pacotes que depois são passados de sensor
em sensor. Estes pacotes são denominados sCAP (“Smart Context-Aware Packets”).

Não existe um ponto de controlo central, sendo os sensores que tomam conhecimento dos
seus vizinhos. Um sensor só acrescenta informação de contexto num pacote que recebe se esta
tiver alguma similaridade com o contexto que este contém.

Cada pacote está organizado em três partes: o plano de recolha, o contexto provável e o
caminho de recolha. O plano de recolha é um plano baseado num modelo inicial que depois é
adaptado cada vez que um pacote passa por um sensor. O contexto provável é a lista de
informações recolhidas do sensor. O caminho de recolha representa a lista de sensores já
visitados.

Depois de passar por todos os sensores definidos no plano de recolha os pacotes são
enviados directamente ao utilizador que os requisitou. Este depois dará o tratamento que
quiser à informação. Uma descrição mais aprofundada desta arquitectura encontra-se na
secção 1.04 do Anexo I.

A arquitectura, proposta por Samulowitz [Samulowitz et al 2001], também refere o uso de

pacotes de forma semelhante à arquitectura Smart-its. Uma descrição mais aprofundada desta
arquitectura encontra-se na secção 1.04 do Anexo I.

17
2.3.2 Arquitectura Merino
Esta arquitectura, apresentada por Kummerfeld [Kummerfeld et al 2003], classifica
sensores por capacidades. Estes podem ser normais, sensores inteligentes e agentes de
ambiente. É definido também o modelo do utilizador e o repositório. Esta arquitectura está
representada na Figura 3.

Sensores que estejam em camadas mais altas produzem informação de mais alto nível,
promovendo uma visão mais complexa do contexto. Os sensores nas camadas mais baixas
limitam-se a recolher informações do ambiente.

O repositório é o local onde os agentes processam os dados recolhidos. As necessidades do

utilizador são representadas no modelo do utilizador. Este é controlado por um assistente
pessoal inteligente.

Figura 3 – Arquitectura Merino

Uma descrição mais aprofundada desta arquitectura encontra-se na secção 1.04 do Anexo I.

2.3.3 Arquitectura proposta por Cortese e seus colaboradores

Esta arquitectura proposta por Cortese e seus colaboradores [Cortese et al 2004] define um
modelo lógico de arquitectura dividido em duas camadas. Esta divisão separa a captura de
informação dos sensores do tratamento desta.

Na camada inferior, denominada de camada de sensores, procede-se à extracção da

informação dos sensores. Na camada superior, denominada camada semântica, adapta-se a
informação recolhida de acordo com uma ontologia definida.

A informação é publicada num repositório comum onde agentes de fusão geram

informação adicional com um nível mais alto de abstracção. Uma descrição mais aprofundada
desta arquitectura encontra-se na secção 1.04 do Anexo I.

18
2.3.4 Arquitectura WASP
A arquitectura WASP (“Web Architectures for Service Platforms”) [Costa et al 2003] define
um ambiente de desenvolvimento genérico que suporta a execução de serviços móveis com
dependência do contexto (Figura 4). A ideia base desta arquitectura é ocultar a complexidade
introduzida pela manipulação do contexto. Isto consegue-se usando módulos de interpretação
que oferecem serviços de dependência no contexto às aplicações. Esses módulos reúnem a
informação de contexto e disponibilizam-na ao resto da plataforma. Esta arquitectura tem
presente apenas o nível operacional visto que lida apenas com desafios de desenho da
aplicação.

Figura 4 – Arquitectura WASP

A plataforma inclui repositórios que suportam um componente de monitorização que tem

conhecimento dos elementos envolvidos no ambiente de desenvolvimento. Este componente
de monitorização é responsável pela subscrição e integração das aplicações WASP, e pela
recolha de informação dos repositórios e interpretadores de contexto. A informação de
contexto é subscrita pelos serviços que estão inscritos na plataforma, sendo posteriormente
processada no interpretador de contexto.

Ao se inscreverem na plataforma, as aplicações configuram-na para que reaja de acordo

com um determinado conjunto de eventos, que podem envolver informação de contexto.

São usadas ontologias para modelar o contexto, permitindo que os componentes da

arquitectura partilhem conhecimento.

Para obter contexto mais complexo, diferentes entidades fornecedoras de contexto devem
partilhar a mesma representação contextual.

19
 A arquitectura apresentada permite a uma aplicação obter informação de contexto de uma
forma transparente. Os problemas de manipulação de contexto são resolvidos dentro desta
arquitectura. No entanto, a parte relacionada com a captura da informação de contexto terá de
ser tratada pelos serviços que fornecem essa informação. A ideia de ocultar a complexidade
do processamento da informação de contexto introduzida por esta arquitectura pode ser usada
para os objectivos desta tese.

2.3.5 Arquitectura CoBrA

A arquitectura CoBrA (“Context Broker Architecture”) [Chen et al 2003] é uma
arquitectura baseada em agentes que suporta dependência no contexto em sistemas
inteligentes, tais como os sistemas que compõem uma casa inteligente, ou um veículo
inteligente (Figura 5). Esta arquitectura possui um elemento central que fornece uma visão
geral do contexto aos restantes agentes, o mediador de contexto (“context broker”). Este
elemento fornece também privacidade ao impor as políticas de acesso definidas por cada
agente. A arquitectura tem presente o nível operacional na parte do seu desenho, e o nível
informativo está presente no modelo da informação de contexto.

Para que esta arquitectura funcione é definida uma colecção de ontologias para modelar o
contexto, um modelo partilhado do contexto é uma linguagem declarativa de políticas que os
utilizadores e dispositivos poderão usar para impor limitações no acesso a informação
protegida. Esta linguagem de políticas permite também aos utilizadores controlar as suas
informações de contexto. A arquitectura CoBrA usa o OWL [W3C 2004] como linguagem de
ontologia.

O mediador de contexto (“context broker”), é um agente criado para manter e gerir o

modelo partilhado do contexto e que está associado a um determinado espaço inteligente
(“smart space”), como por exemplo uma casa inteligente. Este agente é constituído por vários
outros agentes mediadores que representam partes mais pequenas do espaço.

20
 Figura 5 – Arquitectura COBrA

Ao se usar esta visão descentralizada consegue-se evitar os problemas de engarrafamentos

associados ao acesso a um mediador centralizado. O mediador de contexto pode também
inferir informações de contexto que não possam ser facilmente adquiridas pelos sensores, e
que poderão ser usadas para complementar o contexto com elementos que faltem. A principal
função do agente de contexto é a aquisição de informações de contexto de várias fontes, a
fusão dessa informação num modelo coerente e posterior partilha esse modelo com outras
entidades no ambiente.

As soluções propostas por esta arquitectura são ideais para redes de agentes. O uso de um
agente como mediador de contexto permite que a comunicação desta arquitectura com outras
arquitecturas de agentes possa ser feita usando directamente uma linguagem de comunicação
de agentes.

A distribuição do mediador de contexto por vários domínios permite uma maior robustez
do sistema, visto que a falha de um dos mediadores não põe em causa o funcionamento do
resto do sistema. A ideia de mediador de contexto proposta nesta solução é a mais adaptada
para os objectivos desta tese, no entanto tem como desvantagem o facto de as aplicações
precisarem de conhecer a linguagem de comunicação de agentes e respeitar os protocolos de
comunicação. A aquisição do contexto é da responsabilidade do mediador de contexto, no

21
entanto se se usarem redes de sensores, grande parte dessas funcionalidades seria distribuída.
Essa distribuição iria trazer uma maior robustez à arquitectura.

2.3.6 Context Tailor

Esta arquitectura, proposta por Davis e seus colaboradores [Davis et al 2003, Davis et al
2003a], é baseada em componentes. Consiste num serviço de contexto que recolhe dados de
um conjunto de fontes geradoras de contexto. Estes dados são guardados num repositório e
disponibilizados às aplicações via uma API.

Mecanismos de aprendizagem abstraem padrões da informação de contexto para

posteriores pesquisas. Nesta arquitectura, estão presentes o nível informativo e o nível
operacional.

Esta arquitectura é constituída por fontes geradoras, um repositório para o histórico do

contexto, um motor de aprendizagem, um repositório de padrões de contexto, um activador
desses padrões, e um servidor que coordena a interacção entre estes componentes.

O serviço de contexto serve como um repositório de camada intermédia (“middleware”)

que disponibiliza contexto sobre uma determinada entidade. Este serviço gere a ligação com
cada fonte de contexto, apresentando a informação de contexto às aplicações através de uma
API. A estrutura desta arquitectura encontra-se descrita na Figura 6.

O servidor regista os pedidos de contexto feitos pelos utilizadores e guarda toda a

informação de contexto fornecida pelo serviço no repositório de contexto. Cada entrada de
contexto é formada por quatro campos: uma marca temporal, uma identificação do utilizador,
um tipo de contexto e um estado de contexto. Cada tipo de contexto corresponde a um
determinado formato de representação. O estado do contexto contém informação do contexto
de um determinado tipo, observado a uma determinada altura.

O Mecanismo de aprendizagem aplica algoritmos de aprendizagem às informações de

contexto no repositório, abstraindo padrões de contexto. Esses padrões são depois
armazenados no repositório de padrões.

Cada padrão é constituído por uma condição, uma pré-condição, um nível de semelhança
entre padrões e um suporte. As pré-condições e as condições definem conjuntos de eventos,
onde cada evento representa uma instância dos atributos do contexto.

22
 Figura 6 – Arquitectura Contex Tailor

Esta arquitectura apresenta uma solução de captura e armazenamento de informação de

contexto que poderá ser útil para os objectivos da tese. No entanto o uso de uma API implica
que esta tenha de ser genérica e bem estruturada para que suporte vários tipos de sensores. A
existência de uma API permite que qualquer aplicação que a conheça possa aceder ao sistema.
A solução da API permite um acesso generalizado, mas no entanto a sua criação ou
actualização é complexa. A estrutura da API não poderá mudar muito, pois isso implicaria
também a alteração das aplicações que lhe acedem.

2.3.7 Análise crítica

As arquitecturas de sensores apresentadas mostram várias formas de lidar com o contexto
ao nível dos sensores. Com o uso destas arquitecturas está-se a resolver em parte o problema
da integração do contexto. A arquitectura Smart-its está mais adaptada a redes sem elementos
centrais. Tanto esta como a arquitectura de pacotes cientes do contexto requerem o uso de
sensores mais sofisticados. Para uma melhor integração de vários tipos de sensores têm-se a
arquitectura Merino. Esta arquitectura difere vários tipos de sensores assim como um
repositório onde estes podem guardar informação.

As três arquitecturas completas apresentadas focam alguns aspectos importantes para

desenvolvimento desta tese. No caso de se querer usar redes de agentes, a solução mais
adaptada é a arquitectura CoBrA, visto que o seu principal componente é baseado num agente.
Pode-se desta forma usar directamente os mecanismos de comunicação de agentes. Nas
restantes arquitecturas, para possibilitar que vários tipos de aplicações acedam ao sistema, é
necessário o uso de uma plataforma que seja acessível por uma API. Esta API teria de ser

23
flexível o suficiente para permitir a introdução de vários tipos de informação de contexto e
sensores. A solução da arquitectura WASP permite apenas ocultar o processo de manipulação
de informação. Estas arquitecturas mostram soluções diferentes para lidar com o contexto. No
entanto em nenhuma delas se refere directamente o uso de redes de sensores. Em todas elas os
sensores são referidos de uma maneira geral, não havendo diferenciação entre sensores
simples, sensores inteligentes e redes de sensores. Também não é feita nenhuma referência
aos pacotes gerados pelas redes de sensores, assumindo-se assim que estes não são tratados
nestas arquitecturas.

A solução desenvolvida nesta tese terá como base tanto as soluções apresentadas nestas
arquitecturas tendo também em atenção a camada dos sensores. A arquitectura proposta nesta
tese terá de estar ciente da existência de vários tipos de sensores. Estará adaptada a receber
tanto informações simples enviadas por sensores normais, como informações mais complexas
e até mesmo pacotes gerados por redes de sensores e sensores inteligentes.

2.4 Conclusões finais

Dos modelos e arquitecturas revistos ao longo desta revisão do estado actual dos
conhecimentos, conclui-se que ainda não existe nenhuma solução definitiva para lidar com o
contexto. Nenhuma das arquitecturas aborda o tema do contexto no geral. Apenas são
propostas algumas soluções para alguns dos vários problemas relacionados com o contexto.
Várias propostas foram apresentadas, cada uma com a sua visão própria para lidar com
determinados problemas relacionados com a captura, modelação e processamento da
informação de contexto. Das arquitecturas apresentadas nenhuma delas foca todos os aspectos
relevantes à aquisição e processamento do contexto detectados ao longo desta revisão, pelo
que o sistema a implementar nesta tese será um melhoramento das propostas descritas. Falta
uma solução que agregue todas as soluções particulares a cada um dos aspectos do contexto
numa só plataforma.

Esta tese irá contribuir para a criação de sistema de dependência do contexto que tenta
englobar os aspectos focados nesta revisão. Este sistema será baseado numa arquitectura
distribuída e organizada em camadas. Consegue-se assim separar os métodos de captura de
contexto dos métodos de processamento e distribuição do mesmo. A captura seria feita
usando redes de sensores que auxiliariam na captura de contexto. Será usada uma infra-
estrutura com repositório que permita guardar de forma eficiente informações de histórico dos
sensores por um determinado período de tempo. Os sensores serão tratados como

24
componentes para permitir uma mais fácil integração destes na arquitectura. O acesso à
informação de contexto por parte das aplicações poderá seguir um modelo de agentes
proposto na arquitectura CoBra, ou um modelo de infra-estrutura acedido por uma API.

Alguns dos pontos em comum apresentados nas várias propostas tais como o uso de
ontologias para representação da informação de contexto e a utilização de componentes
distribuídos estarão também presentes no sistema proposto.

25
 Capítulo 3. Análise do Sistema

A análise do sistema é uma parte importante no desenvolvimento de uma aplicação. É a

parte que requer maiores cuidados visto que é aqui que são tomadas as principais decisões do
sistema.

A análise de um sistema consiste na apresentação do cenário onde este será implementado

de onde são retirados os requisitos necessários para o seu funcionamento. A metodologia
usada para a análise do sistema e identificação dos requisitos é baseada na metodologia de
Jacobson e seus colegas [Jacobson et al 1999].

Esta metodologia, denominada processo de desenvolvimento unificado de software

(“Unified Software Development Process”), define que o desenvolvimento de uma aplicação
se divide em várias fases recursivas. A parte da análise consiste no processo de recolha de
requisitos, de onde se obtém os fundamentos básicos da aplicação a desenvolver [Jacobson et
al 1999].

Tratando-se de um sistema de aquisição e gestão de informação contextual, o processo de

análise tem de incluir também a identificação dos elementos considerados como contexto no
cenário. Para tal procede-se à análise das interacções existentes no cenário, de onde se irá
retirar em primeiro lugar as entidades presentes em cada interacção. Depois de identificar
cada entidade define-se qual a informação referente a cada uma. Esta é depois considerada
como sendo informação de contexto [Christopoulou et al 2004, Dey e Abowd 1999].

Para considerar uma informação como sendo contexto é necessário definir em primeiro
lugar o que é contexto. Esta definição tem de ser abrangente não só para todo o cenário como
também para outros possíveis cenários.

A definição usada nesta tese permite determinar de forma concisa o que é considerado
contexto e o que é informação necessária para realizar uma determinada acção. Contexto é

26
toda a informação que não seja necessária para efectuar uma acção mas que no caso de existir
melhora os resultados dessa acção.

Este capítulo inicia-se com a descrição e estudo do cenário proposto. Segue-se a

identificação das interacções existentes no cenário. A análise do sistema continua com a
descrição dos diagramas de casos de utilização (“use cases”) criados a partir do cenário. Esta
descrição é complementada com o diagrama de casos de utilização do sistema, inerente ao
cenário. O capítulo termina com a apresentação dos requisitos recolhidos dos diagramas de
casos de utilização.

3.1 Cenário proposto

O cenário escolhido para demonstração do sistema foi o cenário proposto no projecto
CASCOM no âmbito do qual se insere a presente tese [Möller et al 2004]. No cenário
apresentado os números entre parêntesis indicam interacções às quais se fará referência na
secção 2.01 do Anexo II.

O principal motivo da análise do cenário proposto é a identificação das interacções

relevantes que posteriormente servirão para identificar a informação contextual relevante.
Uma determinada informação é considerada como contexto se estiver de acordo com a
seguinte definição:

Contexto é a informação recolhida do sistema de contexto de cada uma das entidades

presentes e que seja relevante para uma determinada interacção, em conjunto com a
informação relevante do sistema de contexto das entidades que não participem na
interacção mas que estejam mencionadas nas mensagens trocadas nela. Todas estas
informações de contexto não são essenciais para o funcionamento da aplicação sendo
elementos adicionais à interacção, mas contribuem para um melhor desempenho desta.

De seguida encontra-se a descrição do cenário proposto na tese:

Bob, um homem de negócios da Finlândia está a assistir a uma apresentação na Áustria.

Nessa noite no hotel, Bob começa a sentir dores de estômago e como é a primeira vez que se
encontra na Áustria não sabe o que fazer. Felizmente traz consigo o seu PDA com uma
aplicação de emergência médica baseada no contexto. Após esta aplicação ser activada, o
sistema encontra imediatamente um centro hospitalar próximo de si (1). Para além disso a
aplicação disponibiliza também informação de contacto do representante finlandês do
sistema de emergência médica (SEM) (2). Devido às suas dificuldades em falar alemão, ele

27
decide pedir auxílio ao sistema de emergência médica finlandês (3). Este obtém informação
dos sintomas de Bob e procura um sistema de diagnóstico médico. Este sistema é contactado
para determinar as causas possíveis dos sintomas de Bob (4). O Sistema de emergência
médica procura então qual o centro médico mais próximo de Bob que seja capaz de lidar com
os seus sintomas. Este aconselha-o a dirigir-se ao hospital mais próximo. O sistema pode
aconselhar também uma outra clínica especializada no tratamento de doenças com esses
sintomas que esteja próxima do utilizador, baseando a procura não só na localização de Bob
como também nos sintomas (5). Com essa informação, Bob usa a aplicação no seu PDA para
calcular o percurso entre a sua localização e o centro de saúde indicado. Esta informação
pode-lhe ser disponibilizada num mapa, número de telefone de uma central de táxis ou uma
ligação via transportes públicos (6). Se o centro de saúde possuir a tecnologia necessária
será informado da chegada do utilizador para que se possam fazer alguns preparativos (7).

Depois de chegar ao centro de saúde, Bob liga o seu PDA à rede local do centro, transfere
os seus dados gerais para o sistema de informação do centro de saúde (8). Ao ser atendido
pelo médico, este verifica que necessita de recolher mais informações sobre o paciente. Essas
informações poderão ser resultados de análises ou outros diagnósticos. Bob usa novamente o
seu PDA para recolher essas informações do seu relatório médico. Este relatório pode ser
constituído por informação proveniente de várias fontes (9). Após aprovação do utilizador, os
dados são transmitidos para o seu PDA. Caso o formato dos dados do sistema do centro
médico seja diferente, será necessário efectuar uma conversão (10). Depois de convertida, a
informação é transmitida para o computador do médico. Com esta nova informação o médico
será capaz de tratar Bob de forma conveniente.

Descrito o cenário procede-se à identificação dos intervenientes e das interacções. Este

processo é um passo importante para a determinação dos intervenientes e da informação
trocada entre estes. O cenário apresenta várias interacções onde a informação de contexto é
relevante. Na secção 2.01 do Anexo II encontra-se uma descrição pormenorizada de cada uma
das interacções identificadas.

3.2 Descrição dos elementos constituintes da aplicação

Nas interacções do cenário participam serviços da aplicação tais como a descoberta,
comparação, composição e execução de serviços. A cada um destes serviços estão associados
vários elementos que são considerados como contexto. Uma breve descrição de cada um dos
serviços assim como dos elementos associados a eles será apresentada de seguida:

28
 - O serviço de descoberta de serviços tem como função descobrir os serviços requisitados
pelo utilizador. O serviço de comparação de serviços compara as descrições dos vários
serviços, sendo um componente essencial para o funcionamento da descoberta de serviços.
Para ambos os serviços podem ser considerados como elementos de informação de contexto
as restrições impostas por alguns serviços, a limitação do número de serviços devolvidos e a
indicação da topologia da rede.

- O componente de composição de serviços junta vários serviços num só de maneira a criar

um novo serviço composto. Para este serviço podem ser considerados como elementos de
informação de contexto as restrições impostas pelos serviços, a capacidade de processamento
do componente de composição de serviços e os custos associados à execução do serviço
composto.

- O componente de execução de serviços executa as descrições de serviços fornecidas. Para

este serviço podem ser considerados como elementos de informação de contexto a capacidade
de processamento do executor e o tamanho das listas de espera de pedidos recebidos pelo
componente de execução de serviços.

3.3 Diagrama de Casos de Utilização

A representação conceptual das funcionalidades da aplicação de emergência médica
descrita no cenário da tese encontra-se apresentada na Figura 7 sob a forma de um diagrama
de casos de utilização (“use cases”).

Figura 7 – Diagrama de casos de utilização da aplicação de emergência médica

29
 O diagrama da Figura 7 representa os actores que participam na aplicação e as suas
principais características. O GCMAS encontra-se representado no caso de utilização 6.

Este é descrito pormenorizadamente na Figura 8. O sistema é responsável pela aquisição,

monitorização representação e armazenamento de informação de contexto. Está dividido em
duas camadas, uma camada de infra-estrutura e uma camada de aplicação. A camada de infra-
estrutura possui mecanismos genéricos que permitem às aplicações fornecer informações de
contexto, pesquisar por contexto e subscrever eventos. A camada de aplicação é adaptada ao
tipo de aplicação que acede ao sistema e possui mecanismos de modelação, agregação e
raciocínio de contexto.

Figura 8 – Diagrama de use cases do GCMAS

Na camada de infra-estrutura, a pesquisa de contexto consiste na interpretação das

perguntas feitas pela aplicação e fornecimento da informação de contexto requerida.

O fornecimento de contexto consiste na recepção e armazenamento de informação de

contexto fornecida por aplicações. Estas informações podem ser consideradas como contexto
estático. Este tipo de contexto não muda ou muda com muito pouca frequência e normalmente
está associado à informação dos utilizadores tal como nome e data de nascimento. Contexto
mais dinâmico também pode ser fornecido ao sistema, no entanto a sua disponibilização
estará dependente da velocidade de processamento deste.

30
 A subscrição de eventos consiste na criação de alertas que avisam a aplicação quando o
contexto é alterado.

Na camada de aplicação realiza-se a modelação da informação de contexto de acordo com

uma determinada ontologia e com processos de inferência.

Uma descrição mais detalhada de cada um dos casos de utilização e actores representados
nos diagramas da Figura 7 e Figura 8 podem ser consultados na secção 2.02 do Anexo II.

3.4 Requisitos do Sistema

Os requisitos obtidos pela análise do diagrama de casos de utilização são apresentados
numa tabela, numerados de acordo com a sua importância e classificados em dois tipos:
funcionais e não funcionais. Os requisitos funcionais são requisitos essenciais para o
funcionamento da aplicação, sendo desta forma apresentados em primeiro lugar.

Os requisitos não funcionais são requisitos acessórios que no caso de não serem cumpridos
não comprometem o funcionamento da aplicação. Estes requisitos estão normalmente
associados à interface gráfica e às funcionalidades opcionais do sistema. A Tabela 1 apresenta
os requisitos do sistema desenvolvido. Uma descrição mais pormenorizada destes requisitos
pode ser encontrada na secção 2.03 do Anexo II.

Tabela 1 – Requisitos do sistema desenvolvido

Requisito #: Descrição Tipo

Separação do conceito de captura de contexto e semântica
SC01 Funcional
da aplicação
SC02 Captura do contexto independente do sensor Funcional
SC03 Compatibilidade entre aplicações e sensores Funcional
SC04 Captura do contexto Funcional
SC05 Transparência nas comunicações Funcional
SC06 Diversidade de interfaces Funcional
SC07 Armazenamento do histórico do contexto Funcional
SC08 Contexto estático armazenado em repositório Funcional
SC09 Mecanismos de descoberta de fontes de contexto Funcional
SC10 Propriedades da informação dos sensores Funcional
Registo de novos sensores quando a aplicação está a
SC11 Funcional
correr
Registo de novos sensores quando a aplicação está a
SC12 Funcional
correr
SC13 Sistema alerta alterações no contexto Funcional
SC14 Disponibilidade constante Não Func.
SC15 Sistema deve ser genérico e adaptável a várias aplicações Não Func.

31
 Capítulo 4. Ontologia do Contexto

A definição do método usado para representar o modelo de contexto e a identificação da

informação de contexto para cada um dos elementos identificados no Capítulo 3 é um passo
importante na modelação de um sistema ciente do contexto. O método usado baseia-se na
metodologia proposta por Dey e seus colaboradores [Dey et al 2001]. Esta metodologia define
que a informação de contexto no sistema é representada por uma ontologia onde são definidos
os elementos de informação de contexto disponibilizados pelo sistema.

A metodologia define também entidades de contexto. Estas representam aplicações,

pessoas, locais ou objectos sobre os quais se obtém informação de contexto [Dey et al 2001].
Cada entidade de contexto vai estar associada a elementos de informação de contexto que
determinam características da entidade tais como localização e temperatura.

Sensores ou estruturas de dados do repositório representam os elementos de informação de

contexto. A informação dada por esses sensores ou armazenada no repositório representa a
informação de contexto.

A organização das entidades de contexto e dos respectivos elementos de informação de

contexto é representada numa ontologia, a ontologia do contexto. A representação desta
estrutura em ontologias permite tirar proveito da flexibilidade e representatividade das
linguagens de representação de ontologias.

Tratando-se de um sistema genérico, a informação de contexto usada irá variar de cenário

para cenário. Para garantir a compatibilidade entre as ontologias usadas nos diversos cenários,
definiu-se que estas terão de respeitar uma ontologia base.

A ontologia base parte do princípio que a declaração do contexto num cenário é feita por
entidades de contexto e por elementos de informação de contexto. A ontologia base de
contexto é única, servido como estrutura para a representação do contexto de um cenário.

32
 A distribuição do contexto de um cenário é feita através da ontologia de distribuição de
contexto. Esta é construída segundo as regras da ontologia base e determina como o contexto
se encontra distribuído pelas entidades de contexto e pelos elementos de informação de
contexto.

Uma terceira ontologia é usada para especificar o tipo de dados que caracteriza a
informação de contexto. Esta terceira ontologia é definida numa linguagem mais próxima das
linguagens orientadas por objectos e serve de ponte entre a estrutura ontológica do contexto e
a representação orientada por objectos das aplicações.

A representação do contexto no sistema é então determinada por três ontologias: a

ontologia base de contexto, a ontologia de distribuição de contexto e a ontologia de dados do
contexto. Destas três ontologias apenas uma se mantém inalterável para todas as situações, a
ontologia base. As restantes duas são definidas de acordo com o cenário onde o sistema será
usado.

Este capítulo inicia-se com a apresentação de uma análise da solução de modelo de

contexto a ser usada no sistema. O capítulo termina com a descrição das ontologias usadas
para representar o contexto. Detalhes pormenorizados dessas ontologias podem ser
observados no Anexo III.

4.1 Solução para representar o modelo de contexto

Um dos aspectos mais importantes do desenvolvimento de um sistema de contexto é a
identificação da informação que ele mantém. Para identificar essa informação de uma forma
simples determina-se em primeiro lugar uma definição conveniente de contexto. Essa
definição tem de ser genérica visto que o contexto depende do cenário em que o sistema será
usado. Deve também abranger todas as aplicações que utilizem um sistema de contexto [Dey
et al 2001]. A definição de contexto aplicada no desenvolvimento desta tese encontra-se
descrita de seguida:

Contexto é a informação recolhida do sistema de contexto de cada uma das entidades

presentes e que seja relevante para uma determinada interacção, em conjunto com a
informação relevante do sistema de contexto das entidades que não participem na
interacção mas que estejam mencionadas nas mensagens trocadas nela. Todas estas
informações de contexto não são essenciais para o funcionamento da aplicação sendo
elementos adicionais à interacção, mas contribuem para um melhor desempenho desta.

33
 Segundo a metodologia proposta por Dey e seus colaboradores [Dey et al 2001], o passo a
tomar após obtenção de uma definição abrangente de contexto é a identificação dos elementos
presentes no cenário de aplicação do sistema. Isto permite determinar as entidades e os
elementos de informação de contexto.

O modelo de contexto é construído com base nestas informações. Este é uma representação
da estrutura da informação de contexto usada no sistema. Aplicações que queiram consultar o
sistema usam este modelo como referência para identificar a informação que queiram
pesquisar.

O uso de uma estrutura onde aplicações e sensores reconhecem qual a informação que
procuram ou qual a informação que fornecem, torna um sistema de contexto extensível a
qualquer situação, desde que esta possa ser descrita nessa estrutura. Das soluções
apresentadas por vários autores (ver Capítulo 2), o uso de ontologias revelou-se aquela que
permite uma maior integração com aplicações externas. O uso de ontologias permite uma base
única reconhecida tanto por aplicações como sensores [Christopoulou et al 2004].

Para o sistema desenvolvido nesta tese, o GCMAS (“Generic Context Managment and
Aquisition System”), esta é a solução ideal, pois o seu funcionamento baseia-se na troca de
informação entre aplicações e sensores. A linguagem usada para definir a ontologia do
sistema é o OWL (“Web Ontology Language”) [W3C 2004], a qual foi aprovada pelo W3C1.

Esta é a linguagem padrão usada na definição de ontologias, reconhecida por um grande

número de aplicações e compatível com a maioria dos standards. Para além do facto de ser
uma linguagem padrão, está numa fase de maturidade estável, não sendo previstas grandes
alterações nas novas versões que sejam lançadas.

A última versão do OWL divide-o em três sub linguagens. A versão mais simples (“OWL
Lite”) permite o acesso às funcionalidades primárias da linguagem. Com esta versão é
possível criar hierarquias de classes e restrições simples. A versão de descrição lógica (“OWL
DL”) permite o uso total da expressividade do RDF [W3C 2004a], uma outra linguagem de
representação de ontologias, garantindo que a inferência na ontologia termina num tempo
razoável. Para que tal aconteça são impostas algumas restrições no uso de certas capacidades
da linguagem

1
www.w3.org

34
 A versão mais completa (“OWL full”) permite o uso de todas as capacidades da linguagem.
A expressividade desta linguagem pode tornar o processo de inferência na ontologia muito
complexo não sendo garantida a sua terminação em tempo razoável.

Uma ontologia OWL válida criada com a versão mais simples é também válida do ponto
de vista das outras versões mais complexas. Uma ontologia OWL válida criada com a versão
de descrição lógica é também válida para a versão mais completa do OWL.

De maneira a garantir a compatibilidade das ontologias criadas para o sistema, este assume
que todas estão descritas na versão mais completa do OWL. Ao se assumir o uso de uma
versão mais simples do OWL as descrições da ontologia do sistema ficariam limitadas às
descrições compatíveis com estas versões. Descrições que requeressem parâmetros mais
avançados do OWL não poderiam ser usadas no sistema.

Visto que a ferramenta usada para a integração das ontologias também usa a versão mais
completa do OWL a utilização desta versão torna-se óbvia. Apesar de tornar o processo de
inferência mais complexo as relações discriminadas na ontologia do contexto são simples não
implicando grandes esforços de inferência.

4.2 Descrição da ontologia de contexto

A ontologia de contexto foi definida para permitir a introdução de novos elementos sem
necessidade de alterar o código do sistema desenvolvido. Informações adicionais sobre
elementos do cenário ou até mesmo novos elementos podem ser adicionados a posteriori sem
necessidade de recompilar o sistema.

Para tal, esta não pode estar descrita directamente no código da aplicação (“Hard Coded”).
A ontologia tem de ser carregada de um repositório exterior (e.g., um ficheiro) que permitia a
sua fácil alteração. A sua estrutura tem de ser extensível de maneira a permitir a adição de
nova informação sem necessidade de grandes alterações. A nova ontologia deve também ser
compatível com aplicações que usem a antiga ontologia.

Ao se introduzir nova informação de contexto na ontologia tem de ser garantida a

compatibilidade com a estrutura existente. Isto permite a utilização dos mesmos mecanismos
de processamento da informação de contexto (e.g., procura de informação de contexto).

Consequentemente, a ontologia de contexto tem de possuir uma base comum para toda a
informação de contexto. Esta base é expressa como uma ontologia e serve para classificar as
informações de contexto.

35
 Esta classificação é feita com base no método proposto por Dey e seus colaboradores [Dey
et al 2001]. Segundo estes autores, para facilitar a sua identificação, o contexto deve ser
dividido em classes. Esta divisão deve realizar-se ao nível dos fornecedores de contexto (e.g.,
sensores ou aplicações) sendo a classificação orientada pelo tipo de informação que estes
fornecem e pela entidade a que estes se referem.

Esta metodologia classifica o contexto por entidades e categorias. Entende-se por entidade
a pessoa, local, máquina, aplicação ou serviço à qual as informações de contexto dizem
respeito. Uma categoria é o tipo de informação de contexto que é adquirida de uma dada
entidade (e.g., a entidade pessoa tem como categorias de contexto a sua informação pessoal e
a sua localização).

Dey e seus colaboradores definem três tipos de entidades: locais, pessoas e objectos. Cada
entidade é dividida em quatro categorias: identidade, localização, estado e tempo. A
identidade identifica o elemento de uma forma única possibilitando a sua distinção de outros
elementos.

Localização é toda a informação de contexto que determina a posição e orientação do

elemento num determinado local. Estado é toda a informação sobre as características de um
elemento ou as acções em que este elemento participa.

Tempo é a toda a informação que ajude a caracterizar uma determinada situação.

Normalmente o tempo é usado em conjunto com outras informações de contexto e serve como
marcador para informações de histórico. Na Figura 9 encontra-se a representação desta
classificação.

Esta ontologia, por estar ligada aos fornecedores de contexto, é considerada uma ontologia
de baixo nível. Aplicações que queiram obter informações de mais alto nível terão de possuir
ontologias baseadas na ontologia de contexto que representem essa informação.

Como exemplo da diferenciação entre a ontologia de contexto e uma ontologia de mais alto
nível, específica de uma aplicação, tem-se a localização. Esta, na ontologia do GCMAS, pode
ser constituída por simples coordenadas, indicação de presença ou outra qualquer informação
retirada de um fornecedor de contexto.

Para a aplicação que requer esta informação, a localização pode indicar algo mais
complexo como uma morada. Esta morada será uma conversão do valor retirado do GCMAS
feita com auxílio de uma ontologia de alto nível.

36
 A ontologia de contexto representa assim a informação disponibilizada pelos fornecedores
de contexto. Esta informação está estruturada de acordo com uma base que segue o modelo
proposto por Dey e seus colaboradores. Esta base é também representada por uma ontologia,
denominada ontologia base de contexto.

Figura 9 – Classificação do contexto

Para além da ontologia base de contexto, outras duas ontologias compõem a ontologia de
contexto, a ontologia de distribuição do contexto e a ontologia de dados do contexto.

Cada uma destas ontologias será explicada em pormenor de seguida.

4.2.1 Ontologia base de contexto

A ontologia base de contexto é a ontologia que serve de base à ontologia de distribuição e
cujas alterações afectam o funcionamento do sistema. Por esse motivo a ontologia é genérica
o suficiente para poder suportar todo o tipo de cenários de contexto sem necessidade de
alteração.

A ontologia base define a forma como o contexto e entidades são classificados. É nesta
ontologia que se define o que são entidades e a que classes pertencem as informações de
contexto. Para identificar a informação de contexto e separá-la das entidades, a ontologia
define também o elemento de contexto.

37
 Um elemento de contexto representa a informação de contexto que caracteriza uma
entidade. Este pode ser uma informação obtida por sensores, informação sensorial, ou
armazenada no sistema, informação de repositório.

A informação disponibilizada pelo elemento de contexto é representada por uma classe

orientada por objectos. Esta classe está especificada na ontologia de dados do contexto.

Como se pode verificar na Figura 10, a ontologia base de contexto está dividida três grupos
de representação da informação. A entidade e o elemento de contexto definem a organização
do contexto, indicando como estão distribuídas as entidades e quais são os elementos de
informação de contexto que caracterizam cada uma delas. A classe valor está associada à
ontologia de dados de contexto, sendo a ligação entre a ontologia de dados e a ontologia de
distribuição.

Figura 10 – Ontologia base de contexto

A ligação entre classes da ontologia é feita através de propriedades. A ontologia de

distribuição de contexto, que representa a distribuição das entidades e elementos encontrados
no cenário, tem de estender estas propriedades.

Cada entidade tem de possuir uma identificação e um conjunto de elementos de contexto

que a definam. Estes elementos representam a informação de contexto que se pode obter
sobre essa entidade (e.g. a entidade pessoa tem como elementos de contexto os seus dados
pessoais e a sua localização). Cada elemento de contexto pode representar uma informação
sensorial ou uma informação de repositório. Tratando-se de contexto obtido por sensores, o

38
elemento deve estender a classe “informação sensorial”. Tratando-se de uma informação
fornecida por uma aplicação e armazenada no repositório do sistema, a propriedade deve
estender a classe “informação de repositório”.

Cada elemento de contexto possui três propriedades. Estas representam a ligação da

ontologia de distribuição à ontologia de dados. Estas propriedades representam a classe, o
esquema e o valor do elemento.

A informação de classe permite às aplicações saber qual a classe do objecto que representa
o valor devolvido pelo GCMAS para um determinado elemento de contexto. Esta informação
trata-se apenas de uma informação textual sobre o caminho da classe (e.g., o elemento de
contexto localização tem como classe “gcf.ontology.Location”).

A informação de esquema indica o caminho para o ficheiro onde se encontra o esquema da

estrutura da classe que representa o objecto devolvido pelo GCMAS. Este esquema é útil para
aplicações que não conheçam a classe devolvida pelo objecto. O esquema da classe é descrito
em XML Schema [W3C 2004b], uma linguagem que permite a conversão do esquema num
objecto usando as ferramentas apropriadas.

O valor representa a forma serializada da informação devolvida pelo GCMAS para um

dado elemento de contexto (e.g. após uma aplicação fazer o pedido de armazenamento de
dados pessoais de um utilizador, essa informação fica acessível no repositório através da
propriedade valor). Usa-se a representação serializada para guardar o valor da informação de
contexto na ontologia, uniformizando a sua representação. Isto implica que, na ontologia de
dados do contexto, onde são definidas as classes que representam cada um dos objectos
devolvidos pelo GCMAS, sejam também definidos os métodos de serialização desses objectos.

Para distinguir as várias instâncias, cada entidade está associada a um identificador. Esta
propriedade é obrigatória e tem de possuir valores diferentes para cada instância.

Cada entidade pode estar associada a outras entidades. Para tal basta estender a
propriedade “ligadoA” (“linkedTo”), que liga duas entidades entre si.

A ligação de entidades permite a inferência na ontologia, sendo assim possível associar

contexto de outras entidades a uma determinada entidade (e.g. a localização é um elemento de
contexto da entidade dispositivo que por sua vez está ligada à entidade utilizador. Usando a
inferência na ontologia é possível determinar a localização do utilizador como se este
elemento de contexto estivesse associado a esta entidade).

39
4.2.2 Ontologia de distribuição
A ontologia de distribuição define a distribuição das entidades e dos elementos de contexto
num determinado cenário. Esta ontologia deve estender a ontologia base de contexto para ser
compatível com o sistema.

A ontologia de distribuição é dependente do cenário, sendo construída a partir das

informações retiradas deste. O GCMAS trabalha sobre esta ontologia para fazer as pesquisas
de contexto. A informação de contexto obtida pelos sensores ou guardada no repositório é
organizada de acordo com as definições da ontologia de dados.

Um exemplo prático desta ontologia pode ser aplicado a um cenário simples onde apenas
existe um utilizador e a sua localização. A ontologia base de contexto define o que é uma
entidade, o utilizador, e o que é um elemento de contexto, a localização. Esta definição
permite ao sistema distinguir entidades de elementos de contexto.

A ontologia de distribuição indica ao sistema quais as entidades e elementos de contexto

presentes no cenário em que o sistema é implementado. Neste caso teríamos como entidades
os utilizadores registados na aplicação e como elementos de contexto as suas localizações.
Estes seriam os dados contidos na ontologia de distribuição usada neste exemplo.

Com estas duas ontologias é possível determinar de forma perceptível ao GCMAS como
estão distribuídas as entidades e elementos de contexto determinados. Neste caso apenas
existe uma relação entre a entidade utilizador e o elemento localização.

Para determinar o tipo de dados devolvido pelo elemento de contexto da localização

define-se uma outra ontologia, a ontologia de dados do contexto. Considerando que a
localização do utilizador é dada sob a forma de coordenadas em latitude e longitude, a
ontologia de dados define um objecto que representa essa informação no sistema. Neste caso,
o elemento de contexto localização é caracterizado por um objecto do tipo
“LocationDegrees” que possui dois atributos fraccionários (“double”), lat que representa a
latitude e long que representa a longitude.

4.2.3 Ontologia de dados

O uso de uma ontologia de dados separada da ontologia de distribuição de contexto
deve-se às diferenças entre a representação orientada para objectos e a representação de
ontologias. A representação de atributos de classe é mais complexa usando linguagens de
ontologia, assim como a definição do tipo de dados dos atributos de classe.

40
 Nas linguagens de ontologia, as classes possuem propriedades que as distinguem. Cada
uma dessas propriedades aponta para uma outra classe que define o domínio dessa
propriedade. A linguagem de ontologias OWL possui um mecanismo que permite agrupar
diversas propriedades de uma classe de forma semelhante aos atributos de classe nas
linguagens orientadas para objectos. No entanto, mesmo usando esta particularidade do OWL
não é possível um mapeamento directo desta estrutura de propriedades para uma classe com
atributos.

Para simplificar o mapeamento das classes de ontologia para classes orientadas por
objectos foi criada a ontologia de dados. Esta exprime a informação devolvida pelo sistema
que corresponde a um determinado elemento de contexto descrito na ontologia de distribuição.
As descrições são feitas em XML Schema, uma linguagem que permite uma transposição
directa para classes de linguagens de programação orientadas por objectos.

Para a ligar a ontologia de distribuição do contexto à ontologia de dados, cada elemento

definido na ontologia de distribuição tem obrigatoriamente associado a si duas propriedades.
Estas propriedades indicam respectivamente o caminho da classe orientada por objectos que
representa a informação devolvida pelo sistema respeitante a este elemento “temClasse”, e o
caminho para o esquema da classe “temEsquema”.

Como exemplo prático da aplicação dessas propriedades temos a localização de um

utilizador por latitude e longitude. A localização é definida com uma classe na ontologia
determinando-a como um elemento de contexto. Este elemento de contexto de acordo com a
ontologia base de contexto possui três propriedades, “temValor” (“hasValue”), “temClasse”
(“hasClass”) e “temEsquema” (“hasSchema”).

A primeira propriedade é usada para armazenar o valor da amostra actual do contexto. A

propriedade “temClasse” representa a classe Java correspondente à localização. Sendo a
localização representada pela classe gcf.ontology.LocationDegrees o valor da propriedade
“temClasse” seria gcf.ontology.LocationDegrees.

A representação do objecto LocationDegrees é feita em XMLSchema e armazenada num

ficheiro. O caminho para esse ficheiro seria o valor guardado na propriedade “temEsquema”.
Supondo que o ficheiro estaria guardado num repositório Web o valor da propriedade
“temEsquema” seria ‘http://<servidor>/<caminho>/ontology.xspo’. O ficheiro ontology.xspo
pode conter definições de outros objectos da ontologia.

41
 A ontologia de dados em conjunto com a ontologia de distribuição possibilita a descrição
do contexto de um dado cenário. A ontologia base permite que múltiplos cenários possam ser
usados sem que seja necessário incorrer a alterações no sistema.

Estas ontologias representam a solução para manter o GCMAS genérico e facilmente

adaptável a várias situações. Detalhes sobre a ontologia usada podem ser observados no
Anexo III.

42
 Capítulo 5. Descrição do Sistema

A descrição do GCMAS foca-se na fase de desenho e implementação do sistema. É nesta

fase que se tomam as decisões fundamentais de desenho. Durante a fase de projecto ou de
desenho do sistema projecta-se a forma como os requisitos são cumpridos e encontram-se
soluções para os problemas mais gerais que ajudarão no desenvolvimento do sistema.

Apenas na fase de implementação são encontrados os problemas mais específicos e mais

difíceis de resolver. Muitos estão relacionados com limitações das linguagens ou ferramentas
usadas no desenvolvimento assim como com a integração de ferramentas externas. Isto
implica a necessidade de retomar o ciclo de desenho para proceder a ajustes.

O GCMAS ("Generic Context Managment and Acquisition System") funciona como um

sistema baseado em componentes com funcionalidades específicas. Estas funcionalidades são
a captura de informação de contexto de sensores, armazenamento de informação de contexto
fornecido por aplicações, subscrição de eventos de contexto e gestão de informação de
histórico. Todos estes componentes, com excepção do de subscrição de eventos, foram
implementados para a demonstração desta tese.

O GCMAS disponibiliza também um módulo de desenvolvimento para aplicações. Este

consegue comunicar directamente com os componentes do sistema, procedendo à agregação
de contexto e raciocínio sobre este.

A implementação deste módulo está dependente da aplicação. Isto permite ao sistema

exibir funcionalidades de interpretação de contexto sem que isso afecte a sua independência
no domínio. O módulo de desenvolvimento para aplicações não foi implementado durante a
realização desta tese.

O sistema apresenta as suas funcionalidades a aplicações externas por meio de interfaces.

Interfaces especializadas permitem que diferentes tipos de aplicação possam comunicar com o

43
sistema. Serviços Web, aplicações orientadas por objectos e agentes são exemplos de tipos de
interfaces especializadas que se podem desenvolver. Destas foram implementadas para a
demonstração da tese as interfaces orientadas por objectos (interface JINI e XSP) descritas na
secção 5.1.1.

Devido à grande complexidade do sistema desenvolvido apenas algumas das suas

funcionalidades foram implementadas. Estas funcionalidades incluem a inserção de sensores
no sistema, a pesquisa de contexto, o armazenamento de informação e operações sobre
histórico de contexto.

Neste capítulo são apresentados os resultados dos vários ciclos de implementação e

desenho que ocorreram antes de se concluir o desenvolvimento da aplicação. Este inicia-se
com uma visão geral da arquitectura, onde são apresentados os aspectos fundamentais e são
identificados os componentes do GCMAS.

O capítulo continua com as considerações de desenho seguidas da abordagem das várias

fases de desenvolvimento do sistema. Na secção do desenvolvimento do sistema (5.3) são
apresentadas as decisões tomadas para implementar as funcionalidades do sistema e
descrevem-se as interfaces desenvolvidas em cada fase. São também descritas as soluções
encontradas para futura implementação das restantes funcionalidades do sistema. O capítulo
termina com a descrição de alguns dos problemas encontrados durante o desenvolvimento.

5.1 Arquitectura do GCMAS

É na fase de desenho da aplicação que se decide a arquitectura de um sistema. Depois de
analisados os requisitos apresentados no Capítulo 3, procede-se à análise do desenho e
definição da arquitectura. A definição da arquitectura é um passo importante pois trata da
estrutura do sistema desenvolvido.

Vários tipos de arquitectura podem adaptar-se ao GCMAS. Entre elas as mais relevantes
são as arquitecturas de agentes e as arquitecturas baseadas em componentes. Estas são usadas
em várias propostas de sistemas de contexto, tal como se pode verificar no Capítulo 2.
Exemplos destas propostas são a arquitectura CoBrA de Chen e seus colaboradores [Chen et
al 2003], baseada em agentes, e a arquitectura WASP de Costa e seus colaboradores [Costa et
al 2003], baseada em componentes.

Devido à simplicidade das arquitecturas baseadas em componentes, o sistema foi

desenvolvido com uma arquitectura deste tipo. Consegue-se com esta perspectiva uma maior

44
flexibilidade da estrutura pois novas funcionalidades podem ser adicionadas com novos
componentes.

O GCMAS é apresentado às aplicações como um sistema fechado (“black box”) com

várias interfaces. A Figura 11 representa uma visão geral da arquitectura do GCMAS. Nesta
figura são apresentadas, em tonalidades diferentes, as várias funcionalidades do sistema. As
funcionalidades implementadas durante o desenvolvimento da tese estão identificadas com
um tom claro. As funcionalidades identificadas com tom mais escuro não foram
implementadas. Apesar de não implementadas estas também são importantes para o sistema.

Figura 11 – Visão geral da arquitectura do GCMAS

Tal como se pode verificar na Figura 11, as aplicações acedem ao GCMAS através das
suas interfaces. Um processo semelhante verifica-se do lado dos sensores.

Da arquitectura apresentada retira-se que o GCMAS é composto por duas partes. A parte
genérica integra a maioria das funcionalidades tais como as ferramentas para adaptadores de
sensor, interfaces, serviço de páginas amarelas e os componentes do núcleo do sistema. A
parte específica de aplicação, também denominada de módulo de interpretação, consiste do
interpretador de contexto.

45
 Na camada genérica do GCMAS, as ferramentas de adaptadores de contexto fornecem
métodos base para criação de componentes de adaptação de sensor. Estes métodos permitem a
adaptação da informação retirada dos sensores para um nível determinado pela ontologia do
sistema (ver Capítulo 4) e a inclusão de capacidades de pesquisa no sistema.

Os adaptadores de sensor são implementados de acordo com o tipo de sensor. Estes têm de
respeitar a interface de adaptação de sensores fornecida pelo GCMAS para que a sua
integração no sistema seja possível.

O serviço de páginas amarelas presente na camada genérica do sistema permite o registo e

localização de todos os componentes do sistema. Este serviço, em conjunto com as
ferramentas de adaptação de sensor, implementam a funcionalidade de pesquisa de contexto.

A camada genérica abrange também as funcionalidades nucleares do sistema. Estas

correspondem aos controladores de repositório, de eventos, o núcleo do sistema e
implementação das interfaces específicas para cada tipo de aplicação.

Esta camada funciona de acordo com a ontologia base de contexto. Tal como indicado no
Capítulo 4, esta define a estrutura da ontologia de distribuição do contexto. O conhecimento
da ontologia por parte das aplicações que lhe acedem é necessário para que estas possam
compreender as informações que estão a trocar com o sistema.

A camada específica de aplicação é considerada como um módulo pois não influencia o

funcionamento do sistema. Esta permite a introdução de funcionalidades mais específicas para
aplicações, que aumentam o nível de abstracção do contexto fornecido pelo sistema. O
interpretador de contexto possui as ferramentas necessárias para que aplicações possam obter
a informação de contexto a um nível de abstracção adequado, nível esse que é superior ao da
informação fornecida directamente pelos sensores.

O GCMAS permite que várias instâncias dos seus componentes possam ser lançadas
simultaneamente. Isto introduz maior eficiência pois os pedidos das aplicações são escoados
para as várias instâncias dos componentes responsáveis por tratarem deles. A multiplicidade
de instâncias do mesmo componente permite que as funcionalidades que estes implementam
possam correr em locais diferentes. Isto diminui a probabilidade de falha do sistema.

As interfaces desenvolvidas no GCMAS para aplicações externas permitem o acesso a

agentes e aplicações orientadas por objectos. No domínio das aplicações orientadas por

46
objectos dois tipos de acesso são disponibilizados. Nestes acessos são usados protocolos de
modelos de componentes, JINI [JINI 2005] e XSP 1 (“eXtended Service Platform”). Estes
modelos permitem que o sistema seja entendido como um componente por parte das
aplicações. A aplicação ao aceder às funcionalidades desse componente estará
automaticamente a aceder ao sistema.

O acesso JINI permite que aplicações que usem o modelo de componentes do JINI acedam
ao sistema como se este se tratasse de um componente JINI. O acesso XSP permite que
aplicações XSP acedam ao GCMAS como se este se tratasse de um componente XSP.

Outras interfaces podem vir a ser definidas no futuro permitindo assim a expansão do
sistema para outros tipos de aplicações. A introdução de interfaces no sistema é realizada da
mesma forma que na adição de novos componentes.

5.1.1 Interfaces externas do GCMAS

Apesar de ser um sistema distribuído, o GCMAS é apresentado às aplicações externas
como uma caixa fechada com diversas interfaces. Cada uma destas interfaces é um meio de
acesso às funcionalidades do sistema. Este disponibiliza interfaces para subscrição de eventos
de contexto, pesquisas de contexto, envio de informação de contexto e acréscimo de novas
classes de informação de contexto. Cada uma destas interfaces é implementada por
componentes internos do sistema. Do lado dos sensores o sistema de contexto possui
interfaces para a comunicação com os adaptadores de sensor.

A interface de pesquisa de eventos permite que aplicações subscrevam a determinados

eventos de contexto. Estes eventos são lançados quando se verificam alterações ao contexto.
Aplicações que requererem os eventos têm de possuir também interfaces específicas para
receber e lidar com os eventos.

A interface de pesquisa de contexto permite às aplicações a pesquisa de informações de

contexto. Esta pesquisa pode ser feita apenas à informação actual ou a um conjunto de
amostras de contexto captadas e mantidas ao longo do tempo.

A interface do repositório permite às aplicações o envio de informações de contexto. A

maioria destas informações é estática, não se alterando muito ao longo do tempo. No entanto

1
Desenvolvido por We, the body and the mind research group (http://www.we-b-mind.org/) e Accedo
Consulting (http://www.accedo.pt)

47
as aplicações estão livres de enviar o tipo de informação que quiserem desde que esteja
especificada na ontologia como uma informação de repositório.

O sistema possui ainda interfaces do lado dos sensores. Estas são realizadas pelos
componentes de adaptação de sensor. Os componentes de adaptação possuem ferramentas que
possibilitam a ligação dos sensores ao sistema, funcionando de certa maneira como interfaces.

Interfaces mais específicas podem ser definidas no módulo de aplicação. Estas são
construídas especificamente para uma aplicação e servem para a comunicação desta com o
componente responsável pela interpretação de contexto.

Para garantir que vários tipos de aplicação podem usufruir do GCMAS, cada uma das
interfaces foi definida para vários tipos de aplicação. A subscrição de eventos, a pesquisa de
contexto e o repositório possuem várias interfaces que permitem a comunicação com vários
tipos de aplicação.

Três tipos de aplicação são abrangidos pelo GCMAS. Aplicações orientadas por objectos,
agentes e serviços Web podem comunicar directamente com o sistema usando as respectivas
interfaces.

Para as aplicações orientadas por objectos, a interface definida permite a comunicação com
modelos de componentes. Os modelos suportados são o JINI [JINI 2005] e o XSP. Aplicações,
usando esta interface, acedem ao sistema tal como se este se tratasse de um único componente.

A interface de agentes transforma o sistema num agente, registando-o numa rede de

agentes. Outros agentes que queiram comunicar com o sistema fazem-no usando uma
linguagem de comunicação de agentes. As interfaces de agentes tratam de traduzir esses
pedidos e de os enviar aos componentes responsáveis.

A interface de serviços Web transforma o sistema num serviço. Aplicações que usem
serviços Web requerem serviços de contexto através desta interface. Os pedidos são depois
traduzidos e enviados aos componentes responsáveis pela funcionalidade requerida.

Das interfaces descritas apenas as interfaces de aplicações orientadas por objectos foram
implementadas durante a escrita da tese.

O sistema permite estender o conjunto de aplicações que lhe acedem através da criação de
outras interfaces. Esta funcionalidade torna o sistema mais extensível. Deve salientar-se que
na adição de novas interfaces e na alteração de interfaces já existentes apenas as extensões aos

48
mecanismos básicos dos componentes necessitam de ser recompiladas. Estes mecanismos
básicos implementam as funcionalidades dos componentes.

5.1.2 Diagrama de componentes do GCMAS

O GCMAS é composto por vários componentes. Cada um destes desempenha uma função
específica para o sistema. Na Figura 12 encontra-se representado o diagrama de componentes
da arquitectura. Esta figura apresenta três camadas relevantes para o GCMAS, a camada de
sensores, contexto e aplicação. O sistema funciona assim como uma camada intermédia
(“middleware”).

Na camada dos sensores estão presentes os sensores de hardware e as redes de sensores

inteligentes. Estes ligam-se ao GCMAS, que se encontra distribuído na camada intermédia,
através dos adaptadores de sensores.

Figura 12 – Componentes da arquitectura do sistema

O sistema está implementado entre a camada de aplicação e a dos sensores, sendo que
parte desta camada se encontra dentro da camada de aplicação. A parte do sistema que se
encontra dentro da camada de aplicação representa a extensão deste sistema para as aplicações.
Esta extensão está representada na Figura 12 pelo interpretador de contexto.

49
 Na camada de aplicação encontram-se os sensores de software e as aplicações. São estes
que fornecem e pesquisam informações de contexto no sistema. As aplicações podem também
efectuar a subscrição de eventos.

Os componentes que se encontram entre a camada de aplicação e a camada dos sensores

são os elementos funcionais do sistema. Estes elementos são genéricos e independentes das
aplicações que lhe acedam.

Os componentes do GCMAS que se encontram na camada de aplicação são mais

específicos para as aplicações. Estes componentes tratam da interpretação, agregação e
raciocínio de contexto de maneira a produzir contexto com níveis de abstracção mais
próximos das aplicações.

Cada componente do sistema fica responsável por implementar as interfaces necessárias

para comunicação com as aplicações que acedem ao sistema. A comunicação entre
componentes encontra-se representada na Figura 12 pelas interacções de (1) a (13).

5.1.2.1 Componente de adaptador de sensor

Os adaptadores de sensor são componentes cuja principal função é adaptar as informações
produzidas pelos sensores para a ontologia do sistema (Figura 12 (4)), (ver Capítulo 4). Estes
tratam também dos eventos enviados pelo componente de pesquisa (Figura 12 (3)) (ver secção
5.1.2.3). O armazenamento de informação de histórico e a submissão de informações
sensoriais para o mecanismo de eventos é também outra das funcionalidades dos adaptadores.

As ferramentas de adaptação das informações recolhidas dos sensores para a ontologia do

sistema são apresentadas como um pacote de desenvolvimento de sensores (API). Este pacote
permite aos programadores desenvolver facilmente adaptadores de sensor apropriados para o
sistema. Funcionalidades como a inscrição do sensor no sistema e métodos de acesso à
informação do sensor estão presentes neste pacote.

Para tornar o sensor visível ao sistema, é necessário registar o seu componente de

adaptação no serviço de páginas amarelas (Figura 12 (13)). O processo é efectuado
automaticamente pelos componentes criados com o pacote de desenvolvimento.

Este registo consiste na indicação da classe de contexto associada ao sensor, e na indicação

da entidade à qual esse sensor está associado. Estas indicações são efectuadas com base na
ontologia descrita (ver Capítulo 4 secção 4.2). A classe de contexto associada ao sensor
corresponde ao elemento de contexto que define esse sensor (e.g., a classe localização). A

50
entidade associada ao sensor corresponde à entidade de contexto representada pelo elemento
de contexto (e.g., a classe pessoa).

Durante o processo de registo do sensor efectua-se também o registo da entidade associada

ao sensor caso esta ainda não exista no sistema (e.g., da primeira vez que se regista um sensor
para a “pessoa A” no sistema, a entidade “pessoa A” tem de ser criada no registo do sistema).

O registo da entidade no sistema permite que sejam feitas associações a outras entidades já
existentes. Essas associações têm no entanto de ser especificadas pelo sensor que está a
registar a entidade. O registo de entidade é efectuado pelo controlador de ontologia, descrito
na secção 5.1.2.6.

Quando várias instâncias do mesmo adaptador de sensor são lançadas, correspondendo

cada uma delas a um sensor distinto, ocorre redundância. O sistema permite que vários
sensores do mesmo tipo de informação e relativos à mesma entidade possam ser registados,
considerando-os como sensores redundantes.

Os adaptadores de sensor podem também ser desenvolvidos sem recurso ao pacote de

desenvolvimento de sensores. Para que sejam compatíveis com o GCMAS, estes terão de
implementar a interface do componente de adaptação de sensores. Esta interface permite a
comunicação com o resto do sistema.

Os pedidos de pesquisa de informação de contexto efectuados por aplicações são

encaminhados pelo componente de pesquisa de contexto para a interface do componente de
adaptação de sensor (Figura 12 (3)) (ver secção 5.1.2.3). Esta possui métodos que permitem a
requisição da informação mais recente presente no sensor e a requisição de um conjunto de
valores obtidos anteriormente, também denominado de histórico de contexto.

A requisição de informação de histórico implica a indicação do número de amostras que se

pretende. Estas amostras representam a informação do sensor obtida desde a mais recente até
ao número de amostras que se requereu. É também possível fazer o pedido de amostras de
contexto num determinado intervalo de tempo.

O componente de adaptação de sensores trata também do armazenamento dessas amostras.

Esta capacidade de armazenamento pode ser considerada como uma extensão do componente
de repositório (ver secção 5.1.2.2).

Fazendo com que cada componente de adaptação trate do problema de armazenamento

alivia-se a necessidade de armazenamento e de consulta do repositório do sistema. Como cada

51
componente de adaptação corre no local onde se encontra o sensor, armazenar localmente a
informação de histórico do sensor é a solução mais adequada. A gestão do número de
amostras que podem ser guardadas e a forma como são armazenadas é feita pelo próprio
componente de adaptação.

O componente de adaptação é também responsável pela notificação de eventos. Quando

requisitado, o componente de adaptação notifica o componente de eventos (ver secção 5.1.2.4)
sempre que se verifiquem alterações no contexto capturado pelo sensor. Esta notificação
consiste no envio da nova informação do sensor.

O componente de adaptação de sensores possui interfaces definidas para a comunicação

com o componente de eventos. Os métodos desta interface permitem que componente de
eventos se inscreva no sensor. Esta inscrição permite que o sensor saiba a quem enviar as
notificações de nova informação de contexto. O mecanismo de eventos está descrito em
pormenor na secção 5.1.2.4.

Os adaptadores de sensor podem estar ligados a um hardware específico que faz a captura
da informação ou serem apenas software. Aplicações que queiram guardar informação
directamente no sistema sem recorrer ao uso de sensores terão de comunicar com o
componente de repositório (ver secção 5.1.2.2).

Os adaptadores de sensor podem também representar redes de sensores inteligentes. A

implementação destes adaptadores será no entanto mais complexa pois a forma como a
informação é retirada dos sensores é também mais complexa.

O acréscimo de complexidade é contrabalançado com a quantidade de informação que é

obtida a partir das redes de sensores. Estas redes normalmente usam mecanismos de
comunicação por pacotes [Michachelles e Samulowitz 2001, Samulowitz et al 2001,
Kummerfeld et al 2003].

O adaptador de sensor permite a tradução da informação retirada desses pacotes para a

ontologia do sistema. A funcionalidade de extracção de informação das redes de sensores não
foi no entanto implementada no desenvolvimento da tese, pois implicaria um grande esforço
na implementação de adaptadores de sensor.

O componente de adaptação de sensor é dos componentes mais complexos do GCMAS. A

maioria dos pedidos feitos ao sistema é redireccionada para este componente, tornando-o
numa peça fundamental para o funcionamento do sistema.

52
5.1.2.2 Componente de repositório
O componente de repositório é responsável pelo armazenamento das informações de
contexto enviadas pelas aplicações e pela gestão do histórico de contexto desta informação. O
repositório representa uma forma alternativa de guardar informação de contexto. Esta serve
para que aplicações possam fornecer informações de contexto, sem recurso a sensores, que
são guardadas no repositório do sistema. O armazenamento é efectuado numa base de dados
gerida pelo próprio componente.

Este componente possui dois tipos de interface, externa e interna. Interfaces externas
permitem que aplicações armazenem contexto no sistema. Interfaces internas permitem que o
componente de pesquisa possa recolher contexto do repositório.

O contexto guardado no repositório é normalmente considerado como contexto estático

pois as alterações da informação são esporádicas. No entanto não há imposições relativas a
aplicações que queiram usar o repositório para guardar informações mais dinâmicas.

Se um grande volume de informação dinâmica passar a ser guardado no repositório, o

acesso a este componente pode tornar-se mais demorado do que no caso de se usarem
sensores. Isto ocorre pois o acesso ao componente de adaptação do sensor é dedicado à
aplicação ao contrário do que acontece com o acesso ao componente de repositório. Este é
acedido por várias aplicações ao mesmo tempo pois encontra-se centralizado no sistema.

Os sensores estarão directamente ligados à aplicação e só quando outras aplicações

requerem a informação de contexto fornecida é que ocorre comunicação. O uso de sensores
permite também que seja possível a subscrição de eventos de contexto para esse tipo de
informação.

Para diferenciar a informação obtida por sensores da informação guardada no repositório

estas são representadas de formas diferentes na ontologia do sistema (ver secção 4.2.1 do
Capítulo 4). Esta diferenciação ocorre apenas dentro do sistema para facilitar a pesquisa de
informação. Para as aplicações, tanto a informação de sensores como a informação do
repositório é informação de contexto e pode ser acedida através da interface do componente
de pesquisa de contexto (ver secção 5.1.2.3).

A principal função do repositório é receber os dados das aplicações (9,12) e armazená-los

na base de dados do sistema. Estes dados são guardados em conjunto com a informação da
entidade à qual estão associados. Isto permite definir a que entidade a informação de contexto
pertence.

53
 As entidades são registadas no sistema no momento em que se armazena a informação. Os
pedidos de registo de entidades são tratados pelo controlador de ontologias (ver secção
5.1.2.6).

O sistema de contexto permite a actualização das ontologias com novas classes de

informação de contexto. Esta actualização é realizada pelo núcleo do sistema, descrito na
secção 5.1.2.6, e implementa interfaces tanto do lado das aplicações como do lado dos
sensores.

O armazenamento de informação no repositório é feito recorrendo a uma base de dados

relacional. Esta pode estar centralizada num só local ou distribuída pelos vários locais onde
são executadas as instâncias do componente de repositório. A distribuição é feita ao nível da
base de dados, sendo que, para todos os efeitos, as instâncias dos componentes usam sempre a
mesma base de dados.

O repositório permite armazenar, para além da informação actual de contexto, o histórico

das amostras armazenadas anteriormente. Para limitar o espaço ocupado pelo histórico,
apenas se guarda um determinado número de amostras. Este número é definido pelo sistema.

De notar que ao contrário do que acontece com a informação proveniente de sensores, a

informação de repositório é centralizada. Apenas o histórico da informação de repositório tem
um número limite de amostras fixo e determinado pelo sistema. O limite de amostras de
histórico da informação proveniente de sensores é determinado por cada sensor.

Para permitir a comunicação com diferentes tipos de aplicações definem-se várias

interfaces externas para o repositório. Estas fazem parte das interfaces externas do GCMAS
para armazenamento de informação de contexto.

Como campos comuns para os pedidos de armazenamento de contexto tem-se a indicação

do contexto a armazenar e da entidade à qual estão associados. Isto permite desenvolver uma
base comum a partir da qual se podem criar novas interfaces. Os pedidos relacionados com
inscrição de entidades também estão incluídos nestas interfaces.

A interface interna do repositório recebe os pedidos do componente de pesquisa de

contexto (Figura 12 (3)). Estes ocorrem quando são feitas pesquisas a informações guardadas
no repositório. Os métodos apresentados nesta interface permitem recolher o contexto do
repositório usando os mesmos atributos que na interface dos adaptadores de sensor.

54
 O componente de repositório permite que informações importantes sejam guardadas de
forma indefinida no GCMAS. Estas informações são acedidas por outras aplicações usando as
interfaces de pesquisa de contexto do sistema. Para as aplicações não há diferenciação entre
informação vinda do repositório e informação vinda de sensores.

5.1.2.3 Componente de pesquisa de contexto

O componente de pesquisa trata dos pedidos de pesquisa de contexto feitos pelas aplicações
(Figura 12 (1)). Estes pedidos podem estar ligados a informações retiradas de sensores (Figura
12 (2)) ou do repositório (Figura 12 (3)). O componente implementa as interfaces externas do
GCMAS para pesquisa de informação de contexto.

A mesma interface é usada tanto para a pesquisa de contexto de sensores como para a
pesquisa de contexto de repositório. A diferenciação entre estas duas ocorre no componente
de pesquisa e é dada pela ontologia. A informação proveniente de sensores estende uma
classe ontológica diferente da informação proveniente do repositório.

Basta ao componente determinar qual a classe da ontologia que a informação requerida

estende para orientar a pesquisa dessa informação para o repositório ou para o serviço de
páginas amarelas. É no serviço de páginas amarelas que se procede à localização do sensor
que fornece o contexto requerido (ver secção 5.1.2.5).

As interfaces implementadas por este componente permitem que aplicações externas façam
pesquisas sobre a informação actual de contexto e sobre histórico de contexto. O histórico de
contexto consiste no conjunto de amostras de um sensor ou repositório obtidas ao longo do
tempo.

As amostras devolvidas numa pesquisa representam o contexto recolhido no sensor ou no

repositório desde a informação mais actual até ao número de amostras requisitado. A pesquisa
de histórico de contexto também pode ser efectuada tendo como parâmetro o intervalo de
tempo desejado.

Para efectuar a pesquisa, as aplicações têm de indicar qual a classe do elemento de

contexto que querem procurar e qual a entidade associada. Para pesquisas de histórico é
também necessário indicar o número de amostras pedido ou o intervalo de tempo a considerar.

O sistema retorna um objecto comum para todas as pesquisas, tanto para as de informação
actual como de histórico. Neste objecto encontra-se encapsulada a informação pretendida. Os
vários tipos de resposta são encapsulados neste objecto.

55
 Para os diferenciar, o objecto devolvido possui um parâmetro que indica o tipo de resposta.
Quatro tipos de resposta são possíveis na pesquisa de contexto: informação actual, informação
de histórico, informação actual redundante e informação de histórico redundante. Estes estão
representados na Tabela 2.

Tabela 2 – Tipos de resposta da pesquisa de contexto

Tipo de resposta Descrição

Informação actual Amostra mais recente do sensor ou
repositório
Informação de histórico Conjunto de amostras recolhidas do
sensor ao longo de um determinado tempo
Informação actual redundante Conjunto das amostras actuais dos
sensores redundantes
Informação de histórico redundante Conjunto de amostras recolhidas ao longo
de um determinado tempo, de cada um
dos sensores redundantes

Quando uma aplicação realiza uma pesquisa da informação actual de contexto (e.g.,
obtenção da localização actual de uma pessoa), a resposta devolvida vem sob a forma de uma
informação actual. Este tipo de resposta ocorre quando o sensor que fornece a informação
pretendida não é redundante ou quando a informação é fornecida pelo repositório. A
informação encapsulada no objecto devolvido vem na forma original do tipo de informação
(e.g., se a localização for dada por um objecto da classe Location então a informação
encapsulada estará sob a forma de um objecto Location).

Quando uma aplicação realiza uma pesquisa de informação de histórico de contexto (e.g.,
obtenção da lista de locais por onde uma pessoa andou) a resposta devolvida vem sob a forma
de uma informação de histórico. Este tipo de resposta ocorre quando o sensor que fornece o
histórico não é redundante ou quando se trata do histórico de informações de repositório. A
informação encapsulada na resposta vem sob a forma de um conjunto de amostras de contexto.
(e.g., se a localização for dada por um objecto da classe Location então a informação
encapsulada estará sob a forma de um vector de objectos Location)

Quando a pesquisa é realizada sobre sensores redundantes, o componente de pesquisa tem

de retirar a informação de contexto de todos os sensores. Estas são depois agrupadas e
enviadas para a aplicação que as requereu. Não é realizado nenhum tratamento dessa

56
informação pelo sistema, com a excepção da conversão do formato original específico do
sensor para o formato da ontologia.

O resultado destas pesquisas pode dar origem a uma resposta do tipo informação actual
redundante ou do tipo informação de histórico redundante. O tipo de resposta depende de se
estar a pesquisar por informações actuais ou por informações de histórico.

No caso de se tratar de uma pesquisa de informação actual, é devolvido o grupo de

amostras dos sensores redundantes. No caso de se tratar de uma pesquisa de informação de
histórico é devolvido o grupo de amostras de histórico, retiradas de cada sensor redundante.

Tal como os restantes componentes do sistema, este componente permite o lançamento de

várias instâncias no sistema. O acesso à informação de repositório e à informação sensorial é
garantido pois tanto a base de dados onde se guarda o repositório como o serviço de páginas
amarelas onde se registam os sensores são vistos pelos componentes do sistema como
elementos centralizados.

5.1.2.4 Componente de subscrição de eventos

O componente de subscrição de eventos permite que uma aplicação subscreva a recepção
de eventos (Figura 12 (10)) sempre que nova informação de contexto esteja disponível.
Sempre que houver alterações ao contexto, a aplicação é notificada com o envio da nova
informação de contexto por parte do sistema. Este processo é denominado, no âmbito desta
tese, de “subscrição de eventos de contexto”.

O processo em si divide-se em duas etapas. Na primeira, a aplicação faz a subscrição no

sistema. Na segunda etapa, o sistema notifica essa aplicação sempre que haja alterações ao
contexto subscrito.

A subscrição suporta apenas contexto fornecido por sensores, tendo de ser feita
individualmente para cada sensor. O componente de subscrição de eventos trata de
encaminhar as subscrições para o componente de adaptação de sensor (11). Este fica
responsável por notificar o componente de eventos sempre que detectar uma alteração na
informação recebida pelo sensor (e.g., após receber o pedido do componente de eventos, um
adaptador de sensor para um sensor de localização passa a notificar o componente de eventos
sempre que um utilizador muda de lugar).

O componente de eventos usa a interface definida pelo componente de adaptação de

sensores (ver secção 5.1.2.1) para se subscrever. Isto permite que o componente de adaptação

57
de sensores saiba que tem de enviar notificações e a qual a instância do componente de
eventos deve enviar.

Este componente implementa as interfaces externas do GCMAS responsáveis pela

subscrição de eventos. Estas possuem métodos que permitem às aplicações indicar ao sistema
que querem ser notificadas sempre que haja alterações no contexto recolhido por um dado
sensor.

Para poderem ser notificadas, as aplicações têm de implementar uma interface

disponibilizada pelo sistema. Esta interface declara o método que permite ao sistema enviar a
nova informação de contexto para uma aplicação. Uma aplicação, ao subscrever um evento,
está a registar esta interface numa tabela de encaminhamento.

A tabela de encaminhamento possui, para além da ligação à interface, uma ligação ao

sensor do qual a aplicação quer receber as notificações. Quando um sensor envia uma
notificação ao componente de eventos este verifica quais as aplicações que requereram
notificações desse sensor e encaminha a notificação.

Tal como acontece com as interfaces do GCMAS, existem vários tipos de interfaces
disponíveis para serem implementados pelas aplicações. Estas interfaces estão associadas aos
mesmos tipos de aplicação que as interfaces externas do sistema.

A adaptação das notificações para os diferentes tipos de aplicação é feita recorrendo a

módulos de interpretação. Por cada novo tipo de interface um novo módulo de interpretação
tem de ser acrescentado ao componente de eventos.

5.1.2.5 Serviço de páginas amarelas

O serviço de páginas amarelas é a peça fundamental para o funcionamento dos sistemas
baseados em componentes. Neste sistema tem como funcionalidade o registo e localização
dos componentes do sistema, tanto componentes internos como adaptadores de sensor.

O GCMAS funciona sobre uma plataforma de gestão de componentes que possui o seu
próprio serviço de páginas amarelas. Este é usado maioritariamente para registo e pesquisa de
sensores.

Cada novo sensor que se queira ligar ao sistema tem de registar o seu componente de
adaptação neste serviço (13). Isto permite que o componente do sensor esteja incorporado na
lista de componentes afectos ao serviço. Facilita-se assim a localização do componente. A

58
comunicação com os componentes é sempre feita através dos métodos especificados nas suas
interfaces.

Para registar um componente num serviço de páginas amarelas basta indicar a interface
que o componente implementa. Para distinguir várias instâncias do mesmo componente pode
enviar-se também um identificador que as distinga.

O registo de sensores no serviço de páginas amarelas do sistema requer mais informação.

Registar um sensor implica indicar ao serviço não só a interface que o componente de
adaptação implementa como também a informação do tipo de contexto fornecido pelo sensor
e a entidade à qual a informação está associada. Com estas informações a pesquisa de
informação de contexto torna-se mais simples. Os dados requeridos na pesquisa de
informação são os mesmos que para o registo de sensores.

O processo de registo de componentes internos ocorre de forma semelhante. Um

componente do sistema regista-se no serviço de páginas amarelas indicando a interface que
implementa e um número de instância. O número de instância é responsável por diferenciar as
várias instâncias do componente.

A implementação de interfaces do sistema para outras aplicações pode requerer a inscrição

de certos componentes em serviços de páginas amarelas externos. A inscrição em serviços
como o serviço de páginas amarelas do XSP e o directório de agentes é feita na
implementação da interface específica.

Sem o serviço de páginas amarelas seria impossível gerir os componentes constituintes do

GCMAS, os quais podem aparecer ou desaparecer dinamicamente.

5.1.2.6 Núcleo do GCMAS

O núcleo do GCMAS pode ser considerado como um componente do sistema que agrega
várias funções incluindo o seu arranque. Estas funcionalidades estão dispersas pelo sistema
sendo usadas pelos vários componentes.

Os métodos de arranque são configuráveis, sendo possível indicar que interfaces deverão
ser iniciadas e quantas instâncias dos componentes internos são lançadas. A ontologia do
sistema é carregada pelos componentes do núcleo. Os métodos incluídos no núcleo do sistema
incluem também a gestão de ontologias.

59
 A gestão de ontologias é efectuada por um pequeno módulo associado aos componentes de
pesquisa, repositório e adaptação de sensores. Este módulo possui interfaces que permitem a
inclusão de novas classes de informação de contexto na ontologia e a pesquisa sobre a
ontologia do sistema.

A inclusão de novas classes de informação de contexto na ontologia é um aspecto

importante da gestão de ontologias. Esta permite que sejam adicionados novos elementos à
ontologia sem reinicialização do sistema.

A inclusão ocorre quando novos sensores ou informação de repositório são adicionados ao

sistema. Caso a informação devolvida não esteja incluída na ontologia original do sistema, o
componente de adaptação de sensor, ou o componente de repositório realizam a actualização
da ontologia.

Para actualizar a ontologia, tem de se indicar ao módulo de gestão de ontologias a

localização do ficheiro onde se encontra descrita a nova informação. A linguagem de
ontologia usada nesta descrição tem ser a mesma que a usada na ontologia do sistema.

Outro dos aspectos importantes na gestão da ontologia é a pesquisa de informações na

própria ontologia. Tanto as entidades como a associação destas aos sensores ou a informação
de repositório são guardadas na ontologia. O módulo de gestão de ontologias permite a
resposta a pedidos de registo e a pedidos de pesquisa de informação na ontologia.

As informações sobre entidades, sensores ou informação de repositório são guardadas na

ontologia como instâncias das classes que as representam. Por cada novo sensor ou
informação de repositório adicionado ao sistema, a sua descrição é associada à descrição do
sensor ou do repositório na ontologia.

Estas associações também existem entre instâncias de entidades. Os pedidos de associação

de entidades são emitidos pelas aplicações responsáveis pela entidade ou sensores associados.

O núcleo do sistema possui também métodos para desligar os componentes associados

caso seja necessário. Estes estão concentrados numa classe de arranque do sistema,
responsável por iniciar os mecanismos necessários à manutenção da plataforma de gestão de
componentes sobre a qual corre o GCMAS. Esta classe permite também iniciar os
componentes internos mediante as configurações feitas.

Cada componente tem a capacidade de associar-se por si só ao sistema sem que seja
necessário recorrer aos métodos de arranque do núcleo. O componente de adaptação de

60
sensores como depende directamente do sensor, possui métodos específicos para o seu registo
no sistema, independentes dos métodos de arranque do núcleo.

O núcleo do sistema permite simplificar o arranque deste, centralizando-o numa

funcionalidade do próprio sistema.

5.1.2.7 Componentes do módulo de aplicação

Os componentes que se encontram na camada de aplicação do GCMAS fornecem
ferramentas às aplicações. Estas ferramentas permitem aumentar o nível de abstracção da
informação adquirida nos sensores. Os componentes presentes nesta camada são apresentados
como uma extensão do sistema.

O principal componente da camada de aplicação é o interpretador de contexto. Este é

responsável por elevar o nível de abstracção da informação de contexto para um nível mais
próximo do das aplicações. Para tal este componente pode comunicar com o componente de
pesquisa (Figura 12 (5)) para fazer pesquisa de novas informações.

O interpretador de contexto serve em certos casos de interface entre a aplicação e o

componente de pesquisa (Figura 12 (8)), transformando as perguntas de alto nível feitas pelas
aplicações em perguntas de mais baixo nível, interpretáveis pelo GCMAS.

Isto é útil quando a comunicação entre a aplicação e o sistema tem de ser feita a um nível
de abstracção mais alto. A subida do nível de abstracção da informação de contexto pode
requerer também o uso dos componentes de agregação (Figura 12 (6)) e de raciocínio (Figura
12 (7)).

O componente de agregação tem como principal função a agregação da informação de

contexto recolhida durante a pesquisa de modo a produzir novo contexto. Esta agregação
consiste em juntar vários elementos de contexto num único elemento de mais alto nível. Para
tal são usadas ontologias de nível mais elevado, descrevendo classes que integram informação
proveniente de mais do que uma fonte, que indicam que elementos podem ou não ser
agregados. Estas ontologias são determinadas no próprio componente de agregação.

O componente de raciocínio usa mecanismos de inferência para produzir novo contexto a

partir de contexto já recolhido. A inferência permite a criação de nova informação de contexto
sem ser necessária a recolha de mais informação de sensores ou de repositório. Para que tal
seja possível, é necessário usar mecanismos de inferência associados a ontologias que
definam características e categorias de contexto.

61
 As ontologias definidas no módulo de aplicação têm como base a ontologia do sistema
para manter a compatibilidade da informação. Estas ontologias são no entanto mais
complexas e especificas das aplicações para qual o módulo foi desenvolvido.

A comunicação desde módulo com os componentes internos do sistema é feita usando as

interfaces internas dos componentes. Isto possibilita uma comunicação mais rica que no caso
de serem usadas as interfaces externas. Estas são as interfaces usadas por aplicações que
acedam ao sistema.

O facto de se usar as interfaces internas dos componentes permite que a comunicação do

módulo de aplicação com os componentes do sistema seja mais directa. Isto torna a utilização
deste módulo mais apreciável por parte de aplicações que queiram trabalhar sobre a
informação obtida no sistema. Ao comunicar directamente com o interior do sistema
consegue-se melhorar o desempenho da interpretação da informação de contexto.

O componente de interpretação encontra-se sob a forma de um módulo adicional pois este

possui funcionalidades específicas da aplicação à qual está adaptado. Isto permite manter o
GCMAS genérico. Sem a adição do módulo de aplicação, as funcionalidades do sistema
adaptam-se a todos os cenários de uso de informação de contexto. A especificação do
GCMAS irá ser exclusivamente dependente da ontologia utilizada.

A introdução do módulo de aplicação no interior do sistema como se este se tratasse de um

componente interno faria com que fosse necessário proceder a alterações sempre que se
usasse o GCMAS numa aplicação diferente. O módulo de aplicação é apresentado como um
componente opcional que é implementado especificamente para uma aplicação.

Este módulo possui as ferramentas necessárias para o desenvolvimento. Estas permitem

que, para cada cenário específico, sejam construídos componentes especializados para a
aplicação que irão integrar-se no sistema.

A solução do módulo de aplicação permite assim usufruir das vantagens de um sistema de

contexto genérico ao mesmo tempo que garante que as aplicações que o usam não necessitem
de interpretar o contexto de forma complexa. Os componentes desenvolvidos do módulo de
aplicação comportam-se tal como se fossem componentes internos do sistema.

62
5.2 Considerações de desenho
As considerações de desenho definem aspectos como as linguagens de desenvolvimento, o
mecanismo de gestão de componentes a usar e aspectos da integração da ontologia. Estes
aspectos são importantes para encaminhar a implementação do sistema.

Como linguagens usadas no desenvolvimento do sistema usa-se o Java [Java 2005], o

OWL [W3C 2004] e o XML Schema [W3C 2004b]. O Java é usado no desenvolvimento dos
componentes e interfaces do sistema. Esta linguagem permite criar uma estrutura
independente da arquitectura para o sistema. Isto permite ao sistema correr sobre qualquer
plataforma computacional ou sistema operativo.

Como linguagens de desenvolvimento de ontologias usa-se o OWL e o XMLSchema. O

OWL é utilizado para definir as ontologias base e de distribuição do contexto (ver Capítulo 4).
Esta linguagem permite a descrição de ontologias usando lógica descritiva. É uma linguagem
estável e normalizada, sendo utilizada em muitas aplicações.

O XMLSchema é usado para descrever a ontologia de dados do contexto (ver secção 4.2.3
do Capítulo 4). Esta linguagem permite a transformação automática das classes descritas em
objectos. Para tal, é usada uma ferramenta de conversão, o SCB (“Schema Class Builder”),
desenvolvido pelo laboratório de investigação ”We, the Body, and the Mind” da ADETTI1,
em parceria com a Accedo2.

Esta transformação permite que baste definir apenas as classes de ontologia. A sua
representação em objectos concretos é garantida pela ferramenta de conversão.

Como mecanismo de gestão de componentes usa-se o JINI. Este mecanismo permite a

comunicação entre componentes desenvolvidos em Java que podem estar distribuídos por
vários locais. O serviço de páginas amarelas deste mecanismo permite a introdução de várias
informações sobre os componentes registados.

As interfaces definidas para o sistema também usam os seus mecanismos de comunicação.

Para a interface XSP é usado o mecanismo de gestão de componentes XSP, semelhante ao
mecanismo JINI.

1
We, the body and the mind research group. http://www.we-b-mind.org/
2
Accedo Consulting. http://www.accedo.pt

63
 A interface de agentes usa os protocolos definidos pela FIPA [FIPA 2002-00026] [FIPA
2002-00037] para a troca de mensagens entre agentes e o sistema. Estes protocolos usam o
FIPA-ACL (“Agent Communication Language”) [FIPA 2002-00061] como linguagem para
troca de mensagens entre agentes. A linguagem de conteúdo usada nessa comunicação é o
FIPA-SL (“Semantic Language”) [FIPA 2002 00008].

A interface de serviços Web usa a linguagem OWL-S [W3C 2005], como linguagem de
descrição de serviços. Esta é uma das linguagens padrão aconselhadas pelo W3C. São usados
os mecanismos padrão para comunicação com serviços Web.

Os componentes do GCMAS apresentam também interfaces para comunicação interna.

Um diagrama geral da comunicação entre os componentes internos encontra-se descrito na
Figura 13

A comunicação entre os componentes incide basicamente em operações de pesquisa de

contexto subscrição de eventos e de gestão de ontologias. Para tais operações são usadas as
interfaces dos componentes apresentados na secção 5.1.2. A interfaces internas descrevem as
operações que se podem fazer sobre estes componentes.

Figura 13 – Comunicação interna entre componentes

A integração da ontologia no sistema é feita recorrendo à ferramenta JENA [JENA 2005].

Esta ferramenta permite o uso de ontologias OWL no Java. O JENA usa a versão completa do

64
OWL e a interpretação directa de classes e instâncias da ontologia. No entanto, relações
directas entre classes da ontologia e objectos Java não são possíveis, justificando o uso da
ontologia de dados do contexto.

As considerações de desenho apresentadas determinam aspectos de desenvolvimento do

GCMAS. Devido ao grande número de funcionalidades do sistema a sua implementação será
complexa. Para diminuir esta complexidade cada uma das suas funcionalidades foi
desenvolvida isoladamente.

A separação é possível pois as funcionalidades são independentes umas das outras. Isto no
entanto não torna desnecessária a sua futura integração. Para facilitar este processo, cada
funcionalidade desenvolvida será integrada nas já existentes. Isto permite o desenvolvimento
do sistema em fases. Cada uma das fases de desenvolvimento acrescenta uma nova
funcionalidade ao sistema.

Uma visão mais detalhada das considerações de desenho pode ser observada no Anexo IV.
As convenções usadas no desenvolvimento do sistema podem ser observadas no Anexo VII.

5.3 Desenvolvimento do GCMAS

É na fase de desenvolvimento que se põe em prova o funcionamento das decisões tomadas
no desenho. Para simplificar o processo de desenvolvimento, este foi separado em várias fases.
Em cada uma delas foi adicionada uma nova funcionalidade ao sistema. Partes destas
funcionalidades são incrementos aos componentes já existentes em fases anteriores.

A organização definida para as fases de desenvolvimento permite que as funções essenciais

do sistema sejam desenvolvidas em primeiro lugar. Estas funções essenciais consistem na
concepção de um mecanismo de captura de informação de sensores. Este encontra-se
desenvolvido nos adaptadores de sensor. Por esta razão estes são os primeiros componentes a
serem desenvolvidos.

Na primeira fase de desenvolvimento o GCMAS baseia-se na interacção directa entre

aplicações e adaptadores de sensor. As interfaces usadas pelos adaptadores de sensor para
pesquisas de informação serão, em fases futuras, as interfaces de comunicação interna com o
sistema.

Aos adaptadores de sensor foram sendo agregadas outras funcionalidades acessórias, que
também possuem a sua relevância no funcionamento do sistema. Destas, a mais importante é

65
a manipulação de ontologias, que permite associar a informação de contexto a uma ontologia.
Esta integração dá origem à segunda fase de desenvolvimento.

Os mecanismos de distribuição da informação de contexto tornam-se mais simples pois a

estrutura da informação está centralizada numa ontologia, compreendida por um grande
número de aplicações. Introduz-se também o componente de pesquisa de informação e as
interfaces JINI e XSP para pesquisa.

O componente de adaptação de sensor é actualizado com a funcionalidade de

armazenamento de histórico de sensores. A implementação do núcleo do GCMAS inicia-se
com a definição do módulo de gestão de ontologias.

A terceira fase de desenvolvimento trata da construção das interfaces que permitem o

acesso às funcionalidades do sistema. Inicia-se com as funcionalidades mais básicas, o acesso
à informação dada por sensores, e segue-se para funcionalidades mais complexas como o
armazenamento de contexto no próprio sistema e subscrição de eventos.

O componente de repositório é implementado, permitindo a aplicações guardar e pesquisar

informação de repositório. As interfaces JINI e XSP para armazenamento de contexto são
também implementadas. O módulo de gestão de ontologias é terminado. Na parte subscrição
de eventos de contexto é desenvolvido o componente de eventos. As interfaces JINI e XSP de
subscrição de eventos são implementadas e é definida a interface de aplicações de contexto
para aplicações orientadas por objectos.

A quarta fase de desenvolvimento introduz os restantes interfaces do sistema, as interfaces

de agente e de serviço Web. Os restantes componentes internos do sistema são ajustados e
terminados. Nesta fase são concluídas as funcionalidades descritas para a camada genérica do
GCMAS.

Depois de definidas interfaces de comunicação mais complexas parte-se para a quinta fase
de desenvolvimento, onde se implementa o módulo de interpretação de contexto. Esta fase
não é no entanto abrangida neste documento devido à sua complexidade ser tão grande quanto
o desenvolvimento de toda a parte genérica do GCMAS.

A complexidade da implementação das fases do sistema associada a problemas

encontrados no desenvolvimento levou a que, até ao momento da escrita da tese, o GCMAS
se encontrasse a meio da terceira fase de desenvolvimento.

66
 Os componentes e interfaces a desenvolver na terceira e quarta fases são descritos numa
secção à parte. Esta descrição apresenta os conceitos e possíveis formas de implementar as
funcionalidades presentes nestas fases. Descrições mais completas da implementação de cada
um dos componentes são apresentadas no Anexo V.

5.3.1 Adaptação de sensores e pesquisa de informação

Esta fase torna possível a pesquisa de informações de contexto fornecidas por sensores e o
registo destes no serviço de páginas amarelas. O sistema desenvolvido trata-se simplesmente
de um conjunto de componentes que comunicam com a aplicação que requer o contexto.

Estes componentes representam cada sensor e correm independentemente nas máquinas

que possuam os sensores. Os componentes são registados num único serviço de páginas
amarelas. Este serviço em conjunto com os componentes representantes de sensores formam a
parte central do sistema.

As pesquisas de sensor são feitas directamente ao serviço de páginas amarelas. A

comunicação do sistema é feita usando directamente a interface do adaptador de sensor. Esta
será a interface que em versões futuras servirá de interface interna de comunicação com os
componentes do sistema de contexto. Uma descrição mais completa do componente
desenvolvido nesta fase encontra-se na secção 5.01 do Anexo V.

5.3.2 Introdução do conceito de ontologias e componente de pesquisa de

contexto
Na segunda fase de desenvolvimento, o sistema passa a trabalhar sobre uma ontologia. Na
primeira fase, os objectos devolvidos pelos sensores não se encontravam definidos numa
ontologia. Isto implicava que, durante o desenvolvimento da aplicação, esta teria de conhecer
à priori todos os sensores que se poderiam ligar ao sistema e qual o tipo de informação que
estes devolviam.

A introdução da ontologia veio permitir que estas informações estivessem centralizadas

num só local e pudessem ser facilmente actualizadas. Para além de facilitar o acesso á
informação, a ontologia permite também que as aplicações se possam adaptar ao tipo de
informação devolvida pelos sensores.

Tal como especificado no Capítulo 4 a informação de contexto é representada por três

ontologias. O sistema foi modelado de acordo com a ontologia base de contexto. Esta define

67
que a informação de contexto é representada por um elemento de contexto que está ligado a
uma entidade, a qual é definida por esse elemento. Entidades de contexto são definidas por
vários elementos de contexto. A cada elemento de contexto está associada a uma classe da
ontologia de dados do contexto.

De modo a criar uma representação dos conceitos definidos na ontologia base, foram
criados um conjunto de objectos Java que os representam. Na Tabela 3 encontra-se a
descrição de cada um destes objectos.

As informações de contexto devolvidas pelo sistema serão instâncias de ContextObject.

Cada sensor ou informação de repositório tem de preencher estas instâncias para retornar a
informação que possuem.

Um exemplo de uma instância deste objecto para um sensor que devolve a localização de
uma pessoa seria a seguinte:

O objecto devolvido pelo sistema contém informação acerca da classe da ontologia de

distribuição do contexto que representa a localização. A informação da entidade à qual diz
respeito, neste caso a pessoa, encapsulada num objecto ContextEntity e a informação de
contexto propriamente dita estão também contempladas nesse objecto. A informação de
contexto propriamente dita, ou seja a localização, possui o formato definido pela ontologia de
dados do contexto.

Uma entidade é registada no sistema usando uma instância do objecto ContextEntity para a
representar. Este objecto contém informação acerca do identificador único da entidade e uma
descrição da mesma.

A ligação entre entidades ou entre uma entidade e um elemento de contexto é representada

pelo objecto Link. Um exemplo é a ligação entre uma pessoa e a sua informação pessoal. A
pessoa seria representada por uma entidade de contexto na ontologia, a informação pessoal
por um elemento de contexto.

Este objecto representa uma propriedade da ontologia. As propriedades são elementos da

ontologia que ligam duas classes distintas. A utilização deste tipo de objectos permite ao
indicar ao sistema quais as ligações entre as instâncias das entidades.

Para normalizar o processo de registo de sensores na ontologia estes são definidos de

acordo com o objecto SensorProperty. Este objecto representa as características do sensor tais
como qual o contexto que devolve e a que entidade está associado. O contexto guardado em

68
repositório também usa este objecto para fazer o armazenamento da informação. Um exemplo
da estrutura do objecto SensorProperty para um sensor que mede a temperatura de uma
divisão da casa seria a seguinte:

O objecto SensorProperty contém informação sobre o tipo de contexto que o sensor

retorna, neste caso a temperatura. Esta informação seria dada indicando a classe da ontologia
de distribuição do contexto que representa a temperatura. A informação da entidade também
estaria presente no objecto. Neste caso iria representar uma divisão indicando classe da
ontologia de distribuição do contexto que representa essa divisão, assim como um
identificador para esta.

O identificador permite distinguir as várias instâncias de entidades, neste caso permite

distinguir as várias divisões da casa. Esta seria a informação contida no objecto que permite o
registo do sensor no sistema.

Tabela 3 – Descrição dos objectos base da ontologia

Objecto Descrição
Representa uma entidade de contexto. As informações que
ContextEntity poderão ser extraídas deste objecto são o identificador único da
entidade e uma descrição.
Representa uma propriedade que liga duas entidades ou uma
Link
entidade a um elemento de contexto.
Representa o elemento de contexto. É responsável por guardar a
informação de contexto fornecida pelo sensor ou repositório e que
ContextObject está representado sob a forma determinada por uma classe da
ontologia de dados. Este objecto possui também informação
acerca da entidade à qual o contexto diz respeito
Representa as propriedades de um sensor. Este objecto não tem
representação directa na ontologia, pois trata-se de um
agrupamento de várias características da ontologia (classe do
SensorProperty sensor, classe da entidade, etc.), mas serve de formulário de
registo de componentes de adaptação de sensor. Todos os
componentes de adaptação terão de se registar com estes objectos
para indicar as suas propriedades.

69
 Para a integração da linguagem de ontologias a ser usada no GCMAS, o OWL, tirou-se
partido de uma ferramenta de modelação de ontologias denominada JENA. Esta trabalha com
a versão completa do OWL, permitindo a interpretação de ficheiros descritos nesta linguagem.

A integração do JENA no sistema permite que seja possível extrair e interpretar

informação de ontologia descrita em OWL. No entanto esta interpretação está limitada à
identificação de classes e instâncias existentes. Relações directas entre classes da ontologia e
objectos Java não são possíveis de fazer. Por esse motivo foram definidos os objectos
descritos na Tabela 3 para colmatar essa falha.

O uso da ferramenta JENA em conjunto com os objectos de representação da ontologia

permitem assim que o GCMAS possa trabalhar directamente com a ontologia usando a
linguagem OWL.

Para além da introdução das ontologias nesta fase também são criadas as interfaces
externas de pesquisa de contexto. Estas interfaces são implementadas pelo componente de
pesquisa de contexto, também introduzido nesta fase.

O componente de pesquisa recebe os pedidos de pesquisa das aplicações e comunica com o

componente de adaptação de sensor que devolve a informação requerida. Esta comunicação é
efectuada usando a interface definida pelo adaptador de sensor na primeira fase de
desenvolvimento. O componente de pesquisa obedece a um protocolo genérico de pesquisa de
informação. Este protocolo encontra-se descrito na Figura 35 e na Figura 36 do Anexo VI.

O armazenamento de histórico da informação de contexto completa as funcionalidades

definidas para o componente de adaptação de sensor. Este componente passa a ser
responsável pelo armazenamento e gestão desta informação.

Uma descrição mais completa dos componentes e funcionalidades implementadas nesta

fase encontram-se descritos nas secções 5.02 e 5.03 do Anexo V.

5.3.3 Armazenamento de contexto

A terceira fase de desenvolvimento introduz o armazenamento de contexto no repositório
do sistema. Nesta fase são desenvolvidos o componente de repositório e as interfaces de
armazenamento de informação.

Esta fase também contempla a funcionalidade de subscrição de eventos. No entanto, o

desenvolvimento programado para o sistema na altura da escrita da tese não contempla esta

70
funcionalidade. Esta descrição é feita de forma simplificada na secção 5.3.4 e de uma forma
mais detalhada na secção 5.05 do Anexo V.

O componente de repositório usa a ontologia do sistema para guardar a informação de

contexto enviada pelas aplicações. Para tal, o módulo de gestão de ontologias terá de ser
actualizado com novas funções.

Quando se inscreve uma entidade ou sensor a sua representação na ontologia é feita por um
individual (uma instância da classe respectiva da ontologia) (e.g., a entidade “pessoa A” é
representada na ontologia como o individual “pessoa A” da classe “pessoa”). O mesmo se
passa quando se submete uma informação de repositório. Essa informação é representada por
uma instância da classe respectiva na ontologia (e.g., A informação de memória do
dispositivo “dispositivo A” com valor “128 MB” é armazenada na ontologia como o
individual “128 MB” da classe “memória de dispositivo” e ligado ao individual “dispositivo
A” que representa o dispositivo).

A gestão de histórico de contexto no repositório usa registos adicionais na base de dados

onde é guardada a ontologia. No entanto, esta gestão não se encontra completamente
implementada no sistema pelo que não será contemplada nas funcionalidades actuais do
GCMAS.

As informações guardadas no repositório são pesquisadas da mesma forma que

informações de sensor. Quando uma aplicação requer informação de contexto usa os mesmos
interfaces e os mesmos métodos para pesquisar tanto informação de sensores como de
repositório.

Para uma aplicação externa não há diferenciação entre informações de repositório e

informações de sensores. É o componente de pesquisa que tem de filtrar os pedidos e
redirecciona-los para os componentes correspondentes.

As interfaces desenvolvidas nesta fase permitem que aplicações orientadas por objectos,
usando os mecanismos XSP e JINI, possam guardar informação de contexto no sistema. Estas
são as interfaces externas de armazenamento do sistema, podendo ser observadas na Figura 31
presente no Anexo V

Uma descrição mais completa dos componentes desenvolvidos nesta fase encontra-se na
secção 5.04 do Anexo V.

71
5.3.4 Componentes e interfaces não implementados no GCMAS
Esta secção descreve os componentes que não foram implementados durante a fase de
desenvolvimento desta tese de mestrado. São apresentadas de forma breve as noções tomadas
para o desenvolvimento do componente de subscrição de eventos e das interfaces de agentes.

Dada a complexidade do sistema, estas funcionalidades não chegaram a ser implementadas

no momento em que esta tese foi concluída. No entanto, para facilitar a futura implementação,
a sua integração no GCMAS será explanada simplesmente de forma conceptual.

O componente de subscrição de eventos comporta-se da mesma forma que os restantes

componentes do sistema. Este implementa as interfaces de subscrição de eventos descritas na
Figura 32 presente no Anexo V. As interfaces iniciais desenvolvidas para este componente
serão as interfaces JINI e XSP tal como ocorreu com os restantes componentes.

Alterações no componente de adaptação de sensores terão de ser realizadas para que a

subscrição de eventos seja possível. Estas irão permitir que o adaptador de sensor se aperceba
que tem de enviar as novas informações de contexto do sensor para o componente de eventos.

Este componente tem de definir uma interface de envio de eventos para aplicações de
modo a que estas recebam eventos de contexto. Esta interface é definida pelo sistema e tem de
ser implementada pelas aplicações externas que queiram receber eventos de contexto. São
definidos vários tipos de interfaces de envio de eventos adaptadas ao tipo de aplicação com o
qual se está a comunicar.

Uma descrição mais detalhada das noções de desenvolvimento desta funcionalidade pode
ser observada na secção 5.05 do Anexo V.

As interfaces de agentes funcionam de forma diferente das restantes interfaces

desenvolvidas até ao momento. Para permitir a comunicação do sistema com agentes, esta
interface funciona como um representante (“proxy”). Este representante traduz os pedidos dos
agentes e encaminha-os para os componentes responsáveis. As respostas dos componentes são
depois traduzidas pelo representante e encaminhadas para os agentes.

O representante define vários protocolos de comunicação para determinar os pedidos que

podem ser feitos ao sistema. Este representante também tem de implementar a interface de
envio de eventos para possibilitar o envio de eventos de contexto para agentes. Uma descrição
mais detalhada desta interface pode ser consultada na secção 5.06 do Anexo V.

72
 A interface web funciona de forma semelhante à interface de agentes. As funcionalidades
do sistema são representadas por vários serviços. Estes encontram-se descritos em OWL-S e
são inscritos numa directoria de serviços.

Cada um destes serviços, representando uma ou várias funcionalidades, serve como

tradutor dos pedidos SOAP (“Simple Object Access Protocol”) efectuados pelas aplicações.
Depois de traduzidos para a linguagem interna do sistema, estes são tratados como pedidos
efectuados através das interfaces JINI. A resposta do sistema é novamente traduzida pelo
mesmo serviço e enviada para a aplicação.

5.3.5 Problemas encontrados no desenvolvimento

Durante a fase de desenvolvimento do GCMAS surgiram alguns problemas que não tinham
sido previstos na fase de desenho. A maioria destes estava relacionada com as ferramentas
usadas no desenvolvimento do sistema. A integração das ferramentas de gestão de
componentes e de manipulação de ontologias foram os estágios que mais problemas
trouxeram.

Na fase de integração do sistema de gestão de componentes foi decidido em primeiro lugar

usar-se a ferramenta XSP como gestora de componentes. Esta ferramenta foi desenvolvida
pela ADETTI em parceria com a Accedo e é usada como base nos restantes serviços do
projecto. Isto tornava a sua utilização prioritária.

No entanto a sua utilidade para o GCMAS era limitada. A ferramenta XSP não permite a
introdução de características de componentes no seu serviço de páginas amarelas. Esta
característica é necessária para que se possa diferenciar várias instâncias de sensores do
mesmo tipo.

Não sendo possível ultrapassar esta limitação usou-se a ferramenta JINI para gestão de
componentes. Sendo todos os componentes desenvolvidos em Java e sendo esta a ferramenta
mais utilizada para gestão de componentes no Java, esta foi a escolha mais acertada. O JINI
permite a introdução de diversas características do componente no serviço de páginas
amarelas, sendo estas relevantes na pesquisa dos componentes.

O JINI está limitado a componentes desenvolvidos na linguagem de programação JAVA.

Esta limitação pode também trazer alguns entraves em futuras actualizações do sistema.
Trata-se no entanto da ferramenta mais adequada para o desenvolvimento no momento, visto
que toda a implementação será feita em Java.

73
 Outra das limitações impostas pelo JINI encontra-se nas variáveis existentes nos
componentes. Estas terão de ser serializáveis para que o componente funcione. Isto implica
que estes objectos assim como os elementos que os compõem terão de estender a interface
serializable.

Esta limitação veio colocar alguns entraves na fase de integração de ontologias. A

integração foi efectuada usando a ferramenta mais conhecida para este efeito, o JENA. Esta
ferramenta permite ao sistema aceder a ontologias descritas em linguagens de descrição de
ontologias tais como o OWL. Esta foi a linguagem decidida para a descrição das ontologias
no sistema.

A interacção com o JENA faz-se no controlador de ontologias presente no núcleo do

sistema. Este controlador apresenta-se aos restantes elementos através da sua interface, tal
como ocorreria com um outro componente JINI. No entanto esta interface não pode ser
implementada por um componente JINI pois os mecanismos de integração de ontologias do
JENA possuem variáveis que não são serializáveis.

A tradução da ontologia descrita em OWL para objectos é feita pelo JENA através de
objectos que representam classes, propriedades e individuais da ontologia. Estes objectos têm
de ser obrigatoriamente variáveis do controlador de ontologias. Se estes objectos fossem
serializáveis, os mecanismos de ontologias seriam facilmente integrados num componente.
Bastaria aos restantes componentes do sistema aceder aos métodos disponibilizados por este
para realizar operações sobre a ontologia.

No entanto, como os objectos de adaptação de ontologia do JENA não entendem a

interface serializable, as operações sobre ontologias são feitas por processos separados. Esta
acção permitiu a introdução das ontologias no sistema tornando-a no entanto mais complexa.
As operações sobre a ontologia são efectuadas de forma separada. A única interligação entre
estas é efectuada na base de dados do sistema. É nesta base de dados que é guardada a
ontologia do sistema.

Isto implica que, por cada operação sobre a ontologia, a base de dados tem de ser carregada
no método para que depois se possa manipular a informação da ontologia. Depois de
manipulada a informação, a ligação do método à base de dados tem de ser fechada para que
outros métodos lhe possam aceder.

O problema da serialização do JINI só foi detectado depois de implementados os primeiros

mecanismos de integração de ontologias. O processo de compatibilização das duas

74
ferramentas tornou-se moroso devido ao acesso à base de dados feito pelo JENA. Este acesso
implica que ligações à base de dados sejam criadas e eliminadas por cada operação sobre a
ontologia.

Este foi o processo mais eficaz encontrado para contornar o facto de o objecto responsável
pela ligação não ser serializável, não permitindo o lançamento de um componente JINI que se
responsabilizasse pela manutenção da ligação. Apesar da complexidade das operações,
usando esta metodologia consegue-se poupar recursos do sistema relativos à manutenção de
uma ligação constante à base de dados.

O uso de outros sistemas de gestão de componentes padecia de problemas semelhantes aos

encontrados no JINI. Para além desse aspecto, o uso de duas ferramentas de gestão de
componentes no sistema implicaria que todos os componentes tivessem de conhecer e saber
comunicar com ambos os mecanismos.

Conjuntamente com estes problemas foram também encontradas algumas dificuldades na

definição de uma ontologia de representação do contexto. Esta teria não só de definir o que
era o contexto numa linguagem de descrição lógica, como também converter esta descrição
lógica numa descrição orientada para objectos. Isto torna possível uma transição mais directa
da ontologia para as aplicações. Esta transição é útil não só para o sistema como para as
aplicações que o usam pois não necessitam de ferramentas complexas para lidar com a
informação devolvida.

As linguagens de definição de ontologias definem apenas a estrutura da informação de um

determinado sistema. As linguagens de ontologia usam a descrição lógica para indicar como
se relaciona a informação tratada num determinado sistema.

Tentar descrever uma estrutura de dados como um objecto com argumentos e funções
usando uma linguagem de ontologia como o OWL é complexo. O uso de propriedades para
ligar a classe que representa o objecto às classes que representam os atributos implica o uso
de todas as funcionalidades do OWL. Isto implica que a leitura de dados armazenados nessas
classes seja mais complexa.

Esta definição é no entanto muito importante para as aplicações. Sem a definição do tipo
de dados da informação, as aplicações não saberão qual o formato da informação que estão a
receber do sistema. Para tal, a ontologia foi dividida em três níveis em que, no terceiro nível,
é especificado o tipo da informação descrita no sistema.

75
 Esta descrição do tipo de informação é feita numa linguagem de descrição mais tipificada
que as linguagens de ontologia. A linguagem usada, o XMLSchema, permite definir tipos de
dados complexos tal como se definem classes em linguagens orientadas para objectos.

Esta representação, em conjunto com ferramentas presentes no XSP, permite a geração

automática de objectos que representem estas classes. Estes objectos representam o tipo de
dados das classes apresentadas na ontologia.

Serão instâncias destes objectos que são retornadas pelo sistema, quando aplicações fazem
pedidos de pesquisa de contexto ou de subscrição de eventos. São também estes os objectos
enviados pelas aplicações ao sistema quando se realiza o armazenamento de informação de
contexto.

Para representar as classes mais genéricas da ontologia, foram criados objectos

representativos. Estes representam entidades, elementos de contexto e ligações tanto entre
entidades como entre elementos e entidades. Cada elemento de contexto é depois
caracterizado por um objecto definido em XMLSchema (e.g., o elemento “Localização” é
caracterizado pelo objecto “LocationXY”).

Os problemas encontrados durante a fase de desenvolvimento do GCMAS levaram a que o

seu desenvolvimento fosse atrasado. Isto implicou que a terceira fase de desenvolvimento não
fosse implementada na sua totalidade. No entanto, as noções acerca da finalização desta fase
de desenvolvimento e da quarta fase de desenvolvimento encontram-se descritos na secção
5.3.4.

76
 Capítulo 6. Avaliação do Sistema

Definido e Implementado

Neste capítulo são descritos os critérios de avaliação definidos para avaliar o GCMAS.
Estes critérios estabelecem quais os parâmetros testados e medidos no sistema desenvolvido
para que se possa determinar se este atingiu ou não os resultados esperados.

Os critérios definidos tanto podem determinar acções específicas que o sistema tem de
efectuar como conceitos que devem estar demonstrados no sistema. A avaliação das acções do
sistema será feita usando um conjunto de teste onde essas acções são desencadeadas. O
sistema tem de reagir de acordo com os pedidos feitos em cada teste. A avaliação do resultado
obtido serve de parâmetro de avaliação do critério.

Os critérios de avaliação ligados a conceitos serão avaliados mediante a apresentação de

uma demonstração da aplicação desse conceito. Essa demonstração servirá de parâmetro de
avaliação relativo ao critério. A demonstração desse conceito inclui também comparações
com outras aplicações semelhantes.

O conjunto de testes usado para avaliação dos critérios está relacionado com o cenário
apresentado no Capítulo 3. Os pedidos desencadeados abrangem um grande leque dos pedidos
que as aplicações fariam ao sistema. Estes pedidos testam o funcionamento do sistema
aplicado no cenário proposto.

Nestes testes são usados sensores desenvolvidos com o propósito de testar a comunicação
entre sensores e o sistema. Estes sensores representam alguns dos sensores descritos no
cenário de aplicação do sistema.

77
 A avaliação do sistema resulta da análise dos resultados obtidos nos testes. Estes resultados
tanto podem servir para demonstrar a aplicação de conceitos como para demonstrar acções
que o sistema deve efectuar

Tratando-se o GCMAS de uma aplicação inovadora, não podem ser efectuados testes de
comparação directa com outras aplicações semelhantes. Alguns dos seus conceitos serão
comparados com aplicações que usem conceitos semelhantes. Os critérios de avaliação irão
avaliar também a inovação dos conceitos introduzidos no sistema.

Este capítulo inicia-se com a descrição dos critérios de avaliação seleccionados para
demonstrar as funcionalidades do sistema. Termina com a apresentação dos resultados da
avaliação de cada um dos critérios seleccionados.

6.1 Descrição dos critérios de avaliação

Para demonstrar o correcto funcionamento do GCMAS foram definidos quatro critérios de
avaliação. Estes critérios demonstram as funcionalidades comparativamente com outros
sistemas semelhantes, os tempos de resposta em diferentes situações de carga, e a sua
robustez relativamente a falhas de sensores.

As vantagens da aplicação do sistema desenvolvido na plataforma de agentes e noutras

situações também são focadas nos critérios. As análises finais ao GCMAS permitem
determinar os tempos de resposta e a sua robustez.

6.1.1 Comparação com outros sistemas de contexto

Este critério permite uma análise comparativa do GCMAS com outros sistemas de
contexto. Nesta análise são apontadas as várias características de cada um desses sistemas
sendo indicadas quais delas foram implementadas.

6.1.2 Funcionalidades do GCMAS

Este critério permite apontar quais as principais funcionalidades do GCMAS. Nesta análise
são demonstrados quais os requisitos implementados e planeados para o sistema.

6.1.3 Avaliação do funcionamento e dos tempos de resposta do sistema

Este critério permite avaliar o funcionamento e os tempos de resposta do GCMAS em
diferentes situações de carga. Estes testes servem para verificar o funcionamento do sistema
nos diferentes ambientes onde este pode ser aplicado.

78
 6.1.4 Robustez
Este critério permite determinar se o sistema é robusto relativamente à falha de sensores e
componentes internos. Esta robustez garante o funcionamento do sistema mesmo nas piores
condições. A robustez é um critério que pode ser avaliado com descrições da arquitectura do
sistema.

6.2 Avaliação dos critérios

A avaliação dos critérios permite mostrar por intermédio de demonstrações que o sistema
desenvolvido satisfaz os critérios definidos. Esta demonstração tanto pode ser do
comportamento do sistema como uma apresentação de conceitos implementados no mesmo.

Os resultados são analisados independentemente para cada um dos critérios. Alguns destes
podem ser suportados por demonstrações do funcionamento do sistema.

6.2.1 Comparação com outros sistemas de contexto

A comparação do GCMAS com outros sistemas de contexto é feita recorrendo a uma
tabela comparativa. As características a ter em conta na comparação são a abrangência,
arquitectura usada, descrição do contexto, interfaces, modularidade e reutilização do
sistema.

A abrangência de um sistema permite determinar em que circunstâncias um sistema pode

ser utilizado. A análise da arquitectura permite determinar qual dos modelos de arquitectura é
aplicado na concepção de um sistema (ver Capítulo 2). Uma descrição detalhada das
vantagens destas arquitecturas pode ser consultada no Anexo VIII.

A descrição do contexto permite determinar o método usado para descrever a informação

de contexto trocada num sistema. As interfaces permitem determinar com que tipos de
aplicações um sistema pode comunicar.

A modularidade permite determinar até que ponto o conceito de captura da informação de

contexto está separado do conceito de tratamento de dados no desenho de um sistema. A
reutilização permite determinar até que ponto a estrutura do sistema é suficientemente
genérica para permitir a sua reutilização noutras situações.

Os sistemas e modelos escolhidos para serem comparados são o CoBrA [Chen et al 2003],
o Context Taylor [Davis et al 2003, Davis et al 2003a], o modelo de arquitectura de Cortese
e seus colaboradores [Cortese et al 2004], o sistema de localização dentro de casa [Harter et

79
al 2002], o SOCAM [Gu et al 2004], o CORTEX [Biegel and Cahill 2004] e o modelo de
Widgets de Dey e seus colaboradores [Dey et al 2001].

Estes são os sistemas e arquitecturas que mais se aproximam do sistema desenvolvido. As

suas características encontram-se descritas em maior pormenor no Anexo VIII. Na Tabela 4
encontra-se o quadro comparativo destes sistemas.

Tabela 4 – Comparação de funcionalidades com outros sistemas e arquitecturas

Característica Arquitectura Descrição

Usado apenas para aplicações com agentes. Permite
CoBrA
diversidade de utilizações no campo dos agentes.
Context Utilização está dependente das fontes geradoras de
Taylor contexto.
Modelo de Está dependente dos protocolos de utilizados para
Cortese comunicação com os sensores
Limitado a sensores de localização. É uma aplicação
Sistema de
que se limita à determinação da localização de
localização
pessoas no interior da casa. São usados sensores
dentro de
Abrangência específicos da aplicação que determinam a sua
casa (DC)
posição por triangulação.
Limitado aos adaptadores de sensor desenvolvidos
SOCAM
para a aplicação
Limitado aos adaptadores de sensor desenvolvidos
CORTEX
para a aplicação
Limitado aos adaptadores de sensor desenvolvidos
Widgets
para a aplicação
Limitado aos adaptadores de sensor desenvolvidos
para a aplicação. Podem ser desenvolvidos novos
GCMAS
adaptadores com auxílio das ferramentas
disponibilizadas pelo sistema
Arquitectura Arquitectura baseada em agentes com um
CoBrA controlador central. Pode-se dizer que se aproxima
do modelo de serviços de rede.
Context Modelo de componentes com um repositório
Taylor centralizado
Modelo de Modelo baseado em camadas com um repositório
Cortese centralizado
Usa uma arquitectura especializada onde sensores se
Sistema de
ligam a um componente centralizado que calcula a
localização
sua posição. Pode ser considerado como um modelo
DC
de componentes.
SOCAM Modelo de serviços de rede
CORTEX Modelo de serviços de rede
Modelo de componentes com um serviço de páginas
Widgets
amarelas simplificado

80
 Usa um misto de modelo de camada intermédia com
o modelo de componentes. Os componentes de
adaptação de sensor encontram-se encapsulados em
componentes que são executados na mesma máquina
que o sensor e comunicam com a camada do sistema
de contexto. Do lado das aplicações, o sistema
GCMAS comporta-se como uma camada intermédia entre os
sensores e a aplicação.
Com o uso das interfaces do sistema é possível
ligá-lo a sistemas de agentes, e fazer com que este se
comporte como um serviço Web.

Usa ontologias para descrever a informação de

CoBrA contexto. Permite uma maior flexibilidade na
descrição de novas informações.
Usa uma estrutura própria para descrever a
Context
informação de contexto. Implica que a integração de
Taylor
outros tipos de informação seja mais complexa.
Usa ontologias para descrever a informação de
Modelo de
contexto. Permite uma maior flexibilidade na
Cortese
descrição de novas informações.
Como é usado um único tipo informação de contexto
Sistema de a sua descrição não se torna necessária. A aplicação
localização limita-se a receber os pedidos dos sensores que estão
DC ligados directamente em rede ao sistema. É um
Descrição do exemplo limitativo de descrição de contexto.
contexto Usa ontologias para descrever a informação de
SOCAM contexto. Permite uma maior flexibilidade na
descrição de novas informações.
Usa ontologias para descrever a informação de
CORTEX contexto. Permite uma maior flexibilidade na
descrição de novas informações.
Usa uma estrutura própria para descrever a
Widgets informação de contexto. Implica que a integração de
outros tipos de informação seja mais complexa.
Usa ontologias com vários níveis para descrever a
informação de contexto. Permite não só uma maior
flexibilidade na descrição de novas informações
GCMAS
como uma forma fácil de introduzir novas
informações de contexto no sistema sem necessitar
de reiniciar este.
Interfaces Limitado a comunicação com a plataforma de
CoBrA
agentes
Context Limitado á comunicação com aplicações desenhadas
Taylor especificamente para a aplicação
Modelo de Limitado á comunicação com aplicações desenhadas
Cortese especificamente para a aplicação
Sist, de loc,
Trata-se de uma aplicação fechada
DC

81
 Limitado á comunicação com aplicações desenhadas
SOCAM
especificamente para a aplicação
Limitado á comunicação com aplicações desenhadas
CORTEX
especificamente para a aplicação
Limitado á comunicação com aplicações desenhadas
Widgets
especificamente para a aplicação
Possui um conjunto de interfaces extensível que
permite a comunicação com vários tipos de
aplicações usando protocolos de plataformas de
GCMAS
gestão de componentes, assim como permite
também a comunicação com agentes e por meio de
serviços web.
Permite que as aplicações possam focar-se no
CoBrA tratamento das informações recebidas. O sistema
pode ser considerado como um módulo.
Permite que as aplicações possam focar-se no
Context
tratamento das informações recebidas. O sistema
Taylor
pode ser considerado como um módulo.
Permite que as aplicações possam focar-se no
Modelo de
tratamento das informações recebidas. O sistema
Cortese
pode ser considerado como um módulo.
Sistema de
localização Trata-se de uma aplicação fechada
DC
Modularidade Permite que as aplicações possam focar-se no
SOCAM tratamento das informações recebidas. O sistema
pode ser considerado como um módulo.
Permite que as aplicações possam focar-se no
CORTEX tratamento das informações recebidas. O sistema
pode ser considerado como um módulo.
Permite que as aplicações possam focar-se no
tratamento das informações recebidas. As aplicações
Widgets
têm de ser desenvolvidas sobre o sistema.
Modularidade não é muito visível.
Permite que as aplicações possam focar-se no
tratamento das informações recebidas. O sistema
GCMAS pode ser considerado como um módulo. Permite a
adição de outros módulos para aumentar o nível de
abstracção da informação de contexto.
Reutilização CoBrA Limitado a plataformas de agentes
Context Limitado ao tipo de sensores desenhado
Taylor especificamente para a aplicação
Modelo de Limitado ao tipo de sensores desenhado
Cortese especificamente para a aplicação
Sistema de
localização Trata-se de uma aplicação fechada
DC
Limitado ao tipo de sensores desenhado
SOCAM
especificamente para a aplicação

82
 Limitado ao tipo de sensores desenhado
CORTEX
especificamente para a aplicação
Limitado ao tipo de sensores desenhado
Widgets especificamente para a aplicação. Permite no entanto
uma grande flexibilidade na concepção dos sensores.
Limitado ao tipo de sensores desenhado
especificamente para a aplicação. Permite no entanto
uma grande flexibilidade na concepção dos sensores.
GCMAS
Possui também mecanismos que facilitam o
desenvolvimento de sensores especificamente para o
sistema.

Das informações apresentadas na Tabela 4 conclui-se que o GCMAS possui características

que igualam e em muitos casos superam características de outros sistemas semelhantes. De
acordo com os resultados da Tabela 4 considera-se que este critério foi satisfeito

6.2.2 Funcionalidades do GCMAS

A apresentação das funcionalidades planeadas para o GCMAS recorre a uma tabela onde
são descritos sumariamente cada uma destas. Estas encontram-se descritas em maior
pormenor no Capítulo 5. Cada uma destas funcionalidades é implementada em um ou mais
componentes do sistema.

Juntamente com a descrição sumária das funcionalidades encontra-se também a

informação do seu estado, se foi planeada, desenhada ou implementada. Mediante a
proporção de funcionalidades planeadas, desenhadas e implementadas este critério será
considerado como satisfeito ou não satisfeito.

As funcionalidades apresentadas são a adaptação de sensores, incorporação de

informação dada pela aplicação cliente do GCMAS, o registo de histórico, a estrutura do
contexto, a extensão do sistema, a possibilidade de pesquisa de contexto, a possibilidade
lidar com de eventos de contexto, interfaces de aplicação, interface de agentes, interface
web e inferência de contexto.

De acordo com os resultados descritos na Tabela 5 verifica-se que das onze

funcionalidades descritas seis encontram-se implementadas, uma parcialmente implementada,
três ficaram pela fase de desenho e apenas uma ficou pela fase de planeamento. Considerando
que mais de metade das funcionalidades foram implementadas e das restantes apenas uma
ficou pelo planeamento considera-se que este critério foi satisfeito.

83
 Tabela 5 – Funcionalidades do sistema desenvolvido

Funcionalidade Descrição Estado

Ferramentas que permitem adaptar qualquer tipo de
Adaptação de sensor ao sistema. Convertem a informação adquirida
Implementada
sensores do sensor para uma estrutura definida pela ontologia do
sistema.
Inclusão de informação de contexto no sistema por parte
de aplicações. O sistema define uma interface que
Informação dada
armazena informação fornecida pelas aplicações num Implementada
pela aplicação
repositório. Esta informação é depois disponibilizada
como informação de contexto
Permite armazenar amostras de contexto relativas a
vários momentos anteriores ao momento actual. Essa
Registo de informação é disponibilizada às aplicações que as Parcialmente
histórico requeiram. Esta funcionalidade está parcialmente implementada
implementada para informação sensorial mas não para
informação armazenada no repositório do sistema.
O GCMAS define uma estrutura para a informação de
contexto sob a forma de ontologias. Estas estão
Estrutura do
estruturadas de maneira a poderem ser actualizadas e Implementada
contexto
alteradas sempre que necessário sem ter que recompilar
o sistema.
A ontologia que define a informação de contexto
Extensão do
permite ser estendida sem que seja necessário Implementada
sistema
recompilar nem reiniciar o sistema.
Pesquisa de Permite que sejam efectuadas pesquisas de informação
Implementada
contexto de contexto.
Permite que o sistema responda a eventos de contexto
Eventos de mediante a subscrição por parte das aplicações que
Desenhada
contexto queiram receber informação sobre os eventos subscritos
sem terem de efectuar pesquisas explícitas.
Permite que aplicações usando protocolos de
Interfaces de comunicação das plataformas de gestão de
Implementada
aplicação componentes, tais como o JINI e o XSP, comuniquem
com o GCMAS.
Permite que aplicações baseadas em agentes possam
Interface de
comunicar com o GCMAS, usando uma linguagem e Desenhada
agentes
protocolos de comunicação de agentes.
Permite que aplicações baseadas em serviços web
Interface Web Desenhada
possam comunicar com o sistema
Permite que o GCMAS possua métodos para aumentar
Inferência de
o nível de abstracção da informação de contexto Planeada
contexto
recolhida dos sensores
Os resultados da Tabela 5 demonstram que este critério de avaliação é satisfeito pelo
sistema.

84
 6.2.3 Avaliação do funcionamento e dos tempos de resposta do sistema
Relativamente a este critério são apresentados os resultados dos testes efectuados ao
sistema. Estes testes foram efectuados através de uma aplicação desenvolvida especificamente
para testar as funcionalidades do GCMAS. A aplicação foi desenvolvida com base no cenário
escolhido para o desenvolvimento da tese. Detalhes dos testes ao sistema podem ser
consultados no Anexo IX. Detalhes da arquitectura podem ser consultados no Capítulo 5.

Os primeiros testes realizados demonstram o funcionamento do GCMAS. Foram testadas a

capacidade de pesquisa de informação de contexto, a capacidade de diversificação da
informação de contexto, a diversidade de ligações ao sistema, o armazenamento de
histórico de contexto, a pesquisa por propriedades de sensor e a capacidade de
actualização da ontologia do sistema. Os resultados destes testes são apresentados na Tabela
6.

Tabela 6 – Demonstração do funcionamento do sistema

Teste Resultado
O sistema foi capaz de pesquisar contexto dada a informação da
Pesquisa de
classe da informação de contexto e do identificador do objecto.
informação de
Foram testadas pesquisas sobre dados do utilizador e a sua
contexto
localização.
Diversificação da O sistema foi capaz de realizar pesquisas sobre vários tipos de
informação de informação com diferentes formatos. Foram testadas pesquisas
contexto sobre localização, informação de bateria e lista de espera
Foram feitos pedidos ao sistema, usando várias interfaces, sendo
Diversidade de obtida a mesma informação. Foram testadas pesquisas sobre dados
ligações pessoais e localização de um utilizador usando as interfaces JINI e
XSP
O sistema foi capaz de armazenar um número pré determinado de
amostras de contexto de vários tipos de sensores. Posteriores
Armazenamento
pesquisas sobre essas amostras demonstraram a disponibilidade
de histórico
dessa informação. Foram realizados testes sobre sensores de
localização, informação de bateria e de lista de espera.
O sistema foi capaz de distinguir dois sensores da mesma classe
Pesquisa por
relacionados com utilizadores diferentes. Foram testadas pesquisas
propriedades de
sobre a localização de dois utilizadores que usam a mesma classe
sensor
de sensores de localização.
O sistema foi capaz de efectuar uma pesquisa sobre uma classe de
Actualização da sensores que não estava descrita na ontologia carregada durante o
ontologia arranque do sistema. A nova classe da ontologia foi carregada
posteriormente quando se inscreveu um novo sensor no sistema.
De acordo com os dados da Tabela 6 prova-se que o sistema cumpre os requisitos
estipulados no Capítulo 3. Explicações mais detalhadas dos testes efectuados encontram-se
nas secções 9.01 a 9.06 do Anexo IX.

85
 Os testes seguintes determinam o tempo que o sistema leva a disponibilizar a informação
de contexto após a inscrição de um novo sensor ou de informação no repositório. Na Tabela 7
estão apresentados os resultados obtidos no teste de determinação do tempo de resposta.

Nesta tabela encontram-se discriminados os tempos de registo e obtenção de informação

contados em milissegundos desde o arranque da aplicação. Para evitar o assincronismo entre
várias máquinas, as aplicações necessárias ao teste correram na mesma máquina. A descrição
completa dos testes pode ser visualizada na secção 9.07 do Anexo IX.

Como se pode verificar pelos resultados obtidos, a diferença entre os tempos de registo do
sensor ou o armazenamento de informação no repositório e o instante em que a nova
informação (proveniente do sensor ou do repositório) é obtida por parte da aplicação que a
consulta é da ordem dos 1,2 segundos para sensores, chegando aos 40 milissegundos no caso
da informação registada no repositório.

Tabela 7 – Tempos de acesso ao sistema

Observações Tempo (ms)

Sensor de localização registado no GCMAS 117886

Informação da pesquisa de sensor obtida 119158

Informação de dados do utilizador armazenada 130194

Informação da pesquisa aos dados do utilizador obtida 130234

A diferenciação entre o tempo de obtenção de informação nos sensores e o tempo de

obtenção da informação no repositório deve-se em parte ao tempo de registo do adaptador de
sensor no serviço de páginas amarelas do JINI. Outro dos aspectos que pode contribuir para o
aumento do tempo de resposta é o facto de a aplicação que faz as pesquisas ser cíclica.

O tempo de aquisição é óptimo apenas se, no momento em que a informação é

disponibilizada no sistema, a aplicação de pesquisa estiver no início do seu ciclo. Caso a
aplicação não esteja no início do seu ciclo de pesquisa, o tempo de aquisição da informação é
um pouco mais longo.

Uma variação da mesma aplicação foi usada para determinar os valores mostrados na
Tabela 8. Esta tabela apresenta os tempos de resposta do sistema em diferentes situações de
carga dependendo do número de sensores.

86
 Dos resultados obtidos verifica-se que quanto maior for o número de sensores ligados mais
tempo se demora a fazer uma pesquisa. No entanto a ocupação de processador não aumenta
muito com o aumento do número de sensores ligados. Nem sequer a ocupação de memória do
processo do GCMAS aumenta significativamente com o registo de novos sensores.

Tabela 8 – Tempos de resposta do sistema

Tempo de Tempo de pesquisa Ocupação média

Nº de sensores
pesquisa com histórico do processador
1 1,2 s 1,3 s aprox. 10 %
10 10,4 s 15,5 s aprox. 12 %
20 25,6 s 30,8 s aprox. 15 %
O atraso na resposta do sistema deve-se sim à ocupação de memória dos processos que
representam os sensores. Por cada novo sensor lançado cerca de 18 kilobytes de memória são
reservados para o processo.

Este motivo leva a que os resultados destes testes não sejam fidedignos pois, para
relatarem o funcionamento do sistema, cada um dos sensores teria de correr numa máquina à
parte. O sistema tem de correr numa máquina distinta da máquina em que os sensores estão
instalados.

Mesmo sem a separação do GCMAS em relação ao resto, os resultados podem ser

considerados aceitáveis pois os atrasos causados pela rede são muitas das vezes maiores do
que o valor máximo obtido. Como o sistema funciona em rede, a maior preocupação com
atrasos será devido ao tráfego e não a problemas de processamento da informação.

Mais informações relativas ao teste dos tempos de resposta podem ser encontradas na
secção 9.08 do Anexo IX. De acordo com os resultados apresentados, considera-se que este
critério foi satisfeito.

6.2.4 Robustez
A robustez do GCMAS é garantida pela existência de múltiplas instâncias dos
componentes internos do sistema e pela separação das suas várias funcionalidades. A robustez
relativa à falha de sensores é garantida pelos mecanismos de protecção do serviço de páginas
amarelas do JINI e do componente responsável pelas pesquisas.

Tendo sido definido como um sistema orientado por componentes, o GCMAS permite que
várias instâncias do mesmo componente sejam lançadas simultaneamente, podendo estas até
correr em máquinas diferentes. Isto permite introduzir redundância no sistema. Ao existirem

87
componentes redundantes a probabilidade de falha de uma funcionalidade é muito baixa visto
que estes se podem substituir.

Esta substituição pode ou não ser linear. Caso as várias instâncias do mesmo componente
sejam lançadas com as mesmas propriedades apenas a primeira instância a ser lançada seria
usada. Isto porque os mecanismos normais de pesquisa do serviço de páginas amarelas JINI
devolvem sempre a primeira instância dos componentes registados com o mesmo nome.

Um mecanismo mais complexo de pesquisa de componentes teria de ser implementado

para que se possam utilizar os restantes componentes. Uma forma mais fácil de aceder a estes
componentes é registando-os com propriedades diferentes. O mecanismo usado no sistema
define uma propriedade denominada número de componente que possui valores sequenciais
para cada instância do mesmo componente que seja lançada.

O mecanismo definido permite assim a existência de componentes alternativos que podem

ser lançados em diferentes máquinas expandindo o sistema para vários locais. Esta expansão é
possível desde que os componentes se registem no mesmo serviço de páginas amarelas.

Esta propriedade não só introduz redundância como também permite o acesso múltiplo. As
únicas partes centralizadas desta arquitectura são o serviço de páginas amarelas e a base de
dados que representa o repositório do sistema.

Outro aspecto relativo à robustez da falha de componentes internos é o facto de as

funcionalidades do sistema terem alguma independência umas das outras. Os únicos
componentes necessários para o funcionamento de mais do que uma funcionalidade são os
adaptadores de sensor e o mecanismo de gestão de ontologias.

Os componentes directamente responsáveis por implementar as interfaces externas do

sistema são independentes entre si. Isto não implica entretanto que alguns destes componentes
precisem de utilizar algumas funcionalidades do outro, como acontece com o componente de
pesquisa. Este precisa de aceder ao componente de repositório para efectuar pesquisas sobre o
contexto lá guardado.

No entanto, caso o componente de repositório não esteja a funcionar pode-se continuar a

efectuar pesquisas sobre sensores. As pesquisas efectuadas sobre informação de repositório
resultariam no envio de mensagens de indisponibilidade às aplicações que as requeressem.

Também os vários tipos de interfaces externas do sistema para pesquisa armazenamento e

subscrição de eventos são independentes uns dos outros. Cada uma destas interfaces recorre a

88
funcionalidades específicas para cada tipo de interface dentro do componente que podem
falhar sem comprometer as restantes interfaces.

Relativamente à robustez em relação a falhas de sensores o componente de pesquisa do

GCMAS permite a gestão de excepções lançadas por acessos a sensores não existentes. O
mecanismo de pesquisa no serviço de páginas amarelas usado pelo componente de pesquisa
possui também mecanismos de protecção contra pesquisas a sensores não registados no
sistema ou cujo registo tenha sido removido.

A robustez do sistema é assim justificada com os mecanismos descritos nesta secção. O

GCMAS permite garantir a estabilidade e fiabilidade necessárias para um funcionamento
constante requerido para este tipo de aplicações.

89
 Capítulo 7. Conclusões
Conclusões e Trabalho

Futuro

O avanço da tecnologia sensorial e a necessidade constante de informação vinda do

exterior são factores que motivam o avanço da computação ciente do contexto. Tratando-se de
uma área que está na sua fase inicial de desenvolvimento, não existe ainda uma base
tecnológica estável de onde se possam desenvolver aplicações cientes do contexto.

Da avaliação do estado actual do conhecimento verifica-se que existem varias soluções

para resolver determinados aspectos da problemática do contexto. Estas soluções foram
entretanto desenvolvidas especificamente para um conjunto de situações particulares. Não foi
ainda definida uma estrutura mais generalizada para a resolução da problemática do contexto.

Da análise dos requisitos concluiu-se que o sistema desenvolvido teria de reunir algumas
das soluções mais proeminentes na tentativa de encontrar uma solução única que abrangesse
uma grande parte da problemática do contexto. Esta solução teria de ser também independente
do domínio e adaptável à situação em que fosse aplicada.

Definido um cenário de aplicação do sistema, foi possível desenhá-lo de maneira a que este
não só respondesse ao cenário determinado, como também fosse extensível a outros cenários.
Do desenho foram determinados os componentes a serem desenvolvidos e as possibilidades
de futuras extensões. Foi também definido um mecanismo de módulos que permite
acrescentar funcionalidades de alto nível ao sistema.

Após a implementação dos componentes seleccionados, a funcionalidade do sistema foi

testada de acordo com critérios de avaliação bem definidos. Conclui-se que o sistema
desenvolvido apresenta uma solução de qualidade para a computação ciente do contexto
relativamente a outros sistemas semelhantes. Em aspectos de abrangência, escalabilidade,

90
independência do domínio, e possibilidade de se estender / adaptar, o sistema desenvolvido
supera os restantes sistemas analisados.

Os resultados da avaliação provaram também que em situações de grande carga o sistema

mantém-se estável, e que mesmo em caso de falha de componentes internos, apenas as
funcionalidades desses componentes são afectadas. Prova-se assim a fiabilidade, rapidez e
robustez do sistema.

Embora o sistema tenha sido desenhado na sua totalidade, apenas parte deste chegou a ser
implementado até ao momento da conclusão da tese. Isto significa que algumas das
funcionalidades descritas na análise de requisitos não foram implementadas, devido à grande
complexidade de cada uma delas.

Como trabalho futuro a realizar sobre o sistema tem-se a conclusão de funcionalidades

como o interface de tipo serviço Web e interface de agentes, toda a parte relacionada com a
subscrição de eventos e a finalização da funcionalidade de armazenamento de histórico de
contexto com a possibilidade de armazenamento de histórico no repositório.

Com a conclusão destas funcionalidades ter-se-á completado toda a camada de adaptação

de contexto do sistema desenvolvido. Isto permitirá que se cumpram todos os objectivos
básicos definidos durante a fase de análise.

Objectivos adicionais determinam que o sistema deve possibilitar também a subida do

nível de abstracção da informação de contexto disponível e a realização de inferência com a
informação de contexto. Dado que o raciocínio e o aumento do nível de abstracção envolvem
conceitos e conhecimento mais ligados a domínios específicos, estes mecanismos estarão
concentrados em módulos implementados ao mesmo nível que as aplicações que vão usar o
sistema.

Estes módulos acrescentarão ao sistema a possibilidade de trabalhar sobre a informação de

contexto adquirida, aumentando-lhe o seu nível de abstracção para algo mais próximo do
nível de abstracção das aplicações. Por requererem o uso de mecanismos sofisticados de
inferência sobre o contexto, estes só foram referidos superficialmente no planeamento do
sistema (ver Capítulo 3).

O seu desenho e implementação irão requerer um esforço idêntico àquele que foi requerido
para desenvolver a camada de adaptação do sistema. Com a finalização destes objectivos, o
sistema desenvolvido tornar-se-á uma ferramenta essencial para a computação ciente do
contexto.

91
 Capítulo 8. Referências Bibliográficas

[Anagnostopoulos et al 2004] C. Anagnostopoulos, A. Tsounis, S. Hadjiefthymiades.

“Context Awareness in Mobile Computing Environments: A Survey”. In Mobile e-
conference 2004, Information Society Technologies, 2004

[Bardram et al 2003] J. E. Bardram, R. E. Kjær, and M. Pedersen. “Context-Aware User

Authentication – Supporting Proximity-Based Login in Pervasive Computing”. In A.
Dey, J. McCarthy, and A. Schmidt, editors, Proceedings of Ubicomp 2003: Ubiquitous
Computing, volume 2864 of Lecture Notes in Computer Science, pages 107–123,
Seattle, Washington, USA, Oct 2003.

[Bardram 2004] J. E. Bardram. “The Java Context Awareness Framework (JCAF) A Service
Infrastructure and Programming Framework for Context-Aware Applications”. Centre
for pervasive computing, Department of Computer Science. University of Aarhus, 2004

[Bardram 2004a] J. E. Bardram. “Applications of Context Aware Computing in Hospital

Work – Examples and Design Principles”. In ACM Symposium on Applied Computing
(ACM SAC2004). ACM Press, 2004.

[Biegel and Cahill 2004] Gregory Biegel, Vinny Cahill. “A Framework for Developing
Mobile, Context-aware Applications”. In Proceedings of 2nd IEEE conference on
Pervasive computing and Communications. Percom 2004

[Capra et al 2001] L. Capra, W. Emmerich and C. Mascolo. “Reflective Middleware

Solutions for Context-Aware Applications”. In A. Yonezawa and S. Matsuoka (eds),
Metalevel Architectures and Separation of Crosscutting Concerns - Proc. of Reflection
2001, Kyoto, Japan. Lecture Notes in Computer Science. Vol. 2192. pp. 126-133, 2001

92
[Capra et al 2003] L. Capra, W. Emmerich and C. Mascolo. “CARISMA: Context-Aware
Reflective middleware System for Mobile Applications”. In IEEE Transactions on
Software Engineering, 29(10):929-945, 2003

[Chalmers e Sloman 1999] D. Chalmers, M. Sloman. “QoS and Context Awareness for
Mobile Computing”. In HUC99, 1999

[Chen e Kotz 2000] G. Chen and D. Kotz. „A Survey of Context-Aware Mobile Computing
Research”. In Dartmouth Computer Science Technical Report TR2000-381, 2000.

[Chen e Kotz 2001] G. Chen and D. Kotz. “Solar: Towards a Flexible and Scalable Data-
Fusion Infrastructure for Ubiquitous Computing”. In UbiTools Workshop at
UbiComp2001, Atlanta, Georgia, October, 2001.

[Chen e Kotz 2002] G. Chen and D. Kotz. “Solar: An Open Platform for Context-Aware
Mobile Applications”. In the First International Conference on Pervasive Computing
(Pervasive 2002), Switzerland, June, 2002.

[Chen et al 2003] H. Chen, T. Finin, and A. Joshi. “An Intelligent Broker for Context-Aware
Systems”. In Adjunct Proceedings of Ubicomp 2003, Seattle, Washington, USA,
October 12-15, 2003.

[Christopoulou et al 2004] E. Christopoulou, C. Goumopoulos, I. Zaharakis and A. Kameas.

“An Ontology-based Conceptual Model for Composing Context-Aware Applications”.
In Research Academic Computer Technology Institute, 2004

[Cortese et al 2004] G. Cortese, M. Lunghi, F. Davide. “Context-Awareness for Physical

Service Environments”. In Ambient Intelligence, IOS press 2004

[Costa et al 2003] P. D. Costa, J. G. P. Filho and M. van Sinderen. “Architectural

Requirements for Building Context-Aware Services Platforms”. In IFIP workshop on
Next Generation Networks, Balatonfured, Hungary, 8-10 September, 2003

[Davis et al 2003] J. S.Davis II, D. M. Sow, M. Blount, and M. R. Ebling. “Context tailor:
Towards a programming model for context-aware computing”. In Proceedings of the
first International Workshop on Middleware for Pervasive and Ad Hoc Computing
(MPAC)., pages 68-75, Rio De Janeiro, Brazil, 16-20 June 2003.

[Davis et al 2003a] J. S. Davis, D. M. Sow, Dalton, M. R. Ebling. “Context-sensitive

Invocation Using the Context Tailor Infrastructure”. In System Support for Ubiquitous

93
 Computing Workshop at the Fifth Annual Conference on Ubiquitous Computing,
October 2003.

[Dey 1998] A. K. Dey. “Context-Aware Computing: The CyberDesk Project”. In AAAI 1998
Spring Symposium on Intelligent Environments, Technical Report SS-98-02, pp 51–54,
1998.

[Dey e Abowd 1999] A. K. Dey and G. D. Abowd. “Towards a better understanding of

context and context awareness”. In GVU Technical Report GIT-GVU-99-22, College of
Computing, Georgia Institute of Technology, 1999.

[Dey et al 2001] A. K. Dey, D. Salber, G. D Abowd. “A conceptual framework and a toolkit

for supporting the rapid prototyping of context-aware applications”. In Human
Computer Interaction, 2001

[Filho e Sinderen 2003] J.G. P. Filho, M. van Sinderen. “Web service architectures, semantics
and context-awareness issues in web services platforms”. WASP/D3.3, 16-26, 2003

[FIPA 2002-00061] Foundation for Intelligent Physical Agents. 2002. “FIPA Agent
Communication Language”. Especificação número 00061.
http://www.fipa.org/specs/fipa00026/index.html

[FIPA 2002-00008] Foundation for Intelligent Physical Agents. 2002. “FIPA Semantic
Language”. Especificação número 00008.
http://www.fipa.org/specs/fipa00037/index.html

[FIPA 2002-00026] Foundation for Intelligent Physical Agents. 2002. “FIPA Request
Interaction Protocol Specification”. Especificação número 00026.
http://www.fipa.org/specs/fipa00026/index.html

[FIPA 2002-00037] Foundation for Intelligent Physical Agents. 2002. “FIPA Communicative
Act Library Specification”. Especificação número 00037.
http://www.fipa.org/specs/fipa00037/index.html

[Gellersen et al 2002] H. W. Gellersen, A. Schmidt, and M. Beigl. “Multi-sensor Context-

Awareness in Mobile Devices and Smart Artefacts". In Journal on Mobile Networks and
Applications, 7(5), Imrich Chlamtac (Ed.), pp. 341-351, Oct. 2002.

[Gold e Mascolo 2001] R. Gold, C. Mascolo. “Use of Context-Awareness in Mobile Peer-to-

Peer Networks”. In Proc. of the 8th IEEE Workshop on Future Trends of Distributed
Computing Systems (FTDCS'2001). Bologna, Italy, October 2001.

94
[Goslar et al 2003] Kevin Goslar, Sven Burchholz, Alexander Schill, Hartmut Vogler. “A
Multidimensional approach to Context-Awareness”. In Proceedings of the 7th World
Multiconference on Systemics, Cybernetics and Informatics (SCI2003), 2003

[Gu et al 2004] Tao Gu, Xiao Hang Wang, Hung Keng Pung, Da Qing Zhang. “A Middleware
for Context-Aware Mobile Services”. IEEE Vehicular Technology Conference. Milan,
Italy, 2004

[Harter el al 2002] Andy Harter, Andy Hopper, Pete Steggles, AndyWard, Paul Webster.
“The Anatomy of a Context-Aware Application”. Wireless Networks, 8(2/3) 2002

[Henricksen et al 2002] Karen Henricksen, Jadwiga Indulska, Andry Rakotonirainy.

“Modeling Context Information in Pervasive Computing Systems”. School of
Information Technology and Electrical Engeneering, 2002

[Hong e Landay 2001] Jason I. Hong and James A. Landay. “An Infrastructure Approach to
Context-Aware Computing”. In Human-Computer Interaction, 16:287–303, 2001.

[Jacobson et al 1999] Ivar Jacobson, James Rumbaugh, Grady Booch. “The Unified Software
Development Process”. Addisson-Wesley Object Technology Series. Addison-Wesley,
1999

[Korpipää e Mäntyjärvi 2003] Panu Korpipää, Jani Mäntyjärvi. “An Ontology for
Mobile Device Sensor-Based Context Awareness”. In Fourth International and
Interdisciplinary Conference on Modeling and Using Context (CONTEXT 2003): 451-
458. Stanford, California (USA), June 23-25, 2003

[Korpipää et al 2003] Panu Korpipää, Jani Mäntyjärvi. “An Ontology for Mobile Device
Sensor-Based Context Awareness”. Proc. Context ’03, LNAI no. 2680, 2003

[Kummerfeld et al 2003] Bob Kummerfeld, Aaron Quigley, Chris Johnson, Rene Hexel.
“Merino:Towards an intelligent environment architecture for multigranularity context
description”. In User Modeling for Ubiquitous Computing, 2003

[Laamanen e Helin 2004] Heimo Laamanen, Heikki Helin. “Contex-Awareness, Overview

and State-of-Art”. CASCOM project, TeliaSonera, 2004

[Michachelles e Samulowitz 2001] Florian Michachelles, Michael Samulowitz. “Smart CAPS

for Smart Its – Context Detection for Mobile Users”. In Third International Workshop
on Human Computer Interaction with Mobile Devices (MobileHCI), Lille, France,
September 2001

95
[Möller et al 2004] Thorsten Möller, Patricia Schirmer, Heiko Schuldt, Ari Kinnunen,
Christian Stark, Raimund Vogel. “Emergency Healthcare Scenario Description”.
CASCOM project, TeliaSonera 2004

[Prekop e Burnett 2002] Paul Preko, Mark Burnett. “Activities, context and ubiquitous
computing”. In Elsevier Science PII: S0140-3664(02)00251-7, 2002

[Ritchie 2002]Martin Ritchie. “Pre & Post Processing for Service Based Context-Awareness”.
In Technical Report Equator-02-023, University of Glasgow / Department of Computing
Science, 2002.

[Rubinsztejn et al 2004] Hana K. Rubinsztejn, Markus Endler, Vagner Sacramento, Kleder

Goncalves and Fernando Nascimento. “Support for Contex-Aware Collaboration”. In
MATA 2004.

[Samulowitz et al 2001] Michael Samulowitz, Florian Michahelles, Claudia Linnhoff-Popien.

“Adaptive Interaction for Enabling Pervasive Services”. University of Munich,2001

[Schilit e Theimer 1994] B. Schilit, M. Theimer. “Disseminating Active Map Information to

Mobile Hosts”. IEEE Network, 8(5):22–32, 1994

[Schmidt et al 1998] A. Schmidt, M. Beigl, and H.W. Gellersen. "There is more to Context
than Location". In Proceedings of the International Workshop on Interactive
Applications of Mobile Computing (IMC98), Rostock, Germany, November 1998.

[Winograd 2001] Terry Winograd. “Arquitectures for Context”. In HI Journal, 2001.

[W3C 2004] World Wide Web Consortium. 2004. “OWL Features”.

http://www.w3.org/TR/owl-features/

[W3C 2004a] World Wide Web Consortium. 2004. “RDF Primer”.

http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

[W3C 2004b] World Wide Web Consortium. 2004. “XML Schema 1.1 Release”.
http://www.w3.org/XML/Schema

[W3C 2005] World Wide Web Consortium. 2005. “OWL-S 1.0 Release”.
http://www.daml.org/services/owl-s/1.0/

[Yau e Karim 2001] S. S. Yau and F. Karim, "Reconfigurable Context-Sensitive Middleware

for ADS Applications in Mobile Ad-Hoc Network Environments". In Proc. 5th IEEE
Int'l Symp. on Autonomous Decentralized Systems (ISADS 2001), Dallas, USA, 2001.

96