Você está na página 1de 61

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO

CENTRO TÉCNICO CIENTÍFICO

DEPARTAMENTO DE INFORMÁTICA

PROGRAMA DE MESTRADO

APLICAÇÕES PARA COMPUTAÇÃO UBÍQUA

Disciplina: Introdução à Computação Móvel

Aluna: Claudia Silva Villa Alvarez de Noronha Rolins


Professor: Markus Endler

Rio de Janeiro, Novembro de 2001.


“Over the next twenty years computers will inhabit the most trivial
things: clothes labels (to track washing), coffee cups (to alert
cleaning staff to moldy cups), light switches (to save energy if no
one is in the room), and pencils (to digitize everything we draw).
In such a world, we must dwell with computers, not just interact
with them."

Mark Weiser
R E S U M O

Ao longo dos últimos 30 anos a velocidade de operação e a densidade de


componentes eletrônicos digitais teve um crescimento significativo,
enquanto o preço dos mesmos também teve uma queda significativa.
Hoje, os desenvolvedores de bens de consumo estão incorporando, cada
vez mais, eletrônicos digitais nos produtos finais. Se essa tendência
continuar, como nós esperamos que vá, vários itens do dia-a-dia irão em
breve incluir alguma espécie de computador.

Embora os computadores estejam se tornando cada vez mais frequentes


em utensílios tais como: VCRs, fornos de microondas, e em assintentes
digitais pessoais (PDAs), eles vão continuar muito isolados uns dos outros
e de máquinas mais robustas como por exemplo, “laptops” ou
computadores de mesa. Segundo[11] no futuro, muitos computadores
em conjunto, irão prover serviços mais valiosos do que isoladamente. O
cenário ideal é aquele onde várias máquinas especializadas irão trabalhar
em conjunto na rede permitindo que os usuários acessem e controlem as
informações, a computação bem como, seus ambientes físico e eletrônico.

A computação ubíqua tem por objetivo tornar o uso do computador mais


agradável fazendo que muitos computadores estejam disponíveis em todo
ambiente físico, mas de forma invisível para o usuário.

A computação ubíqua não é realidade virtual, não é um assistente digital


pessoal (PDA), não é uma computação pessoal ou íntima com agentes
fazendo suas ofertas. A computação ubíqua prevê um mundo com vários
tipos de dispositivos conectados entre si, com redes sem fio em todo lugar e
com um custo bem baixo. Ao contrário do PDA, a computação ubíqua afirma
que o usuário não precisa carregar muitas coisas consigo, uma vez que a
informação pode ser acessada em qualquer lugar, e a qualquer momento.

O objetivo deste trabalho, é apresentar o conceito da computação ubíqua


seus principais conceitos, e alguns exemplos de aplicações em
computação ubíqua e da infraestrutura necessária para que a computação
ubíqua venha a ser tornar uma realidade, de fato.

Palavras-chave: aplicações ubíquas, onipresente/dia-a-dia, mobilidade,


contexto, interface, humano computador, interface.
Conteúdo

1. I n t r o d u ç ã o ...............................................................................................8

1.1 ERA DO M A I N F R A M E ..........................................................................................8

1.2 ERA DO P C ..........................................................................................................8

1.3 TRANSIÇÃO – A INTERNET E A C O M P U T A Ç Ã O D I S T R I B U Í D A ................9

1.4 ERA DA U C .......................................................................................................1 0

1.5 ABORDAGEM DOS C A P Í T U L O S ........................................................................1 1

2. C O M P U T A Ç Ã O U B Í Q U A .........................................................................1 2

2.1 A FILOSOFIA DA C O M P U T A Ç Ã O U B Í Q U A .....................................................1 2

2.2 O V I S I O N Á R I O : M A R K W E I S E R ....................................................................1 4

2.3 A INFRAESTRUTURA DA C O M P U T A Ç Ã O U B Í Q U A ........................................1 5

2.4 QUESTÕES DA C O M P U T A Ç Ã O U B Í Q U A .........................................................1 6

3. A P L I C A C Õ E S U B Í Q U A S ........................................................................2 3

3.1 P A R C T A B ............................................................................................................2 4

3 .1 .1 M O T I V A Ç Ã O ....................................................................................................24

3 .1 .2 P R O J E T O DE S I S T E M A ....................................................................................25

3 .1 .3 P R O J E T O DE I N T E R F A C E .................................................................................28

3 .1 .4 A R Q U I T E T U R A DE S I S T E M A ............................................................................30

3 .1 .5 D E S E N V O L V I M E N T O DE SISTEMA E COMPONENTES DA A P L I C A Ç Ã O .................31

3 .1 .6 C L A S S I F I C A Ç Õ E S DAS A P L I C A Ç Õ E S .................................................................32

3 .1 .7 E X P E R I Ê N C I A S COM O P A R C T A B .....................................................................37

3 .1 .8 C O N C L U S Õ E S ..................................................................................................39
3.2 C L A S S R O O M 2 0 0 0 ......................................................................................4 0

3 .2 .1 M O T I V A Ç Ã O ....................................................................................................40

3 .2 .2 O P R O T Ó T I P O ................................................................................................41

3 .2 .3 A R Q U I T E T U R A DO SISTEMA E QUESTÕES DE I M P L E M E N T A Ç Ã O .......................47

3 .2 .4 A V A L I A Ç Ã O DA E F I C Á C I A ................................................................................50

3 .2 .5 R E C O M E N D A Ç Õ E S E T R A B A L H O S F U T U R O S .....................................................53

4. C O N C L U S Ã O ..............................................................................................5 6

4.1 T R A B A L H O S F U T U R O S .....................................................................................5 7

L I S T A D E A C R Ô N I M O S ................................................................................6 0

R e f e r ê n c i a s B i b l i o g r á f i c a s ......................................................................6 1
Lista de Figuras

Figura 1: Maiores Tendências da Computação..................................................................10

FIGURA 2: O EQUIPAMENTO PARC TAB...................................................................................26

FIGURA 4: O ALFABETO UNISTROKE.......................................................................................30

FIGURA 5: A ARQUITETURA DE SISTEMA PARCTAB....................................................................31

FIGURA 6: A APLICAÇÃO CLASSPAD.......................................................................................43

FIGURA 7: PROGRAMA DO CURSO, COM INDICAÇÕES DE MATERIAIS................................................44

FIGURA 8: REVISÃO DA APRESENTAÇÃO...................................................................................46

Figura 9: Programa cliente de audio................................................................................47


L I S T A D E T A B E L A S

TABELA 1: CATEGORIAS DE APLICAÇÕES MÓVEIS.......................................................................33

Tabela 2: Respostas ao Questionário Final.......................................................................51


1. I N T R O D U Ç Ã O

As importantes ondas de mudança tecnológica são aquelas que


fundamentalmente alteram o lugar da tecnologia em nossas vidas. Não é
só a tecnologia que importa, mas a forma como ela se relaciona com os
seres humanos.

Ao longo dos últimos dez anos da computação existiram duas grandes


tendências desse relacionamento: o relacionamento “mainframe” e o
relacionamento PC. A Internet hoje, está levando os seres humanos da
era computação distribuída à era da computação ubíqua, caracterizada
pela profunda absorção da computação no mundo.

1.1 E R A D O M A I N F R A M E

A primeira era foi a chamada era do “mainframe”. Nessa época, o


relacionamento entre pessoas e computadores era estabelecido através de
pessoal altamente capacitado e que geralmente estava atrás de portas
fechadas. O computador era um recurso escasso, negociado e
compartilhado entre várias pessoas.

1.2 E R A D O PC

A segunda grande tendência foi a do computador pessoal. Em 1984, o


