Um estudo sobre arquiteturas de software paracomputação ubíqua

Rubens de S. Matos JúniorDepartamento de Computação

Universidade Federal de Sergiperubens.matos@gmail.com

Rogério NascimentoDepartamento de Computação

Universidade Federal de Sergipe

ABSTRACTTexto pendente

KeywordsComputacao ubıqua, computacao pervasiva

1. INTRODUÇÃOA computacao ubıqua e uma das areas mais promissorase que tem merecido grande atencao deste a ultima decada.Neste trabalho apresentaremos alguns conceitos de computacaoubıqua, elucidando quais os desafios principais dos softwaresubıquos. Tambem serao mostrados alguns dos modelos exis-tentes para o desenvolvimento desse tipo de aplicacao, procu-rando chegar ao nıvel de uma arquitetura comum para sis-temas ubıquos. Abordaremos tambem alguns problemas queainda se encontram em aberto, chegando as conclusoes so-bre o que ja ha de solido, e o que deve ainda desafiar ospesquisadores da area.

2. VISÃO GERAL DA COMPUTAÇÃO UBÍQUAO termo ”computacao ubıqua” geralmente designa o acessoa determinados recursos computacionais nas mais diversassituacoes, indepentementemente da localizacao, do tempo edo dispositivo que esteja sendo usado. Essa ideia ganhoubastante forca atraves das ideias de Mark Weiser para acomputacao do seculo XXI. Em sua analise [4], foi desta-cado que as tecnologias mais profundas sao aquelas que seintegram a vida cotidiana ate se tornarem indistinguıveis damesma. Tal conceito esta intimamente ligado ao objetivo dacomputacao pervasiva, de embutir poder computacional emobjetos triviais do cotidiano, tornando tao natural quantopossıvel a presenca da informatica nos ambientes, sendo no-tada unicamente nos momentos de sua utilizacao.

Neste contexto, uma das condicoes essencias para que estecenario seja possıvel e a adaptabilidade dos sistemas aosmais variados dispositivos e condicoes computacionais. Esteimportante requisito traz consigo varias outras necessidades,

muitas das quais sao bastante conhecidas em areas comosistemas distribuıdos e aquelas que lidam com dispositivosmoveis. Dentre esses desafios estao: escalabilidade, hetero-geneidade, integracao, seguranca e severas restricoes de re-cursos. Ainda com relacao a adaptabilidade, podemos citara necessidade de atribuir aos softwares a capacidade de con-sciencia e gerencia de contexto.

Alem das preocupacoes supracitadas, o projeto de um sis-tema ubıquo nao pode abrir mao da qualidade do software,tanto em termos de manutenibilidade e adaptabilidade, quantode um elevado nıvel de atencao dispensado a usabilidade domesmo, ja que a interface do sistema com o usuario devefacilitar a incorporacao da aplicacao ubıqua ao cotidiano.

Vemos que nao se trata de um conjunto simples de proble-mas a serem solucionados, para atingir a ubiquididade nonıvel idealizado por varias pessoas. E preciso “esconder”essa complexidade para os desenvolvedores, utilizando ca-madas de abstracao, que simplifiquem e resolvam eficiente-mente parte destas tarefas, diminuindo consequentemente otempo de desenvolvimento da mesma e a probabilidade dealto acoplamento entre partes componentes do sistema.

A seguir, sao apresentados alguns dos modelos propostos naliteratura para a construcao de sistemas ubıquos, capazes deatender as demandas discutidas nesta secao.

3. MODELOS EXISTENTES PARA APLICAÇÕESUBÍQUAS

Banavar[1] propoe um modelo focado numa mudanca deparadigma, quanto a forma de percepcao do que e e de quaissao os bojetivos de um sistema computacional. Esta refor-mulacao de conceitos pode ser resumida em 3 ideias princi-pais:

• Um dispositivo e um portal, num espaco de dados eaplicacao. Nao pode ser tratado como um repositoriode software customizado.

• Uma aplicacao e um meio pelo qual o usuario realizauma tarefa. Explorar todas as capacidades do hard-ware nao deve ser prioridade.

• O ambiente computacional e o proprio espaco fısico,otimizado pelas informacoes. O sistema deve ter o am-biente real como fonte e objeto de informacao.

Uma caracterıstica importante dessa abordagem, e a divisaode ciclo de vida da aplicacao em 3 fases, cada uma com suaspeculiaridades:

• Tempo de projeto: As atividades aqui sao voltadaspricipalmente para o modelo de programacao e a metodolo-gia de desenvolvimento a ser adotados.

• Tempo de carga: Aqui sao tratadas as especifici-dades da descoberta dinamica, assim como da negoci-acao de capacidades e requisitos. Selecao, adaptacaoe composicao da apresentacao tambem sao atividadesposıveis de serem realizadas nesta fase.

