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