Uma Infraestrutura de Suporte a Aplicações Cientes de Contexto com o Enfoque no Usuário Final

(1)

Universidade Federal de Campina Grande

Centro de Engenharia El´etrica e Inform´atica

Coordenação de Pós-Graduação em Informática

Uma Infraestrutura de Suporte a Aplicac¸˜oes Cientes

de Contexto com o Enfoque no Usu´ario Final

Hugo Feitosa de Figueirˆedo

Dissertação submetida à Coordenação do Curso de Pós-Graduação em

Ciência da Computação da Universidade Federal de Campina Grande -Campus I como parte dos requisitos necessários para obtenção do grau

de Mestre em Ciência da Computação.

´

Area de Concentração: Ciência da Computação

Linha de Pesquisa: Sistemas de Informac¸˜ao e Banco de Dados

Cl´audio de Souza Baptista

(Orientador)

Campina Grande, Para´ıba, Brasil c

(2)

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG

F475i Figueirêdo, Hugo Feitosa de

Uma infraestrutura de suporte a aplicações cientes de contexto com o enfoque no usuário final / Hugo Feitosa de Figueirêdo ─ Campina Grande, 2009.

115 f.

Dissertação (Mestrado em Ciência da Computação)- Universidade Federal de Campina Grande, Centro de Engenharia Elétrica e Informática.

Referências.

Orientador: Prof. Dr. Cláudio de Souza Baptista.

1. Dispositivos Móveis 2. Aplicação Cientes de Contexto 3. Ontologias I. Título.

CDU 004.65 (043)

(3)

Resumo

As aplicações cientes de contexto estão se tornando populares, como consequência de

avanços tecnológicos em dispositivos móveis, sensores e comunicação de redes sem fio. Entretanto, desenvolver um sistema ciente de contexto envolve vários desafios. Por

exem-plo, quais serão as informações contextuais, como representar, adquirir e processar essas informações e como estas serão utilizadas pelo sistema. Alguns frameworks e middlewares

foram propostos na literatura para auxiliar programadores a superar esses desafios, porém ainda faltam mecanismos que auxiliem usuários finais na personalização dessas aplicações.

Além disso, a maioria das soluções propostas não possui um modelo de contexto extens´ıvel baseado em ontologias ou não utiliza uma comunicação que permita aproveitar as

potenci-alidades dos modelos que seguem esta abordagem. Este trabalho propõe uma infraestrutura de suporte a aplicações cientes de contexto que possui um modelo de contexto extens´ıvel

baseado em ontologias e comunicação entre os elementos utilizando SPARQL e SPARQL Update. Também são propostas ferramentas para usuários finais criarem e validarem

visual-mente regras contextuais.

(4)

Abstract

Context-aware applications have become popular as a consequence of the technological

ad-vances on mobile devices, sensors, and wireless network communication. However, there are many challenges in the development of these applications. For instance, which

contex-tual information will be used, how to represent, capture, proccess and use the context in the system are some of such application development challenges. Frameworks and middlewares

to improve context-aware application development have been proposed, but they still lack helping users in customizing their applications. Furthemore most proposed solutions do not

have an extensible ontology-based context model and an efficient communication which ena-bles to explore the main features of such approach. This work proposes an infrastructure to

support context-aware applications, which uses an extensible ontology-based context mo-del and communication through SPARQL and SPARQL Update. Also there are visual tools

aiming to help end-users in the creation and validation of context rules.

(5)

Agradecimentos

Ao meu orientador e amigo, Cl´audio Baptista, pelos muitos gritos e broncas, por ter me

ensinado muito de como ser um pesquisador e pela paciˆencia que teve comigo (ou n˜ao? :-P). `

A minha esposa, Julliana, por ter aguentado a falta de atenc¸˜ao que lhe dei durante a

redação desta dissertação e por ter me incentivado nos momentos em que precisei.

Em especial, a meu filho Igor, que me deu muitas alegrias e muita forc¸a nos momentos

dif´ıceis. `

A minha m˜ae, por ter me indicado o caminho a ser seguido, pelo apoio financeiro e por

ter me ajudado a entender as broncas do meu orientador. `

A minha irm˜a, Marcella, por ter ficado com Igor v´arios finais de semana para que eu

terminasse meu mestrado. A toda minha fam´ılia.

Ao meu grande amigo e parceiro de pesquisas, Yuri Lacerda, com quem realizei bons trabalhos de pesquisa e tomei poucas cervejas durante o per´ıodo de mestrado.

Aos meus grandes amigos, Cl´audio Campelo e Daniel Fireman.

Aos colegas de Laboratório, Damião, Fábio Leite, Fábio Gomes, Michael, Ricardo,

Lu-ciana, Felipe, Carlos Augusto, Welmisson Jammesson, Tiago (pelas risadas) e Halley. Aos alunos de graduac¸˜aodo LSI, Tiago, Eliael e Diego, por terem contribu´ıdo de alguma

forma com o prot´otipo desenvolvido na minha pesquisa. `

A CAPES e ao CNPQ, pelo apoio financeiro.

(6)

Conte ´udo

1 Introdução 1 1.1 Objetivos . . . 3 1.1.1 Objetivos Espec´ıficos . . . 3 1.2 Metodologia . . . 4 1.3 Estrutura da Dissertação . . . 4 2 Fundamentação Teórica 5 2.1 Computação Ub´ıqua . . . 5 2.2 Contexto . . . 8

2.3 Serviços Baseados em Localização . . . 10

2.4 Representação do Conhecimento, Ontologias e Web Semântica . . . 11

2.5 Modelagem de Contexto . . . 13 2.6 Considerac¸˜oes Finais . . . 15 3 Trabalhos Relacionados 17 3.1 FLAME2008 . . . 17 3.2 WASP e Infraware . . . 19 3.3 MScape . . . 22 3.4 StreamSpin . . . 25 3.5 SOCAM . . . 26

3.6 Context Toolkit e iCAP . . . 28

3.7 Omnipresent. . . 30

3.8 Comparac¸˜ao . . . 32

3.9 Considerac¸˜oes Finais . . . 33 iv

(7)

CONTE ´UDO v

4 VadeMecum 35

4.1 Vis˜ao Geral do Sistema . . . 35

4.2 Servidor de Contexto do VadeMecum . . . 36

4.2.1 Modelo de Contexto do VadeMecum . . . 37

4.2.2 Arquitetura . . . 38

4.2.3 Questões de Implementação . . . 44

4.3 Aux´ılio na criação de regras pelos usuários finais . . . 50

4.3.1 Requisitos Funcionais . . . 51

4.3.2 Requisitos N˜ao Funcionais . . . 52

4.3.3 CARE . . . 53 4.3.4 CARE Emulator . . . 60 4.3.5 Questões de Implementação . . . 62 4.4 Considerações finais . . . 64 5 Estudo de Caso 66 5.1 Outdoor Virtual . . . 67 5.2 Multimedia Service . . . 72 5.3 Considerações Finais . . . 77 6 Conclusão 78 6.1 Contribuições . . . 78

6.1.1 Servidor de Contexto do VadeMecum . . . 79

6.1.2 Aux´ılio na Criac¸˜ao de Regras Contextuais . . . 80

6.2 Trabalhos Futuros . . . 81

Referˆencias Bibliogr´aficas 89

A Modelo de Contexto do VadeMecum 90

(8)

Lista de Abreviac¸˜oes

API - Application Programming Interface

CARE - Context-Aware Rule Editor

CC/PP - Composite Capability/Preference Profiles

CEP - C´odigo de Enderec¸amento Postal

CLDC - Connected Limited Device Configuration

DAML - DARPA Agent Markup Language

DARPA - Defense Advanced Research Projects Agency

DIG - DL Implementation Group FOAF - Friend of a Friend

GMLC - GatewayMobile Location Center GPS - Global Positioning System

HP - Hewlett-Packard

HTTP - Hypertext Transfer Protocol

JAD - Java Application Descriptor

JEE - Java Platform, Enterprise Edition JEE

JME - Java Platform, Micro Edition JSR - Java Specification Request

LBS - Location Based Services

MIDP - Mobile Information Device Profile

MPC - Mobile Positioning Center OGC - Open Geospatial Consortium

OIL - Ontology Inference Layer

OpenLS - Open Location Services Interface Standard

