1. Um estudo sobre arquiteturas de software para
computação ubíqua
Rubens de S. Matos Júnior Rogério Nascimento
Departamento de Computação Departamento de Computação
Universidade Federal de Sergipe Universidade Federal de Sergipe
rubens.matos@gmail.com
ABSTRACT muitas das quais s˜o bastante conhecidas em ´reas como
a a
sistemas distribu´ıdos e aquelas que lidam com dispositivos
Texto pendente
m´veis. Dentre esses desafios est˜o: escalabilidade, hetero-
o a
geneidade, integra¸˜o, seguran¸a e severas restri¸˜es de re-
ca c co
Keywords
cursos. Ainda com rela¸˜o ` adaptabilidade, podemos citar
ca a
Computa¸˜o ub´
ca ıqua, computa¸˜o pervasiva
ca
a necessidade de atribuir aos softwares a capacidade de con-
sciˆncia e gerˆncia de contexto.
e e
1. INTRODUÇÃO
A computa¸˜o ub´
ca ıqua ´ uma das ´reas mais promissoras
e a Al´m das preocupa¸˜es supracitadas, o projeto de um sis-
e co
e que tem merecido grande aten¸˜o deste a ultima decada.
ca ´ tema ub´ ıquo n˜o pode abrir m˜o da qualidade do software,
a a
Neste trabalho apresentaremos alguns conceitos de computa¸˜oca tanto em termos de manutenibilidade e adaptabilidade, quanto
ub´ıqua, elucidando quais os desafios principais dos softwares de um elevado n´ de aten¸˜o dispensado ` usabilidade do
ıvel ca a
ub´ıquos. Tamb´m ser˜o mostrados alguns dos modelos exis-
e a mesmo, j´ que a interface do sistema com o usu´rio deve
a a
tentes para o desenvolvimento desse tipo de aplica¸˜o, procu-
ca facilitar a incorpora¸˜o da aplica¸˜o ub´
ca ca ıqua ao cotidiano.
rando chegar ao n´ ıvel de uma arquitetura comum para sis-
temas ub´ ıquos. Abordaremos tamb´m alguns problemas que
e Vemos que n˜o se trata de um conjunto simples de proble-
a
ainda se encontram em aberto, chegando `s conclus˜es so-
a o mas a serem solucionados, para atingir a ubiquididade no
´
bre o que j´ h´ de s´lido, e o que deve ainda desafiar os
aa o n´
ıvel idealizado por v´rias pessoas. E preciso “esconder”
a
pesquisadores da ´rea.
a essa complexidade para os desenvolvedores, utilizando ca-
madas de abstra¸˜o, que simplifiquem e resolvam eficiente-
ca
mente parte destas tarefas, diminuindo consequentemente o
2. VISÃO GERAL DA COMPUTAÇÃO UBÍQUA
tempo de desenvolvimento da mesma e a probabilidade de
O termo ”computa¸˜o ub´
ca ıqua” geralmente designa o acesso
alto acoplamento entre partes componentes do sistema.
a determinados recursos computacionais nas mais diversas
situa¸˜es, indepentementemente da localiza¸˜o, do tempo e
co ca
A seguir, s˜o apresentados alguns dos modelos propostos na
a
do dispositivo que esteja sendo usado. Essa id´ia ganhou
e
literatura para a constru¸˜o de sistemas ub´
ca ıquos, capazes de
bastante for¸a atrav´s das id´ias de Mark Weiser para a
c e e
atender `s demandas discutidas nesta se¸˜o.
a ca
computa¸˜o do s´culo XXI. Em sua an´lise [4], foi desta-
ca e a
cado que as tecnologias mais profundas s˜o aquelas que se
a
integram ` vida cotidiana at´ se tornarem indistingu´
a e ıveis da 3. MODELOS EXISTENTES PARA APLICAÇÕES
mesma. Tal conceito est´ intimamente ligado ao objetivo da
a
UBÍQUAS
computa¸˜o pervasiva, de embutir poder computacional em
ca
Banavar[1] prop˜e um modelo focado numa mudan¸a de
o c
objetos triviais do cotidiano, tornando t˜o natural quanto
a
paradigma, quanto ` forma de percep¸˜o do que ´ e de quais
a ca e
poss´ a presen¸a da inform´tica nos ambientes, sendo no-
ıvel c a
s˜o os bojetivos de um sistema computacional. Esta refor-
a
tada unicamente nos momentos de sua utiliza¸˜o. ca
mula¸˜o de conceitos pode ser resumida em 3 id´ias princi-
ca e
pais:
Neste contexto, uma das condi¸˜es essencias para que este
co
cen´rio seja poss´
a ıvel ´ a adaptabilidade dos sistemas aos
e
mais variados dispositivos e condi¸˜es computacionais. Este
co
• Um dispositivo ´ um portal, num espa¸o de dados e
e c
importante requisito traz consigo v´rias outras necessidades,
a
aplica¸˜o. N˜o pode ser tratado como um reposit´rio
ca a o
de software customizado.
• Uma aplica¸˜o ´ um meio pelo qual o usu´rio realiza
ca e a
uma tarefa. Explorar todas as capacidades do hard-
ware n˜o deve ser prioridade.
a
• O ambiente computacional ´ o pr´prio espa¸o f´
e o c ısico,
otimizado pelas informa¸˜es. O sistema deve ter o am-
co
biente real como fonte e objeto de informa¸˜o.
ca

