Aplicações para Computação Ubíqua



Baixar 162.64 Kb.
Página4/6
Encontro29.07.2016
Tamanho162.64 Kb.
1   2   3   4   5   6

3.Aplicacões Ubíquas


A classificação de aplicações é uma questão complexa porque elas envolvem vários elementos pertencentes a diversas categorias. A categoria “Reminders”, por exemplo, é a categoria de aplicações que ajudam aos usuários a “lembrar” de seus compromissos (mas não se poderia caracterizá-las como aplicações baseadas em contexto – “awareness applications”). Também é muito comum que as aplicações sejam semelhantes do ponto de vista de engenharia, embora tenham um emprego bem diferente. As aplicações classificadas como de orientação (“Guides”) e de lembretes (“Reminders”) possuem um semelhança técnico embora a experiência de uso seja completamente diferente. Pode se dizer que ambas são exemplos de aplicações do tipo gatilho (“triggering”). Dessa forma, poder-se-ía montar uma classificação onde as aplicações estariam relacionadas ao contexto e poder-se-ía ter três ou quatro outras classificações onde gatilho (“triggering”) seria uma delas. Entretanto, a existência de três classificações nunca seria suficiente para suportar as infinitas combinações que se pode encontrar na computação ubíqua. Segundo [4], um exemplo de classificação des aplicações ubíquas pderiam ser a seguinte: “Active Environments”, “Augmenting the Human” (usam sensores para prover informações sensoriais que um dado usuário não tem capacidade), “Automatic Device Configuration”, “Awareness”, “Guides” (aquelas que ajudam ao usuário a executar uma dada tarefa), “Input”, “Nomadicity”, “PIM” (auxiliam no gerenciamneto de informações) e as “Reminders”.

Nessa seção estaremos avaliando algumas aplicações ubíquas.


3.1ParcTab


O sistema ParcTab foi um protótipo desenvolvido na Xerox Parc para explorar as capacidades e os impactos da computação móvel e que faz parte dos projetos de pesquisa em computação ubíqua.

3.1.1Motivação


O ParcTab tinha que ser fisicamente atrativo aos usuários, compatível com a rede, e capaz de mudar seu comportamento de acordo com o contexto corrente. Acreditava-se que para preencher todos esses requisitos, o ParcTab tinha que ser pequeno, leve e esticamente agradável de forma que os usuários o aceitariam como um acessório do dia-a-dia. Precisava ter uma conexão sem fio com as redes confiável e mecanismos de rastreamento capazes de detectar sua localização até dentro de uma sala. Tinha que ter bateria suficiente para um dia sem que fosse necessária recarga.

A interface com o usuário tinha que permitir que as pessoas fizessem seu uso mesmo que tivessem apenas uma das mãos livres. O vídeo tinha que ser capaz de exibir tanto gráficos como textos. Os usuários teriam que ser capazes de selecionar opções através do toque. Além disso, o custo do “hardware” e da infraestrutura de rede tinham que estar dentro dos limites razóaveis de modo que se pudesse dispor de seu uso além do laboratório.

O custo não foi a unica limitação nas opções do projeto. Alguns outros fatores também foram limitantes na atual tecnologia tais como a largura de banda de conexão de alguns dispositivos, resolução do vídeo, desempenho do processador e capacidade de bateria.

O projeto ParcTab tinha os seguintes objetivos:



  1. projetar o hardware para um dispositivo móvel, o ParcTab, que permitisse a comunicação pessoal;

  2. projetar uma arquitetura que suportasse a comunicação móvel;

  3. construir aplicações baseadas em contexto que explorasse a arquitetura projetada;

  4. testar todo o sistema com quarenta e um usuários.

3.1.2Projeto de Sistema


O Equipamento Móvel

Os requerimentos e as limitações acima citadas foram cuidadosamente pesadas quando da ocasião das decisões dos engenheiros na aparência final (Figura 2) e na funcionalidade do equipamento ParcTab.