número de pessoas que utilizavam computadores pessoais superava as
que compartilhavam computadores [6]. O relacionamento da computação
pessoal era íntimo. Cada pessoa com o seu próprio computador, contendo
as suas coisas, e interagindo diretamente com o mesmo. O computador
pessoal seria análogo ao automóvel – um item especial e relativamente
caro, que apesar de “levar a pessoa onde ela desejava ir”, também
requeria uma atenção considerável para aprender a operá-lo. Assim como
uma pessoa poderia ter vários carros, ela também poderia ter vários
computadores: um para casa, um para o trabalho, e um para quando
estivesse fora de casa e fora do trabalho. Qualquer computador com quem
o ser humano tenha um relacionamento especial, ou que o ocupa
completamente, é um computador pessoal.

1.3 T R A N S I Ç Ã O – A INTERNET E A C O M P U T A Ç Ã O

D I S T R I B U Í D A

Muitas coisas tem sido escritas sobre a Internet e sobre o movimento que
ela lidera. A Internet tem tido uma grande influência em negociações e na
prática da tecnologia. Milhões de pessoas e suas informações passaram a
estar interconectados.

De maneira bastante interessante, a Internet colocou em contato


elementos da era mainframe e da era PC. É o advento da computação
client-servidor em larga escala, onde de um lado, como clientes Web,
estão os PCs e de outro, como servidores Web, estão os mainframes.
Embora transitória, a Internet é um fenômeno massivo que convoca os
melhores inventores, os financistas mais inovadores e um grande número
de empresas multinacionais. Ao longo de talvez mais uma década, as
consequências dessa interconexão massiva de informações pessoais, dos
governos, e dos negócios vão sedimentar esse novo campo, esse novo
meio, do qual o próximo tipo de relacionamento vai surgir.

1.4 E R A D A UC

A terceira onda da computação é da computação ubíqua, UC, cujo ponto


de cruzamento com a computação pessoal deverá ocorrer entre 2005-
2020 [10]. A era da “UC” terá vários computadores compartilhados por
todas as pessoas. Alguns desses computadores serão centenas daqueles
que as pessoas podem acessar durante alguns minutos de consulta na
Internet. Outros estarão implantados em paredes, cadeiras, roupas,
carros – em tudo. A “UC” é fundamentalmente caracterizada pela conexão
das coisas existentes no mundo através da computação. Entre essas
coisas estão incluídas várias escalas, até microscópicas.

A figura abaixo foi obtido a partir da web, e ilustra a cronologia das três
abordagens da computação (mainframe, pessoal e ubíqua):

Figura 1: Maiores Tendências da Computação

1.5 A B O R D A G E M D O S C A P Í T U L O S

A organização deste trabalho é feita de forma a conduzir o leitor a


compreender a questão da computação ubíqua, seus principais conceitos,
e alguns exemplos de aplicações em computação ubíqua e da
infraestrutura necessária para que a computação ubíqua venha a ser
tornar uma realidade, de fato.
No Capítulo 1, introduzimos as maiores tendências da computação,
apresentando as principais definições das eras mais importantes pelas
quais a informática já passou.

O Capítulo 2, traz uma descrição detalhada sobre o conceito de


computação ubíqua e seus requisitivos de dispositivo. Ainda nesse capítulo
é apresentada a origem da computação ubíqua bem como os principais
aspectos que se tem de levar em consisderação para que a computação
ubíqua venha a se tornar de fato, uma realidade.

Dois exemplos de aplicações ubíquas serão de fato, vistos no Capítulo 3


com a explanação do projeto ParcTab e da Classroom 2000. Alguns
aspectos de arquitetura e implementação também são discutidos para as
aplicações.

Finalmente, no Capítulo 4 são apresentadas as conclusões obtidas durante


a elaboração deste trabalho, levantando também, questões referentes a
trabalhos futuros.
Computação Ubíqua 12

2. C O M P U T A Ç Ã O U B Í Q U A

O impacto social dos computadores a qualquer hora e em qualquer lugar


será análogo a duas outras tecnologias que se tornaram ubíquas. A
primeira é a escrita, que é encontrada em qualquer lugar desde etiquetas
de roupas até quadro para afixar anúncios. A segunda é a eletricidade,
que surge invisível nas paredes de todas as casas, escritórios e carros. A
escrita e a eletricidade tornaram-se um lugar comum, tão quotidiano, que
as pessoas esqueceram o tremendo impacto que elas causaram na rotina
de suas vidas. Assim será a computação ubíqua.

2.1 A F I L O S O F I A D A C O M P U T A Ç Ã O U B Í Q U A

A computação ubíqua coloca a computação na periferia da vida dos


usuários, como uma ferramenta, e não em foco, isto é, fora de seus
caminhos, permitindo assim, o verdadeiro cumprimento das tarefas que
de fato, eles necessitam ou desejam concluir. O termo “ubíquo” é usado
para exprimir que tanto os computadores, como a computação estarão
presentes em qualquer lugar, e embutidos nas estruturas de nossas vidas,
ao contrário da realidade virtual onde as pessoas são inseridas em
mundos gerados dentro do próprio computador. Em outras palavras, o
objetivo da computação ubíqua é mover os computadores do foco central
de atenção dos usuários para um mundo invisível, onde eles são usados
subconscientemente, para aumentar a eficiência das ferramentas e meios
de comunicação existentes.

Tal futuro vai trazer uma grande ajuda com relação ao atual problema de
“sobrecarga de informação”. Ao invés das pessoas se preocuparem em
lembrar as várias coisas de que necessitam, as coisas é que lembrariam
Computação Ubíqua 13

as pessoas do que e quando teriam que ser executadas. Em outras


palavras, uma pessoa poderia ser lembrada de que, já é hora para uma
troca de óleo do seu carro, ou de que está faltando café em seu armário
da cozinha, por exemplo. Ou mais além, por que não fazer com que a
própria cozinha fizesse as compras dos itens necessários através de um
simples envio de pedido a um supermercado?

Mark Weiser criou a idéia da computação ubíqua a partir de uma análise


do papel dos computadores nas atividades diárias das pessoas. Em
particular, um estudo antropológico sobre a rotina de trabalho [6,7]
mostrou que os homens vivem situações de compartilhamento e de
habilidades técnologicas não treinadas. Entretanto, tanto o computador
está isolado, como vem isolando o homem de todas as situações, e não
tem conseguido estar fora do caminho. Em outras palavras, ao invés de
ser uma ferramenta com o qual o ser humano trabalha, e portanto
deixando de ser uma preocupação, o computador tem estado
constantemente no foco das atenções. E isso é real, principalmente
quando se fala em computador pessoal, especificamente em PC’s,
“palmtops”, etc. A caracterização do computador do futuro é a de um
“computador íntimo”, ou de preferência “um assistente do homem”...

Tirar os computadores fora do caminho dos seres humanos não é uma


tarefa fácil. Esse não é um problema de interface do usuário (GUI) e sim,
uma propriedade do contexto de uso da máquina e de seus recursos,
como um todo. O problema não é de “interface”. Pela mesma razão de
contexto, também não é um problema de multimídia, resultante de uma
deficiência qualquer relativa a exibição de certos tipos de dados em tempo
real ou integração dos mesmos na aplicação. (Na realidade, a multimídia
tenta capturar a atenção, que é o oposto do ideal invisível proposto pela
computação ubíqua). O grande desafio é o de criar um novo tipo de
relacionamento entre pessoas e máquinas (computadores), na qual os
computadores teriam que tomar a dianteira quanto a sairem do caminho e
deixarem as pessoas se ocuparem de suas vidas.
Computação Ubíqua 14

Os computadores ubíquos tem que demandar menos concentração do que


as atuais interfaces comercias que requerem disponibilidade e foco.
Através de interações casuais, eles deverão prover mais informações e
mais vantagens oriundas de uma inteligência orquestrada e de sistemas
altamente conectados.

A criação de sistemas tão intuitivos e distribuídos requer dois ingredientes