2. Application need One.world service
Uma caracter´ ıstica importante dessa abordagem, ´ a divis˜o
e a
Search Query engine
de ciclo de vida da aplica¸˜o em 3 fases, cada uma com suas
ca
Store data Structured I/O
peculiaridades:
Communicate Remote events
Locate Discovery
• Tempo de projeto: As atividades aqui s˜o voltadas
a Fault-protect Check-pointing
pricipalmente para o modelo de programa¸˜o e a metodolo-
ca Move Migration
gia de desenvolvimento a ser adotados.
Table 1: Tabela de servi¸os do sistema para
c
• Tempo de carga: Aqui s˜o tratadas as especifici-
a
One.world
dades da descoberta dinˆmica, assim como da negoci-
a
a¸˜o de capacidades e requisitos. Sele¸˜o, adapta¸˜o
ca ca ca
e composi¸˜o da apresenta¸˜o tamb´m s˜o atividades
ca ca e a o middleware tem a capacidade de trocar a interface
pos´ıveis de serem realizadas nesta fase. para outra, baseada em entrada manual dos dados.
• Tempo de execu¸˜o: Neste ponto ´ tratado o mon-
e
ca
itoramento e redistribui¸˜o de tarefas, a possibilidade
ca
Uma outra proposta de modelo, mais detalhado, ´ apresen-
e
de opera¸˜o desconectada e a setec¸˜o e recupera¸˜o
ca ca ca
tada em [3]. Trata-se, de fato, de uma arquitetura para a
de falhas.
constru¸˜o de aplica¸˜es pervasivas. Chamada “One.world”,
ca co
ela define servi¸os b´sicos do “n´ cleo” de um sistema ub´
c a u ıquo,
que atacariam determinadas necessidades fundamentais. Os
Seguindo essa abordagem, outros trabalhos [2] vˆm indi-
e
principais seriam:
cando que as tarefas de tempo de projeto seriam facilitadas
pelo uso de APIs e frameworks adequados, enquanto muitas
das tarefas de tempo de carga e de execu¸˜o seriam tratadas
ca
• M´quina virtual : JVM tem sido uma op¸˜o comum.
a ca
atrav´s de recursos de um middleware, que deveria estar
e
presente nos dispositivos utilizados. Podemos compreender • Tuplas: Armazenamento simplificado.
melhor essa separa¸˜o de responsabilidades ao citar uma ex-
ca
• Eventos ass´
ıncronos: notifica¸˜o expl´
ca ıcita de uma mu-
emplo de resolu¸˜o do desafio das interfaces com o usu´rio.
ca a
dan¸a de contexto.
c
Para este problema, uma parte da solu¸˜o, que corresponde
ca
• Ambientes: Containers para cada aplica¸˜o e seus re-
ca
ao tempo de projeto, envolve a escolha e utiliza¸˜o de APIs
ca
spectivos dados.
que suportem o desenvolvimento de interfaces abstratas. Es-
tas APIs tamb´m devem permitir uma vis˜o de neutralidade
e a
quanto ao dispositivo-alvo do sistema desenvolvido. Quanto Al´m desses, na arquitetura One.world deve haver alguns
e
` parte resolvida em tempo de carga por um middleware,
a servi¸os do sistema, que far˜o uso dos servi¸os b´sicos, e
c a c a
est´ a sele¸˜o dinˆmica de interfaces, que depender´ das in-
a ca a a atender˜o a algumas necessidades comuns neste tipo apli-
a
forma¸˜es que o mesmo possui sobre suas capacidades e as
co ca¸˜o. A tabela 1 indica quais s˜o esses servi¸os e que ne-
ca a c
do dispositivo. Esta sele¸˜o dinˆmica poderia ocorrer tam-
ca a cessidades eles suprem.
b´m em tempo de execu¸˜o, quando diferentes contextos de
e ca
execu¸˜o do software seriam refletidos em diferentes formas
ca
de intera¸˜o. Outra atividade de tempo de execu¸˜o, de
ca ca
responsabilidade do middleware, seria o pr´prio tratamento
o 4. CONCLUSÕES
da intera¸˜o com o usu´rio.
ca a
Por enquanto, podemos afirmar que h´ alguns problemas em
a
aberto, tais como a defini¸˜o de padr˜es de engenharia do
ca o
Com essas diretrizes, obt´m-se um modelo gen´rico para sis-
e e
software mais adequados, j´ que o MVC ´ comumente usado
a e
temas ub´
ıquos, que pode ser instanciado de diversas formas,
em dispositivos m´veis, mas em geral aumenta tamanho do
o
a depender das tecnologias dispon´
ıveis, tanto a n´ de hard-
ıvel
c´digo e n˜o muda o modelo da aplica¸˜o, limitando a adapt-
o a ca
ware quanto de software.
abilidade. Outro desafio n˜o completamente solucionado ´
a e
tratamento de interfaces das mais variadas, no sentido mais
Um cen´rio real de instancia¸˜o desse modelo, com um soft-
a ca
extremo do termo “wearable computing” at´ coisas as diver-
e
ware de agenda de compromissos, seria o seguinte:
sas resolu¸˜es de tela, etc.
co
´ 5. REFERENCES
• Tempo de projeto: E escolhida a plataforma de desen-
volvimento Java, com algumas APIs auxiliares, etc. [1] G. Banavar, J. Beck, E. Gluzberg, J. Munson,
J. Sussman, and D. Zukowski. Challenges: an
• Tempo de carga: No ato da instala¸˜o, o middleware
ca application model for pervasive computing. ACM Press,
presente no dispositivo ser´ o respons´vel pela defini¸˜o
a a ca 2000.
da forma de entrada de datas pelo usu´rio, que pode
a
[2] C. F. R. G. Cristiano Andr´ da Costa. Um modelo
e
ser atrav´s de sele¸˜o em um calend´rio gr´fico, digi-
e ca a a
gen´rico de infra-estrutura de software para a
e
ta¸˜o de n´ meros, ou at´ mesmo vocal.
ca u e
computa¸˜o ub´
ca ıqua. In WSPPD’2006 - IV Workshop
PPD/UFRGS, 2006.
• Tempo de execu¸˜o: Supondo que a entrada de datas
ca
seja feita, por padr˜o, de forma vocal, mas a quali-
a [3] R. Grimm. One.world: Experiences with a pervasive
dade do reconhecimento da voz do usu´rio est´ ruim,
a a computing architecture. Pervasive computing, 2004.

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