Content uploaded by Fabio Santos
Author content
All content in this area was uploaded by Fabio Santos on Dec 05, 2018
Content may be subject to copyright.
1
Jogos de Guerra em Plataformas Móveis
Fábio Marcos de A. Santos
cjd@ciasc.mar.mil.br
CIASC
Marinha do Brasil
Marcos A. Casanova
casanova@inf.puc-rio.br
Depto de Informática
PUC-RIO
Roberto de Beauclair Seixas
Tron@visgraf.impa.br
Visgraf
IMPA
1 INTRODUÇÃO
Durante séculos a humanidade tem dado atenção a
jogos de estratégia, como meio para o treinamento dos
militares, proporcionando ao Comandante o exercício do
Comando e Controle (C2) [18] com baixo custo.
A partir da diversificação da utilização dos
computadores, os jogos de guerra saíram dos tabuleiros
de papel e das mesas com areia para suas telas,
popularizando o seu uso como objeto de diversão e, mais
importante, possibilitando sua maior aproximação da
realidade com a utilização de modelos matemáticos e
estatísticos complexos no jogo.
Atualmente os exercícios em campo no Corpo de
Fuzileiros Navais usam meios computacionais, porém
com a dependência da existência de um servidor no local
do exercício.
Na busca de uma solução para utilizar
equipamentos móveis nos exercícios foram estudadas
aplicações como o sistema de arquivos CODA [1,7], o
sistema Odyssey [8,9,13,14,15] o Bayou [17] e o toolkit
Rover [6,16], que tornaram evidentes a necessidade de
mecanismos de adaptação devido à grande diferença
entre suas características e aquelas encontradas em
aplicações baseadas em estações fixas.
A grande diferença entre as aplicações comerciais e
uma de caráter militar provavelmente é a necessidade de
trafegar dados sigilosos que pode fazer necessário o uso
de criptografia na sua transmissão em uma operação real,
ou uma simples codificação dos dados utilizados nos
jogos e exercícios.
Neste trabalho serão propostas plataformas para a
utilização de equipamentos móveis nos jogos e exercícios
em uso no Corpo de Fuzileiros Navais. Uma aplicação
foi implementada em uma das plataformas propostas.
2 O SISTEMA DE AVALIAÇÃO DO
EXERCÍCIO - SAE
Para melhor compreensão do domínio do problema
onde se insere o emprego de dispositivos móveis nos
jogos e exercícios vamos de maneira suscinta descrever o
funcionamento do SAE.
O Sistema de Avaliação Exercício (SAE) é
empregado pela Força de Fuzileiros da Esquadra (FFE)
na avaliação dos exercícios em campo. Quando ocorre
uma interação entre dois elementos de combate, por
exemplo, seus respectivos observadores enviam para um
centro de controle uma mensagem que contém alguns
dados sobre os engajantes, tais como posição, moral da
tropa, tática empregada, etc. Esta mensagem segue via
rádio transmissão e, após ser recebida e validada por um
grupo de juizes, denominado Grupo de Controle ou
GRUCON, ela é inserida no SAE. O sistema então gera o
resultado da interação, que é informado aos
observadores. Os observadores funcionam então como
braços do Grupo de Controle em campo.
O SAE, mantido pela FFE, possui um conjunto de
mensagens padronizadas que determinam a interface do
sistema. Estas mensagens são codificadas e recebem
códigos que variam de A1 até A13. Cada mensagem é
empregada para se transmitir ou receber dados relativos a
um evento que pode ocorrer durante o exercício. Alguns
dos principais eventos são:
- Interação terrestre;
- Informação de posição;
- Engajamento de armas AC ou CC; e
- Incorporações e destaques.
Um melhor emprego do SAE depende da resolução
dos seguintes problemas:
- A necessidade de transmissão dos dados entre os
observadores e os juizes implica, atualmente, no
transporte do servidor que executa o SAE para o
local onde ocorre o exercício;
- A necessidade de transcrição dos dados das
mensagens no SAE pode inserir erros;
- A necessidade de se alocar um rádio transmissor
para o observador, para o envio da mensagem e a
recepção do resultado, retira o equipamento da sua
finalidade principal;
- Em caso de inoperância do equipamento onde se
encontra o SAE, todo exercício pode ser
comprometido;
- O SAE deve estar, preferencialmente, ao alcance
rádio de todos os observadores, limitando a área do
exercício;
2
- A entrada de dados via rádio dificulta a integração
do SAE com o SJD; e
- O envio e o recebimento de dados somente é
possível em formato texto.
Figura 1 – Use Case da Interação Terrestre (Alpha -1)
3 JOGOS DE GUERRA EM
PLATAFORMAS MÓVEIS
Os observadores e os comandantes das unidades são
pessoas candidatas a possuírem uma estação móvel para
o uso durante o exercício. A crescente diversidade dos
recursos disponíveis hoje neste tipo de equipamento nos
permite desenvolver diversas aplicações de acordo com
suas características principais, como capacidade de
processamento, memória disponível e largura da banda
de conexão.
3.1 REQUISITOS DE IMPLEMENTAÇÃO EM
JOGOS DE GUERRA
Em [15] é mencionada uma taxionomia para a
caracterização dos dados envolvidos em sistemas móveis,
em três dimensões: disponibilidade, atualização e
precisão (da localização dos dados).
A primeira dimensão, disponibilidade, descreve se
os dados gerenciados estarão disponíveis em todas as
estações móveis ou em apenas algumas selecionadas. A
segunda dimensão, atualização, preocupa-se com que
grau os dados disponíveis nas estações móveis
correspondem à versão mais recente existente. Já a
terceira e última dimensão diz respeito à precisão da
localização dos dados nos dispositivos móveis, ou seja,
se sabemos ou não exatamente onde estes se encontram.
No SAE - Sistema de Avaliação de Exercícios - a
área considerada mais importantes no que diz respeito à
utilização dos dados disponíveis no banco de dados é a
interação.
Nos jogos de guerra, o engajamento entre as
unidades oponentes deve ser realizado com os dados
atualizados para que seja considerado o estado atual de
cada elemento para o cálculo do poder de combate do
atacante e do defensor. Este cálculo depende do efetivo
das unidades, da manobra empregada no combate, do
moral da tropa, etc. Dessa forma, um cálculo realizado
com dados incompletos ou desatualizados pode gerar um
resultado irreal da interação. Assim, para solução dos
engajamentos no jogo, apenas nos interessam os dados
atuais [15], na dimensão atualização.
Entretanto, a desatualização não impede o uso do
jogo com algumas abordagens específicas. Como
exemplo, o jogo pode ser usado em simulações pelos
comandantes das unidades para avaliar os possíveis
resultados de engajamentos apenas com os dados que
dispõem do inimigo. Os comandantes poderiam então
observar os resultados com várias configurações de
ataque, variando a manobra empregada, a quantidade de
meios, a linha de partida, a utilização ou não de apoio de
fogo, etc.
Esta desatualização pode ser intencional,
representando o tempo necessário para disseminação,
pelo serviço de inteligência, dos dados do inimigo entre
as próprias forças, imitando a falta de informações sobre
as forças inimigas, etc. O GRUCON – Grupo de Controle
- pode simular o trabalho do serviço de inteligência
permitindo que uma força tome conhecimento de alguns
dados sobre a oponente ou, inclusive, fornecendo dados
falsos como em um trabalho de contra-informação. Estas
lacunas de dados podem ser das dimensões atualização,
como da disponibilidade. Alguns dados do inimigo
podem não apenas estar desatualizados como, inclusive,
ser totalmente desconhecidos, ou seja, indisponíveis.
Podemos supor, então, que certos dados podem
estar indisponíveis para certas unidades. No caso de duas
unidades inimigas que estão distantes geograficamente de
maneira que seja impossível ocorrer uma interação entre
elas, não seria necessário que uma acessasse os dados da
outra.
Isso abre caminho para o particionamento de
algumas tabelas do sistema. No caso de alguns
elementos, como os navios ou as aeronaves, que não
estão sujeitas às restrições dos obstáculos existentes nos
terrenos para sua movimentação, certamente não é
necessário que acessem dados sobre o terreno. Assim
podemos considerar que, com relação à dimensão
disponibilidade, alguns dados não precisam estar
disponíveis em todas as estações móveis.
Entretanto, dados de sincronização, como o
relógio do jogo e a velocidade do jogo (razão entre o
relógio do jogo e o relógio real), devem obrigatoriamente
estar corretos e distribuídos por todas as estações. Caso o
relógio do jogo possa ser informado por ocasião da carga
da estação móvel e havendo ainda um acerto dos relógios
antes do início do jogo, novamente não haveria
necessidade do acesso sempre a estes dados, uma vez que
Consulta Resultado da IT
<<usa>>
<<us a>>
Msg A1
Msg A9
Msg A9
Gera Resultado da IT
Altera resultado da IT
Grucon
Inclui Mensagem A1
Confirma Res ultado da IT
Observador
Confirma Msg A1
3
eles seriam fornecidos pela própria estação móvel.
Apenas em caso de paradas, retrocessos ou mudança na
escala de tempo do jogo é que as estações precisariam ser
novamente sincronizadas.
Passemos agora à análise da última dimensão,
precisão da localização dos dados. Parece perfeitamente
viável, em algumas condições, existirem dados não
atualizados ou não disponíveis, como mencionamos nos
parágrafos anteriores. Porém, se não soubermos onde
encontrá-los o jogo de guerra se torna inviável.
Entretanto, podemos imaginar um ambiente onde as
estações móveis são independentes de maneira que
possuam os dados necessários ao seu funcionamento, não
havendo a necessidade da existência de um servidor fixo
e central. Assim, haveria no momento de uma interação a
necessidade da estação móvel do atacante encontrar a
estação móvel do defensor para que, obtendo os dados da
unidade do opositor, pudesse processar o resultado do
engajamento. Caso a posição da unidade não fosse
conhecida previamente, haveria a necessidade de buscá-
la imediatamente. Não havendo, a princípio, restrição ao
não conhecimento exato da localização, desde que ela
possa ser buscada quando necessário. Serviços baseados
na localização podem ser criados como, por exemplo,
comunicando à estação móvel, que a unidade observada
encontra-se ao alcance do fogo de unidade inimiga e foi
engajada ou na região onde existe um obstáculo à
movimentação.
Podemos então sugerir três opções de
implementação para as aplicações de jogo de guerra (ver
Tabela 1):
- implementação baseada em dados sempre
atualizados (e também precisos com relação à
localização). Esta plataforma foi denominada de
cliente “magro”.
- implementação baseada em dados normalmente
atualizados, podendo existir dados armazenados
localmente que, porventura, podem ficar
desatualizados, principalmente em caso de
desconexão. Os dados, entretanto, seriam precisos.
Esta plataforma foi denominada de cliente “gordo”.
- implementação baseada na possibilidade de incerteza
das três dimensões, tratando, além do considerado na
segunda alternativa, de particionamentos horizontais
e verticais do banco de dados e trazendo a problema
da necessidade da localização de estações para a
obtenção de dados procurados. Esta plataforma foi
denominada de clientes e servidores móveis.
Note que, a desatualização ou indisponibilidade pode
ser proposital ou não, enquanto que a precisão apenas
não proposital.
Dimensão/
Plataformas
Disponibilidade Atualização
Precisão
Cliente
Magro/Servidor
Fixo
Dados nem sempre disponíveis
(a estação pode estar sem
conexão)
Dados sempre atualizados (o
acesso ao servidor central garante
que quando há dados estes estão
atualizados)
Localização dos dados
sempre precisa (Não há
problema de localização)
Cliente
Gordo/Servidor
Fixo
Dados nem sempre disponíveis
(a estação pode estar sem
conexão e sem os dados em
cache)
Dados nem sempre atualizados (a
estação pode estar sem conexão e
com dados antigos em cache)
Localização dos dados
sempre precisa (Não há
problema de localização)
Clientes e
Servidores Móveis
Dados nem sempre disponíveis
(a estação pode estar sem
conexão e sem os dados em
cache)
Dados nem sempre atualizados (a
estação pode estar sem conexão e
com dados antigos em cache)
Localização dos dados nem
sempre precisa (Onde está
a estação com os dados?)
Tabela 1 - Resumo das Plataformas
3.2 CLIENTE “MAGRO”
3.2.1 ANÁLISE INICIAL
Para esta solução, o cliente precisa ter acesso a
uma base de dados central com a situação corrente do
jogo. Logo, não é necessário armazenar localmente os
dados do jogo e, como o cliente deverá buscar sempre no
repositório central do jogo os dados que precisa, ele
poderá lá mesmo executar os métodos que resolverão,
por exemplo, o engajamento entre dois elementos de
combate. Dessa forma, a estação móvel também não
necessitará de um grande poder de processamento, mas
apenas o suficiente para rodar programas de script para
realizar críticas de dados antes de enviá-los ao já restrito
meio sem fio. Com este propósito precisaremos apenas
de um cliente que denominaremos de “magro”.
Na alternativa baseada nos clientes “magros”,
não há necessidade então da existência de dados locais e,
conseqüentemente, não há a definição do esquema local.
Os dados são sempre acessados de uma base de dados
centralizada.
Os telefones celulares podem ser considerados
como os aparelhos equivalentes aos clientes “magros”.
Eles possuem reduzida capacidade de processamento,
memória, banda passante restrita e interface limitada.
4
3.2.2 UTILIZAÇÃO EFICIENTE DOS RECURSOS
DO CLIENTE “MAGRO”
No caso do cliente “magro” (celulares), as
limitações são enormes. Torna-se necessário a utilização
de técnicas com o propósito de utilizar melhor a
interface, minimizar a digitação dos dados, tornar mais
veloz a navegação no sistema e otimizar a utilização da
conexão para se economizar banda e energia da bateria,
combatendo as restrições existentes [12].
No caso dos clientes “magros”, com a
implementação da lógica da aplicação no servidor e a
utilização da estação móvel apenas como um terminal de
entrada e visualização dos dados, já estamos empregando
de modo eficiente a capacidade de processamento
existente. O uso de dados apenas do tipo texto também
colabora para a economia de processamento.
Sempre que possível, os dados devem ser
apresentados para que o usuário escolha um ou mais
dentre os exibidos. Normalmente, quando os dados têm
vários caracteres, já se torna vantajoso o uso deste tipo de
interface ao invés de exigir que o próprio usuário os
escreva. Entretanto, apenas quando os valores possíveis
são conhecidos previamente, é que esta técnica pode ser
empregada. Dados que têm maior incidência nos campos
podem ser preenchidos previamente, como opção padrão.
Os formulários devem ser divididos em vários pedaços
uma vez que a tela é pequena, não permitindo que seja
exibido de uma só vez. Um formulário grande
necessitaria ser rolado indefinidamente, dificultando o
entendimento global da informação e atrasando o
preenchimento deste.
Os aparelhos possuem teclas padrão que podem
ser associadas às opções mais comuns de navegação
evitando a necessidade do usuário ir até o menu.
O cache pode ser usado para se armazenar as últimas
páginas visitadas de maneira a evitar a requisição delas
novamente pela rede, economizando não apenas este
recurso como também energia.
3.2.3 DIGITAÇÃO DE DADOS
Devido às restrições impostas pelos clientes
“magros”, um esforço deverá ser realizado para
possibilitar a entrada e o recebimento de dados da
maneira mais eficiente possível. O teclado reduzido
presente nesta classe de dispositivo impede, ou torna
inexeqüível, a digitação de textos longos e a tela pequena
torna desconfortável a exibição de textos longos.
As mensagens transmitidas no SAE possuem
rótulos ou dados que caracterizam táticas, características
do terreno, estado de adestramento da tropa, etc que
possuem exatamente estas propriedades. Assim um
rótulo da mensagem A1 “Distância em metros entre a LP
(linha de partida) e o objetivo” apesar de ser bastante
elucidativo, não é capaz de ser exibido adequadamente
em uma tela de 4 X 15 caracteres e receber ainda a
entrada deste dado. Da mesma maneira, o conteúdo do
rótulo “tipo do terreno” descrito como “Terreno
montanhoso; muito coberto de árvores (mata densa);
pântanos ou selvas” ou o do rótulo “Posição fortificada,
excelentes campos de tiro, boas cobertas, todas em vias
de acesso batidas” também não são facilmente
preenchidas neste tipo de equipamento. Obviamente
nenhum usuário precisaria digitar integralmente este
texto no dispositivo. O uso de interfaces do tipo seleção
ou botão de rádio resolveria este problema de forma
eficiente, se não existisse ainda o problema da tela
reduzida.
O SAE hoje já emprega uma codificação nos
seus dados. Esta codificação foi mantida para atender as
dificuldades que apareceram quando da implementação
da versão usando os clientes magros. Talvez pela cultura
já existente nas instituições militares relacionadas com os
procedimentos e doutrinas de comunicações e segurança,
nas mensagens redigidas em formulários próprios em
papel, as informações já são normalmente codificadas e
organizadas de maneira simples e eficiente. Basta então
que o observador tenha consigo uma referência com a
codificação utilizada. O próprio tipo da mensagem já é
uma codificação, uma vez que a mensagem de “Interação
no Combate Terrestre” é uma mensagem do tipo A1.
Exemplificando, uma mensagem A1 pode conter,
dentre outras, as seguintes informações:
- Unidade, sub unidade ou fração
- Coordenadas do objetivo
- Hora do ataque
- Fator de desempenho da tropa
Estas informações são agrupadas em itens ou alíneas
conforme sua semântica e estes itens podem substituir os
rótulos originais, que na sua maioria são demasiadamente
longos, novamente obtendo benefícios na exibição do
rótulo no monitor e na economia da banda passante.
A mensagem A1 é dividida em alíneas nomeadas, de
acordo com sua seqüência (alfa, bravo, charlie, delta
etc). Assim o rótulo “Unidade, sub unidade ou fração”
pode ser apelidado de “bravo” e o Hora do ataque de
“charlie 2”, compondo com outro rótulo (o “charlie 1” –
Coordenada do Objetivo) o grupo “charlie”.
A mensagem A1 tem a seguinte organização:
- Alfa (A)
- Bravo (B)
- Charlie 1 (C1)
- Charlie 2 (C2)
- Delta (D)
Etc.
Não é necessário, então, enviar os rótulos junto
com os dados, mas apenas uma referência da alínea e os
dados.
Da mesma forma, os dados propriamente ditos
podem ser codificados para que sejam transmitidos.
5
Assim, obtemos mais uma vez os benefícios na economia
da banda passante.
A mensagem A1 poderia ser composta, então, das
seguintes informações após seu preenchimento:
- Alfa: A1
- Bravo: ForDBQ ou 11000 (código da força)
- Charlie 1: 2123-9876 (coordenada do objetivo)
- Charlie 2: 14:00 (hora do ataque)
- Delta: Degradado (fator de eficiência)
Etc.
3.2.4 ASPECTOS DE COMUNICAÇÃO
Os textos longos não precisam trafegar em
linguagem clara pela rede sem fio. Além de desperdiçar a
já reduzida largura de banda, esta opção poderia tornar
pública qualquer informação transmitida. Uma das
características da comunicação sem fio é justamente a
sua propagação no meio ar em forma de difusão
permitindo a sua interceptação por outra estação que
esteja em local apropriado.
Como o emprego desta aplicação tem o
propósito apenas de melhorar a execução dos exercícios
em campo, não há uma preocupação qualquer com a
segurança das informações enviadas e recebidas pelas
estações móveis, não havendo a necessidade de uso de
mecanismos de proteção aos dados. A codificação dos
dados é suficiente para não realizar a transmissão destes
em linguagem clara.
Como já mencionado a utilização das páginas em
cache reduz a necessidade da utilização da banda de
comunicação. O protocolo WAP [21] especifica a
política de substituição das páginas em cache [22]. As
páginas requisitadas são substituídas por um algorítmo de
substituição da página menos recentemente usada (LRU
– least recently used). O padrão orienta que o histórico
tenha pelo menos 10 entradas para armazenar as páginas
recentemente visitadas [23]. A utilização ou não das
informações em cache é determinada através do uso de
um atributo de controle de cache presente no cabeçalho
[22]. As requisições de páginas no SAE-WAP utilizam,
sempre que possível, a página disponível em cache.
4 IMPLEMENTAÇÃO
Neste capítulo serão apresentadas as principais
decisões relativas à implementação do SAE-WAP nos
“clientes magros”.
4.1 IMPLEMENTANDO O CLIENTE “MAGRO”
Um framework foi projetado para que a
instanciação seja menos vulnerável às constantes
mudanças da tecnologia. Estas mudanças ocorrem
rapidamente na área relacionada à computação móvel.
A utilização de transformações XSL [20] para
gerar as saídas do framework instanciado também visa
sua rápida adaptação às constantes mudanças
principalmente no tamanho e capacidade dos monitores
dos dispositivos móveis e nas linguagens de marcação
suportados por estes. Padrões de projeto [3,4] também
foram usados para proporcionar menor manutenibilidade
ao código.
O framework possui os seguintes pontos de
flexibilização:
- Mensagem. Novos tipos de mensagens podem ser
incorporados ao exercício;
- Notificação. A notificação poderá ser efetuada por
outros meios disponíveis no futuro.
4.1.1 VANTAGENS DA IMPLEMENTAÇÃO DO
SAE-WAP
A implementação em WAP, resolve os problemas
abaixo:
- A necessidade de transmissão dos dados entre os
observadores e os juizes implica, atualmente, no
transporte do servidor onde executa o SAE para
local onde ocorre o exercício. Com a implementação
em WAP, o servidor poderá ficar na sede, ou em
outro local adequado, não havendo a necessidade do
seu deslocamento;
- A transcrição dos dados recebidos no SAE via fonia
pode incluir erros. A entrada de dados diretamente
no SAE elimina este tipo de problema;
- A necessidade de se alocar um rádio transmissor
para o observador, para o envio da mensagem e a
recepção do resultado, retira o equipamento da sua
finalidade principal. O observador levará consigo o
telefone WAP liberando o rádio para a tropa. O
aparelho, de baixo custo, também poderá ser usado
para troca de informações entre observadores ou
entre estes e o GRUCON;
- Em caso de inoperância da estação onde se encontra
o SAE, todo exercício pode ser comprometido. Com
a permanência do servidor no seu local de origem,
teremos um ambiente operacional menos agressivo
com maiores facilidades de reparos disponíveis;
- O SAE deve estar, preferencialmente, ao alcance
rádio de todos os observadores, limitando a área do
exercício. O telefone também apresenta uma
limitação de área de operação que, no entanto, pode
ser ampliada com convênios com a operadora;
- A entrada de dados centralizada não possibilita a
integração do SAE com o SJD. A entrada de dados
não será mais centralizada.
O envio e o recebimento de dados prevê atualmente
apenas o formato texto. Com o avanço na tecnologia,
novos tipos de dados poderão ser enviados de forma
eficiente no futuro. A implementação dos clientes
6
“gordos” poderá também facilitar o envio de outros tipos
de dados.
4.1.2 INTERFACE COM O USUÁRIO
Foram usadas as técnicas abaixo no projeto da
interface com o usuário.
a) Construir a interface em forma unidades semânticas.
Cada item de entrada de dados deve ser feita
separadamente ou no máximo em pequenos grupos,
desde que mantenham uma unidade semântica. A
utilização de muitas entradas de dados como em um
formulário implicará na realização excessiva da rolagem
da tela, tornando mais demorada e mais sujeita a erros a
operação de entrada de dados.
b) Preferencialmente devemos utilizar entrada de dados
do tipo “seleção”.
A digitação de dados no teclado reduzido dos telefones é
extremamente demorada e sujeita a erros. Para cada
caractere entrado podemos ter que pressionar uma tecla
mais do que quatro vezes. Com a tendência de
miniaturização dos aparelhos, os teclados ficam também
cada vez menores dificultando a digitação correta. Caso o
usuário pressione uma vez a mais uma tecla, passando do
caractere desejado, ele tem que continuar pressionando a
referida tecla passando por todos os valores possíveis
disponíveis novamente aumentando consideravelmente o
tempo de digitação. Utilizando-se entradas de dados do
tipo “seleção” os usuários apenas devem navegar e
escolher uma ou mais opções dentre as oferecidas. No
entanto quando o domínio referente a um campo de
entrada de dados é muito extenso, ou as opções não são
previamente conhecidas, não há maneira de se empregar
as seleções.
c) Opções podem receber rótulos para terem um
significado melhor que simplesmente um “ok”.
No entanto em alguns dispositivos rótulos maiores que
cinco caracteres são abreviados, podendo perder
totalmente a informação que carrega consigo.
d) Manter o conteúdo que aparece juntamente com
campos de entrada de dados em no máximo uma ou
duas linhas.
Após a seleção da opção associada a uma seleção ou a
digitação de uma informação em um campo texto, estes
podem ocupar mais espaço, produzindo um efeito
desagradável ao usuário com o truncamento de
informações apresentados e a conseqüente perda da
compreensão sobre a interface.
e) Empregar opções com maior probabilidade de
escolha como opção default ou como opções pré-
selecionadas.
Esta prática possibilita uma economia no números de
passos para se selecionar uma opção ou entrar com
dados. A opção de navegação mais comum também pode
ser associada à soft key do telefone.
f) Usar as páginas no histórico (cache) sempre que for
visitar uma página.
Substituindo chamadas que usam o conteúdo em cache
podemos acessar páginas disponíveis localmente. Assim
economizamos a banda passante e a bateria do aparelho.
g) Formatar a entrada de dados e restringir os caracteres
que podem ser digitados.
Desta forma estamos não somente impedindo a entrada
de dados com erro e conseqüentemente economizando
banda e bateria, como também reduzindo o número de
toques necessários para se escolher o caractere no
teclado, uma vez que os formatos de entrada fazem este
tipo de seleção junto ao teclado.
h) As páginas devem ter um tamanho próximo a 500
bytes para que sejam carregadas rapidamente.
Páginas maiores de 1500 bytes, aproximadamente,
correm o risco de não poderem ser processadas em
alguns aparelhos.
5 CONCLUSÕES
Com a rápida evolução dos equipamentos móveis,
notadamente em sua capacidade de comunicação e
processamento, a tendência é a aproximação entre a
tecnologia usada em computação móvel e a usada na
computação baseada em estações fixas, exigindo um
menor esforço de adaptação às restrições.
A possibilidade do emprego destes equipamentos
nos adestramentos reduz o custo da sua execução, acelera
a velocidade na troca de dados entre as frações e o
Grucon, diminui a possibilidade de erros nesta troca,
possui menor peso e dimensões que outros equipamentos
com o mesmo fim e permite a integração em um só local
várias funcionalidades, sendo indicado para ser
empregado nos exercícios. A transferência de
informações em silêncio, ou seja, sem emprego da voz
pode ser requisito fundamental em alguns tipos de
exercícios.
A combinação destas plataformas com canais mais
seguros de comunicação pode possibilitar o emprego
também em operações reais.
São as seguintes as áreas importantes de trabalhos
futuros necessárias ao amadurecimento deste trabalho:
- Implementação das respostas das mensagens com
VoiceXML[19];
- Estudo e implementação dos “clientes gordos”;
- Estudo das MANETs [2] para a implementação da
plataforma de “clientes e servidores móveis”.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] BRAAM,P.J., The CODA Distributed File
System. Linux Journal, #50, Junho 1998.
[2] CORDEIRO, C., AGRAWAL, D. Mobile Ad
hoc Networking. SBRC 2002.
[3] GAMMA, E. et al Design Patterns, 1995
7
[4] GRAND, M. Patterns in Java, 1998
[5] JOSEPH, A., TAUBER, J., KAASHOEK , M.
Mobile Computing with Rover Toolkit.
IEEE Transactions on Computers, 1997.
[6] KAASHOEK, M. et al. Rover: A Toolkit for
Mobile Information Access. Proceedings
of the Fifteenth Symposium on Operating
Systems Principles, Dezembro de 1995.
[7] KISTLER, J.J., SATYANARAYANAN, M.
Disconnected Operation in the Coda File
System. ACM Transactions on Computer
Systems, Fevereiro de 1992.
[8] NOBLE, B. D. & SATYANARAYANAN, M.
Experience with adaptative mobile
applications in Odyssey. Mobile Networks
and Applications, 1999.
[9] NOBLE, B. System Support for Mobile,
Adaptative Applications. IEEE Personal
Comunications, Fevereiro de 2000.
[10] PITOURA, E. Location Management in
Mobile Computing, 1998.
[11] PITOURA, E. System Support for Mobile
Wireless Computing, 1998.
[12] PITOURA, E., BHARGAVA, B. Building
Information Systems for Mobile
Environments. Third International
Conference on Information and
Knowledge Management, 1994.
[13] SATYANARAYANAN et al. RPC2 User
Guide and Reference Manual, 1991.
[14] SATYANARAYANAN, M. Fundamental
Challenges in Mobile Computing. ACM
Symposium on Principles of Distributed
Computing, Agosto de 1995.
[15] SATYANARAYANAN, M. Mobile
Information Access. IEEE Personal
Communications, 1996.
[16] SNOEREN, A.,BALAKRISHNAN, H.,
KAASHOEK, M. Reconsidering Internet
Mobility. Proc. 8th Workshop on Hot
Topics in Operating Systems. 2001.
[17] SPREITZER, M. et al. The Bayou
Architecture: Support for Data Sharing
among Mobile Users. Proceedings IEEE
Workshop on Mobile Computing Systems
& Applications, 1994.
[18] TENENTE-CORONEL JAMES E., Combater
Digital. Military Review Brazilian, 2nd
Quarter 2000
[19] VOICEXML, VoiceXML specifications.
[20] W3C. Extensible Stylesheet Language (XSL).
Version 1.0, W3C Working Draft, 18
October 2000.
[21] WAP Forum, Wireless Application Protocol –
White Paper.
[22] WAP Forum, Wireless Application Protocol
Caching Model.
[23] WAP Forum, Wireless Markup Language.