chaves: contexto e comunicação. A comunicação permite que
componentes do sistema compartilhem informação sobre suas situações
(status), sobre os usuários e sobre o ambiente – que é o contexto no qual
eles operam. Especificamente, informação de contexto deve incluir
elementos tais como:

 O nome da posição corrente do usuário;


 A identidade dos usuários e das pessoas ao redor;
 Identidades e status das impressoras locais, estações de trabalho,
máquinas de café, etc.;
 Parâmetros físicos tais como: tempo, temperatura, condições de
meteorologia.

2.2 O V I S I O N Á R I O : M A R K W E I S E R

Mark Weiser foi o criador da computação ubíqua ou “ubicomp”. No


Laboratório de Ciência da Computação da Xerox Parc foram realizados
vários estudos para se poder compreender como as pessoas trabalhavam
e que ferramentas usavam. Weiser percebeu que a melhor utilização de
uma ferramenta é quando o usuário não percebe que está utilizando-a,
isto é, o usuário não percebe seu uso e dessa forma, ele pode centrar
mais atenção no trabalho que está realizando.

Dr. Weiser começou suas pesquisas em 1988 e percebeu que a tecnologia


da época não era suficiente para suportar a sua visão. Então ele se focou
primeiro, nas diferentes características da computação ubíqua, como
dispositivos que eram portáteis e cuja localização era sempre conhecida
Computação Ubíqua 15

ou em dispositivos que auxiliariam as pessoas a trabalharem em conjunto.


Os primeiros protótipos foram os “tabs”, “pads” e “boards”. “Tabs” são
similares a pequenos blocos de anotações eletrônico similares aos “Post-
It” e, poderiam haver centenas deles em um escritório, cada um
correspondendo a uma pequena surperfície com informações. Já os “pads”
são como blocos amarelos, maiores, ou computadores usados com o
objetivo de serem usados momentaneamente e depois, poderem ser
deixados para outras pessoas quaisquer. Os “boards” são enormes
quadros negros eletrônicos, que visam permitir o trabalho coolaborativo e
que estão em uso, hoje em dia.

2.3 A I N F R A E S T R U T U R A D A C O M P U T A Ç Ã O U B Í Q U A

Para alcançar as metas da Computação Ubíqua vai ser necessário uma


infraestrutura altamente sofisticada. No sistema ideal, um mecanismo de
registro sequencial de passos em tempo real vai supor as localizações e
status operacional dos inúmeros componentes do sistema e vai se utilizar
do contexto para despachar mensagens de forma mais inteligente. Os
usuários serão capazes de escolher entre uma grande variedade de
dispositivos a fim de obterem mobilidade, acesso aos dados em banda
larga e recursos computacionais em qualquer ponto da rede.
Automaticamente, eles vão adapatar seus comportamentos de modo a se
ajustar ao usuário corrente e ao contexto.

É impossível prognosticar as séries de formas dos dispositivos e suas


capacidades disponíveis daqui a uma década. Alguns trabalhos se
basearam no tamanho dos dispositivos, um fator que provavelmente
continuará a dividir os computadores em categorias funcionais. Uma
metáfora bem útil que ilustra essa abordagem é a que considera o
cumprimento tradicional das unidades, em Inglês: polegadas, pés e
jardas. Essas unidades se desenvolveram porque representavam três
escalas sinificativamente diferente sob ponto de vista humano.
Computação Ubíqua 16

 Dispositivos em escala de polegada, em geral, podem ser facilmente


associados a roupas ou objetos carregados na mão ou em bolso.
 Dispositivos do tamanho de pés também podem ser carregados,
apesar de que não, o tempo todo e os empregados vão usá-los de
modo semelhante ao modo que usam seus “notebooks” hoje em dia.
Alguns “notebooks” são pessoais e são carregados para lugares
particulares, para própositos particulares. Nossos “notepads” são
espalhados pelo local de trabalho e podem ser usados por quaisquer
pessoas e quaisquer propósitos.
 No escritório do futuro vão existir computadores com vídeos em
tamanho de jardas. Provalvelmente serão dispositivos estacionários
analogos aos quadros de avisos atuais.

2.4 Q U E S T Õ E S D A C O M P U T A Ç Ã O U B Í Q U A

Alguns aspectos atuais da computação precisam mudar de forma a ajudar


a computação ubíqua a se tornar realidade. É sabido que a computação
ubíqua vai compreender um grande conjunto de dispositivos pequenos,
onde muitos deles vão estar em comunicação constante uns com os
outros, de modo que questões como: qual seria a infraestrutura
necessaria para viabilizar a computação ubíqua; como esse tipo de
infraestrutura pode ser construído a partir da existente hoje, são algumas
das questões levantadas e que precisam ser respondidas. Assim sendo,
essa seção se propõe a analisar alguns “hardware” e limitações de
usabilidade que atualmente impedem a computação ubíqua de se tornar
realidade.

O custo dos dispositivos computacionais


Computação Ubíqua 17

Um dos fundamentos da computação ubíqua é “uma pessoa, para muitos


computadores”. De modo a satisfazer a idéia de muitos computadores,
cada computador precisa custar menos. Hoje em dia, um computador de
mesa do tipo “desktop” (como por exemplo um Palm Pilots) custam em
torno de quinhentos dolares, ou mais. Obviamente, o custo é alto para dar
margem a um computador por pessoa.

Entretanto, os tipos de computadores que estarão envolvidos na


computação ubíqua não vão precisar ser computadores para propósitos
genéricos, e não vão portanto precisar ter a mesma velocidade e
capacidade de armazenamento requerida pelos nossos tradicionais
computadores pessoais. Assim sendo, eles poderão custar menos,
especialmente porque o custo dos processadores e dos discos rígidos está
em queda constante, como parte da chamada “Moore’s Law” que
determina que a quantidade de transistores que cabe em um silicone
dobre a cada dezoito meses.

Ainda existem componentes que não tiveram queda significativa de preço.


Em especial, os monitores de computadores tradicionais e telas LCD não
apresentaram queda de preço suficiente que justificasse uma troca de
dispositivos de computador antigos por novos. A fim de que os
dispositivos para computação ubíqua tenham um custo relativamente
baixo, será necessário a produção em escala dos mesmos, como por
exemplo a produção de motores elétricos. A computação ubíqua só será
praticável quando os custos dos dispositivos apresentarem uma queda em
seus custos tal que será possível poder jogar fora computadores
individuais com monitor, sem levar em consideração o seu custo. Fazendo
uma comparação, as calculadoras de mão já tiveram um custo bem alto,
mas nos dias de hoje são tão baratas que geralmente elas são dadas
como promoção em vários produtos.

Baixo Consumo de Energia


Computação Ubíqua 18

Um dos requerimentos básicos para os dispositivos pequenos, ubíquos


também está relacionado ao baixo consumo de energia. Os usuários não
estarão dispostos a trocar baterias de centenas de dispositivos com
frequência. O computadores de preço baixo vão precisar de baterias
baratas, economicas e vão usar componentes de baixo consumo.

A carência de largura de banda

Um dos requerimentos necessários para que a computação ubíqua se


torne lugar comum é a largura de banda de rede suficiente para permitir
que centenas de dispositivos sejam capazes de se comunicar uns com os
outros. Atualmente, ainda estamos nos estágios primários de rede, mas a
medida que o tempo passa, o mundo baseado na comunicação por voz
está cada vez mais, migrando para fibra ótica e redes sem fio. Para se ter
uma idéia dos requerimentos de rede que serão necessários, um estudo
recente do MCI estimou que o atual tráfego de dados em rede vai
ultrapassar o tráfego de voz nos próximos três anos, com tendências de
aumento ainda maior para os anos seguintes.

Mobilidade

A mobilidade é outro aspecto relacionado a computação ubíqua. Os