• Tempo de execucao: Neste ponto e tratado o mon-itoramento e redistribuicao de tarefas, a possibilidadede operacao desconectada e a seteccao e recuperacaode falhas.

Seguindo essa abordagem, outros trabalhos [2] vem indi-cando que as tarefas de tempo de projeto seriam facilitadaspelo uso de APIs e frameworks adequados, enquanto muitasdas tarefas de tempo de carga e de execucao seriam tratadasatraves de recursos de um middleware, que deveria estarpresente nos dispositivos utilizados. Podemos compreendermelhor essa separacao de responsabilidades ao citar uma ex-emplo de resolucao do desafio das interfaces com o usuario.

Para este problema, uma parte da solucao, que correspondeao tempo de projeto, envolve a escolha e utilizacao de APIsque suportem o desenvolvimento de interfaces abstratas. Es-tas APIs tambem devem permitir uma visao de neutralidadequanto ao dispositivo-alvo do sistema desenvolvido. Quantoa parte resolvida em tempo de carga por um middleware,esta a selecao dinamica de interfaces, que dependera das in-formacoes que o mesmo possui sobre suas capacidades e asdo dispositivo. Esta selecao dinamica poderia ocorrer tam-bem em tempo de execucao, quando diferentes contextos deexecucao do software seriam refletidos em diferentes formasde interacao. Outra atividade de tempo de execucao, deresponsabilidade do middleware, seria o proprio tratamentoda interacao com o usuario.

Com essas diretrizes, obtem-se um modelo generico para sis-temas ubıquos, que pode ser instanciado de diversas formas,a depender das tecnologias disponıveis, tanto a nıvel de hard-ware quanto de software.

Um cenario real de instanciacao desse modelo, com um soft-ware de agenda de compromissos, seria o seguinte:

• Tempo de projeto: E escolhida a plataforma de desen-volvimento Java, com algumas APIs auxiliares, etc.

• Tempo de carga: No ato da instalacao, o middlewarepresente no dispositivo sera o responsavel pela definicaoda forma de entrada de datas pelo usuario, que podeser atraves de selecao em um calendario grafico, digi-tacao de numeros, ou ate mesmo vocal.

• Tempo de execucao: Supondo que a entrada de datasseja feita, por padrao, de forma vocal, mas a quali-dade do reconhecimento da voz do usuario esta ruim,

Application need One.world serviceSearch Query engineStore data Structured I/OCommunicate Remote eventsLocate DiscoveryFault-protect Check-pointingMove Migration

Table 1: Tabela de servicos do sistema para

One.world

o middleware tem a capacidade de trocar a interfacepara outra, baseada em entrada manual dos dados.

Uma outra proposta de modelo, mais detalhado, e apresen-tada em [3]. Trata-se, de fato, de uma arquitetura para aconstrucao de aplicacoes pervasivas. Chamada “One.world”,ela define servicos basicos do“nucleo”de um sistema ubıquo,que atacariam determinadas necessidades fundamentais. Osprincipais seriam:

• Maquina virtual : JVM tem sido uma opcao comum.

• Tuplas: Armazenamento simplificado.

• Eventos assıncronos: notificacao explıcita de uma mu-danca de contexto.

• Ambientes: Containers para cada aplicacao e seus re-spectivos dados.

Alem desses, na arquitetura One.world deve haver algunsservicos do sistema, que farao uso dos servicos basicos, eatenderao a algumas necessidades comuns neste tipo apli-cacao. A tabela 1 indica quais sao esses servicos e que ne-cessidades eles suprem.

4. CONCLUSÕESPor enquanto, podemos afirmar que ha alguns problemas emaberto, tais como a definicao de padroes de engenharia dosoftware mais adequados, ja que o MVC e comumente usadoem dispositivos moveis, mas em geral aumenta tamanho docodigo e nao muda o modelo da aplicacao, limitando a adapt-abilidade. Outro desafio nao completamente solucionado etratamento de interfaces das mais variadas, no sentido maisextremo do termo “wearable computing” ate coisas as diver-sas resolucoes de tela, etc.

5. REFERENCES[1] G. Banavar, J. Beck, E. Gluzberg, J. Munson,

J. Sussman, and D. Zukowski. Challenges: anapplication model for pervasive computing. ACM Press,2000.

[2] C. F. R. G. Cristiano Andre da Costa. Um modelogenerico de infra-estrutura de software para acomputacao ubıqua. In WSPPD’2006 - IV WorkshopPPD/UFRGS, 2006.

[3] R. Grimm. One.world: Experiences with a pervasivecomputing architecture. Pervasive computing, 2004.

[4] M. Weiser. The computer for the 21st century.Scientific American, 265(3):94:104, 1991.