Havia uma crença de que um pacote ergonomico seria essencial uma vez que as pessoas iriam carregar e usar o “tab” regularmente. O PARCTAB foi envolto em uma capa plástica de alta qualidade junto com um prendedor de cinto. O “tab” tinha o tamanho aproximado ao dos assistentes digitais pessoais (PDAs), 10.5 cm X 7.8 cm X 2.4 cm. Ele pesava 215 gr. O “tab” foi concebido de forma que o usuário poderia optar pelo uso de uma das mãos com botões ou o uso de ambas as mãos. Porque o pacote é simétrico, poderia ser usado por qualquer uma das mãos, uma característica importante para os canhotos que desejavam usá-lo de maneira elegante. Para converter o uso da mão direita para esquerda, o usuário precisaria executar um comando de configuração que giraria o vídeo e as coordenadas da tela em 180 graus.

Um vídeo LCD foi concebido com as seguintes dimensões: 6.2 cm X 4.5 cm e com uma resolução de 128 X 64 pixels monocromáticos.



Figura 2: O equipamento Parc Tab



GERENCIAMENTO DO CONSUMO DE ENERGIA

Após alguns testes, conclui-se que a célula retangular Nicad foi a mais adequada tecnologia de bateria dadas as metas de tamanho, peso e desempenho estabelecidas. Foram necessárias quatro células para fornecer uma fonte de consumo recarregável para o “tab”. O processador poderia ser programado para ingressar no modo economico (“low-power”). Quando ocioso, o equipamento tirava proveito do modo de consumo economico aumentando assim, a vida da bateria. O vídeo, a tela, a RAM adicional e os eletrônicos de comunicação também podiam ser programados pelo micro-controlador para passarem a consumir menos energia.



COMUNICAÇÃO

As restrições de espaço limitado e consumo de energia só permitiram duas opções de tecnologia de comunicação sem fio: radio ou infra-vermelho (IR). Optou-se pela tecnologia de infra-vermelho com a especificação correspondente a 85nm IR. Esse foi um dos componentes de IR menores e mais baratos disponível no mercado. Ele teve o menor consumo de energia e proporcionou velocidades de conexão entre 9600 a 19200 bps. Dado que os sinais de IR não atravessavam as paredes de uma sala, essa tecnologia também facilitou o projeto de um sistema celular que competisse por uma largura de banda que seria exigida para suportar um sistema operando em todo um prédio e para vários usuários. Além disso, a comunicação por IR não era regulamentada. Já um link de radio demandaria mais espaço, mais consumo de energia e provavelmente, licença de operação emitida pelo governo.

A rede IR tab era composta por nano-células com um “transceiver” infra-vermelho delimitado pelas paredes de uma sala. Salas ou ambientes muito grandes também poderiam conter nano-células se existissem receptores espalhados em determinados limites de comunicação. Os “transceivers” (figura 3) se conectavam a LAN através das portas RS-232 de estações de trabalho próximas.

Figura 3: O “transceiver”



INTERFACE DE REDE LOCAL

De modo a prover uma comunicação nano-celular sem fio atrativa e a minimizar o custo optou-se pela estensão da LAN já existente. O cabeamento já existia e todos os edifícios do centro de pesquisa possuíam pelo menos, uma estação de trabalho com uma porta serial RS-232 adicional. Assim, só havia a necessidade de colocar cabos telefônicos entre os “transceivers” de teto e as estações Unix, e deles para a ethernet.


3.1.3Projeto de Interface


Com o desenvolvimento das primeiras aplicações do sistema ParcTab, ficou evidente que aquelas “interfaces” convencionais desenhadas para monitores de 640 X 480 “pixels”, colorido, não poderia ser utilizado para o ParcTab 128 X 64 “pixels”, monocromático.

BOTÕES Vs. TOQUE

O princípio básico era o de que o usuário não estaria com as duas mãos sempre livres e, portanto, cabia aos desenvolvedores de aplicação criar soluções de interface mistas, isto é, sensíveis a botões e ao toque na tela.

A solução intermediária elaborada foi a seguinte: apertando-se o botão do meio pela metade, seria exibida uma tela com opções de menu. Os botões acima e abaixo deveriam ser usados para mover uma seleção de opção para cima e para baixo, respectivamente, enquanto que o segundo clique do botão do meio indicaria a seleção da opção desejada. E adotou-se essa mesma filosofia para telas que tinham rolagem ou listas de texto. Assim, as aplicações teriam soluções de interface que permitissem a utilização das duas mãos (uma para apertar os botões e outra para selecionar a opção desejada), bem como a de uma única mão que estivesse desocupada.

