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
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
2
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
3
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
4
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 Infravermelho (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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
5
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
6
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).
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
7
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).
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
8
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
9
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
10
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
11
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
12
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
13
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
14
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:
MoCAMonitorInterfaceCE (C# .NET CF)
MoCAMonitor (C# .NET CF)
MoCAMonitorDllCE (C)
Windows CE
API
NDIS
MoCAMonitorGPSDllCE (C)
GPSID
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
15
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
16
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
17
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
18
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
19
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
20
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
21
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 / infraestrutura 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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
22
Projeto Final
atender a futuros requisitos, com a inclusão da coleta da informação de GPS em
dispositivos que ofereçam esta tecnologia.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
23
Projeto Final
4 Projeto e especificação da aplicação
4.1
Modelo de dados
4.1.1 Diagrama de classes
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
24
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
cpuUsage
String
freeMem
String
powerStatus
String
currentIP
String
currentMask
String
macAddr
String
currentApMacAddr
string
Modificador Descrição
de Acesso
private
Representa a porcentagem de
CPU em utilização no
sistema. Ex: “12 %”
private
Representa a quantidade de
memória livre no sistema em
KBs. Ex: “32768 KBs”
private
Representa a porcentagem de
energia contida na bateria
principal do dispositivo. Ex:
“80 %”
private
Representa o endereço IP
corrente do dispositivo. Ex:
“10.10.10.150”
private
Representa a máscara da subrede corrente do dispositivo.
Ex: “255.255.255.0”
private
Representa o endereço MAC
da interface de rede do
dispositivo.
Ex: “00:02:3F:7C:77:50”
private
Representa o endereço MAC
do Ponto de Acesso corrente
da rede sem fio IEEE802.11,
também conhecido como
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
25
Projeto Final
lastCurrentApMacAddr
String
private
lastCurrentIP
String
private
ipChange
bool
private
apChange
bool
private
serializedApList
String
private
scanList
ArrayList
private
satellitesInViewCount
String
private
satellitesInUseCount
String
private
fixQuality
string
private
BSSID (Basic Service Set
Identifier)
Ex: “00:02:3F:7C:77:50”
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”
Representa o último endereço
IP do dispositivo antes de uma
mudança, caso essa tenha
ocorrido. Ex: “10.10.10.149”
Flag booleana que indica se
uma mudança de endereço IP
ocorreu. Ex: 1
Flag booleana que indica se
ocorreu uma mudança entre
Pontos de Acesso. Ex: 1
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
Lista do tipo ArrayList com
objetos do tipo AccessPoint,
que representam Pontos de
Acesso detectados por uma
operação de scan na rede semfio IEEE 802.11.
Número de satélites
detectados pelo dispositivo
GPS.
Número de satélites utilizados
pelo dispositivo GPS para a
inferência da localização.
Qualidade da inferência da
localização, pode ser inválida,
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
26
Projeto Final
Latitude
String
private
longitude
String
private
Altitude
String
private
gpsCoordinatesStr
String
private
serializedMonitorData
String
private
cisAddress
String
private
cisPort
int
private
dsAddress
String
private
GPS ou GPS Diferencial
Latitude em graus. Números
positivos indicam latitudes
Norte, números negativos
indicam latitudes Sul.
Longitude em graus. Números
positivos indicam latitudes
Leste, números negativos
indicam latidudes Oeste.
Altitude em metros com
relação ao nível do mar.
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”
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
Endereço IP do Context
Information Service da
MoCA, o serviço que receberá
as informações de contexto
coletadas pelo Monitor.
Porta do Context Information
Service da MoCA, o serviço
que receberá as informações
de contexto coletadas pelo
Monitor.
Endereço IP do Discovery
Service da MoCA, o serviço
que fornece os endereços dos
demais serviços.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
27
Projeto Final
dsPort
int
private
csAddress
String
private
csPort
int
sendDataPeriodicity
int
private
devDataPeriodicity
int
private
scanDataPeriodicity
int
private
gpsDataPeriodicity
int
private
cardQueryInterval
int
private
gpsQueryInterval
int
private
deviceDataThread
DeviceDataThread
private
threadGetDevData
Thread
private
flagDeviceData
bool
private
scanDataThread
ScanDataThread
private
threadGetScanData
Thread
private
Porta do Discovery Service da
MoCA, o serviço que fornece
os endereços dos demais
serviços.
Endereço IP do Configuration
Service da MoCA, o serviço
que fornece configurações
automaticamente para o
Monitor.
Porta do Configuration
Service da MoCA, o serviço
que fornece configurações
automaticamente para o
Monitor.
Periodicidade para o envio de
informações ao CIS.
Periodicidade para a coleta de
informações do dispositivo e
de conectividade.
Periodicidade para a
realização de scans na rede
sem-fio para a obtenção de
Pontos de Acesso.
Periodicidade para a coleta de
dados GPS.
Tempo de espera por
resultados após uma operação
de scan na rede sem-fio.
Tempo de espera por
resultados após a requisição
de dados ao dispositivo GPS.
Implementa uma thread para a
coleta de dados do dispositivo
e de conectividade.
Classe do sistema para
executar a thread
DeviceDataThread.
Flag de controle que ativa e
desativa a DeviceDataThread.
Implementa uma thread para a
realização de scans na rede
sem-fio para obtenção de
Pontos de Acesso.
Classe do sistema para
executar a thread
ScanDataThread.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
28
Projeto Final
flagScanData
bool
private
gpsDataThread
GPSDataThread
private
threadGetGPSData
Thread
private
flagGPSData
bool
private
sendDataThread
SendDataThread
private
threadSendData
Thread
private
flagSendData
bool
private
mainForm
MocaMonitorInterface
private
Flag de controle que ativa e
desativa a ScanDataThread.
Implementa uma thread para a
coleta de dados do dispositivo
GPS.
Classe do sistema para
executar a thread
GPSDataThread.
Flag de controle que ativa e
desativa a GPSDataThread.
Implementa uma thread para o
envio das informações de
contexto coletadas para o CIS.
Classe do sistema para
executar a thread
SendDataThread.
Flag de controle que ativa e
desativa a SendDataThread.
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
FlagScanData
Bool
public
FlagGPSData
Bool
public
FlagSendData
Bool
public
CISAddress
String
public
CISPort
Int
public
DSAddress
String
public
Obtém o valor da
flag de controle da
DeviceDataThread.
Obtém o valor da
flag de controle da
ScanDataThread.
Obtém o valor da
flag de controle da
GPSDataThread.
Obtém o valor da
flag de controle da
SendDataThread.
Obtém o endereço
definido do CIS
Obtém a porta
definida do CIS
Obtém o endereço
definido do DS
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
29
Projeto Final
DSPort
Int
public
CSAddress
String
public
CSPort
Int
public
Obtém a porta
definida do DS
Obtém o endereço
definido do CS
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)
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
30
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,
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
31
Projeto Final
string
int
_csAddress,
_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
usuário.
public void ShowDeviceData()
e
do
dispositivo
na
interface
com
Mostra dados dos serviços MoCA na interface com o usuário.
public void ShowServicesData()
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
32
o
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
dispositivo
public void DisableDeviceDataThread()
de
conectividade
e
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()
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
33
do
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
cpuUsage
string
freeMem
string
powerStatus
string
currentIP
string
currentMask
string
macAddr
string
currentApMacAddr
string
lastCurrentApMacAddr
string
Modificador Descrição
de Acesso
private
Representa a porcentagem de
CPU em utilização no
sistema. Ex: “12 %”
private
Representa a quantidade de
memória livre no sistema em
KBs. Ex: “32768 KBs”
private
Representa a porcentagem de
energia contida na bateria
principal do dispositivo. Ex:
“80 %”
private
Representa o endereço IP
corrente do dispositivo. Ex:
“10.10.10.150”
private
Representa a máscara da subrede corrente do dispositivo.
Ex: “255.255.255.0”
private
Representa o endereço MAC
da interface de rede do
dispositivo.
Ex: “00:02:3F:7C:77:50”
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”
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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
34
Projeto Final
lastCurrentIP
string
private
ipChange
bool
private
apChange
bool
private
devDataQueryPeriodicity
int
private
IEEE 802.11 caso esta tenha
ocorrido. Ex:
00:02:3F:7C:12:07”
Representa o último
endereço IP do dispositivo
antes de uma mudança, caso
essa tenha ocorrido. Ex:
“10.10.10.149”
Flag booleana que indica se
uma mudança de endereço IP
ocorreu. Ex: 1
Flag booleana que indica se
ocorreu uma mudança entre
Pontos de Acesso. Ex: 1
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()
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
35
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
apList
string
scanList
ArrayList
scanDataPeriodicity
int
cardQueryInterval
int
Modificador Descrição
de Acesso
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
private
Lista do tipo ArrayList com
objetos do tipo AccessPoint,
que representam Pontos de
Acesso detectados por uma
operação de scan na rede semfio IEEE 802.11.
private
Periodicidade para a
realização de scans na rede
sem-fio para a obtenção de
Pontos de Acesso.
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)
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
36
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)
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
37
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
serializedMonitorData
string
sendDataPeriodicity
int
Modificador Descrição
de Acesso
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
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()
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
38
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
satellitesInViewCount
String
satellitesInUseCount
String
fixQuality
String
Latitude
String
longitude
String
Altitude
String
gpsCoordinatesStr
String
gpsDataPeriodicity
int
gpsQueryInterval
int
Modificador Descrição
de Acesso
private
Número de satélites
detectados pelo dispositivo
GPS.
private
Número de satélites utilizados
pelo dispositivo GPS para a
inferência da localização.
private
Qualidade da inferência da
localização, pode ser inválida,
GPS ou GPS Diferencial
private
Latitude em graus. Números
positivos indicam latitudes
Norte, números negativos
indicam latitudes Sul.
private
Longitude em graus. Números
positivos indicam latitudes
Leste, números negativos
indicam latidudes Oeste.
private
Altitude em metros com
relação ao nível do mar.
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”
private
Periodicidade para a coleta de
dados GPS.
private
Tempo de espera por
resultados após a requisição
de dados ao dispositivo GPS.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
39
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()
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
40
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
41
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);
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
42
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);
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
43
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
44
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.
3. A aplicação informa o erro.
4. 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 GPS.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
45
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.
5. A aplicação informa o erro.
6. 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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
46
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
47
Projeto Final
5.2 Projeto modular
Esta aplicação é estruturada segundo o padrão arquitetural Model-ViewController 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
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
48
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 subrede, 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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
49
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
50
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
51
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
52
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.
_____________________________________________________________________
Gustavo Luiz Bastos Baptista
53
