Um Ambiente de Desenvolvimento de Aplicações Multi-Plataformas e Adaptativas para Dispositivos Móveis

Universidade Federal do Cear
Departamento de Computao
Mestrado em Cincia da Computao
Dissertao de Mestrado
Um Ambiente de Desenvolvimento de Aplicaes MultiPlataformas e Adaptativas para Dispositivos Mveis
Windson Viana de Carvalho
Fortaleza-CE, 2005
Um Ambiente de Desenvolvimento de Aplicaes Multi-Plataformas e

Adaptativas para Dispositivos Mveis
Este exemplar corresponde redao

final
da
Dissertao
devidamente
corrigida e defendida por Windson

Viana de Carvalho e aprovada pela
Banca Examinadora.
Fortaleza, 14 de junho de 2005
Rossana Maria de Castro Andrade

(Orientadora)
Dissertao apresentada ao Mestrado de

Cincia
da
Computao
da
Universidade Federal do Cear (UFC),
como requisito parcial para a obteno
do ttulo de Mestre em Cincia da
Computao
RESUMO
A heterogeneidade dos dispositivos mveis e a integrao com as tecnologias de
comunicao sem fio impem desafios para o desenvolvimento de aplicaes e de servios,
dos quais podemos citar os seguintes: a descrio, independente de dispositivo e
plataforma, da interface com usurio; a adaptao do contedo acessado pelas aplicaes; e
o desenvolvimento de aplicaes multi-plataformas.
Diversos trabalhos foram propostos para solucionar cada um desses desafios.
Contudo, no foi encontrada na literatura nenhuma abordagem satisfatria que permitisse a
um engenheiro de software construir aplicaes multi-plataformas utilizando uma descrio
inicial da interface e dos seus dados, de forma que essa descrio seja independente de um
dispositivo especfico ou de uma plataforma de programao. Ressalta-se, ainda, que
nenhuma soluo facilita a descrio da aplicao e a sua integrao com as arquiteturas de
adaptao de contedo.
Portanto, necessria a criao de um ambiente para integrar e aprimorar essas
solues existentes para os desafios expostos. Esta dissertao prope ento um ambiente
para o desenvolvimento de aplicaes para dispositivos mveis composto pelos frameworks
XFormUI, Requisitor, Mobile Adapter e MobAC e pela ferramenta de gerao de cdigo
User Interface Generator (UIG). Esse ambiente propicia o desenvolvimento rpido de
aplicaes multi-plataformas e adaptveis descrio e oferece mecanismos eficientes para
captura, gerenciamento e manipulao dos perfis do dispositivo, do usurio e do contexto
em que executam, o que auxilia a construo de Mobile Application Servers (MAS) para
realizar adaptao de contedo.
Um estudo de caso, que consiste em um sistema para adaptao de imagens
fotogrficas tambm apresentado para ilustrar como os frameworks e a ferramenta UIG
podem ser utilizados para construir sistemas complexos para dispositivos mveis.
iv
ABSTRACT
The heterogeneity of mobile devices and their integration with wireless
communication technologies impose challenges for the development of applications and
services, such as: device and platform independent user interface description; content
adaptation for mobile applications; and development of multi-platform applications.
Several works have been proposed to solve these challenges. However, no satisfactory
approach has been found in the literature that allows a software engineer to specify multiplatform applications using an initial description of their interface and data as well as using
an independent description of a specific device or a programming platform. Moreover, it
has not been found in the literature solutions that facilitate the description of an application
and its integration with content adaptation architectures.
Therefore, it is necessary the creation of an environment to integrate and improve
these existing solutions. This master thesis proposes an environment for mobile device
applications composed by the XFormUI, Requisitor, Mobile Adapter and MobAC
frameworks and the User Interface Generator (UIG), which is a code generation tool. This
environment offers the fast development of multi-platform and description adaptable
applications. Moreover, it provides efficient mechanisms for capture, management and
manipulation of device, user and context profiles. These mechanisms help the construction
of Mobile Application Server (MAS) that executes content adaptation.
A case study, which consists in a system for adaptation of photographic images, is
also presented in this work to illustrate how the frameworks and the UIG tool is used to
build complex systems for mobile devices.
NDICE
RESUMO.............................................................................................................................IV
ABSTRACT ......................................................................................................................... V
LISTA DE FIGURAS..................................................................................................... VIII
LISTA DE TABELAS........................................................................................................IX
LISTA DE ABREVIATURAS E SIGLAS ........................................................................ X
1.
INTRODUO .......................................................................................................... 12
1.1.
1.2.
1.3.
2.
CARACTERIZAO DO PROBLEMA E MOTIVAO ................................................. 12

OBJETIVOS ............................................................................................................. 14
ORGANIZAO DA DISSERTAO .......................................................................... 16
ADAPTAO PARA DMS: DESAFIOS E SOLUES...................................... 18

2.1.
2.2.
DEFINIO E CARACTERSTICAS DE ADAPTAO .................................................. 18

DESCRIO, INDEPENDENTE DE DISPOSITIVO E PLATAFORMA, DA INTERFACE DAS
APLICAES ....................................................................................................................... 20
2.2.1.
Adaptive Applications for Ubiquitous Collaboration .............................. 20
2.2.2.
ICrafter: A Framework for Ubiquitous Computing Environments.......... 22
2.2.3.
Using XML to semi-automatically derive user interfaces........................ 24
2.2.4.
XML-based unified user interface system under J2EE architecture........ 24
2.2.5.
MAB - Mobile Application Builder .......................................................... 25
2.2.6.
UIML User Interface Markup Language .............................................. 26
2.2.7.
Resumo comparativo .................................................................................... 27
2.3. ARQUITETURAS DE ADAPTAO DE CONTEDO.................................................... 29
2.3.1.
Adaptation d'une application multimdia par un code Mobile................ 30
2.3.2.
Context-aware adaptation for mobile devices ......................................... 31
2.3.3.
Adaptation in Mobile Computing............................................................. 32
2.3.4.
Resumo Comparativo ................................................................................... 33
2.4. CONCLUSO .......................................................................................................... 34
3.
PLATAFORMAS DE PROGRAMAO PARA DMS E FRAMEWORKS ...... 36

3.1. PLATAFORMAS DE PROGRAMAO........................................................................ 36
3.1.1.
J2ME............................................................................................................. 37
3.1.2.
Superwaba .................................................................................................... 41
3.1.3.
Resumo comparativo entre as plataformas .................................................. 43
3.2. FRAMEWORKS E PADRES DE PROJETO ................................................................. 45
3.3. CONCLUSO .......................................................................................................... 47
4.
FRAMEWORK XFORMUI...................................................................................... 49
4.1. XFORMS ................................................................................................................ 49
4.2. ANLISE DE DOMNIO ............................................................................................ 51
4.3. FRAMEWORK XFORMUI ......................................................................................... 53
4.3.1.
MainXForm .................................................................................................. 55
vi
4.3.2.
Formulrios .................................................................................................. 56
4.3.3.
Validaes e Restries ................................................................................ 59
4.3.4.
XFormItem e Componentes .......................................................................... 60
4.3.5.
Hot Spots e Classes do XFormUI ................................................................. 64
4.4. CONCLUSO .......................................................................................................... 65
5.
USER INTERFACE GENERATOR ........................................................................ 67

5.1. VISO GERAL DA FERRAMENTA USER INTERFACE GENERATOR ............................ 67
5.2. LINGUAGEM SUPORTADA PELA FERRAMENTA ........................................................ 69
5.2.1.
Suporte ao XForms....................................................................................... 70
5.2.2.
Suporte ao XML Schema .............................................................................. 72
5.2.3.
Suporte ao Cascading Style Sheets (CSS) .................................................... 73
5.3. REGRAS DE MAPEAMENTO PARA AS PLATAFORMAS ............................................... 74
5.4. PROCESSO DE GERAO DE CDIGO ...................................................................... 75
5.5. A ESTRUTURA DO CDIGO GERADO ....................................................................... 76
5.6. PLUGIN DO ECLIPSE ............................................................................................... 77
5.7. CONCLUSO .......................................................................................................... 79
6.
FRAMEWORKS MOBILE ADAPTER, REQUISITOR E MOBAC..................... 80

6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
7.
CC/PP E UAPROF ................................................................................................. 80

MOBILE ADAPTER E MOBAC ................................................................................ 81
ARQUITETURA DO MOBILE ADAPTER .................................................................... 84
FRAMEWORK REQUISITOR ...................................................................................... 86
ARQUITETURA DO MOBAC ................................................................................... 89
CONCLUSO .......................................................................................................... 91
ESTUDO DE CASO ................................................................................................... 92

7.1. M-FLOG................................................................................................................. 92
7.2. APLICAO NO DM............................................................................................... 94
7.3. MAS ADAPTATIVO ............................................................................................... 98
7.3.1.
Adaptao de Textos................................................................................... 100
7.3.2.
Adaptao de Imagens ............................................................................... 102
7.4. ANLISE DE EFICINCIA ...................................................................................... 103
7.5. CONCLUSO ........................................................................................................ 107
8.
CONCLUSO........................................................................................................... 108
8.1.
8.2.
9.
CONTRIBUIES E RESULTADOS ALCANADOS................................................... 108

TRABALHOS FUTUROS ......................................................................................... 109
BIBLIOGRAFIA ...................................................................................................... 112
vii
LISTA DE FIGURAS
Figura 1 - Viso geral da codificao da aplicao que executa no dispositivo mvel...... 15
Figura 2 - Viso geral do processo de construo de MAS Adaptativos............................. 16
Figura 3 - Processo de mapeamento das aplicaes ( extrado de [27] ) ........................... 22
Figura 4 - Estrutura de uma aplicao UIML (extrado de [14]) ....................................... 27
Figura 5 - Arquitetura NAC, retirado de [12] ..................................................................... 32
Figura 6 - Arquitetura proposta em [11] ............................................................................. 33
Figura 7 - Viso Geral das tecnologias Java da Sun [62]................................................... 38
Figura 8 - Adaptao ao dispositivo oferecida pela plataforma J2ME MIDP.................... 40
Figura 9 - Cdigo em XForms de uma tela de login............................................................ 50
Figura 10 - Visualizao da tela de login no X-Smiles [15]................................................ 51
Figura 11 - Framework XFormUI ....................................................................................... 55
Figura 12 - Telas dos componentes nas plataformas........................................................... 64
Figura 13 - Documento UAProf do P900 retirado do site da Sony Ericsson [97].............. 81
Figura 14 - Viso geral do Mobile Adapter e do MobAC.................................................... 82
Figura 15 - Viso geral do framework Mobile Adapter....................................................... 84
Figura 18 - Framework Requisitor ...................................................................................... 87
Figura 19 Cdigo que utiliza o framework Requisitor ..................................................... 89
Figura 16 - Framework MobAC e a interao com framework Requisitor......................... 90
Figura 17 - Documento CC/PP gerado durante uma requisio no dispositivo P900........ 90
Figura 20 - Viso geral do M-Flog...................................................................................... 93
Figura 21 - Telas da aplicao no XSmiles ......................................................................... 94
Figura 22 - Tela de login nas trs plataformas.................................................................... 96
Figura 23 - Um fluxo de execuo da aplicao cliente do M-Flog.................................... 98
Figura 24 Classes que participam dos processos de adaptao do M-Flog .................. 100
Figura 25 - Caminho Lgico da Adaptao de Textos ...................................................... 101
Figura 26 - Caminho Lgico da Adaptao de Imagens ................................................... 103
Figura 27 - Adaptao de imagens nos emuladores dos dispositivos................................ 104
Figura 28 - Grficos do Cenrio IEEE 802.11b................................................................ 105
Figura 29 - Grficos do cenrio GPRS com o A388.......................................................... 106
Figura 30 - Grficos da simulao no cenrio EDGE ...................................................... 106
viii
LISTA DE TABELAS
Tabela 1 Resumo comparativo de solues para descrio da interface com usurio .... 29
Tabela 2 Resumo comparativo dos trabalhos de adaptao de contedo ........................ 34
Tabela 3 Resumo comparativo entre as plataformas de programao ............................ 44
Tabela 4 - Cdigos do MainXForm nas plataformas........................................................... 56
Tabela 5 - TextArea, Triggers e o showAlert() em J2ME MIDP 2.0 ................................... 58
Tabela 6 - Cdigo do TextArea apresentado na Tabela 5 usando as classes de validao 60
Tabela 7- Restries de filtragem e componentes instanciados nas plataformas................ 63
Tabela 8 - Classes que compem o XFormUI e seus mapeamentos nas plataformas ......... 65
Tabela 9 - Cdigos do XML Schema da tela de login e do CSS usado nos formulrios .... 95
Tabela 10 Cdigo do formulrio em XForms e o correspondente em XFormUI ............. 96
Tabela 11- Caractersticas dos dispositivos testados ........................................................ 103
ix
LISTA DE ABREVIATURAS E SIGLAS

API
Application Programming Interface
CC/PP
Composite Capability/Preference Profiles
CLDC
Connected Limited Device Configuration
CSS
Cascading Style Sheets
DM
Dispositivo Mvel
EDGE
Enhanced Data GSM Environment
GPL
GNU General Public License
GPRS
General Packet Radio Service
GSM
Global System for Mobile Communications
HTML
HyperText Markup Language
IDE
Integrated Development Environment
IEEE
Institute of Electrical and Electronic Engineers
IP
Internet Protocol
J2EE
Java 2 Enterprise Edition
J2ME
Java 2 Micro Edition
J2SE
Java 2 Standard Edition
KVM
Kilobyte Virtual Machine
LAN
Local Area Network
LGPL
Lesser General Public License
MAS
Mobile Application Server
MIDP
Mobile Information Device Profile
MobAC
Mobile Adapter Client
NAC
Negotiation and Adaptation Core
PDA
Personal Digital Assitant
RTP
Real-Time Transport Protocol
SDK
Software Development Kit
SMIL
Synchronized Multimedia Integration Language
SQL
Structured Query Language
UAProf
User Agent Profiling
UID
User Interface Description
UIG
User Interface Generator
UPnP
Universal Plug and Play
VoiceXML
Voice Extensible Markup Language
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WLAN
Wireless Local Area Network
WML
Wireless Markup Language
WTK
Wireless Toolkit
XHTML
Extensible HyperText Markup Language
XML
eXtended Markup Language
XSL
eXtensible Stylesheet Language
XSLT
eXtensible Stylesheet Language Transformation
xi
Captulo 1
_______________________________________________________________________________________________________________________________________
1. Introduo
Esta dissertao apresenta um ambiente para desenvolvimento de aplicaes multiplataforma e adaptativas para dispositivos mveis. Neste captulo, apresentada na Seo
1.1 uma viso geral sobre o desenvolvimento de aplicaes para dispositivos mveis e a
caracterizao do problema que gerou a motivao deste trabalho. Na Seo 1.2, so
descritos os objetivos principais da dissertao, e, por fim, na Seo 1.3 apresentada a
estrutura na qual est organizado o restante do trabalho.
1.1. Caracterizao do Problema e Motivao

O desenvolvimento de aplicaes para dispositivos mveis tornou-se uma rea de grande
interesse para a computao devido ao aumento da disponibilidade desses dispositivos no
mercado e a sua crescente integrao com as tecnologias de comunicao sem fio [40].
Celulares com suporte a WAP, GPRS ou EDGE e handhleds, como Palms e Pocket PCs,
com Bluetooth [42] e IEEE 802.11 [73] fazem crescer a demanda por novos tipos de
servios e aplicaes nas mais diversas reas (e.g., sistemas de vendas em campo, coletores
de informao, aplicaes de entretenimento).
Essa integrao dos dispositivos mveis (DMs) com as redes de comunicao de
dados, permitiu aos sistemas corporativos e aos sistemas Web, que antes interagiam
somente com computadores desktops, serem acessados tambm por dispositivos mveis
[9]. Contudo, esses DMs apresentam diferentes restries de processamento, memria,
bateria e largura de banda. Eles possuem ainda diferenas nas formas de interao do
usurio com as aplicaes e nas dimenses e cores dos displays. Alm disso, o suporte a
plataformas de programao varia de um dispositivo para outro, dificultando a adoo de
uma nica plataforma para o desenvolvimento das aplicaes.
Desta forma, a heterogeneidade dos dispositivos e a integrao com as tecnologias de
comunicao sem fio tm imposto desafios para o desenvolvimento de aplicaes. Entre os
desafios
encontrados
na
pesquisa
bibliogrfica
realizada
nesta
dissertao
[22][76][12][25][26], destacam-se os seguintes: a descrio, independente de dispositivo e
_______________________________________________________________________________________________________________________
Um Ambiente de Desenvolvimento de Aplicaes Multi-Plataformas e Adaptativas para

Dispositivos Mveis
12
Captulo 1
_______________________________________________________________________________________________________________________________________
plataforma, da interface com usurio; a adaptao do contedo acessado pelas aplicaes; e

o desenvolvimento de aplicaes multi-plataformas.
O problema da descrio das interfaces das aplicaes consiste na dificuldade que o
engenheiro de software encontra em projetar as interfaces com usurio para que estas
possam se adequar a diferentes tipos de dispositivos e executar em diferentes plataformas
de programao. Para solucionar esse desafio, podemos citar os seguintes trabalhos: o
UIML (User Interface Markup Language) [14], o Icrafter [21], o UID (User Interface
Description) [16] , o MAB (Mobile Application Builder) [17] e MultiMad [75]. Esses
trabalhos propem a definio da interface utilizando documentos XML (i.e., eXtended
Markup Language) [36]. Essa definio feita atravs de marcaes (i.e., tags) prestabelecidas para a criao dos componentes de interface. Depois, geradores de cdigo
transformam a descrio inicial em cdigo executvel ou em documentos de uma
linguagem de marcao (e.g., XHTML). No caso do MAB e do MultiMad, ferramentas
grficas so disponibilizadas para facilitar a criao das interfaces das aplicaes.
Outros trabalhos foram propostos para prover a adaptao de contedo baseada nas
caractersticas dos dispositivos, nas preferncias dos usurios e no contexto do ambiente em
que o dispositivo se encontra (e.g., mudana na largura de banda).
Algumas dessas
solues utilizam proxys ou gateways para realizar a tarefa de adaptao, como em [10],
[11] e [12]. Contudo, esses trabalhos concentram toda a deciso da adaptao em uma
arquitetura geral, podendo no ser satisfatria para certos tipos de aplicaes que no
consistam na simples requisio de um contedo Web. Alm disso, essas solues no
apresentam formas eficientes de captura e gerenciamento dos perfis do usurio e do
dispositivo.
Conforme exposto anteriormente, existem solues para os desafios citados no
desenvolvimento de aplicaes para DMs. Entretanto, no foi encontrada na literatura
nenhuma abordagem satisfatria que permita a um engenheiro de software construir
aplicaes multi-plataformas utilizando uma descrio inicial da interface e dos seus dados,
de forma que essa descrio seja independente de um dispositivo especfico ou de uma
plataforma de programao. Vale ressaltar ainda que nenhuma soluo vislumbra
simultaneamente a descrio da aplicao e a sua integrao com as arquiteturas de
_______________________________________________________________________________________________________________________

Dispositivos Mveis
13
Captulo 1
_______________________________________________________________________________________________________________________________________
adaptao de contedo. Portanto, necessria a criao de um ambiente para integrar e

aprimorar essas solues existentes para os desafios expostos.
1.2. Objetivos
Na Seo 1.1, foi destacada a necessidade de integrar e aprimorar as solues
existentes para os desafios no desenvolvimento de aplicaes para DMs. Com o objetivo
principal de suprir essa necessidade, este trabalho apresenta um ambiente para a
programao em dispositivos mveis a fim de facilitar, para o engenheiro de software, o
desenvolvimento de aplicaes multi-plataformas e adaptativas.
Esse ambiente composto pelos frameworks XFormUI, Mobile Adapter, Mobile
Adapter Cliente (MobAC), Requisitor e pela ferramenta de gerao de cdigo User
Interface Generator (UIG). Com esse ambiente, o engenheiro de software pode construir
mais rapidamente tanto aplicaes que executam somente no dispositivo, como aplicaes
que trocam dados com servidores remotos, denominados Mobile Application Servers
(MAS) [74]. Nos dois tipos de aplicaes, o ambiente permite a construo de prottipos
utilizando uma descrio independente de uma plataforma de programao. E no caso da
aplicao que acessa um MAS, o ambiente prov um conjunto de frameworks que auxiliam
a construo do MAS e do cliente que executa no dispositivo mvel.
Para atingir o objetivo de construir aplicaes multi-plataformas com interfaces
adaptveis descrio, o ambiente proposto permite ao engenheiro descrever os
formulrios da aplicao, suas validaes e o estilo das interfaces em XForms [15]. Com
esses documentos, o engenheiro utiliza a ferramenta, User Interface Generator (UIG), para
produzir cdigo em uma plataforma de programao. Esse cdigo gerado utiliza o
framework multi-plataforma XFormUI para a composio dos formulrios, o que torna o
prottipo da aplicao multi-plataforma. Ao final do processo de gerao, o engenheiro
complementa a codificao acrescentando a lgica de negcio inerente aplicao. Na
Figura 1, uma viso geral desse processo de codificao apresentado.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
14
Captulo 1
_______________________________________________________________________________________________________________________________________
Figura 1 - Viso geral da codificao da aplicao que executa no dispositivo mvel
Nos casos em que o engenheiro precisa criar aplicaes que acessam um MAS, o
ambiente fornece dois frameworks: Mobile Adapter e MobAC. O Mobile Adapter facilita a
construo de MAS adaptativos, pois esse framework prov de forma eficiente informaes
sobre os perfis do dispositivo, do contexto e do usurio que acessa o MAS. O MobAC
permite a construo das aplicaes clientes que executam no dispositivo mvel e acessam
os MAS construdos com o Mobile Adapter.
Na Figura 2, apresentada uma viso geral do processo de construo dos MAS
adaptativos usando os frameworks propostos. Para a construo da aplicao cliente, o
engenheiro utiliza o cdigo dos formulrios gerados pela UIG (1) e codifica a integrao
com o MAS usando o framework MobAC (2). Na construo do servidor, o engenheiro
codifica o MAS utilizando o Mobile Adapter (I) e constri os pacotes de adaptao de
contedo baseados nas informaes fornecidas pelo framework (II). Ao final do processo, o
engenheiro construiu uma aplicao multi-plataforma adaptvel a descrio para DMs que
capaz de coletar informaes dinmicas sobre o dispositivo e envi-las ao MAS. Alm
disso, o MAS construdo pode recuperar as informaes estticas do dispositivo e do
usurio e as caractersticas dinmicas do contexto, o que possibilita a realizao da
adaptao do contedo requisitado pela aplicao do DM.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
15
Captulo 1
_______________________________________________________________________________________________________________________________________
Figura 2 - Viso geral do processo de construo de MAS Adaptativos
Para prover o desenvolvimento de aplicaes multi-plataformas e adaptativas, os

frameworks MobAC e XFormUI so implementados em trs plataformas de programao
J2ME MIDP 1.0/CLDC 1.0 [43], J2ME MIDP 2.0/CLDC 1.1 [43] e Superwaba [44]. Alm
disso, o ambiente proposto projetado para facilitar a construo de novas implementaes
dos frameworks em outras plataformas.
1.3. Organizao da Dissertao

Essa dissertao est dividida em mais 8 captulos que sero descritos a seguir:
No Captulo 2, apresentado um conjunto de definies para adaptao e so

detalhados os desafios e as solues existentes descritos na Seo 1.1 no
desenvolvimento de aplicaes para dispositivos mveis.
No Captulo 3, apresentada uma introduo sobre frameworks e sobre as

plataformas de programao investigadas para a construo e a implementao do
ambiente proposto na dissertao.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
16
Captulo 1
_______________________________________________________________________________________________________________________________________
No Captulo 4, so enumerados os requisitos desejados para a construo de um

framework de interface grfica e apresentado o projeto e os detalhes de
implementao do framework XFormUI para a construo de interfaces grficas
multi-plataformas.
No Captulo 5, apresentada a ferramenta de gerao de cdigo User Interface

Generator (UIG) proposta nesta dissertao para agilizar o desenvolvimento de
aplicaes para dispositivos mveis.
No Captulo 6, so apresentados os frameworks Mobile Adapter, MobAC e

Requisitor que, em conjunto, permitem a construo de Mobile Aplication Servers
(MAS) que adaptam contedo e seus clientes para DMs.
No Captulo 7, descrito um estudo de caso construdo para exemplificar como o

ambiente proposto pode ser utilizado para construir um MAS que adapta contedo e
uma aplicao para DM multi-plataforma e adaptvel a descrio. Uma avaliao da
eficincia do uso da adaptao de imagens contida no estudo de caso tambm
apresentada.
No Captulo 8, a concluso da dissertao apresentada com as principais

contribuies e os resultados alcanados, alm de sugestes de trabalhos futuros.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
17
Captulo 2
_______________________________________________________________________________________________________________________________________
2. Adaptao para DMs: Desafios e Solues

Neste captulo, so detalhados os desafios e as solues existentes no cenrio atual do
desenvolvimento de aplicaes para DMs. Como descrito no Captulo 1, esses desafios so
impostos pela heterogeneidade e pela integrao desses dispositivos com as tecnologias de
comunicao sem fio.
Na Seo 2.1, so apresentadas a definio e os diferentes modos de adaptao. Na
Seo 2.2, solues para a descrio, independente de dispositivo e de plataforma, da
interface das aplicaes so descritas. Por fim, na Seo 2.3, so apresentadas arquiteturas
de adaptao de contedo encontradas na literatura.
2.1. Definio e Caractersticas de Adaptao

Adaptao, de forma mais geral, definida como o relacionamento entre um organismo e
seu ambiente tal que uma mudana ou uma coleo de mudanas do organismo resultam
em uma melhor adequao em um contexto particular [76]. Portanto, ser adaptvel significa
ter a habilidade de modificar o comportamento para responder a eventuais mudanas de um
ambiente. Analogamente, em cincia da computao, uma aplicao adaptvel quando
tm a capacidade de se adequar, de forma tima, a mudanas nas circunstncias em que
executa [22]. Assim, se o ambiente de execuo mudar, a aplicao capaz de se modificar
para executar de uma forma mais eficiente nas novas condies.
No caso de aplicaes para DMs, a heterogeneidade e a dinamicidade do ambiente de
computao mvel tornam a adaptao da aplicao uma tcnica necessria. M. Wieiser
denomina de calm computing [23] a adaptao de uma aplicao sem a interveno
humana. No desenvolvimento de aplicaes adaptativas esse o objetivo a ser alcanado
[24]. Contudo, a construo desse tipo de aplicao representa um obstculo ainda maior
para o engenheiro de software.
A adaptao de uma aplicao para DMs pode ocorrer de vrias formas e em
diferentes momentos. Entre os modos de adaptao, destacam-se os seguintes
[81][27][26][25][76]:
Adaptao descrio: a capacidade de descrever uma aplicao permitindo
sua adequao ou transformao em diferentes linguagens ou plataformas de programao.

_______________________________________________________________________________________________________________________

Dispositivos Mveis
18
Captulo 2
_______________________________________________________________________________________________________________________________________
Nesse caso, a aplicao descrita em uma meta-linguagem e transformada em uma

linguagem de programao (e.g., Java, C++) ou em uma linguagem de marcao de
hipertexto como Extensible HyperText Markup Language (XHTML) ou Wireless Markup
Language (WML).
Adaptao ao dispositivo: a habilidade de uma aplicao de adequar seu modo
de execuo s caractersticas do dispositivo. Essas caractersticas podem ser estticas,

como nmero de cores e dimenses da tela, e dinmicas, como a quantidade de memria e
bateria disponveis. Essa adaptao pode ser especfica para um dispositivo ou ocorrer
tambm em relao a uma classe deles (e.g., celulares, handhelds).
Adaptao ao contexto: a propriedade de uma aplicao de adequar-se a
mudanas no contexto em que executa. As mudanas no contexto podem ser decorrentes,

por exemplo, das alteraes da localizao do dispositivo, do interesse do usurio e da
largura de banda de comunicao.
Esses modos de adaptao podem acontecer tanto em tempo de construo como em
tempo de execuo. A adaptao em tempo de construo ocorre quando uma aplicao
transformada para se adequar mudana de um ambiente antes de executar nele. Esse tipo
de adaptao exige a interveno do engenheiro de software e caracterizada pela
construo de novas verses da aplicao. Por exemplo, uma aplicao que tem uma verso
para executar em celulares e uma verso para executar em handhelds.
No caso da adaptao em tempo de execuo, a aplicao adaptvel modifica seu
comportamento, sem a interveno do engenheiro de software, para atender as mudanas no
ambiente em que j est executando. Por exemplo, uma aplicao de visualizao de
streams de vdeos capaz de modificar as propriedades do vdeo para se adequar s variaes
na banda passante do canal de comunicao.
Os modos de adaptao apresentados anteriormente no esto restritos a uma
mudana no modo de execuo das aplicaes nos DMs. A adaptao pode tambm estar
relacionada adequao dos dados que a aplicao acessa. Nesse caso, a adaptao
denominada de adaptao de contedo.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
19
Captulo 2
_______________________________________________________________________________________________________________________________________
2.2. Descrio, independente de dispositivo e plataforma, da