PREVENÇÃO DE EVENTO ESPÚRIO

Como a maioria das aplicações eram executadas em algum ponto da rede, era previsto um certo atraso na exibição de uma tela, como resposta à seleção de uma opção desejada. Mas esse atraso poderia dar a oportunidade ao uso incorreto da interface como, por exemplo, o clique múltiplo do botão de seleção de opção ou múltiplas seleções de uma dada opção intencionalmente, ou por mera impaciência. A primeira seleção dispararia a execução do evento reponsável pela exibição da próxima tela, corretamente, mas a execução dos eventos subsequentes poderiam corresponder a seleções não desejadas. Para prevenir este tipo de problema, um campo chamado época foi adicionado à estrutura do pacote. Cada vez que a aplicação solicitasse uma mudança de tela, o campo época seria incrementado, de forma que se existisse uma requisição com o número época igual ao da requisição anterior, essa requisição seria descartada.



ENTRADA E EXIBIÇÃO DE TEXTO

Como o ParcTab só podia exibir oito linhas de vinte e um caracteres cada, era previsto uma certa dificuldade para leitura de textos. A experiência mostrou que como a atualização da oitava linha se dava muito rapidamente devido à limitação da largura de banda, esse problema foi contornado. Ficou comprovado que a leitura de textos no ParcTab ocorria de maneira bem similar à leitura de colunas de um jornal através de uma janela pequena onde o usuário tinha que rolá-la para cima e para baixo. Apesar da relativa eficiência na rolagem das telas, também foi necessário o uso da filtragem de alguns textos exibidos.

A entrada de texto se deu de duas formas: gráfica, através da exibição de um teclado na tela, e a chamada “Unistrokes” (figura 4) que se baseava na recente técnica de reconhecimento da escrita.

Figura 4: O alfabeto Unistroke


3.1.4Arquitetura de Sistema


O equipamento ParcTab foi integrado à rede PARC através de uma arquitetura de sistema de múltiplas camadas de modo que, facilmente, a parte rede das aplicações poderia controlar e responder aos dispositivos móveis baseado no próprio contexto. Embora os ParcTabs agissem mais como terminais do que como computadores propriamente, eles também eram capazes de executar algumas funções locais. Em geral, os “transceivers” e os “gateways” infra-vermelhos eram responsáveis por encaminhar os eventos gerados pelos ParcTabs a determinados processos agentes (“tab agents”) que eram executados nas máquinas da rede. Os agentes eram responsáveis por manter um rastro dos “tabs” móveis e por conectá-los às aplicações disponíveis nas estações de trabalho. A figura 5 ilustra a arquitetura de sistema entre os ParcTabs e as aplicações.

Os gateways controlavam um ou mais transceivers. Recebia pacotes enviados pelos transceivers e os encaminhava aos agentes e na direção contrária, recebia pacotes dos agentes e os encaminhava aos tranceivers. Os tranceivers faziam “broadcast” para entrega dos pacotes aos tabs.

Quando o tab se movia para outra célula, os agentes emitiam sinal de beacon e promovia a atualização das localizações dos tabs.

Figura 5: A Arquitetura de Sistema ParcTab


3.1.5Desenvolvimento de Sistema e Componentes da Aplicação


As aplicações ParcTab foram desenvolvidas com base em três alternativas: bibliotecas Modula-3, e sistemas Tcl/Tk e MacTabbit. Cada uma ofereceu níveis diferentes de acesso ao ParcTab e suas capacidades.

O Modula-3 era uma linguagem relativamente nova; ela tinha algumas características valiosas que beneficiaram o projeto de sistemas maiores. Essas características incluiam estabelecimento de sessões mais leves e suporte para módulos e programação orientada a objeto. A decisão por usar o Modula-3 foi influenciada pelo fato de que as primeiras versões bem sucedidas do Parc tinham utilizado a linguagem Cedar (antecessora da Modula-3) e pelas caracterïsticas de orientação a objeto que poderiam resultar em aplicação com maior qualidade e com códigos re-usáveis.