ORM - (Object Role Modeling)

(9)

vii

OWL - Ontology Web Language PDA - Personal Digital Assistants

RDF - Resource Description Framework

RDFS - Resource Description Framework Schema

RIA - Rich Internet Application

SIG - Sistemas de Informações Geográficas

SOAP - Simple Object Access Protocol

SPARQL - SPARQL Protocol and RDF Query Language

SWRL - Semantic Web Rule Language UML - Unified Modeling Language

W3C - The World Wide Web Consortium XML - eXtensible Markup Language

(10)

Lista de Figuras

2.1 Eras computacionais propostas por Weiser.. . . 6

2.2 Tendências futuras em computação(Adaptado de http://www.ubiq.com). . . 7

2.3 Camadas da Web Semˆantica (adaptada de http://www.w3.org/2001/sw). . . 12

3.1 Arquitetura do FLAME2008. . . 18

3.2 Plataforma WASP e seus relacionamentos . . . 20

3.3 Arquitetura da plataforma WASP.. . . 21

3.4 Arquitetura da plataforma Infraware. . . 22

3.5 Componentes de um mediascape. . . 23

3.6 Ferramenta de criac¸˜ao de mediascapes. . . 23

3.7 Arquitetura da plataforma StreamSpin. . . 26

3.8 Modelo baseado em ontologia com dois n´ıveis de hierarquia. . . 27

3.9 Arquitetura do SOCAM. . . 28

3.10 Arquitetura do Context Toolkit.. . . 29

3.11 Arquitetura do Omnipresent. . . 30

4.1 Esquema de criac¸˜ao de regras . . . 36

4.2 Contextos do modelo de contexto do VadeMecum. . . 39

4.3 Ontologia superior do modelo de contexto.. . . 40

4.4 Ontologia do VadeMecum para regras. . . 40

4.5 Arquitetura do servidor de contexto do VadeMecum. . . 41

4.6 Diagrama de classes da API para criac¸˜ao de provedores de contexto. . . 43

4.7 Ferramenta Prot´eg´e com o plugin OWL. . . 45

4.8 Arquitetura do CARE. . . 53

4.9 Widget para seleção de elementos geográficos. . . . 56 viii

(11)

LISTA DE FIGURAS ix

4.10 Interface do CARE. . . 57

4.11 Tela do CARE para seleção da opção para especificar o estado contextual. . 58

4.12 Tela do CARE para selec¸˜ao da classe do tipo ContextEntity.. . . 58

4.13 Tela do CARE para selec¸˜ao do relacionamento da entidade. . . 59

4.14 Arquitetura do CARE Emulator. . . 61

4.15 Interface do CARE Emulator. . . 63

5.1 Diagrama de classes do provedor do contexto de localizac¸˜ao. . . 67

5.2 Ferramenta CARE com uma regra para o Outdoor Virtual. . . 69

5.3 Ferramenta CARE com o widget do google maps . . . 70

5.4 CARE Emulator validando a regra contextual criada para o Outdoor Virtual. 71 5.5 Aplicação móvel antes e depois da ação de mostra uma arquivo multim´ıdia. 72 5.6 Tela inicial do cliente móvel. . . 74

5.7 Tela de escolha do tipo arquivo o usu´ario deseja criar. . . 75

5.8 Tela de criac¸˜ao do arquivo de imagem. . . 76

(12)

Lista de Tabelas

2.1 Comparação entre os tipos de computação.. . . 7

2.2 Comparac¸˜ao entre abordagens para modelagem de contexto. . . 15

3.1 Comparac¸˜ao entre os trabalhos relacionados.. . . 33

(13)

Lista de C´odigos-Fonte

4.1 Regra contextual no VadeMecum. . . 44

4.2 Sintaxe das regras no Jena. . . 46

4.3 Exemplo de consulta em SPARQL SELECT.. . . 48

4.4 Resultado de uma consulta SPARQL na forma SELECT. . . 49

4.5 Atualizando o contexto utilizando SPARQL Update no VadeMecum. . . 49

4.6 Exemplo de arquivo com as func¸˜oes permitidas pelo CARE nas regras. . . . 55

5.1 Regra criada no CARE para o Outdoor Virtual. . . 68

5.2 Regra alterado do estudo de caso do Outdoor Virtual. . . 77

A.1 Modelo de contexto do VadeMecum descrito em OWL. . . 90

B.1 Configurac¸˜ao do Joseki no VadeMecum. . . 101

(14)

Cap´ıtulo 1

Introduc¸˜ao

O poder de processamento e armazenamento dos computadores est´a aumentando cada vez

mais. Tal evolução não está só ocorrendo com os computadores pessoais, mas também com os dispositivos móveis. Desta forma, estes dispositivos estão agregando cada vez mais

fun-cionalidades, permitindo que as pessoas possam realizar algumas tarefas com estes dispo-sitivos enquanto se movimentam. Por exemplo, um investidor recebe uma not´ıcia em seu

dispositivo sobre uma queda na bolsa de valores de Nova York e, rapidamente, vende algu-mas ações suas na Bovespa, antes que os efeitos dessa queda afetem suas cotações, sendo

toda a negociac¸˜ao feita no seu dispositivo.

Por outro lado, uma grande variedade de sensores est˜ao surgindo no mercado, sendo

poss´ıvel acoplá-los a dispositivos móveis através de entradas seriais, Bluetooth, IrDa, etc. A fusão dos dispositivos móveis com esses sensores, torna poss´ıvel o monitoramento da

situação na qual o usuário está inserido. Por exemplo, através de um sensor de temperatura de uma pessoa, é poss´ıvel descobrir se ela está com febre. Estas informações, que podem

ser monitoradas a partir de sensores, são conhecidas como informações contextuais, as quais

comp˜oem um conjunto chamado de estado contextual [1].

O monitoramento do estado contextual pelas aplicações, permite que estas estejam cien-tes de informações impl´ıcitas na comunicação entre o homem e a máquina e não somente as

expl´ıcitas. Com estas informações, as aplicações podem tomar decisões com o intuito de per-sonalizar os serviços a seus usuários. Por exemplo, uma aplicação pode alterar a temperatura

do ar-condicionado de acordo com as preferências das pessoas localizadas no ambiente. Uma das definições mais referenciadas para contexto foi proposta por Dey [2]:

(15)

2

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

O contexto é um dos temas mais pesquisados na computação ub´ıqua, que foi visionada

por Weiser [3]. Na visão de computação ub´ıqua, é previsto que as pessoas serão

auxili-adas nas suas atividades cotidianas pelos computadores, de maneira que este aux´ılio n˜ao

seja percebido pelos próprios usuários. Para que os computadores consigam ajudar sem ser percebidos, é necessário o monitoramento do contexto do usuário, de forma que suas

neces-sidades sejam atendidas automaticamente, quando algum determinado estado contextual for

atingido.

Com os avanc¸os na capacidade de processamento e armazenamento dos dispositivos

móveis, muitos serviços poderão ser fornecidos nestes, havendo a possibilidade destes serviços serem cientes de contexto. Dessa forma, surge a necessidade de pesquisas

volta-das para esta ´area, para se superar alguns desafios provenientes desta vis˜ao.

Os Serviços Baseados em Localização (Location-Based Services - LBS) [4] podem ser

vistos como uma parte dos serviços cientes de contexto que podem ser oferecidos para dispo-sitivos móveis. Estes serviços já deixaram de ser uma visão do futuro para ser uma realidade

[5]. Por exemplo, existem diversas aplicac¸˜oes no mercado que oferecem a busca por uma

rota entre dois pontos geográficos. Além disso, existem outras aplicações que permitem que

sejam criadas condições relacionadas a áreas geográficas. Assim, quando o usuário estiver dentro de alguma destas áreas, uma ação será executada.

Apesar de muitas aplicações cientes de contexto já existirem, poucas possuem uma ar-quitetura extens´ıvel, para facilitar a adição de novos contextos ou serviços. Com isso,

al-guns frameworks, middlewares e arquiteturas foram propostas na literatura para o auxilio na criação destas aplicações [6] [7] [8] [9] [10].

A maior parte das soluções para facilitar a extensão de aplicações cientes de contexto, porém, não enfoca o usuário final, pois são feitas para facilitar a extensão por programadores

– que conheçam bem a solução. Deste modo, alguns pesquisadores propuseram algumas ferramentas com o foco no usuário final, de forma que, ele próprio possa estender e alterar

(16)

1.1 Objetivos 3

para sistemas de Casas inteligentes (Smart Home) e n˜ao possuem um modelo de contexto extens´ıvel ao qual as ferramentas se adaptem.

Este trabalho apresenta uma infraestrutura para facilitar o desenvolvimento de aplicações cientes de contexto com o enfoque na personalização pelo usuário final. Fazem parte da

infraestrutura: um servidor de contexto, que realiza algumas tarefas comuns necessárias às aplicações cientes de contexto; uma ferramenta que auxilia o usuário final na especificação

de regras contextuais; e um emulador para validac¸˜ao das regras.

Na próxima seção, serão apresentados os objetivos deste trabalho. Em seguida, na seção

1.2, é descrita a metodologia que foi utilizada nesta pesquisa. Por fim, na seção1.3, é exposta a estrutura do restante desta dissertação.

1.1 Objetivos

O principal objetivo deste trabalho é desenvolver uma infraestrutura para dar suporte à criação de aplicações cientes de contexto, que permitam a personalização pelo usuário

fi-nal.

1.1.1 Objetivos Espec´ıficos

Os objetivos espec´ıficos deste trabalho s˜ao:

• Obter um modelo de contexto baseado em ontologias;

• Obter um servidor de contexto para o tratamento das informac¸˜oes contextuais;

• Obter uma ferramenta visual para gerac¸˜ao de regras, de forma que, esta tarefa possa

ser executada pelos usuários finais da aplicação;

• Obter um emulador do sistema para validação pelo usuário final das regras criadas; • Fazer com que a infraestrutura permita a extensão do modelo de contexto; e

• Obter aplicac¸˜oes cientes de contexto que validem a infraestrutura proposta neste

(17)

1.2 Metodologia 4

1.2 Metodologia

A metodologia utilizada no trabalho descrito nesta dissertação baseou-se em atividades de estudos regulares em aplicações cientes de contexto, além da realização de pesquisas nas

principais publicações na área. Foram levantadas algumas ferramentas que possuem carac-ter´ısticas similares a este trabalho e estas foram analisadas para o levantamento das lacunas

existentes. A partir das análises realizadas nas ferramentas, foram levantados os requisitos para o sistema. Em seguida, foi desenvolvido um protótipo e realizada uma validação com

alguns estudos de casos de utilização do sistema em simulações de usos reais.

1.3 Estrutura da Dissertac¸˜ao

O restante desta dissertação está estruturada da seguinte forma:

• Cap´ıtulo 2: contém uma fundamentação teórica necessária para a compreensão desta dissertação, como as definições para contexto, aplicações cientes de contexto, computação ub´ıqua e ontologias;

• Cap´ıtulo3: contém uma discussão sobre os principais trabalhos relacionados na área, destacando os pontos relevantes, inspiradores e fracos de cada um;

• Cap´ıtulo4: é apresentada a infraestrutura VadeMecum, sendo descrito uma visão ge-ral do sistema, o servidor de contexto e o processo de criação e validação de regras

contextuais pelo usu´ario final;

• Cap´ıtulo5: são apresentados alguns estudos de caso de situações reais da utilização da infraestrutura proposta neste trabalho; e

• Cap´ıtulo 6: é conclu´ıda esta dissertação, sendo apresentadas as principais contribuições obtidas e outros trabalhos que podem ser desenvolvidos no futuro.

(18)

Cap´ıtulo 2

Fundamentação Teórica

Neste cap´ıtulo, apresenta-se a terminologia b´asica e os conceitos fundamentais utilizados

du-rante esta dissertação. Questões como distinção entre computação pervasiva, ub´ıqua e móvel são abordadas. Também será introduzida uma noção de Web Semântica, que representa um

dos elementos-chaves a serem considerados na modelagem do contexto.

O restante deste cap´ıtulo está organizado da seguinte forma, na seção 2.1,

introduzem-se os conceitos de computação ub´ıqua. Na introduzem-seção 2.2, apresentam-se algumas definições e

caracter´ısticas de contexto, como tamb´em, alguns exemplos de sistemas cientes de contexto.

Na seção2.3, discorre-se sobre serviços baseados em localização, que são um caso espec´ıfico de serviços cientes de contexto. Posteriormente, na seção2.4, descrevem-se alguns conceitos sobre representação do conhecimento, ontologias e Web semântica. Em seguida, na seção

2.5, apresenta-se um estudo sobre modelagem de contexto. Por fim, s˜ao citadas algumas

considerações finais do cap´ıtulo na última seção.

2.1 Computac¸˜ao Ub´ıqua

Weiser [3], em 1991, idealizou um futuro – para o per´ıodo em que o artigo foi escrito – para a computação, a qual seria onipresente na vida das pessoas durante a realização de tarefas do cotidiano. Entretanto, esta não seria percebida pelos mesmos, devido à naturalidade da

situação. Esta ideia abriu caminho para uma nova linha de pesquisa até então inexplorada: a computação ub´ıqua.

Weiser [3] descreveu a computac¸˜ao ub´ıqua como a terceira grande era dos

(19)

2.1 Computac¸˜ao Ub´ıqua 6

res, sendo as duas primeiras representadas pelos mainframes e os computadores pessoais. Na era do mainframe, existiam poucos computadores de grande porte e imenso poder de

processamento para serem compartilhados por inúmeros usuários. Já a era dos computa-dores pessoais foi caracterizada pela utilização de micro-computacomputa-dores para uso pessoal e

exclusivo. Por último, a era da computação ub´ıqua seria caracterizada pela existência de di-versos dispositivos de pequeno porte que auxiliariam os usuários nas suas tarefas cotidianas

sem ser percebidos. A Figura2.1apresenta o relacionamento com as cardinalidades das eras

propostas por Weiser e a Figura2.2mostra um gráfico com as três eras e suas tendências.

Figura 2.1: Eras computacionais propostas por Weiser.

A computação ub´ıqua muitas vezes é equivocadamente confundida com computação per-vasiva; no entanto, estes referem-se a ramos distintos de pesquisa, apesar de possu´ırem uma

grande interseção. A computação móvel trata da habilidade de utilizar dispositivos com-putacionais mesmo quando em movimento. Enquanto, computação pervasiva refere-se à

colaboração transparente entre dispositivos computacionais distribu´ıdos no ambiente f´ısico para a obtenção de informações do meio para a construção dinâmica de novos modelos

com-putacionais. Por fim, a computação ub´ıqua integra os avanços da computação móvel e da computação pervasiva [14]. Na Tabela2.1, confrontam-se os três tipos de computação cita-dos com duas caracter´ısticas, a de imersão computacional – referente à distribuição de

(20)

dis-2.1 Computac¸˜ao Ub´ıqua 7

Figura 2.2: Tendências futuras em computação(Adaptado de http://www.ubiq.com).

Tabela 2.1: Comparação entre os tipos de computação.

Imers˜ao Computacional Mobilidade

Computac¸˜ao Tradicional -

-Computac¸˜ao Pervasiva +

-Computação Móvel - +

Computac¸˜ao Ub´ıqua + +

positivos computacionais para a captação de informações do ambiente – e a de mobilidade – referente à mobilidade dos dispositivos computacionais enquanto está em funcionamento.

“+” indica que a computação atende à caracter´ıstica e “-” que não atende.

Jensen [15] afirma que a realidade na qual uma aplicação será utilizada deve ser pensada quando esta é desenvolvida para o futuro. Desta forma, o ideal é se basear em algumas referências de pesquisadores sobre as tendências no mundo computacional para o per´ıodo

em que a aplicação será utilizada. Por exemplo, basear-se na lei de Moore para estimar qual será o poder computacional no per´ıodo desejado ou, até mesmo, nas visões de Weiser [3].

A computac¸˜ao ub´ıqua abrange diversos ramos de pesquisas, incluindo o dos sistemas

cientes de contexto, que ´e um passo inicial para o futuro visionado por Weiser [3]. Esses

(21)

2.2 Contexto 8

2.2 Contexto

Com a proliferação de dispositivos móveis, tais como smartphones e PDA (Personal Di-gital Assistants), os usuários destes dispositivos podem se movimentar enquanto realizam

outras tarefas. Com isto, informações podem ser coletadas da situação na qual o usuário está inserido para fornecer serviços e informações personalizadas, realizações automáticas de

co-mandos e armazenamento destas informações para uso posterior. Este tipo de informação utilizada para estas tomadas de decisões é chamado de contexto, sendo as aplicações que

utilizam este tipo de informação as aplicações cientes de contexto.

Como visto anteriormente, na computação ub´ıqua o usuário seria auxiliado por

compu-tadores em suas tarefas cotidianas, de forma que, estes não fossem percebidos. Para este objetivo ser alcançado, é necessário que o contexto seja monitorado constantemente, para a

tomada de decis˜ao pelo computador, a fim de auxiliar o usu´ario em suas tarefas.

Existem diversos desafios relacionados à utilização de contexto em sistemas, sendo

al-guns enumerados por Schmidt [16]:

• Entender o conceito de contexto. O conceito de contexto deve ser assimilado antes

de tentar us´a-lo;

• Utilizar o contexto. É necessário saber como o contexto será utilizado;

• Adquirir informac¸˜oes de contexto. Nesta parte entra os desafios relacionados a

captação de informações de sensores;

• Conectar a aquisição de contexto na utilização de contexto. A conexão da aquisição

do contexto com a utilizac¸˜ao deve ser feita de maneira uniforme, independente de qual

sensor a informação foi capturada e onde o sensor está localizado, sendo esta parte abstra´ıda no momento de utilização do contexto;

• Entender a influência da interação entre o homem e o computador. Uma das

utilidades do contexto é facilitar a interação entre o homem e o computador. Com isso,

é necessário entender como esta interação ocorre para tentar melhorá-la;

• Auxiliar na construção de sistemas ub´ıquos. A construção de aplicações cientes de

(22)

2.2 Contexto 9

de mecanismos que auxilie na construc¸˜ao destes; e

• Validar sistemas cientes de contexto. Para validar um sistema ciente de contexto,

é necessário testar o funcionamento deste em situações reais com alguns usuários e analisar os resultados.

Baldauf et al. [17] definem sensor como sendo qualquer fonte de dados que provˆe

informac¸˜oes contextuais. Considerando a maneira como os dados foram capturados, os sensores podem ser classificados como: sensores f´ısicos, quando representam o hardware

utilizado para captar informações do ambiente; sensores virtuais, quando adquirem os dados de aplicações ou serviços; e sensores lógicos, quando utilizam um conjunto de outras fontes

de dados – incluindo outros sensores – para inferir novas informações. Por exemplo, o GPS é um sensor f´ısico, enquanto que uma agenda de compromissos na Web que indica a atividade

que o usuário está realizando é um sensor virtual e um sistema que infere a localização do usuário a partir de sua agenda de compromissos é um sensor lógico.

Schilit e Theimer [18] foram dois dos precursores na pesquisa envolvendo sistemas

cien-tes de contexto, sendo dada por eles a seguinte definição: ciente de contexto é a habilidade de

uma aplicação de descobrir e reagir às mudanças no ambiente. Já com relação à classificação de contexto, eles propuseram a seguinte:

• Contexto computacional. Este contexto está associado às informações do dispositivo

que est´a sendo utilizado. Por exemplo: mem´oria dispon´ıvel e tamanho do visor;

• Contexto do usuário. Este contexto está associado às informações do usuário. Por

exemplo: press˜ao sangu´ınea e temperatura corporal; e

• Contexto f´ısico. Este contexto está associado às informações do ambiente f´ısico ao

redor do usuário. Por exemplo: temperatura ambiente e pressão atmosférica.

Dentre os sistemas cientes de contexto, um dos tipos que mais est˜ao sendo utilizados,

fora do âmbito dos laboratórios de pesquisas, são as aplicações nas quais o contexto de localização do usuário é o foco [19]. Na próxima seção, serão descritas mais caracter´ısticas dos Serviços Baseados em Localização (LBS).

(23)

2.3 Serviços Baseados em Localização 10

2.3 Serviços Baseados em Localização

Serviços que são fornecidos baseados em alguma localização espacial são chamados de

Serviços Baseados em Localização (LBS) [5]. Alguns exemplos de LBS são sistemas de

navegação de carros, sistemas de monitoramento de caminhões, entre outros.

Segundo Schiller e Voisard [4], LBS pode ser definido como um servic¸o que integra

localização ou posição de um dispositivo móvel com outras informações, para adicionar valor para o usuário.

LBS tem sido uma área bastante pesquisada devido ao barateamento dos equipamentos necessários para a utilização destes, como por exemplo, o GPS e smartphones. Além disto, os

avanços tecnológicos têm permitido cada vez mais uma maior capacidade de armazenamento e processamento em dispositivos móveis.

As aplicações LBS podem ser classificadas como do tipo pull ou push, sendo as aplicações do primeiro tipo as que fornecem serviços requisitados pelos usuários, ou seja,

os usuários possuem o controle de quando os serviços irão ser fornecidos. Por outro lado, no serviço do tipo push, os usuários não possuem o controle de quando este será fornecido. Um

exemplo de serviço do tipo pull é o de procura de amigos, no qual o usuário pede para o sis-tema localizar algum amigo. Como exemplo de serviço push, podem ser citados os serviços

de monitoramento de amigos, os quais lançam um alerta quando algum amigo está próximo do usuário.

Os serviços push resultam em um alto preço pela transparência e comodidade oferecida, sendo muito mais caros do que os serviços pull. Este alto custo é devido à maior quantidade

de recurso de rede necessário, pois a localização do usuário precisa ser atualizada constan-temente. Além disto, os serviços push possuem a questão da privacidade do usuário, devido

ao monitoramento constante de sua localizac¸˜ao por terceiros.

No momento de criação de aplicações LBS, algumas caracter´ısticas do sistema a ser

implementado devem ser levadas em consideração [5]. Algumas destas são:

• A aplicação será baseada em serviços push ou pull?

• Os perfis dos usuários podem ser adquiridos indiretamente ou só diretamente? • Quais informações do perfil do usuário serão dispon´ıveis?

(24)

2.4 Representação do Conhecimento, Ontologias e Web Semântica 11 • Quais os cenários poss´ıveis de interação no sistema?

– Requisitante e provedor s˜ao estacion´arios?

– Um é estacionário e outro não. Por exemplo, um carro que emite sua

localização pode ser visto como um provedor e o servidor LBS que consulta essas informações como estacionário; e

– Os dois são móveis. Por exemplo, um usuário que procura um amigo. • Qual a fonte da informação de localização?

• Qual o n´ıvel de precisão da localização é necessário para a aplicação?

• Será mantido um histórico do contexto e, caso seja, este histórico será utilizado para

tomadas de decis˜oes futuras?

• Qual o tipo de fonte de informação? – Estática: banco de dados; e – Dinâmica: tempo, tráfego.

2.4 Representac¸˜ao do Conhecimento, Ontologias e Web

Semˆantica

Nesta seção, serão abordados conceitos importantes para aplicações cientes de contexto, como a representação do conhecimento, ontologias e Web Semântica.

A representação de conhecimento através de ontologias tem ganhado forças nos últimos anos devido à influência da Web Semântica, que possui como um de seus pilares, a

representação das informações na Web na forma de uma ontologia. Segundo Gruber [20], em

ciência da computação, ontologia define um conjunto de primitivas de representação, com o

qual se modela um dom´ınio de conhecimento, sendo este conjunto formado tipicamente por classes, atributos e relacionamentos.

Já a Web Semântica é considerada uma extensão da Web original, na qual a informação é dada com um significado bem definido, permitindo que computadores e pessoas trabalhem

(25)

2.4 Representação do Conhecimento, Ontologias e Web Semântica 12

em cooperação [21]. A Figura2.3apresenta as camadas da Web Semântica, como pode ser

observado uma das camadas superiores é formada por ontologias, as quais são responsáveis

pela representação do conteúdo na Web de forma interpretável por homens e máquinas. Na camada acima das ontologias estão as regras, que definem como serão inferidos novos

co-nhecimentos na Web a partir dos j´a conhecidos.

Figura 2.3: Camadas da Web Semˆantica (adaptada de http://www.w3.org/2001/sw).

Em aplicações simples, a escolha de uma representação não é importante, devido à fa-cilidade de manter um vocabulário consistente. Em aplicações complexas como as cientes

de contexto, porém, existe a necessidade de uma representação mais geral e flex´ıvel. Con-sequentemente, a forma como o conhecimento é representado em aplicações cientes de

con-texto deve ser bem definida, sendo este processo conhecido como m odelagem de concon-texto.

O RDFS (RDF Schema) [22] e o OWL (Web Ontology Language) [23] est˜ao entre as

principais linguagens de definição e instanciação de ontologias. RDFS é uma extensão

semântica do RDF (Resource Description Framework) [24] que é uma recomendação W3C

para descrever recursos na Web. A estrutura de qualquer expressão RDF é uma coleção de triplas, cada uma formada por um sujeito, um predicado (propriedade) e um objeto. O RDFS

possui um grande poder de descrição, porém, falta a capacidade de informar caracter´ısticas das classes e propriedades, o que é poss´ıvel com OWL. Por exemplo, informar que uma

(26)

2.5 Modelagem de Contexto 13

O OWL é dividido em três sublinguagens: OWL Lite, OWL DL e OWL Full. A expres-sividade nestas é aumentada na ordem apresentada. A OWL Lite é a mais simples, sendo

todos os relacionamentos com cardinalidade zero ou um. Já o OWL DL, permite o máximo de expressividade sem perder a completude computacional – todos os v´ınculos são

garan-tidos de serem computados – e a decidibilidade – as computações terminarão em tempo finito – das máquinas de inferência. Enquanto que o OWL Full, apesar de possuir a maior

expressividade, n˜ao possui garantias de decidibilidade.

2.5 Modelagem de Contexto

Um modelo de contexto define os tipos, nomes, propriedades e atributos das entidades

envol-vidas nas aplicações cientes de contexto, como os usuários, dispositivos móveis, contextos, etc. O modelo tenta prover a representação, busca, troca e interoperabilidade de informação

contextual entre as aplicac¸˜oes.

Strang e Linnhoff [25] realizaram um estudo de comparac¸˜ao entre as principais

aborda-gens para modelagem de contexto. Para tanto, foram considerados os seguintes requisitos:

1. Composic¸˜ao distribu´ıda: capacidade do modelo de ser descrito de maneira dis-tribu´ıda;

2. Validação parcial: facilidade para detecção de conhecimento contextual inválido, de acordo com a descrição do modelo;

3. Riqueza e qualidade da informação: o modelo de contexto utilizado deve permitir a descrição da qualidade e riqueza da informação fornecida, pois esta é bastante variável

em aplicac¸˜oes cientes de contexto;

4. Incompletude e ambiguidade: as informac¸˜oes contextuais descrevendo um ambiente,

geralmente, são incompletas e amb´ıguas, quando envolvem uma rede de sensores. Estes aspectos da informação devem ser cobertos pelo modelo;

5. N´ıvel de formalidade: é importante que haja um compreendimento compartilhado dos significados das informações existentes no modelo, o que gera a necessidade de

(27)

2.5 Modelagem de Contexto 14

6. Aplicabilidade em ambientes existentes: do ponto de vista da implementação, o modelo de contexto deve ser aplicável ao ambiente tecnológico dispon´ıvel para o

de-senvolvimento de aplicac¸˜oes cientes de contexto.

Adotando como crit´erio a estrutura de dados utilizada, as t´ecnicas para modelagem de contexto podem ser classificadas em:

• Modelos Chave-Valor: este modelo ´e a estrutura de dados mais simples para

mode-lagem de contexto. O contexto ´e representado no formato de uma lista de pares de

chaves, como “temperatura”, e valores, como “370

C”. Esta t´ecnica de modelagem foi

utilizada por Schilit et al. [26];

• Modelos Baseados em Esquemas de Marcação: a principal linguagem para a descrição das informações contextuais neste modelos é o XML (eXtensible Markup Language) [27], a qual organiza estas informações de maneira hierárquica através de

tags com atributos e valores. Um dos representantes dos modelos desta categoria ´e o

CSCP [28] que estende o CC/PP da W3C [29];

• Modelos Gráficos: Elementos gráficos são utilizados na modelagem feita utilizando

esta t´ecnica. Como exemplos de modelos que utilizam esta t´ecnica temos: o CMP

(Context UML Profile) [30], que utiliza a linguagem UML (Unified Modeling

Lan-guage) para descrever o modelo; e CML (Context Modelling LanLan-guage) [31], que

utiliza ORM (Object Role Modeling) [32];

• Modelos Orientados a Objetos: Esta t´ecnica para modelagem de contexto permite

que sejam aproveitados os principais benef´ıcios das abordagens orientada a objetos,

que s˜ao, a encapsulamento e a reusabilidade. Em Cheverst et al. [33], foi utilizada

uma abordagem de modelagem de contexto orientada a objetos para gerar o modelo chamado de Active Object Model;

• Modelos Baseados em Lógica: Nesta abordagem os modelos são descritos através de

fatos, expressões e regras, podendo novos fatos serem derivados a partir do processo de inferência sobre as regras. Como exemplos de modelos que utilizam esta técnica

(28)

2.6 Considerac¸˜oes Finais 15 • Modelos Baseados em Ontologia: Esta abordagem utiliza ontologias para descrever

as entidades do sistemas e seus relacionamentos. Esta t´ecnica ´e uma das mais

pro-missoras, devido ao grande poder de descric¸˜ao das ontologias. O Omnipresent [36],

o SOCAM [7] e o FLAME2008 [10] s˜ao bons exemplos de sistemas que utilizam

modelos de contexto baseados em ontologias.

Ainda no trabalho de Strang e Linnhoff [25], foi exposto que os modelos baseados em

ontologias s˜ao os mais expressivos e preenchem todos os requisitos descritos anteriormente,

como pode ser observado na Tabela2.2, na qual ’++’ indica que a abordagem atende

total-mente ao requisito, ’+’ indica que atende parcialtotal-mente e ’-’ que n˜ao atende.

Consequen-temente, uma abordagem baseada em ontologias ´e a mais indicada para a modelagem de contexto.

Tabela 2.2: Comparac¸˜ao entre abordagens para modelagem de contexto (adaptado de [25]).

Abordagens/ Requisitos 1 2 3 4 5 6 Chave-Valor - - - + Esquemas de Marcação + ++ - - ++ + Gráficos - - + - + + Orientado a Objetos ++ + + + + + Lógica ++ - - - ++ -Ontologia ++ ++ + + ++ +

A utilização de ontologias para a modelagem de contexto tem sido um dos grandes temas estudados por pesquisadores [7][10][37], devido à necessidade de uma maior expressividade

na modelagem de contexto [9]. No entanto, ainda falta uma padronizac¸˜ao na forma como o

contexto ´e modelado utilizando esta abordagem.

2.6 Considerac¸˜oes Finais

Neste cap´ıtulo, foram apresentados alguns conceitos gerais necessários para o entendimento desta dissertação, como a computação ub´ıqua, contexto, representação do conhecimento,

(29)

2.6 Considerac¸˜oes Finais 16

sobre aplicações cientes de contexto, onde é poss´ıvel obter mais informações sobre o tema. No próximo cap´ıtulo, serão apresentados alguns trabalhos relacionados.

(30)

Cap´ıtulo 3

Trabalhos Relacionados

Neste cap´ıtulo, ser˜ao abordadas algumas ferramentas propostas na literatura para o

desen-volvimento de aplicações cientes de contexto. Serão observadas nas aplicações suas arquite-turas, contribuições e lacunas. Uma atenção especial foi dada as ferramentas de criação de

aplicações cientes de contexto que possuem o foco no usuário final, por ser um dos principais objetivos deste trabalho.

O restante do cap´ıtulo está organizado da seguinte forma: na próxima seção, será apre-sentada a plataforma FLAME2008. Na seção seguinte, serão apreapre-sentadas as plataformas

WASP e Infraware. Na seção 3.3, descreve-se a ferramenta MScape. Na seção seguinte,

é apresentado o sistema StramSpin. Já na seção 3.5, apresenta-se o midleware SOCAM.

Na sec¸˜ao 3.6 apresenta a ferramenta iCAP e o framework Context Toolkit. Para finalizar

a lista de trabalhos relacionados, na seção 3.7, é apresentado o Omnipresent. Em seguida,

é apresentada uma comparação entre os trabalhos descritos. Por fim, são apresentadas as considerações finais deste cap´ıtulo.

3.1 FLAME2008

O FLAME2008 [10] utiliza uma abstração em relação ao contexto, chamada de situação,

que acontece quando algumas caracter´ısticas do contexto ficam inalteradas durante algum

intervalo de tempo. Devido a esta abstração, os serviços são chamados de cientes de situação.

O FLAME2008 [10] é uma plataforma de serviços cientes de situação, desenvolvida para

ser utilizada durante os jogos ol´ımpicos de 2008 em Pequim. Nesta plataforma, ´e utilizado

(31)

3.1 FLAME2008 18

um n´ıvel semântico para identificar os serviços que mais se aproximam das demandas dos usuários, que não necessitam procurá-los.

Na Figura 3.1, pode ser visualizada a arquitetura do FLAME2008, que ´e formada por

trˆes camadas, sendo a primeira camada formada pelos clientes, a segunda formada pela

pla-taforma de serviços e a terceira formada pelos fornecedores de conteúdo. A plapla-taforma é composta de um conjunto de servidores, que são:

Figura 3.1: Arquitetura do FLAME2008 (adaptada de [10]).

• O servidor Log´ıstica de Informac¸˜ao, que implementa os mecanismos de

comunicação push e pull, para o fornecimento de informações e serviços, baseado

no casamento semântico dos serviços com as situações, através do módulo Casamento Semântico;

• O servidor Corretor de Conte údo, que possui os registros semânticos – através da

ontologia da aplicação – e provê acesso aos conteúdos;

• O servidor Perfis e Contextos, que é responsável por fornecer informações – perfil e

contexto – do usuário para a detecção de situações; e

• O servidor Verificador de Serviços [38], que é responsável por fornecer os serviços dispon´ıveis na área em que o usuário está inserido e substituir os serviços

(32)

3.2 WASP e Infraware 19

No FLAME2008, os serviços não são acionados por regras e sim através de uma in-ferência semântica realizada sobre a descrição dos serviços e da situação do usuário, sendo

analisada a semelhanc¸a destes, para verificar quais servic¸os devem ser oferecidos.

Para habilitar a seleção flex´ıvel de serviços para os usuários em um n´ıvel semântico, é

necessária a descrição semântica das situações e dos serviços oferecidos. Assim, são utili-zadas ontologias para estas descrições, podendo ser realiutili-zadas inferências para a seleção de

serviços personalizados, que atendam às necessidades do usuário na sua situação atual. Todas as vezes que acontece alguma alteração significante no contexto do usuário, é

realizada a procura por serviços que possuam semelhança à situação atual do usuário, sendo todos os serviços resultantes enviados para o dispositivo móvel do usuário.

As principais contribuições do FLAME2008 são: o oferecimento de serviços personali-zados baseados na situação do usuário sem a necessidade da interferência dele e a utilização

de ontologias para descrever semanticamente os perfis, serviços e situações, possibilitando a inferência para seleção de serviços.

Uma caracter´ıstica que falta no FLAME2008 é o monitoramento de situações de ter-ceiros, principalmente para o propósito que a plataforma foi criada – eventos com grande

concentração de pessoas. Por exemplo, se o usuário desejar saber onde está uma atleta para pedir um autógrafo, necessitará monitorar o contexto dele.

No FLAME2008, não há a possibilidade do usuário se inscrever em algum serviço, dessa forma, o usuário não possui o controle sobre os serviços fornecidos a ele, com isso, muitos

serviços que não são do seu interesse são oferecidos.

No processo de desenvolvimento da plataforma de servic¸os para os Jogos Ol´ımpicos de

Pequim, o FLAME2008 foi renomeado para COMPASS2008, sendo colocado um protótipo em execução e testado com usuários [39].

3.2 WASP e Infraware

WASP (Web Architectures for Services Platforms) [9] ´e uma plataforma para servic¸os cientes

de contexto, que oferece o apoio à construção e execução dessas aplicações. Na Figura3.2, são mostrados os três elementos com os quais a plataforma WASP possui relacionamentos, sendo eles:

(33)

Figura 3.2: Plataforma WASP e seus relacionamentos (adaptada de [9]).

• Os Provedores de Contexto, que são responsáveis por fornecer as informações de

texto provindas de sensores, estruturas computacionais ou outros provedores de con-texto;

• Os Provedores de Serviço, que são entidades que fornecem serviços à plataforma,

havendo a necessidade dos servic¸os serem publicados e registrados; e

• As Aplicações WASP, que são as aplicações sens´ıveis ao contexto, que utilizam a

plataforma WASP para ter acesso à assinatura de serviços e as informações contextuais dos Provedores de Contexto.

As informações de contexto e os serviços são definidos na plataforma WASP através de

ontologias, para auxiliar a criação de novos serviços e a descrição de regras que ativarão os serviços dispon´ıveis pelos provedores de serviços. O monitoramento do contexto e das regras é realizado pela plataforma, sendo algumas vezes necessário que informações de contexto

das aplicações sejam fornecidas através de provedores de contexto para a plataforma (ver

Figura3.3).

Para a descrição de regras, a plataforma WASP possui uma linguagem de comunicação

entre as aplicações e a plataforma, para que as aplicações especifiquem como a plataforma deve reagir a um determinado contexto.

Existe uma camada de Privacidade na plataforma WASP, a qual permite um controle so-bre o fluxo de informações provindas dos provedores de contexto e serviço, que são utilizadas

(34)

Figura 3.3: Arquitetura da plataforma WASP (adaptada de [9]).

O Infraware [40] [41] ´e uma plataforma que est´a dando continuidade ao projeto iniciado com a plataforma WASP, sendo desenvolvida na Universidade Federal do Esp´ırito Santo. O Infraware pretende estender as funcionalidades da plataforma WASP com o objetivo de

tornar a arquitetura mais flex´ıvel, permitindo a adição de novos serviços e a interpretação

num n´ıvel mais abstrato do contexto. Na Figura 3.4, pode ser observada a arquitetura do

Infraware, a qual possui módulos adicionais de manipulação semântica em relação à arquite-tura da plataforma WASP, sendo esta semântica utilizada, entre outras funcionalidades, para

a composição de serviços.

Um dos problemas destes sistemas é a falta de uma ferramenta que auxilie a criação

de novos serviços e de criação de regras, pois a utilização de uma semântica, através de ontologias, não é o suficiente para auxiliar na criação de serviços e de regras para a aplicação

(35)

3.3 MScape 22

Figura 3.4: Arquitetura da plataforma Infraware (retirada de [40]).

3.3 MScape

MScape [42] é um projeto da HP, que tem como objetivo o aux´ılio na criação, no

comparti-lhamento e na distribuição de mediascapes por usuários de dispositivos móveis. Mediascape

é uma experiência multim´ıdia ciente de contexto que permite acionar conteúdos multim´ıdia baseados no contexto.

Um mediascape pode ser executado em um dispositivo móvel que possua a aplicação instalada, sendo um arquivo de m´ıdia apresentado quando determinado contexto acontecer.

A existência de um portal Web torna poss´ıvel o compartilhamento e distribuição dos mediascapes pelos usuários, além de poderem trocar experiências obtidas no processo de

criação, através de um fórum de discussão.

Na Figura 3.5, podem ser observados os componentes b´asicos de um mediascape, que

são: a parte lógica, as entradas do usuário, os sensores e os arquivos de m´ıdia.

Para facilitar o processo de criação de um mediascape por usuários, foi desenvolvida

uma ferramenta para auxiliá-los (ver Figura3.6). A ferramenta de construção de mediascape

possui uma interface de construção baseada em regras de contexto. Desta forma, é poss´ıvel

criar regras do tipo: quando o usuário estiver inserido em uma determinada área geográfica, então será mostrado um determinado v´ıdeo sobre aquele local.

(36)

3.3 MScape 23

Figura 3.5: Componentes de um mediascape (adaptada de [42]).

(37)

3.3 MScape 24

Os seguintes requisitos foram utilizados para a criação da ferramenta de construção de mediascape:

• Uma linguagem extens´ıvel para descrever o contexto. Existe uma linguagem de

script na ferramenta, com a qual o usuário pode manipular as informações recebidas

dos sensores.

• Especificação de eventos contextuais e as suas consequências. Através da

lingua-gem de script ´e poss´ıvel determinar consequˆencias de acordo com um estado

contex-tual no qual o usu´ario est´a inserido.

• A representação do estado contextual. Com eventos lançados quando o usuário

“en-tra” ou “sai” de um determinado contexto ´e poss´ıvel representar os estados contextuais poss´ıveis e suas consequˆencias.

• O armazenamento e gerenciamento de arquivos de m´ıdia. Arquivos multim´ıdia

podem ser carregados no sistema, para posteriormente serem utilizados na gerac¸˜ao de regras.

• Uma interface de criação que permite não programadores explorar novos gêneros de mediascape. Através de uma interface visual de criação de regras é poss´ıvel que

usu´arios n˜ao programadores consigam criar mediascapes.

• Um emulador para testar as regras criadas. O emulador que acompanha a

ferra-menta de criação possui ferraferra-mentas para simular informações retornadas por um GPS e ativações de botões no dispositivo, mas para haver o suporte a outro tipo de sensor é

necessário a adição de um plugin à ferramenta.

As grandes contribuições do MScape são: a liberdade oferecida para os usuários

cri-arem suas próprias aplicações com uma ferramenta visual; a opção de testar o funciona-mento do mediascape criado em um emulador; e a existência de um portal no qual pode-se

compartilhar e distribuir os mediascapes criados, além de ser poss´ıvel a discussão sobre as experiências na criação.

Apesar da ferramenta de emulação de mediascapes ser uma das grandes contribuições do MScape, esta possui a limitação de só permitir a simulação do GPS, não permitindo a

(38)

3.4 StreamSpin 25

Uma caracter´ıstica marcante que falta ao MScape é a possibilidade de adição de arquivos multim´ıdia pelo próprio dispositivo móvel, podendo assim criar ou alterar mediascapes a

partir do próprio dispositivo móvel. Por exemplo, um usuário poderia tirar uma foto e gerar um mediascape com essa foto, de forma que, quando o usuário estivesse nesta mesma área

novamente a foto fosse mostrada.

Outro problema detectado no MScape é que a alteração de um mediascape torna-se quase

inviável, pois seria necessário utilizar a ferramenta de criação de mediascape e novamente adicionar no portal Web. Deste modo, pessoas que já haviam baixado o mediascape

desa-tualizado teriam que substituir o mediscape antigo. Além disto, o armazenamento de vários mediascapes nos dispositivos móveis pode não ser viável, pois o espaço de armazenamento

nos dispositivos móveis é reduzido. Assim sendo, seria mais interessante o armazenamento em um servidor central. Desta forma, ao invés de baixar o mediascape para o dispositivo, os

usu´arios iriam execut´a-lo de uma plataforma.

3.4 StreamSpin

O projeto StreamSpin desenvolvido na Universidade de Alborg [43] [13], tem como objetivo

criar um portal onde se concentrem os serviços dispon´ıveis para os dispositivos móveis, sendo estes serviços na sua grande maioria cientes de contexto. Com isso, é mantida uma

API para o desenvolvimento dos serviços e um sistema de cadastro de usuários, os quais podem gerenciar suas inscrições nos serviços e adicionarem seus próprios serviços para a

comunidade.

Na Figura 3.7, ´e apresentada a arquitetura do portal StreamSpin, a qual ´e formada por

três módulos: o módulo de Serviços Web, responsável pelo gerenciamento dos serviços dispon´ıveis; o módulo do S´ıtio Web, responsável pelo gerenciamento dos usuários no

sis-tema e pela distribuição dos serviços; e o Núcleo, responsável pela execução de casamento semântico e gerenciamento da distribuição dos serviços.

O grande lema do projeto StreamSpin é ser para serviços móveis o que o YouTube é para os v´ıdeos. A grande contribuição do projeto, segundo os autores, é facilitar criação e

compartilhamento de servic¸os m´oveis.

(39)

3.5 SOCAM 26

Figura 3.7: Arquitetura da plataforma StreamSpin (adaptada de [13]).

um programador, pois s´o ´e fornecida uma API de desenvolvimento e nenhuma ferramenta

para auxiliar na criação do serviço. Devido às grandes dificuldades de se construir uma aplicação ciente de contexto de maneira ad hoc, torna-se quase que inviável a criação de

serviços pelos usuários finais. Além disso, para a adição de novos sensores para a captação de novos contextos, é necessário estender a API fornecida, o que exige experiência do usuário

com programac¸˜ao.

O controle de acesso e privacidade é quase inexistente. Desta forma, não há a

possibili-dade de um usu´ario acessar o contexto de outro usu´ario.

O fornecimento de mapas ´e outro problema, pois deixa a responsabilidade para o servic¸o

a ser criado, não existindo um serviço padrão de fornecimento de mapas.

3.5 SOCAM

O SOCAM (Service-Oriented Context-Aware Middleware) [7] ´e um intermediador para a

construção de aplicações cientes de contexto, cujo modelo de contexto é baseado em ontolo-gia.

Na Figura 3.8, pode ser visualizado o modelo baseado em ontologia, que ´e formado

por dois n´ıveis de hierarquia. No n´ıvel inferior, est˜ao contidas as ontologias de dom´ınio

espec´ıfico do sistema, como por exemplo, os dom´ınios de uma casa e um ve´ıculo. J´a o n´ıvel superior ´e composto da ontologia geral do sistema, que possui conceitos gerais sobre

(40)

3.5 SOCAM 27

as outras ontologias. Desta forma, a ontologia de um dom´ınio espec´ıfico selecionada, pode ser alterada dinamicamente. Por exemplo, quando o usuário está em casa, então a ontologia

de dom´ınio selecionada é a de uma casa, mas se ele sair da casa e entrar em seu carro, então a ontologia selecionada será a de um ve´ıculo.

Figura 3.8: Modelo baseado em ontologia com dois n´ıveis de hierarquia (retirada de [7]).

Na Figura3.9, ´e apresentada a arquitetura do SOCAM, cujos elementos principais s˜ao:

• Provedores de contexto: responsáveis pela separação de um n´ıvel mais baixo de

sen-soriamento de um n´ıvel mais alto de manipulação de contexto. Os provedores de contexto necessitam ser registrados no Serviço de Localização de Serviço, para que

este possa ser utilizado por outros usu´arios.

• Serviço de localização de serviço (SLS): serviço responsável pelo cadastro e

localização dos provedores de serviço.

• Interpretador de contexto: responsável pela interpretação de contexto, para

forne-cer um n´ıvel mais alto de abstração. O interpretador de contexto também pode ser cadastrado no Serviço de Localização de Serviços, para poder ser utilizado por outros

(41)

3.6 Context Toolkit e iCAP 28

Figura 3.9: Arquitetura do SOCAM (adaptada de [7]).

• Serviços móveis ciente de contexto: são os serviços fornecidos ao usuário, com ou

sem o controle deste. Por exemplo, um serviço de segurança de ve´ıculo, não pos-sui controle do usuário, que recebe informações sobre as condições de trânsito nas

suas proximidades. Por outro lado, um serviço de localização de amigos, necessita da requisição do usuário para ser fornecido.

As principais contribuições do SOCAM são: o modelo de contexto de dois n´ıveis hierárquicos baseado em ontologia, devido ao alto n´ıvel semântico dado ao sistema; a

capa-cidade de alteração dinâmica da ontologia de dom´ınio espec´ıfico de acordo com o contexto; e uma arquitetura orientada a serviços, que possibilita a adição de novos serviços facilmente.

Por outro lado, a utilização somente de ontologias não é o suficiente para o auxilio da criação de serviços. Além disso, o SOCAM não possui uma interface para os dispositivos

m´oveis, de maneira que, sejam utilizados os servic¸os fornecidos pelo sistema.

3.6 Context Toolkit e iCAP

O Context Toolkit [6] é um framework que auxilia na construção de aplicações cientes de

contexto. Para isso, são utilizados os seguintes conceitos: a separação de preocupações, da

aquisição e uso de contexto; a agregação de contexto e a interpretação de contexto.

Na Figura 3.10, pode ser visualizada a arquitetura do Context Toolkit, que ´e composto

(42)

3.6 Context Toolkit e iCAP 29

das informações de contexto; o agregador, que é responsável por agregar toda informação de contexto de uma entidade; e o interpretadoro, utilizado para abstrair as informações de

contexto.

Figura 3.10: Arquitetura do Context Toolkit (adaptada de [6]).

O Context Toolkit é um framework para auxiliar na criação de aplicações cientes de con-texto num n´ıvel mais baixo de abstração. Dessa forma, necessitando de outras ferramentas

para auxiliar na criac¸˜ao de um sistema mais completo.

Um dos problemas do Context Toolkit ´e a falta de um controle de privacidade das

informações de contexto. Além disso, não existe uma semântica para descrever o contexto e as regras.

O Context-Aware Application Prototyper (iCAP) [11] ´e um sistema que permite usu´arios

finais projetarem visualmente aplicações cientes de contexto. O iCAP permite que o usuário

descreva uma situação e uma ação associada a esta. Para isso, possui uma interface de criação

de regras de forma visual, a qual utiliza o esquema de casamento de Pane e Myers [44] – que

representa o operador AND na vertical e o operador OR na horizontal.

O iCAP possui uma boa interface com o usuário para a prototipação e simulação de

sistemas cientes de contexto pelos usu´arios finais, utilizando o Context Toolkit. Entretanto, foi desenvolvido focado mais na ´area de Casas Inteligentes.

(43)

3.7 Omnipresent 30

3.7 Omnipresent

O Omnipresent [8] ´e um sistema ciente de contexto baseado em uma arquitetura orientada a

serviço. Na Figura3.11, apresenta-se a arquitetura do Omnipresent que é formada por três

camadas:

Figura 3.11: Arquitetura do Omnipresent (adaptada de [8]).

Na camada cliente, o Omnipresent possui duas formas de ser acessado, atrav´es de um navegador Web ou em um dispositivo m´ovel. Algumas funcionalidades podem ser acessadas

nas duas formas de acesso, que são o monitoramento da localização de terceiros, a rota entre dois pontos, a alteração do contexto emocional e o status, o acesso de informações de pontos

de interesse, operações de aproximação e deslocamento em um mapa e o recebimento de alertas.

Por outro lado, algumas funcionalidades s´o podem ser acessadas em uma das formas de acesso. Por exemplo, somente no navegador Web ´e poss´ıvel criar regras sobre os estados

contextuais e somente no dispositivo móvel é poss´ıvel alterar os contextos fisiológicos e de localização – através das informações captadas dos sensores.

´

(44)

tercei-3.7 Omnipresent 31

ros. As ações podem ser no formato de alertas ou de e-mails, sendo que os alertas podem ser visualizados tanto no dispositivo móvel, quanto no navegador Web.

As regras de estados contextuais são criadas no formato XML respeitando as definições de um XSD, não havendo uma forma visual de criar as regras. As ações poss´ıveis de uma

regra são: o lançamento de alertas para o usuário desejado ou o envio de um e-mail. Alguns serviços são oferecidos no Omnipresent, sendo eles:

• O Serviço de Apresentação: utiliza o iGIS [45] para o fornecimento de mapa e de informações sobre a localização. Este serviço é dividido em duas partes a WMS e a

WFS, que seguem os respectivos padr˜oes da OGC [46][47];

• O Serviço de Roteamento: serviço que fornece o roteamento a partir de dois pontos; • O Serviço LBS: monitora os contextos de todos os usuários, lançando alertas de

acordo com as regras criadas no sistema; e

• O Serviço de Propaganda: serviço para o lançamento de propagandas para o usuário

de acordo com suas preferˆencias e contexto.

As grandes contribuições do Omnipresent são a proposta de uma arquitetura orientada a serviço, o monitoramento de diversos tipos de contextos além da localização, a existência de

um Sistema de Informação Geográfico no cliente, uma interface de gerenciamento de regras pelo o usuário final e o monitoramento do contexto de terceiros.

O Omnipresent, porém, não utiliza uma máquina de inferência baseada em regras, ele simplesmente compara informações de contexto atuais com os valores monitorados. Além

disso, a extensão do modelo de contexto para suportar outros tipos de contextos é bastante complicada, uma vez que é necessário a modificação do código fonte e adição de serviços

Web, que não seguem um padrão. Outro problema refere-se aos serviços, uma vez que não é poss´ıvel adicionar novos serviços em tempo de execução, sendo necessário a criação de

stubs1e adição do suporte destes no dispositivo móvel.

O modelo de monitoramento de contexto e regras do Omnipresent [36] ao atualizar um

contexto que está sendo monitorado, serão acionados todos que estão escutando as mudanças neste. Entretanto, para a utilização eficiente deste modelo foi necessária a não utilização de

(45)

3.8 Comparac¸˜ao 32

uma máquina de inferência e a simplificação das regras contextuais poss´ıveis no sistema, restringindo as regras a um formato de arquivo XML que segue um XSD que dá pouca

liberdade na criação das regras, comparada à complexidade de regras poss´ıveis com o modelo de contexto existente.

Outro problema detectado no Omnipresent é que as ações das regras que compõem os serviços push só permitem enviar e-mail ou mandar um alerta, desta forma, limitando-se a

uma pequena diversidade de servic¸os.

3.8 Comparac¸˜ao

Nesta seção, apresenta-se uma comparação entre os trabalhos relacionados descritos neste

cap´ıtulo. Para esta comparação foram considerados as seguintes caracter´ısticas consideradas relevantes para o propósito do trabalho ao qual trata esta dissertação:

1. Modelo de contexto baseado em ontologias. Como descrito na sec¸˜ao2.5, uma

abor-dagem baseada em ontologias é a mais indicada para modelagem de contexto, devido à sua grande expressividade e preenchimento de vários requisitos necessários para um

modelo de contexto;

2. Extensibilidade do modelo de contexto. A natureza dinâmica das aplicações cientes

de contexto geram mudanças rápidas e constantes nos requisitos destas aplicações [48], consequentemente, o modelo de contexto deve se extens´ıvel para diminuir o tempo e

os custos no preenchimento dos novos requisitos;

3. Aquisição de dados provindos de sensores f´ısicos, virtuais e lógicos. As aplicações

cientes de contexto podem adquirir as informações contextuais de vários tipos de fon-tes diferenfon-tes, gerando a necessidade das ferramentas que almejam dar suporte a estas

aplicações possuam uma forma de aquisição desses vários tipos;

4. Interface gráfica para criação visual de regras contextuais. Para permitir que

usu´arios finais possam criar regras contextuais, existe a necessidade de uma ferramenta visual para este fim;

(46)

5. Emulador para validação de regras contextuais. Após criar regras contextuais, o usuário necessita validá-las em um emulador antes de serem submetidas para o

servi-dor; e

6. Comunicação entre os componentes que permita a adição de novas informações

contextuais. Para permitir que o modelo de contexto seja estendido em tempo de

execução, é necessário que a comunicação entre os componentes do sistema permita

esta ac¸˜ao.

Na Tabela 3.1, mostram-se quais trabalhos possuem as caracter´ısticas citadas

anterior-mente. Os campos marcados com ’+’ indicam que a ferramenta possui a determinada

fun-cionalidade, os marcados com ’-’ indicam que n˜ao a possuem. Quando alguma ferramenta possui parcialmente alguma funcionalidade, os campos s˜ao marcados com ’+-’.

Tabela 3.1: Comparac¸˜ao entre os trabalhos relacionados.

3.9 Considerac¸˜oes Finais

Neste cap´ıtulo, foram descritos alguns trabalhos relacionados, sendo citadas suas principais vantagens e desvantagens. Em seguida, foi apresentada uma comparac¸˜ao entre os

traba-lhos, levando em consideração algumas caracter´ısticas desejáveis para um sistema ciente de contexto que permita a personalização pelo usuário final e seja extens´ıvel.

Algumas lacunas, referentes às caracter´ısticas citadas neste cap´ıtulo, foram detectadas nos trabalhos relacionados. Nenhum dos trabalhos possui uma comunicação que facilite

(47)

execução. Além disto, somente dois trabalhos possuem uma forma visual de criação de regras contextuais, porém, estes não possuem um modelo de contexto baseado em ontologias.

No pr´oximo cap´ıtulo, ser´a apresentado o servidor de contexto do VadeMecum e, no se-guinte, as ferramentas CARE e CARE Emulator, as quais formam a infraestrutura proposta