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

                 Rubens de S. Mat...
Application need    One.world service
Uma caracter´ ıstica importante dessa abordagem, ´ a divis˜o
                       ...
[4] M. Weiser. The computer for the 21st century.
    Scientific American, 265(3):94:104, 1991.
Próximos SlideShares
Carregando em…5
×

Um Estudo sobre Arquiteturas de Software para Computação Ubíqua

826 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
826
No SlideShare
0
A partir de incorporações
0
Número de incorporações
25
Ações
Compartilhamentos
0
Downloads
37
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Um Estudo sobre Arquiteturas de Software para Computação Ubíqua

  1. 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. 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. 3. [4] M. Weiser. The computer for the 21st century. Scientific American, 265(3):94:104, 1991.

×