O estabelecimento de sessões Modula-3 foi uma característica muito importante pois permitiu a simplificação da arquitetura baseada em “gateway” infra-vermelho e agente. Ambos eram como servidores que interagiam com vários clientes ao mesmo tempo, onde cada cliente tinha uma sessão dedicada. Para auxiliar os testes das aplicações, também desenvolveu-se um simulador em Modula-3.

Apesar das inúmeras qualidades da nova linguagem, algumas deficiências também foram observadas durante a implentação como por exemplo, a ferramenta para depuração de erros. Não havia suporte para depuração de erros de múltiplas sessões. O Modula-3 também gerou executáveis muito grandes que às vezes sobrecarregava as estações de trabalho de 64MB.

O Tcl/Tk proveu uma linguagem de alto nível para prototipagem da interface gráficas das aplicações e uma plataforma de comunicação para intercâmbio de comandos Tcl interpretados. Já o sistema MacTabbit foi usado pela EuroPARC para acesso a aplicações Macintosh.

3.1.6Classificações das Aplicações


Três características básicas diferenciaram um tab e as suas aplicações:

  1. Portabilidade: formato muito pequeno, leveza

  2. Comunicação: interações de baixa latência entre usuário e sistema

  3. Operações baseadas em contexto

Tabela 1: Categorias de Aplicações Móveis

O significado de contexto para o sistema Tab era descrito a partir da combinação de três fatores: localização, presença de outros dispositivos móveis, e presença de pessoas. Contexto também inclui tempo, máquinas não móveis na redondeza e estado do sistema de arquivo da rede. Os sistemas para computadores tradicionais costumavam ter aceso a essa informação mas não faziam uso da mesma. O contexto pode ser usado para adaptar a interface do usuário, o critério de pesquisa e a apresentação dos dados, configuração do sistema, e até efeitos de alguns comandos. Apesar do contexto ser usado para apresentação das opções mais prováveis de serem escolhidas, em um sistema bem desenhado também será permitido que o usuário possa ter acesso a todas as opções, se assim desejar.

A combinação de fatores como rede sem fio e uso de contexto tornram o ParcTab um sistema único. Um sumário das categorias de aplicações que foram experimentadas pelo tab está descrito na Tabela 1.



  1. Acesso a Informação

O acesso às informações contidas nos computadores da rede era essencial. A rede infra-vermelho ParcTab provia mecanismos para toranar as informações acessíveis idenpendente da localização.

Cada ParcTab estava conectado à rede local e portanto, podia acessar qualquer informação disponível na rede local ou em redes remotas conectadas à rede local. Por exemplo, a consulta à meteorologia (obtida através da Internet) e informações sobre a temperatura local e a velocidade do vento (obtida através de uma estação de meteorolgia conectada à rede local). Os usuários do ParcTab também tinham à disposição um dicionário, um “thesaurus” (repositório de informações), um gerenciador de arquivo Unix e uma conexão a WWW.

As aplicações ParcTab também eram integradas com as aplicações já existentes para as estações de trabalho. Por exemplo, o calendário do ParcTab funcionava integrado ao calendário da Sun (“cm”), que já era usado. Uma atualização do calendário do usuário executada na estação de trabalho ou no ParcTab poderiam ser visualizadas por ambos os sistemas.

O gerenciador de arquivos do tab era um exemplo de uso do contexto como filtro de informações. Ao invés da apresentação de toda a hierarquia de diretórios e arquivos, só eram apresentados os arquivos que continham informações relevantes à localização onde um tab se encontrava.

Outros exemplos de uso de contexto porém, de forma mais complexa, poderiam ser vistas em ferramentas construídas no RXRC (Rank Xerox Resource Center ou também conhecido com EuroParc) tal qual o “Forget-me-not”. Essa aplicação podia suprir um usuário tab com um histórico automatico de suas próprias vidas baseada em detalhes do dia-a-dia tais como: onde a pessoa foi no seu escritório, com quem ela encontrou, que documentos ela editou ou imprimiu, que telefonemas ela deu ou recebeu. A motivação para esse tipo de aplicação era a de ajuda às mentes dos seres humanos, que são passíveis de falha. A aplicação fornecia uma interface ao usuário que lhe permitia fazer pesquisas e filtragens no seu histórico sobre um dado evento. Por exemplo, seria possível construir um filtro que mostrasse todos os documentos que estavam sendo editados por um usuário quando ele foi interrompido pea visita inesperada de um colega, que passava por perto da sua sala, no dia do seminário, na semana anterior. O “Forget-me-not” era bastante útil e eficaz para ajudar os usuários com tarefas que lhes consumiam muito tempo pelo fato de terem colocado algumas coisas em lugares errados ou porque tinham simplesmente esquecido onde as haviam colocado.


  1. COMUNICAÇÃO

