Your SlideShare is downloading. ×
Um Overview de Metodologias para Computação Ubíqua
               Relacionando com MPS.BR

              Adolfo Guimarães ...
para os usu´rios finais e que a visibilidade destes servi¸os se-
            a                                           c ...
sobre um determinado dispositivo, portanto, o front-end da
aplica¸˜o deve ser dispositivo-neutra.
      ca                ...
Figura 1: Diagrama geral do POCAp




vante para uma intera¸˜o entre um usu´rio e uma aplica¸˜o,
                      ca ...
Figura 4: Principais conceitos das dimens˜es
                                                                             ...
Figura 6: Estruturas de desenvolvimento para os
                                                                 Perfis Fun...
Figura 8: Componentes do MPS.BR


                                                                  gios de melhoria da im...
Ao longo do artigo ´ poss´ perceber que as metodologias
                                                                  ...
Upcoming SlideShare
Loading in...5
×

Artigo Tees

892

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
892
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Artigo Tees"

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

×