usuários têm que ter computadores portáteis, com acesso sem fio a
Internet, a partir de qualquer ponto de acesso.

Mobile IP

O Internet Protocol (IP) assume que a localização e a conexão de um


computador permanece fixa. Um aspecto da atual pesquisa em
computação móvel é na área de protocolos como o Mobile IP que é uma
extensão do IP que possibilita os computadores se conectarem a partir de
diversos pontos de acesso e mantendo o mesmo endereço IP.
Computação Ubíqua 19

Necessidade de conscientização do usuário para com sistemas de


arquivo

Uma das primeiras coisas que os usuários precisam aprender no novo


computador é sobre o conceitos de arquivos, e a hierarquia de diretórios
que eles contem. Ao invés de concentrar na informação que eles têm
disponível, o usuário é forçado a pensar em termos de como a informação
está armazenada. Como consequência, a informação é armazenada de
forma não intuitiva fazendo com que o usuário perca o rastro de
localização dos arquivos, sobreponha novas versões de arquivos por
versões antigas, exclua diretórios que contenha arquivos importantes, por
acidente etc. Qualquer usuário de computador tem sua própria história
aterrorizadora sobre exclusão acidental de arquivos, e quase na maioria
das vezes, quando recuperáveis, acabaram resultando em perda de dados
devido a natureza dos sistemas de arquivo.

Uma das idéias chaves da computação ubíqua é a de que os


computadores devem se tornar invisíveis, e que eles têm que fornecer
informações aos usuários na própria linguagem de usuário. Por exemplo,
quando o usuário deseja trabalhar com um relatório do dia anterior, eles
não deveriam ser forçados a lembrar de alguma coisa tal como
“~/report.txt”, ou “C:\report.txt”, uma vez que isso seria forçar o usuário
a pensar usando linguagem do computador. Seria mais simples para o
usuário, se ele pudesse dizer em voz alta “abra o arquivo de ontem”. É
claro que tal funcionalidade iria demandar um reconhecimento de voz de
alta qualidade, que está começando a ficar mais praticável nos
computadores atuais. Mas, qualquer que fosse o esquema de acesso, o
principal conceito é o de que o usuário pode acessar seus dados sem a
necessidade de um conhecimento do nome dos arquivos ou de suas
localizações, informações que são atualmente pedidas a ele. O usuário
poderia acessar uma dado estritamente através do seu contexto, sem a
preocupação sobre o formato do arquivo, a localização do arquivo, ou
mesmo em que máquina tal arquivo foi salvo.
Computação Ubíqua 20

A necessidade de instalação de programa

Hoje em dia, quase todo programa (“software”) existente precisa ser


formalmente instalado em um computador. Isto significa dizer que, o
computador tem que ser submetido a um processo de reconfiguração
rigoroso para que o novo programa possa rodar adequadamente.
Bibliotecas compartilhadas precisam ser instaladas com o caminho (path)
correto, configurações globais precisam ser mudadas ( às vezes, exigindo
que o usuário faça um novo “reboot” do computador), preferências
“default” do usuário precisam ser determinadas pela primeira vez e assim
por diante. Na maioria dos casos, uma pessoa tem que acompanhar
manualmente um processo de instalação, de forma a assegurar que todo
o processo ocorreu corretamente, e em alguns casos, assegurar-se de que
o produto recém instalado não se trata de nenhum ataque a segurança,
tal qual um tipo de vírus. A única excessão à regra é no que diz respeito
a programas embutidos do tipo “firmware”, que são confeccionados como
uma parte do “hardware”.

Para que a computação ubíqua aconteça de verdade, o conceito de


instalação tem que desaparecer. Ao invés da pessoa ir até o programa, o
programa tem que vir à pessoa e, como consequência, o programa tem
que fluir livremente de um computador para o outro sem demandar que
cada computador tenha mudanças essenciais de configuração para poder
executá-lo. Os computadores têm que saber separar os programa em
pedaços, de modo que os novos programas não sejam consumidores
ilimitados de recursos ou acessem arquivos que não estão relacionados
com os mesmos. Além disso, já que um programa poderá ir de um
computador para o outro, todos os rastros deixados por ele devem ser
removidos do computador anterior assim como as preferências de usuário.
O uso dos “softwares” tem que se tornar “stateless”, onde cada programa
está sempre pronto para executar suas funções a qualquer momento, sem
necessidade de configuração prévia.
Computação Ubíqua 21

Uma analogia a isso é o conhecido arquivo de texto em ASCII. Esses


arquivos texto podem ser simplesmente levados de um computador para
o outro, idenpendentemente do sistema operacional que esteja rodando:
Unix, Windows, OS/2, etc. Nunca há uma preocupação quanto a
necessidade de instalação e desinstalação, assim como não há a
preocupação da existência de um arquivo corromper o sistema. Para que a
computação ubíqua possa ser bem sucedida, os programas também terão
que ter a mesma filosofia: Uma entidade de fácil transferência, escrita em
formato universal.

O candidato a “formato universal” mais próximo para programas, que


existe atualmente é o Java. Existem dois pontos muito fortes a seu favor.
O primeiro, é que o formato de armazenamento de código usado
independe de processador, tornando-o bastante viável para transferências
entre computadores. A questão sobre que tipo de processador um dado
computador possui se torna irrelevante. O segundo, é a segurança que
está embutida no formato, que faz com que se torne praticamente
impossível que chamadas indevidas ao sistema sejam permitidas. Isso o
torna também bastante viável para transferências, já que nenhum
programa Java terá a capacidade de violar a segurança da máquina em
que está hospedado. O maior obstáculo para o Java é que sua interface de
programação ainda é baseada em versões, o que inviabiliza a codificação
de programas que levam a versão em consideração. Não será possível
usar Java para computação ubíqua até que duas coisas aconteçam: ou a
interface de programação é congelada ( o que é bastante improvável,
dado o histórico em computação), ou algum tipo de sistema seja
estabelecido de forma que a interface de programação seja transportada
pelo programa que a utiliza.
Aplicações Ubíquas 22

3. A P L I C A C Õ E S U B Í Q U A S

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.


Aplicações Ubíquas 23

3.1 P A R C T A B

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.1 M O T I V A Ç Ã 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:


Aplicações Ubíquas 24

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.2 P R O J E T O D E S I S T E M A

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.
Aplicações Ubíquas 25

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
Aplicações Ubíquas 26

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


Aplicações Ubíquas 27

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.3 P R O J E T O D E I N T E R F A C E

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


Aplicações Ubíquas 28

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.
Aplicações Ubíquas 29

Figura 4: O alfabeto Unistroke

3.1.4 A R Q U I T E T U R A D E S I S T E M A

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.
Aplicações Ubíquas 30

Figura 5: A Arquitetura de Sistema ParcTab

3.1.5 D E S E N V O L V I M E N T O D E S I S T E M A E

C O M P O N E N T E S D A A P L I C A Ç Ã 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.
Aplicações Ubíquas 31

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.6 C L A S S I F I C A Ç Õ E S D A S A P L I C A Ç Õ E S

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
Aplicações Ubíquas 32

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.

I. 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.
Aplicações Ubíquas 33

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.

II. COMUNICAÇÃO
Aplicações Ubíquas 34

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.

III. 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
Aplicações Ubíquas 35

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.

IV. 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
Aplicações Ubíquas 36

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.7 E X P E R I Ê N C I A S C O M O P A R C T A B

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
Aplicações Ubíquas 37

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.
Aplicações Ubíquas 38

3.1.8 C O N C L U S Õ E S

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.
Aplicações Ubíquas 39

3.2 CLASSROOM 2000

Essa aplicação foi desenvolvida no Instituto de Tecnologia da Georgia,


Atlanta, EUA durante sete meses e testada com alunos do departamento
de Ciência da Computação do Instituto.