Os programas de correio eletrônico são ferramentas de comunicação bastante populares entre usuários de computadores. O acesso móvel populariza mais o correio eletrônico ao aumentar a sua disponibilidade.

Reuniões em grupos frequentemente consomem grande parte do dia de trabalho e a aplicação de correio eletrônico para o ParcTab era de grande valia. O acesso ao correio eletrônico durante as reuniões satisfazia grandes necessidades.

A aplicação de correio eletrônico ParcTab também podia fazer uso do contexto através da geração de filtros para exibição de mensagens ou para avisar aos usuários de mensagens recebidas. Por exemplo, o usuário poderia determinar que, enquanto ele estivesse em reunião, só as mensagens urgentes lhes seriam entregues.

OPERAÇÕES DE LOCALIZAÇÃO E “PAGING”

O sistema ParcTab já possuía um sistema localizador inerente, desde que a pessoa que precisasse ser encontrada estivesse de posse de um ParcTab. No escritório, as pessoas podiam usar o contexto para decidir se incomodaria um outro colega ou não, uma vez que ele já tinha sido localizado. Por exemplo, as pessoas poderiam se deixar interromper quando estivessem sozinhas ao invés de em uma reunião.



  1. COLABORAÇÃO ASSISTIDA PELO COMPUTADOR

Como o ParcTab era um dipositivo pequeno, foi possível utilizá-lo em situações que requeriam colaboração ou atitudes colaborativas.

INDICADOR DE GRUPO

Vários ParcTabs poderiam se concetar a um único computador, dependendo da sua localização. Assim, se alguém estivesse fazendo uma apresentação em um quadro negro eletrônico onde vários ouvintes estivessem de posse do seu tab, eles poderiam usá-lo como um indicador individual no quadro e interagir com o palestrante.



VOTAÇÃO

O ParcTab poderia também ser utilizado como um instrumento de votação anônima ou não. Dessa forma, desenvolveu-se um sistema de votação chamado Arbitron e que foi muito útil no contexto de apresentações. O sistema permitia que a audiência votasse na qualidade e no ritmo de uma apresentação através de seus ParcTabs. Os votos eram coletados e exibidos no Liveboard de modo que, tanto o palestrante como a audiência fossem capaz de visualizar se a apresentação ou palestra estava enfadonha ou não. Sem esse sistema, a audiência teria que interromper o palestrante para pedir que ele acelerasse ou diminuisse o ritmo de uma apresentação, por exemplo.



PAPEL VIRTUAL

A tabdraw era aplicação multi-usuário construída para permitir que o tab fosse usado como um bloco de rascunho. Cada usuário da aplicação poderia escrever no seu bloco de rascunho, bem como visualizar as anotações feitas por outros colegas. Os blocos de rascunho compartilhados eram definidos por usuários de uma sala, onde cada sala tinha seu bloco de rascunho independente, muito embora também pudessem compartilhar blocos de rascunho por sala.



  1. OPERAÇÃO LOCAL

Na última revisão de equipamento, o tab estava com 128K de memória RAM, para permitir que programas pudessem ser transferidos através do link IR e fossem executados em modo “stand-alone”. Operando o tab dessa maneira, o usuário se liberta da rede IR apesar das severas limitações à funcionalidade do tab. A capacidade de armazenamento de um dispositivo móvel sempre será pequena quando comparada às expectativas do usuário.

3.1.7Experiências com o ParcTab


O sistema ParcTab está em uso desde 1993 servindo a uma pequena comunidade de usuários. Algumas observações importantes descritas abaixo podem servir de indicadores de pontos de falha e sucesso dessa experiência.

