monitor/ce: um componente para a coleta de informacões de...

Gustavo Luiz Bastos Baptista

Matricula: 0116275-6

Monitor/CE: um componente para a coleta de informacões de contexto e localização para Palmtops.

Projeto Final de Graduação

Orientador: Prof. Markus Endler

Rio de Janeiro, junho de 2006

Projeto Final

_____________________________________________________________________ Gustavo Luiz Bastos Baptista 2

Sumário 1 Introdução ................................................................................................................... 3

1.1 Domínio da Aplicação - Mobile Colaboration Architecture (MoCA)................ 7 1.2 Motivações........................................................................................................ 11

1.2.1 Portabilidade da MoCA para Palmtops..................................................... 11 1.2.2 Novos Requisitos para o Serviço de Localização ..................................... 12

1.3 Usuários-alvo .................................................................................................... 13 1.4 Ambiente Computacional ................................................................................. 14

2 Estado da arte............................................................................................................ 20 2.1 Descrição e avaliação de tecnologias e aplicações existentes .......................... 20

3 Objetivos do Projeto ................................................................................................. 22 4 Projeto e especificação da aplicação......................................................................... 24

4.1 Modelo de dados ............................................................................................... 24 4.1.1 Diagrama de classes.................................................................................. 24 4.1.2 Dicionário de dados .................................................................................. 25

4.2 Casos de uso...................................................................................................... 44 4.3 Interfaces Gráficas ............................................................................................ 48

5 Considerações finais ................................................................................................. 52 Referências bibliográficas................................................................................................. 53

Projeto Final


1 Introdução

A crescente disponibilidade e capacidade dos dispositivos móveis vêm assumindo

um papel cada vez mais significativo no dia a dia das pessoas. É cada vez mais comum

encontrarmos dispositivos, de celulares a computadores de bolso, com maior poder de

processamento e armazenamento, além disso, geralmente equipados com interfaces para

conectividade via Bluetooth, Wi-Fi, Infravermelho e GPS. Podemos facilmente acreditar

que em um futuro bem próximo uma convergência da computação tradicional para a

computação móvel ocorrerá de forma significativa.

Juntamente com esta evolução e a diminuição nos custos dos dispositivos, pode-se

notar um aumento na demanda por serviços e aplicações especializadas, entre elas

aplicações e serviços sensíveis a contexto e localização, como por exemplo, aplicações de

navegação pessoal com mapas, guias virtuais e etc.

À medida que os computadores se tornam mais portáveis, as pessoas desejam

acessar as informações a qualquer momento e em qualquer lugar. Entretanto, os sistemas

distribuídos tradicionais que assumem um ambiente de execução estacionário não são em

sua totalidade apropriados para tais cenários móveis. Em face dessa realidade, muitos

pesquisadores na área de computação móvel têm proposto soluções (e.g., Sistema CODA,

Wirelless CORBA, IP Móvel) para tornar as questões relacionadas à mobilidade

(desconexão e conexão com uma nova rede) transparentes para os usuários finais.

Entretanto, ao invés de prover transparência total de mobilidade para as

aplicações, os sistemas de gerenciamento de mobilidade deveriam permitir também que

as aplicações pudessem estar cientes da mobilidade para que elas pudessem se adaptar

apropriadamente as eventuais perdas de dados na desconexão e estabelecimento de

conexão em uma nova rede. De fato, tais aplicações, cientes da mobilidade do usuário,

proverão serviços mais efetivos e úteis se elas puderem tirar proveito das características

do ambiente dinâmico, tais como localização do usuário, proximidade entre pessoas, hora

do dia, nível de ruído, intensidade da luz, estado do sistema e do hardware e etc.

Além das características primárias que fazem parte da lógica de negócio, essas

aplicações levam em conta o contexto corrente do usuário (e.g., localização), dispositivo

ou ambiente computacional (e.g., rede, sistemas operacionais, etc) para adaptarem-se a

Projeto Final


esse contexto, e, por conseguinte proverem serviços mais adequados ao usuário final. Por

exemplo, uma aplicação sensível ao contexto poderia usar a informação de localização

para enviar uma oferta de um produto de uma loja co-localizada com o usuário, ou,

poderia usar as informações de conectividade da rede sem fio para adaptar o seu

comportamento de acordo com a comunicação intermitente desse tipo de rede. De fato,

são muitas as suas aplicabilidades.

Percepção de contexto (Context awareness) tem sido apontada como um dos

principais paradigmas de programação de aplicações distribuídas para redes móveis.

Existem várias definições na literatura sobre “contexto” e “percepção de contexto”. Por

exemplo, Dey define que: “Contexto é qualquer informação que possa ser utilizada para

caracterizar uma situação de uma entidade considerado relevante para a interação entre

um usuário e uma aplicação, incluindo o usuário e a própria aplicação”. Schilit, um dos

precursores da pesquisa da computação sensível ao contexto, divide o contexto em três

categorias gerais:

Contexto computacional: rede, conectividade, custo da comunicação, banda

passante, recursos e etc;

Contexto do usuário: perfil do usuário, posição, velocidade, pessoas próximas,

situação social, estado de espírito, etc;

Contexto físico: luminosidade, nível de ruído, temperatura, humidade e etc.

Além disso, outros pesquisadores também incluíram nessa relação o contexto

temporal caracterizado pela hora do dia, informações de calendário, semana, estação do

ano, dentre outros.

Dentre os diversos tipos de contexto existentes, localização é um dos que mais

tem atraído a atenção de diversos grupos de pesquisa. Considerando que a localização do

usuário muda sempre que ele se move, um sistema de rastreamento confiável é

necessário, e é o ponto crítico a ser tratado no desenvolvimento das aplicações LBS

(Location Based Services). A seguir, são discutidas algumas abordagens relacionadas ao

desenvolvimento de sistemas de rastreamento de localização em ambientes abertos

(Outdoors) e em ambientes fechados (indoors).

O sistema de inferência de localização outdoor mais comumente utilizado é o

Global Positioning System (GPS). A partir desse é possível inferir as coordenadas

Projeto Final


geográficas (Altura em relação ao nível do mar, latitude e longitude) que representam a

localização do dispositivo (que está utilizando um receptor de sinal GPS) com uma

precisão aproximada de 3 metros. Alem do GPS, podem ser utilizadas outras abordagens

tais como triangulação dos pontos de acesso em redes GSM ou 802.11. Entretanto,

devido às possibilidades de interferência e variação de sinal nessas redes, a inferência não

é precisa e confiável como nos sistemas GPS.

A inferência da localização baseada no GPS não funciona apropriadamente para

ambientes indoors, pois a força/intensidade do sinal emitida pelos satélites não é o

suficiente para penetrar na maioria dos prédios.

Existem várias tecnologias para inferência de localização indoor. A maioria dos

projetos de pesquisa relacionados desenvolveu seus próprios sistemas de

rastreamento/localização. O sistema Olivetti Active Badge, Xerox ParcTab, e o projeto

Cyberguide construíram sistemas de rastreamento baseado em sensores de Infra-

vermelho (IR). A inferência é realizada a partir da localização dos sensores que estão

emitindo sinais IR. Esses foram colocados estrategicamente em determinadas localidades.

Nesses projetos, ao invés do sistema inferir a localização do usuário, o próprio

dispositivo determina sua localização a partir da identificação e da localização do sensor

no mapa de regiões. Outros projetos, tais como MoCA, MiddleWhere, Ekahau, Place

Lab, Radar inferem a localização corrente do dispositivo a partir de técnicas de

triangulação dos sinais dos pontos de acesso no raio de cobertura do dispositivo móvel

em redes 802.11.

Não existe uma maneira uniforme de rastrear localização dos dispositivos com

granularidade fina que funcione em ambos tipos de ambiente indoors e outdoors. Na

prática, um sistema pode consultar diferentes serviços de localização para localizar

diferentes tipos de objetos, enquanto um sistema pode localizar um objeto através de

diferentes técnicas. Por exemplo, usar GPS em redes outdoors, usar redes 802.11,

câmeras de reconhecimento facial, cartão de identificação pessoal, dentre outros em redes

indoors. Entretanto, em todos os sistemas existe uma margem de erro com relação a

confiabilidade da inferência devido ao ruído presente no sinal, erros dos sensores, alta

taxa de mobilidade dos usuários, etc.

Projeto Final


Para desenvolver aplicações sensíveis ao contexto, faz-se necessário um

mecanismo para capturar o contexto corrente e repassá-lo para a aplicação. Desenvolver

aplicações sensíveis ao contexto, entretanto, não é uma tarefa trivial considerando que tal

controle estaria misturado com a lógica da aplicação. Tal dificuldade nos permite

concluir que este processamento deve ser realizado transparentemente à aplicação dentro

de uma camada de middleware que forneça os meios necessários para a obtenção de

informações de contexto e localização de forma transparente, permitindo que diversas

aplicações sejam desenvolvidas sem que detalhes da implementação destes tenham que

ser considerados. Alguns grupos de pesquisa tem proposto infra-estruturas de middleware

(e.g., Context Toolkit, Context Fabric - Confab, Mobile Collaboration Architecture -

MoCA, Context Broker Architecture - CoBrA, etc) que implementam a coleta e difusão

das informações de contexto. O middleware MoCA, apresentado na seção 1.1, foi

desenvolvido para oferecer tal transparência.

Este trabalho apresenta o desenvolvimento de um componente de software, para

o middleware MoCA, que coleta informações de contexto de Palmtops, incluindo suas

coordenadas geográficas obtidas do GPS, e as envia para um Servidor de Informações de

Contexto que disponibilizará tais dados para aplicações ou outros serviços (tais como

serviços de localização) interessados.