interface das aplicaes
Como foi mencionado anteriormente, uma das formas de adaptao a adaptao
descrio. Nesse tipo de adaptao, a aplicao tem que ser descrita em uma meta
linguagem, independente de uma linguagem de programao ou de marcao, que executa
em um determinado dispositivo. Para prover esse tipo de adaptao, foram propostos
trabalhos [14] [21] [16] [17] que utilizam documentos XML para definir a interface da
aplicao e, em alguns casos, definir tambm seus dados.
Descrever uma interface de uma aplicao independente de uma plataforma de
programao e de um dispositivo, uma tarefa complexa, j que esses dispositivos
possuem diversas formas de exibio de dados e de interao com o usurio. Portanto,
descrever, por exemplo, que uma interface de uma aplicao composta por botes e reage
a eventos de click, pode no ser adequado.
Com o objetivo de solucionar a questo da definio da interface, os trabalhos
descritos nas subsees seguintes sugerem uma outra forma de descrio dos componentes
e dos eventos das aplicaes. Cada trabalho ser apresentado atravs de um resumo
contendo seus objetivos, resultados alcanados, propostas de trabalhos futuros e uma
classificao quanto a tipo de adaptao de acordo com as definies apresentadas na Seo
2.1. No final dessa seo, apresentado um resumo comparativo das solues.
2.2.1.
Adaptive Applications for Ubiquitous Collaboration
Em [27], descrita uma arquitetura para a proviso de adaptao para aplicaes mveis
em ambientes colaborativos heterogneos. Um ambiente colaborativo caracterizado pela
existncia de vrios usurios colaborando e interferindo sobre uma determinada coleo de
objetos ou de dados. No caso de [27], as aplicaes executam em diferentes dispositivos e
devem ser capazes de acessar, interferir e perceber alteraes do ambiente colaborativo.
Os autores identificam trs requisitos para garantir a adaptao nesses ambientes: a
descrio, independente de dispositivo, da interface da aplicao que possa ser facilmente
mapeada para uma implementao real; a adaptao dinmica da interface com usurio,
baseada em mudanas contextuais, tais como, alteraes no interesse do usurio ou na
_______________________________________________________________________________________________________________________

Dispositivos Mveis
20
Captulo 2
_______________________________________________________________________________________________________________________________________
largura de banda; e o suporte visualizao heterognea dos dados, na qual a visualizao

adaptada s potencialidades do dispositivo.
No trabalho apresentada uma arquitetura para suportar o desenvolvimento de
ferramentas para facilitar a colaborao em ambientes heterogneos. Essa arquitetura define
uma linguagem para a descrio genrica das aplicaes e mapeia essa descrio em uma
implementao especfica. A linguagem de descrio composta de um conjunto de
componentes chamados de interactors, semelhante abordagem do XWeb[28], que
correspondem visualizao de um objeto ou de um recurso do mundo compartilhado (e.g.,
um rob em uma sala, um conjunto de lmpadas controladas por vrios dispositivos).
Na arquitetura, foi definida uma linguagem baseada em XML para a especificao
desses interactors. XSL (eXtensible Stylesheet Language) [36] e processadores XSLT
(XSL Transformation) mapeiam essa especificao em uma visualizao adaptada a classe
do dispositivo alvo. No caso de um computador, gerada uma visualizao tri-dimensional,
e no caso de um PDA, so geradas plantas bidimensionais.
A arquitetura foi definida para possibilitar que eventos externos ou eventos indiretos
das aplicaes de visualizao (e.g., mover o rob pra frente) sejam refletidos em todas as
visualizaes. Dessa forma, toda a lgica e os dados da aplicao concentram-se no
servidor. Esse, por sua vez, gera a aplicao a ser enviada aos dispositivos quando esses
requisitam ou quando ocorre alguma alterao nos objetos do ambiente colaborativo.
Como foi mencionado, o processo de gerao da aplicao acontece no servidor, que
responsvel por mapear a descrio da aplicao e dos dados em uma visualizao Java
que enviada para o dispositivo que fez a requisio da aplicao. Desta forma, a
arquitetura prov adaptao em tempo de execuo em relao descrio e a classes
de dispositivos. Na Figura 3, ilustrado esse mecanismo de mapeamento.
Para testar a arquitetura, foi construda uma aplicao, o SlowTetris, que possui
quatro objetos no ambiente colaborativo. Os dados dos objetos, como dimenses e
localizao, foram descritos utilizando os interactors. Esses eram mapeados em cWorld,
um Software Development Kit (SDK) de Java 3D, e em PocketEscape, um ambiente de
visualizao bidimensional em Pocket PC. O SlowTetris possibilita apenas a visualizao
dos quatro objetos, sem eventos de interao da aplicao mvel com eles.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
21
Captulo 2
_______________________________________________________________________________________________________________________________________
Essa abordagem torna a aplicao mvel uma visualizao do mundo compartilhado

permitindo poucos eventos e limitando as possibilidades de aplicaes que possam ser
construdas. Entretanto, o uso de XML para descrever a interface da aplicao e o uso de
XSLT para mape-la representam boas estratgias para o provimento de adaptao
descrio. Como trabalhos futuros, foi apresentada a possibilidade de serem geradas
aplicaes J2ME MIDP [43].
Figura 3 - Processo de mapeamento das aplicaes ( extrado de [27] )
2.2.2.
ICrafter: A Framework for Ubiquitous Computing
Environments
Em [21], apresentado o ICrafter, um framework para o desenvolvimento de servios
e de suas interfaces com usurio para uma categoria de ambientes ubquos, os espaos
interativos (i.e., interative workspaces). Um espao interativo um espao fsico rico em
tecnologia. Ele pode conter computadores interconectados (e.g., desktops, laptops,
handhelds.), dispositivos de uso geral (e.g., scanners, impressoras) e dispositivos de I/O
(e.g., projetores, microfones, alto-falantes). Nesses espaos interativos, os usurios,
utilizando os seus dispositivos, podem interagir com o ambiente e com outros usurios para
_______________________________________________________________________________________________________________________

Dispositivos Mveis
22
Captulo 2
_______________________________________________________________________________________________________________________________________
compartilhar dados e colaborar na realizao de tarefas (e.g., apresentaes, revises de

projeto). Os espaos de trabalho interativos podem ser salas de reunies, de conferncias ou
bibliotecas.
Baseado nas caractersticas dos espaos interativos citadas anteriormente, a
arquitetura do ICrafter prope a centralizao das aplicaes em um servidor que possui
informaes sobre o contexto do ambiente. Na estrutura do ICrafter, os clientes devem
requisitar um servio atravs de um pedido ao servidor de UIs (i.e., interfaces de usurios)
especficas para o dispositivo utilizado. O pedido recebido por uma entidade chamada de
Interface Manager (IM). O IM, ao receber um pedido para uma UI de um servio, seleciona
primeiramente um gerador baseado no dispositivo, que realizou o pedido, e no servio para
qual a UI foi pedida. Em seguida, o IM executa o gerador que cria uma descrio da
aplicao para ser enviada ao dispositivo para que ele monte a interface (e.g., HTML para
um notebook com navegador).
Para criar as UIs, os geradores necessitam de acesso informao dos servios, do
dispositivo, e do contexto do espao interativo. Essas informaes esto armazenadas no
servidor, num espao chamado de Context Memory, sendo esse, compartilhado por todos os
dispositivos que fazem parte do ambiente.
Os dispositivos ubquos, ao receberem a descrio das UIs do servio, devem ser
capazes de transform-las em interfaces permitidas pelo dispositivo. No ICrafter, foram
implementadas: a gerao de VoiceXML, HTML e SUIML (Swing UI Markup Language).
O SUIML uma linguagem tambm proposta no ICrafter para ser utilizada em dispositivos
que suportam Java Swing (i.e., uma biblioteca grfica do Java) atravs da instalao de um
middleware chamado de SUIML Interpreter. Esse middleware transforma uma interface
descrita em SUIML em componentes grficos da API do Java.
O ICrafter semelhante, em termos de concepo, ao trabalho descrito na Seo
2.2.1, com a diferena de exigir no dispositivo que requisita um servio a existncia de uma
aplicao capaz de transformar os UIs em uma interface exibvel no dispositivo. Desta
forma, tambm prov adaptao da interface das aplicaes, em tempo de execuo,
adaptao descrio e s classes de dispositivos.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
23
Captulo 2
_______________________________________________________________________________________________________________________________________
2.2.3.
Using XML to semi-automatically derive user interfaces
Em [16], apresentada uma abordagem para gerao semi-automtica de interfaces de

aplicaes a partir de XML. O artigo apresenta uma linguagem prpria para descrio da
interface, baseada em XML, denominada de UID (User Interface Description) que permite
a descrio da interface da aplicao atravs dos UIOs (User Interface Objects) que
representam componentes de entrada e sada de dados. O engenheiro de software deve
especificar um mapeamento de cada UIO, descrito na interface da aplicao, para um
componente de uma linguagem de programao (e.g., Java) ou uma linguagem de marcao
(e.g.,VoiceXML) atravs de um documento chamado UIM (User Interface Mapping).
No trabalho [16], ao contrrio dos trabalhos [27] e [21], no foram especificadas
regras para mapear a linguagem UID para uma linguagem de marcao ou de programao.
Essa tarefa deveria ser realizada pelo engenheiro de software e esse poderia tambm utilizar
a linguagem DEVDEF proposta para especificar as caractersticas do dispositivo alvo da
aplicao. Dessa forma, usando a definio inicial e as regras escritas pelo engenheiro de
software, o processo de mapeamento seria realizado.
Um prottipo inicial de uma ferramenta que realiza o mapeamento para WML foi
desenvolvido. Contudo, a ferramenta no realizava o processo completo de gerao do
cdigo WML, sendo a sua finalizao apresentada como um trabalho futuro. A ferramenta
gera em tempo de construo o WML a partir dos UIDs descritos no XML. Assim, a
ferramenta prov adaptao, em tempo de construo, descrio da interface das
aplicaes.
importante mencionar que na concluso do trabalho foi destacado que padres
como Composite Capability/Preference Profiles (CC/PP) [47] e Universal Plug and Play
(UPnP) [29] podem ser mais adequados para a descrio do dispositivo do que o DEVDEF
proposto pelo trabalho.
2.2.4.
XML-based unified user interface system under J2EE
architecture
Em [30], apresentada uma arquitetura para o desenvolvimento de aplicaes para
internet. A arquitetura projetada para prover diferentes visualizaes de dados e servios
contidos em um servidor Web, permitindo o acesso a esses servios por diferentes clientes
_______________________________________________________________________________________________________________________

Dispositivos Mveis
24
Captulo 2
_______________________________________________________________________________________________________________________________________
(e.g., PCs, PDAs). A arquitetura, intitulada de XML-Based Unified User Interface System,
dividida em trs camadas: a cliente, que possui um navegador com suporte a linguagens de
marcao WEB (e.g., XHTML); a middlelayer, que contm a lgica de programao; e a
camada de dados na qual esto as bases de dados legadas ou os bancos de dados. A
arquitetura proposta para ser desenvolvida utilizando J2EE [51], tecnologia Java para
servidores.
As aplicaes devem ser desenvolvidas utilizando J2EE e o acesso aos dados deve ser
realizado com XML. Documentos XML so utilizados na comunicao com qualquer base
de dados, inclusive as legadas. Para realizar essa operao, sugerida a criao do XML
DB Converter, uma camada da arquitetura responsvel por mapear os dados contidos nos
documentos XML, provenientes da aplicao, em um formato conhecido pelos banco de
dados (e.g., inseres em SQL). O mapeamento foi implementado de XML para tabelas
cujos relacionamentos eram um para um.
A arquitetura sugere que a interface das aplicaes seja descrita tambm em XML e
que conversores devem ser escritos para mapear essa descrio em uma linguagem de
marcao aceita pelos navegadores dos computadores ou dos PDAs (e.g., XHTML, WML),
assim, a arquitetura permite adaptao, em tempo de execuo, descrio e a classes de
dispositivos.
Na arquitetura so apresentados como trabalhos futuros: o desenvolvimento de uma
linguagem para descrever as aplicaes e a construo de conversores para linguagens de
marcao (e.g., HTML, WML).
2.2.5.
MAB - Mobile Application Builder
Em [17], apresentada uma soluo para o problema de descrio de aplicaes

independentes de dispositivo. O trabalho prope que a descrio da aplicao seja realizada
em XML e apresenta a possibilidade de gerar cdigo nativo ou intermedirio para um
dispositivo alvo, assim como, a possibilidade de acrscimo de cdigos na linguagem de
programao (e.g., J2ME MIDP).
No trabalho, foi apresentada uma ferramenta, intitulada MAB (Mobile Application
Builder), que possibilita a gerao de cdigo J2ME MIDP para executar em PalmOS
utilizando KVM/CLDC [43], assim como a gerao de cdigo WML para executar em
_______________________________________________________________________________________________________________________

Dispositivos Mveis
25
Captulo 2
_______________________________________________________________________________________________________________________________________
celulares atravs do uso de WAP [114]. A ferramenta possibilita a criao de aplicaes

cliente/servidor que utilizam trs componentes de interface: listas, texto e formulrios. A
interface da aplicao construda atravs de um mdulo grfico que possibilita a
montagem dos componentes que compem a interface, bem como a relao entre eles. A
ferramenta gera uma descrio da aplicao em XML que depois convertida no cdigo
alvo. Assim, a ferramenta prov adaptao, em tempo de construo, descrio da
interface das aplicaes.
A incorporao e a importao de dados so feitas atravs do uso de XML, mas o
acesso a dados no dispositivo no possibilitado pela ferramenta, sendo esse, um papel
adicional do programador que deve utilizar o recurso de insero de cdigos externos
atravs da invocao de mtodos de uma classe abstrata. A ferramenta construda em
Delphi e a tecnologia utilizada na aplicao servidor Java Servlets [51] rodando em um
servidor TomCat. Uma aplicao teste de m-Commerce criada para validar o uso da
ferramenta.
2.2.6.
UIML User Interface Markup Language
A UIML [52] uma linguagem declarativa baseada em XML para especificao de

interfaces de usurio independente de dispositivo. A UIML permite a descrio da interface
em cinco partes: description, structure, data, style e events. Na Figura 4, apresentada uma
aplicao que segue essa estrutura do UIML.
Em <description>, declara-se os elementos que compem a interface e a classe a qual
pertence cada elemento. Em <structure>, descreve-se como os componentes se agrupam
para definir a interface (e.g. um boto dentro de um painel dentro de um formulrio). Em
<data>, descrita a informao que deve ser exibida pela interface para cada componente
(e.g. OK para um boto). Em <style>, definido o mapeamento de cada classe para um
componente de uma linguagem real e em <events> permitido associar eventos em
linguagens reais (e.g. Java) aos componentes descritos.
A plataforma proprietria LiquidUI [113] fornece uma aplicao servidor para
realizar mapeamentos de aplicaes escritas em UIML para WML, VoiceXML e HTML
dependendo da requisio realizada por um navegador via HTTP. Essa ferramenta prov,
portanto, adaptao, em tempo de execuo, descrio da interface das aplicaes.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
26
Captulo 2
_______________________________________________________________________________________________________________________________________
O UIML apresenta como desvantagens: a permisso para que quaisquer componentes

de interface possam ser definidos, a exigncia de que cada aplicao possua uma folha de
estilo para mapeamento, a definio de eventos dependentes de uma implementao real e a
ausncia de grande quantidade de documentao.
Figura 4 - Estrutura de uma aplicao UIML (extrado de [14])
2.2.7.
Resumo comparativo
As solues de adaptao descrio expostas anteriormente tm em comum o uso de uma

meta linguagem para descrever as interfaces das aplicaes em XML. Essa meta linguagem
em um determinado momento convertida em cdigo de uma linguagem de programao
ou de uma linguagem de marcao. Essa converso pode ocorrer tanto em tempo de
construo quanto em tempo de execuo.
A ferramenta User Interface Generator (UIG) proposta nesta dissertao e detalhado
no Captulo 5 utiliza a mesma abordagem de descrio das aplicaes em XML. E realiza,
em tempo de construo, a converso desse XML para um cdigo executvel nas
plataformas de programao para DMs.
Na Tabela 1, apresentada um resumo das principais caractersticas das solues
descritas e da ferramenta UIG possibilitando uma melhor visualizao das caractersticas
comuns e das diferenas existentes entre as solues. As caractersticas apresentadas so as
seguintes:
I - Tipos de Aplicaes alvo;
II - Plataformas de programao das aplicaes geradas;
_______________________________________________________________________________________________________________________

Dispositivos Mveis
27
Captulo 2
_______________________________________________________________________________________________________________________________________
III - Componentes grficos das interfaces das aplicaes;

IV - Definio de estilos para as interfaces;
V - Gerao de comportamento esperado para as interfaces;
VI - Exigncia de middlewares para execuo das aplicaes;
VII - Existncia de uma ferramenta grfica para auxiliar a edio;
VIII - Integrao com arquiteturas de adaptao de contedo;
IX - Estratgia de adaptao.
Para facilitar a construo da tabela foram criados acrnimos para dois trabalhos:
AAUC referente ao trabalho Adaptive Applications for Ubiquitous Collaboration e UID
referente ao trabalho Using XML to semi-automatically derive user interfaces. Os demais
acrnimos j so adotados nos prprios trabalhos expostos anteriormente.
III
AAUC
Aplicaes para
ambientes
colaborativos
PockectSpace e
J2SE com 3D
interactors
IV
II
ICrafter
Aplicaes para
espaos
interativos
VoiceXML,
HTML e SUIML
UIs criados pelo
engenheiro de
software para
cada servio do
espao interativo
-
UID
Aplicaes com
formulrios
MAB
Aplicaes com
formulrios
UIG
Aplicaes com
formulrios
WML
WML e J2ME
MIDP 1.0
Listas, Textos,
Formulrios com
campos de entrada
de dados e datas
Superwaba, J2ME
MIDP 1.0 e 2.0
10 componentes
do XForms e o
image do XHtml
Uso de CSS (i.e.,
O engenheiro
cria os
componentes
UIO de entrada
de dados
-
Cascading
Style Sheets)
VI
VII
Uma ao em um
interactor reflete
em uma mudana
no modelo
compartilhado
A aplicao no
PDA exige o
PockectSpace
-
Uma ao em um
UI invoca um
servio no
servidor
Passagem de
parmetros entre
formulrios
SUIML
Interpreter para
gerao em
SUIML
-
Ferramenta para
definies dos
formulrios e da
interao entre eles
para definio de
cores e atributos
para definir
alinhamento
Uso de XML
Schema para
definio da
validao da
entrada de dados
-
Plugin para o
Eclipse que
facilita a
configurao da
gerao de cdigo
_______________________________________________________________________________________________________________________

Dispositivos Mveis
28
Captulo 2
_______________________________________________________________________________________________________________________________________
VIII
IX
A arquitetura
adapta o modelo
em relao
visualizao
XSLT prO engenheiro cria
estabelecidos para
templates para
a transformao
mapear o
resultado dos
do XML
servios nos UIs
O engenheiro
escreve um
UIM com as
regras de
mapeamento
A ferramenta
contm os
mapeamentos
definidos
gerao de cdigo
O cdigo gerado
facilmente
integrvel ao
MobAC
XSLT prestabelecidos para
a transformao
do XML
Tabela 1 Resumo comparativo de solues para descrio da interface com usurio
2.3. Arquiteturas de Adaptao de Contedo

Na Seo 2.2, foram apresentadas solues para o problema de definio, independente de
dispositivo, da interface de uma aplicao. Contudo, a adaptao de uma aplicao no est
restrita a sua interface com usurio. Como mencionado no Captulo 1, a integrao dos
dispositivos mveis com as redes de comunicao de dados permitiu aos sistemas
corporativos e aos sistemas Web, que antes interagiam somente com computadores
desktops, serem acessados tambm por dispositivos mveis [9]. Essa integrao imps a
exigncia de um outro tipo de adaptao para as aplicaes: a adaptao de contedo, j
que as informaes dos sistemas corporativos e dos sistemas Web, em geral, no esto
preparadas para serem exibidas por esses dispositivos [12].
Nesses casos em que um sistema acessado por diferentes dispositivos e por
computadores desktops, o contedo deve ser cuidadosamente selecionado e adaptado s
condies restritivas do equipamento de destino (e.g. dimenses do display, quantidade de
cores, memria disponvel). Obviamente, que o mesmo contedo direcionado para um
computador fixo (i.e. desktop) no deve ser enviado a um celular, por exemplo. Nesse caso,
tanto deve haver reduo das informaes, como modificao da forma de apresentao dos
dados.
Contudo, a adaptao de contedo no, necessariamente, baseia-se somente nas
caractersticas dos dispositivos que acessam as informaes. As preferncias e o contexto
do usurio que utiliza a aplicao tambm podem ser relevantes nessa adaptao.
Informaes sobre a localizao, o perfil e os parmetros de qualidade de servio do
usurio so importantes para a deciso de filtragem de informao [9]. Essa adaptao
_______________________________________________________________________________________________________________________

Dispositivos Mveis
29
Captulo 2
_______________________________________________________________________________________________________________________________________
chamada em [12], de adaptao semntica. Essa pode considerar inclusive a lngua materna
do usurio para converter as informaes.
As estratgias para adaptao de contedo podem ser divididas em:
Adaptao de contedo baseada em agentes mveis.
Nesse tipo de
adaptao de contedo, a aplicao no DM contm um agente mvel capaz de coletar dados

sobre o dispositivo e usurio e migrar para uma rede (e.g a Internet) com intuito de buscar
informaes nos servidores para a aplicao. Dentre os trabalhos que descrevem solues
para esse tipo de adaptao podemos citar o PUMAS [38] , o
KODAMA [35] e o
CONSORT [39] .
Adaptao de contedo baseada em proxys ou gateways. Nesse tipo de
adaptao de contedo, imagens, vdeos, udio e pginas Web, so requisitadas pelas

aplicaes atravs de gateways ou proxies que so responsveis por adaptar as informaes
utilizando as caractersticas do dispositivo ou do usurio que as acessa.
Nas subsees seguintes so descritos trs trabalhos que utilizam a estratgia de
adaptao de contedo atravs de proxys e gateways. Esses trabalhos so fortemente
relacionados soluo de adaptao de contedo do ambiente proposto nesta dissertao.
2.3.1.
Adaptation d'une application multimdia par un code
Mobile
No trabalho [10], so descritas as vantagens de utilizar adaptao de contedo atravs de
proxys. Dentre as vantagens, so citadas as seguintes: a adequao das informaes ao
dispositivo e a diminuio do trfego de informao entre o proxy e o DM que, na maioria
das vezes, utiliza uma conexo sem fio instvel e de baixa largura de banda.
No trabalho, uma arquitetura para adaptao de vdeo apresentada. Um proxy
usado para intermediar e adaptar um stream de vdeo de acordo com as dimenses da tela
do dispositivo, consistindo, de acordo com as definies de adaptao descritas na Seo
2.1, em uma adaptao de contedo, em tempo de execuo, ao dispositivo. O proxy
utiliza HTTP para se comunicar com o servidor no qual se encontra o vdeo requisitado e
utiliza RTP (i.e., Real Time Protocol) para entregar o vdeo ao dispositivo mvel. Durante a
converso, o proxy converte o vdeo de MPEG para o formato H.263 e reduz as imagens
brutas que compem o vdeo, assim como pode modificar o nmero de quadros por
_______________________________________________________________________________________________________________________

Dispositivos Mveis
30
Captulo 2
_______________________________________________________________________________________________________________________________________
segundo no vdeo adaptado. Entretanto, o trabalho no apresenta uma abordagem para

coletar as informaes sobre os dispositivos mveis e enviar essas caractersticas ao proxy
para realizar a adaptao.
2.3.2.
Context-aware adaptation for mobile devices
Em [12], apresentada uma arquitetura de adaptao de documentos Web para dispositivos

mveis, intitulada de NAC (Negotiation and Adaptation Core). Nessa arquitetura, a
adaptao do contedo modifica o layout dos documentos baseado nas caractersticas do
dispositivo cliente e das preferncias do usurio. Para realizar a adaptao, um conjunto de
regras de converso estabelecido na arquitetura. Essas regras so utilizadas por um proxy
para realizar a transformao dos documentos.
Um repositrio dos perfis dos usurios e dos dispositivos criado para fornecer as
caractersticas necessrias para adaptao. Esses perfis encontram-se descritos no padro
proposto pelo World Wide Web Consortium (W3C) [36] para a descrio de perfis
conhecido como Composite Capability/Preference Profiles (CC/PP) [46]. Os vocabulrios
para a construo dos documentos CC/PP utilizam a linguagem UPS (Universal Profiling
Schema) proposta nesse mesmo trabalho.
O acesso do proxy aos perfis realizado utilizando a tecnologia SOAP [55] para
acessar WebServices. Assim, quando um dispositivo deseja acessar um documento Web, ele
requisita ao proxy, que obtm o documento original dos servidores de contedo e o
documento CC/PP com o perfil do dispositivo. O proxy realiza a adaptao baseada nas
regras pr-estabelecidas e devolve ao dispositivo o documento transformado.
Os documentos Web podem ser adaptados para a lngua de preferncia do usurio.
Neste caso, o documento original contido no servidor Web deve ser descrito em SMIL [10],
uma tecnologia XML que permite a descrio de contedo com alternativas, por exemplo,
textos em ingls e francs. Assim, o proxy retira o contedo descrito na lngua de
preferncia do usurio e o devolve ao dispositivo. Nesse caso, uma adaptao de
contedo, em tempo de execuo, ao contexto (i.e., preferncias do usurio e perfil do
dispositivo).
_______________________________________________________________________________________________________________________

Dispositivos Mveis
31
Captulo 2
_______________________________________________________________________________________________________________________________________
Outra forma de adaptao exposta refere-se apresentao dos documentos que

podem ser convertidos de XHTML para WML caso sejam acessados por celulares. Nesse
caso, uma adaptao de contedo, em tempo de execuo, ao dispositivo.
Uma importante desvantagem desta arquitetura a necessidade de descrever cada
novo dispositivo em UPS, que dificulta a escalabilidade dessa soluo. Outro problema
decorre do fato da adaptao, em alguns casos, necessitar de documentos alternativos para
cada requisio. Na Figura 5, ilustrada essa arquitetura.
Figura 5 - Arquitetura NAC, retirado de [12]
2.3.3.
Adaptation in Mobile Computing
Em [11], apresentada uma arquitetura geral para adaptao de contedo multimdia Web
utilizando um mdulo cliente para monitoramento e realizao de tarefas de descompresso
e um gerenciador de adaptao localizado em um servidor proxy. Esse gerenciador de
adaptao repassa as requisies recebidas para os mdulos responsveis pelas adaptaes
especficas de um servio.
No trabalho, mdulos, parmetros e estratgias para a realizao de adaptao de
imagem, vdeo e udio so definidos. Na Figura 6, ilustrada a arquitetura proposta em
[11], na qual um mdulo cliente de adaptao capaz de monitorar e armazenar
informaes sobre as preferncias do usurio e informaes sobre o dispositivo. Essas
informaes so enviadas em cada requisio da aplicao ao gerenciador de adaptao
localizado no servidor. Esse servidor, por sua vez, repassa as informaes para o mdulo de
_______________________________________________________________________________________________________________________

Dispositivos Mveis
32
Captulo 2
_______________________________________________________________________________________________________________________________________
adaptao responsvel pelo servio, por exemplo, no caso de requisio de um vdeo, ela
repassada ao mdulo de adaptao de vdeo.
O trabalho apresenta a simulao da adaptao de stream de vdeo baseada nas
mudanas da banda passante da simulao. O que consiste em uma adaptao de
contedo, em tempo de execuo, ao contexto. Contudo, as formas de adquirir a
informao necessria para realizar a adaptao no so apresentadas.
Figura 6 - Arquitetura proposta em [11]
2.3.4.
Resumo Comparativo
Na Tabela 2, apresentada um resumo das principais caractersticas das arquiteturas

