Quando no início dos anos 80 todas as atenções estavam voltadas aos computadores pessoais, Mark Weiser visualizou um cenário futuro para aplicações computacionais onde a computação estaria presente nos mais diversos dispositivos de forma imperceptível ao usuário final. O documento apresenta modelos e metodologias para desenvolvimento de aplicações ubíquas, como o Modelo de Banavar, o Modelo de Grimm e o POCAp, e sugere a aplicação do MPS.BR ao POCAp para melhorar o controle da qualidade do processo de desenvolvimento.

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 - 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˜

2. 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˜

3. 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

4. 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

5. 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 ı-

6. 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

7. 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˜

8. 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-