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.
E a chuva ... (Livro pedagógico para ser usado na educação infantil e trabal...
Manuscrito Computação Ubíqua
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-