de adaptao de contedo descritas anteriormente. As arquiteturas so comparadas ao
framework Mobile Adapter proposto nesta dissertao possibilitando uma melhor
visualizao das caractersticas comuns e das diferenas existentes entre as solues. As
caractersticas abordadas no resumo comparativo so:
I - Tipos de Aplicaes alvo;
II - Processo de captura das caractersticas dos dispositivos;
III - Descrio dos perfis do dispositivo e do usurio;
IV - Integrao com aplicaes para dispositivos mveis;
V - Tipos de Contedo Adaptado;
VI - Estratgias de adaptao.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
33
Captulo 2
_______________________________________________________________________________________________________________________________________
Adaptation
par un code
mobile
Aplicaes
multimdia Web
II
III
IV
Streams de Vdeo
VI
O vdeo
adaptado pelo
proxy para as
dimenses do
dispositivo
NAC
Mobile
Computing
Mobile Adapter
Aplicaes
Aplicaes multimdia Mobile Application Servers
multimdia para
para Web
(MAS)
Web
Um monitor no
Um monitor no
Um monitor no dispositivo
dispositivo captura dispositivo captura as
captura as caractersticas
as caractersticas
caractersticas e envia dinmicas, o identificador do
dinmicas e os
usurio e a URI do
a cada requisio
identificadores dos
documento UAProf que
perfis do usurio e
descreve o dispositivo
do dispositivo
Utiliza CC/PP para
Utiliza CC/PP para descrio
descrio dos perfis
dos perfis do usurio e
usando os
UAProf para descrio das
caractersticas estticas do
vocabulrios UPS
dispositivo
Um simulador
O MobAC implementado
executa em Pocket
em Superwaba, Personal
Profile, J2ME MIDP 1.0 e
PC
2.0
Documentos SMIL Imagens, Streams de
Recursos estticos (e.g.
e HTML
udio e de vdeo.
imagens, texto)
Extrao de
Streams de Vdeo so As estratgias de adaptao
contedo e
adaptados banda
so delegadas ao MAS
converso de
passante da simulao
formatos de HTML
para WML
Tabela 2 Resumo comparativo dos trabalhos de adaptao de contedo
2.4. Concluso
Neste captulo, foram apresentadas arquiteturas de adaptao de contedo e solues
para a construo de aplicaes adaptveis descrio. No caso das arquiteturas de
adaptao de contedo, os trabalhos no apresentam formas eficientes de captura,
manipulao e gerenciamento dos perfis do dispositivo, do contexto e do usurio, o que
dificulta a construo de sistemas reais que realizem adaptao de contedo.
Os trabalhos para a construo interfaces com usurio adaptveis descrio
restringem os tipos de aplicaes que podem ser construdas. E, em certos casos, exigem do
engenheiro software a escrita das regras de mapeamento e dos componentes de interface
com usurio. No caso do MAB, existem poucos componentes grficos para a construo
dos formulrios.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
34
Captulo 2
_______________________________________________________________________________________________________________________________________
Alm disso, como mencionado no Capitulo 1, necessria a criao de um ambiente

para integrar e aprimorar essas solues existentes para os desafios do desenvolvimento de
aplicaes para DMs. A abordagem de construo de interfaces adaptveis proposta por
Allan [27] e a arquitetura de adaptao de contedo NAC [12] foram utilizadas como base
para atingir este objetivo e construir o ambiente proposto nesta dissertao.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
35
Captulo 3
_______________________________________________________________________________________________________________________________________
3. Plataformas de programao para DMs e

FrameWorks
Neste captulo, apresentada uma introduo sobre frameworks e sobre as
plataformas de programao investigadas para a construo e a implementao dos
frameworks XFormUI, MobAC e Requisitor propostos nesta dissertao.
Na Seo 3.1, so descritas as caractersticas das plataformas Superwaba, J2ME
MIDP 1.0/CLDC 1.0 e MIDP 2.0/CLDC 1.1. Na Seo 3.2, so apresentadas as definies
de framework , a sua correlao com padres de software e como essas tecnologias podem
ser utilizadas para facilitar a construo de aplicaes adaptativas e multi-plataformas.
3.1. Plataformas de Programao

No Captulo 1, o desenvolvimento de aplicaes multi-plataformas foi descrito como um
dos desafios no desenvolvimento de aplicaes para DMs. Para construir aplicaes para
esses dispositivos, um engenheiro de software pode utilizar uma diversidade de linguagens
e plataformas de programao, como: Brew [59], J2ME [43], C++ [56], Superwaba [44],
Mophun [57] e CodeWarrior C++ [58]. Essas aplicaes podem tambm ser criadas
utilizando linguagens de marcao, como HTML, XHTML [36] e WML quando os
dispositivos mveis possuem navegadores que suportam essas tecnologias.
O desafio no desenvolvimento de aplicaes multi-plataformas decorre do suporte
heterogneo a essas plataformas de programao e a essas linguagens de marcao. Em sua
maioria, as plataformas para DMs executam apenas em uma classe de dispositivos (e.g.,
Sattellite Forms [86] para handhelds), ou em um determinado sistema operacional (e.g.,
CodeWarrior C++ para Palm OS [48]). Esse mesmo problema acontece com as linguagens
de marcao, pois apenas algumas classes de dispositivos suportam WML (e.g., celulares),
HTML (e.g., Pockect PCs) e XHTML (e.g., smartphones). Portanto, essa heterogeneidade
inviabiliza a escolha de uma nica linguagem para o desenvolvimento de uma aplicao
que tenha como requisito executar em uma grande quantidade de diferentes dispositivos.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
36
Captulo 3
_______________________________________________________________________________________________________________________________________
Assim, em muitos casos, a nica soluo para o engenheiro de software reescrever

todo o cdigo da aplicao para que essa execute em uma outra plataforma de
programao. A reescrita do cdigo pode ocorrer mesmo nos casos em que o engenheiro
escolhe plataformas baseadas na mesma linguagem de programao. Isto acontece com
Superwaba [44] e J2ME [43]. Essas plataformas so baseadas na linguagem de
programao Java, mas possuem APIs (Application Programming Interface) diferentes para
interface grfica, armazenamento e comunicao de dados. At mesmo o suporte aos tipos
bsicos de dados diferente nessas plataformas.
Portanto, existe uma necessidade de construir solues que permitam ao engenheiro
de software desenvolver, com uma menor quantidade de reescrita de cdigo, aplicaes que
executem em muitos dispositivos. Com objetivo de criar um ambiente que atenda a essa
necessidade, as plataformas Superwaba, J2ME MIDP 1.0/CLDC 1.0 e J2ME MIDP
2.0/CLDC 1.1 foram investigadas.
Essas plataformas foram escolhidas por apresentarem alguns conceitos de adaptao
descrio, porque em conjunto so suportadas por uma grande quantidades de DMs e o
processo de desenvolvimento pode ser realizado, em sua maioria, utilizando ferramentas
livres e de cdigo aberto. Alm disso, essas plataformas so baseadas em Java, uma
linguagem orientada a objeto, com curva de aprendizagem relativamente baixa em relao a
linguagens como C++ e j amplamente adotada [20] [75].
Nas subsees seguintes, so descritos detalhes de cada uma dessas plataformas e ao
final, um resumo comparativo entre elas apresentado.
3.1.1.
J2ME
Java 2 Mobile Edition (J2ME) [43] uma coleo de tecnologias e especificaes que
foram projetadas pela Sun Microsystems[tm] para o desenvolvimento de aplicaes para
dispositivos de pequeno porte, especialmente sem fio. J2ME utiliza a linguagem de alto
nvel Java que foi projetada para executar independentemente de um sistema operacional
especfico e sintaticamente semelhante ao C++. As especificaes do J2ME so divididas
em configuraes (i.e., Configurations) e perfis (i.e., Profiles). O conjunto perfilconfigurao determina quais as funcionalidades disponveis para uma aplicao e a forma
_______________________________________________________________________________________________________________________

Dispositivos Mveis
37
Captulo 3
_______________________________________________________________________________________________________________________________________
com que ela deve se estruturar. Na Figura 7, so ilustradas as especificaes e as

configuraes do J2ME e a sua relao com as outras tecnologias Java: J2SE e J2EE.
As configuraes so especificaes que detalham uma mquina virtual Java e um
conjunto bsico de APIs que podem ser usadas por um certo conjunto de dispositivos. Para
dispositivos de maior poder de processamento existe a especificao CDC (i.e., Connected
Device Configuration), voltada para dispositivos com mais de 512 KB de memria,
conexo permanente e taxa de transmisso relativamente alta. Na Figura 7, pode-se ver que
o CDC uma especificao cuja implementao se faz sobre a mquina virtual Java
convencional, que naturalmente demanda maior capacidade de processamento e memria.
Para dispositivos de pequeno porte, tais como PDAs e celulares, com menos de 512
KB de memria disponvel para as aplicaes e sem conexo permanente, usa-se a
especificao CLDC (i.e., Connected, Limited Device Configuration). A mquina virtual
Java para essa especificao conhecida como KVM (Kilo Virtual Machine) e seu
conjunto de APIs o ncleo de funcionalidades bsicas de uma aplicao (e.g tipos de
dados, conexo). O CLDC possui duas verses: a 1.0, que no contm tipos de dados ponto
flutuante e a verso 1.1, que incorpora esses tipos de dados e outras funes matemticas.
Os perfis (i.e., Profiles) so as especificaes que criam um ambiente completo para
desenvolvimento das aplicaes. Eles contm bibliotecas de classes adaptadas a uma
determinada famlia de dispositivos. Nessas bibliotecas esto os componentes de interface
visual e acesso a armazenamento de dados.
Figura 7 - Viso Geral das tecnologias Java da Sun [62]
_______________________________________________________________________________________________________________________

Dispositivos Mveis
38
Captulo 3
_______________________________________________________________________________________________________________________________________
O MIDP construdo sobre a especificao CLDC, como pode ser visto na Figura 7.
A unidade bsica de um programa MIDP um Midlet. Um Midlet executa no dispositivo
em um ambiente de execuo chamado de MidletSuite que limita as permisses de acesso
do Midlet ao dispositivo, semelhante ao mecanismo de sandbox dos Applets [62]. O MIDP
adiciona APIs com diversas funcionalidades, tais como: armazenamento de dados
permanentes, comunicao e interface com o usurio.
O MIDP foi projetado inicialmente para executar em celulares e pagers. Entretanto, j
existem implementaes para PDAs como a mquina virtual MIDP/CLDC para PalmOS da
IBM [63]. O MIDP possui duas verses: a 1.0, que possui muitas limitaes dos
componentes visuais e a 2.0, com maior quantidade de componentes e que executa sobre o
CLDC 1.1. As seguintes APIs esto presentes no MIDP:
javax.microedition.lcdui,
que
apresenta
um
conjunto
de
classes
para
implementao de interface com o usurio;
javax.microedition.rms, que fornece um mecanismo
para armazenamento de
dados permanentes;
javax.microedition.io, que fornece suporte bsico para rede e
javax.microedition.midlet, que faz a interface entre a aplicao e o ambiente em
que ele est executando.

As aplicaes J2ME MIDP/CLDC so extremamente limitadas com relao a
gerenciamento de eventos disponibilizados para programador. Apenas os eventos de aes
em Commands, semelhantes a botes, e seleo em um List, so disponibilizados. A
construo de interface nesta plataforma bem distinta de outras plataformas de
programao, pois no permite ao programador estabelecer a posio exata no display do
dispositivo na qual um componente de interface ir se posicionar.
O posicionamento de componentes em J2ME MIDP foi assim projetado para
possibilitar adaptao ao dispositivo da interface da aplicao. Na Figura 8, ilustrado esse
processo de adaptao provido pela plataforma, na qual uma mesma aplicao se comporta
da forma mais adequada em cada tipo de dispositivo. Por exemplo, o componente que lista
opes apresentado no Palm OS como um ComboBox, no qual um click dispara a abertura
de uma pequena janela com as opes. J nos outros dispositivos as opes j so
_______________________________________________________________________________________________________________________

Dispositivos Mveis
39
Captulo 3
_______________________________________________________________________________________________________________________________________
apresentadas na tela. Alm disso, a forma como os commands so exibidos na tela

modifica-se dependendo da mquina virtual do dispositivo. No caso do Palm OS, os
commands so apresentados diretamente no display do dispositivo, j em outros, so
acessveis atravs de um Menu (options em certos celulares).
Figura 8 - Adaptao ao dispositivo oferecida pela plataforma J2ME MIDP
No MIDP 2.0, novos componentes so disponibilizados e existe a possibilidade de

determinar alinhamento aos componentes (e.g. centro, esquerdo, direita). Outra vantagem
do MIDP 2.0 permitir a construo de componentes costumizveis atravs da classe
CustomItem. Esse componente foi utilizado para a elaborao do ColorLabel que ser
apresentado no framework XFormUI e que possibilita atribuir cores aos labels dos
componentes. Na Figura 8, ilustrada uma aplicao MIDP 2.0 utilizando o ColorLabel e
as funes de alinhamento.
Para comear a desenvolver aplicativos em J2ME/MIDP necessria a instalao das
seguintes ferramentas:
Editor
Java
de texto: necessrio para editar o cdigo fonte do aplicativo;
2 Standard Edition (J2SE) SDK: utilizado para compilar, pr-verificar e
empacotar os cdigos escritos para J2ME .

J2ME
Wireless Toolkit (WTK): um conjunto de ferramentas que oferece ao
engenheiro de software um ambiente de gerenciamento dos projetos, compilao,

_______________________________________________________________________________________________________________________

Dispositivos Mveis
40
Captulo 3
_______________________________________________________________________________________________________________________________________
emulao, documentao e exemplos necessrios para o desenvolvimento de aplicaes

usando a especificao CLDC/MIDP [37].
Emuladores
de dispositivos reais: os fabricantes de dispositivos mveis
disponibilizam SDKs com emuladores de modelos comerciais que podem ser integrveis ao
WTK.
Existem verses distintas do Wireless Toolkit e dos SDKs dos fabricantes para MIDP
1.0 e MIDP 2.0. Uma aplicao MIDP 1.0 pode executar em um dispositivo MIDP 2.0,
contudo o contrrio no possvel. E na maioria dos dispositivos, no existe a possibilidade
de realizar atualizao das mquinas virtuais para suportar a nova verso do MIDP.
Existem ambientes de desenvolvimento completos, os IDEs, com os quais o
engenheiro de software pode escrever, testar e depurar aplicaes em um nico ambiente.
Um bom exemplo de um IDE completo Sun Java[tm] Studio Mobility [79], da prpria
Sun. Outra IDE bastante utilizada o ambiente Eclipse [37] que atravs do uso do plugin
eclipseme [78] oferece todo o processo de desenvolvimento: edio, compilao,
depurao, pr-verificao, empacotamento e emulao no WTK e nos SDKs dos
fabricantes.
Neste trabalho, iremos considerar o J2ME MIDP 2.0/CLDC 1.1 e J2ME MIDP
1.0/CLDC 1.0 como plataformas distintas, j que o MIDP 2.0 apresenta diferenas
significativas, como mencionadas anteriormente, em relao ao MIDP 1.0 e exige uma
nova mquina virtual e uma ferramenta distinta para compilao.
3.1.2.
Superwaba
O Superwaba [44] uma plataforma de software livre para desenvolvimento de software

para PDAs. O Superwaba foi criado no incio de 2000, por Guilherme Campos Hazan,
bacharel em Cincia da Computao, pela Universidade Federal do Rio de Janeiro e uma
evoluo de um outro projeto de software livre chamado Waba. A plataforma
disponibilizada sob duas verses: GPL (gratuita) e LGPL (subscrio anual), que permite
tanto o desenvolvimento de aplicaes livres quanto comerciais, e ao mesmo tempo impe
que a plataforma continue como um software de cdigo aberto.
O Superwaba SDK define uma linguagem, uma mquina virtual, um formato de
arquivo para armazenagem de classes e um conjunto de classes padro. Um programa
_______________________________________________________________________________________________________________________

Dispositivos Mveis
41
Captulo 3
_______________________________________________________________________________________________________________________________________
Superwaba multi-plataforma, pode executar, com as devidas restries, tanto em PalmOS,

Pocket PC e Symbian OS, alm de poder executar como um applet em Linux e Windows.
Devido ao modo com que o Waba e o Superwaba foram projetados, os programadores
podem usar as ferramentas Java, como compiladores e editores, para desenvolver
programas em Superwaba. Entretanto, o Superwaba no implementa nenhuma parte das
especificaes do Java e tambm no tem nenhuma conexo com a detentora da marca, a
Sun Microsystems [62].
As principais APIs disponveis no Superwaba so:
java.lang, que contm os tipos bsicos de dados e a classe Class;
waba.ui, que contm os principais componente para construo de interface

grfica;
waba.fx, que engloba a classe Graphics para desenhos e a classe Color para
mudana de cores;
waba.io, para entrada/sada e classes de comunicao;
waba.sys, com classes que oferecem uma interface com o sistema operacional;
Superwaba.ext, com classes para acesso de perifricos.
Alm disso, o Superwaba fornece um conjunto completo de APIs para

desenvolvimento em PDAs, como classes para exibio de informaes GPS (i.e. Global
Positioning System), classes para acessar dados pessoais nas plataformas Pocket PC e Palm
OS e classes que permitem armazenamento de dados em arquivos PDBs (i.e. Palm Record
Database) tambm no Pocket PC, o que torna o PDB, especfico do Palm OS, multiplataforma. Nas verses mais recentes, foram disponibilizadas classes para realizar
consultas SQL sobre PDBs, o pacote PDBDriver.
O Superwaba permite a criao de bibliotecas nativas em C e tem suporte escala de
cinza, cores e alta-resoluo em todos os PDAs. O Superwaba utiliza toda a memria
disponvel para as aplicaes, ao contrrio do J2ME MIDP.
Ele permite ainda acessar banco de dados para PDAs como o IBM Db2EveryPlace
[65] e o PDB SQL [44], alm de suportar tipos de dados ponto flutuante, fontes
customizveis, deteco de coliso para jogos, janelas popup e arrastveis, Threads, USB e
IrDA.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
42
Captulo 3
_______________________________________________________________________________________________________________________________________
O Superwaba ao contrrio do J2ME MIDP, possibilita ao engenheiro de software

determinar a posio dos componentes no display e colocar mais de um componente em
uma mesma linha do dispositivo. Esta caracterstica, apesar de possibilitar uma maior
flexibilidade para a criao de interfaces, pode impedir que uma aplicao se adapte a
diferentes dispositivos com resolues distintas. Para evitar esse problema, o Superwaba
permite posicionamento relativo dos componentes usando diretivas de posicionamento (e.g.
AFTER, BEFORE, RIGHT).
A unidade bsica de uma aplicao Superwaba a classe MainWindow. Todo
programa Superwaba inicia-se atravs da execuo dessa classe. O Superwaba possibilita o
gerenciamento de uma grande quantidade de eventos para interface: eventos de click com
as canetas dos PDAs, eventos de focus e de sada dos componentes e eventos de seleo.
Com Superwaba, pode-se construir janelas arrastveis, modificar as propriedades de cores
dos componentes, criar componentes customizveis e adicionar menus s aplicaes.
Para iniciar o desenvolvimento de aplicaes mveis utilizando a plataforma
Superwaba, necessrio utilizar os seguintes componentes:
Editor de texto: para editar o cdigo fonte do aplicativo;
Java 2, Standard Edition (J2SE) Software Development Kit (SDK): para a
compilao, empacotamento e execuo no computador desktop.

Superwaba SDK [11]: contm as classes que compem a plataforma;
Emuladores ou simuladores: Palm OS Emualtor (POSE), Palm OS Simulator,
UIQ SDK para Symbian OS.

No desenvolvimento em Superwaba, a ferramenta Eclipse tambm pode ser utilizada
para a compilao, a emulao e a gerao de instaladores das aplicaes.
3.1.3.
Resumo comparativo entre as plataformas
Conforme descrito anteriormente, para construir os frameworks do ambiente proposto,

as funcionalidades distintas e comuns das plataformas de programao para DMs foram
investigadas. Na Tabela 3, apresentado um resumo comparativo das caractersticas dessas
plataformas que foram mais relevantes para a criao do framework XFormUI de interface
grfica e do framework Requisitor de comunicao de dados.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
43
Captulo 3
_______________________________________________________________________________________________________________________________________
Critrio
MIDP 1.0
MIDP 2.0
Superwaba
Executa em Palm OS
SIM
SIM
SIM
Executa em Windows CE
NO
NO
SIM
Na maioria dos modelos a

partir de 2003
Na maioria dos
modelos a partir de
2005
S em alguns modelos
Symbian OS
Executa em celulares
Interface Adaptvel ao
dispositivo
SIM
Mquinas virtuais so pagas

pelos fabricantes
Custos
Documentao disponvel
Acesso a arquivos do
sistema
Suporte a TCP/IP
Suporte a IrDA
Depende do
engenheiro de
software
SIM
Livros, sites e fruns
Mquinas virtuais so
pagas pelos
fabricantes
Livros, sites e fruns
Depende da licena
Restrita ao site e aos
fruns
NO
Sim, usando a PIM

API
SIM
S HTTP
HTTP e Sockets
HTTP e Sockets
NO
Depende do
dispositivo
SIM
Formato PNG, GIF e

JPG
Formato BMP na
verso GPL e PNG,
GIF e JPG na verso
LGPL
Suporte a imagens
Formato PNG
Controle do layout
Os componentes so
adicionados um por linha
Controle de
alinhamento e adio
de componentes
Posicionamento
relativo dos
componentes
Suportes a cores nos

componentes de interface
NO
S nos componentes
CustomItems
SIM
Suporte a ponto flutuante
NO
SIM
SIM
18 componentes e
componentes
customizveis
Mais 100
componentes
disponveis na API e
no site
Quantidade de
componentes
12 componentes
Tabela 3 Resumo comparativo entre as plataformas de programao
Como pode ser visto, cada uma delas atende a uma classe de dispositivos e
apresentam funcionalidades distintas, principalmente em relao composio das
interfaces grficas. Alm disso, a estrutura do cdigo da aplicao varia de J2ME MIDP
para Superwaba, o que dificulta mais ainda a portabilidade de aplicaes entre as
plataformas.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
44
Captulo 3
_______________________________________________________________________________________________________________________________________
3.2. Frameworks e Padres de Projeto

O conceito de framework apresentado na literatura de diferentes modos. Uma
definio mais geral apresentada em [66]: um framework um projeto abstrato para um
tipo de aplicao. Segundo Viljamaa [44], framework um conjunto de objetos
reutilizveis que engloba conhecimento de determinadas reas e se aplica a um domnio
especfico. Framework definido tambm como um projeto de reutilizao que descreve
como o sistema est decomposto em um conjunto de objetos que interagem entre si,
podendo ser uma aplicao inteira ou apenas um subsistema [87].
Nessa dissertao, consideraremos um framework como um elemento para o reuso de
componentes de arquiteturas orientadas a objetos. De um framework podem ser
especializadas partes significantes de uma aplicao ou at mesmo, uma aplicao
completa. Assim, um framework determina a arquitetura da aplicao e predefine
parmetros de projeto, permitindo ao engenheiro concentrar-se nos detalhes especficos da
aplicao.
Vale ressaltar que um framework orientado a objeto diferente de um pacote de
classes ou de uma API, pois indica o modo como as classes devem ser instanciadas para
colaborar na construo de uma aplicao. Frameworks tm como objetivo facilitar para o
engenheiro de software a construo de aplicaes com a adio de menor quantidade de
cdigo escrito possvel, alm de propiciar que boas solues possam ser reutilizadas dentro
de um mesmo domnio de aplicaes.
Frameworks so construdos para serem flexveis e permitir a adio de novas
funcionalidades. Pontos de flexibilizao, chamados de Hot Spots, so disponibilizados
para propiciar a incorporao dessas novas caractersticas.
Para utilizar frameworks, os engenheiros de softwares escrevem subclasses das
classes contidas na estrutura (frameworks caixa branca) ou utilizam classes existentes
(frameworks caixa preta). Com essas classes, criam objetos para colaborarem juntos na
realizao das funcionalidades.
De um modo geral, o processo de desenvolvimento de um framework realizado em
trs grandes fases [20] que so descritas a seguir:
_______________________________________________________________________________________________________________________

Dispositivos Mveis
45
Captulo 3
_______________________________________________________________________________________________________________________________________
anlise de domnio Nessa fase, identificado e organizado o conhecimento
sobre o domnio para o qual o framework proposto. O objetivo principal dessa fase
capturar os requisitos do domnio, encontrar os pontos comuns para compor o framework e
identificar os pontos de flexibilizao (i.e., os Hot spots).
projeto de framework Nessa fase, concentram-se os esforos na criao das
abstraes do framework e na identificao dos relacionamentos entre as classes que iro

comp-lo;
instanciao do framework Nessa fase, o engenheiro de software constri
classes a partir das classes disponveis (framework caixa branca) ou escolhe classes
fornecidas na estrutura (framework caixa preta) para criar as aplicaes.
Em geral, como frameworks focam na reutilizao de boas solues, outro conceito
de engenharia de software, os padres de software, so utilizados durante a fase de projeto
de um framework. De acordo com Coplien [68], um padro um pedao de literatura que
descreve um problema de projeto e uma soluo geral para o problema num contexto
particular. Desta forma, um padro uma entidade que documenta uma soluo, um
problema recorrente e o contexto em que se deve aplicar tal soluo.
Padres de software so utilizados em diferentes estgios do desenvolvimento de um
software. E podem ser classificados de acordo como a fase em que so aplicados (e.g.
padres de anlise, padres de projeto) [19]. Nesta dissertao, diversos padres de projeto
foram utilizados para a construo dos frameworks e da ferramenta de gerao de cdigo do
ambiente proposto. Alm de facilitar a construo dos frameworks, os padres de projeto
so tambm adequados para document-los, pois o uso de padres permite o entendimento
do framework, sem forar o conhecimento pleno do seu cdigo fonte [45].
Alm de permitir o reuso de boas solues, frameworks so utilizados tambm para
abstrair para o engenheiro de software como APIs especficas de uma plataforma de
programao so utilizadas para realizar tarefas comuns. Por exemplo, uma implementao
de um framework caixa preta pode conter classes que usam APIs de uma plataforma de
programao, porm, o engenheiro de software ao instanciar essas classes no sabe quais
APIs so usadas e nem como elas so acessadas.
Assim, caso um framework seja implementado em diferentes plataformas de
programao, os cdigos das aplicaes que utilizam o framework podero executar nas
_______________________________________________________________________________________________________________________

Dispositivos Mveis
46
Captulo 3
_______________________________________________________________________________________________________________________________________
diferentes plataformas. Desta forma, frameworks podem ser construdos para abstrair
funcionalidades como construo de interface grfica, persistncia, comunicao de dados e
segurana.
Uma outra forma de realizar essa abstrao seria o uso de middlewares que
oferecessem s aplicaes essas funcionalidades. Esses middewares seriam implementados
nos diferentes dispositivos mveis e poderiam ser requisitados pelas aplicaes [60].
Contudo, o uso de middlewares pode no ser possvel devido pequena quantidade de
memria de alguns dispositivos, alm do desperdcio de espao e do atraso no tempo de
execuo que os middlewares podem causar, como foi comprovado no trabalho [61].
Portanto, frameworks podem ser mais adequados para realizar a abstrao das APIs, alm
de permitir a sua alterao e extenso por parte do engenheiro de software.
Dentro desse contexto, um framework de persistncia de dados para DMs, o
FramePersist, foi proposto em [1] com objetivo de prover a transparncia do
armazenamento de objetos para a aplicao e fornecer um mecanismo eficiente de busca de
objetos. Na construo do FramePersist, formas de armazenamento de dados das
plataformas J2ME Personal Profile, J2ME MIDP e em Superwaba foram estudadas e
generalizadas no framework para permitir sua implementao nas diferentes plataformas.
Essa mesma abordagem de abstrao das APIs utilizada na construo do
framework XFormUI e do framework Requisitor propostos nesta dissertao.
As
funcionalidades comuns de cada plataforma investigada so incorporadas aos frameworks e

as diferenas nas instanciaes das classes que compem as APIs das plataformas so
ocultadas das aplicaes. Por exemplo, um engenheiro de software escreve um cdigo que
realiza uma conexo HTTP utilizando o framework Requisitor, sem saber que cada
implementao desse framework instancia classes distintas das APIs das plataformas para
realizar a conexo.
3.3. Concluso
Neste Captulo, foram apresentados os principais conceitos relacionados a
frameworks e s plataformas de programao para DMs.
Como visto na seo 3.1, as plataformas J2ME MIDP 1.0/CLDC 1.0, MIDP
2.0/CLDC 1.1 e Superwaba apresentam diferenas quanto a forma de estruturar as
_______________________________________________________________________________________________________________________