3.2.1 M O T I V A Ç Ã O

Suponha um cenário onde um estudante que estivesse estudando para


uma prova de uma dada disciplina, desejasse pesquisar um repositório de
dados que contivesse toda a informação coletada durante todo o curso.
Esse repositório incluiria uma pesquisa no material apresentado pelo
professor em sala de aula, pelas notas do aluno em sala de aula e os
audios e os vídeos correspondentes às aulas em si. E finalmente, suponha
que essa recuperação de informação e associação pudesse ser feita por
todas as aulas que o aluno tivesse assistido ou por todas as aulas dessa
disciplina e que foram ministradas na instituição de ensino ao qual o aluno
pertencia. O suporte automatizado para captura, exploração e reprodução
dessa fonte de informação rica e dinâmica que é compartilhada em sala de
aula é o objetivo dessa aplicação.

3.2.2 O P R O T Ó T I P O

O projeto do protótipo do “Classroom 2000” foi dividido em três fases


distintas – pré-produção, uso “em-classe” e pós-produção. As sub-seções
a seguir descrevem cada uma dessas fases detalhadamente.

Fase de pré-produção

Assim como no modelo baseado em sala de aula, o professor se prepara


de alguma maneira para cada aula, na fase de pré-produção também há a
preparação de uma apresentação completa de transparências que será
mostrada ou mesmo, a de preparação de uma apresentação mais informal
Aplicações Ubíquas 40

a ser usada em sala. Qualquer material que o professor deseje


disponibilizar para os alunos durante a aula tem que ser transformado
para um formato que possa ser armazenado nos blocos de notas
eletrônicos (“electronic notepads”) dos alunos e apresentado durante a
aula no quadro-negro eletrônico (“electronic liveboard”).

Inicialmente, esse trabalho só dá suporte pleno para apresentação da


informação estática em sala de aula, isto é, são suportados tipos de aula
que compreendem escrita em quadros negros, quadros brancos, ou
usando projeções de transparências ou “slides”. Já o suporte que envolve
a apresentação de vídeos ou qualquer outra informação dinâmica como
simulações em computadores ou demonstrações ao vivo não foi
contemplado. O suporte a informação dinâmica é cogitado para o futuro.

O “Classroom 2000” se propos a minimizar o impacto que causa a


preparação de uma aula, principalmente porque a maioria das aulas já
terá algum material a ser reutilizado. Quanto mais for necessário recriar
informação, menos provável será a adoção da tecnologia “Classroom
2000”. Adotou-se o “PostScript” como o formato universal para
representação de material de sala-de-aula e filtros de domínio público
(Unix) para converter arquivos PostScript em uma sequência de imagens
(em formato GIF ou BMP).

O último passo da fase de pré-produção é o de carga dos arquivos de


imagens nos blocos-de-notas eletrônicos e no quadro-negro eletrônico os
arquivos para a aula.

Fase “em-sala de aula”/ “ao vivo”

Essa é a fase da sala de aula propriamente dita onde o instrutor usou um


quadro-negro eletrônico (“liveboard”) que era um PC com uma tela de 67
polegadas com uma caneta eletrônica (“pen-sensitive”). Os alunos
usaram uma variedade de dispositivos “pen-based”, desde “pranchetas
digitais” x86 até um PC 486 de mão. Todos os dispositivos (“liveboard” e
Aplicações Ubíquas 41

os dos estudantes) rodavam o MS Windows for Pen Computing sobre o


MS Windows 3.1.

Também foram produzidas uma apresentação em “slides” e uma aplicação


de anotações em MS Visual Basic chamada ClassPad para rodar em todos
os dispositivos. Essa aplicação teve que ser especialmente produzida
porque nenhuma das existentes disponíveis permitia o registro dos
eventos anotados com a caneta eletrônica bem como, também não
convertiam as anotações resultantes (em formato de “slides”) em um
formato que fosse facilmente mostrado em qualquer “Web browser”. A
figura 6 mostra uma tela típica da aplicação ClassPad.

À medida que o professor ministrava a aula, ele podia ir marcando os


“slides” com anotações adicionais, de maneira similar à que ele usaria
para escrever com uma caneta sobre as transparências se estivesse
utilizando um retroprojetor. Os alunos tinham as suas próprias cópias dos
“slides” o que lhes permitia percorrê-los e marcá-los como bem
entendessem durante a aula. Também era permitido a criação de novos
“slides” em sala de aula, caso fosse necessário.
Aplicações Ubíquas 42

Figura 6: A Aplicação ClassPad

Todo o audio da aula era gravado digitalmente. À medida que os “slides”


eram passados e anotados, também eram registrados alguns eventos
significantes (ex.; troca de slides, anotação em um “slide” com um
movimento contínuo de escrita) e as anotações eram salvas em um
arquivo intermediário. Ao final da aula, a aplicação ClassPad era encerrada
e todos os registros e anotações eram salvos.

Pós-produção

A fase de pós-produção é aquela após o término da aula. Seu propósito


era o de suportar o estudante e o professor na revisão do material das
aulas. Tanto alunos como professores poderiam verificar os “slides”
anotados em sala e todas as anotações feitas por alunos em uma
determinada aula específica , através do acesso via “web” do programa do
curso (figura 7).

Figura 7: Programa do curso, com indicações de materiais


Aplicações Ubíquas 43

Através de um “browser” compatível com “frames” aluno e professor


teriam acesso a apresentação da sala de aula divida em três panéis. O
painel superior contem uma visão geral reduzida de todos os slides de
uma aula específica permitindo que qualquer um deles seja selecionado e
uma imagem detalhada seja exibida no painel inferior direito. O slide que
tiver sido selecionado fica indicado no painel geral supeior em vídeo
reverso realçado, como mostrado na figura 8. O painel inferior esquerdo
revela algumas informações sobre o conteúdo do slide, uma lista de de
“links” de audio e um “link” para uma página de pesquisa baseada em
conteúdo.

Todo o conjunto (apresentação e anotações) era gerado automaticamente


a partir dos arquivos de registro histórico de uma aula onde o ClassPad foi
usado. Através da associação entre um determinado “slide” e um
determinado registro de data e hora poderia se ter acesso ao audio
gravado naquela apresentação específica. Havia um programa de audio
que permitia que o estudante utilizasse a interface gráfica para percorrer
a trilha em qualquer direção.

As anotações eletrônicas agregavam um valor adicional em relação as


anotações feitas em papel. Sem esses recursos adicionais era difícil
justificar a utilização das anotações eletronicas. Um outro recurso
disponibilizado na fase de pós-produção, era a habilidade de fazer
pesquisa baseada em conteúdo (limitada) nos “slides” de todo um curso.
Usando o texto de rodapé dos slides de aula, criou-se um índice invertido
de palavras-chave para os “slides” de uma determinada aula, mostradas
no topo do painel esquerdo inferior apresentado na figura 8. Ao
selecionar o “link” à esquerda, o estudante acessava um formulário
através do qual ele poderia submeter perguntas textuais simples que
pudessem servir de argumento de pesquisa para os “slides”das aulas de
um dado curso. Por exemplo, o estudante poderia pesquisar todos os
Aplicações Ubíquas 44

slides que contivessem a palavra “Evaluation”. O resultado da pesquisa


seria uma outra página de três painéis, sendo que os “slides” mostrados
não estariam limitados a uma única aula.

Figura 8: Revisão da apresentação


Aplicações Ubíquas 45

Figura 9: Programa cliente de audio

No futuro será possível fazer algum pós-processamento adicional na