Projeto Final


1.1 Domínio da Aplicação - Mobile Colaboration Architecture (MoCA)

A Mobile Collaboration Architecture (MoCA) é um middleware para provisão de

informações de contexto que auxilia o desenvolvimento de serviços e aplicações

colaborativas com percepção de contexto para usuários móveis. O projeto dessa

arquitetura focou na simplicidade, extensibilidade, escalabilidade, heterogeneidade de

protocolos e na capacidade de customização das aplicações.

A MoCA foi projetada para redes sem fio infra-estruturadas e sua atual

implementação funciona com redes IEEE 802.11 baseadas nas camadas do protocolo IP,

entretanto a arquitetura pode também ser implementada para funcionar em redes celulares

de dados tais como o GPRS.

A arquitetura, é formada por APIs cliente e servidor, um conjunto de serviços

para registrar aplicações, monitorar e inferir o contexto de execução dos dispositivos

móveis. A MoCA facilita o desenvolvimento de programas distribuídos que requerem

acessar o contexto de um grupo ou de um indivíduo específico para adaptar seu

comportamento.

Na sua forma mais geral, uma aplicação desenvolvida com base na MoCA é

composta por um servidor da aplicação, normalmente executado na rede fixa, e os

clientes da aplicação, que são executados em dispositivos móveis.

A arquitetura oferece os seguintes serviços que suportam o desenvolvimento de

aplicações sensíveis ao contexto colaborativas:

Monitor: É um daemon executando em cada dispositivo móvel que é encarregado

de coletar dados relativos ao estado do dispositivo, de execução, conectividade ou

ambiente, e enviar tais informações para o CIS (Context Information Service) executando

em um (ou mais) nó(s) da rede cabeada. Os dados coletados incluem a qualidade da

conexão sem fio, o nível de energia, a utilização de CPU, memória livre, Ponto de Acesso

802.11 corrente e uma lista com todos os Pontos de Acesso no alcance do dispositivo,

cada um com sua respectiva intensidade de sinal (RSSI – Received Signal Stregth

Indicator).

Projeto Final


Figura 1 - Arquitetura típica de uma aplicação cliente/servidor MoCA

Context Information Service (CIS): é um serviço distribuído no qual cada

servidor CIS recebe e processa dados brutos de contexto obtidos de um número qualquer

de dispositivos móveis, enviados por seus respectivos Monitores. Cada servidor trata

consultas diretas sobre o valor corrente de variáveis de contexto específicas de

dispositivos. Além disso, servidores CIS utilizam a Event-Based Communication

Interface (ECI) para aceitar subscrições de aplicações (ou outros serviços) com

expressões de sintaxe semelhante a SQL sobre variáveis de contexto, para serem

notificadas quando tais expressões de interesse forem satisfeitas. Um dos clientes deste

serviço é o Location Inference Service, que consulta periodicamente os servidores CIS

sobre os conjuntos de intensidade de sinal medidos em todos os dispositivos monitorados.

Location Inference Service (LIS): É responsável por inferir e disponibilizar a

localização simbólica de dispositivos móveis em áreas cobertas por Pontos de Acesso de

redes IEEE 802.11. Para isso, utiliza a intensidade de sinais coletados pelo CIS de todos

os dispositivos móveis (i.e. seus monitores).

Projeto Final


Basicamente, a idéia é comparar um histograma contruído com o vetor corrente

de RSSI (Received Signal Strength Indication) (onde cada elemento do vetor corresponde

ao sinal de um AP no alcance de dispositivo) com os histogramas construídos com

vetores medidos anteriormente em pontos pré-definidos em um prédio ou ambiente

externo.

Portanto, em uma primeira etapa (fase de calibração) amostras de vetores RSSI

são coletadas em pontos de referência bem definidos na(s) área(s) de interesse, e

armazenados em histogramas no banco de dados do LIS. Durante esta calibração, em

cada ponto de referência, amostras de vetores RSSI são coletadas com o dispositivo

voltado para várias direções. Considerando que sinais de rádio são suscetíveis à intensa

variação e interferência, a precisão da inferência da localização depende fortemente do

número de Pontos de Acesso, do número de pontos de referência escolhidos e do número

de vetores RSSI coletados.

Após a fase de calibração, o LIS é capaz de realizar a inferência da localização de

um dispositivo. Isto é feito através da comparação (estimativa da “distância” entre) o

vetor RSSI corrente do dispositivo e os vetores RSSI coletados nos pontos de referência

na área de interesse.

O LIS é direcionado a aplicações que necessitam conhecer a posição de um

dispositivo em termos de regiões simbólicas (ao invés de coordenadas), onde tais regiões

simbólicas são áreas geográficas não menores do que 1 a 4m quadrados, e.g. salas, partes

de salas maiores, setores de uma rua, etc. Devido à flutuação intrínseca no sinal de rádio,

a inferência da localização baseada em RSSI não é capaz de oferecer resultados com

maior precisão. Entretanto, a precisão da localização obtida pelo LIS é suficiente para

uma grande classe de aplicações sensíveis à localização.

O serviço provê interfaces para modos de comunicação síncrono e assíncrono. No

modo síncrono, os clientes podem realizar requisições através de um protocolo simples

da forma request/reply. No modo assíncrono os clientes se subscrevem no LIS para

receber eventos assíncronos relativos a mudanças na localização de dispositivos. O

último modo foi implementado utilizando a Event-based Communication Interface (ECI).

Nos dois modos de acesso, consultas (ou subscrições) podem se referir a um dispositivo

(e.g. recuperar a localização do dispositivo) ou a uma região (e.g. recuperar a localização

Projeto Final


de um conjunto de dispositivos dentro de uma região). De fato, o acesso específico por

regiões provou ser bastante útil para diversas aplicações sensíveis à localização.

Symbolic Region Manager (SRM): Serviço que permite estabelecer uma relação

entre as regiões atômicas definidas pelo (LIS), descrevendo uma hierarquia em que

regiões podem estar subordinadas a outras, ou seja, contidas em outras regiões.

Configuration Service (CS): serviço encarregado de guardar e manter

informações de configurações de todos os dispositivos móveis. As informações de

configuração são armazenadas em tabelas hash onde cada entrada na tabela (indexada

pelo endereço MAC do dispositivo) guarda os endereços do servidor CIS e de um

Discovery Service e a periodicidade com a qual o Monitor deverá enviar informações do

dispositivo para o CIS.

Discovery Service (DS): é encarregado de guardar informações como nome,

propriedades, endereços, e etc, de qualquer aplicação ou serviço registrado no

middleware MoCA, para que sejam descobertos por seus clientes automaticamente.

Projeto Final


1.2 Motivações

1.2.1 Portabilidade da MoCA para Palmtops

A MoCA foi desenvolvida utilizando a linguagem Java de programação em sua

versão 1.4, para a qual, há até pouquíssimo tempo atrás, não existia uma máquina virtual

destinada à dispositivos do tipo Palmtop que suportasse as classes contidas naquela

versão. Utilizando Java 1.4, apenas poderiam ser utilizadas as tradicionais máquinas

virtuais Java (Java Virtual Machines) destinadas aos principais sistemas operacionais, tais

como Windows, Linux e Unix em Geral. Além disso, a atual implementação do Monitor

foi desenvolvida para a plataforma Windows NT / XP. Portanto, a arquitetura só atendia

aos computadores com capacidade de executar esse sistema operacional, tais como

Desktops, Notebooks e Tablet-PCs.

Para que a arquitetura efetivamente pudesse atender aos dispositivos portáteis de

menor porte, novas versões das APIs (que executam no lado do cliente) e componentes

existentes deveriam ser re-implementados para plataformas que executassem em uma

variedade maior de dispositivos móveis. Tal implementação representaria na verdade um

atraso, pois para que as APIs funcionassem nas JVMs (para dispositivos do tipo Palmtop)

existentes, elas deveriam ser portadas para uma versão anterior da linguagem Java, e.g.

Java 1.3, pois tais JVMs apresentavam só suportavam um sub-conjunto das classes dessa

versão.

No início do ano de 2006, antes que qualquer trabalho de re-implementação fosse

realizado, foi lançada pela IBM uma nova versão da máquina virtual J9 destinada à

dispositivos portáteis, que implementa a nova especificação da Sun Microsystems para o

padrão CLDC 1.1, que suporta um subconjunto de classes da linguagem Java 1.4

permitindo portanto que algumas APIs da MoCA pudessem ser utilizadas em PDAs

(Personal Data Assinstants) do tipo Pocket PCs. Entretanto, permanecia ainda necessária

uma versão do Monitor que funcionasse para tais dispositivos até que a realização desse

projeto fosse proposta.

Projeto Final


1.2.2 Novos Requisitos para o Serviço de Localização

A Inferência do Serviço de Localização (LIS) da MoCA não possui precisão

absoluta. Testes realizados mostraram um erro de no máximo 4 metros para 90% dos

casos. Devido à interferência pela a qual redes de radio freqüência são suscetíveis, a

confiabilidade da inferência não é garantida, ou seja, a informação correta da localização

é afetada em uma porcentagem dos casos.

A tecnologia de redes IEEE 802.11 vem tornando-se cada vez mais difundida e

utilizada no dia a dia das pessoas e já é presente em um grande número de ambientes

internos. Entretanto, para diversas aplicações seria interessante um serviço de localização

capaz de funcionar em ambientes internos e externos, e em uma maior escala. A

tecnologia GPS é bastante disseminada e uma integração do LIS com este sistema pode

ser considerada como um passo natural na evolução do serviço. O projeto do LIS foi