Dispositivos Mveis
47
Captulo 3
_______________________________________________________________________________________________________________________________________
interfaces das aplicaes e contm APIs distintas para sua construo. Alm disso, cada
plataforma mais adequada para um grupo de dispositivos. Desta forma, para que um
engenheiro de software possa construir aplicaes que executem em grande quantidade de
dispositivos, boa parte do cdigo dessas aplicaes teria que ser reescrito.
Os frameworks XFormUI e Requisitor propostos nesta dissertao tm o objetivo de
diminuir essa reescrita na construo de interfaces com usurio e na realizao de
comunicao de dados. O framework XFormUI ser apresentado no prximo captulo,
assim como a ferramenta UIG que realiza a gerao de cdigo que estende esse framework
a partir de documentos XML.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
48
Captulo 4
_______________________________________________________________________________________________________________________________________
4. Framework XFormUI
Neste captulo apresentado o framework proposto nesta dissertao para a construo de
interfaces grficas multi-plataformas para DMs. Na seo 4.1, apresentada a tecnologia
XForms utilizada como fonte de nomes e de componentes para o framework. Na seo 4.2,
so apresentados os requisitos identificados para a construo do XFormUI. Na seo 4.3,
apresentada uma viso geral do framework e como ele atende aos requisitos.
4.1. XForms
XForms [53][15] um esforo do World Wide Web Consortium (W3C) [36] para substituir
formulrios HTML por um formato mais avanado que permita a definio de formulrios
Web multi-plataformas e independente de dispositivos. XForms uma linguagem baseada
em XML que permite a definio de formulrios, eventos e dados iniciais dos formulrios.
A estrutura de um documento XForms baseada no modelo MVC (i.e.,
Model/Viewer/Controller) e dividida em trs partes: Instance, Model e User Interface.
Essa estrutura composta pelos dados iniciais, pelos componentes de interface e pelos
eventos. Dessa forma, a aplicao XForms construda de modo mais abstrato, com a
separao de dados, lgica e apresentao. Essa abordagem definida em [15] como a
forma ideal para criao de aplicaes independente de dispositivo.
A descrio dos componentes de interface e dos eventos do XForms foi projetada para
ser independente de dispositivo. Os campos de entrada de dados, por exemplo, so descritos
como inputs e no como campos de texto que ocupam determinadas posies na tela.
Outro exemplo o elemento que dispara um evento de ao. Em XForms, em vez de
descrev-lo como um boto que recebe um evento de click, esse elemento descrito como
um gatilho (i.e., trigger) que recebe um evento de ativao. Isto permite que dispositivos
que no possuam interface visual possam executar tambm a aplicao XForms.
Outra grande vantagem de XForms permitir a integrao com outras tecnologias
XML como CSS (Cascading Style Sheets) [36] e XML Schema [36]. Em [15],
apresentado um navegador chamado X-Smiles que suporta parte da linguagem XForms e
sua integrao com as tecnologias citadas anteriormente. O navegador executa apenas em
PCs e foi programado utilizando a linguagem Java.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
49
Captulo 4
_______________________________________________________________________________________________________________________________________
Na Figura 9, apresentado o cdigo de um pequeno formulrio que contm dois

campos de entradas de dados e dois gatilhos de aes. So utilizados os componentes de
interface input, secret e trigger do XForms. Cada componente descrito possui um label. No
caso do input e do secret usa-se XPath [36] para acessar os dados contidos na parte Model
do documento. Na aplicao, o campo de entrada de dados tfLogin descrito como um
input, possui o label Login e a referncia ao valor /data/login que nesse caso
Windson. Na Figura 10, ilustrada a visualizao desse formulrio, utilizando o
navegador X-Smiles [15].
<?xml version="1.0" encoding="ISO-8859-1" ?>
<XHTML xmlns="http://www.w3.org/1999/xhtml"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<HEAD>
<link href="css.css" rel="stylesheet" type="text/css"/>
<title>Formulrio</title>
<xforms:model id="FormLogin">
<xforms:instance xmlns="" id="instance1">
<data>
<faixa>Exemplo XForms</faixa>
<login>Windson</login>
<senha>senha</senha>
</data>
</xforms:instance>
</xforms:model>
</HEAD>
<BODY>
<xforms:output ref="/data/faixa" id="faixa">
<xforms:label/>
</xforms:output>
<xforms:input ref="/data/login" id="tfLogin">
<xforms:label>Login:</xforms:label>
</xforms:input>
<xforms:secret ref="/data/senha"id="pwSenha">
<xforms:label>Senha:</xforms:label>
</xforms:secret>
<xforms:trigger id="btOK">
<xforms:label>OK</xforms:label>
</xforms:trigger>
<xforms:trigger id="btLimpar">
<xforms:label>Limpar</xforms:label>
</xforms:trigger>
</BODY>
</XHTML>
Figura 9 - Cdigo em XForms de uma tela de login
O XForms utilizado nessa dissertao para servir como fonte de nomes e de

componentes para o framework XFormUI. Alm disso, documentos XForms so utilizados
pela ferramenta UIG, descrita no Captulo 5, para a gerao de cdigo nas plataformas de
programao. A escolha do XForms deve-se ao fato dessa tecnologia ter qualidades
desejadas para uma linguagem de descrio de interface. Dentre essas qualidades, podemos
enumerar: a descrio dos componentes e dos eventos da interface independente de
dispositivo e a grande quantidade de detalhes que as aplicaes podem conter. Alm disso,
_______________________________________________________________________________________________________________________

Dispositivos Mveis
50
Captulo 4
_______________________________________________________________________________________________________________________________________
o XForms tem boa quantidade de documentao [54], se comparado aos outros trabalhos
mencionados no Captulo 2.
Figura 10 - Visualizao da tela de login no X-Smiles [15]
4.2. Anlise de domnio

Como mencionado no Captulo 3, a primeira fase no processo de desenvolvimento de
um framework consiste na anlise do seu domnio. Desta forma, para a concepo do
framework XFormUI, foi investigada a construo de interfaces grficas nas plataformas de
programao para DMs. Essa investigao ocorreu com o estudo apresentado no Captulo 3
das plataformas de programao e com o desenvolvimento de software para DMs
apresentado nos trabalhos [3], [4] e [1].
Nesta anlise do domnio, foi identificada, uma lista, no exaustiva, de requisitos
desejveis para um framework de construo de interfaces grficas para DMs. Esses
requisitos so descritos a seguir:
1. Disponibilidade de uma variedade de componentes de interface. importante
para um engenheiro de software ter a sua disposio uma variedade de componentes de
interface para compor os formulrios, por exemplo, componentes de entrada de texto,
nmeros, datas e senhas; componentes para escolha de opes; gatilhos para disparar aes;
componentes para exibio de textos e imagens; e componentes para exibio de tabelas de
dados (i.e., os grids).
2. Suporte a mecanismos de restrio e validao da entrada de dados em um
formulrio. Em geral, os dados que so preenchidos por um usurio de uma aplicao tm
_______________________________________________________________________________________________________________________

Dispositivos Mveis
51
Captulo 4
_______________________________________________________________________________________________________________________________________
restries estabelecidas pelas regras de negcio e devem ser validados durante o seu
preenchimento. Assim, o framework deve conter mecanismos de restrio e validao
desses dados preenchidos para auxiliar o engenheiro de software no desenvolvimento das
aplicaes.
3. Suporte a funes para troca de formulrios e exibio de mensagens. O
framework deve permitir a fcil mudana entre os formulrios de uma aplicao para
agilizar os processos de prototipao e desenvolvimento. Outra importante funo a
exibio de mensagens que so usadas nas aplicaes para informar erros de entrada de
dados e exibir alertas com informaes sobre o sistema.
4. Suporte ao Gerenciamento de Eventos. O gerenciamento de eventos uma das
partes mais importantes do desenvolvimento de uma aplicao, pois define a mudana de
fluxo entre formulrios e dispara as aes realizadas pela aplicao. Com o framework, o
engenheiro de software deve ser capaz de gerenciar eventos que disparam aes (e.g., clicks
em um boto), eventos de seleo de opes e eventos de mudana de estado dos
componentes (e.g., entrada e sada, alterao do valor).
5. Execuo adaptativa nos dispositivos. O framework deve possibilitar a construo
de interfaces grficas adaptativas para dispositivos mveis. As interfaces devem se adequar
a diferentes dispositivos e tentar exibir sempre a melhor forma de apresentao. Por
exemplo, a aplicao construda com o framework deve ser capaz de expandir sua rea de
viso e usar cores quando executada em um dispositivo com um display maior e colorido.
6. Flexibilidade na composio dos componentes dos formulrios. importante
que o framework contenha funcionalidades que permitam ao engenheiro de software definir
o layout dos componentes, como cores e alinhamento. Desta forma, ele pode construir
interfaces mais amigveis com usurio.
7. Extensibilidade para criao de novos componentes grficos. O framework deve
conter Hot Spots que possibilitem a fcil insero de novos componentes para atender a
novas funcionalidades desejadas pelo engenheiro de software.
8. Facilidade no uso. A nomenclatura dos componentes de interface do framework
deve ser intuitiva para facilitar a instanciao dos componentes. Alm disso, as funes de
composio de formulrios devem ser de fcil uso e o framework deve ser documentado pra
facilitar a aprendizagem.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
52
Captulo 4
_______________________________________________________________________________________________________________________________________
O framework XFormUI atende parcial ou totalmente cada um desse requisitos

apresentados, como ser descrito na prxima seo.
4.3. Framework XFormUI

Para atender os requisitos apresentados e facilitar o processo de gerao de cdigo da
ferramenta UIG, o framework XFormUI foi projetado para conter componentes que
tivessem o mesmo nome e comportamento dos componentes do XForms. Essa escolha
deve-se ao fato de o XForms j atender os requisitos 1, 2, 4, 6 e 8, o que facilita a
construo do framework XFormUI.
No Captulo 3, foi explicado que o estudo e generalizao das caractersticas comuns
de um domnio deve ser utilizado na construo de um framework. Contudo, somente esta
estratgia de generalizao insuficiente para que o XFormUI possa satisfazer todos os
requisitos apresentados anteriormente. Assim, alm da generalizao, outras trs estratgias
foram utilizadas na construo do framework XFormUI: transparncia, especificidade e
combinao de componentes . Essas estratgias e a generalizao so descritas, a seguir:
Generalizao. Para que o framework pudesse ser implementado em vrias
plataformas, as caractersticas comuns foram capturadas e generalizadas. A generalizao

acontece principalmente em relao estrutura das classes principais das plataformas que
so instanciadas no incio da aplicao (e.g., Midlet em J2ME MIDP, MainWindow em
Superwaba). Outro exemplo de generalizao usado no framework o gerenciamento de
eventos que contm apenas os eventos comuns s plataformas investigadas.
Transparncia. Todos os mtodos contidos nas classes do framework
abstraem da aplicao o modo pelo qual so instanciadas as APIs de cada plataforma para
criar os componentes, montar a interface, disparar eventos e exibir mensagens de alerta.
Como mencionado no Captulo 3, essa estratgia permite a construo de aplicaes para
executar em qualquer plataforma na qual o framework implementado.
Especificidade. Para que o framework pudesse atender aos requisitos 5 e 6,
funes que no correspondem a caractersticas comuns das plataformas foram adicionadas

ao framework. Estas funes esto principalmente relacionadas ao gerenciamento de layout
que pode no ser possvel de ser executado em certas plataformas de programao como
J2ME MIDP 1.0. No caso em que funcionalidades no so possveis de serem
_______________________________________________________________________________________________________________________

Dispositivos Mveis
53
Captulo 4
_______________________________________________________________________________________________________________________________________
implementadas por completo em uma plataforma de programao, as implementaes dos

mtodos correspondentes no framework podem no executar nada ou executar aquilo que se
predispe de forma parcial. Um exemplo dessa estratgia so os mtodos para mudana de
cores dos componentes que, na implementao em J2ME MIDP 1.0, no tm nenhum
cdigo para execuo. Isto acontece devido a essa plataforma no suportar mudana de
cores paras os componentes da API. A vantagem do uso dessa estratgia que a aplicao
executada da melhor forma em cada uma das plataformas (e.g., se a plataforma suporta
cores, os componentes da aplicao ficam coloridos).
Combinao de Componentes. Nem todos os componentes existentes no
XForms tm componentes correspondentes que executam o mesmo comportamento nas

plataformas de programao. Nesses casos, componentes das plataformas so combinados
para construir o componente do XFormUI.
Na Figura 11, apresentada uma viso geral do XFormUI que dividido em quatro
partes: Formulrios; Ncleo e Eventos; Componentes; e Validao e Restrio.
Trs tipos de formulrios podem ser construdos com o framework XFormUI:
TextArea, Select1Full e XForm. O TextArea corresponde a um formulrio com uma nica
caixa de texto que deve ocupar toda a tela do dispositivo. O Select1Full um formulrio
com um menu para escolha de uma nica opo. O XForm, por sua vez, corresponde ao
formulrio padro ao qual podem-se adicionar vrios componentes (e.g., campos de entrada
de dados, componentes de escolha de opes).
A parte de Ncleo e Eventos contm as trs principais classes do framework:
MainXFform, XFormItem e Trigger. O MainXForm a classe que define a estrutura
principal da aplicao e a primeira classe a ser executada no incio de uma aplicao.
Todos os componentes que podem ser adicionados a um formulrio XForm herdam da
classe XFormItem. O Trigger define um gatilho para disparar aes e pode ser adicionado
aos trs tipos de formulrios descritos anteriormente.
A parte Validao e Restrio composta pelas classes que permitem ao engenheiro
de software definir restries entrada de dados nos componentes e testar se os dados no
violam essas restries. As classes StringRestriction, StringValidator, BindRestriction,
BindValidator, NumberRestriction e NumberValidator compem esta parte e so descritas
em detalhes nas prximas sub-sees.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
54
Captulo 4
_______________________________________________________________________________________________________________________________________
Figura 11 - Framework XFormUI

A parte Componentes composta pelas oito classes disponibilizadas pelo framework
para construo de formulrios do tipo XForm. Essas classes em conjunto permitem a
entrada de dados, como texto, datas e senhas; a exibio de textos e imagens, e a seleo de
opes. Esses componentes, juntamente com a classe Trigger, atendem quase totalmente
ao requisito 1 apresentado na seo 4.2, pois o framework XFormUI s no contm
componentes para exibio de tabelas de dados.
Nas sub-sees seguintes so descritas em detalhes cada uma dessas classes e seus
mapeamentos e implementaes nas plataformas Superwaba, J2ME MIDP 1.0 e 2.0.
4.3.1.
MainXForm
Como mencionado no Captulo 2, a estrutura de uma aplicao em J2ME MIDP 1.0 e 2.0
diferente da estrutura de uma aplicao em Superwaba. Em J2ME MIDP, a classe principal
de uma aplicao herda da classe Midlet e deve reescrever os mtodos startApp() e
destroyApp(boolean typeExit) que correspondem, respectivamente, a inicializao da
aplicao e as funes a serem executadas antes de sua sada. J em Superwaba, a classe
principal de uma aplicao herda da classe MainWindow e deve reescrever o mtodo
onStart() que disparado no incio da execuo. Portanto, para criar uma estrutura que
_______________________________________________________________________________________________________________________

Dispositivos Mveis
55
Captulo 4
_______________________________________________________________________________________________________________________________________
possa ser implementada nessas plataformas, o framework XFormUI disponibiliza a classe

MainXForm que generaliza os mtodos dessas plataformas.
A classe MainXForm uma classe abstrata que contm os mtodos onStart() e
onExit(boolean typeExit) que devem ser reescritos pelo engenheiro de software para definir
o que ocorre ao iniciar aplicao e ao sair dela. A classe MainXForm disponibiliza,
tambm, o mtodo setCurrentForm() que permite a troca rpida entre formulrios da
aplicao e abstrai como ocorre a mudana de formulrios nas plataformas.
A classe MainXForm implementa os mtodos obrigatrios das estruturas de cada
plataforma e mapeia suas chamadas para os mtodos abstratos que devem ser escritos pelo
engenheiro de software. Na Tabela 4, podem ser vistos os cdigos de implementao do
MainXForm nas plataformas. No caso do J2ME MIDP, os mtodos startApp() e
destroyApp() invocam, respectivamente, os mtodos abstratos onStart() e onExit(). E no
caso do Superwaba, apenas o mtodo onExit() mapeado, uma vez que a prpria
plataforma j exige o mtodo onStart(). Na Tabela 4, pode ser visto tambm, como a classe
MainXForm abstrai a forma de mudana de formulrios.
Implementao em J2ME MIDP
public abstract class MainXForm extends MIDlet{
protected void startApp(){
onStart();
}
protected void destroyApp(boolean arg0) {
onExit(arg0);
}
public void setCurrentForm(XForm xform){
xform.addComponents();
Display.getDisplay(this).setCurrent(xform);
}
public abstract void onStart();
public abstract void onExit(boolean arg);
}
Implementao em SuperWaba
public abstract class MainXForm extends
MainWindow{
public MainXForm(){
super("",TAB_ONLY_BORDER);
this.setDoubleBuffer(true);
}
public void setCurrentForm(XForm xform){
swap(xform);
}
public void onExit(){
onExit(false);
}
public abstract void onExit(boolean arg);
}}
Tabela 4 - Cdigos do MainXForm nas plataformas
4.3.2.
Formulrios
Como mencionado anteriormente, o framework XFormUI disponibiliza ao engenheiro de

software trs tipos de formulrios: Select1Full, XForm e TextArea. Esses formulrios tm,
em comum, um mtodo para exibio de mensagens de alerta, o showAlert(). Alm disso,
como mencionado anteriormente, a classe MainXForm disponibiliza um mtodo que
possibilita a fcil troca entre esses formulrios para estabelecer o formulrio corrente da
_______________________________________________________________________________________________________________________

Dispositivos Mveis
56
Captulo 4
_______________________________________________________________________________________________________________________________________
aplicao. Desta forma, esse mtodo, em conjunto com o showAlert(), faz com que o
framework XFormUI atenda ao requisito 3 especificado na seo 4.2.
Outra caracterstica comum entre esses formulrios a possibilidade de adio de
Triggers para disparar eventos de ao. Os Triggers so mapeados para a classe Button na
implementao em Superwaba e para a classe Command em J2ME MIDP 1.0 e 2.0. No
caso do mtodo showAlert(), a implementao em Superwaba instancia e exibe um
MessageBox, enquanto em J2ME MIDP a implementao utiliza uma instncia da classe
Alert. A seguir, descrito em detalhes cada um desses formulrios.
4.3.2.1.
Select1Full
O Select1Full um formulrio para exibio de opes das quais o usurio pode escolher
somente uma. O Selec1Full pode receber em seu construtor uma lista de opes e um ttulo
para ser exibido no topo do formulrio. A esta classe, apenas um tipo de componente pode
ser adicionado, o Trigger. Essa adio acontece atravs do mtodo add que pode receber
tambm diretivas de layout como alinhamento e mudana de linha no display.
Para que o engenheiro de software possa utilizar um Select1Full, ele precisa escrever
uma subclasse dessa classe. Essa subclasse deve implementar os mtodos triggerEvent() e
selectEvent() que permitem o gerenciamento dos eventos de aes, respectivamente, sobre
o Trigger e sobre a lista de opes.
O Select1Full foi mapeado em J2ME MIDP 1.0 e 2.0 para a classe List que tm
exatamente o mesmo comportamento de escolha de opes e eventos de seleo. No caso
do Superwaba, um componente foi criado atravs da combinao das classes Container e
ListBox. Vale ressaltar que as diretivas de layout dos Triggers funcionam apenas em
Superwaba, j que no se pode atribuir alinhamento aos Commands em J2ME.
4.3.2.2. TextArea
O TextArea um formulrio para exibio e edio de textos. Ele pode receber em seu
construtor um texto e um ttulo. esta classe, assim como acontece com Select1Full,
apenas um tipo de componente pode ser adicionado, o Trigger. Para que o engenheiro de
software possa utilizar um TextArea, ele precisa escrever uma subclasse dessa classe. Ao
contrrio do Select1Full, essa subclasse deve implementar apenas o mtodo triggerEvent. O
TextArea foi mapeado em J2ME MIDP 1.0 e 2.0 para a classe TextBox que permite a edio
_______________________________________________________________________________________________________________________

Dispositivos Mveis
57
Captulo 4
_______________________________________________________________________________________________________________________________________
e exibio de textos. No caso do Superwaba, um componente foi criado atravs da