informação coletada em sala de aula (anotações e audio). Por exemplo,
será possível usar um sistema de reconhecimento de voz para prover uma
pesquisa baseada em palavras-chave em uma aula ou em um conjunto de
aulas. Além disso, também será permitido usar o reconhecimento de
escrita para converter as anotações em um formato mais compatível com
pesquisa automatizada. Será possível a criação de “links” automáticos
dentro e entre aulas ligando partes do curso que discutam o mesmo
tópico. Essas capacidades adicionais suportariam tanto o estudante
quanto o professor na revisão das aulas e do material do curso. Por fim, o
conteúdo completo do curso poderia resultar em um livro online
multimídia.

3.2.3 A R Q U I T E T U R A D O S I S T E M A E Q U E S T Õ E S D E

I M P L E M E N T A Ç Ã O

Apesar das severas críticas, a prototipação em três fases facilitou o


desenvolvimento e permitiu a modificação e o aperfeiçoamento de certas
funcionalidades do sistema com impactos mínimos umas nas outras.
Aplicações Ubíquas 46

Outra decisão importante foi a adoção de um padrão “Web” para a


arquitetura do sistema. A “Web”, por excelência, permite o acesso multi-
plataforma a um sistema de arquivos compartilhados, e todas essas
características foram importantes na concepção do sistema. Além disso,
uma das importantes características de aprendizado a longo prazo é a
relação entre a informação nova e a informação antiga. Seja essa
relação resultante de uma associação explícita feita pelo estudante
durante a revisão ou inferida automaticamente pelo sistema, a operação
básica a ser suportada é o estabelecimento de uma ligação entre duas
porções de informação.

O que se pretende é que todas as fases do projeto estejam suportadas


pelo modelo “Web” e por suas ferramentas. O protótipo já permitiu
anotações ao vivo em sala de aula, usando mapas de imagem localizados
no lado da aplicação cliente. Quando o “browser” tiver uma interface
baseada em caneta eletrônica (“pen-based”) será possível finalmente
transportar a fase “em-sala-de-aula” para “Web”, também.

Outra decisão crítica na arquitetura do sistema foi modelar as anotações


em formato de imagem. Em várias montagens da sala de aula, os
professores forneceram aos estudantes transparências ou anotações
previamente montadas antes da aula e a maioria deles considerou isso
uma vantagem. Além disso, muitas das outras tarefas desempenhadas no
dia-a-dia envolviam tomada de notas. Por exemplo, os professores
corrigiam textos de alunos por meio de anotações. Portanto, esse modelo
em forma de anotações foi útil para a sala de aula.

Sabia-se também que qualquer coisa manuscrita por cima de uma


transparência poderia perder o significado se a transparência fosse re-
exibida de uma forma diferente (altamente provável se utilizados “Web
browsers” genéricos em diferentes tamanhos de tela). A adoção de uma
padrão de imagem “bitmap” poderia evitar esse problema.
Aplicações Ubíquas 47

A contrapartida dessa decisão foi que toda transferência de arquivos eram


mais lentas (“downloading” de pré-produção, “uploading” de pós-
produção e carga da imagem em um Web Browser). Além disso, o formato
das páginas de revisão era menos flexivel em termos de como elas
poderiam ser exibidas.

Uma consideração final do desenho era o fato de que, ao final, se


pretendia ter a capacidade de recriação de toda a experiência de sala de
aula. Isso significa que será permitido se ter a capacidade de manipular
fontes de mídia mais rica a níveis de granularidade menores. Por exemplo,
ao apontar para uma anotação qualquer, o aluno poderia perguntar
durante a revisão, “O que o instrutor estava dizendo quando eu escrevi
isso?”. Ou o estudante poderia querer achar as anotações associadas a
uma apresentação ao vivo que ocorreram em algum ponto da aula. A
solução que se apresentou para revisão e indexação da trilha de audio
para a aula foi também aplicada a video. A restrição que se tinha era a de
armazenamento eficiente e a de apresentação. A granularidade em
relação ao registro histórico que se tinha era muito grosseira devido
principalmente a interface de programação limitada que o Visual Basic
tinha e usado para desenvolver o ClassPad. Para fins de protótipo, O
Visual Basic foi de excelente utilidade mas para desenvolvimento de um
produto em si, seria necessário pesquisar outros ambientes mais flexíveis.

Essas últimas ressalvas comprovaram a necessidade de se tratar a fase


“em sala de aula” como uma atividade de captura inteligível. A carga das
atividades futuras com relação ao aprimoramento do Classroom 2000
estarão relacionadas as atividades de pós-produção necessárias na
reconstrução e na filtragem das informações.
Aplicações Ubíquas 48

3.2.4 A V A L I A Ç Ã O D A E F I C Á C I A

Protótipos Iniciais

A infraestutura do Classroom 2000 foi desenvolvida durante o outono do


ano de 1995 pelo Georgia Tech. Durante esse trimestre, ao mesmo tempo
em que o desenvolvimento acontecia, quarenta estudantes da
universidade proviam “feedbacks” constantes sobre vários aspectos do
sistema protótipo como por exemplo: uso do quadro-negro eletrônico, uso
da aplicação ClassPad, serviço de audio.

Os estudantes apreciaram o aumento da participação em sala de aula que


foi influenciado pelo quadro-negro eletrônico e pela disponibilização e
riqueza do material que era fornecido a eles depois das aulas
(principalmente quando eles faltavam aula). Vários estudantes também
optaram por desenvolver e implementar uma ferramenta em SmallTalk
para ajudar na construção da aplicação “Web” do programa do curso,
facilitando a tarefa de manutenção da página por parte do professor. E
embora o serviço de audio só estivesse disponível para uma aula, os
estudantes também acharam muito útil poder escutar as discussões que
aconteceram em sala de aula ao mesmo tempo em que olhavam as notas
estáticas que tinham sido coletadas durante a aula.

A Experiência Completa

Durante dez semanas do inverno do ano de 1996, o protótipo completo do


Classroom 2000 foi usado com vinte e cinco estudantes do curso de
graduação da Ciência da Computação, para a aula de Interface Humano
Computador[3]. Os recursos tecnológicos do projeto foram sendo
gradativamente introduzidos em sala de aula começando com o quadro-
negro eletrônico, depois o serviço de audio e finalmente, as unidades
móveis para os estudantes. Na terceira semana, os alunos já estavam
fazendo anotações eletrônicas. Quatro dos alunos (os regulares) foram
Aplicações Ubíquas 49

selecionados para fazer anotações usando a ClassPad, durante dez aulas.


Quatro estudantes (os relutantes) optaram por não fazer anotações
eletrônicas durante todo o curso. O resto deles (os eventuais) usaram
outro tipo de recurso.

As avaliações foram feitas da seguinte forma: no início, foram distribuídos


questionários para que se pudesse avaliar as reações iniciais dos
estudantes ao Classroom 2000 ao longo do curso. Além disso, foi pedido
que os estudantes mantivessem um diário de suas anotações à mão e
eletrônicas e um histórico das respostas dadas a pequenos questionários
que avaliavam suas reações em relação ao uso da tecnologia em sala de
aula especificamente naquele dia e se eles tinham usado a aplicação
“Web” para revisão desde a primeira aula. Ao final do curso, os alunos
preencheram um outro questionário que tinha por objetivo investigar as
sua s reações como um todo. A tabela 2 contém um sumário das
respostas dos alunos com relação a um pequeno grupo de perguntas que
avaliavam a eficácia do Classroom 2000. Os alunos proveram as respostas
a afirmações da tabela 2 com base na seguinte escala: 1 (discorda
fortemente); 2 (discorda); 3 (neutro); 4 (concorda); 5 (concorda
fortemente).

Tabela 2: Respostas ao Questionário Final

A disponibilização das anotações feitas no quadro-negro eletrônico em


conjunto com o audio fizeram com que os alunos não se sentissem tão
Aplicações Ubíquas 50