realizado de forma a tornar possível a inclusão de novos requisitos e adição de novos

componentes, logo a inclusão desta nova funcionalidade não afetaria as características

básicas da arquitetura. Naturalmente, os dispositivos móveis utilizados deverão estar

equipados com um receptor GPS além da interface de rede IEEE 802.11, sendo este um

requisito que já pode ser considerado viável considerando que é cada vez mais comum

encontrar este tipo de hardware em dispositivos móveis.

Para permitir a integração da tecnologia GPS ao middleware MoCA de uma

forma que a infra-estrutura existente seja aproveitada e que não ocorram mudanças

significativas na arquitetura, a coleta dos dados de GPS do dispositivo deverá ser

realizada também pelo Monitor, o qual enviará esta informação tal como todas as outras

informações de contexto para o CIS.

Projeto Final


1.3 Usuários-alvo

Os usuários que utilizarão a aplicação deverão ser na maioria das vezes

desenvolvedores de aplicações sensíveis a contexto ou localização e que utilizem o

middleware MoCA interagindo diretamente com o Monitor para testar suas aplicações.

Será possível também o uso pelos usuários finais de aplicações que não saibam que estão

utilizando o Monitor, já que este poderá estar sendo executado em segundo plano e que a

aplicação que estiver interagindo com o middleware não deixe explícita esta utilização.

Aplicações executando no mesmo dispositivo que o Monitor poderão também realizar

consultas diretamente para obter informações de contexto do dispositivo ou para saber

quais informações estão sendo enviadas para os servidores de contexto.

Em geral, o Monitor poderá ser utilizado por qualquer usuário/aplicação/serviço

que queira obter informações de contexto sobre o dispositivo, a rede sem fio ou GPS.

Uma outra utilidade para o Monitor é descobrir a existência de Pontos de Acesso na

proximidade do dispositivo. O provável cenário de utilização é no ambiente universitário

com estudantes que desejam realizar experimentos com aplicações sensíveis a contexto

e/ou com dispositivos móveis em lugares abertos ou dentro de edifícios.

Projeto Final


1.4 Ambiente Computacional

A aplicação foi desenvolvida para ser executada no sistema operacional Microsoft

Windows CE, incluído dentro da plataforma Microsoft Windows Mobile, um conjunto de

utilitários, aplicações e sistema operacional que é disponibilizado para dispositivos

móveis que possuem poder de processamento, capacidade gráfica e de armazenamento

medianas, tais como PDAs (Personal Data Assistants) do tipo Pocket PC ou Smartphone.

A Figura 1 mostra um exemplo de PDA do tipo Pocket PC que utiliza a plataforma

Windows Mobile 5.0. Esse dispositivo possui um processador de 416MHz, 64MB de

memória RAM e 128MB de memória ROM, Wi-fi, Bluetooth, GPS e Infravermelho

integrados e uma tela TFT de 3.5’’, além da possibilidade da utilização de cartões de

memória SD (que possuem grande capacidade de armazenamento, e.g. 1GB).

Figura 2 Exemplo de Pocket PC com Windows Mobile 5.0

O ambiente para o desenvolvimento da aplicação foi o Microsoft Visual Studio

.NET 2005, utilizado no sistema operacional Microsoft Windows XP Professional. O

Visual Studio 2005 contém funcionalidades específicas para o desenvolvimento de

aplicações destinadas à dispositivos móveis e possui uma total integração com todas as

APIs dos sistemas operacionais deste tipo de dispositivo. Além disso, este Ambiente de

Desenvolvimento Integrado contém emuladores que reproduzem com fidelidade alguns

dos principais dispositivos, permitindo que aplicações desenvolvidas para eles sejam

Projeto Final


testadas mesmo que tais dispositivos não estejam disponíveis. A ferramenta permite

também que a aplicação seja compilada e depurada diretamente dentro do dispositivo

real, possibilitando uma depuração completa do código executando realmente dentro do

dispositivo em questão, através da integração do Visual Studio com a ferramenta de

sincronização com dispositivos móveis Microsoft Active Sync. Tal funcionalidade é de

extrema importância para o processo de desenvolvimento, pois comportamentos da

aplicação relacionados a dados específicos de hardware, conectividade e etc, seriam

difíceis de reproduzir utilizando apenas um emulador de dispositivo.

Foram utilizadas duas linguagens de programação para o desenvolvimento do

Monitor CE e a aplicação foi projetada com as seguintes partes:

MoCAMonitorDllCE: Para a realização da coleta de dados do dispositivo, tais

como utilização de CPU, memória livre, nível de energia, informações de conectividade

(endereço IP, endereço MAC e etc), e informações da rede sem fio (Pontos de Acesso e

etc) foi necessária a utilização da linguagem C, que é a linguagem nativa do sistema

operacional Windows CE e que permite a utilização de APIs que contêm chamadas

diretas ao sistema e a chamadas que consultam os drivers de dispositivos para a obtenção

de informações específicas dos mesmos. Foi então criada uma biblioteca dinâmica (Dll)

em C contendo os métodos que realizam a obtenção dos dados mencionados acima do

MoCAMonitorDllCE (C)