As células de comunicação foram fáceis de serem instaladas nos escritórios contando com um “transceiver” colocado no teto e que era ligado por um cabo telefonico às portas seriais RS232. Alguns usuários que possuíam uma linha telefonica ISDN também instalaram células em suas casas.

A primeira versão do sistema ParcTab que foi implementado em Março de 1993 tinha 20 (vinte) usuários e 25 (vinte e cinco) células. Já a segunda, contou com 41 (quarenta e um usuários) e 50 (cinquenta) células e incluiu várias melhorias que aumentaram o desempenho dos canais de comunicação proporcionando maior confiabilidade.

Por exemplo, a versão original contava com um serviço central de nome para obter o endereço de rede do agente para o roteamento dos pacotes até os tabs; quando este serviço estava indisponível o sistema ParcTab não funcionava. A nova versão já contou com um serviço distribuído que usou um mecanismo de multicast de rede para determinar o endereço dos componentes do sistema.

Alguns problemas foram descobertos em função da intensa utilização da rede infra-vermelho. Essa utilização intensa causou três problemas: a tendência de corrupção dos pacotes infra-vermelho; estouro de “buffer” de transmissão do transceiver e re-transmissões causadas pela perda de pacotes, o que intensificou mais a carga na rede. Essa sobrecarga de utilização acabou por ocasionar erros no sistema.

De forma a aumentar a confiança no sistema, não só foram corrigidos os erros que ocorreram mas também foram feitas muitas melhorias como o desenvolvimento de mecanismos de auto-monitoramento para vários componentes que pudessem fornecer informações mais detalhadas quando do acontecimento de uma falha.

Percebeu-se que o ParcTab não podia ser usado em algumas salas devido à interferência causada por lâmpadas fluorescentes. A posição dos “transceivers” também era algo importante pois tinha que evitar a exposição ao sol e que o seu sinal causasse interferências em células adjacentes.

Quando da disponibilização da segunda versão do sistema, foram realizadas algumas medições além da distribuição de dois questionários para determinar a aceitação ou não pelos usuários.

As medições atestaram que as aplicações mais populares entre os usuários foram: o correio eletrônico, aplicação de previsão do tempo e localizador de arquivos.

Apesar da comunidade de usuários ter sido relativamente pequena para prover algum resultado estatístico confiável e do sistema ainda estar em desenvolvimento quando da ocasião de seu teste fazendo com que muitas aplicações não estivessem completas, um certo número de pessoas atestou que o ParcTab era muito pesado e um tanto estranho de ser usado.


3.1.8Conclusões


Ficou comprovado que o ParcTab não era útil se não estivesse conectado à rede, fato este que causou uma insatifação em alguns dos usuários.

O desenho do sistema era baseado em uma arquitetura distribuída contendo vários componentes. Individuamente, esses componentes eram relativamente simples mas se analisados em conjunto, eles apresentavam um certo nível de complexidade que tornava a depuração de erros mais difícil.

A largura de banda de 19.2kbps não era suficiente quando os usários usavam o ParcTab ao mesmo tempo, ou quando compartilhavam células.

Algumas aplicações não apresentaram um padrão de uso pelo usuário como, por exemplo aquelas que permitiam o uso de caracteres Unistroke. Este tipo de aplicação gerava um tráfego maior do que a rede IR podia suportar. Como resultado, foram feitas algumas melhorias para que se pudesse obter um melhor particionamento das aplicações entre os ParcTab e o resto do sistema.

Observou-se que era difícil persuadir as pessoas para que mudassem seus hábitos no sentido de aceitarem o uso do ParcTab. Além disso, o tipo de vestimenta usado por alguns dos usuários poderia causar um grande impacto na aceitação ou não para uso do dipositivo tal como um “pager”.

Muitas pessoas mostraram interesse com relação ao uso do sistema fora do prédio também, que faria com que elas adotasem o sistema mais fácilmente. Ficou claro que um esquema de transmissão por rádio poderia proporcionar uma maior mobilidade aos usuários. Assim sendo, um sistema mais flexível deveria ter um misto de sistema nano-celular e rádio.


1   2   3   4   5   6


©principo.org 2016
enviar mensagem

    Página principal