preocupados quando algum deles não podia estar presente à aula embora
eles não tenham sido encorjados a faltar às aulas. Os alunos (os
regulares) que usaram a aplicação ClassPad se mostraram menos
positivos quanto ao uso da tecnologia em sala de aula. Eles explicaram
que o tempo de resposta das unidades individuais era mais lento do que o
do quadro-negro eletrônico causando uma certa frustração. Isso então,
diminuiu a probabilidade dos alunos consultarem os “slides” já que, a
troca de “slide” era uma das operações mais demoradas. Um outro
aspecto foi o fato de que os alunos gastaram muito tempo copiando
textualmente o que o professor tinha escrito no quadro-negro eletrônico.
Apesar do ClassPad objetivar minimizar o tempo gasto com anotações,
essa avaliação pareceu evidenciar o contrário.

Para aqueles alunos que usaram o ClassPad ocasionalmente ou nunca


usaram essa aplicação, consensaram de que a tecnologia disponibilizada
em sala de aula os liberou da tarefa de anotação e lhes proporcionou mais
tempo para se concentrarem e entenderem o material apresentado em
sala.

Os estudantes foram questionados quanto ao fato deles abandonarem o


uso de papel em favor do uso da caneta eletrônica. Apesar de algumas
oposições que preocuparam-se com o fato de que nem todos os
estudantes tinham uma conexão de internet rápida em suas casas ou de
que a leitura do material no vídeo do computador poderia lhes fazer mal,
quase que metade dos estudantes confirmaram que eles largariam as
anotações manuais. Algumas das razões que eles apresentaram foi a de
que as anotações acessadas eletronicamente eram mais organizadas,
poderiam ser mais pesquisadas e tinham tendência a se tornarem mais
valiosas pelo fato de que a essas anotações poderiam ser incorporadas as
anotações de outras aulas. Vários alunos notaram que eles só
conseguiram comprovar o benefício do uso do Classroom 2000 somente
após uma exposição prolongada.
Aplicações Ubíquas 51

3.2.5 R E C O M E N D A Ç Õ E S E T R A B A L H O S F U T U R O S

Nessa seção são apresentadas algumas soluções para os problemas


levantados durante a experiência de prototipação.

A fase “em sala de aula” foi operada em modo desconectado e é evidente


que se pode perceber algumas vantagens com relação a serem fornecidos
diferentes níveis de conexão entre as anotações do professor e as
unidades dos alunos e, entre os alunos entre si. A conexão entre o
quadro-negro eletrônico e as unidades dos estudantes permitirá que os
estudantes possam fazer cópias seletivas das anotações do professor.

A aplicação ClassPad contou com uma interface de tela única, o que por
um lado facilitou e simplificou seu uso mas, que por outro foi um tanto
limitante. O acesso a múltiplas telas proporciona a capacidade de
visualização concorrente das anotações dos estudantes e das anotações
do professor. Uma simples gesticulação pode vir a acionar uma cópia de
anotações de uma lado para o outro ou pode implicar na criação de ‘links”
hipertexto entre diferentes anotações. Essa facilidade também pode ser
estendida para permitir que os estudantes possam vir a visualizar as
anotações uns dos outros, desde que estejam conectados e que se resolva
algumas questões de segurança. Outra vantagem do acesso múltiplo é o
fato de que os estudantes também podem recuperar anotações de aulas
anteriores. Durante a prototipação, houve vários momentos onde
comprovou-se que essa funcionalidade teria sido bastante útil.

O acesso múltiplo porém incorre em um outro problema que é relacionado


aos diferentes tamanhos de dispositivos. Várias críticas foram feitas com
relação ao tamanho da tela dos palmtops. Considerou-se a possibilidade
de dar aos alunos múltiplas unidades para que eles pudessem ter mais
área de visualização. Entretanto, como as unidades dos alunos não seriam
próprias deles, pensou-se em equipar a sala com vídeos maiores e até
Aplicações Ubíquas 52

mesmo trocar o “desktop” inteiro por um vídeo sensível a caneta


eletrônica.

Haviam vários outros projetos que se desenvolveram com base nas fases
do Classroom 2000. A maioria deles concentrou seus esforços em
aplicações de anotação durante a fase “em sala de aula”, de forma que os
alunos pudessem utilizar palavras-chaves para acelerar o processo de
anotação como por exemplo, o projeto Marquee[9], fornecer uma
avaliação anônima imediata sobre as questões ou tópicos apresentados
pelo professor e melhorar o modo de revisão.

Alguns problemas enfrentados foram pela falta de acesso ubíquo para


algumas características do sistema. Só foi possível dar acesso ao
programa de audio Unix. Está sendo desenvolvido uma aplicação de audio
em Java que vai proporcionar essa capacidade de acesso multi-
plataforma. A pesquisa baseada em contexto só foi apresentada ao final
do ano letivo para ajudar nos exames finais, o que foi um pouco tardio
para que se pudesse perceber seu benefício. Além disso, essa pesquisa
baseada no conteúdo só funcionava para o material preparado para a aula
e conclui-se que também seria necessário disponibilizar esse tipo de
pesquisa para a parte do audio e para as anotações individuais.

Os alunos se queixaram de que as anotações que foram disponibilizadas


estavam em modo de leitura e eles não podiam editá-las durante as aulas.
O que aconteceu é que essas anotações estavam disponíveis para serem
acessadas por um editor HTML mas os alunos não souberem tirar
vantagem disso.

Também se percebeu que essa aplicação foi baseada em interface sensível


a caneta eletrônica e que poderiam ter sido explorados outros tipos de
dispositivos de entrada, especificamente o teclado e o papel. Por outro
lado, essa perspectiva só requereu esse tipo de computador na
Aplicações Ubíquas 53

universidade já que a fase de pós-produção pode ser executada por


qualquer computador que suporte um “Web browser” .

Embora a outra intenção desse projeto seja a da possibilidade de


recriação da sala de aula, ainda é necessário que se consiga capturar mais
informação que ainda é perdida. Para isso tem se investido em tecnologias
de vídeo e na interação entre todos os alunos com a aplicação ClassPad.

Espera-se que esse tipo de aplicação seja bastante rico para a área de
aprendizado através de máquinas.
Conclusão 54

4. C O N C L U S Ã O

A proliferação de dispositivos com alguma espécie de computação


promete mais do que simplesmente uma infraestrutura de computação
disponível a qualquer momento, ela sugere novos paradigmas de
interação inspirados no acesso constante a informação e aos recursos de
computação.

Mark Weiser ressaltou que toda a discussão em torno da computação


ubíqua resume-se no desenvolvimento de aplicações que impulsionem a
criação de dispositivos e de infraestrutura. O verdadeiro objetivo da
computação ubíqua é o de permitir a interação de muitas atividades
isoladas e que juntas promovem a integração unificada e contínua entre
seres humanos e serviços disponibilizados através computação.

A pesquisa em computação ubíqua requer algumas novas noções de


escala; seja em quantidade e tipo de dispositivos, em distribuição da
computação pelo espaço físico ou em quantidade de pessoas usando um
sistema. Surge uma nova área de pesquisa em aplicação, computação
onipresente. A medida que a disponibilidade da computação não fica
restrita a um “desktop”, as relações entre homens e computador muda,
propiciando uma interação contínua que vai desde uma
ferramenta/aplicação local até se tornar uma companhia constante. O
projeto para tais aplicações tem que levar em consideração a interrupção
e a retomada da interação, não podendo deixar de representar as
passagens no tempo e fornecendo modelos de armazenamento
associativos.

A existência de recursos tecnológicos mais adequados e a sua utilização


apropriada são aspectos extremamente importantes para o sucesso e a
maior aceitação das aplicações ubíquas. Por exemplo, a substituição
Conclusão 55

completa do papel tem que ser mais bem avaliada. Papel ainda é muito
bom e bem aceito para algumas coisas. Ele tem uma resolução muito alta,
é confiável, portável e de baixo custo. Os progressos na área da visão e a
sua aplicação em projetos pode vir a quebrar barreiras entre o mundo
eletrônico e e o mundo digital.