MoCAMonitor (C# .NET CF)

NDIS

MoCAMonitorInterfaceCE (C# .NET CF)

Windows CE API

GPSID

MoCAMonitorGPSDllCE (C)

Projeto Final


dispositivo móvel. A Figura 2 mostra a MoCAMonitorDllCE, a dll que possui os

métodos que realizam a consulta às informações do dispositivo. Para a obtenção de dados

do dispositivo de rede, os métodos responsáveis por esta tarefa consultam a interface

NDIS da Microsoft que será explicada a seguir.

NDIS: O Monitor coleta informações de conectividade do dispositivo de rede, tais

como endereço IP, máscara da rede e endereço MAC. Coleta também informações da

rede sem fio, tais como endereço MAC do Ponto de Acesso corrente (informação

conhecida como BSSID - Basic Service Set IDentifier) e realiza também uma operação

chamada scan, uma consulta que retorna todos os Pontos de Acesso no alcance do

dispositivo com suas respectivas intensidades de sinal em decibéis (informação utilizada

pelo serviço de localização (LIS) da MoCA).

Para obter as informações de conectividade e da rede sem fio, é utilizada a

arquitetura de rede da microsoft, conhecida por Network Driver Interface Specification

(NDIS). O NDIS define uma API padrão para diversas interfaces de rede (NIC’s –

Network Interface Cards) oferecendo uma biblioteca de funções (conhecida também

como “wrapper”) que pode ser utilizada por drivers MAC assim como por protocolos de

mais alto nível (tais como o TCP/IP). As funções do “wrapper“ facilitam o

desenvolvimento de drivers de MAC e de protocolos escondendo dependências de

plataformas específicas. Além disso, aplicações podem realizar consultas aos drivers de

dispositivos de forma genérica.

Os detalhes de implementação do hardware de uma interface de rede são

organizados pelos drivers de controle de acesso ao meio (MAC – Media Access

Controller) de uma forma que todos os NIC’s destinados a um mesmo tipo de meio (e.g

Ethernet) podem ser acessados utilizando uma interface comum de programação.

Como ilustrado na figura abaixo, a comunicação entre a aplicação e o driver da

placa de rede sem fio não é direta. Dessa forma, a implementação do monitor torna-se

independente do fabricante da placa de rede sem fio, pois toda a comunicação entre o

monitor e o driver da placa de rede ocorre via a NDIS Wrapper.

As consultas realizadas ao NDIS no código da MoCAMonitorDllCE estão

documentadas no próprio código fonte da Dll e podem ser encontradas no CD que

acompanha este projeto.

Projeto Final


NDIS Protocol Driver: - driver de protocolo da NDIS que interage com a NDIS

Wrapper para enviar e receber pacotes através do driver da placa de rede sem fio (NDIS

Miniport Driver). Esse driver é específico para cada sistema operacional (oferecido pelo

Windows CE);

NDIS Wrapper: - driver no modo kernel que exporta um conjunto de interfaces

de software definidas pela NDIS para interagir com o driver da placa de rede. A NDIS

Wrapper isola o driver da placa de rede sem fio das aplicações. Desta forma, é possível

acessar o driver de placas de diferentes fabricantes através do mesmo conjunto de

interfaces.

Windows CE API: As informações do dispositivo, utilização de CPU, memória

livre do sistema e nível de energia, são obtidas utilizando APIs específicas do Microsoft

Windows CE. Os métodos que realizam a chamada a esta API estão na Dll

MoCAMonitorDllCE.

Projeto Final


MoCAMonitorGPSDllCE: Para o acesso às informações de GPS, tais como

latitude, longitude e altitude, foi utilizada a linguagem de programação C e foi criada uma

biblioteca dinâmica (dll) que contém métodos que realizam chamadas nativas à API

GPSID oferecida pelo sistema operacional Windows CE 5.0 e é explicada a seguir.

GPSID(GPS Intermediate Driver): O Windows Mobile 5.0 é a mais nova versão

da plataforma que contém o Windows CE 5.0 e foi lançado no início do ano de 2005. Ele

foi desenvolvido com o objetivo de prover acesso as mais novas características dos

dispositivos móveis mais modernos, que contém melhor suporte à multimídia, displays

melhores com capacidades 2D e 3D, integração com câmeras, assim como integração

com o GPS. Cada vez mais dispositivos aparecem no mercado equipados com um

receptor de GPS, embutido ou como assessório adicional.

Diversos aspectos envolvem o acesso às capacidades do GPS e os

desenvolvedores geralmente têm que resolver problemas complexos tais como se

comunicar com portas seriais, executar diversas threads e realizar o parsing de seqüências

NMEA ( especificação da National Marine Electronics Association para comunicação de

dispositivos eletrônicos, no caso o GPS). Para resolver estas dificuldades e para

padronizar o acesso de aplicações aos dispositivos GPS em geral, o novo Windows

Mobile 5.0 oferece uma nova API chamada GPS Intermediate Driver (GPSID).

O GPSID é como uma camada intermediária entre o hardware GPS e aplicações

cliente que acessam GPS. Essa API padroniza o acesso das aplicações a qualquer

dispositivo GPS de qualquer fabricante, permite que diversas aplicações executando no

mesmo dispositivo possam acessar o hardware GPS ao mesmo tempo e realiza o parsing

das seqüências NMEA transparentemente para a aplicação, oferecendo estruturas de

dados prontas para a realização de consultas aos dados que interessam. O acesso a esta

API está documentado no próprio código fonte da aplicação Monitor CE. Os métodos que

realizam a chamada a esta API estão na Dll MoCAMonitorDllCE.

MoCAMonitor e MocaMonitorInterfaceCE: Toda a lógica da aplicação e a

interface gráfica foram implementadas na linguagem C# da plataforma .NET de

programação utilizando o Microsoft .NET Compact Framework 2.0. O Microsoft .NET

Compact Framework é um subconjunto da Microsoft .NET Framework, criado para

Projeto Final


possibilitar o desenvolvimento de aplicações para dispositivos móveis da mesma forma

com que aplicativos para Windows. A .NET Compact Framework, por ser um

subconjunto da .NET Framework, herdou muitas de suas características e formas de

execução. Todos os códigos desenvolvidos para serem executados sob a .NET CF são

executados por um compilador de alta performance, denominado Compilador JIT (Just In

Time Compiler). Este compilador é responsável por otimizar o código para o dispositivo

onde o software será executado. Ou seja, o mesmo software é otimizado para ser

executado em dispositivos que possuem recursos de hardware ou software diferentes. Por

baixo do Compilador JIT, a CLR (Common Language Runtime) juntamente com uma

coleção de classes (Class Library) permite uma gerência de processos otimizada para ser

executada em equipamentos com recursos limitados. Pensando nesses dispositivos, a

CLR foi otimizada para que permitisse que tudo o que era possível ser feito com a .NET

Framework, também fosse possível de ser feito com a .NET CF, sendo executada nos

mais diversos e diferentes equipamentos.

Além das vantagens apresentadas acima, algumas outras vantagens motivaram o

desenvolvimento dessa parte da aplicação Monitor CE utilizando a linguagem C# com a

plataforma .NET CF. Primeiramente, a ferramenta para a construção de interfaces

gráficas com o usuário oferecidas pelo Visual Studio para esta linguagem é extremamente

superior a aquela destinada à linguagem C/C++ de programação. Utilizando essa

ferramenta, a interface pode ser implementada de forma mais rica e detalhada, bem como

com um esforço de programação muito menor para sua construção. O código se mostrou

bem melhor organizado e fácil de ser mantido do que a versão que existia em C++ Win32

na versão do Monitor XP e poderá inclusive ser utilizado no Windows XP tendo que ser

mudada apenas a Dll que realiza as consultas ao dispositivo.

Projeto Final


2 Estado da arte

2.1 Descrição e avaliação de tecnologias e aplicações existentes

A aplicação Monitor XP é uma implementação da ferramenta proposta, para o

sistema operacional Microsoft Windows XP que realiza com sucesso o envio de

informações de contexto para o CIS (menos informações de GPS). Porém, como foi

mencionado anteriormente, tal ferramenta só pode ser utilizada em dispositivos que

utilizem tal sistema operacional e esses dispositivos são em geral Laptops ou Tablet PCs

que, apesar de serem móveis, não oferecem mobilidade tal como a dos dispositivos

portáteis do tipo PDA (ou Palmtops).

O código da aplicação existente em C++ não pode ser utilizado no sistema

operacional Windows CE, pois as APIs do sistema operacional e a forma de interação

com os drivers de dispositivos não são as mesmas. A interface gráfica oferecida para

dispositivos móveis é diferente, pois é destinada a dispositivos com capacidade gráfica

reduzida e um espaço de tela muito menor e a aplicação existente não separa a

implementação de sua interface gráfica, implementada utilizando a API gráfica do

Windows Win32 de uma forma que a lógica da aplicação possa ser utilizada no Windows

CE.

O projeto do Monitor CE foi realizado de forma a promover o reaproveitamento

de código tanto para a versão CE como para a versão XP. Toda a lógica principal da

aplicação foi programada com a linguagem C# utilizando a Microsoft .NET Compact

Framework 2.0 que é um subconjunto da Microsoft .NET Framework 2.0 sendo o código

desenvolvido para a primeira, apto a ser utilizado pela segunda, ou seja, um código C#

.NET desenvolvido para dispositivos móveis com Windows CE poderá ser utilizado no

Windows XP. Além disso, o código C# é muito melhor organizado, fácil de entender,

programar e manter do que o código C++, uma característica importante para motivar os

alunos do ambiente universitário a contribuírem mais rapidamente com o projeto.

O código da dll que contém as chamadas específicas ao sistema operacional, para

obter dados de contexto do dispositivo, pode ser trocada de acordo com a versão do

Projeto Final


sistema que se queira utilizar. Um trabalho ainda a ser realizado é incluir diretivas de

compilação no código desta biblioteca para que possam ser mantidos no mesmo arquivo

os códigos para a utilização dos dois diferentes sistemas operacionais.

O QuickBoard 2006 e o ResourceONE 1.0 da empresa Tonaya Technologies

Corp. (http://www.tonaya.com) são coletores de informações sobre o dispositivo que as

exibem na interface com o usuário. Entretanto não foi encontrado em suas

documentações sinal de que esses produtos possibilitem o envio das informações

monitoradas a algum serviço ou aplicação cliente que possam estar interessados nestas

informações. Além disso, informações relativas às redes sem fio, tais como Access Points

e também informações de localização GPS não são coletadas.

Projeto Final


3 Objetivos do Projeto

Inicialmente pretendeu-se desenvolver um serviço de localização que integrasse o

atual LIS, baseado no padrão de intensidades de sinal de radiofreqüência, com a

tecnologia GPS de forma a realizar o mapeamento de regiões simbólicas para

coordenadas geográficas. Entretanto, a infra-estrutura não estava pronta para atender aos

requisitos de um serviço como esse, já que, como mencionado anteriormente, não havia

um componente Monitor que funcionasse em dispositivos portáteis do tipo Palmtop (mais

especificamente Pocket PCs) e que coletasse as informações do GPS. Portanto o

desenvolvimento do serviço teria uma etapa inicial de adequação da arquitetura / infra-

estrutura aos novos requisitos, que representaria juntamente com o tempo de projeto e

implementação do serviço em si, uma carga de desenvolvimento não viável para ser

realizado por um aluno apenas durante os períodos do projeto final. Portanto, o escopo do

projeto foi direcionado a criar um mecanismo básico para a coleta de informações de

contexto de dispositivos portáteis incluindo a localização GPS para dispositivos com esta

capacidade:

• Desenvolver um componente de software que execute em segundo plano

(daemon) em dispositivos portáteis do tipo Pocket PC, com o Sistema

Operacional Windows CE, coletando periodicamente dados de contexto do

dispositivo, tais como: memória livre no sistema, nível de energia, endereços IP e

MAC, Ponto de Acesso corrente, lista de Pontos de Acesso no alcance do

dispositivo e coordenadas geográficas GPS (quando disponível), e etc, enviando

tais dados para o Serviço de Informações de Contexto (CIS) da MoCA ou

qualquer outra aplicação/serviço que necessite obter informações de contexto dos

dispositivos móveis. Tal desenvolvimento deverá ser realizado através da

reestruturação e re-implementação do atual componente Monitor XP de forma a

portá-lo para o sistema Windows CE e promover a máxima reutilização de código

para ambas as versões do componente para diferentes sistemas operacionais.

• Atender aos novos requisitos do Sistema de Inferência de Localização, dando

início ao processo de integração com a tecnologia GPS, além de possibilitar

Projeto Final


atender a futuros requisitos, com a inclusão da coleta da informação de GPS em

dispositivos que ofereçam esta tecnologia.

Projeto Final


4 Projeto e especificação da aplicação

4.1 Modelo de dados

4.1.1 Diagrama de classes

Projeto Final


4.1.2 Dicionário de dados Classe: MocaMonitorCE

É a classe principal do Monitor CE, onde são armazenados todos os dados e as

referências para todos os outros componentes que realizam tarefas específicas. A classe

MocaMonitorCE cria e controla quatro diferentes threads: A DeviceDataThread,

responsável por coletar periodicamente dados de conectividade e do dispositivo, a

ScanDataThread, responsável por realizar periodicamente scans na rede sem-fio obtendo

Pontos de Acesso no alcance do dispositivo, a GPSDataThread que periodicamente coleta

dados do dispositivo GPS e a SendDataThread, que é responsável por enviar

periodicamente todos os dados coletados pelo monitor para o CIS. Campos Nome Tipo do Dado Modificador

de Acesso Descrição

cpuUsage String private Representa a porcentagem de CPU em utilização no sistema. Ex: “12 %”

freeMem String private Representa a quantidade de memória livre no sistema em KBs. Ex: “32768 KBs”

powerStatus String private Representa a porcentagem de energia contida na bateria principal do dispositivo. Ex: “80 %”

currentIP String private Representa o endereço IP corrente do dispositivo. Ex: “10.10.10.150”

currentMask String private Representa a máscara da sub-rede corrente do dispositivo. Ex: “255.255.255.0”

macAddr String private Representa o endereço MAC da interface de rede do dispositivo. Ex: “00:02:3F:7C:77:50”

currentApMacAddr string private Representa o endereço MAC do Ponto de Acesso corrente da rede sem fio IEEE802.11, também conhecido como

Projeto Final


BSSID (Basic Service Set Identifier) Ex: “00:02:3F:7C:77:50”

lastCurrentApMacAddr String private Representa o endereço MAC (BSSID) do último Ponto de Acesso antes de uma mudança entre Pontos de Acesso em uma rede sem fio IEEE 802.11 caso esta tenha ocorrido. Ex: 00:02:3F:7C:12:07”

lastCurrentIP String private Representa o último endereço IP do dispositivo antes de uma mudança, caso essa tenha ocorrido. Ex: “10.10.10.149”

ipChange bool private Flag booleana que indica se uma mudança de endereço IP ocorreu. Ex: 1

apChange bool private Flag booleana que indica se ocorreu uma mudança entre Pontos de Acesso. Ex: 1

serializedApList String private Representa uma serialização da lista de Pontos de Acesso detectados após uma operação de scan na rede sem-fio IEEE 802.11 da forma AP1&AP2&APn, onde APn é a representação de um Ponto de Acesso com a forma: Endereço MAC#RSSI#Identificador do Ponto de Acesso

scanList ArrayList private Lista do tipo ArrayList com objetos do tipo AccessPoint, que representam Pontos de Acesso detectados por uma operação de scan na rede sem-fio IEEE 802.11.

satellitesInViewCount String private Número de satélites detectados pelo dispositivo GPS.

satellitesInUseCount String private Número de satélites utilizados pelo dispositivo GPS para a inferência da localização.

fixQuality string private Qualidade da inferência da localização, pode ser inválida,

Projeto Final


GPS ou GPS Diferencial Latitude String private Latitude em graus. Números

positivos indicam latitudes Norte, números negativos indicam latitudes Sul.

longitude String private Longitude em graus. Números positivos indicam latitudes Leste, números negativos indicam latidudes Oeste.

Altitude String private Altitude em metros com relação ao nível do mar.

gpsCoordinatesStr String private String com as coordenadas geográficas latitude, longitude e altitude correntes do dispositivo obtidas do GPS. Ex: “22º58'47.98"S 43º14'01.41"W 30m”

serializedMonitorData String private Serializa todos os dados coletados pelo Monitor na forma: CPU#Memória Livre#Energia #Periodicidade#Mudança IP #Mudanca AP#IP#Máscara #Endereco MAC#Endereço MAC AP corrente &AP1&AP2&AP3&APn, onde APn é a representação de um Ponto de Acesso com a forma: Endereço MAC #RSSI#Identificador do Ponto de Acesso

cisAddress String private Endereço IP do Context Information Service da MoCA, o serviço que receberá as informações de contexto coletadas pelo Monitor.

cisPort int private Porta do Context Information Service da MoCA, o serviço que receberá as informações de contexto coletadas pelo Monitor.

dsAddress String private Endereço IP do Discovery Service da MoCA, o serviço que fornece os endereços dos demais serviços.

Projeto Final


dsPort int private Porta do Discovery Service da MoCA, o serviço que fornece os endereços dos demais serviços.

csAddress String private Endereço IP do Configuration Service da MoCA, o serviço que fornece configurações automaticamente para o Monitor.

csPort int Porta do Configuration Service da MoCA, o serviço que fornece configurações automaticamente para o Monitor.

sendDataPeriodicity int private Periodicidade para o envio de informações ao CIS.

devDataPeriodicity int private Periodicidade para a coleta de informações do dispositivo e de conectividade.

scanDataPeriodicity int private Periodicidade para a realização de scans na rede sem-fio para a obtenção de Pontos de Acesso.

gpsDataPeriodicity int private Periodicidade para a coleta de dados GPS.

cardQueryInterval int private Tempo de espera por resultados após uma operação de scan na rede sem-fio.

gpsQueryInterval int private Tempo de espera por resultados após a requisição de dados ao dispositivo GPS.

deviceDataThread DeviceDataThread private Implementa uma thread para a coleta de dados do dispositivo e de conectividade.

threadGetDevData Thread private Classe do sistema para executar a thread DeviceDataThread.

flagDeviceData bool private Flag de controle que ativa e desativa a DeviceDataThread.

scanDataThread ScanDataThread private Implementa uma thread para a realização de scans na rede sem-fio para obtenção de Pontos de Acesso.

threadGetScanData Thread private Classe do sistema para executar a thread ScanDataThread.

Projeto Final


flagScanData bool private Flag de controle que ativa e desativa a ScanDataThread.

gpsDataThread GPSDataThread private Implementa uma thread para a coleta de dados do dispositivo GPS.

threadGetGPSData Thread private Classe do sistema para executar a thread GPSDataThread.

flagGPSData bool private Flag de controle que ativa e desativa a GPSDataThread.

sendDataThread SendDataThread private Implementa uma thread para o envio das informações de contexto coletadas para o CIS.

threadSendData Thread private Classe do sistema para executar a thread SendDataThread.

flagSendData bool private Flag de controle que ativa e desativa a SendDataThread.

mainForm MocaMonitorInterface private Referência para a Interface Gráfica com o Usuário do Monitor.

Propriedades Nome Tipo do Dado Modificador de

Acesso Descrição

FlagDeviceData Bool public Obtém o valor da flag de controle da DeviceDataThread.

FlagScanData Bool public Obtém o valor da flag de controle da ScanDataThread.

FlagGPSData Bool public Obtém o valor da flag de controle da GPSDataThread.

FlagSendData Bool public Obtém o valor da flag de controle da SendDataThread.

CISAddress String public Obtém o endereço definido do CIS

CISPort Int public Obtém a porta definida do CIS

DSAddress String public Obtém o endereço definido do DS

Projeto Final


DSPort Int public Obtém a porta definida do DS

CSAddress String public Obtém o endereço definido do CS

CSPort Int public Obtém a porta definida do CS

Construtores: Cria uma instância do tipo MocaMonitorCE public MocaMonitorCE() Cria uma nova instância do tipo MocaMonitorCE especificando uma interface com o usuário MocaMonitorInterface.

_mainForm Referência a uma instancia de MocaMonitorInterface, uma Interface com o Usuáiro para o MocaMonitorCE.

public MocaMonitorCE(MocaMonitorInterface _mainForm) Métodos: Obtém a Interface Gráfica com o Usuário MocaMonitorInterface public MocaMonitorInterface GetInterfaceInstance() Define a Interface Gráfica com o usuário do Monitor CE

_mainForm Referência à instância do MocaMonitorInterface a ser definida.

public void SetInterfaceInstance(MocaMonitorInterface _mainForm)

Projeto Final


Define os dados de contexto correntes do dispositivo. _cpuUsage Uma string representando a porcentagem corrente de utilização de CPU no sistema. _freeMem Uma string representando a quantidade corrente de memória livre no sistema (em KBs). _powerStatus Uma string representando a porcentagem corrente de energia na bateria principal do dispositivo. _macAddr Uma string representando o endereço MAC da interface de rede do dispositivo. _currentApMacAddr Uma string representando o endereço MAC do Ponto de Acesso corrente (BSSID). _currentIP Uma string representando o endereço IP do dispositivo. _currentMask Uma string representando a máscara da sub-rede do dispositivo. _lastCurrentApMacAddr Uma string representando o endereço MAC do último Ponto de Acesso caso uma mudança entre Pontos de Acesso tenha ocorrido. _lastCurrentIP Uma string representando o último endereço IP do dispositivo caso este tenha mudado. _ipChange Uma flag booleana indicando se o dispositivo mudou de endereço IP. _apChange Uma flag booleana indicando se o dispositivo mudou de Ponto de Acesso.

public void SetDeviceData( string _cpuUsage, string _freeMem, string _powerStatus, string _macAddr, string _currentApMacAddr, string _currentIP, string _currentMask, string _lastCurrentApMacAddr, string _lastCurrentIP, bool _ipChange, bool _apChange) Define os endereços IP e portas dos serviços da MoCA Context Information Service (CIS), Discovery Service (DS) e Configuration Service (CS)

_cisAddress Uma string representando o endereço IP do Context Information Service (CIS). _cisPort Um inteiro representando a porta do Context Information Service (CIS). _sendDataPeriodicity Um inteiro representando a periodicidade (em ms) de envio de informações de contexto para o CIS. _dsAddress Uma string representando o endereço IP do Discovery Service (DS). _dsPort Um inteiro representando a porta do Discovery Service (DS). _csAddress Uma string representando o endereço IP do Configuration Service (CS). _csPort inteiro representando a porta do Configuration Service (CS).

public void SetServicesData( string _cisAddress, int _cisPort, int _sendDataPeriodicity, string _dsAddress, int _dsPort,

Projeto Final


string _csAddress, int _csPort) Define os dados de scan para o dispositivo, identificando todos os Pontos de Acesso no alcance do dispositivo e suas respectivas intensidades de sinal.

_apList Uma string com uma serialização da lista de todos os Pontos de Acesso identificados dentro do alcance do dispositivo com suas respectivas intensidades de sinal. _scanList Uma lista do tipo ArrayList com intâncias de objetos do tipo AccessPoint representando os Pontos de Acesso encontrados no alcance do dispositivo.

public void SetScanData(string _apList, ArrayList _scanList) Define os dados coletados pelo GPS.

_satellitesInViewCount Uma string representando o número de satélites detectados pelo dispositivo GPS. _satellitesInUseCount Uma string representando o número de satélites utilizados para inferir a localização do dispositivo. _fixQuality Uma string representando a qualidade dos dados GPS, que podem ser do tipo Inválido (No Fix), GPS ou DGPS (Differential GPS) _latitude Uma string representando a latitude do dispositivo em graus. Números positivos indicam latitudes Norte, números negativos indicam latitudes Sul. _longitude Uma string representando a longitude do dispositivo em graus. Números positivos indicam longitudes Leste, números negativos indicam longitudes Oeste. _altitude Uma string representando a altitude em metros com relação ao nível do mar. _gpsCoordinatesStr Uma string com as coordenadas geográficas do dispositivo: latitude, longitude e altitude.

public void SetGPSData( string _satellitesInViewCount, string _satellitesInUseCount, string _fixQuality, string _latitude, string _longitude, string _altitude, string _gpsCoordinatesStr) Serializes all Monitor data as: Serializa todos os dados do Monitor como: CPU#Memória Livre#Energia#Periodicidade#Mudança IP#Mudança de AP# IP#Máscara#Endereço MAC#Endereço MAC do Ponto de Acesso Corrente&AP1&AP2&AP3&APn. Onde APn é uma representação de um Ponto de Acesso da forma: Endereço MAC#RSSI#Identificador AP public string SerializeData() Mostra dados de conectividade e do dispositivo na interface com o usuário. public void ShowDeviceData() Mostra dados dos serviços MoCA na interface com o usuário. public void ShowServicesData()

Projeto Final


Mostra dados do scan por Pontos de Acesso na interface com o usuário public void ShowScanData() Mostra dados coletados pelo GPS na interface com o usuário public void ShowGPSData() Shows the specified error message on the user interface Mostra uma mensagem de erro na interface com o usuário message Uma string com a mensagem de erro a ser exibida public void ShowErrorMessage(string message) Ativa a thread que coleta informações de conectividade e do dispositivo public void EnableDeviceDataThread() Desativa a thread que coleta informações de conectividade e do dispositivo public void DisableDeviceDataThread() Ativa a thread que realiza scans por Pontos de Acesso public void EnableScanDataThread() Desativa a thread que realiza scans por Pontos de Acesso public void DisableScanDataThread() Ativa a thread que coleta dados do dispositivo GPS public void EnableGPSDataThread() Desativa a thread que coleta dados do dispositivo GPS public void DisableGPSDataThread() Inicializa as variáveis dessa classe private void InitializeVariables() Carrega as configurações de um arquivo xml private bool LoadAppConfig()

Projeto Final


Classe: DeviceDataThread

É responsável por coletar periodicamente dados do dispositivo tais como:

porcentagem de utilização de CPU, memória livre, porcentagem de energia na bateria e dados de conectividade tais como: endereço IP, máscara da sub-rede,

endereço MAC, endereço MAC do Ponto de Acesso corrente, último endereço

IP e último endereço MAC do Ponto de Acesso.

Campos Nome Tipo do Dado Modificador


cpuUsage string private Representa a porcentagem de CPU em utilização no sistema. Ex: “12 %”

freeMem string private Representa a quantidade de memória livre no sistema em KBs. Ex: “32768 KBs”

powerStatus string private Representa a porcentagem de energia contida na bateria principal do dispositivo. Ex: “80 %”

currentIP string private Representa o endereço IP corrente do dispositivo. Ex: “10.10.10.150”

currentMask string private Representa a máscara da sub-rede corrente do dispositivo. Ex: “255.255.255.0”

macAddr string private Representa o endereço MAC da interface de rede do dispositivo. Ex: “00:02:3F:7C:77:50”

currentApMacAddr string private Representa o endereço MAC do Ponto de Acesso corrente da rede sem fio IEEE802.11, também conhecido como BSSID (Basic Service Set Identifier) Ex: “00:02:3F:7C:77:50”

lastCurrentApMacAddr string private Representa o endereço MAC (BSSID) do último Ponto de Acesso antes de uma mudança entre Pontos de Acesso em uma rede sem fio

Projeto Final


IEEE 802.11 caso esta tenha ocorrido. Ex: 00:02:3F:7C:12:07”

lastCurrentIP string private Representa o último endereço IP do dispositivo antes de uma mudança, caso essa tenha ocorrido. Ex: “10.10.10.149”

ipChange bool private Flag booleana que indica se uma mudança de endereço IP ocorreu. Ex: 1

apChange bool private Flag booleana que indica se ocorreu uma mudança entre Pontos de Acesso. Ex: 1

devDataQueryPeriodicity int private Periodicidade para a coleta de informações do dispositivo e de conectividade.

Construtores: Cria uma nova instância do tipo DeviceDataThread especificando a periodicidade em que a thread consulta informações do dispositivo e de conectividade e especificando uma referência à uma instância de um MocaMonitorCE. A DeviceDataThread coleta periodicamente, como definido pela variável devDataQueryPeriodicity, dados do dispositivo e de conectividade, tais como, utilização de CPU, memória livre no sistema, energia, endereço IP, máscara da sub-rede, endereço MAC e o endereço MAC do Ponto de Acesso corrente (BSSID).

_devDataQueryPeriodicity Um inteiro representando a periodicidade de consulta à informações do dispositivo e de conectividade. _mocaMonitorCE Referência para a instância to MocaMonitorCE.

public DeviceDataThread(int _devDataQueryPeriodicity, MocaMonitorCE _mocaMonitorCE) Métodos: Método para executar a DeviceDataThread public void runDeviceDataThread() Inicializa as variáveis dessa classe private void InitializeVariables()

Projeto Final


Classe: ScanDataThread

É responsável por realizar periodicamente varreduras (scans) na rede sem-fio para

obter os Pontos de Acesso que estão no alcance do dispositivo com suas respectivas

intensidades de sinal. Campos Nome Tipo do Dado Modificador


apList string private Representa uma serialização da lista de Pontos de Acesso detectados após uma operação de scan na rede sem-fio IEEE 802.11 da forma AP1&AP2&APn, onde APn é a representação de um Ponto de Acesso com a forma: Endereço MAC#RSSI#Identificador do Ponto de Acesso

scanList ArrayList private Lista do tipo ArrayList com objetos do tipo AccessPoint, que representam Pontos de Acesso detectados por uma operação de scan na rede sem-fio IEEE 802.11.

scanDataPeriodicity int private Periodicidade para a realização de scans na rede sem-fio para a obtenção de Pontos de Acesso.

cardQueryInterval int private Tempo de espera por resultados após uma operação de scan na rede sem-fio.

Construtores: Cria uma nova instância de ScanDataThread especificando a periodicidade do scan por Pontos de Acesso e especificando uma referência à instancia do MocaMonitorCE. A ScanDataThread realiza scans periodicamente de acordo como definido na variável scanDataPeriodicity.

_scanDataPeriodicity Um inteiro representando a periodicidade de realização de scans por Pontos de Acesso. _mocaMonitorCE Referência à instância do MocaMonitorCE.

public ScanDataThread( int _scanDataQueryPeriodicity, int _cardQueryInterval, MocaMonitorCE _mocaMonitorCE)

Projeto Final


Métodos: Método para executar a ScanDataThread public void runScanDataThread() Inicializa as variáveis dessa classe private void InitializeVariables() Extrai de uma string retornada pela MocaMonitorDllCE os dados referentes ao Pontos de Acesso e cria objetos do tipo AccessPoint incluindo-os na lista do tipo ArrayList scanList private void ExtractAPsData(string apList, ArrayList scanList)

Projeto Final


Classe: SendDataThread

É responsável por enviar periodicamente as informações de contexto coletadas

pelo Monitor para o Context Information Service (CIS) da MoCA. Campos Nome Tipo do Dado Modificador


serializedMonitorData string private Serializa todos os dados coletados pelo Monitor na forma: CPU#Memória Livre#Energia #Periodicidade#Mudança IP #Mudanca AP#IP#Máscara #Endereco MAC#Endereço MAC AP corrente &AP1&AP2&AP3&APn, onde APn é a representação de um Ponto de Acesso com a forma: Endereço MAC #RSSI#Identificador do Ponto de Acesso

sendDataPeriodicity int private Periodicidade para o envio de informações ao CIS.

Construtores: Cria uma nova instancia de SendDataThread especificando a periodicidade de envio de dados de contexto ao CIS e especificando uma referência à instância do MocaMonitorCE. A SendDataThread envia periodicamente dados de contexto para o CIS conforme definido na variável sendDataPeriodicity.

_sendDataPeriodicity Um inteiro representando a periodicidade de envio de dados para o CIS. _mocaMonitorCE Referência para a instancia do MocaMonitorCE

public SendDataThread( int _sendDataPeriodicity, MocaMonitorCE _mocaMonitorCE)

Métodos: Método para a execução da SendDataThread public void runSendDataThread() Inicializa as variáveis dessa classe private void InitializeVariables() Envia os dados coletados pelo Monitor para o CIS private void SendDataToCIS()

Projeto Final


Classe: GPSDataThread

É responsável por coletar periodicamente dados do dispositivo GPS, tais como

latitude, longitude e altitude do dispositivo. Campos Nome Tipo do Dado Modificador


satellitesInViewCount String private Número de satélites detectados pelo dispositivo GPS.

satellitesInUseCount String private Número de satélites utilizados pelo dispositivo GPS para a inferência da localização.

fixQuality String private Qualidade da inferência da localização, pode ser inválida, GPS ou GPS Diferencial

Latitude String private Latitude em graus. Números positivos indicam latitudes Norte, números negativos indicam latitudes Sul.

longitude String private Longitude em graus. Números positivos indicam latitudes Leste, números negativos indicam latidudes Oeste.

Altitude String private Altitude em metros com relação ao nível do mar.

gpsCoordinatesStr String private String com as coordenadas geográficas latitude, longitude e altitude correntes do dispositivo obtidas do GPS. Ex: “22º58'47.98"S 43º14'01.41"W 30m”

gpsDataPeriodicity int private Periodicidade para a coleta de dados GPS.

gpsQueryInterval int private Tempo de espera por resultados após a requisição de dados ao dispositivo GPS.

Projeto Final


Construtores: Cria uma nova instancia de GPSDataThread especificando a periodicidade da coleta de dados do dispositivo GPS e especificando uma referencia à instancia do MocaMonitorCE. A GPSDataThread obtém dados GPS periodicamente, como definido na variável gpsDataPeriodicity.

_gpsDataPeriodicity Um inteiro representando a periodicidade de coleta de dados GPS. _gpsQueryInterval Intervalo (em ms) de espera por resultados após consultar o dispositivo GPS. _mocaMonitorCE Referencia à instancia do MocaMonitorCE

public GPSDataThread( int _gpsDataQueryPeriodicity, int _gpsQueryInterval, MocaMonitorCE _mocaMonitorCE)

Métodos: Método para executar a GPSDataThread public void runGPSDataThread()

Projeto Final


Classe: MonitorDllWrap

É a classe que realiza interface com a MocaMonitorDllCE, a dll escrita em C++

que realiza de fato as consultas sobre informações do dispositivo e de conectividade

diretamente com o sistema. A MonitorDllWrap é um “wrapper” realiza uma conversão

em tempo de execução dos métodos da dll escrita em C++ para os métodos em C#

contidos nessa classe. Portanto, para a aplicação, esta classe representa a biblioteca em si,

e é acionada sempre que for necessária sua utilização, tal como seria a biblioteca se

pudesse ser acionada diretamente.

Métodos: Carrega os recursos da biblioteca. Este método deverá ser chamado antes da utilização de qualquer outro método da MonitorDllWrap. [DllImport("MocaMonitorDllCE.dll")] public static extern int loadLib(); Libera os recursos da biblioteca. Este método deverá ser chamado após a utilização da MonitorDllWrap para liberar os recursos utilizados por ela. [DllImport("MocaMonitorDllCE.dll")] public static extern void unloadLib(); Obtém informações sobre o dispositivo e de conectividade tais como: porcentagem corrent de utilização de CPU, memória livre no sistema, porcentagem de energia na bateria, endereço MAC, endereço MAC do Ponto de Acesso corrente (BSSID), endereço IP, máscara da sub-rede, o endereço MAC do último Ponto de Acesso, o último endereço IP, flag indicando se o endereço IP mudou e uma flag indicando se o Ponto de Acesso mudou.

_cpuUsage Uma string representando a porcentagem corrente de utilização de CPU no sistema. _freeMem Uma string representando a quantidade corrente de memória livre no sistema (em KBs). _powerStatus Uma string representando a porcentagem corrente de energia na bateria principal do dispositivo. _macAddr Uma string representando o endereço MAC da interface de rede do dispositivo. _currentApMacAddr Uma string representando o endereço MAC do Ponto de Acesso corrente (BSSID). _currentIP Uma string representando o endereço IP do dispositivo. _currentMask Uma string representando a máscara da sub-rede do dispositivo. _lastCurrentApMacAddr Uma string representando o endereço MAC do último Ponto de Acesso caso uma mudança entre Pontos de Acesso tenha ocorrido. _lastCurrentIP Uma string representando o último endereço IP do dispositivo caso este tenha mudado. _ipChange Uma flag booleana indicando se o dispositivo mudou de endereço IP. _apChange Uma flag booleana indicando se o dispositivo mudou de Ponto de Acesso.

Projeto Final


[DllImport("MocaMonitorDllCE.dll")] public static extern void getMonitorData(string _cpuUsage, string _freeMem, string _powerStatus, string _macAddr,

string _currentApMacAddr, string _currentIP, string _currentMask, string _lastCurrentApMacAddr, string _lastCurrentIP, ref bool _ipChange, ref bool _apChange); Realiza uma varredura (scan) na rede sem-fio retornando uma lista com os Pontos de Acesso que estão no alcance do dispositivo e seus correspondentes valores de intensidades de sinal RSSI (Radio Signal Stregth Indentifier).

_apList Uma string alocada para guardar uma lista serializada de Pontos de Acesso. cardQueryInterval Um inteiro representando o intervalo de tempo (em ms) para aguardar que o dispositivo retorne resultados após uma operação de scan.

[DllImport("MocaMonitorDllCE.dll")] public static extern void getScanData( string apList,

int cardQueryInterval);

Projeto Final


Classe: GPSDllWrap

É a classe que realiza interface com a MocaMonitorGPSDllCE, a dll escrita em

C++ que realiza as consultas ao dispositivo GPS. A MonitorDllWrap é um “wrapper” que

realiza uma conversão em tempo de execução dos métodos da dll escrita em C++ para os

métodos em C# contidos nessa classe. Portanto, para a aplicação, esta classe representa a

biblioteca MocaMonitorGPSDllCE.dll em si, e é acionada sempre que for necessária sua

utilização, tal como seria a biblioteca se pudesse ser acionada diretamente.

Métodos: // Initializes the GPS device under GPSID public static extern void startGPSDevice(); // Stops the GPS device under GPSID public static extern void stopGPSDevice(); Gets GPS data from the device under GPSID such as: number of satellites in the device's view, number of satellites used for the location inference, the quality of the GPS data (No Fix, GPS or DGPS), the latitude, longitude and altitude of the device.

_satellitesInViewCount Uma string representando o número de satélites detectados pelo dispositivo GPS. _satellitesInUseCount Uma string representando o número de satélites utilizados para inferir a localização do dispositivo. _fixQuality Uma string representando a qualidade dos dados GPS, que podem ser do tipo Inválido (No Fix), GPS ou DGPS (Differential GPS) _latitude Uma string representando a latitude do dispositivo em graus. Números positivos indicam latitudes Norte, números negativos indicam latitudes Sul. _longitude Uma string representando a longitude do dispositivo em graus. Números positivos indicam longitudes Leste, números negativos indicam longitudes Oeste. _altitude Uma string representando a altitude em metros com relação ao nível do mar.

[DllImport("MocaMonitorGPSDllCE.dll")] public static extern void getGPSData(ref long satellitesInViewCount, ref long satellitesInUseCount, ref int fixQuality, ref double latitude, ref double longitude, ref float altitude, string gpsCoordinatesStr,

int queryInterval);

Projeto Final


4.2 Casos de uso A aplicação Monitor CE é um daemon, ou seja, um componente de software que

executa principalmente em segundo plano, com muito poucas interações com o usuário.

As operações que são realizadas pela aplicação são em geral ativadas pelo tempo, pois

são tarefas executadas periodicamente onde o usuário apenas define qual

periodicidade de tempo será utilizada. Portanto basicamente os casos de uso

descrevem o comportamento das threads que definem a principal lógica da aplicação. A

DeviceDataThread, responsável por coletar periodicamente dados de conectividade e

do dispositivo, a ScanDataThread, responsável por realizar periodicamente scans na

rede sem-fio obtendo Pontos de Acesso no alcance do dispositivo, a GPSDataThread

que periodicamente coleta dados do dispositivo GPS e a SendDataThread, que é

responsável por enviar periodicamente todos os dados coletados pelo monitor para o

CIS.

Caso de uso CDU1: Obter informações do dispositivo e conectividade Ator principal: Evento temporal Interessados e interesses: Usuário: Deseja visualizar os dados do dispositivo na interface gráfica da aplicação. Pré-Condições: Caso a periodicidade de tempo, com que os dados do dispositivo e conectividade, são coletados não estiver definida no arquivo de configurações ou obtida do Configuration Service (CS) da MoCA um valor default será utilizado. Caso uma ou mais informações do dispositivo ou conectividade não possam ser obtidas essas serão mostradas na interface na forma N/A. Garantia de sucesso (ou pós-condições): A periodicidade de coleta de dados do dispositivo foi definida, os dados do dispositivo e conectividade são coletados e exibidos na interface com o usuário. Garantia de Sucesso Principal (ou Fluxo Básico): 1. O Monitor inicia e obtém a periodicidade de coleta de dados do dispositivo e conectividade do Configuration Service (CS) da MoCA. 2. A thread de coleta de dados de dispositivo e conectividade é iniciada (“acorda periodicamente”) e coleta dados de dispositivo e conectividade e os exibe na interface do usuário. Extensões (ou Fluxos Alternativos): 1a. O Monitor não consegue obter a periodicidade com o Configuration Service da MoCA.

Projeto Final


1. A aplicação informa o erro. 2. A aplicação obtém a periodicidade do arquivo de configurações.

a. Não é possível obter a periodicidade do arquivo de configurações. i. A aplicação utiliza um valor default para a periodicidade.

2a. A aplicação não consegue obter uma ou mais informações do dispositivo ou conectividade.

1. A aplicação informa o erro que ocorreu e mostra o dado que não pode ser obtido, na interface com o usuário na forma N/A (Não disponível).

Caso de uso CDU2: Obter dados do dispositivo GPS Ator principal: Evento temporal Interessados e interesses: Usuário: Deseja visualizar os dados do dispositivo GPS na interface gráfica da aplicação. Pré-Condições: Caso a periodicidade de tempo, com que os dados do dispositivo GPS são coletados, não estiver definida no arquivo de configurações ou obtida do Configuration Service (CS) da MoCA um valor default será utilizado. Caso uma ou mais informações do dispositivo GPD não possam ser obtidas essas serão mostradas na interface na forma N/A (Não disponível). Garantia de sucesso (ou pós-condições): A periodicidade de coleta de dados do GPS foi definida, os dados do GPS são coletados e exibidos na interface com o usuário. Garantia de Sucesso Principal (ou Fluxo Básico): 1. O Monitor inicia e obtém a periodicidade de coleta de dados do dispositivo GPS do Configuration Service (CS) da MoCA. 2. A thread de coleta de dados de dispositivo GPS é iniciada (“acorda” periodicamente) e coleta dados do dispositivo GPS e os exibe na interface do usuário. Extensões (ou Fluxos Alternativos): *a. A qualquer momento o usuário poderá parar a coleta de dados do dipositivo GPS através da interface gráfica com o usuário. 1a. O Monitor não consegue obter a periodicidade com o Configuration Service da MoCA.



2a. A aplicação não consegue obter uma ou mais informações do dispositivo GPS.

Projeto Final


2. A aplicação informa o erro que ocorreu e mostra o dado que não pode ser obtido, na interface com o usuário na forma N/A (Não disponível).

Caso de uso CDU3: Realizar varredura na rede sem-fio por Pontos de Acesso Ator principal: Evento temporal Interessados e interesses: Usuário: Deseja visualizar os Pontos de Acesso que estão no alcance do dispositivo na interface gráfica da aplicação. Pré-Condições: Caso a periodicidade de tempo, com que as varreduras são realizadas, não estiver definida no arquivo de configurações ou obtida do Configuration Service (CS) da MoCA, um valor default será utilizado. Caso nenhum Ponto de Acesso seja encontrado no alcance do dispositivo nenhum será mostrado na interface com o usuário. Garantia de sucesso (ou pós-condições): A periodicidade de varredura foi definida, os Pontos de Acesso no alcance do dispositivo são detectados e exibidos na interface gráfica com o usuário. Garantia de Sucesso Principal (ou Fluxo Básico): 1. O Monitor inicia e obtém a periodicidade de varredura do Configuration Service (CS) da MoCA. 2. A thread que realiza varreduras por Pontos de Acesso é iniciada (“acorda periodicamente”) e realiza a varredura coletando os Pontos de Acesso no alcance do dispositivo e os exibindo na interface do usuário. Extensões (ou Fluxos Alternativos): *a. A qualquer momento o usuário poderá interromper as varreduras por Pontos de Acesso através da interface gráfica com o usuário. 1a. O Monitor não consegue obter a periodicidade com o Configuration Service da MoCA.



Projeto Final


Caso de uso CDU4: Enviar dados coletados pelo Monitor para o CIS Ator principal: Evento temporal Interessados e interesses: Usuário: Deseja enviar os dados do dispositivo para o CIS. Pré-Condições: Caso a periodicidade de tempo com que os dados coletados são enviados ou o endereço IP e porta do CIS não estiverem definidos no arquivo de configurações ou obtidos do Configuration Service (CS) da MoCA valores default serão utilizados. Garantia de sucesso (ou pós-condições): A periodicidade de envio dos dados foi definida, o endereço e porta do CIS foram definidos, os dados coletados são enviados para o CIS. Garantia de Sucesso Principal (ou Fluxo Básico): 1. O Monitor inicia e obtém a periodicidade de envio de dados o endereço e a porta do CIS do Configuration Service (CS) da MoCA. 2. A thread de envio de dados de dispositivo é iniciada (“acorda” periodicamente) e envia os dados coletados para o CIS. Extensões (ou Fluxos Alternativos): 1a. O Monitor não consegue obter a periodicidade de envio dos dados, o endereço IP ou a porta do CIS com o Configuration Service da MoCA.

7. A aplicação informa o erro. 8. A aplicação obtém os parametros do arquivo de configurações.

a. Não é possível obter os parâmetros do arquivo de configurações. i. A aplicação utiliza valores default para a periodicidade, o

endereço IP e a porta do CIS.

Projeto Final


5.2 Projeto modular

Esta aplicação é estruturada segundo o padrão arquitetural Model-View-

Controller também conhecido por MVC. O padrão MVC permite que a aplicação seja

extensível e modular separando a aplicação em três partes:

• parte lógica do negócio (Model), que implementa a recuperação e a

manipulação dos dados.

• parte interface de usuário (View), que é o que os usuários da

aplicação vêem

• parte controladora (Controller), que encaminha pedidos aos objetos

adequados.

Separando a aplicação nestss três partes, o padrão de projeto MVC permite

modificar uma parte da aplicação sem atrapalhar às outras. Isto significa que é possível

ter vários desenvolvedores trabalhando em diferentes partes da aplicação na mesma hora

sem que seja necessário que um entre no domínio do outro. Cada desenvolvedor sabe seu

papel na aplicação. Por exemplo, a interface de usuário não deve conter nenhum código

que tenha a ver com a lógica do negócio, e vice-versa.

4.3 Interfaces Gráficas

Figura 3 - Interface de dados do dispositivo

Projeto Final


Interface de dados do dispositivo: Na interface de dados do dispositivo (Figura 3)

o usuário poderá acompanhar o estado dos recursos do dispositivo, tais como a utilização

de CPU, a quantidade de memória livre e a porcentagem de energia disponível de bateria.

Figura 4 - Interface de dados de conectividade

Interface de dados de conectividade: Na interface de dados de conectividade

(Figura 4) o usuário poderá obter dados da rede, tais como endereço IP, máscara da sub-

rede, endereço MAC da interface de rede, endereço MAC do Ponto de Acesso corrente e

a lista de Pontos de Acesso no alcance do dispositivo, cada um com seu respectivo

endereço MAC (BSSID), intensidade de sinal (RSSI) e identificação de rede sem-fio

(SSID). O usuário poderá parar a operação periódica de scan caso não a esteja utilizando

no momento ou queira economizar bateria do dispositivo.

Projeto Final


Figura 5 - Interface de dados GPS

Interface de dados GPS: Na interface de dados GPS (Figura 5) o usuário poderá

obter informações relativas ao sistema GPS e à localização do dispositivo através de suas

coordenadas geográficas latitude, longitude e altitude. O usuário poderá parar a operação

periódica de coleta de dados GPS caso não a esteja utilizando ou queira poupar bateria

do dispositivo.

Projeto Final


Interface dos Serviços MoCA: Na interface dos Serviços MoCA o usuário poderá

visualizar os endereços IP e portas dos serviços MoCA utilizados pelo Monitor além da

periodicidade de envio de informações para o CIS.

Projeto Final


5 Considerações finais

Com a implementação do componente Monitor para dispositivos Palmtops, a

MoCA pode finalmente atender a essa classe de dispositivos, que vem sendo cada vez

mais encontrada no mercado e vem apresentando uma grande aceitação por parte dos

usuários. Novos protótipos e experimentos poderão ser criados e os

protótipos/experimentos existentes poderão também ser testados nesse novo ambiente

computacional. Com isso, poderão ser levantados novas idéias e requisitos para

aplicações que executem nesse tipo de ambiente e também para aplicações/serviços que

possam aproveitar a informação de localização GPS.

Este trabalho apresenta também a utilização de uma nova API para o acesso a

dispositivos GPS de uma forma genérica e padronizada. Tal utilização pode servir como

base para que outras pessoas possam desenvolver aplicações com essa tecnologia de uma

forma mais prática.

Poderá ser incluído futuramente na arquitetura MoCA um serviço de localização

que possa realizar a inferência baseado tanto na intensidade de sinais de radiofreqüência

(atual implementação do LIS) quanto em coordenadas geográficas GPS, realizando o

mapeamento entre regiões simbólicas e coordenadas geográficas. Contudo, por si só, a

informação de GPS irá contribuir significativamente para a MoCA como uma informação

de contexto relevante para uma gama de aplicações.

Projeto Final


Referências Bibliográficas [1] V. Sacramento, M. Endler, H.K. Rubinsztejn, L.S. Lima, K. Gonçalves, F.N.do Nascimento, G. Bueno, MoCA: A Middleware for Developing Collaborative Applications for Mobile Users. ACM/IFIP/USENIX International Middleware Conference, Toronto, October, 2004. [2] J. Viterbo Filho, V. Sacramento, R.C.A. da Rocha, M. Endler MoCA: Uma Arquitetura para o Desenvolvimento de Aplicações Sensíveis ao Contexto para Dispositivos Móveis Proc. of the XXIV Simpósio Brasileiro de Redes de Computadores (SBRC) - Tool Session, Curitiba, May-Jun 2006 (to appear). [3] F. Nascimento, V. Sacramento, G. Baptista, H. Rubinsztejn, M. Endler Desenvolvimento e Avaliação de um Serviço de Posicionamento Baseado em IEEE 802.11 Proc. of the XXIV Simpósio Brasileiro de Redes de Computadores (SBRC) (ISBN: 85-7669-022-5), Curitiba, May-Jun 2006 (to appear). [4] F. Adelstein, S. Gupta, G. Richard III, L. Schwiebert; Fundamentals of Mobile and Pervasive Computing, McGraw-Hill 2005. [5] STAA, Arndt Von; Programação modular - desenvolvendo programas complexos de forma organizada e segura. Rio de Janeiro: Campus, 2000. [6] Microsoft Developer Network ( MSDN) , www.msdn.com [7] Harvey M. Deitel, Paul J. Dietel, Jeffrey A. Listfield, Tem R. Nieto, Cheryl H. Yaeger, Marina Zlatkina ; C# How to Program, Prentice Hall 2001.

monitor/ce: um componente para a coleta de informacões de...

Documents