combinao das classes Container e Edit.
Na Tabela 5, apresentado um cdigo de um formulrio que utiliza o framework
XFormUI para construir um TextArea. Uma subclasse foi criada e o mtodo triggerEvent
foi escrito. Nesse evento, um alerta exibido caso uma ao seja disparada sobre o Trigger
de alerta e o tamanho do texto no TextArea seja maior que 50 caracteres. Na Tabela 5,
tambm podem ser visualizadas as telas do processo descrito.
Cdigo em XFormUI
Telas no J2ME MIDP 2.0
import org.great.xform.ui.TextArea;
import org.great.xform.ui.Trigger;
public class FormComentar extends TextArea{
//Trigger(s)
Trigger trgAlerta;
FormComentar(MainXForm mainXForm){
public void triggerEvent(Trigger trig) {

if(trig==trgAlerta){
if(this.getValue().length()>50){
this.showAlert("No permitido texto
com mais de 50 caracteres!!!");
}}
}
Tabela 5 - TextArea, Triggers e o showAlert() em J2ME MIDP 2.0
4.3.2.3. XForm
O XForm o formulrio padro correspondente ao comportamento de um formulrio
XForms. A ele podem ser adicionados Triggers e qualquer componente que herde de
XFormItem. Assim como nos outros formulrios, a adio acontece atravs do mtodo add
que recebe diretivas de layout como alinhamento e mudana de linha no display. A
diferena que essas diretivas funcionam para os componentes que herdam de XFormItem
tanto em Superwaba como em J2ME MIDP 2.0.
O XForm implementado em J2ME MIDP estendendo a classe Form. No caso do
MIDP 2.0, ele utiliza as diretivas de layout da classe Item para adicionar os componentes.
Essas diretivas permitem alinhar os componentes esquerda, ao centro e direta e
determinam se um ou mais componentes esto na mesma linha do formulrio. No
Superwaba, o XForm estende a classe Container e utiliza as diretivas da classe Control para
adicionar os componentes.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
58
Captulo 4
_______________________________________________________________________________________________________________________________________
4.3.3.
Validaes e Restries
Para atender o requisito de disponibilizar mecanismos para validao e restrio das

entradas de dados nos formulrios (i.e., requisito 2), o framework contm as classes
StringRestriction, StringValidator, BindRestriction, BindValidator, NumberRestriction e
NumberValidator.
A classe StringRestriction permite atribuir aos componentes de entrada de dados
Input, Secret e TextArea as seguintes restries: nmero exato, tamanho mximo e mnimo
de caracteres. A classe StringValidator disponibiliza um mtodo que valida se uma cadeia
de caracteres atende s restries impostas em um objeto StringRestriction.
A classe BindRestriction permite associar restries de valor requerido (i.e., required)
ou de proibio de entrada de dados (i.e., readonly) para os componentes Input, Secret e
TextArea. Essas restries so passadas no incio da construo desses componentes, pois
influenciam na forma como eles so mapeados para as plataformas de programao. A
classe BindValidator testa se a restrio de required est cumprida em um componente.
A classe NumberRestriction permite atribuir ao componente Input as seguintes
restries na entrada de dados numricos: se o nmero inteiro ou decimal, o nmero exato
de dgitos, valores mximos e mnimos que o nmero pode assumir.
A classe
NumberValidator testa se uma cadeia de caracteres (i.e., String) segue as restries

impostas pelo NumberRestriction.
Os componentes Input, Secret e TextArea disponibilizam uma funo que dispara a
checagem das restries, o mtodo isValid(). Este mtodo retorna verdade (i.e., true) se o
valor contido no campo de entrada de dados satisfaz todas as restries. Na Tabela 6,
apresentado o cdigo reescrito do TextArea descrito na Tabela 5, utilizando as funes de
validao disponibilizadas pelo framework. No construtor do formulrio FormComentar,
so chamados os mtodos de restrio do tipo BindRestriction e StringRestriction (i.e.,
setRequired e setMaxlength). A checagem de validao acontece agora atravs do uso do
mtodo isValid() implementado pelo framework.
public class FormComentar extends TextArea{
//Trigger(s)
Trigger trgAlerta;
FormComentar(MainXForm mainXForm){
//Restries
this.setRequired(true);
_______________________________________________________________________________________________________________________

Dispositivos Mveis
59
Captulo 4
_______________________________________________________________________________________________________________________________________
this.setMaxLength(50);
}
public void triggerEvent(Trigger trig) {
if(trig==trgAlerta){
if(this.isValid()){
this.showAlert("No permitido texto vazio ou
com mais de 50 caracteres!!!");
}}}
Tabela 6 - Cdigo do TextArea apresentado na Tabela 5 usando as classes de validao
4.3.4.
XFormItem e Componentes
O framework XFormUI disponibiliza componentes para a construo de formulrios do

tipo XForm. Todos esses componentes so subclasses da classe abstrata XFormItem e
devem implementar os mtodos: getValue(), setValue(String s), setLabelForeColor() e
setLabelBackColor(), definidos como abstratos na classe XFormItem. Os dois primeiros
mtodos definem modificadores sobre o contedo do componente, permitindo alterar e
recuperar o valor existente. A semntica desse valor depende da implementao de cada
componente que herda de XFormItem. Por exemplo, em um Input, esses mtodos
modificam e acessam o texto inserido no componente pelo usurio, enquanto no Select1,
esses mtodos modificam e acessam o item selecionado.
Os mtodos setLabelForeColor() e setLabelBackColor() devem permitir que as cores
dos labels dos componentes possam ser modificadas. Esses mtodos recebem como
parmetros trs inteiros que representam as componentes de uma cor no modelo de cores
aditivo RGB (i.e., red, green e blue). Como mencionado anteriormente, na plataforma
J2ME MIDP 1.0, esses mtodos no possuem nenhum cdigo, uma vez que, no possvel
modificar as cores dos labels dos componentes nessa plataforma.
Na plataforma J2ME MIDP 1.0, o XFormItem contm uma instncia de Item, classe
da API padro do J2ME. No caso do J2ME MIDP 2.0, o componente XFormItem contm
um ColorLabel, uma classe tambm proposta nessa dissertao, e um Item. A plataforma
J2ME MIDP 2.0 no contm nenhuma classe que permita a adio de cores a componentes,
contudo, disponibiliza a classe CustomItem para a construo de componentes
costumizveis.
Assim, o ColorLabel foi construdo para exibir cadeias de caracteres coloridos no
display do dispositivo. No Superwaba, o componente XFormItem contm um Label e um
Control, classes j disponibilizadas na API da plataforma. Os mtodos de mudana de cores
_______________________________________________________________________________________________________________________

Dispositivos Mveis
60
Captulo 4
_______________________________________________________________________________________________________________________________________
so mapeados para os mtodos disponibilizados pela plataforma para mudana de cores dos
componentes: setForeColor() e setBackColor().
O framework XFormUI disponibiliza oito componentes que herdam de XFormItem:
Secret, Output, SelectBoolean, Select1, Select, XFormImage, Range e Input. Esses
componentes so descritos em detalhes a seguir.
4.3.4.1. Secret e Output

O Secret permite a entrada de textos e exibe para cada caractere digitado um * e
utilizado para entrada de senhas. Como mencionado anteriormente, a esse componente
podem ser relacionadas s restries do tipo BindResctriction e StringRestriction.
O Secret contm em J2ME MIDP 1.0 e 2.0 uma instncia da classe TextField com a
restrio TextField.PASSWORD, enquanto em Superwaba, o Secret contm um Edit com a
restrio Edit.PASSWORD.
O Output, por sua vez, permite a exibio de textos que no podem ser editados. Esse
componente o nico do XFormUI que permite que toda a cor de seu contedo seja
modificada pelo engenheiro de software.
Em J2ME MIDP 1.0, o Output instancia um StringItem, enquanto no MIDP 2.0
instancia o ColorLabel provido pelo framework. Em Superwaba, a classe instancia um
Label.
4.3.4.2. SelectBoolean, Select1, Select

Esses trs componentes so utilizados para escolha de opes. No SelectBoolean,
apresentada uma nica opo de escolha. No Select1 e no Select so disponibilizadas vrias
opes. No caso do Select1, apenas uma pode ser escolhida.
Em J2ME MIDP 1.0 e 2.0, esses componentes so mapeados para o ChoiceGroup. O
SelectBoolean e Select1 utilizam a restrio Choice.Exclusive para explicitar que apenas
uma opo pode ser escolhida. Enquanto, o Select usa a restrio Choice.Multiple. Em
Superwaba, esses componentes so mapeados para, respectivamente, o Check, o ComboBox
e o ListBox.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
61
Captulo 4
_______________________________________________________________________________________________________________________________________
4.3.4.3. XFormImage e Range

O XFormImage define um componente para exibio de imagens. No J2ME MIDP 1.0 e
2.0, o XFormImage composto pelas classes da API do J2ME, ImageItem e Image. No
MIDP 2.0, elas permitem a exibio de imagens dos tipos JPG, PNG e GIF. No MIDP 1.0,
como mencionado no Captulo 2, apenas o formato de imagem PNG suportado. No caso
do SuperWaba, o XFormImage contm as classes da API Image e Button que permitem a
exibio de imagens nos formatos BMP, PNG, JPG e GIF.
O Range permite a escolha de um valor dentro de um intervalo de valores. Em J2ME
MIDP, ele instancia a classe Gauge e em Superwaba, instancia a classe ScroollBar. A
implementao do mtodo getValue() do Range
retorna o valor escolhido dentro do
intervalo que estabelecido durante a instanciao de um Range.
4.3.4.4. Input
Esse componente permite a entrada de dados numricos, texto, datas e horas. Durante a sua
construo, o engenheiro de software informa que tipo de restrio aplicada para filtrar a
entrada dos dados. Ele pode escolher as seguintes restries: NUMERIC, DECIMAL,
STRING, DATE, DATE_TIME, TIME.
Contudo, essas restries de filtragem podem no ser possveis de executar em certas
plataformas de programao. Nesses casos a checagem ocorre durante a execuo do
mtodo isValid().
Essas restries tambm influenciam em quais componentes o Input instancia durante
a execuo da aplicao. Na Tabela 7, so apresentadas as formas como essas instanciaes
acontecem em cada plataforma na qual o framework foi implementado. Entre o J2ME
MIDP 1.0 e MIDP 2.0 uma nica diferena acontece na instanciao, no MIDP 1.0 a
restrio DECIMAL do Input se transforma em uma restrio do tipo TextField.ANY, pois
no existem restries em MIDP 1.0 para entrada somente de valores decimais nos campos
do tipo TextField.
Como mencionado no Captulo 3, isso acontece devido a inexistncia de suporte a
ponto flutuante na plataforma. Como em MIDP 2.0, j existe o suporte a ponto flutuante,
uma restrio para entrada de valores decimais nos TextField disponibilizada, a
_______________________________________________________________________________________________________________________

Dispositivos Mveis
62
Captulo 4
_______________________________________________________________________________________________________________________________________
TextField.DECIMAL. No caso da restrio est relacionada a tempo ou a datas, o Input

instancia um objeto da classe DateField disponibilizada pela API do J2ME MIDP.
Restrio
NUMERIC
J2ME MIDP 1.0

TextField com
restrio
TextField.NUMERIC
J2ME MIDP 2.0

TextField com
restrio
TextField.NUMERIC
Superwaba
Edit com restrio
Edit.CURRENCY e
caracteres vlidos
"0123456789-+"
DECIMAL
TextField com
restrio
TextField.ANY
TextField com
restrio
TextField.DECIMAL
Edit com restrio

Edit.CURRENCY e
caracteres vlidos
"0123456789.,-+"
STRING
TextField com
restrio
TextField.ANY
TextField com
restrio
TextField.ANY
Edit com restrio

Edit.NORMAL
DATE
DateField com
restrio DateField.
DATE
DateField com
restrio DateField.
DATE
Edit com restrio

Edit.DATE
DATE_TIME
DateField com
restrio DateField.
DATE_TIME
DateField com
restrio DateField.
DATE_TIME
Edit com restrio

Edit.NORMAL e
caracteres vlidos
"0123456789/:"
TIME
DateField com
restrio DateField.
TIME
DateField com
restrio DateField.
TIME
Edit com restrio

Edit com restrio
Edit.NORMAL e
caracteres vlidos
"0123456789:
Tabela 7- Restries de filtragem e componentes instanciados nas plataformas
No caso do Superwaba, em todos os tipos de restrio, apenas um tipo de componente

da plataforma instanciado, o Edit. As restries so implementadas na plataforma atravs
do tipo do componente Edit e da mscara de filtragem aplicada aos caracteres. As mscaras
para cada restrio do Input so apresentadas na Tabela 7. Vale ressaltar, que ao contrrio
do J2ME MIDP, no qual j existe um componente para permitir entrada de data e hora que
exibe um calendrio, no Superwaba a classe Edit apenas filtra a entrada de texto. Assim,
para que um Input do tipo DATE tivesse o mesmo comportamento nas trs plataformas,
_______________________________________________________________________________________________________________________

Dispositivos Mveis
63
Captulo 4
_______________________________________________________________________________________________________________________________________
uma chamada automtica ao Calendar, classe da API do Superwaba que exibe um

calendrio, foi escrita dentro da classe XForm.
Na Figura 12, podem ser vistos um formulrio com os componentes Output, Secret,
Select1, SelectBoolean e um Input com a restrio do tipo DATE sendo executados nas trs
plataformas. ainda exibido na figura o uso de cores e alinhamento dos componentes,
assim como a execuo da abertura de uma janela para escolha de uma data no componente
Input.
Figura 12 - Telas dos componentes nas plataformas
4.3.5.
Hot Spots e Classes do XFormUI
Na Tabela 8, so apresentadas as classes que compem o framework XFormUI e uma viso

geral do seus mapeamentos para as trs plataformas. Essas classes em conjunto oferecem
uma boa quantidade de componentes que permitem a construo da maioria dos
formulrios desejados em uma aplicao para dispositivos mveis. Alm disso, Hot Spots
so disponibilizados para o engenheiro de software construir seus prprios componentes.
Para que esse novo componente seja adicionado a um XForm, suficiente que ele estenda a
classe XFormItem e implemente os mtodos abstratos definidos nela. Desta forma, o
framework tambm atende ao requisito 7 de extensibilidade apresentado na seo 4.2.
XFormUI
MainXFform
XForm
Select1Full
J2ME MIDP 1.0

Midlet
Form
List
J2ME MIDP 2.0

Midlet
Form
List
TextArea
TextBox
TextBox
XFormItem
Contm um Item
Contm um Item e um
Superwaba
MainWindow
Container
Container com um
ListBox
Container com um
ListBox
Contm um Control e
_______________________________________________________________________________________________________________________

Dispositivos Mveis
64
Captulo 4
_______________________________________________________________________________________________________________________________________
Secret
Input
Output
Select1
Select
SelectBoolean
XFormImage
Trigger
Range
triggerEvent()
ColorLabel
Contm um TextField Contm um TextFied
e um ColorLabel
Pode conter um
Contm um
TextField ou um
ColorLabel e pode
DateField dependendo conter um TextField
da restrio
ou um DateField
dependendo da
restrio
Contm um StringItem Contm um StringItem
e um ColorLabel
Contm um
Contm um
ChoiceGroup com
ColorLabel e um
restrio Exclusive
ChoiceGroup com
restrio Exclusive ou
Popup
Contm um
Contm um
ChoiceGroup com
ColorLabel e um
restrio Multiple
ChoiceGroup com
restrio Multiple
Contm um
Contm um
ChoiceGroup com
ColorLabel e um
restrio Exclusive e
ChoiceGroup com
um nico item
restrio Exclusive e
um nico item
Contm um
Contm um
ImageItem e um
ImageItem e um
Image
Image
Estende Command
Estende Command
Contm um Gauge
Contm um
ColorLabel e um
Gauge
commandAction()
commandAction()
um Label
Contm um Edit e um
Label
Contm um Edit e um
Label. No caso da
restrio de tipo ser
date, um Calendar
aberto ao se clicar no
Input
Contm um Label
Contm um Label e
um ComboBox ou um
RadioGroup ou um
ListBox dependendo do
tipo do Select1
Contm um Label e
um ListBox
Contm um Label e
um Check
Contm um Image e
um Button
Estende Button
Contm um ScrollBar
onEvent()
Tabela 8 - Classes que compem o XFormUI e seus mapeamentos nas plataformas
4.4. Concluso
Neste Captulo foi apresentado o framework XformUI que permite a construo de
interfaces grficas adaptativas e multi-plataformas para dispositivos mveis. O framework
contm vrios componentes de interface e facilita a construo de formulrios com recursos
de validao de dados e layout para os componentes. As implementaes do framework em
J2ME MIDP1.0/CLDC 1.0, J2ME MIDP2.0/CLDC1.1 e Superwaba proporcionam a
execuo das aplicaes em trs plataformas distintas.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
65
Captulo 4
_______________________________________________________________________________________________________________________________________
Assim, de acordo com as definies de adaptao apresentadas no Captulo 2, o

framework prov adaptao descrio em tempo de construo da interfaces das
aplicaes. Contudo, o engenheiro de software ainda tem que escrever cdigo para compor
os formulrios e realizar as aes de validao. Alm disso, algumas funcionalidades do
framework no funcionam em certas plataformas de programao (e.g., mudana de cores
no J2ME MIDP 1.0), o que representa um desperdcio de cdigo, j que chamadas de
mtodos so executadas em vo (e.g., setLabelForeColor() no J2ME MIDP 1.0/CLDC 1.0).
Dessa forma, para evitar que mtodos que no executam cdigo sejam invocados e
para agilizar a criao de interfaces que utilizem o framework XFormUI apresentada a
ferramenta UIG no prximo captulo. Essa ferramenta permite ao engenheiro de software
descrever as interfaces de uma aplicao usando uma linguagem declarativa, e com essa
descrio, a ferramenta gera cdigo que utiliza o framework XformUI.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
66
Captulo 5
_______________________________________________________________________________________________________________________________________
5. User Interface Generator

Neste captulo, apresentada a ferramenta de gerao de cdigo User Interface Generator
(UIG) proposta nesta dissertao. Essa ferramenta gera cdigo dos formulrios de uma
aplicao a partir de uma descrio inicial desses formulrios em uma linguagem de
marcao.
Na Seo 5.1, apresentada uma viso geral da ferramenta UIG. Na Seo 5.2,
descrita a linguagem suportada pela ferramenta. Na Seo 5.3, so apresentadas as regras
de mapeamento dos documentos para o framework XFormUI. Na Seo 5.4, descrito o
processo de gerao de cdigo. Na Seo 5.5, detalhada a estrutura do cdigo gerado. Por
fim, na Seo 5.6 apresenta o plugin
do eclipse construir para auxiliar o uso da
ferramenta UIG.
5.1. Viso geral da ferramenta User Interface Generator

Conforme mencionado no Captulo 2, um dos desafios do desenvolvimento de aplicaes
para DMs consiste na descrio, independente de plataforma ou dispositivo, da interface
com usurio das aplicaes. O framework XFormUI soluciona em parte esse desafio, visto
que, possibilita a construo de interfaces vinculadas ao framework e no a uma
determinada plataforma. Alm disso, as diretivas de cores e alinhamento disponibilizadas e
implementadas pelo XFormUI so independentes de dispositivo.
Contudo, para utilizar o framework o engenheiro de software ainda escreve cdigo
para montar as interfaces e para disparar os eventos que executam a validao dos dados.
Com o objetivo de agilizar esse processo de construo de interfaces e permitir que o
engenheiro de software utilize uma linguagem declarativa para descrever as restries dos
dados e as interfaces, essa dissertao apresenta a ferramenta User Interface Generator
(UIG).
Na Figura 13, apresentada uma viso geral dessa ferramenta. A UIG permite ao
engenheiro de software descrever os formulrios de uma aplicao utilizando o XForms
para definir os componentes, o CSS para definir o estilo (i.e., cores) e o XML Schema para
definir restries aos campos de entrada de dados do formulrio. O engenheiro cria um
documento XML, o Manifest.xml, que define quais formulrios sero mapeados e para qual
_______________________________________________________________________________________________________________________

Dispositivos Mveis
67
Captulo 5
_______________________________________________________________________________________________________________________________________
plataforma o cdigo ser gerado. Ele dispara a ferramenta UIG e esta, por sua vez, gera o
cdigo dos formulrios utilizando o framework XFormUI.
Para criar esse Manifest.xml, o engenheiro pode utilizar o plugin para a ferramenta
livre Eclipse [37] disponibilizado pelo ambiente proposto nesta dissertao. Esse plugin
permite a construo do Manifest.xml de forma grfica e tambm dispara o processo de
gerao de cdigo da ferramenta.
Figura 13 - Viso geral da ferramenta UIG
A ferramenta realiza essa gerao de cdigo utilizando XSL [36] (i.e., eXtensible
Stylesheet Language). Essa linguagem de marcao baseada em XML permite a criao de
folhas de estilo ou documentos de transformao chamados de XSLT (i.e., XSL
Transformation). O XSLT permite a definio de regras de mapeamento das tags de um
documento XML para uma outra descrio. Com XSLT, possvel converter um
documento XML em outros documentos XML, em arquivos texto ou em documentos
HTML. A vantagem do uso do XSLT decorre da existncia de vrios processadores ou
parsers XSL, capazes de realizar a transformao a partir de dois documentos: o
documento XML original e o documento XSLT de transformao.
O cdigo dos formulrios gerados pela ferramenta seguem um modelo semelhante ao
MVC (i.e., Model/Viewer/Controller) [41]. Para cada formulrio, trs classes so geradas:
Interface, Bean e Controller.
A classe Interface define a viso do formulrio na qual esto descritos os
componentes grficos e como eles se compem para constituir o formulrio. Esses
_______________________________________________________________________________________________________________________

Dispositivos Mveis
68
Captulo 5
_______________________________________________________________________________________________________________________________________
componentes grficos utilizados so instncias das classes que fazem parte do framework
XFormUI apresentado no Captulo 4.
A classe Bean contm atributos relacionados aos campos de seleo e de entrada de
dados do formulrio, assim, essa classe corresponde ao modelo na qual esto os dados
relacionados ao formulrio. Por sua vez, a classe Controller contm mtodos de execuo
para cada Trigger existentes nos formulrios.
Esse modelo de cdigo gerado permite o desenvolvimento mais rpido das aplicaes,
pois o engenheiro se concentra na escrita dos mtodos da classe controladora que so
referentes s regras de negcio da aplicao. Na Seo 5.5, as estruturas dessas classes so
detalhadas.
5.2. Linguagem suportada pela ferramenta

Como descrito anteriormente, a ferramenta utiliza como entrada, para a gerao de
cdigo, documentos XForms, CSS e XML Schema. Para utilizar essas tecnologias na
descrio de um formulrio, o engenheiro de software utiliza um documento XHTML, no
qual esto includos as tags do XForms e as referncias aos arquivos do CSS e do XML
Schema.
Desta forma, alm de suportar essas trs tecnologias, a ferramenta UIG tambm
mapeia certas tags do XHTML, listadas a seguir:
xhtml:html, define o incio do documento;
xhtml:link. , onde est o caminho para arquivo que define o estilo do formulrio;
xhtml:head, descreve o incio do cabealho do XHTML que pode ter dois filhos:
o xhtml:title, o ttulo do formulrio;
o xforms:model, a parte Model do XForms;
xhtml:body, contm os componentes XForms e as tags XHTML;
xhtml:img, adiciona uma imagem ao formulrio;
xhtml:p, o pargrafo para separar os componentes em linhas.
Como pode ser visto, alm das tags que definem a estrutura do documento XHTML, a
ferramenta suporta a tag xhtml:img para adicionar imagens a um formulrio e o xhtml:p
para definir o layout dos componentes.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
69
Captulo 5
_______________________________________________________________________________________________________________________________________
5.2.1.
Suporte ao XForms
Como mencionado no Captulo 4, um formulrio XForms dividido em 3 partes: Model,

User Interface e Instance.
O XForms Model suportado pela UIG semelhante ao Model original do XForms,
com a restrio de que apenas um nico modelo exista em cada formulrio. Para descrever
o esquema do documento XML contido no modelo, o engenheiro de software pode
relacionar a ele um arquivo XML Schema. Essa relao acontece atravs do atributo
schema do Model.
Alm das restries impostas pelo XML Schema, que sero descritas em detalhes nas
prximas subsees, a UIG suporta tambm a tag Bind para definir restries. Esta tag
permite ao engenheiro de software associar uma restrio a um campo do modelo. As
restries suportadas pela UIG so:
Required: pode ser false() ou true() e define se um valor do modelo
obrigatrio.
Readonly: pode ser false() ou true() e define se um valor do modelo pode ser
modificado. Neste caso, o componente relacionado a esse valor do modelo torna-se
readonly.
Com relao parte User Interface do XForms, a UIG suporta todos os componentes
XForms que so descritos nessa parte do documento, exceto o upload. Os componentes
suportados, juntamente com o xhtml:img, disponibilizam ao engenheiro de software uma
variedade de componentes para a construo das interfaces de uma aplicao.
Na Tabela 9, so listados os componentes XForms suportados, sua sintaxe e a
imagem no navegador XSmiles [15].
Componente
Descrio
Sintaxe
Input
Componente <input id=inp ref=>

<label>Input:</label>
para entrada
</input>
de dados
Secret
Componente <secret id=sec ref=>

<label>Secret:</label>
para entrada
</secret>
de senhas
Select1
Componente <select1 id=sel ref="">

<label>select1:</label>
para escolha
<item>
de um entre
Imagem no XSmiles
_______________________________________________________________________________________________________________________

Dispositivos Mveis
70
Captulo 5
_______________________________________________________________________________________________________________________________________
alguns itens
<value>1</value>
<label>1st</label>
</item>
</select1>
Output
Componente <output id=out ref=>

<label>output:</label>
para
</output>
exibio de
dados
Textarea
Componente <textarea id=tex ref=>

<label>Texto:</label>
para entrada
</textarea>
de cadeias
grandes de
caracteres
Select
Componente <select id=sel ref="">

<label>select:</label>
para escolha
<item>
de itens
<value>1</value>
Selectboolean Componente
para marcar
ou no um
item
<label>1st</label>
</item>
</select1>
<selectboolean id=sb
ref=>
<label>Selectboolean:</label>
</selectboolean>
Range
Componente
para escolha
de valores
em um
intervalo
Trigger
Gatilho para <trigger id=trig>

<label>Reset</ label>
disparar
<reset/>
aes
</trigger>
Submit
Gatilho que <submit id=sub>

<label>Submit</ label>
dispara a </submit>
ao de
submisso
<range end="20" ref=""

id=rg start="1" step="1">
<label>Range:</label>
</range>
Tabela 9 - Componentes XForms Suportados
Como pode ser visto na tabela, cada componente obrigatoriamente contm o atributo
id e o n filho label, respectivamente, o identificador e o texto que exibido ao lado de
cada componente. Os componentes, exceto o trigger e o submit, possuem o atributo ref com
o caminho XPath referente ao a seu valor correspondente no Model do XForms.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
71
Captulo 5
_______________________________________________________________________________________________________________________________________
Os componentes input, secret e textarea podem possuir o n filho alert. O n alert

contm uma mensagem que exibida no caso do texto inserido no corresponder restrio
estabelecida no Bind ou no Schema para o n do modelo ao qual o componente se refere
(e.g. o texto no satisfaz a restrio integer). O componente trigger, por sua vez, pode
conter o n filho reset que indica que sua ao reinicializar os valores de todos os
componentes do formulrio.
A UIG suporta tambm dois atributos adicionais ao XForms:
O atributo maxlength para limitar o tamanho do texto a ser inserido no caso
dos componentes input, secret e textarea;

O atributo align que pode ser left, right e center que indica a posio relativa
dos componentes no display.
5.2.2.
Suporte ao XML Schema
Como mencionado anteriormente, o XML Schema utilizado no XForms para associar

restries aos campos de dados do modelo. Quando o engenheiro de software associa,
usando o atributo ref, um componente XForms a um valor do modelo, a restrio referente
a esse valor repassada para o componente.
No caso da UIG, essas restries se tornam as restries das classes de validao e
restrio do framework XFormUI. As restries do XML Schema so especfificadas
atravs do estabelecimento de tipos para os dados. Esses tipos podem ser bsicos, simples
ou complexos. Os tipos bsicos so os tipos j suportados pelo XML Schema (e.g.,
xs:string). Os tipos simples so aqueles definidos a partir dos tipos bsicos aplicando-se
restries. Os tipos complexos so definidos usando expresses regulares ou uma rvore de
ns XML. Os tipos XML Schema suportados pela UIG, so os seguintes:
Tipos bsicos:
o xs:string;
o xs:date, xs:datetime, xs:time;
o xs:integer,
xs:nonNegativeInteger,
xs:positiveInteger,
xs:integer,
xs:nonPositiveInteger, xs:negativeInteger;
o xs:decimal, xs:double.
Tipos simples:
_______________________________________________________________________________________________________________________

Dispositivos Mveis
72
Captulo 5
_______________________________________________________________________________________________________________________________________
o Base xs:string com as restries length, maxLength e minLength .

o Base xs:integer, xs:nonNegativeInteger, xs:positiveInteger, xs:integer,
xs:nonPositiveInteger, xs:negativeInteger com as restries minExclusive,
maxExclusive, minInclusive, maxInclusive.
o Base xs:decimal, xs:double com as restries minExclusive, maxExclusive,
minInclusive, maxInclusive, fractionDigits.
5.2.3.
Suporte ao Cascading Style Sheets (CSS)
O CSS utilizado no XForms para formatao de estilo das pginas e dos componentes. Na
UIG, so suportadas as modificaes das cores de todo componente, a mudana nas cores
do label e a modificao das cores do value (e.g., o texto contido em input). O uso do CSS
pode ser realizado de duas formas, listadas a seguir:
Com modificadores para todos os componentes. Nesse caso, o estilo inicia pelo
tipo de componente ao qual ele est associado (e.g., input{...} para todos os inputs);
Com a criao de classes. Nesse caso, um novo estilo criado no CSS (e.g., texto
{...}). No XForms, o engenheiro de software associa essa nova classe de estilo, usando o
atributo class, em cada componente que desejar.
Na Tabela 10, so apresentados exemplos de como o CSS pode ser usado para
modificar estilo de cores nos componentes XForms.
Descrio
Atributos
Modificar atributos
de todos os
componentes de um
tipo (e.g., todos os
inputs)
Modificar atributos
do label de todos os
componentes de um
tipo
Modificar atributos
do value de todos os
componentes de um
tipo
Sintaxe
Backgroundcolor e
Color dos
componentes
input{
background-color:
rgb(255,255,100);
color: #AAAAAA
}
Backgroundcolor e
Color do label
input>label{
background-color: #000000;
color:
rgb(255,255,255);
}
Backgroundcolor e
Color do value
select1::value{
background-color: #FFFFFF;
color:
rgb(155,0,0);
}
Imagem no
XSmiles
Tabela 10 - Exemplo de estilos do CSS suportados pela UIG

_______________________________________________________________________________________________________________________

Dispositivos Mveis
73
Captulo 5
_______________________________________________________________________________________________________________________________________
5.3. Regras de mapeamento para as plataformas

Como mencionado no Captulo 4, o XForms foi escolhido como fonte de nomes dos
componentes XFormUI para facilitar o mapeamento realizado pela ferramenta UIG. Dessa
forma, os mapeamentos, em sua maioria, acontecem de componentes XForms para
componentes de mesmo nome em XFormUI.
Os casos em que esse mapeamento no acontece de forma direta so os seguintes:
Componente submit. Esse componente XForms mapeado para o componente
XFormUI Trigger e uma funo que checa se todos os dados do formulrio so vlidos
chamada no evento desse gatilho de ao.
Componente textarea. Nos casos em que o formulrio contm um textarea e
outros componentes diferentes do trigger, o seu mapeamento depende da plataforma de

programao. Se as plataformas desejadas forem J2ME MIDP 1.0 ou 2.0, o componente
mapeado para o formulrio TextArea e os componentes diferentes de triggers so
descartados na gerao do cdigo. Se o mapeamento for para Superwaba, o textarea
mapeado para um Input e os outros componentes so adicionados ao formulrio. O
mapeamento de textarea para TextArea s ocorre em Superwaba quando apenas triggers e
um textarea so descritos no XForms.
Componente select1 com atributo appearance=full. O mapeamento desse
componente depende da plataforma de programao quando o formulrio contm um

select1 com atributo appearance=full e outros componentes diferentes do trigger. Se as
plataformas desejadas forem J2ME MIDP 1.0 ou 2.0, o componente mapeado para o
formulrio Select1Full e os componentes diferentes de triggers so descartados na gerao
do cdigo. Se o mapeamento for para Superwaba, o select1 mapeado para um Select1 e os
outros componentes so adicionados ao formulrio. O mapeamento de Componente select1
com atributo appearance=full para Select1Full s ocorre em Superwaba quando apenas
triggers e um select1 so descritos no XForms.
As restries impostas pelo XML Schema e pela Bind se transformam em chamadas
dos mtodos dos componentes do XFormUI que implementam essas restries. Por
exemplo, se existe um Bind de required=true no XForms, essa restrio mapeada para
_______________________________________________________________________________________________________________________

Dispositivos Mveis
74
Captulo 5
_______________________________________________________________________________________________________________________________________
a chamada do mtodo setRequired() do componente associado a essa restrio (e.g., um

Input).
As diretivas de alinhamento adicionadas ao XForms (i.e., o atributo align) e os estilos
do CSS so mapeados para as funes do framework XFormUI que permitem esse mesmo
comportamento. Caso o mapeamento seja feito para uma plataforma que no possu
diretivas de layout e os mtodos do framework no contenham nenhum cdigo a ser
executado (e.g., mudana de cor no J2ME MIDP 1.0), o mapeamento das diretivas de
layout no realizado.
5.4. Processo de gerao de cdigo

Na Figura 14, apresentado o processo de gerao de cdigo da ferramenta UIG.
Como mencionado anteriormente, a ferramenta utiliza XSLT para realizar as
transformaes dos documentos XMLs para cdigo Java que estende o framework
XFormUI. Contudo, uma das entradas da ferramenta um documento CSS que no
baseado no padro XML.
Assim, para realizar o processo de mapeamento, o primeiro passo transformar o
CSS em um documento XML. Para isso, foi criado um Document Type Definition (DTD)
que especifica um documento XML para suportar os parmetros de um documento CSS, o
XCSS. Aps a gerao do XCSS, esse documento, em conjunto com o documento XForms
e o XML Schema, so transformados para um documento intermedirio o
XMLMiddleForm.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
75
Captulo 5
_______________________________________________________________________________________________________________________________________
Figura 14 - Processo de gerao de cdigo
O XMLMiddleForm a forma cannica definida pelo UIG para facilitar o

mapeamento para as plataformas de programao. Os documentos so primeiramente
transformados para XmlMiddleForm e depois de XMLMiddeForm para as plataformas de
programao. Essa abordagem a aplicao do padro de gerao de cdigo Meta-Model,
descrito em [102], que tem como vantagem facilitar a construo de novos tipos de
mapeamentos (e.g., para uma outra plataforma de programao).
Aps a gerao do XMLMiddleForm, o Manifest.xml lido e identificado a
plataforma desejada pelo engenheiro de software para realizar a transformao. Assim, a
UIG passa para o processador XSLT os templates que mapeiam de XMLMiddleForm para
classes em Java.
A construo da ferramenta UIG foi realizada em Java e utilizou o JAXP [71] (i.e.,
Java API for XML Processing). O JAXP contm vrias classes que facilitam a manipulao
de documentos XML e um processador XSLT capaz de realizar as transformaes
desejadas pela ferramenta.
5.5. A estrutura do cdigo gerado

Como mencionado anteriormente, para cada formulrio, a ferramenta gera trs classes: a
classe Interface, a classe Bean e a classe Controller.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
76
Captulo 5
_______________________________________________________________________________________________________________________________________
A classe Interface dividida em quatro partes: declarao, instanciao, adio dos

componentes e controle de eventos. Na declarao, so gerados os cdigos que declaram os
componentes da interface do formulrio, todos eles so declarados como protected. Na
parte de instanciao, dois construtores so disponibilizados, um que constri o formulrio
com os dados estticos preenchidos no documento XForms e um outro construtor, no qual
passado como parmetro o Bean com novos dados para preencher os campos do
formulrios.
Assim, esses construtores possibilitam ao engenheiro de software tanto criar um
formulrio que j possua alguns valores preenchidos, quanto criar um formulrio com
valores dinmicos, modificados a cada instanciao.
Na parte de controle de eventos, so criados mtodos que tratam os eventos dos
Triggers e repassam o fluxo para um mtodo correspondente da classe Controller. Esses
mtodos da classe Controller recebem como parmetro uma instncia do Bean com os
valores atuais dos campos dos formulrios.
Por exemplo, se um formulrio XForms, chamado de FormLogin, contm um trigger
cujo o id tgOk, o mapeamento da UIG gera as classes FormLogin, FormLoginBean e
FormLoginController. Na classe FormLogin, dentro do mtodo triggerEvent() gerado um
cdigo que testa se o alvo do evento o tgOK. Caso seja verdade, o mtodo tgOkAction()
da classe FormLoginController acionado e nele passado como parmetro uma instncia
de FormLoginBean com os valores atuais dos campos preenchidos do formulrio (e.g.,
login e senha). Desta forma, o engenheiro de software necessita apenas escrever cdigo na
classe controladora. Nos casos em que est definido um submit no XForms, um mtodo que
checa todas as restries que compem o formulrio chamado antes de repassar o fluxo
pra o mtodo do controlador.
5.6. Plugin do eclipse

O UIG plugin projetado e construdo no ambiente Eclipse. Funcionalmente, o UIG
plugin utiliza wizards para simplificar a definio dos diversos atributos da transformao
contidos no Manifest.xml, tais como:
A plataforma de programao alvo do mapeamento (e.g., J2ME MIDP 1.0 ou
Superwaba);
_______________________________________________________________________________________________________________________

Dispositivos Mveis
77
Captulo 5
_______________________________________________________________________________________________________________________________________
A lista de arquivos que devem ser transformados;
A pasta de destino no sistema de arquivos para onde os arquivos gerados devem
ser copiados.
Em um wizard, definida uma seqncia de passos pela qual o usurio pode navegar
atravs dos botes NEXT e BACK, finalizando, enfim, com o boto FINISH.
Os wizards do plugin seguem os seguintes passos:
1. O usurio escolhe qual wizard ir utilizar, de acordo com a plataforma alvo. Esse
passo apresentado na Figura 15.
2. O usurio decide se utilizar definies de uma transformao j realizada pelo
plugin ou ir realizar uma nova transformao, especificando novas definies.
Figura 15 Passos 1 e 2 do wizard
3. Um dos dois passos seguintes realizado, de acordo com a escolha do passo

anterior.
a. Se escolher por utilizar definies de uma transformao j realizada, o
usurio deve informar onde o plugin deve buscar o arquivo Manifest.xml, gerado
anteriormente.
b. Se escolher por uma nova transformao, dever informar o nome do projeto a
ser criado e os dados especficos de transformao de cada plataforma, como a verso do
J2ME.
4. Nesse passo, os arquivos a serem transformados, seus atributos de transformao e
seus componentes so apresentados, para que o engenheiro de software possa confirm-los
_______________________________________________________________________________________________________________________

Dispositivos Mveis
78
Captulo 5
_______________________________________________________________________________________________________________________________________
e, caso seja necessrio, adicionar ou remover mais arquivos. Esse passo mostrado na
Figura 16.
5. Finalmente, o usurio deve escolher a pasta onde os arquivos sero transformados,
dando incio transformao propriamente dita. A transformao transparente para o
usurio e uma barra de progresso mostra o andamento do processo. Todos os passos da
transformao so detalhados em um arquivo de log, salvo tambm na pasta escolhida para
gerar os arquivos.
Figura 16 - Passos 4 e 5 do wizard
5.7. Concluso
Neste captulo, foi descrita a ferramenta User Interface Generator (UIG) que facilita a
construo de aplicaes que utilizam o framework XFormUI. Com a ferramenta, o
engenheiro de software pode construir formulrios, as restries dos dados e o estilo dos
componentes usando linguagens declarativas que agilizam o processo de desenvolver.
Esses formulrios descritos so mapeados pela ferramenta em cdigo executvel nas
plataformas de programao para dispositivos mveis J2ME MIDP 1.0, J2ME MIDP 2.0 e
Superwaba.
No prximo captulo so apresentados os frameworks que permitem a construo de
MAS que adaptem contedo e seus clientes para dispositivos mveis. Vale ressaltar que o
cdigo gerado pela UIG facilmente integrvel a esses frameworks.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
79
Captulo 6
_______________________________________________________________________________________________________________________________________
6. Frameworks Mobile Adapter, Requisitor e

MobAC
Neste captulo so descritos os frameworks Mobile Adapter, Requisitor e MobAC que, em
conjunto, facilitam a construo de Mobile Application Servers que adaptam contedo e
aplicaes para dispositivos mveis que acessam essas informaes adaptadas.
Na seo 6.1, so descritas as especificaes XML CC/PP e UAProf utilizadas pelos
frameworks como documentos para troca e descoberta das informaes do usurio, do
dispositivo e do contexto. Na seo 6.2, apresentado o Mobiler Adapter e seu
relacionamento com o MobAC. Na seo 6.3, descrita a estrutura do framework Mobile
Adapter. Na seo 6.4, apresentado o framework multi-plataforma Requisitor para
realizao de comunicao de dados do tipo Request-Response. Por fim, na seo 6.5,
descrito em detalhes o processo de monitorao e montagem do documento CC/PP pelo
MobAC e como ele utiliza o framework Requisitor para trocar dados com o Mobile
Adapter.
6.1. CC/PP e UAProf

A adaptao de contedo para dispositivos mveis pode basear-se nas caractersticas do
dispositivo, nas preferncias do usurio e nas condies de contexto em que ambos se
encontram. Para fornecer essas informaes para os MASs realizarem a adaptao de
contedo, as especificaes Composite Capability/Preference Profiles (CC/PP) e User
Agent Profiling Specification (UAProf) podem ser utilizadas.
O CC/PP [47] uma especificao do W3C [36] para expressar caractersticas dos
dispositivos e das preferncias de usurios. O CC/PP baseado no framework RDF [36]
para descrio de documentos XML que permite uma maior flexibilidade na criao de
novos vocabulrios. O CC/PP especifica uma estrutura geral de um documento XML para
descrever as caractersticas dos dispositivos e dos usurios. Nos perfis dos dispositivos, o
documento
pode
ser
dividido
em
componentes
(e.g.,
TerminalHardware,
TerminalSoftware) e fornece alguns vocabulrios padres para descrever caractersticas

bsicas dos dispositivos (e.g., dimenses do display, verso do sistema operacional).
_______________________________________________________________________________________________________________________

Dispositivos Mveis
80
Captulo 6
_______________________________________________________________________________________________________________________________________
Contudo, o CC/PP no evita que cada fabricante ou engenheiro de software crie um

vocabulrio prprio, o que dificulta a integrao de sistemas para obteno das
caractersticas dos dispositivos.
O Open Mobile Alliance [96] criou a especificao UAProf com o objetivo de
padronizar os vocabulrios CC/PP entre os fabricantes de dispositivos mveis. UAProf
consiste em um conjunto de vocabulrios para descrever as caractersticas dos dispositivos
e dos User Agent Browsers existentes nos mesmos. Para cada dispositivo criado pelos
fabricantes, um documento UAProf criado e armazenado no repositrio Web do site do
fabricante. Esse documento contm informaes como caractersticas do display do
dispositivo, informaes sobre sistema operacional e softwares disponveis. Na Figura 17,
apresentada uma parte do documento UAProf do dispositivo P900 disponvel no site da
Sony Ericsson [97]. No documento podem ser vistas informaes sobre a quantidade de
cores do dispositivo, dimenses da tela, nmero de linhas e colunas de texto.
<prf:component>
<rdf:Description rdf:ID="HardwarePlatform">
<prf:BitsPerPixel>16</prf:BitsPerPixel>
<prf:ColorCapable>Yes</prf:ColorCapable>
<prf:ScreenSize>208x320</prf:ScreenSize>
<prf:ImageCapable>Yes</prf:ImageCapable>
<prf:ScreenSizeChar>20x15</prf:ScreenSizeChar>
<prf:TextInputCapable>Yes</prf:TextInputCapable>
<prf:Vendor>Sony Ericsson</prf:Vendor>
</rdf:Description>
</prf:component>
Figura 17 - Documento UAProf do P900 retirado do site da Sony Ericsson [97]
No ambiente proposto nessa dissertao, os frameworks Mobile Adapter e MobAC

utilizam o UAProf como fonte de informao das caractersticas estticas dos dispositivos.
Assim, ao contrrio da arquitetura NAC [8], os engenheiros de softwares podero criar os
MAS sem a necessidade de descrever cada dispositivo. J os documentos CC/PP so
utilizados para especificar as caractersticas dinmicas do contexto e as preferncias do
usurio.
6.2. Mobile Adapter e MobAC

Para construir aplicaes que adaptam contedo, certas questes devem ser respondidas
[26]: (i) como os perfis dos dispositivos e dos usurios podem ser obtidos; (ii) que polticas
de adaptao so empregadas; e (iii) quando a adaptao deve ser executada. Em [10], [11]
_______________________________________________________________________________________________________________________

Dispositivos Mveis
81
Captulo 6
_______________________________________________________________________________________________________________________________________
e [12], uma nica entidade, um proxy, responde a essas questes. Um proxy adapta os
recursos a cada requisio e o responsvel por delegar como e quando realizar a
adaptao. Contudo, como mencionado no Captulo 2, essa abordagem concentra toda a
deciso da adaptao em uma arquitetura geral que pode no ser satisfatria para outros
tipos de aplicaes que no consistam na simples requisio de um contedo Web.
No Mobiler Adapter e no MobAC, as decises relacionadas com a adaptao so
delegadas para os MAS e para as aplicaes no dispositivo mvel. As implementaes
desses frameworks se encarregam ento de capturar, manipular e gerenciar os perfis dos
dispositivos, dos usurios e do contexto. Desta forma, permite-se a criao de sistemas mais
flexveis quanto adaptao, uma vez que a obteno das informaes separada dos
mtodos de adaptao.
O Mobile Adapter consiste em um framework Web para criao de MAS adaptativos.
O Mobile Adapter Client (MobAC) um cliente multi-plataforma para dispositivos mveis
que capaz de trocar informaes com o Mobile Adapter. Na Figura 18, uma viso geral
das classes que compem esses frameworks e seus relacionamentos com um MAS e com os
repositrios de especificaes UAProf so apresentados.
Figura 18 - Viso geral do Mobile Adapter e do MobAC

_______________________________________________________________________________________________________________________

Dispositivos Mveis
82
Captulo 6
_______________________________________________________________________________________________________________________________________
O MobAC responsvel por capturar as informaes dinmicas do contexto

referentes ao dispositivo e ao ambiente de execuo (e.g., memria livre, localizao),
assim como responsvel por capturar a identificao do dispositivo ou a URI da
especificao UAProf e a identificao do usurio. De posse desses valores, a cada
requisio, o MobAC gera um documento CC/PP que enviado juntamente com a
requisio da aplicao (A). Ao contrrio do trabalho [113], somente os atributos dinmicos
do dispositivo so enviados a cada requisio, o que reduz o tamanho da informao a ser
enviada.
Aps a gerao do documento CC/PP, o MobAC envia ao MAS o documento e a
requisio (A). Esse envio realizado utilizando uma implementao do framework
Requisitor que descrito na seo 6.4. O MAS repassa o documento ao Mobile Adapter (B)
para que este fornea as informaes estticas e dinmicas do dispositivo, do usurio e do
contexto. A entidade central do Mobile Adapter, chamada de ProfileManager, instancia o
CC/PPHandler para processar o documento CC/PP (I).
Durante o processamento, o CC/PPHandler separa as informaes contidas no
documento em trs partes: ID do usurio, informaes do contexto e URI do documento
UAProf. As partes so repassadas para os manipuladores especficos de cada informao,
respectivamente: UserProfileHandler, ContextProfileHandler e DeviceProfileHandler.
A classe UserProfileHandler l o ID do usurio (II) e recupera o seu perfil na base de
dados XML do framework. Estes perfis dos usurios devem ser previamente cadastrados
pelo MAS, utilizando o ProfileManager e tambm devem estar descritos em CC/PP. De
posse do perfil, o UserProfileHandler gera um objeto (III) que contm todos os dados do
usurio descritos no documento, com mtodos de acesso que seguem a especificao Java
Beans [118]. O ContextProfileHandler, de forma semelhante, aps receber as informaes
relacionadas ao contexto (IV) gera um objeto Java Beans povoado (V) com os dados
contidos no documento CC/PP enviado pela aplicao do DM.
O DeviceProfileHandler, por sua vez, recebe do CC/PPHandler a URI do documento
UAProf
que
descreve
as
propriedades
estticas
do
dispositivo
(VI).
DeviceProfileHandler utiliza o UAProfCache para checar se esse documento j se encontra

no cache do framework. Caso no seja encontrado, o download do documento realizado
junto ao site dos fabricantes (VII e VIII). O DeviceProfileHandler, de posse do documento
_______________________________________________________________________________________________________________________

Dispositivos Mveis
83
Captulo 6
_______________________________________________________________________________________________________________________________________
UAProf, gera tambm um objeto Java Beans correspondente aos dados estticos que sero
utilizados para adaptao (IX).
Assim, aps os processo de gerao dos Beans, o CC/PPHandler retorna um
UserBean, um DeviceBean e um ContextBean ao ProfileManager (X). Este, por sua vez,
repassa os objetos para o MAS (C). Em seguida, o MAS executa as polticas de adaptao e
retorna a resposta adaptada para a aplicao no dispositivo mvel (D).
6.3. Arquitetura do Mobile Adapter

Na Figura 19, apresentado uma viso geral das classes que compem o framework
Mobile Adapter. O framework dividido em trs partes: Ncleo, Manipuladores de Perfis e
Beans.
Figura 19 - Viso geral do framework Mobile Adapter
Na parte Ncleo, encontram-se as principais classes do framework: ProfileManager,

CCPPHandler, UserProfileDAO e UAProfCache. A classe ProfileManager, como descrito
anteriormente, a principal classe do framework e deve ser instanciada pelo MAS para a
sua utilizao. A classe UserProfileDAO a responsvel por armazenar e recuperar os
perfis dos usurios descritos em CC/PP que so adicionados pelo MAS usando o mtodo
addUserProfile da classe ProfileManager.
A classe UAProfCache a responsvel por gerenciar o cache dos documentos
UAProf. O cache utilizado consiste em uma tabela de disperso (i.e., hashtable) cuja chave
a URI e o valor o documento UAProf. As tabelas de disperso so eficientes para esse
tipo de operao, pois possuem complexidade mdia O(1) para acesso [118]. O uso de
_______________________________________________________________________________________________________________________

Dispositivos Mveis
84
Captulo 6
_______________________________________________________________________________________________________________________________________
cache necessrio devido aos tamanhos que os documentos UAProf podem ter, em geral
acima de 14KB. Dessa forma, se o cache no for utilizado, downloads repetidos do UAProf
causam atraso no processo de adaptao.
Na parte Manipuladores de Perfis, encontram-se as classes: UserProfileHandler,
ContextProfileHandler e DeviceProfileHandler. Essas classes so responsveis por mapear,
para instncias de objetos da parte Beans do framework, os parmetros contidos,
respectivamente, nos documentos CC/PP do usurio, CC/PP enviado pelo MobAC e
UAProf do dispositivo.
Para que o engenheiro de software possa utilizar os parmetros que desejar nos
documentos CC/PP relacionados ao contexto e ao usurio, as classes UserProfileHandler e
ContextProfileHandler criam os objetos Beans utilizando o conceito de Reflection que a
capacidade de em tempo de execuo descobrir mtodos e atributos de um objeto ou de
uma classe [100]. Dessa forma, esses Handlers descobrem o nome de cada atributo contido
nos Beans e procuram nos documentos XMLs, tags com o mesmo nome. Caso encontrem,
esses Handlers utilizam os mtodos sets para atribuir aos Beans os valores contidos no
documento XML.
Para facilitar o uso do Mobile Adapter, o framework j disponibiliza Beans com
atributos gerais, que so descritos a seguir:
BasicUserBean contm o atributo language que define a lngua de preferncia
do usurio;
BasicContextBean contm os atributos battery, fMem e fStorMem que
correspondem quantidade de bateria disponvel, memria livre para a execuo e o

armazenamento no dispositivo.
BasicDeviceBean
contm
os
atributos
displayColor,
displayWidth,
displayHeight, displayNumberOfColors, displayCharsLines, displayCharsColumns e

playSound referentes s propriedades do dispositivo.
Para monitorar novos atributos relacionados ao contexto e ao usurio, o engenheiro de
software deve utilizar os Hot Spots disponibilizados no framework (ver Figura 19).Vale
ressaltar que a instanciao do BasicDeviceBean pelo DeviceProfileHandler ocorre sem o
uso de Reflection, pois os dados estticos do dispositivo so retirados de um documento
UAprof com tags pr-estabelecidas. Assim, caso o engenheiro deseje monitorar novos
_______________________________________________________________________________________________________________________

Dispositivos Mveis
85
Captulo 6
_______________________________________________________________________________________________________________________________________
atributos do dispositivo, ele deve, alm de criar uma subclasse de DeviceBean, modificar o
cdigo do DeviceProfileHandler.
O framework Mobile Adapter foi implementado em Java utilizando a API livre
Common Bean Utils para realizar as operaes de Reflection. E a classe Java HashTable foi
utilizada na implementao do cache.
6.4. Framework Requisitor

Como mencionado no Captulo 3, as plataformas de programao para dispositivos
mveis, mesmo as baseadas em Java, possuem diferentes APIs para conexo de dados. Esta
caracterstica dificulta a construo de aplicaes multi-plataformas que necessitam trocar
informaes com servidores ou outras aplicaes remotas.
Nesse contexto, apresentamos um framework multi-plataforma, intitulado de
Requisitor, para permitir que aplicaes em dispositivos mveis possam realizar
comunicao de dados do tipo Request-Response. Este framework permite a comunicao
transparente de dados e foi projetado para suportar troca de dados atravs de socket TCP-IP
e do protocolo HTTP.
Na analise de domnio do framework, foi realizada uma investigao de como pode
ser estabelecida a comunicao de dados nas plataformas de programao J2ME MIDP,
Superwaba e J2ME Personal Profile, uma outra verso de J2ME baseada na configurao
CDC [43]. A partir dessa investigao, foram identificadas as principais classes de cada
plataforma que realizam a comunicao de dados e uma generalizao dos seus mtodos foi
criada.
Como mencionado no Captulo 3, padres de projeto podem ser utilizados na fase de
projeto de um framework. No caso do Requisitor, os padres de software Foward-Receiver
[41], Strategy [41] e Factory Method [41] foram utilizados para permitir a transparncia
dos protocolos de comunicao e das APIs de conexo.
O padro Forward-Receiver introduz um modelo de comunicao ponto-a-ponto (i.e.,
peer-to-peer), que permite a separao dos remetentes (Forwarders) e receptores
(Receivers), dos mecanismos de comunicao utilizados para a entrega e recebimento das
informaes, provendo, assim, uma comunicao interprocesso transparente. O padro
_______________________________________________________________________________________________________________________

Dispositivos Mveis
86
Captulo 6
_______________________________________________________________________________________________________________________________________
Forwarder-Receiver utilizado como base para a construo do framework Requisitor. O

framework utiliza a mesma abordagem de Fowarders, Receivers e Peers.
O padro Strategy utilizado quando se quer manter a independncia do algoritmo
utilizado para realizar uma determinada tarefa. Sendo assim, ele define uma famlia de
algoritmos e os encapsula, permitindo ao objeto utilizador realizar a permuta entre os
algoritmos sempre que esse achar conveniente. O padro Strategy foi utilizado na definio
do framework para montar a hierarquia das classes do Forwarder, do Receiver e do Entry,
nas quais as estratgias de envio, de recebimento e de mapeamento das entradas ficam
transparentes para o Peer.
Alm desses padres, o framework utilizou o padro Factory Method para gerao
dos Forwarders e Receivers dependentes do protocolo de comunicao que o Peer utilizar
para se comunicar com outro Peer (e.g., ForwarderHTTP, ReceiverSocketTcpIp).
Na Figura 20, apresentada uma viso geral do framework que dividido em trs
partes principais: Requisitor Interface, Requisitor Factory e Requisitor Communication
Protocols.
Figura 20 - Framework Requisitor
A parte Requisitor Interface disponibiliza para as aplicaes as classes Peer e as

classes que herdam de Entry. A classe Peer representa a interface do framework com a
_______________________________________________________________________________________________________________________

Dispositivos Mveis
87
Captulo 6
_______________________________________________________________________________________________________________________________________
aplicao. Nessa classe so disponibilizados os mtodos para envio e recebimento de dados.

Ela tambm possui uma tabela de disperso (i.e., hashtable) na qual so armazenados os
nomes das partes comunicantes e seus respectivos objetos das classes que herdam de Entry.
Em um objeto Entry est contido o tipo de protocolo que deve ser utilizado para a
comunicao, assim como os dados especficos dessa comunicao (e.g., URI na classe
EntryHTTP; endereo IP e porta na classe EntrySocketTCPIP). A aplicao utiliza o
mtodo pblico addEntry, pertencente ao Peer, para adicionar novas partes comunicantes e
seus respectivos dados especficos de comunicao.
Para que a aplicao possa enviar dados utilizando a classe Peer, basta informar a
mensagem e o nome dado ao outro Peer comunicante. E para receber os dados, a aplicao
deve informar o nome do outro Peer comunicante. O Peer disponibiliza dois tipos de envio:
em cadeia de bytes e em cadeia de caracteres (i.e., String). Alm disso, o Peer possui trs
formas de recebimento de dados: em cadeia de bytes, em cadeia de caracteres e um objeto
da classe ReceiverBytePerByte que permite manipular byte a byte medida que os dados
so recebidos.
A parte Requisitor Factory do framework responsvel por criar o Forwarder e o
Receiver especficos para estabelecimento da comunicao. Na parte Requisitor
Communication Protocols, as classes especficas de cada protocolo, como por exemplo, o
ForwarderHTTP, so associadas a cada API de comunicao da plataforma de
programao na qual o framework implementado. Assim, para portarmos o framework
para outra plataforma de programao necessrio apenas reimplementar partes das classes
da terceira parte do framework. Caso o engenheiro de software deseje adicionar um novo
protocolo de comunicao (e.g., envio por SMS - Short Message Service), ele deve utilizar
os Hot Spots para criar novas classes que herdam de Forwarder, Receiver e Entry.
O framework Requisitor foi implementado em J2ME MIDP 1.0 e 2.0, J2ME Personal
Profile e Superwaba. Como mencionado anteriormente, estas implementaes so usadas
pelo MobAC para enviar o documento CC/PP para um MAS que utiliza o Mobile Adapter.
Contudo, vale ressaltar que o framework Requisitor pode ser utilizado sem o uso do
MobAC para envio e recebimento de dados. Na Figura 21, ilustrado um trecho do cdigo
de uma aplicao J2ME MIDP 1.0 que utiliza o framework Requisitor para realizar o
download de uma imagem de um servidor Web.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
88
Captulo 6
_______________________________________________________________________________________________________________________________________
EntryHTTP entryImagem=new EntryHTTP("GET",

"http://www.lia.ufc.br/~windson/imagens/ ");
Peer peer1=new Peer();
peer1.addEntry("ServImagem",entryImagem);
//...
//Na parte que controla os eventos dos Botes
peer1.sendString("logomidp.png ","ServImagem");
byte[] imagem=peer1.readBytes("ServImagem");
if(imagem!=null){
Image imagemAux=Image.createImage(imagem,0,imagem.length);
//Imagem criada
}
Figura 21 Cdigo que utiliza o framework Requisitor
6.5. Arquitetura do MobAC

Como mencionado anteriormente, o MobAC o framework responsvel por capturar as
variveis dinmicas do contexto e montar o documento CC/PP que enviado juntamente
com as requisies da aplicao para o MAS.
Para permitir a flexibilidade do MobAC e a sua implementao em diferentes
plataformas, ele dividido em quatro processos bsicos: a interface com a aplicao, a
monitorao, a gerao do documento CC/PP e o envio da requisio.
Entre esses quatro processos, o envio de requisio e a monitorao so as partes mais
complexas a serem portadas para vrias plataformas. Para facilitar esse procedimento, toda
parte de comunicao do MobAC realizada utilizando o framework Requisitor.
Na Figura 22, so apresentadas as classes que compem o framework e seu
relacionamento com o framework Requisitor. A classe MobAC a classe a ser utilizada
pela aplicao e contm mtodos para envio e recebimento de vetores de bytes e cadeias de
caracteres (i.e., Strings).
A classe abstrata CCPPAssembler a responsvel por montar o documento CC/PP
que adicionado requisio. Na instanciao da classe MobAC, o engenheiro de software
deve passar como parmetro uma instncia de uma subclasse do CCPPAssembler que
implemente o mtodo que monta o contedo do documento CC/PP.
O framework j disponibiliza uma classe que implementa este mtodo, a
CCPPBasicAssembler. Esta classe monta um documento CC/PP com as seguintes
propriedades: o ID do usurio, a URI do UAProf, a quantidade de energia disponvel na
bateria, memria livre de execuo e de armazenamento do dispositivo. O ID do usurio
_______________________________________________________________________________________________________________________

Dispositivos Mveis
89
Captulo 6
_______________________________________________________________________________________________________________________________________
passado pela aplicao ao realizar uma requisio, a URI do documento UAProf que
descreve o dispositivo capturada pela classe UAProfGetter e os outros parmetros so
obtidos a partir de uma instncia da classe Monitor.
Figura 22 - Framework MobAC e a interao com framework Requisitor
Vale ressaltar, que os atributos do contexto contidos no documento CC/PP gerado

pela classe CCPPBasicAssembler correspondem aos atributos do bean ContextBasicBean
disponibilizados pelo framework Mobile Adapter. Na Figura 23, apresentada uma parte
do documento CC/PP gerado pelo framework MobAC durante uma requisio no P900
utilizando a classe CCPPBasicAssembler.
Entretanto, caso o engenheiro de software deseje monitorar e enviar outros
parmetros sobre o contexto de execuo, ele deve criar o seu prprio CCPPAssembler e
seu Monitor utilizando os Hot Spots disponibilizados pelo framework (Figura 22), assim
como criar uma nova classe que herda de ContextBean no framework Mobile Adapter
conforme mencionado na seo 6.2.
<ccpp:component>
<rdf:Description>
<great:uaProfURI>wap.sonyericsson.com/UAprof/P900R101.xml</great:uaProfURI>
<great:userID>UserDefault</great:userID>
<great:fMem>465812</great:fMem>
<great:fStorMem>145800</great:fStorMem>
<great:battery>0.8</great:battery>
</rdf:Description>
</ccpp:component>
Figura 23 - Documento CC/PP gerado durante uma requisio no dispositivo P900
O MobAC foi implementado em J2ME MIDP e Superwaba, o que facilita a

integrao com os cdigos gerados pela UIG. Como essas plataformas so baseadas em
_______________________________________________________________________________________________________________________

Dispositivos Mveis
90
Captulo 6
_______________________________________________________________________________________________________________________________________
Java e o processo de requisio utiliza o framework multi-plataforma Requisitor, apenas o

processo de monitorao foi implementado em cada plataforma.
6.6. Concluso
Neste Captulo foi apresentado o Mobile Adapter e MobAC que, em conjunto,
propiciam uma forma eficiente de captura, manipulao e gerenciamento dos perfis do
dispositivo, do usurio e do contexto em que executam. Como mencionado no Captulo 2, a
ausncia destes tipos de mecanismos dificulta a construo de sistemas reais que executam
adaptao de contedo.
Alm disso, o MobAC foi construdo para ser facilmente integrvel ao cdigo gerado
pela ferramenta UIG apresentada no Captulo 5. Dessa forma, o ambiente proposto pode ser
facilmente utilizado tanto para construir aplicaes adaptveis descrio e multiplataformas, quanto para construir aplicaes que acessam MAS que adaptam contedo.
No captulo, tambm foi apresentado o framework multi-plataforma Requisitor que
permite o estabelecimento de comunicao de dados entre servidores remotos e as
aplicaes nos dispositivos mveis. Esse framework foi utilizado no MobAC para facilitar
sua implementao em vrias plataformas.
No prximo captulo, apresentado um estudo de caso que ilustra como os
frameworks e a ferramenta propostos nessa dissertao podem ser integrados para construir
aplicaes complexas para dispositivos mveis.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
91
Captulo 7
_______________________________________________________________________________________________________________________________________
7. Estudo de Caso
Neste Captulo apresentado um estudo de caso que ilustra como o ambiente
proposto nesta dissertao pode ser utilizado no desenvolvimento de aplicaes adaptativas
e multi-plataformas para dispositivos mveis. O estudo de caso consiste em um sistema
para a visualizao e a postagem de imagens fotogrficas e comentrios. O sistema,
chamado de M-Flog, composto de uma servidor Web e de um cliente para DMs.
Na Seo 7.1, so apresentados os requisitos e a arquitetura geral do M-Flog. Na
Seo 7.2, detalhado o processo de construo da aplicao para DMs do M-Flog. Na
Seo 7.3, descrita a construo do MAS Adaptativo e dos pacotes de adaptao de
imagem e de texto. E, por fim, na Seo 7.4 a apresentado uma avaliao da eficincia do
uso de adaptao de imagens.
7.1. M-Flog
Uma das aplicaes de entretenimento que tem se tornado popular na Internet so os
Flogs. Um Flog um dirio de fotos na forma de um site na Internet. Esses sistemas Web
permitem ao usurio adicionar imagens fotogrficas a cada dia e colocar comentrios sobre
elas. Alm disso, outros usurios podem adicionar comentrios nos Flogs dos amigos.
J existem Flogs [88] que permitem o envio, atravs de MMS (Multimedia Message
Service), de imagens retiradas com cmera de um celular. Contudo, o objetivo do M-Flog
construir um Flog acessvel por dispositivos mveis, tanto para visualizar imagens e
comentrios, quanto para o usurio adicionar comentrios aos Flogs dos seus amigos.
Para que o M-Flog possa ser acessado por uma grande quantidade de usurios e o para
que sistema tenha um tempo satisfatrio de resposta s requisies, dois requisitos no
funcionais devem ser satisfeitos e so listados a seguir:
Portabilidade
da aplicao cliente. Diferentes usurios iro utilizar o M-Flog em
dispositivos com caractersticas diferentes entre si. Desta forma, a aplicao deve ser capaz
de ser executada em uma grande diversidade de dispositivos e plataformas de programao.
Adaptao
das imagens e dos comentrios. A adaptao das imagens necessria
devido dificuldade que um dispositivo mvel possa vir a ter para conseguir acessar uma
imagem fotogrfica da Web, por causa do tamanho ou do formato da mesma. A adaptao
_______________________________________________________________________________________________________________________

Dispositivos Mveis
92
Captulo 7
_______________________________________________________________________________________________________________________________________
dos comentrios importante para possibilitar que mesmo em dispositivos com pequenos
displays, um usurio possa ter acesso a um comentrio ou a uma parte dele.
Portanto, para satisfazer esses requisitos no funcionais e diminuir o tempo e o custo
de construo da aplicao, foi utilizado o ambiente proposto nesta dissertao. Na Figura
24, ilustrada uma viso geral do M-Flog e seus relacionamentos com os frameworks
propostos na dissertao. Para construir a aplicao do DM, a ferramenta UIG foi utilizada
para gerar as interfaces, os controladores e os beans dos formulrios. Desta forma, as
interfaces da aplicao utilizam o framework XFormUI e executam em trs plataformas de
programao.
Para realizar a comunicao com o MAS do M-Flog, cdigos foram escritos nos
controladores dos formulrios. Quando o contedo a ser requisitado no necessita de
adaptao, esses cdigos utilizam o framework Requisitor para enviar a requisio (e.g., na
checagem de login e senha). J nos casos em que as requisies podem ter respostas
adaptadas, o MobAC utilizado (e.g., requisio de imagens).
O MAS do M-Flog tanto pode ser acessado por dispositivos mveis quanto por um
browser de um PC. Para sua construo, o framework Mobile Adapter foi utilizado. Assim,
o M-Flog pode recuperar facilmente os perfis do usurio, do dispositivo e do contexto,
permitindo a realizao da adaptao dos textos e das imagens.
Figura 24 - Viso geral do M-Flog
_______________________________________________________________________________________________________________________

Dispositivos Mveis
93
Captulo 7
_______________________________________________________________________________________________________________________________________
7.2. Aplicao no DM
Para a construo da aplicao no dispositivo mvel, os formulrios foram
especificados em XForms, CSS e XML Schema utilizando o Eclipse e o plugin para edio
de documentos XML, o XMLBuddy [69] . Os formulrios criados so usados para entrada
de dados de login, visualizaes de imagens e comentrios, escolha de opes, busca de
imagens, mudana das preferncias do usurio e adio de novos comentrios. Na Figura
25, so apresentadas as telas da aplicao de login, de preferncias do usurio e de leitura
de comentrios, em XForms executadas no browser X-Smiles [15].
Figura 25 - Telas da aplicao no XSmiles
Na construo do layout dos formulrios da aplicao, os atributos de cores do CSS

foram utilizados para modificar as cores dos labels das interfaces e o atributo align e a tag
</xhtml:p> foram usados para determinar o posicionamento dos componentes nos
formulrios. O XML Schema e o Bind do XForms foram usados para determinar as
restries para entrada de dados em trs formulrios, listados a seguir:
Formulrio de login. Neste formulrio, o usurio preenche login e senha para
obter autorizao para entrar no sistema. Um tipo simples do XML Schema foi associado
ao campo senha para que a mesma contenha de 3 a 10 dgitos. Para o campo login foi
criado um Bind de required=true o qual define o campo como obrigatrio.
Formulrio
de busca de imagens. Neste formulrio, o usurio informa um perodo
para serem buscadas as imagens que ele deseja visualizar. Assim, o tipo bsico xsd:date do
XML Schema foi associado aos Inputs, o que permitiu a seleo de datas para realizar a
busca.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
94
Captulo 7
_______________________________________________________________________________________________________________________________________
Formulrio
de exibio de comentrio. Neste formulrio, exibido o comentrio
adicionado a uma imagem por um amigo do usurio. Como o usurio no pode modificar
esse texto, foi criado um Bind de readonly=true para o TextArea.
Na Tabela 11, podem ser vistos trechos do arquivo XML Schema utilizado nas telas
de login e busca de imagens para aplicar as restries na entrada dos dados. O CSS usado
em todos os formulrios para definir as cores dos labels tambm apresentado nessa tabela.
Schema
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="login" type="xsd:string"/>
<xsd:element name="data" type="xsd:date"/>

<xsd:simpleType name="senha">
<xsd:restriction base="xsd:string">
<xsd:maxLength value="10"/>
<xsd:minLength value="3"/>
</xsd:restriction>
</xsd:simpleType>
CSS
input {
color: #FF0000;
}
secret {
color: #FF0000;
}
selectboolean {
color: #FF0000;
}
Tabela 11 - Cdigos do XML Schema da tela de login e do CSS usado nos formulrios
Aps a escrita dos formulrios, o Manifest.xml foi criado e os formulrios foram

gerados nas trs plataformas de programao utilizando o plugin do Eclipse tambm
provido pelo ambiente. O tempo mximo decorrido para a gerao de cdigo de todos
formulrios para as trs plataformas foi de 9,52 segundos. Vale ressaltar que a UIG foi
executada em uma mquina AMD Atlhon 2400Hz, 512 MB de RAM com Windows XP
Pro.
Na Figura 26, ilustrada a tela de login gerada pela UIG sendo executada nas trs
plataformas de programao. Na aplicao que executa em J2ME MIDP 1.0, pode ser
notada a ausncia de alinhamento centralizado da imagem e do Output se comparada
aplicao em J2ME MIDP 2.0. Alm disso, apesar de o dispositivo ser colorido, no
existem cores nos labels do Input e do Secret. Na aplicao em Superwaba, exibida a
execuo do cdigo gerado automaticamente, a partir do XML Schema e do Bind, para a
validao da entrada de dados nos campos senha e login. Como o campo login no est
preenchido, ao se acionar o Trigger Entrar, a janela de alerta com a mensagem Login
requerido!! exibida.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
95
Captulo 7
_______________________________________________________________________________________________________________________________________
Figura 26 - Tela de login nas trs plataformas
Cinco formulrios gerados pela ferramenta tm dados iniciais dinmicos que se

modificam a cada execuo da aplicao. Desta forma, esses formulrios so instanciados
atravs do construtor gerado pela UIG que permite a passagem de atributos de inicializao
usando um objeto Bean do formulrio. Na Tabela 12, ilustrado o cdigo em XForm do
formulrio de preferncias do usurio, assim como o cdigo correspondente em XFormUI
para o construtor parametrizado.
Cdigo em XForms
<xforms:output ref="/data/titulo"
id="outTitulo" align="center">
<xforms:label/>
</xforms:output>

<xforms:output ref="/data/output"
id="outQualidade" align="center">
<xforms:label/>
</xforms:output>

<xforms:selectboolean
ref="/data/selectboolean"
id="sbDistorcer" align="center">
<xforms:label>Distorcer?</xforms:label>
Cdigo em XFormUI
FormPreferencias(MainXForm
mainXForm,
FormPreferenciasBean xformBean){
super("mflog - mobile fotolog",mainXForm);
// Output(s)
this.outTitulo =
new Output("",""+xformBean.titulo);
this.outQualidade =
new Output("",""+xformBean.output);
// SelectBoolean(s)
this.sbDistorcer =
new SelectBoolean("Distorcer?"," ");
this.sbDistorcer.setValue(""
+xformBean.selectboolean);
// Trigger(s)
</xforms:selectboolean>
this.trgOK = new Trigger("OK");

} // End FormPreferencias
<xforms:submit id="trgOK">
<xforms:label>OK</xforms:label>
</xforms:submit>
Tabela 12 Cdigo do formulrio em XForms e o correspondente em XFormUI

_______________________________________________________________________________________________________________________

Dispositivos Mveis
96
Captulo 7
_______________________________________________________________________________________________________________________________________
Para realizar a comunicao com o MAS do M-Flog e receber as respostas no

adaptadas, cdigos que utilizam o framework Requisitor para enviar e receber informaes
foram escritos nos controladores dos formulrios.
Essas informaes so enviadas atravs de requisies GET do protocolo HTTP. O
MAS responde s requisies e no caso de a resposta ser uma lista de Strings (e.g., lista dos
flogs dos amigos) , as informaes so enviadas para o DM em uma nica String com
caracteres especiais de separao.
No caso das requisies adaptativas de texto e imagem, cdigos que utilizam o
framework MobAC foram escritos nos controladores dos formulrios. Durante uma
requisio, a implementao do framework MobAC adiciona um parmetro que contm o
documento CC/PP com o ID do usurio, a URI do documento UAProf e as seguintes
variveis de contexto monitoradas: memria livre do dispositivo e o tipo de imagem
suportado (e.g., JPG, GIF e PNG). Esse documento processado pelo MAS atravs do
Mobile Adapter o que permite a realizao das adaptaes. Esse processo detalhado na
prxima seo.
Todos esses cdigos escritos nos controladores executam nas trs plataformas de
programao, j que elas so baseadas em Java e os cdigos utilizam os frameworks
implementados nas trs plataformas. Desta forma, todas as funcionalidades de validao
dos dados, troca de formulrios e comunicao com o MAS da aplicao foram escritas
apenas uma vez pelo engenheiro de software.
Na Figura 27, apresentado um fluxo de execuo da aplicao no J2ME MIDP 2.0,
iniciando na tela de login e senha e ilustrando as telas de listagem de amigos, busca de
imagens, a imagem adaptada, visualizao de comentrios e preferncias do usurio.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
97
Captulo 7
_______________________________________________________________________________________________________________________________________
Figura 27 - Um fluxo de execuo da aplicao cliente do M-Flog
7.3. MAS Adaptativo

Como mencionado anteriormente, o Mobile Application Server do M-Flog responde
tanto a requisies normais quanto a requisies que exigem respostas adaptativas. Dois
recursos do sistema so adaptados: imagens e textos dos comentrios.
A adaptao de imagens no M-Flog necessria, pois caso um usurio utilize um
navegador tradicional de um dispositivo mvel para acessar o sistema, as imagens
fotogrficas originais so enviadas por completo para o dispositivo. O envio dessas
imagens ocupa desnecessariamente a banda de comunicao, j que o dispositivo tem que
converter a imagem recebida em dimenses e cores adequadas para a sua exibio. Essa
converso exige memria e processamento do dispositivo que muitas vezes pode no
conseguir realiz-la em um tempo aceitvel para o usurio. Alm disso, nos casos em que o
usurio tarifado pela quantidade de pacotes recebidos (e.g., GPRS, EDGE), ele paga pelo
tamanho inicial da imagem.
Outro problema relacionado ao acesso de imagens pelas aplicaes, decorre da
diferena nos formatos de imagens suportados pelas plataformas de programao. Como
_______________________________________________________________________________________________________________________

Dispositivos Mveis
98
Captulo 7
_______________________________________________________________________________________________________________________________________
mencionado no Captulo 3, a plataforma J2ME MIDP 1.0 suporta apenas PNG, o que exige
uma mudana no formato das imagens acessadas por aplicaes escritas nessa plataforma.
Para oferecer as informaes sobre o usurio, o dispositivo e o contexto em que
ambos executam, o M-Flog foi construdo utilizando o framework Mobile Adapter. Ao
receber uma requisio de uma imagem ou de um comentrio, o M-Flog repassa para o
ProfileManager o documento CC/PP enviado pelo MobAC. O ProfileManager, como
descrito no Captulo 6, dispara os processos de descoberta do perfil do usurio e do
dispositivo e de mapeamento dos perfis para os objetos Beans. De posse desses objetos, o
M-Flog realiza a adaptao.
Os parmetros considerados pelo MAS dos perfis do usurio, do dispositivo e do
contexto para realizar as adaptaes so os seguintes:
Perfil
do Usurio: qualidade desejada e realizao de distoro (i.e., stretch). O
parmetro de qualidade determina qual a qualidade da imagem desejada pelo usurio, j

que em alguns formatos de imagens, como JPEG e PNG, possvel aplicar filtros para
reduo da qualidade e conseqentemente do tamanho da imagem. O parmetro de
realizao de distoro informa se o usurio deseja ou no realizar a operao de stretch de
uma imagem. Uma operao de stretch uma mudana nas dimenses da imagem (i.e.,
reduo ou aumento), que no preserva as propores iniciais da imagem, causando uma
distoro.
Perfil
do Dispositivo: largura e altura do display, nmero de linhas e de colunas de
caracteres e nmero de cores ou tons de cinza do dispositivo.

Perfil
do Contexto: memria livre do dispositivo e tipo de imagem suportada
Como pode ser visto, foram acrescentados dois parmetros ao Perfil do Usurio que
no so suportados de incio pelo framework Mobile Adapter. Essa adio de parmetros
foi realizada atravs de uma nova classe, a UserMFlogBean que estende a classe
BasicUserBean provida pelo framework. Desta forma, as instncias da classe
UserMFlogBean so povoadas automaticamente pelo Mobile Adapter atravs do processo
de Reflection explicitado no Captulo 6. Vale ressaltar que estes parmetros do perfil do
usurio so preenchidos quando este se cadastra ao sistema e podem ser alterados, inclusive
utilizando o cliente para DMs do M-Flog.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
99
Captulo 7
_______________________________________________________________________________________________________________________________________
Para atender as requisies do cliente do M-Flog, o MAS foi implementado em J2EE

[51] utilizando o framework Maverick. O Maverick uma implementao do modelo MVC
(i.e., Model-View-Controller) para facilitar o desenvolvimento de aplicaes Web. Assim,
para cada tipo de requisio foi associada uma classe Servlet controladora. Para armazenar
os comentrios e os relacionamentos entre os usurios, o banco de dados livre MySql foi
utilizado.
Na Figura 28, so apresentadas as classes do M-Flog responsveis por participar do
processo de adaptao e o seus relacionamentos com as classes existentes no Mobile
Adapter. As classes ComController e o ImageController so os Servlets que recebem as
requisies adaptativas provenientes dos clientes dos DMs. As classes TextAdapter e Img
Adapter so responsveis por realizar a adaptao e so descritas nas prximas sub-sees.
Figura 28 Classes que participam dos processos de adaptao do M-Flog
7.3.1.
Adaptao de Textos
Para realizar a adaptao de texto dois parmetros do perfil do dispositivo so usados:

o nmero de linhas e o nmero colunas de caracteres. Com esses dois parmetros
calculado o nmero mximo de caracteres exibveis na tela do dispositivo. Esse nmero
calculado utilizado para classificar o dispositivo em trs categorias: pequeno, mdio e
grande. O dispositivo classificado como pequeno quando o nmero de caracteres
menor que 360 (e.g., celular), mdio quando o nmero de caracteres est entre 360 e 1600
(e.g., Smartphones) e grande quando tem mais de 1600 caracteres (e.g., Pocket PC).
_______________________________________________________________________________________________________________________

Dispositivos Mveis
100
Captulo 7
_______________________________________________________________________________________________________________________________________
A adaptao dos textos realizada usando duas estratgias: verses e cortes. A

adaptao baseada em verso consiste em escolher a mais adequada entre diferentes verses
de um mesmo texto. Essa adaptao semelhante estratgia usada em [12] para
documentos SMIL. A estratgia de corte consiste em recortar um texto para que este
contenha uma quantidade de caracteres que no ultrapasse um nmero determinado.
Assim, quando a aplicao no DM faz uma requisio pedindo ao Servlet
ComController um comentrio, este retira o documento CC/PP da requisio e repassa pra
ProfileManager. Depois de receber os Beans povoados pelo ProfileManager, o Com
Controller instancia o TextAdapter. O TextAdapter classifica o dispositivo em pequeno,
mdio e grande. Baseado na classificao, o TextAdapter consulta a base de dados para
checar se existe uma verso do comentrio para essa classe de dispositivo. Caso exista uma
verso, o comentrio retornado ao dispositivo. Caso uma verso no esteja disponvel, o
TextAdapter retira os primeiros 360 ou 1600 caracteres, dependendo da classificao do
dispositivo, da verso existente do comentrio. Vale ressaltar que o usurio, ao cadastrar
um comentrio, pode criar trs verses para cada um deles ou tem a opo de escrever uma
nica verso.
Desta forma, a adaptao de textos apresentada consiste em uma adaptao de
contedo, em tempo de execuo, a classes de dispositivos. Na Figura 29, apresentado
o caminho lgico dessa adaptao utilizando a notao descrita em [89], na qual cada seta
representa um tipo de adaptao ou uma ao realizada para executar a adaptao.
Figura 29 - Caminho Lgico da Adaptao de Textos
_______________________________________________________________________________________________________________________

Dispositivos Mveis
101
Captulo 7
_______________________________________________________________________________________________________________________________________
7.3.2.
Adaptao de Imagens
Para realizar a adaptao de imagens so utilizados parmetros dos perfis do

dispositivo, do usurio e do contexto. Uma imagem pode ser adaptada de quatro modos,
listados a seguir:
Reduo. O ImgAdapter pode diminuir a imagem para se adequar s dimenses
do dispositivo. O parmetro stretch, do perfil do usurio, consultado para saber se a

reduo deve ou no manter as propores iniciais da imagem.
Mudana de Cores. O ImgAdapter modifica as cores da imagem para as cores
suportadas pelo dispositivo. No caso do dispositivo no ser colorido, a imagem convertida

para os tons de cinza suportados pelo dispositivo.
Converso do Formato. O ImgAdapter altera o formato da imagem para se
adequar ao formato suportado pela plataforma de programao do mdulo cliente que

requisitou a imagem.
Alterao da qualidade. O ImgAdapter modifica os parmetros de qualidade da
imagem para reduzir mais ainda o seu tamanho.

O ImageController ao receber uma requisio de uma imagem de um cliente em um
dispositivo mvel, retira o documento CC/PP da requisio e repassa para o
ProfileManager. Depois de receber os Beans povoados pelo ProfileManager, o mdulo
ImgAdapter acionado. O ImgAdapter inicialmente realiza a converso entre os tipos de
imagem, por exemplo, se a imagem requisitada um JPG e o dispositivo executa J2ME
MIDP 1.0, a imagem convertida de JPG para PNG.
Aps a converso de formatos, o ImgAdapter monta uma chamada de sistema para o
programa Convert que faz parte da coleo da ferramentas para manipulao de imagens
ImageMagick [72]. Essa chamada de sistema contm o caminho do arquivo de imagem
original, os parmetros do usurio, de qualidade e distoro e os parmetros do dispositivo
de nmero de cores e de dimenses. Aps a realizao da converso da imagem, o
ImgAdapter recupera a imagem adaptada e checa se o tamanho da imagem no maior que
a quantidade de memria disponvel no dispositivo quando este fez a requisio. Caso seja
maior, uma pequena imagem com a frase: Memria disponvel insuficiente para a
imagem retornada. Assim, evitada uma possvel falha na execuo da aplicao no
dispositivo mvel.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
102
Captulo 7
_______________________________________________________________________________________________________________________________________
Desta forma, a adaptao de imagens apresentada consiste em uma adaptao de

contedo, em tempo de execuo, ao dispositivo e ao contexto. Na Figura 30,
apresentado o caminho lgico da adaptao de imagens.
Figura 30 - Caminho Lgico da Adaptao de Imagens
7.4. Anlise de Eficincia

Para mostrar as vantagens da adaptao de imagens para dispositivos mveis e validar
os pacotes de adaptao do M-Flog, testes de eficincia da adaptao foram realizados. A
aplicao cliente do M-Flog foi executada em quatro dispositivos: Motorola A388, Nokia
6230, HP Ipaq h4100 e Sony Ericsson P900. Esses dispositivos apresentam diferenas
quanto ao suporte a cores, dimenses do display e plataforma de programao testada.
Alm disso, a aplicao foi executada em cenrios distintos para cada dispositivo: testes
reais numa rede Wi-Fi e numa rede GPRS, e um teste simulado de uma conexo EDGE. Na
Tabela 13, so apresentadas as tecnologias de conexo sem fio utilizadas nos cenrios de
simulao.
Dispositivos
Cor
N Cores
Display
Plataforma
Motorola A388
No
4 tons
260x200 J2ME MIDP 1.0
GPRS
Nokia 6230
Sim
65535
128x128 J2ME MIDP 1.0
GPRS
HP Ipaq h4100
Sim
65535
240X320
Sony Ericsson
P900
Sim
65535
208x320 J2ME MIDP 2.0
Superwaba
Cenrio
IEEE 802.11b
Simulao
EDGE
Tabela 13- Caractersticas dos dispositivos testados
Cinco imagens foram escolhidas para ilustrar o processo de adaptao, elas possuem
tamanhos que variam de 123KB at 660KB. Essas imagens possuem diferentes dimenses
e formatos (i.e., PNG e JPG) e ilustram as imagens que sero colocadas no ambiente real do
M-Flog.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
103
Captulo 7
_______________________________________________________________________________________________________________________________________
Dois tipos de adaptao de imagem foram executados baseados nos parmetros do

usurio: adaptao com qualidade alta e distoro; e adaptao com qualidade baixa e sem
distoro. Duas mtricas so utilizadas para quantificar a avaliao: o tempo de latncia
para realizar o download da imagem adaptada; e o tamanho da imagem adaptada. Cada
teste foi realizado dez vezes em cada dispositivo e aps o descarte do maior e do menor
valor, a mdia dos tempos foi calculada. Os resultados so comparados ao tempo de
latncia para realizar o download da imagem original e o tamanho original da imagem. Na
Figura 31, encontram-se as telas dos processos de adaptao de imagens simulados nos
emuladores dos dispositivos P900 e Nokia 6230. No dispositivo P900 apresentada a
diferena no uso ou no de distoro na adaptao, nos dois casos as imagens tm tamanho
maior do que a imagem adaptada para o dispositivo Nokia 6230.
Figura 31 - Adaptao de imagens nos emuladores dos dispositivos
Na Figura 32, so ilustrados os resultados dos testes no dispositivo Ipaq executando

em uma rede real IEEE 802.11b. So apresentados dois grficos, um referente ao tempo de
latncia de download e outro referente ao tamanho final das imagens. Podemos notar que
nos dois grficos, os dois tipos de adaptao apresentaram ganhos significativos. Com a
imagem real, o tempo de latncia de download variou de 150 a 400 segundos. J com as
imagens adaptadas, o tempo no passou de 35 segundos em todas as imagens. Alm disso,
as imagens foram reduzidas em seu tamanho para menos de 90 Kb. Desta forma, o tempo
de latncia e o tamanho final de cada imagem reduziram pelo menos 95%. A adaptao
com menor qualidade e sem distoro apresentou ganhos ainda maiores.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
104
Captulo 7
_______________________________________________________________________________________________________________________________________
Cenrio
Legenda
Figura 32 - Grficos do Cenrio IEEE 802.11b
Na Figura 33, so ilustrados os grficos dos testes com o dispositivo A388 na rede
GPRS. Esse dispositivo apresentou os maiores tempos de downloads, mesmo quando
comparado ao dispositivo Nokia 6230 que tambm executou os testes no cenrio GPRS. O
tempo de latncia da adaptao teve o valor mximo de 107,08 segundos, que pode ser
considerado inaceitvel para alguns usurios. Contudo, o tempo de download das imagens
originais passava de dez minutos e causava overflow de memria no dispositivo. Assim, a
adaptao das imagens apresentou tambm ganhos sensveis, apesar de o tempo de espera
ainda ser grande.
Na Figura 34, so ilustrados tambm os testes com o dispositivo P900 simulado no
computador com uma conexo do tipo EDGE. Este dispositivo deve a velocidade da rede
apresentou o menor tempo de latncia para download da imagem original. Contudo, a
adaptao ainda obteve ganho de mais de 80% no tempo e de 90% no tamanho.
O tempo de atraso somente da converso das imagens variou de 1,44 a 4,57 segundos
em todas as execues. Esses tempos podem diminuir se o M-Flog for instalado em uma
mquina com maior capacidade de processamento. O M-Flog foi testado em um Pentium
III de 600 MHz com 128 MB de RAM. Com os resultados dos testes apresentados,
podemos constatar que a adaptao realmente possibilitou que os dispositivos possam
_______________________________________________________________________________________________________________________

Dispositivos Mveis
105
Captulo 7
_______________________________________________________________________________________________________________________________________
acessar as imagens do portal M-Flog em tempo satisfatrio e no caso do GPRS e do EDGE

com custo bem menor para os usurios.
Cenrio
Legenda
Figura 33 - Grficos do cenrio GPRS com o A388
Comentrio
Legenda
Figura 34 - Grficos da simulao no cenrio EDGE
_______________________________________________________________________________________________________________________

Dispositivos Mveis
106
Captulo 7
_______________________________________________________________________________________________________________________________________
7.5. Concluso
Neste captulo, foi apresentado como o ambiente proposto nesta dissertao pode ser
utilizado para desenvolver aplicaes multi-plataformas e adaptativas para dispositivos
mveis.
A ferramenta UIG facilita a gerao de cdigo para as plataformas e os frameworks
Requisitor, XFormUI e MobAC diminuem a quantidade de cdigo escrito pelo engenheiro
de software. Uma demonstrao deste fato que a aplicao cliente, apresentada no estudo
de caso, escrita uma nica vez e executada nas trs plataformas. Alm disso, essa
execuo adaptada para cada plataforma com relao ao layout de apresentao das
interfaces.
Os frameworks Mobile Adapter e MobAC oferecem uma forma eficiente de captura e
manipulao dos perfis do usurio, do dispositivo e do contexto. Essas informaes so
indispensveis e fundamentais para que se possam criar sistemas que realizam adaptao de
contedo, o que ilustrado no M-Flog.
A avaliao de eficincia em ambientes reais e simulados demonstra que mesmo
inserindo um passo a mais de converso entre o dispositivo e o recurso desejado, a
adaptao possibilita ganhos significativos no tempo de latncia de download dos recursos
e na diminuio dos pacotes trafegados.
No prximo captulo so apresentadas as principais contribuies dessa dissertao e
trabalhos futuros que podem estender o ambiente proposto.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
107
Captulo 8
_______________________________________________________________________________________________________________________________________
8. Concluso
Esta dissertao apresentou um ambiente para o desenvolvimento de aplicaes adaptativas
e multi-plataformas para dispositivos mveis. Esse ambiente, composto pelos frameworks
XFormUI, Requisitor, Mobile Adapter, MobAC e pela ferramenta UIG, facilita a
construo das interfaces grficas das aplicaes e o desenvolvimento de Moblie
Application Servers (MAS) que realizam adaptao de contedo.
Na seo 8.1, so apresentadas as principais contribuies da dissertao e os
resultados alcanados durante o mestrado. Na seo 8.2, so descritos os trabalhos futuros
que possam estender o ambiente apresentado nesta dissertao.
8.1. Contribuies e Resultados Alcanados

No contexto do desenvolvimento de aplicao para dispositivos mveis, o ambiente
proposto atende ao objetivo de aprimorar e integrar as solues para os desafios de
descrio, independente de dispositivo e plataforma, da interface com usurio; a adaptao
do contedo acessado pelas aplicaes; e o desenvolvimento de aplicaes multiplataformas.
O framework XFormUI possibilita a construo de interfaces grficas com recursos
de validao de dados e layout de componentes. Suas implementaes em Superwaba,
J2ME MIDP 1.0 e J2ME MIDP 2.0 permitem ao engenheiro de software escrever uma
nica vez as interfaces grficas e execut-las de forma adaptativa nas trs plataformas.
A ferramenta UIG de gerao de cdigo diminui o tempo de construo das
aplicaes j que permite a definio das interfaces, dos estilos e da validao dos dados
usando as linguagens declarativas XForms, CSS e XML Schema. Outra importante
contribuio dessa ferramenta o modelo de cdigo gerado que possibilita ao engenheiro
de software escrever apenas os controladores dos formulrios e dessa forma, concentrar-se
nas regras de negcio da aplicao, j que as interfaces j esto construdas. Alm disso, o
plugin do eclipse agiliza a configurao para a gerao de cdigo.
Outra importante contribuio o framework Requisitor que facilita a escrita de
cdigo para realizar a comunicao de dados. Alm disso, as suas implementaes em
_______________________________________________________________________________________________________________________

Dispositivos Mveis
108
Captulo 8
_______________________________________________________________________________________________________________________________________
Superwaba e J2ME MIDP permitem a escrita multi-plataforma de cdigo que envia e

recebe informaes usando HTTP.
Os frameworks Mobile Adapter e MobAC possibilitam a captura, o gerenciamento e a
manipulao das informaes necessrias para a construo de MAS que realizam
adaptao de contedo. O uso de CC/PP e UAProf para servir como fonte de informao
permitem a escalabilidade da abordagem de captura e tornam possvel a implementao de
MAS adaptativos em ambientes reais. O uso de Reflection para a gerao dos Beans do
usurio, do dispositivo e do contexto torna a implementao do framework flexvel de
forma a permitir atravs dos Hot Spots a adio de novos parmetros nos perfis.
O estudo de caso, o M-Flog, alm de ilustrar como o ambiente proposto na
dissertao utilizado, apresenta estratgias e implementaes de adaptao de imagens e
textos que podem ser reutilizadas em outras aplicaes. Alm disso, a avaliao da
eficincia da adaptao apresentada no Captulo 7 comprova as vantagens do uso de
adaptao de contedo para dispositivos mveis.
Alm do ambiente proposto, uma importante contribuio desta dissertao o estudo
e a classificao dos trabalhos de adaptao descritos no Captulo 2. As definies
apresentadas permitem uma melhor compreenso dos desafios e das solues existentes
para a adaptao de aplicaes para DMs.
Finalmente, vale ressaltar que durante o desenvolvimento desta dissertao, foram
publicados artigos relacionados ao desenvolvimento de aplicaes para DMs no
International Conference on Telecommunications - ICT 2004 [3], Simpsio Brasileiro de
Banco de Dados - SBBD 2004 [1], Mobility Aware Technologies and Applications MATA 2004 [4], Salo de Ferramentas do Simpsio Brasileiro de Redes de Computadores
SBRC 2005 [6]. Alm disso, foram aceitos artigos no Advanced International Conference
on Telecommunications - AICT 2005 [2] e tambm um artigo diretamente relacionado ao
trabalho no Semish do Congresso da Sociedade Brasileira de Computao - CSBC 2005
[5].
8.2. Trabalhos futuros

O framework XFormUI pode ser estendido para suportar uma maior quantidade de
eventos e permitir o uso de expresses regulares na definio de restries. Alm disso,
_______________________________________________________________________________________________________________________

Dispositivos Mveis
109
Captulo 8
_______________________________________________________________________________________________________________________________________
esse framework pode ser implementado em outras plataformas de programao, como as

baseadas na linguagem C++ (e.g., BREW [59]) .
Em relao ferramenta UIG, o plugin eclipse da UIG pode ser estendido para
permitir a construo das interfaces grficas das aplicaes, criando uma ferramenta RAD
(Rapid Application Developer). Alm disso, a ferramenta pode ser estendida para suportar
dados complexos e expresses regulares do XML Schema, assim como mapear maior
quantidade de atributos do CSS.
Para melhorar o cdigo gerado pela UIG e facilitar ainda mais a prototipao de
aplicaes, uma forma de especificar em XML as transies entre os formulrios e mapelas para cdigo XFormUI pode ser investigada. O modelo de transio usando mquinas de
estados finitas proposto em [94] pode ser utilizado como ponto de partida. Outro trabalho
futuro, a investigao do uso de palavras reservadas (i.e., inline code atributes) no
XForms e transform-las em cdigos pr-determinados. Estes cdigos podem ser, por
exemplo, chamadas de comunicao de dados, acesso a camadas de persistncia e envio de
dados seguros. Desta forma, a UIG geraria cdigo automaticamente integrado com os
frameworks Requisitor, FramePersist [1] e FrameSec [50].
Outro importante trabalho futuro gerao automtica de interface grfica para
realizar operaes de cadastro, remoo, busca e alterao (i.e., CRUD - Create, Retrieve,
Update e Delete), a partir de uma modelagem dos dados realizadas em UML (Unified
Modeling Language) [91]. Os dados seriam modelados, seguindo uma especificao a ser
investigada, em uma ferramenta de modelagem de UML (e.g., JUDE [93]) e exportados
para o padro XMI (XML Metadata Interchange) [92]. Na ferramenta UIG, seriam criados
XSLTs para mapear de XMI em XMLMiddleForm. Dessa forma, utilizando os processos
de mapeamento apresentados nessa dissertao, esse XML seria transformado em cdigos
executveis de uma linguagem de programao. Esses cdigos, tanto conteriam as
interfaces grficas, como as validaes dos dados e as operaes de CRUD implementadas.
Com relao aos frameworks Mobile Adapter e MobAC, a generalizao dos pacotes
de adaptao apresentados no estudo de caso pode ser realizada para construir um
framework de adaptao de contedo. A esse framework podem ser adicionados outros
tipos de adaptao, como adaptao de streams de vdeo e de udio. Alm disso, o processo
de captura, gerenciamento e manipulao dos perfis apresentados nesses frameworks pode
_______________________________________________________________________________________________________________________

Dispositivos Mveis
110
Captulo 8
_______________________________________________________________________________________________________________________________________
ser integrado ao protocolo ICAP (Internet Content Adaptation Protocol) [95] para permitir
a construo de proxies adaptativos reais.
_______________________________________________________________________________________________________________________

Dispositivos Mveis
111
Captulo 9
_______________________________________________________________________________________________________________________________________
9. Bibliografia
1. MAGALHES, Katy; VIANA, Windson; LEMOS, Fabrcio; CASTRO, Javam de; ANDRADE,
Rossana. Um Framework de Persistncia de Objetos em Aplicaes para Dispositivos Mveis. In:
The Brazilian Symposium on Databases (SBBD 2004). Brasilia-DF, Brasil, Outubro 2004 , 2004.
2. BRINGEL FILHO, Jose Ribamar; VIANA, Windson; CASTRO, Rossana Maria Andrade de.
FRAMESEC: a FRAMEwork for the application development with end-to-end SECurity provision in
the mobile computing environment. Advanced International Conference on Telecommunications AICT 2005.
3. VIANA, Windson, CASTRO, R. M. C., MACHADO, Javam, FILHO, Bringel, MAGALHAES, Katy,
GIOVANO, Carlo. Mobis: A Solution For The Development Of Secure Applications For Mobile
Device. In: ICT: International Conference on Telecommunications, 11th, Fortaleza-CE, Brazil,
2004.. Lecture Notes in Computer Science. , v.3124, p.1015 - 1022, 2004.
4. FILHO, Bringel; VIANA, Windson; CASTRO, R. M. C. PEARL: a PErformance evaluaAtor of
cRyptographic aLgorithms for mobile devices. In: The First International Workshop on Mobility
Aware Technologies and Applications (MATA 2004). Florianpolis-PR, Brasil, Outubro 2004 .
Lecture Notes in Computer Science. MATA 2004 Conference: 275-284, v.3284, 2004.
5. VIANA, Windson; FERNANDES, Paula; TEIXEIRA, Robson; CASTRO, R. M. C. "Mobile
Adapter: Uma abordagem para a construo de Mobile Application Servers adaptativos utilizando
as especificaes CC/PP e UAProf". XXXII Seminrio Integrado de Software e Hardware (SEMISH
2005). No XXV Congresso da Sociedade Brasileira de Computao (CSBC). So Leopoldo-RS,
Brasil, 2005.
6. VIANA, Windson; FILHO, Bringel; CASTRO, R. M. C. PEARL Tools: um Conjunto de
Ferramentas para Avaliao da Eficincia de Algoritmos de Criptografia em Dispositivos Mveis.
Salo de Ferramentas do Simpsio Brasileiro de Redes de Computadores (SBRC 2005). FortalezaCE, Brasil. 2005.
7. PINHEIRO,
Manuele
Kirsch;
VILLANOVA-OLIVER,
M.;
GENSEL,
J.;
MARTIN,
H,
"Representing Context for an Adaptative Awareness Mechanism", in X International Workshop on

Groupware (CRIWG 2004), San Carlos, Costa Rica, Setembro, 2004
8. PINHEIRO, Manuele Kirsch; VILLANOVA-OLIVER, M.; GENSEL, J.; MARTIN, H, "A ContextBased Awareness Mechanism for Mobile Cooperative Users", in International Conference on
Cooperative Information Systems (CoopIS 2004), Larnaca, Cyprus, 25 29. Outubro, 2004.
9. PINHEIRO, Manuele Kirsch; VILLANOVA-OLIVER, M.; GENSEL, J.; MARTIN, H, "Awareness
on Mobile Groupware Systems", in the First International Workshop on Mobility Aware
Technologies and Applications (MATA 2004), , Florianpolis, Brazil, 20-22. Outubro, 2004.
112
Captulo 9
_______________________________________________________________________________________________________________________________________
10. HAGIMONT, Daniel; LAYADA, Nabil. Adaptation d'une application multimdia par un code
mobile. In Technique et Science Informatique (TSI), numro spcial "Agents et code mobile",
Volume 21, Issue 6/2002, Junho, 2002.
11. CASTRO, Mrcio; LOUREIRO, A. A. F. Adaptation in Mobile Computing. In: XXII Simpsio
Brasileiro de Redes de Computadores, 2004, Gramado, RS. Anais do XXII Simpsio Brasileiro de
Redes de Computadores, p.439 452, 2004.
12. LEMLOUMA, T. LAYAIDA, N. Context-aware adaptation for mobile devices. This paper is from
the WAM Project, INRIA, Saint Martin, France. In: Proceedings of IEEE International Conference on
Mobile Data Management, p.106 - 111, 2004.
13. Projeto Sourceforge da linguagem SuperX++. Uma linguagem orientada a objeto baseada em
XML. Disponvel em: <http://xplusplus.sourceforge.net/index.htm>.
Acessado em Setembro de
2004.
14. Site do LiquidUI, ferramenta de UIML. Disponvel em: <http:// www.harmonia.com>. Acessado
em Maro, 2004.
15. HONKALA, M.; VUORIMAA, P.; XForms in X-Smiles. Anais do International Conference on
Web Information Systems Engineering, 2. p203 211. Dezembro, 2001.
16. MUELLER, A.; MUNDT, T.; LINDNER, W.; Using xml to semi-automatically derive user
interfaces. Anais do Uidis 2001. International Workshop on User Interfaces to Data Intensive
Systems, 2., p.91 95, Junho, 2001.
17. MINELLI, ANDR C.O.; LOULEIRO, ANTNIO A.F. Uma ferramenta para desenvolvimento de
aplicaes para dispositivos mveis. SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES
(SBRC), 20., Bzios 2002.
18. Site oficial de O-XML. Disponvel em: <http://www.o-xml.org> . Acessado em maro de 2004.
19. SANTOS, Misael da Silva. Integrao de Modelos de Padres de Software com Ferramentas
de Apoio ao Desenvolvimento de Sistemas: Rose - um estudo de caso. 2004. Dissertao (Cincia
da Computao) - Universidade Federal do Cear.
20. MAGALHAES,Katy. Framepersist: Um Framework de Persistncia de Objetos para o
Desenvolvimento de Aplicaes para Dispositivos Mveis. 2005. Dissertao (Engenharia Eltrica DETI) - Universidade Federal do Cear.
21. SHANKAR, R.; LEE, Brian; FOX, Armando; HANRAHAN, P; ICrafter: A Service Framework for
Ubiquitous Computing Environments. Anais do Ubiquitous Computing Conference (UBICOMP), 21.,
2001.
22. RAATIKAINEN, Kimmo E. E.; Middleware for Mobile Aplications Beyond 3G.
International
Conference on Intelligence in Networks (SMARTNET 2002),7.,p3-18, Abril, 2002.

23. WIEISER, M.; BROWN, J. Designing Calm Technology, PowerGrid J., vol. 1, 1996.
24. WIEISER, M., The Computer for the 21st Century, Scientific American, , p. 94104, vol. 265,
no. 3. Setembro, 1991.
113
Captulo 9
_______________________________________________________________________________________________________________________________________
25. KINDBERG, Tim; FOX, Armando. System Software for Ubiquitous Computing, IEEE Pervasive
Computing, v.1 n.1, p.70-81. Janeiro, 2002.
26. BANAVARF, G. Software Infraestructure and Design Challenges for Ubiquitous Computing
Applications. Communications of the ACM, vol.45, no.12, p.92-96, Dezembro, 2002.
27. ALLAN MENG KREBS; MARSIC, I.; Adaptative Applications For Ubiquitous Collaboration In
Mobile Environments. Annual Hawaii International Conference On System Sciences, 37., p.31
40, 2004.
28. OLSEN, D. R., JEFFERIES, S., NIELSEN, T., MOYES, W., FREDRICKSON, P. Cross-modal
Interaction using Xweb. Anais do UIST 00, p.191-200, Novembro de 2000. San Diego, CA, USA.
29. Site do Frum do UPnP - Universal Plug in Play. Disponvel em: <http://www.upnp.org/>.
Acessado em Maro de 2004.
30. CHI-HSING Chu; CHIEN-HSUAN Huang; LEE, M.; Building an XML-based unified user
interface system under J2EE architecture. Anais do International Symposium on Multimedia
Software Engineering, p.208 214, Dezembro, 2000
31. VILLANOVA-OLIVER, M.; GENSEL, J. ; MARTIN, H. Five models for integrating a progressive
access approach into Web-based Information Systems. The Twelfth International World Wide Web
Conference, Poster session, 20-24 May 2003, Budapest, Hungary.
32. VILLANOVA-OLIVER, M.; GENSEL, J. ; MARTIN, H. Progressive Views for Adaptable Webbased Information Systems. Object-Oriented Information Systems OOIS'02, LNCS, Montpellier,
Setembro 2-5, 2002.
33. GENSEL, J.; FREIRE, J.C. Junior, BARBEIRO, E.; VILLANOVA-OLIVER, M; MARTIN, H.
Adaptable Web Teaching with KIWIS. Int. Conference on Engineering Education (ICEE 2002).
Manchester, UK . 18 - 22 Agosto, 2002.
34. VILLANOVA-OLIVER, M.; GENSEL, J. ; MARTIN, H. Exploiting a progressive access model to
information. 2nd International Conference on Adaptive Hypermedia and Adaptive Web-Based
Systems, LNCS 2347, Ed. Springer, Malaga, Spain, Maio 29-31, 2002.
35. KURUMATANI, K.: Mass User Support by Social Coordination among Citizen in a Real
Environment.In: Chen, Shu-Heng; Ohuchi, Azuma (eds.): Multi-Agent for Mass User Support.
International Workshop (MAMUS 2003). Acapulco, Mexico, Agosto 10, 2003. LNAI, Vol. 3012.
Springer-Verlag, Berlin Heidelberg (2004) 116.
36. W3C- WWW CONSORTIUM, Site do frum de desenvolvimento de tecnologias para Web.
Disponvel em:<http::\\www.w3c.org >. Acessado em Janeiro de 2004.
37. ECLIPSE, Site da ferramenta eclipse. Disponvel em:<http::\\www.eclipse.org >. Acessado em
Janeiro de 2004.
38. RAMOS, Angela Carrillo, VILLANOVA-OLIVER, M.; GENSEL, J.; MARTIN, H. "Modelling with
Ubiquitous Agents a Web-based Information System Accessed through Mobile Devices", in
International Conference on Cooperative Information Systems (CoopIS 2004), Larnaca, Cyprus, 25
29, Outubro, 2004.
114
Captulo 9
_______________________________________________________________________________________________________________________________________
39. TAKAHASHI, K., AMAMIYA, S., IWAO, T.: An Agent-based Framework for Ubiquitous Systems.
In: Challenges in Open Agent Systems '03 Workshop (Challenge03). Melbourne, Australia, July 1415 2003. (2003) http://www.agentcities.org/Challenge03/papers.php. Janeiro, 2004.
40. DORNAN, ANDY. The Essential Guide to Wireless Communication Applications, Prentice Hall
Inc., 2001. ISBN 0-13-031716-0.
41. POSA.Buschmann et al, Pattern-Oriented Software Architecture, Wiley, 1996, ISBN:
0471958697.
42. BlueTooth. Disponvel em: <http://www.bluetooth.com>. Acessado em Agosto de 2003.
43. Java 2 Platform, Micro Edition (J2ME). Disponvel em <http://wireless.java.sun.com>. Acessado
em Maro de 2004.
44. Superwaba: The Java VM for PDAs. Disponvel em < http://www.Superwaba.com.br>.
45. VILJAMAA, A.. Pattern-Based Framework Annotation and Adaptation A systematic Approach,
2001. 118 f. Thesis (Licenciate Thesis in Computer Science) University of Helsinki, Finland.
46. GAMMA, E. R. HELM; JOHNSON, R.; VLISSIDES J. Design Patterns: Elements of Reusable
Object-Oriented Software. Reading, MA: Addison Wesley, 1995.
47. Site da tecnologia XML Composite Capability/Preference Profiles (CC/PP): Structure and
Vocabularie. Disponvel em: <http://www.w3.org/Mobile/CCPP/> . Acessado em Outubro de 2004.
48. PalmOne Aliance. Site da empresa que fabrica os Palms e os handhelds HandSpring.
Disponvel em: <http://www.palmone.com>. Acessado em Outubro de 2004.
49. SANTOS, Misael da Silva. Uma Proposta para a Integrao de Modelos de Padres de
Software com Ferramentas de Apoio ao Desenvolvimento de Sistemas. 104 p, Dissertao
(Mestrado em Cincia da Computao), Universidade Federal do Cear, Fortaleza, 2004.
50. BRINGEL FILHO, Jos de Ribamar Martins. FRAMESEC: Um Framework para a proviso de
segurana fim-a-fim para aplicaes no ambiente de Computao Mvel. 131 p, Dissertao
(Mestrado em Cincia da Computao), Universidade Federal do Cear, Fortaleza, 2004.
51. Java
Plataform
Enterprise
Edition
(J2EE).
Disponvel
em:
<
http://www.java.sun.com/j2ee/index.jsp >. Acessado em Maro de 2004.

52. ABRAMS, M.; PHANOURIOU, C.; BATONGBACAL, A.L.; WILLIAMS, S.M.; SHUSTER, J.;
UIML: An Appliance-Independent XML User Interface Language. International World Wide Web
Conference, 18.,Toronto, Canada, Maio, 1999. Disponvel em: <http://www8.org/w8-papers/5bhypertextmedia/uiml/uiml.html>.
53. KHARE, R.;Can XForm transform the Web? Transcending the Web as GUI II.Internet
Computing, IEEE, Vol 4, p.103 - 106, Abril ,2000.
54. DUBINKO, Micah. XForms Essential. Editora O'Reilly & Associates. ISBN: 0596003692.
Agosto, 2003.
55. Site
de
WebServices
do
Apache,
WebServices
utilizando
SOAP.
Disponvel
em:
<http://ws.apache.org/soap/>. Acessado em Outubro de 2004.
115
Captulo 9
_______________________________________________________________________________________________________________________________________
56. Desenvolvimento
de
aplicae
para
PalmOS
utilizando
C++.
Disponvel
em
<http://www.palmos.com/dev/tools/gcc/>. Acessado em Outubro de 2004.

57. Mophun:
plataforma
de
desenvolvimento
de
jogos
para
celulares.
Disponvel
em
<http://www.mophun.com/ >. Acessado em Outubro de 2004.

58. CODEWARRIOR.
CodeWarrior
for
Palm
OS
v8.0.
Disponvel
em:
<http://www.metrowerksstore.com/palmcomputing.htm>. Acesso em: Setembro 2004.

59. BREW Ambiente de execuo de aplicativos binrios sem fio. Disponvel em:
<http://www.qualcomm.com/brew/>.Acesso em Outubro de 2003.
60. CAPRA, Licia. Mobile Computing Middleware for Context-Aware Applications. In: Proceddings
of International Conference on Software Engineering, 24. p.723-726. Maio, 2002
61. OMOJOKUN, O.; DEWAN, P.; Experiments With Mobile Computing Middleware For Deploying
Appliance Uis. International Conference On Distributed Computing Systems Workshops, 23.,
p.375380, 2003.
62. SUN MICROSYSTEMS. Writing code for the JECF - Java Electronic Commerce Framework.
CA, USA: Sun Microsystems, 1996. Disponvel em: <http://java.sun.com/products> . Acessado em
Setembro 2004.
63. Site da Mquina Micro Java para PalmOs. Disponvel em: <http://www.palmone.com/java>.
Acessado em outubro de 2004.
64. Site do fabricante da Jeode, mquina virtual Personal Profile. Disponvel em: <
http://www.esmertec.com/>. Acessado em outubro de 2004.
65. Banco
de
dados
para
PDAs: IBM
DB2
Everyplace.
Disponvel
em: <http://www-
306.ibm.com/software/data/db2/everyplace/> . Acessado em Outubro de 2004.

66. JOHNSON, R.; FOOTE, B. Designing Reusable Classes. Journal of Object-Oriented
Programming. SIGS, 1, 5 (Junho/Julho. 1988), 22-35. Disponvel em: <http://wwwlifia.
info.unlp.edu.ar/poo2001/DRC.pdf> .
67. ANDRADE, R. Capture, Reuse, and Validation of Requirements and Analysis Patterns for
Mobile Systems. Ph.D. Thesis, School of Information Technology and Engineering (SITE),
University of Ottawa, Ottawa, Ontario, Canada, Maio, 2001.
68. COPLIEN, J. O. Software Patterns. SIGS books and Multimedia, Junho, 1996.
69. Site do XMLBuddy. Plugin para edio de XML para o Eclipse. Disponvel em:
<http://xmlbuddy.com> . Acessado em Outubro de 2004.
70. Site do JavaML. Linguagem de marcao em XML para descrever programas Java. Disponvel
em:
<http://www.cs.washington.edu/research/constraints/web/badros-javaml-www9/>.
Acessado
em Outubro de 2004.
71. Site
do
JAXP.
Java
API
for
XML
Processing.
Disponvel
em:
<http://java.sun.com/xml/jaxp/index.jsp> . Acessado em Outubro de 2004

72. Site do ImageMagick. Disponvel em: <http://www.imagemagick.org/> . Acessado em Outubro
de 2004.
116
Captulo 9
_______________________________________________________________________________________________________________________________________
73. IEEE Std 802.11. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, Maro, 1999.
74. UMAR, Amjad. E-Business and Distributed Systems Handbook: Platforms Module,2003, ISBN:
0972741496.
75. FIGUEIREDO, Thiago H. de Paula, LOUREIRO, A. A. F.MultiMAD: Uma Ferramenta
Multimodelo de Desenvolvimento de Aplicaes para Dispositivos Mveis In: Salo de
Ferramentas, XXIII Simpsio Brasileiro de Redes de Computadores, 2005, Fortaleza.
XXIII
Simpsio Brasileiro de Redes de Computadores. 2005.

76. MENKHAUS, Guido. Adaptive User Interface Generation in a Mobile Computing Environment.
PhD thesis, Salzburg University, 2002.
77. JOHNSON, Ralph E. How to Design Framework. Notes for Proceedings of the Conference on
Object-oriented programming system, languages, and applications - OOPSLA93, University of
Ilinois,
1993.
Disponvel
em:
<ftp://st.cs.uiuc.edu/pub/papers/frameworks/OOPSLA93-frmwk-
tut.ps>. Acessado em Maio de 2004.

78. Site do Projeto Eclipse ME, plugin para construo de aplicaes J2ME no Eclipse. Disponvel
em: <http://eclipseme.org/index.html>. Acessado em Maio de 2005.
79. Site da IDE Sun Java[tm] Studio Mobility. Disponvel em:
<http://developers.sun.com/prodtech/javatools/mobility/downloads/index.jsp>. Acessado em Junho
de 2005.
80. SOUZA, W. L.; BOCHMANN, G. V., EL-KHATIB K., Adaptacao de contedo de mensagens
HTTP baseada em perfis de dispositivo, contedo, usurio e servico de rede (Content adaptation of
HTTP messages based on device, content, user, and network service profiles)", Proceedings of the
20th Brazilian Symposium of Computer Networks, Vol II, pp. 554-568, Buzios-RJ (Brazil), Maio 2024, 2002.
81. LEMLOUMA,
T.;
LAYAIDA,
N.
"Content
Adaptation
and
Generation
Principles
for
Heterogeneous Clients". In : W3C Workshop on Device Independent Authoring Techniques,SAP

University, St. Leon-Rot, Germany, 25-26 Setembro, 2002.
82. LEMLOUMA, T.; LAYAIDA, N. Media Resources Adaptation for Limited Devices. Proceedings
of the 7th ICCC/IFIP International Conference on Electronic Publishing ELPUB 2003 - Universidade
deo Minho, Portugal, Junho 25-28, 2003.
83. LEMLOUMA, T.; LAYAIDA, N. Adaptation et multimedia mobile sur le Web. Mcube 2004, first
national conference on mobile multimedia, Montbliard, France, 30-31. Maro, 2004.
84. RAVI, J.; STEFANO, P.; WULLERT, John. The Mobile Application Server (MAS): An
Infrastructure Platform for Mobile Wireless Services. Information Systems Frontiers. Volume 6,
Number 1, 23-34, Maro, 2004.
85. BERHE, G., BRUNIE, L.; PIERSON, J.M.
Modeling service-based multimedia content
adaptation in pervasive computing. Conf. Computing Frontiers, 60-69, 2004.
117
Captulo 9
_______________________________________________________________________________________________________________________________________
86. Satellite Forms. Plataforma RAD para o desenvolvimento em Palm OS e Pocket PC. Disponvel
em: <http://www.satelliteforms.net/>. Acessado em Abril de 2004.
87. JOHNSON, R. E.; FOOTE, B. Designing Reusable Classes. Journal of Object-Oriented
Programming, 1988. Disponvel em:<ftp://st.cs.uiuc.edu/pub/papers/frameworks/designingreusable-classes.ps>. Acessado em Maio de 2003.
88. Site Internacional do Phlog. Disponvel em:http://www.phlog.net/. Acessado em Maio 2005.
89. BERHE, Girma; BRUNIE, Lionel; PIERSON, Jean-Marc, Modeling Service-Based Multimedia
Content Adaptation in Pervasive Computing, ACM Proceedings of the first conference on
computing frontiers (CF04). Ischia , Italy , Abril 14 - 16, 2004 pp. 60 69.
90. Site do Framework MVC Maverick. Disponvel em: <http://mav.sourceforge.net/>. Acessado
em Novembro de 2004.
91. Site do UML - Unified Modeling Language. Disponvel em: <http://www.uml.org>. Acessado em
Junho de 2005.
92. Tecnologia
XMI
XML
Metadata
Interchange.
Disponvel
em:
<http://www.omg.org/technology/documents/formal/xmi.htm>. Acessado em Abril de 2005.

93. Site da ferramenta livre Jude de modelagem de UML. Disponvel em: <http://www.esm.jp/judeweb/en/index.html> Acessado em Maro de 2005.
94. Jalal Kawash. Declarative user interfaces for handheld devices. In WISICT 04: Proceedings of
the winter international synposium on Information and communication technologies, pages 16.
Trinity College Dublin, 2004.
95. ICAP: Internet Content Adaptation Protocol. Disponvel em: <http://www.i-cap.org/home.html>.
96. Site da especificao XML User Agent Profilling Specfication (UAProf). Disponvel em:
<http://www.openmobilealliance.org/ >. Acessado em Novembro de 2004.
97. P900 UAProf. Disponvel em:<http://wap.sonyericsson.com/UAprof/P900R101.xml>. Acessado
em Novembro de 2004.
98. Site
da
especificao
Java
Beans.
Disponvel
em:
<http://java.sun.com/products/javabeans/docs/spec.html>. Acessado em Janeiro de 2005.

99. SZWARCFITER, Jayme L., MARKENSON, Lilian. Estrutura de Dados e seus Algoritmos. Ed.
LTC - Livros Tcnicos e Cientficos, 1994.
100. GUIMARES, Renato. Tutorial Web sobre a tcnica de Reflection. Disponvel em:
<http://www.linhadecodigo.com.br/artigos.asp?id_ac=264&sub=0 >. Acessado em Maro de 2005.
101. API
Commom
Bean
Utils
para
uso
de
Reflection.
Disponvel
em:
<http://jakarta.apache.org/commons/beanutils/>. Acessado em Maro de 2005.

102. VOELTER, M., A Catalog of Patterns for Program Generation, EuroPlop2003. Disponvel em:
http://www.voelter.de/data/pub/ProgramGeneration.pdf. Acessado em maro de 2005.
118

Um Ambiente de Desenvolvimento de Aplicações Multi-Plataformas e Adaptativas para Dispositivos Móveis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Um Ambiente de Desenvolvimento de Aplicações Multi-Plataformas e Adaptativas para Dispositivos Móveis

Uploaded by

Copyright:

Available Formats

Universidade Federal do Cear

Um Ambiente de Desenvolvimento de Aplicaes MultiPlataformas e Adaptativas para Dispositivos Mveis

Windson Viana de Carvalho

Um Ambiente de Desenvolvimento de Aplicaes Multi-Plataformas e

Este exemplar corresponde redao

corrigida e defendida por Windson

Fortaleza, 14 de junho de 2005

Rossana Maria de Castro Andrade

Dissertao apresentada ao Mestrado de

CARACTERIZAO DO PROBLEMA E MOTIVAO ................................................. 12

ADAPTAO PARA DMS: DESAFIOS E SOLUES...................................... 18

DEFINIO E CARACTERSTICAS DE ADAPTAO .................................................. 18

PLATAFORMAS DE PROGRAMAO PARA DMS E FRAMEWORKS ...... 36

USER INTERFACE GENERATOR ........................................................................ 67

FRAMEWORKS MOBILE ADAPTER, REQUISITOR E MOBAC..................... 80

CC/PP E UAPROF ................................................................................................. 80

ESTUDO DE CASO ................................................................................................... 92

CONTRIBUIES E RESULTADOS ALCANADOS................................................... 108

BIBLIOGRAFIA ...................................................................................................... 112

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interface

Composite Capability/Preference Profiles

Connected Limited Device Configuration

Cascading Style Sheets

Enhanced Data GSM Environment

GNU General Public License

General Packet Radio Service

Global System for Mobile Communications

HyperText Markup Language

Integrated Development Environment

Institute of Electrical and Electronic Engineers

Java 2 Enterprise Edition

Java 2 Micro Edition

Java 2 Standard Edition

Kilobyte Virtual Machine

Local Area Network

Lesser General Public License

Mobile Application Server

Mobile Information Device Profile

Mobile Adapter Client

Negotiation and Adaptation Core

Personal Digital Assitant

Real-Time Transport Protocol

Software Development Kit

Synchronized Multimedia Integration Language

Structured Query Language

User Agent Profiling

User Interface Description

User Interface Generator

Universal Plug and Play

Voice Extensible Markup Language

World Wide Web Consortium

Wireless Application Protocol

Wireless Local Area Network

Wireless Markup Language

Extensible HyperText Markup Language

eXtended Markup Language

eXtensible Stylesheet Language

eXtensible Stylesheet Language Transformation

1.1. Caracterizao do Problema e Motivao

[22][76][12][25][26], destacam-se os seguintes: a descrio, independente de dispositivo e

Um Ambiente de Desenvolvimento de Aplicaes Multi-Plataformas e Adaptativas para

plataforma, da interface com usurio; a adaptao do contedo acessado pelas aplicaes; e