• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Artigo TEES -
 

Artigo TEES -

on

  • 1,101 views

 

Statistics

Views

Total Views
1,101
Views on SlideShare
1,101
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Artigo TEES - Artigo TEES - Document Transcript

    • Um Overview de Metodologias para Computação Ubíqua Relacionando com MPS.BR Adolfo Guimarães Kharylim Machado Daniel Barreto Letícia Gindri Rogério Nascimento Departamento de Computação - UFS {adolfopg, kharylimms}@dcomp.ufs.br, {daniel.aspx, tixa1984}@gmail.com, rogerio@ufs.br ABSTRACT Umbiquitous Computing At the beginning of the 80’s, when all attention was turned to personal computers, Mark Weiser visualized a future sce- RESUMO nario for computational applications. This scenario, later Quando no in´ ıcio dos anos 80 todas as aten¸oes estavam c˜ called Ubiquitous Computing, foresaw the computing pre- voltadas aos computadores pessoais, Mark Weiser visualizou sent in the most diverse devices and increasingly impercep- um cen´rio futuro para aplica¸˜es computacionais. Esse ce- a co tible to the end user. Despite being a bit utopic at that time, n´rio, mais tarde chamado de Computa¸ao Ub´ a c˜ ıqua, previu the Ubiquitous Computing is becoming reality in recent ye- a computa¸ao presente nos mais diversos dispositivos e cada c˜ ars. The number of ubiquitous systems is growing and the vez mais impercept´ ıvel ao usu´rio final. Apesar de ser um a need for new development methodologies as well. This pa- o e tanto ut´pico naquela ´poca, a Computa¸ao ub´ c˜ ıqua est´ se a per presents an overview of some methodologies for the ubi- tornando realidade nos ultimos anos. O n´mero dos cha- ´ u quitous applications development, as Banavar’s Model, the mados sistemas ub´ ıquos vem crescendo e a necessidade de Grimm’s Model, the Model-Driven Development applied in novas metodologias de desenvolvimento tamb´m. Este tra- e Ubiquitous Systems and the POCAp. Banavar’s Model is balho apresenta uma vis˜o geral de algumas metodologias a a more general model and considers a paradigm change of para o desenvolvimento de aplica¸oes ub´ c˜ ıquas, sendo elas the applications’ space for construction of ubiquitous sys- o Modelo de Banavar, o Modelo de Grimm, o Desenvolvi- tems. The Grimm’s Model is a more specific model and mento Dirigido a Modelos aplicado em Sistemas Ub´ ıquos e considers an architecture that provide common services in o POCAp. O Modelo de Banavar ´ um modelo mais geral e pervasive applications. The Model-Driven Development ap- e prop˜e uma mudan¸a de paradigma do espa¸o de apli- o c c plied in Ubiquitous Systems considers a methodology that ca¸oes para constru¸ao de sistemas ub´ c˜ c˜ ıquos. O Modelo de makes use of the MDD to get efficiency in the ubiquitous Grimm ´ um modelo mais espec´ e ıfico e prop˜e uma arqui- o software development. The POCAp is a process created in tetura que provˆ servi¸os comuns em aplica¸oes pervasivas. e c c˜ the USP university and presents a methodology for ubiqui- O Desenvolvimento Dirigido a Modelos aplicado em Siste- tous systems that make use of context information. The mas Ub´ ıquos prop˜e uma metodologia que faz uso do MDD o presented approach uses ontologies to represent these infor- para obter eficiˆncia no desenvolvimento de software ub´ e ı- mation. After that it presents a suggestion of how to apply quo. O POCAp ´ um processo criado na universidade da e the MPS.BR to POCAp in order to obtain a better control USP e apresenta uma metodologia para sistemas ub´ ıquos in the development process quality. que fazem uso de informa¸oes do contexto. A abordagem c˜ apresentada faz uso de ontologias para representar estas in- Categories and Subject Descriptors forma¸oes. Em seguida ´ apresentada uma sugest˜o de como c˜ e a H.4 [Information Systems Applications]: Miscellane- aplicar o MPS.BR ao POCAp afim de obter uma melhor ous; D.2.8 [Software Engineering]: Metrics—complexity controle na qualidade do processo de desenvolvimento. measures, performance measures 1. INTRODUÇÃO General Terms O conceito de Computa¸ao Ub´ c˜ ıqua surgiu em um artigo do Keywords cientista-chefe do Centro de Pesquisa Xerox PARC, Mark Weiser. Neste artigo, intitulado The Computer for the 21st Century, Weiser previu que ocorreria um aumento nas funci- onalidades e na disponibilidade dos servi¸os de computa¸ao c c˜ para os usu´rios finais e que a visibilidade destes servi¸os a c seria a menor poss´ıvel [10]. Numa ´poca em que os usu´- e a rios dispunham apenas de computadores de mesa e grande parte da aten¸˜o e do conhecimento estava na opera¸ao do ca c˜ computador em si, Weiser visualizou que futuramente o foco dos usu´rios estaria voltado para a tarefa, e n˜o mais para a a a ferramenta utilizada, usufruindo da computa¸ao sem per- c˜
    • ceber e sem necessitar de conhecimentos t´cnicos. Hoje, e do processo de desenvolvimento de software - como solu¸˜o ca pode-se dizer que ap´s uma transi¸ao pelo per´ o c˜ ıodo da In- juntamente com as metodologias apresentadas. ternet e da Computa¸ao Distribu´ c˜ ıda, entramos na Era da Computa¸ao Ub´ c˜ ıqua, onde existem diversos computadores A seguir, na se¸˜o 2 ser˜o apresentadas modelos e meto- ca a compartilhando cada um de n´s [6]. o dologias que podem ser usadas para o desenvolvimento de sistemas ub´ ıquos. Nesta mesma se¸ao ser´ dada uma vis˜o c˜ a a Pode-se definir a Computa¸ao Ub´ c˜ ıqua como a integra¸ao c˜ geral do MPS.BR, apresentando seus n´ ıveis, processos e atri- entre a mobilidade dos sistemas e a presen¸a distribu´ de c ıda butos. Nas se¸ao 3 ser´ mostrado como podemos aplicar o c˜ a maneira impercept´ıvel e inteligente, contando com grande MPS.BR em uma das metodologias anteriormente apresen- integra¸ao dos computadores e das suas aplica¸oes e promo- c˜ c˜ tadas. E por fim as se¸oes 4 e 5 apresentam as conclus˜es c˜ o vendo maior comodidade ao usu´rio. a do trabalho e as referˆncias, respectivamente. e Tendo em mente o cen´rio em que a Computa¸ao Ub´ a c˜ ıqua 2. CONCEITOS E TECNOLOGIAS est´ inserida, pode-se visualizar um importante problema a A seguir, ser˜o expostos modelos, metodologias e um pro- a para os desenvolvedores de aplica¸oes para esse meio: com c˜ grama de melhoria de software que podem ser utilizados um grande n´mero e variedade de dispositivos m´veis exis- u o no desenvolvimento de aplica¸oes utilizadas em dispositivos c˜ tentes, a implementa¸˜o torna-se complicada, uma vez que ca ub´ ıquos. cada um desses dispositivos possui limita¸oes quanto a inter- c˜ ` face e ao hardware. Devido a isso, ressalta-se a importˆncia a da escolha da metodologia de desenvolvimento de software 2.1 Modelo de Banavar para aplica¸oes ub´ c˜ ıquas a ser utilizada. Assim, neste artigo, ´ E proposto por [2] um modelo baseado em uma mudan¸a c ser˜o abordados alguns modelos e metodologias que podem a de paradigma, desafiando a comunidade a adotar uma nova ser utilizados na implementa¸ao de aplica¸oes ub´ c˜ c˜ ıquas, mas vis˜o de dispositivos, aplica¸oes e ambientes. Esta refor- a c˜ que ainda n˜o s˜o totalmente vi´veis. a a a mula¸˜o de conceitos pode ser resumida em 3 id´ias princi- ca e pais: (i) Um dispositivo ´ um portal, num espa¸o de apli- e c ca¸ao/dados, e n˜o um reposit´rio de software customizado c˜ a o 1.1 Trabalhos Relacionados gerenciado pelo usu´rio, (ii) Uma aplica¸ao ´ um meio pelo a c˜ e Na UFPE, foi implementado um framework que proporciona qual o usu´rio realiza uma tarefa, e n˜o um trecho de c´digo a a o o desenvolvimento de artefatos ub´ıquos educacionais. Esse escrito para explorar as capacidades do dispositivo e (iii) O framework utiliza as t´cnicas de Etnografia R´pida e Cen´- e a a e c c˜ ambiente computacional ´ uma espa¸o de informa¸ao, es- rios e tem como embasamento te´rico a Teoria da Atividade. o tendido para o usu´rio. E n˜o um espa¸o virtual que existe a a c para armazenar e rodar softwares. Segundo [4], a primeira t´cnica citada prop˜e uma observa- e o c˜o mais direcionada e estreita para reduzir o tempo gasto ¸a Para que seja poss´ ıvel modelar essas aplica¸oes, [2] diz que c˜ no processo. Assim, o desenvolvedor deve acompanhar o ´ necess´rio que o ciclo de vida de uma aplica¸ao deve ser e a c˜ usu´rio em suas atividades no trabalho para, ent˜o, poder a a dividida em trˆs partes: (i) Tempo de projeto (design-time): e levantar os requisitos necess´rios para a implementa¸ao [8]. a c˜ ´ E quando o desenvolvedor cria, mant´m e aprimora a apli- e A segunda baseia-se na cria¸ao de quatro cen´rios (1 atual, c˜ a ca¸ao, (ii) Tempo de carga (load-time): O sistema comp˜e, c˜ o 1 futuro e 2 futuros caricaturados - um positivo e outro ne- adapta e carrega os componentes em uma instˆncia da apli- a gativo) com a utiliza¸ao dos esquemas obtidos dos conceitos c˜ ca¸ao em um dispositivo de hardware em particular e (iii) c˜ da Teoria da Atividade. Quanto a Teoria da Atividade, essa ` Tempo de execu¸ao (run-time): Quando o usu´rio final in- c˜ a permite a estrutura¸ao dos dados brutos obtidos na fase de c˜ voca a aplica¸˜o e utiliza suas funcionalidades. O sistema ca etnografia r´pida e a modela¸ao dos mesmos de acordo com a c˜ provˆ um ambiente onde a aplica¸ao possa rodar e adapta a e c˜ o Triˆngulo de Engestr¨m. a o aplica¸ao a varia¸oes neste ambiente. c˜ c˜ Como estudo de caso deste artigo da UFPE, foram coleta- dos dados em uma sala de 2a s´rie do Ensino Fundamental e 2.1.1 Tempo de projeto (design-time) em Recife. A partir destes, foi idealizado o “Livro Vivo” que Nesta fase do ciclo de vida, ´ importante que o desenvol- e ´ composto por um projetor, munido de gravador e auto- e vedor esteja completamente ciente da reformula¸ao de con- c˜ falante e um conjunto de livros associados. A integra¸˜o ca ceitos proposta no modelo de Banavar: Se o “dispositivo ´ e desses dispositivos seria feita atrav´s da tecnologia Blueto- e um portal”, ent˜o a aplica¸ao n˜o deve ser escrita com um a c˜ a oth. O funcionamento do livro seria da seguinte maneira: determinado dispositivo em mente. Assim, n˜o se deve fazer a quando a professora passasse as p´ginas do livro, a imagem a suposi¸oes sobre tamanho de tela ou capacidades de hard- c˜ da p´gina tocada seria mostrada no projetor e o ´udio da a a ware. Por exemplo, o sistema pode vir a executar em um mesma seria reproduzido. dispositivo sem tela, usando um sintetizador de voz e um fone. A interface n˜o deve incluir informa¸oes espec´ a c˜ ıficas Por outro lado, nenhum dos trabalho acima apresentam um sobre um determinado dispositivo, portanto, o front-end da controle no processo de desenvolvimento. Sabe-se que hoje aplica¸ao deve ser dispositivo-neutra. c˜ em dia a metodologia por si s´ n˜o ´ suficiente para a ga- o a e rantia de um bom software. O controle da qualidade do Se estas aplica¸oes s˜o dispositivo-neutras, o desenvolvedor c˜ a processo de desenvolvimento ´ t˜o importante quanto o uso e a n˜o deve iniciar a constru¸ao da aplica¸ao a partir da ca- a c˜ c˜ de uma metodologia apropriada. Com base nisso, este tra- mada de apresenta¸ao, e ent˜o partir para a l´gica. A tarefa c˜ a o balho apresenta o MPS.BR - programa brasileiro apoiado l´gica deve ser principal e n˜o uma decomposi¸ao r´ o a c˜ ıgida da e e pelo Minist´rio da Ciˆncia e Tecnologia que visa a melhoria c˜ intera¸ao. A decomposi¸ao da intera¸ao deve ser dirigida c˜ c˜
    • pela estrutura e defini¸ao das tarefas, assim sendo, a apli- c˜ c˜ ca¸ao deve capturar o prop´sito da intera¸ao com o usu´rio o c˜ a Tabela 1: Principais necessidades de um sistema ub´ ıquo em um alto n´ıvel. Necessidade Servi¸o One.World c Busca Motor de busca Se um ambiente de uma aplica¸ao ´ definida como sens´ c˜ e ıvel Aramazenamento de Dados I/O Estruturado ao contexto, ent˜o n˜o se deve assumir que um determinado a a Comunica¸˜o ca Eventos remotos servi¸o est´ dispon´ c a ıvel. De mesmo modo, podem vir a existir Localiza¸ao c˜ Descoberta c servi¸os dispon´ a a ıveis que n˜o s˜o conhecidos pelo desenvolve- Prote¸ao a falhas c˜ Check-pointing dor no design-time, mas que podem ser uteis para a tarefa. ´ Mobilidade Migra¸ao c˜ As aplica¸oes devem ser capazes de utilizar tais servi¸os. c˜ c N˜o h´ uma metodologia ideal para o desenvolvimento deste a a ii) tuplas, respons´veis por prover uma forma simplificada a modelo, mas ´ importante que seja qual for a metodologia e de armazenamento; escolhida, que o desenvolvimento da aplica¸ao seja essenci- c˜ almente focado na tarefa do usu´rio, ao inv´s da intera¸ao a e c˜ iii) eventos ass´ıncronos, capazes de fornecer a notifica¸ao c˜ do mesmo com a interface. expl´ ıcita de uma mudan¸a de contexto; c iv) e os ambientes, tratando-se de contˆiners para cada apli- a 2.1.2 Tempo de carga (load-time) ca¸ao e seus respectivos dados. c˜ Aplica¸oes e servi¸os “vivem” em um ambiente f´ c˜ c ısico e dis- tribu´ ıdo, portanto, ´ necess´rio um mecanismo para identi- e a ficar e enumerar essas aplica¸oes e servi¸os neste ambiente. c˜ c Para testar a validade do seu modelo, Grimm desenvolveu Os dispositivos devem realizar uma descoberta dinˆmica so- a algumas aplica¸oes junto a sua equipe. A primeira delas, c˜ bre quais recursos est˜o dispon´ a a ıveis, e ent˜o o sistema deve e denominada Chat, foi um sistema de conversa¸ao atrav´s de c˜ adaptar-se e integrar-se a eles. mensagens de texto e ´udio. O Chat era capaz de geren- a ciar mudan¸as de localiza¸˜o os usu´rios, e provou que as c ca a No tempo de carga tamb´m ´ necess´rio que dispositivos e e a tuplas eram estruturas suficientemente poderosas para ar- negociem requisitos e capacidades para rodar os servi¸os que c mazenar dados complexos como sons. Outra aplica¸ao que c˜ disp˜em. Ou seja, a aplica¸ao deve balancear capacidades o c˜ vale a pena mencionar, ´ o projeto Labscape, onde foi criado e e requisitos atrav´s de algum algoritmo de media¸ao para e c˜ um assistente digital que transmitia dados para o dispositivo negociar um ponto que satisfa¸a estas duas propriedades que c mais pr´ximo de um pesquisador em um laborat´rio de bi- o o competem entre si. ologia. Por fim, o sistema deve suportar a sele¸ao dinˆmica de uma c˜ a 2.3 O Processo POCAp interface apropriada para a aplica¸ao, a partir de um con- c˜ Desenvolver aplica¸oes ub´ c˜ ıquas inclui, entre outros, quatro junto de interfaces, baseada nos recursos do dispositivo. temas de pesquisas principais: interfaces naturais, captura e acesso automatizados de atividades humanas, computa- cao sens´ ¸˜ ıvel ao contexto e computa¸˜o no cotidiano. As ca 2.1.3 Tempo de execução (run-time) interfaces naturais tem como foco estudar novas forma de A aplica¸ao em tempo de execu¸ao deve sempre monitorar os c˜ c˜ intera¸ao usu´rio-sistema de forma a facilitar a capacidade c˜ a recursos do portal (dispositivo), e ambientes h´spedes que o de comunica¸ao usando formas naturais como a voz, por c˜ participam da execu¸ao da aplica¸ao. Assim, o run-time c˜ c˜ exemplo. A captura de acesso automatizado de atividades deve conduzir uma mudan¸a de contexto quando ocorrer c refere-se ao uso autom´tico das informa¸˜es do cotidiano. A a co uma mudan¸a de ambiente, durante uma tarefa, e manipular c computa¸ao sens´ ao contexto usa informa¸oes que est˜o c˜ ıvel c˜ a erros n˜o esperados, queda em servi¸os ou problemas no a c presentes ao redor do usu´rio para fornecer servi¸os basea- a c pr´prio portal. o dos nestas. E por fim, a computa¸ao no cotidiano fornecem c˜ suporte computacional cont´ ınuo - 24h por dia, 7 dias por 2.2 Modelo de Grimm (one.world) semana. O trabalho que ser´ descrito a seguir leva em con- a [7] apresenta outra proposta de modelo mais espec´ ıfica. Trata- sidera¸ao apenas o segundo tema, as aplica¸oes sens´ c˜ c˜ ıveis ao se, de fato, de uma arquitetura (framework) para a constru- contexto. c˜o de aplica¸oes pervasivas. Denominada “One.world”, ela ¸a c˜ define servi¸os que simplificam necessidades fundamentais c O POCAp (Process for Ontological Context-aware Applica- de um sistema ub´ ıquo. tions) foi um processo desenvolvido na USP e leva em con- sidera¸ao sistemas que seguem o terceiro tema acima apre- c˜ As principais necessidades seriam: sentado: computa¸ao sens´ ao contexto. Como represeta- c˜ ıvel cao das informa¸oes de contexto foi usado ontologias para a ¸˜ c˜ Para implementar estes servi¸os e conseq¨entemente suprir c u formaliza¸ao destas. Ambas abordagens ser˜o explicadas a c˜ a as necessidades de aplica¸˜es ub´ co ıquas, o modelo de Grimm seguir. define 4 fundamentos principais. Os fundamentos principais do One.world s˜o: a Segundo [5] informa¸ao sens´ ao contexto ´ qualquer infor- c˜ ıvel e ma¸˜o que possa ser utilizada para caracterizar um entidade. ca Um entidade ´ uma pessoa, lugar ou objeto considerado rele- e i) uma m´quina virtual, para lidar com a heterogeneidade a vante para uma intera¸ao entre um usu´rio e uma aplica¸˜o, c˜ a ca de dispositivos e sistemas operacionais; incluindo o usu´rio e a aplica¸ao em quest˜o. Levando essa a c˜ a
    • Figura 1: Diagrama geral do POCAp defini¸ao para um aspecto mais pr´tico, imagine um sistema c˜ a de localiza¸ao baseado em GPS. A primeira informa¸ao de c˜ c˜ contexto que o sistema faria uso seria a posi¸ao do usu´rio. c˜ a Baseado nessa, outras informa¸oes podem ser obtidas: ou- c˜ tros usu´rios e localiza¸ao de pr´dios, por exemplo. Saber a c˜ e ´ Figura 2: Diagrama da fase ANALISE E ESPECI- representar essas informa¸oes ´ de suma importˆncia para o c˜ e a FICACAO ¸ ˜ do POCAp desenvolvimento de aplica¸oes sens´ c˜ ıveis ao contexto . As ontologias se mostram uma abordagem bem aceit´vel a para essas representa¸ao, uma vez que possuim as caracte- c˜ servi¸os, (ii) projeto de extens˜o de servi¸os e (iii) projeto c a c r´ ısticas de formalidade, portabilidade, abstra¸ao de imple- c˜ de novos servi¸os. Nesta fase o projetista tem a fun¸ao de c c˜ menta¸ao e a possibilidade das aplica¸oes inferirem sobre c˜ c˜ desenvolver uma projeto arquitetural do software baseando- as informa¸˜es de contexto. Isso permite formalizar a re- co se nos requisitos previamente levantados e no modelo on- c˜ c˜ presenta¸ao da diversidade das informa¸oes contextuais e a tol´gico. Trˆs artefatos s˜o produzidos nesta fase: (i) do- o e consequentemente a copera¸ao de dispositivos heterogˆneos c˜ e cumento de descri¸ao de reuso de servi¸os, (ii) documento c˜ c [5]. de descri¸ao de extens˜o de servi¸os e (iii) documento de c˜ a c descri¸˜o de novos servi¸os. O primeiro documento define ca c O POCAp apresenta em detalhes as 4 principais fases do quais servi¸os podem ser reutilizados baseando-se nos re- c desenvolvimento de software, s˜o elas: (i) an´lise e especi- a a quisitos funcionais, n˜o-funcionais e no modelo ontol´gico. a o fica¸ao, (ii) projeto, (iii) desenvolvimento e (iv) verifica¸ao c˜ c˜ O segundo usa o primeiro e especifica quais destes servi¸os c e valida¸ao. Para cada uma destas s˜o apresentadas pap´is c˜ a e podem ser estendidos. O terceiro especifica novos servi¸os, c e a dinˆmica de trabalho. A figura 1 mostra a dinˆmica a a caso os j´ especificados anteriormente n˜o s˜o suficientes a a a entre as fases e o relacionamento com cada papel definido. para atender todas as necessidades do sistema. Todos esses Os pap´is definidos est˜o relacionados com cada uma das e a artefados s˜o usados como entrada para a pr´xima fase, a a o fases descritas, s˜o eles: analista, projetista, desenvolvedor a de desenvolvimento. e validador. Na fase de desenvolvimento, o desenvolvedor deve basear- Na Figura 2 ´ demonstrado a fase de an´lise e especifica- e a se no modelo ontol´gico da applica¸ao para escolher todo o c˜ c˜o. Essa fase ´ subdividida em quatro outras: (i) an´lise e ¸a e a suporte computacional que deve ser usado para processar especifica¸˜o de requisitos, (ii) an´lise e especifica¸ao de in- ca a c˜ a linguagem de ontologia usada. Com os artefatos gerados forma¸ao contextual, (iii) an´lise e especifica¸ao de re´so do c˜ a c˜ u pela fase de projeto, o desenvolvedor deve decidir quais fer- modelo e (iv) an´lise e especifica¸ao de extens˜o do modelo. a c˜ a ramentas computacionais s˜o suficientes para atender suas a Os principais artefatos produzidos nesta fase s˜o: o docu- a necessidades de projeto de cada servi¸o a ser reusado, es- c mento de requisitos e o documento de modelo ontol´gico da o tendido e implementado. Importante lembrar, como afirma aplica¸ao. O documento de requisitos, gerado atrav´s da c˜ e [X], que o processo POCAp ´ neutro com respeito a tecnolo- e ` primeira subfase, ´ uma descri¸ao - na forma de requisitos e c˜ gia utilizada para o desenvolvimento deste tipo de aplica¸ao. c˜ funcionais e n˜o funcionais - dos requisitos dos usu´rios e a a Caracter´ ıstica essa essencial no desevolvimento de aplica¸oes c˜ da aplica¸ao. Este documento tanto ser´ utilizado nas de- c˜ a ub´ıquas. mais subfases como tamb´m ´ entrada para a pr´xima fase. e e o Baseando-se neste documento e juntamente com um levanta- Na fase de verifica¸ao e valida¸ao, o validador deve fazer uso c˜ c˜ mento das informa¸oes de contexto ´ gerado o segundo arte- c˜ e dos seguintes artefatos de entrada: (i) documento de requi- fato principal: o documento de modelo ontol´gico. Este do- o sitos, (ii) documento de re´so do modelo, (iii) documento u cumento deve ser formulado juntamente com um engenheiro de modelo ontol´gico da aplica¸ao e (iv) a imaplementa¸ao o c˜ c˜ de ontologias e descreve de maneira formal o que pode ser´ a da aplica¸ao em si. Tanto os requisitos funcionais quanto os c˜ considerado informa¸ao de contexto para esta aplica¸ao. c˜ c˜ n˜o-funcionais devem ser devidamente testados neste tipo de a aplica¸ao. Segundo [5], os requisitos funcionais precisam ser c˜ e e Na Figura 3 ´ apresentada a fase de Projeto. Tamb´m sub- c˜ testados para analisar se a aplica¸ao atende as especifica¸oes c˜ ` dividida, mas desta vez em 3 fases: (i) projeto de reuso de determinadas. J´ em rela¸ao aos n˜o-funcionais, principal- a c˜ a
    • Figura 4: Principais conceitos das dimens˜es o ver a necessidade da troca de um dispositivo por outro mais moderno. Em rela¸ao ao desenvolvimento dos sistemas, deve-se consi- c˜ derar (i) como desenvolver um software para sistemas ub´ ı- quos que por tr´s do fluxo tradicional de funcionalidades e a informa¸oes, permita uma espec´ c˜ ıfica intera¸ao objeto-objeto c˜ para obter funcinalidades adicionais, permitindo, entre ou- tras, o aumento da eficiˆncia e da robustez do sistema, (ii) e Figura 3: Diagrama da fase PROJETO do POCAp como a prover a manuten¸ao e a evolu¸ao dos sistemas de c˜ c˜ informa¸ao de maneira que permita a inclus˜o de novos re- c˜ a quisitos, funcionalidades ou tecnologias, e (iii) o qu˜o baixo a mente a interoperabilidade e aramazenamento. Outro ques- deve ser o n´ de abstra¸ao em que o solftware ser´ desen- ıvel c˜ a t˜o importante a ser analisada ´ a inferˆncia dos modelos a e e volvido. ontol´gicos, o tempo de resposta das maquinas de inferˆn- o e cias utilizadas podem atrapalhar um bom desempenho do O Model-Driven Development (MDD), em portuguˆs ‘De- e sistema. senvolvimento Orientado a Modelos’, centrando o desenvol- vimento nos modelos e na automatiza¸˜o da transforma¸ao ca c˜ Com fases e atividades bem definidas, o POCAp prop˜e um o dos modelos e gera¸ao do c´digo final oferece um meio de a c˜ o arquitetura real para o desenvolvimento de aplica¸oes ub´ c˜ ı- judar os desenvolvedores de softaware ub´ıquo a lidar com a quas. O uso de ontologias auxilia na formaliza¸ao de infor- c˜ complexidade inerente a esses softwares. Oferece benef´ ıcios ma¸oes e principalmente, na intera¸˜o destas informa¸oes c˜ ca c˜ em potencial que podem ser utilizados para a concep¸ao e c˜ como os mais diversos tipos de dispositivos. No entando, evolu¸ao dos sistemas de informa¸˜o ub´ c˜ ca ıquos. o processo de desenvolvimento estudado n˜o se baseia em a nenhuma abordagem para o controle da qualidade deste. Apesar disso, o uso dos conceitos do MDD s˜o importantes, a Mais a frente, esta metodologia ser´ relacionada com um a ´ mas ainda n˜o s˜o suficientes. E necess´ria uma abordagem a a a abordagem de melhoria do processo de desenvolvimento de que enquanto adota t´cnicas, ferramentas e conceitos mo- e software, o MPS.BR. dernos e apropriados, estabele¸a uma estrat´gia de desen- c e volvimento adequada para o desenvolvimento dos softwares ub´ ıquos. 2.4 Model-Driven Development Esta metodologia, desenvolvida como trabalho de doutorado Como metodologia, o autor apresenta trˆs dimens˜es de de- e o na Universidade do Minho, Portugal, busca contribuir para a senvolvimento e uma abordagem do MDD para o desenvolvi- eficiˆncia e efic´cia do desenvolvimento de software, servi¸os e a c mento de sistemas ub´ ıquos. A figura 4 descreve rapidamente e aplica¸oes suportadas por esse tipo de sistema. c˜ cada uma dessas dimens˜es. o Segundo [1], quando se pretende desenvolver software para sistemas ub´ıquos, algumas carater´ ısticas relevantes desses 2.4.1 Dimensão de classe sistemas devem ser levadas em conta, como o elevado n´- u Os dispositivos podem ser agrupados em classes, de acordo mero de dispositivos, as constantes inova¸oes tecnol´gicas, a c˜ o com caracter´ ısticas, recursos e capacidades comuns desses heterogeneidade dos dispositivos e a potencial complexidade dispositivos (veja Figura 5). Esta perspectiva de agrupa- das intera¸oes entre os dispositivos. c˜ mento dos dispositivos por propriedades comuns constitui a Dimens˜o de Classe. Se necess´rio, essas classes podem ser a a A concep¸ao e a constante evolu¸ao do software para siste- c˜ c˜ classificadas em subclasses de dispositivos. Ent˜o, pode-se a mas ub´ ıquos requer abordagens adequadas que considerem afirmar que os dispositivos pertencentes a uma determinada as exigˆncias e as caracter´ e ısticas particulares desses siste- classe (ou subclasse) possuem caracter´ ısticas e capacidades mas. Com base nisso surgem algumas considera¸oes que c˜ espec´ıficas, permitindo que a eles sejam delegadas funciona- podem ser levadas em conta na escolha do Model-Driven De- lidades espec´ıficas. velopment para o desenvolvimento de sistemas ub´ ıquos. Em rela¸ao as funcionalidades, deve-se considerar que (i) novos c˜ ` 2.4.2 Dimensão de função dispositivos podem ser integrados ao sistema, (ii) uma nova A classifica¸ao dos dispositivos em classes possui apenas uma c˜ fun¸ao pode ser adicionada a um dispositivo e (iii) pode ha- c˜ dimens˜o relativa ao desenvolvimento de um sistema ub´ a ı-
    • Figura 6: Estruturas de desenvolvimento para os Perfis Funcionais de Classes transforma¸oes e da gera¸ao de c´digo, a fim de chegar ao c˜ c˜ o software que re´ne as funcionalidades correspondentes ao u Figura 5: Classes e SubClasses de dispositivos, ba- respectivo perfil funcional. seada em [6] Sobre a utiliza¸ao do MDD, destacam-se duas fases: (i) O c˜ quo. Considerando que a mesma classe de dispositivos pode Plataform Independent Model (PIM), ou em portuguˆs “Mo- e executar diferentes fun¸˜es ou diferentes conjuntos de funci- co delo Independente de Plataforma”, enfoca a opera¸˜o de um ca onalidades, pode ent˜o ser concebida uma outra dimens˜o: a a sistema escondendo os detalhes da plataforma. Nesse passo a Dimens˜o de Fun¸˜o. Essa dimens˜o agrupa os dispo- a ca a s˜o adicionados os detalhes computacionais ao modelo. O a sitivos pelo conjunto de funcionalidades que as classes (de uso da plataforma ´ descrito com grau de abstra¸ao sufici- e c˜ dispositivos) podem ser respons´veis por realizar. Estes s˜o a a ente para que seja poss´ utilizar em diferentes plataformas ıvel conjuntos de funcionalidades s˜o chamados de Perfis Fun- a e (ii) O Plataform Specific Model (PSM), ou em portuguˆs e cionais. Um perfil funcional compreende um conjunto de “Modelo Espec´ ıfico de Plataforma”, combina as especifica- funcionalidades que s˜o esperadas do sistema e que s˜o atri- a a coes do PIM com os detalhes que especificam como o sistema ¸˜ ´ interage com a plataforma. E aplicada uma transforma¸ao c˜ bu´ıdas a uma determinada classe de dispositivos. ao PIM para que seja gerado o PSM, para isso, uma ou mais Para um melhor entendimento, pode ser citado o exemplo de plataformas s˜o escolhidas e um mapeamento para estas pla- a um ambiente m´dico utilizando PDAs. O sistema permite e taformas ´ constru´ e ıdo. O PSM pode ser usado para gerar o o controle da fila de espera de um hospital ao permitir que c´digo do sistema ou ser refinado em outro PSM. o a agenda de atendimentos seja transferida da base de dados para os dispositivos m´veis. Quando um paciente chega ao o Para cada uma das estruturas desenvolvimento, o trabalho e a hospital, ´ recebido por um funcion´rio que porta um PDA; e ´ realizado em trˆs n´ ıvel e ıveis, partindo de um alto n´ de abs- o hor´rio de chegada do paciente ´ registrado e seus dados a e c˜ e ıvel c˜ tra¸ao, o modelo, at´ um baixo n´ de abstra¸ao, o c´digo, o s˜o conferidos, podendo ser feitas pequenas altera¸oes ou a c˜ como pode ser visto na Figura 7. Esses n´ ıveis podem ser o cadastramento como novo paciente. O paciente ´ enca- e descritos como: (i) Alto N´ ıvel - neste n´ ıvel, o PIM para minhado para o m´dico, que realiza o atendimento, insere e cada classe de dispositivos deriva de modelos resultantes do dados referentes a consulta, doen¸a, medica¸ao e no mo- ` c c˜ desenvolvimento inicial do sistema, onde todos os dispositi- mento em que a consulta ´ finalizada, informa ao sistema a e vos computacionais s˜o integrados; (ii) N´ Intermedi´rio - a ıvel a conclus˜o, sendo lan¸ada automaticamente na tela do PDA a c neste n´ıvel, coexistem modelos PIM e PSM que tanto podem a informa¸ao do pr´ximo paciente a ser atendido [3]. c˜ o ser associados com subclasses de dispositivos, quanto podem projetar decis˜es refletindo escolhas espec´ o ıficas e respeitando Ent˜o, neste caso, a Classe de dispositivos tomada como a a plataforma (arquitetura, tecnologia, etc) e que de alguma base para a Dimens˜o de Fun¸ao ´ a Classe A (da Figura a c˜ e maneira introduz certo grau de dependˆncia. Dependendo e 5). Uma parte desses PDAs foi destinada para uso dos fun- do ponto de vista, um modelo intermedi´rio pode ser visto a cion´rios da recep¸ao, enquanto a outra parte foi destinada a c˜ como um PIM ou um PSM; se o modelo for visto a partir para ser utilizada pela equipe m´dica. Como esses PDAs e de um n´ de abstra¸ao maior pode ser considerado como ıvel c˜ prestam diferentes servi¸os para os m´dicos e os funcion´- c e a PSM se, ou pode ser considerado como um PIM se for obser- rio da recep¸ao, pode-se identificar que nesse caso ter-se-´ c˜ a vado a partir de um n´ de abstra¸ao inferior e (iii) Baixo ıvel c˜ pelo menos dois perfis funcionais atribu´ıdos ao conjunto de N´ıvel - nesse n´ ıvel encontram-se os ultimos PSMs, a partir ´ ´ dos quais o c´digo final ser´ produzido. E importante desta- o a PDAs. Logo, pode-se visualizar que uma classe de disposi- tivos pode englobar diversos perfis funcionais (veja a Figura car que a partir de um unico PSM ´ poss´ derivar dois, ou ´ e ıvel 6), a depender do sistema. mais, diferentes c´digos, devido a diferen¸as na plataforma o c onde o c´digo ser´ gerado. o a 2.4.3 Dimensão de abstração Considerando que, para cada estrutura de desenvolvimento 2.5 MPS.BR existe uma respectiva abstra¸ao top-bottom durante o seu c˜ O aumento da competitividade entre empresas desenvolve- desenvolvimento, pode ser ent˜o concebida outra dimens˜o a a doras de software fez com que elas passassem a se preocupar de desenvolvimento: a Dimens˜o de Abstra¸ao. Na dimen- a c˜ mais com a qualidade dos produtos de software e de servi¸os c s˜o de abstra¸˜o, o desenvolvedor concentra os esfor¸os no a ca c correlatos. Assim, percebe-se que qualidade ´ um fator de e emprego do Model-Driven Develoment (MDD), do modelo sucesso para a ind´stria de software do mesmo modo que u
    • Figura 8: Componentes do MPS.BR definido, (v) E - Parcialmente definido, (vi) F - Gerenciado e (vii) G - Parcialmente gerenciado. Os n´ıveis, como mostrado anteriormente, possuem uma letra Figura 7: Ilustra¸˜o do processo de abstra¸˜o, base- ca ca associada a eles e est˜o sendo mostrados em ordem decres- a ada em [6] cente. Assim, o primeiro n´ que uma empresa pode obter ıvel ´ o G - Parcialmente Gerenciado e o ultimo ´ o A - Em e ´ e otimiza¸ao. Cada um desses n´ c˜ ıveis de maturidade permite ´ para outros setores. Com o intuito de se formar um se- e prever o desempenho futuro da organiza¸ao ao executar um c˜ tor de software competitivo, nacional e internacionalmente, ou mais processos e possui associado a ele perfis e atributos ´ necess´rio que empres´rios do setor destaquem a eficiˆn- e a a e de processos (AP). A figura 5 mostra de maneira mais clara cia e efic´cia de seus processos, visando atender a padr˜es a o os sete n´ıveis com seus processos e atributos de processos internacionais de qualidade. relacionados. O atributos s˜o: (i) AP 1.1 - O processo ´ a e executado, (ii) AP 2.1 - O processo ´ gerenciado, (iii) AP e Buscando seguir esses padr˜es, foi criado o programa bra- o 2.2 - Os produtos de trabalho do processo s˜o gerenciados, a sileiro MPS.BR [9] ou Melhoria de Processo do Software (iv) AP 3.1 - O processo ´ definido, (v) AP 3.2 - O processo e Brasileiro que ´ coordenado pela Associa¸ao para Promo¸ao e c˜ c˜ a e est´ implementado, (vi) AP 4.1 - O processo ´ medido, (vii) da Excelˆncia do Software Brasileiro (SOFTEX), contando e AP 4.2 - O processo ´ controlado, (viii) AP 5.1 - O processo e e e com apoio do Minist´rio da Ciˆncia e Tecnologia (MCT), e c˜ e ´ objeto de inova¸oes e (ix) AP 5.2 - O processo ´ otimizado Financiadora de Estudos e Projetos (FINEP) e Banco Inte- continuamente. ramericano de Desenvolvimento (BID). Os processos e atributos de processos do MPS.BR n˜o ser˜o a a Busca-se adequar o MPS.BR ao perfil de empresas com di- explicados nesse artigo uma vez que o intuito deste ´ mos- e ferentes tamanhos e caracter´ ısticas, embora com um foco trar uma vis˜o geral do programa. Entretanto, na pr´xima a o e maior para as micro, pequenas e m´dias empresas. Tamb´m e c˜ a c˜ se¸ao, ser´ feita uma aplica¸ao do MPS.BR na metodologia ´ esperado que esse programa, utilizando toda a competˆn- e e POCAp e alguns processos ser˜o melhor descritos. a cia existente nos padr˜es e modelos de melhoria de processo o a j´ dispon´ o ıveis, seja compat´ com os padr˜es de qualidade ıvel 3. ESTUDO DE CASO LOCAL aceitos internacionalmente. Dentre as metodologias apresentadas, a POCAp foi selecio- nada para o estudo de caso da aplica¸ao do MPS.BR. Como c˜ O MPS.BR baseia-se nos conceitos de maturidade e capaci- apresentado em [5] uma das sugest˜es de trabalho futuro ´ o e dade de processo para a avalia¸ao e melhoria da qualidade c˜ exatamente a escolha de metodologia que possa auxiliar na e produtividade de produtos de software e servi¸os. Dentro c qualidade do processo de desenvolvimento para computa¸oes c˜ desse contexto, o MPS.BR possui trˆs componentes: Modelo e ub´ ıquas. Este artigo prop˜e o uso da MPS.BR. o de Referˆncia (MR-MPS), M´todo de Avalia¸ao (MA-MPS) e e c˜ e Modelo de Neg´cio (MN-MPS). A figura 4 mostra como o Como foi visto na se¸ao anterior, o MPS.BR apresenta uma c˜ funciona essa divis˜o, as subdivis˜es de cada um dos com- a o s´rie de n´ e ıveis e processos, processos estes que podem ser ponentes anteriores e os padr˜es e normas que o MPS.BR o associados como as fases de desenvolvimento do POCAp. utiliza como referˆncia. e Como foi visto, a figura 9 mostra todos os processos e n´ ıveis Nesse artigo, s´ ser´ abordado um dos componentes do MPS.BR o a do MPS.BR. Alguns deste foram selecionados para mostrar que ´ o Modelo de Referˆncia. Esse cont´m os requisitos que e e e sua reala¸ao com o POCAp, no entando, todas estes proces- c˜ os processos das organiza¸oes devem cumprir para estar em c˜ sos podem ser aplicados no desenvolvimento, os selecionados conformidade com o MR-MPS. Al´m disso, nele s˜o defi- e a foram aqueles julgados mas relevantes para o tipo de apli- nidos sete n´ıveis de maturidade que caracterizam est´gios a ca¸ao. S˜o eles: c˜ a de melhoria da implementa¸ao de processos na organiza¸ao, c˜ c˜ sendo estes: (i) A - Em otimiza¸ao, (ii) B - Gerenciado c˜ N´ıvel E - Gerˆncia de Reutiliza¸˜o: uma das carac- e ca quantitativamente, (iii) C - Definido, (iv) D - Largamente ter´ ısticas do POCAp ´ a reutiliza¸ao de artefados durante e c˜
    • los s´lidos j´ existentes. Com base nisso, pode-se supor que o a essas metodologias j´ nascem com um embasamento con- a sistente, uma vez que apoiam-se em modelos bem sucedi- dos, sendo esta uma vantagem em rela¸ao a metodologias c˜ que tenham sido criadas unicamente para serem aplicadas a ` computa¸˜o ub´ ca ıqua. Contudo, uma metodologia pr´pria para a computa¸ao ub´ o c˜ ı- qua teria a vantagem se ser especifica e de, quem sabe, n˜oa ter processos desnecess´rios para o caso espec´ a ıfico. Deve-se considerar que, como n˜o foi encontrada uma metodologia a puramente criada para a computa¸ao ub´ c˜ ıqua, os modelos nos quais as metodologias atuais se baseiam podem n˜o ser a t˜o adequados ou podem n˜o estar t˜o bem adaptados. a a a 4.2 Trabalhos Futuros Como trabalho futuro, sugere-se a cria¸ao de uma metodo- c˜ logia espec´ ıfica para Computa¸ao Ub´ c˜ ıqua, visto que adap- ta¸oes de outros modelos podem n˜o se encaixar perfeita- c˜ a mente ao dom´ ınio do problema. Como se sabe, a tecnologia est´ sempre em evolu¸ao e novos dispositivos ub´ a c˜ ıquos po- dem vir a ser agregados ao sistema. As metodologias devem levar em conta essa caracter´ıstica, que seguramente ´ mais e um obst´culo para a utiliza¸ao de uma metodologia base- a c˜ ada em modelos existentes. Por outro lado, pode-se apontar como outro trabalho futuro a continuidade da adequa¸˜o das ca metodologias existentes, de modo que solucione problemas como o de separar a implementa¸ao de hardware e software. c˜ Figura 9: Componentes do MPS.BR 5. REFERÊNCIAS o desenvolvimento. Tanto na fase de an´lise quanto na de a [1] Model-driven development for pervasive information projeto, infoma¸oes de contexto e de servi¸os s˜o reutiliza- c˜ c a systems, 2000. das para o desenvolvimento das novas funcionalidades do [2] G. Banavar. Challenges: An application model for sistema. Desta forma uma boa gerˆncia no controle do que e pervasive computing, 2000. Dispon´ em ıvel pode ser reutilizado e como deve ser reutilizado pode ser de http://www.research.ibm.com/PIMA/Documents/Mobicom2000 importante valia para o melhor desenvolvimento do sistema. Acessado em 17 Nov 2008. [3] K. Brito, A. Silveira, and A. C. Garcia. Utiliza¸ao de c˜ N´ ıvel D - Verifica¸˜o e Valida¸˜o: esses dois n´ ca ca ıveis es- e pdas e redes wireless no ambiente m´dico. In III t˜o presentes como uma das fases do POCAp. Um maior a Simp´sio Brasileiro de Qualidade de Software, o controle nesta fase afim de selecionar os m´todos adequa- e Bras´ılia, DF, Brasil, 2004. dos para tal tarefa pode resultar em um melhor controle no [4] T. P. da Rocha Falc˜o and A. S. Gomes. Modelagem a processo. de solu¸oes ub´ c˜ ıquas para uso em salas de aula do ensino fundamental. In GCETE 2004 - Global N´ıvel D - Integra¸˜o do Produto: ter essa garantia den- ca Congress on Engineering and Technology Educatio, tro do processo de desenvolvimento pode ser fundamental no 2004. desenvolvimento de software ub´ ıquos. A grande quantidade [5] R. de Freitas Bulc˜o Neto. Um processo de software e a de tipos de dispositivos, redes e informa¸˜es exige um maior co um modelo ontol´gico para apoio ao desenvolvimento o controle nesse conceito para que garanta a total integra¸ao c˜ de aplica¸˜es sens´ co ıveis a contexto. PhD thesis, entre sistema e servi¸os. c Instituto de Ciˆncias Matem´ticas e de Computa¸ao - e a c˜ ICMC-USP, 2006. 4. CONCLUSÕES E TRABALHOS FUTUROS [6] F. Domingues. Computa¸ao ub´ c˜ ıqua 2008, 2008. Ap´s o estudo das metodologias apresentadas neste artigo, o [7] R. Grimm. One.world: Experiences with a pervasive ´ poss´ e ıvel perceber um razo´vel grau de imaturidade das a computing architecture. Pervasive computing, 2004. mesmas. Tendo em vista que a computa¸ao ub´ c˜ ıqua ainda [8] J. M. Rubio. Knowledge management in the ´ muito recente e que novas metodologias est˜o surgindo, e a ubiquitous software development. In First sem que se tenha havido tempo suficiente para coloc´-las a International Workshop on Knowledge Discovery and em pr´tica a larga escala, ainda ´ cedo para um palpite de a e Data Mining (WKDD 2008), pages 6–9. ACM, 2008. qual metodologia ter´ futuro promissor ou ser´ a mais usada. a a [9] D. Scalet. Mps.br - melhoria de processo do software brasileiro: Guia geral (vers˜o 1.2), 2007. a 4.1 Vantagens e Desvantagens [10] M. Weiser. The computer for the 21st century. Ao longo do artigo ´ poss´ perceber que as metodologias e ıvel Scientific American, 265:94–104, Setembro 1991. para computa¸˜o ub´ ca ıqua apresentadas fazem uso de mode-