Recursos ainda não são suficientemente disponibilizados para essa área de


aplicações ubíquas para ajudá-la a ser tornar de fato uma realidade e para
demonstrar o benefício que ela pode vir a proporcionar.

Em suma, à medida que a computação tem se tornado mais ubiquamente


disponível, é extremamente necessário que as aplicações/ferramentas
oferecidas exerçam seus papéis em atividades de mais longa duração.
Embora os princípios da computação onipresente/do dia-a-dia possam ser
aplicados às interfaces “desktop”, os desafios de projeto são mais
relevantes quando se tem um usuário que constantemente está trocando
de contexto.

4.1 T R A B A L H O S F U T U R O S

Dentre as tendências observadas ou desafios que estão abertos para as


aplicações ubíquas, pode-se mencionar:

 Aplicações ubíquas que estejam mais no domínio do dia-a-dia e


caracterizadas pela sua disponibilidade contínua, integradoras e
provendo uma interação sem impedimentos;

 Outro ponto interessante é o de desenvolvimento de aplicações que


não sejam para computadores do tipo “desktop” , isto é, que
explorem uma interação física entre homem e computador que seja
menos baseada no paradigma desktop/teclado/mouse e mais na
forma como os seres humanos interagem com o mundo físico. Ações
como falar, escrever e gesticular devem e podem ser usadas
Conclusão 56

implicita ou explicitamente como entrada dos novos tipos de


sistemas ubíquos. Sistemas com interfaces que suportem mais a
forma natural do ser humano se comunicar estão começando a
substituir os elementos do paradigma GUI ;

 Outro ponto que desperta interesse é o do surgimento cada vez


maior, de tecnologias de reconhecimento de voz e da escrita e
baseadas em percepções para a entrada de dados. A interação
baseada em canetas ou em formas livres estão reaparecendo após o
fracasso da primeira geração[1] ;

 Aplicações ubíquas baseadas em contexto – até hoje essas


aplicações só levaram em consideração a localização e a identidade.
Muitos sistemas baseados em contexto ainda não incorporaram
conhecimento sobre horário, histórico, informações sobre outras
pessoas no ambiente que não apenas o usuário, e alguns outros
tipos de informações que se tem disponível no ambiente;

 Acesso e captura automática de experiências vividas – é necessário


o desenvolvimento de aplicações que capture pedaços
independentes de informação, automatize as relações semânticas e
temporais existentes entre esses pedaços de informação e seja
capaz de disponibilizar interfaces flexíveis, acessíveis e socialmente
apropriadas. Um conjunto de aplicações desse tipo pode tirar a
sobrecarga com o tempo gasto para o registro/gravação das
informações e dar mais liberdade para que o ser humano se
concentre mais em atividades que sejam mais importantes;

 Contínua proliferação de dipositivos de diferentes escalas, com


resolução de vídeo cada vez melhores e com boa receptividade a
entrada de dados, com custo relativamente baixo. Uma questão
também relacionada é o baixo consumo de energia, mesmo que tais
dispositivos estejam sendo usados em conexões de banda larga;
Conclusão 57

 Outra área de interesse para trabalhos futuros seria intensificar as


pesquisas em Ambientes Reativos (“Reactive Environments”). Esse
tipo de ambiente pode ser uma casa ou um prédio com dispositivos
computacionais distribuídos pelo ambiente, onde os dispositivos tem
comunicação uns com os outros, sem que seja através de uma rede,
aumentando a utilização desse ambiente. Um ambiente como esse
usaria dispositivos tais como cameras, microfones detetores de
movimento e sensores de contato que permitisse a detecção das
atividades e das intenções dos usuários para que pudessem reagir
de acordo. Um típico exemplo deste tipo de ambiente é o da
aplicação Classroom 2000.
Lista de Acrônimos 58

L I S T A D E A C R Ô N I M O S

GUI G RAPHIC U SER I NTERFACE


IR I NFRA - VERMELHO
LAN L OCAL A REA N ETWORK
PDA P ERSONAL D IGITAL A SSISTANT
PIM P ERSONAL I NFORMATION M ANAGEMENT
UC U BIQUITOUS C OMPUTING
VCR VIDEO CASSETE RECORDER
ISDN I NTEGRATED S ERVICE D IGITAL N ETWORK
HTML H YPER T EXT M ARKUP L ANGUAGE
GPS G LOBAL P OSITIONING S YSTEM
Referências Bibliográficas 59

R E F E R Ê N C I A S B I B L I O G R Á F I C A S

[1] ABOWD, Gregory, MYNATT, Elisabeth. Future Directions for


Ubiquitous Computing. GVU Center and College of
Computing, Fevereiro de 1999.
[2] ABOWD, Gregory, ATKESON, Chris, FEINSTEIN, Ami,
GOOLAMABBAS, Yusuf, HMELO, Cindy, REGISTER Stott,
MIKIYA Tani. Classroom 2000: Enhancing Classroom
Interaction and Review. GVU Center and College of
Computing, GIT-GVU-96-21.
[3] ABOWD, G. Human-Computer Interaction. Graduate Computer
Science Course offered at George Tech, 1996. Disponível
em
http;//www.cc.gatech.edu/computing/classes/cs6751_96_winter

[4] BURBEY, Ingrid. Ubiquitous Internet Computing. 1996.


Disponível em
http://ei.cs.vt.edu/~wwwbtb/fall.96/book/chap24/index.html
[5] DANIELS, Alan. Ubiquitous Computing. Dezembro de 1997.
Disponível em
http://www.cc.gatech.edu/classes/cs6751_97_fall/projects/
gacha/daniels_essay.html
[6] IDC. Transition to the Information Highway Era. 1995-1996.
Information Industry and Technology Update, pp. 2.
[7] LAVE, Jean. Situated learning: legitimate peripheral
participation. Cambridge University Press. Cambridge. Nova
York, 1991.
[8] SUCHMAN, Lucy A. Plans and Situated Actions:The problem of
human-machine communication. Xerox PARC Technical
Report ISL-6, Fevereiro de 1995.
[9] WEBER, K. e POON, A. Marquee: A tool for real-time video
logging. Em Abril, 1994. CHI-94, pp. 58-64.
[10] WEISER M., BROWN S. John. The Coming Age of Calm
Technology. Xerox PARC. Outubro de 1995. Esse artigo foi
uma revisão da versão: Weiser & Brown. “Designing Calm
Technology”, PowerGrid Journal, v 1.01. Disponível em http:
Referências Bibliográficas 60

//www.ubiq.com/hypertext/weiser/acmfuture2endnote.htm

[11] WEISER, M., Ellis J., GOLDEBERG D., PETERSEN Karin, GOLD,
R., ADAMS Norman, SCHILIT N. Bill, WANT Roy. The
ParcTab Ubiquitous Computing Experiment. University of
California, 2000. Disponível em http://citeseer.nj.nec.com/
su00mobility.html
[12] WEISER, M. The computer for the 21st century. Scientific
American, 265(3): pp. 94-104, Setembro de 1991.
Disponível em
http://www.ubiq.com/hypertext/weiser/SciAMDraft3.html

[13] WEISER, M. Hot Topic: Ubiquitous Computing. IEEE Computer,


pp. 71-72, Outubro de 1993.
[14] WEISER, M. Some computer science issues in ubiquitous
computing. CACM, 36(7): pp. 74-83, Julho de 1993.
Disponível em
http://www.ubiq.com/hypertxt/weiser/UbiCACM.html

[15] WEISER, M. The world is not a desktop. Interactions, pp. 7-8,


Janeiro de 1994. Disponível em
http://www.ubiq.com/hypertext/weiser/ACMInteractions2.html