Post on 08-Apr-2018
8/7/2019 Caso de uso JME
1/71
Coordenacao do Curso de Ciencia da Computacao
Universidade Estadual de Mato Grosso do Sul
Desenvolvendo um Estudo de Caso
Utilizando a Plataforma Java ME
Lais Claudia ZanfolimRodolfo Chaves Fernandes
Andre Chastel Lima (Orientador)Celso G. Camilo Jr (Co-orientador)
Dezembro de 2009
8/7/2019 Caso de uso JME
2/71
Desenvolvendo um Estudo de CasoUtilizando a Plataforma Java ME
Lais Claudia Zanfolim
Rodolfo Chaves Fernandes
Este exemplar corresponde a redacao final
da monografia da disciplina Projeto Final de
Curso devidamente corrigida e defendida por
Lais Claudia Zanfolim
Rodolfo Chaves Fernandes e aprovada pela
Banca Examinadora, como parte dos requisi-
tos para a obtencao do ttulo de Bacharel em
Ciencia da Computacao.
Dourados, 11 de dezembro de 2009.
Andre Chastel Lima (Orientador)
Celso G. Camilo Jr (Co-orientador)
ii
8/7/2019 Caso de uso JME
3/71
Coordenacao do Curso de Ciencia da Computacao
Universidade Estadual de Mato Grosso do Sul
Desenvolvendo um Estudo de Caso
Utilizando a Plataforma Java ME
Lais Claudia ZanfolimRodolfo Chaves Fernandes
Dezembro de 2009
Banca Examinadora:
Andre Chastel Lima (Orientador)
Celso G. Camilo Jr (Co-orientador)
Raquel Marcia Muller
Nielsen Cassiano Simoes
iii
8/7/2019 Caso de uso JME
4/71
Resumo
A plataforma Java Micro Edition e o conjunto de tecnologias que permitem o de-
senvolvimento de aplicacoes Java para dispositivos com processamento, memoria e vdeo
limitados, como celulares e smartphones. Assim como as outras edicoes Java, essa pla-
taforma foi desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas
APIs para o desenvolvimento, o Java ME tambem fornece compatibilidade entre as edi-
coes Java, possibilitando a comunicacao com aplicacoes construdas em Java SE e Java
EE. Mantendo o foco em Java Micro Edition, este trabalho propoe o desenvolvimento de
uma aplicacao movel que una as tecnologias Java ME e Java EE. Como o Java Enterprise
Edition possui varias funcionalidades de redes e Internet e contem classes especialmente
desenvolvidas para acesso a servidores e banco de dados, parte da aplica cao foi construda
usando esta tecnologia, possibilitando a comunicacao entre dispositivos moveis e um servi-
dor disposto na rede local ou Internet. Portanto, neste trabalho foi abordado, juntamente
com a plataforma Java ME, o uso de Servlets dentro da arquitetura Java EE, interagindo
com um cliente movel atraves do protocolo HTTP para estabelecer a comunicacao com
celulares e smartphones. Visto que um Servlet pode efetuar qualquer processamento ine-rente a uma classe Java e enviar respostas na forma de documentos XML, para efetuarmos
a troca de dados entre um dispositivo movel e o servidor remoto de dados, que alimenta o
sistema movel, utilizamos os recursos que a linguagem XML nos oferece. Para auxiliar o
desenvolvimento do estudo de caso, a metodologia agil extreme programming foi utilizada
juntamente com diagramas da UML com o intuito de organizar o processo de desenvolvi-
mento. A aplicacao desenvolvida durante o trabalho e responsavel por agilizar o processo
de vendas de uma distibuidora de bebidas, a fim de automatizar a forca de vendas e foi
testada em celulares e smartphones com o sistema operacional movel Symbian e Windows
Mobile, interagindo com o servidor via requisicoes HTTP.
Palavras Chave: Java ME, mobilidade, celulares e smartphones.
iv
8/7/2019 Caso de uso JME
5/71
8/7/2019 Caso de uso JME
6/71
Agradecimentos
Agradecemos primeiramente a Deus, por ter nos abencoado durante toda nossa vida
e principalmente por ter nos dado forcas durante todo o decorrer do trabalho.
Aos nossos familiares, pela confianca, apoio e educacao durante toda nossa caminhada.
Ao nosso orientador Andre Chastel Lima, pelo apoio e compreensao.
Ao nosso co-orientador Celso Camilo, pelo incentivo e paciencia.
A toda academia, que nos proporcionou as condicoes necessarias para o desenvolvi-
mento deste trabalho, em especial os professores Odival Faccenda e Glaucia Gabriel Sass.
Aos funcionarios da eXclaim, por nos dar a oportunidade de estagiar na empresa e
desenvolver projetos com a tecnologia Java ME.
Aos leitores e colaboradores do javamovel.com, pela lealdade e por nos incentivar a
estudar o tema do projeto.
Enfim, agradecemos todos aqueles que contriburam para o sucesso desta caminhada
e que de forma injusta nao tiveram seus nomes includos aqui.
vi
8/7/2019 Caso de uso JME
7/71
Sumario
Resumo iv
Abstract v
Agradecimentos vi
1 Introducao 3
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Sistemas operacionais para dispositivos moveis 6
2.1 Dispositivos Moveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Sistemas Operacionais e suas tecnologias . . . . . . . . . . . . . . . . . . . 7
2.2.1 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5 BlackBerry OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.6 Iphone OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Analise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Java Micro Edition 11
3.1 Visao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Configuracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Maquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Pacotes Opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
8/7/2019 Caso de uso JME
8/71
8/7/2019 Caso de uso JME
9/71
Lista de Figuras
3.1 Elementos da plataforma Java ME. . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Arquitetura da plataforma Java. . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Ciclo de vida do MIDlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Hierarquia de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Record Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1 Arquitetura da plataforma Java EE. . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Servlet container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3 Ciclo de vida do servlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4 Estrutura do XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1 Esquema de comunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.2 Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Estoria 1-A: Consulta de produtos. . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Estoria 1-B: Consulta e cadastro de clientes. . . . . . . . . . . . . . . . . . 447.5 Estoria 2-A: Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Estoria 2-B: Alteracao de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.7 Estoria 2-C: Envio dos dados para o banco central da empresa. . . . . . . . 46
7.8 Diagrama de classe de projeto - Produto. . . . . . . . . . . . . . . . . . . . 47
7.9 Diagrama de classe de projeto - Cliente. . . . . . . . . . . . . . . . . . . . 47
7.10 Diagrama de classes de projeto. . . . . . . . . . . . . . . . . . . . . . . . . 48
7.11 Autenticacao do usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.12 Menu principal da aplicacao movel. . . . . . . . . . . . . . . . . . . . . . . 51
7.13 Cadastro de Clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.14 Busca de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.15 Detalhamento de produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.16 Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.17 Lista de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
8/7/2019 Caso de uso JME
10/71
Lista de Siglas
AM - Application Manager
API - Application Programming Interface
CDC - Connected Device Configuration
CGI - Common Gateway Interface
CLDC - Connected Limited Device Configuration
CVM - Compact Virtual Machine
DTD - Document Type Declaration
FP - Foundation Profile
GP - Game Profile
GPS - Global Positioning System (Sistema de Posicionamento Global)
HTTP - HyperText Markup Language
HTTP - Hypertext Transfer Protocol
J2SE - Java 2 Standard Edition
JAD - Java Decompiler
JAR - Java ArchiveJava EE - Java Enterprise Edition
Java ME - Java Micro Edition
JCP - Java Community Process
JNI - Java Native Interface
JSP - Java ServerPages
JVM - Java Virtual Machine
KVM - K Virtual Machine
LWUIT - LightWeight User Interface Toolkit
MIDP - Mobile Information Device Profile
MMAPI - Mobile Media APIMMS - Multimedia Messaging Service (Servico de Mensagem Multimdia)
MSA - Mobile Service Architecture
OpenCL - Open Computing Language
OpenGL - Open Graphics Library
1
8/7/2019 Caso de uso JME
11/71
2
PBP - Personal Basis Profile
PC - Personal Computer
PDA - Personal Digital Assistants
PDAP - PDA Profile
PP - Personal ProfileRAD - Rapid Application Development
RAM - Random Access Memory
RIM - Research in Motion
RMI - Remote Method Invocation
RMIP - Remote Method Invocation Profile
RMS - Record Management System
SDK - Software Development Kit
SMS - Short Message Service
SO - Sistema OperacionalUML - Unified Modeling Language
VM - Virtual Machine
W3C - World Wide Web Consortium
WAV - WAVEform audio format
WTK - Wireless ToolKit
XML - eXtensible Markup Language
8/7/2019 Caso de uso JME
12/71
Captulo 1
Introducao
Com a expansao da Internet e da utilizacao de aplicacoes, surgiram diversas linguagens
de programacao, tendo destaque as de multiplataforma, como e o caso do Java, que podeser aplicado em diversos setores, como aparelhos eletronicos, telefones celulares, aplicacoes
para Web e desktop, entre outros. Levando em consideracao os diferentes setores, tornou-
se necessario a criacao de kits de desenvolvimento diferenciados.
A proposta inicial parte do interesse pela linguagem de programacao Java, em espe-
cfico Java Micro Edition - Java ME. E uma plataforma que permite o desenvolvimento
de aplicacoes Java para dispositivos com processamento, memoria e vdeo limitados, tais
como celulares e smartphones. Assim como as outras edicoes Java, essa tecnologia foi
desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas APIs (Ap-
plication Programming Interface) para o desenvolvimento. O Java ME tambem fornece
compatibilidade entre as edicoes Java, possibilitando a comunicacao com aplicacoes JavaSE (Java Standard Edition) e Java EE (Java Enterprise Edition).
A Java Community Process - JCP, especifica o Java ME em dois grupos:
CDC - Connected Device Configuration: para dispositivos com maior capacidade
computacional.
CLDC - Connected Limited Device Configuration: para dispositivos com menor
capacidade computacional e normalmente usado em aplicacoes embarcadas.
Dentro desta ultima configuracao existe uma outra classificacao que define os perfis dos
dispositivos. No caso de celulares e smartphones a classificacao usada e o MIDP, MobileInformation Device Profile. Dentro desta classificacao, se ocorrer a migracao de aplicacoes
para outros celulares com a mesma configuracao elas nao perdem sua funcionalidade
(TOPLEY, 2002).
Para otimizar o funcionamento de aplicacoes em celulares a Sun desenvolveu maquinas
virtuais Java especficas para cada configuracao, que manipulam de maneira mais eficiente
3
8/7/2019 Caso de uso JME
13/71
1.1. Objetivos 4
a codificacao desse tipo de dispositivos.
Com a criacao deste ambiente de desenvolvimento torna-se viavel a construcao de
aplicacoes para dispositivos moveis com maior produtividade e portabilidade (MUCHOW,
2001).
1.1 Objetivos
O objetivo principal deste trabalho e desenvolver um estudo de caso aplicando os prin-
cipais conceitos da plataforma Java ME e utilizar a plataforma Java EE para constru cao
de um servidor que sera responsavel pela troca de dados com a aplicacao movel.
Para alcancar o objetivo principal, as seguintes etapas foram efetuadas:
Fazer um breve estudo sobre as plataformas de dispositivos moveis;
Estudar a plataforma Java ME, voltada para dispositivos moveis;
Estudar a plataforma Java EE para a construcao de um servidor remoto;
Estudar a comunicacao entre o servidor e a aplicacao movel;
Estudar alguns frameworks Java ME e definir quais serao utilizados no estudo de
caso;
Definir os padroes da Engenharia de Software que serao utilizados na aplicacao;
Definir o estudo de caso; Desenvolver e testar o estudo de caso.
1.2 Justificativa
Segundo dados divulgados pela Agencia Nacional de Telecomunicacoes (Anatel), o
numero de linhas de telefones moveis no pas chegou a aproximadamente 152,4 milhoes,
em fevereiro de 2009, o que corresponde a 79,94% da popula cao (AGENCIAESTADO,
2009).
Em nvel mundial, o numero de usuarios de telefones moveis chegou perto de 3 bilhoesem 2007, atingindo 48% da populacao e a estimativa para o final de 2008 era de 4 bilh oes,
o que corresponde a 61%, segundo a Uniao Internacional de Telecomunicacoes (UIT)
(REUTERS, 2008).
Segundo Eric Klein, vice-presidente de marketing do Java, em entrevista a Reuters, o
Java esta instalado em 2,6 bilhoes de telefones em todo o mundo (VIRKI, 2009). Visto
8/7/2019 Caso de uso JME
14/71
8/7/2019 Caso de uso JME
15/71
Captulo 2
Sistemas operacionais para
dispositivos moveis
A tecnologia da informacao atinge a maior parte das empresas e instituicoes de forma
que fiquem dependentes de sistemas que ajudam ou otimizam o trabalho e a comunicacao
dentro das mesmas. Com a massificacao de computadores e Internet surge um outro
conceito: Mobilidade. O poder de carregar as informacoes para qualquer ambiente e
evidentemente util para empresas que trabalham com base de dados e um fator essencial
para se destacar no mercado e ter acesso as informacoes em tempo real.
Sendo evidente o impacto que solucoes de softwares moveis tem e terao nos proximos
anos, e de extrema importancia conhecer os sistemas operacionais moveis do mercado
e quais tipos de aplicacoes cada um deles suporta. Assim, e apresentada uma breve
analise dos principais sistemas operacionais para dispositivos moveis mais importantes daatualidade.
Neste captulo tambem sao explanados os principais tipos de dispositivos moveis e suas
tecnologias, visando uma abordagem completa dos requisitos necessarios para construir
aplicativos de sucesso.
2.1 Dispositivos Moveis
Primeiramente e importante esclarecer que o termo Palm e utilizado para PDAs (As-
sistente Pessoal Digital) ou Handhelds, que sao computadores de mao que fornecem asfuncoes basicas de um computador pessoal, como acesso a Internet, programas de cadas-
tros, agenda, controle financeiro, controle de vendas, planilhas, documentos entre outras
aplicacoes da categoria (PALMBRASIL, 2009a).
O smartphone e uma categoria de telefone celular com caractersticas que antes eram
encontradas somente em Palms e PCs (Personal Computers). PoketPC e o nome que
6
8/7/2019 Caso de uso JME
16/71
2.2. Sistemas Operacionais e suas tecnologias 7
a Microsoft usa para a categoria de PDAs, que difere dos smartphones por agregar ca-
ractersticas como uma tela maior e sensvel a toque, suporte wi-fi, bluetooh, integracao
com GPS (Global Positioning System), enfim, tecnologias que o tornam mais robusto
(MICROSOFT, 2009b).
2.2 Sistemas Operacionais e suas tecnologias
Nesta secao abordaremos as principais caractersticas dos sistemas operacionais moveis
mais utilizados no mercado, bem como suas tecnologias.
2.2.1 Symbian
Comecaremos entao com o sistema operacional para telefones moveis que desde 1998
lidera o mercado mundial, o Symbian OS, ou simplesmente Symbian. Ele possui suporteMMS (Multimedia Messaging Service), bluetooh, wireless, infra-vermelho, entre outras
funcoes que tornam-se extremamente importantes quando o assunto e mobilidade. Este
SO possui um sistema grafico bem simples e atualmente e o sistema mais usado pelos
maiores fabricantes de telefones moveis do mundo, porem com o surgimento de novas
tecnologias e plataformas, vem apresentando queda. Por ser um sistema operacional
que controla muito bem o consumo de memoria, o consumo de energia, o processamento,
entre outros fatores essenciais, as empresas mais poderosas da telecomunicacao investiram
bastante para que este fosse um sistema promissor para o mercado.
Empresas como Nokia, Samsung, Panasonic, Ericsson e Sony Ericsson, foram as res-
ponsaveis pela ascendencia desse modelo de sistema operacional movel. Segundo a INFO(2008), atualmente a Nokia possui a totalidade das acoes da empresa britanica de software
(Symbian), liderando o mercado mundial com 38,9% de participacao e promete concorrer
com o mais novo sistema operacional para dispositivos moveis - Android.
O Symbian suporta sistemas divididos em modulos, desta forma cada empresa pode
criar sua propria interface. Permite o uso de varias linguagens de programacao, entre
as mais importantes estao: Symbian C/C++, Java ME, FlashLite, Perl, Python, Ruby,
entre outras. Assim se o aparelho nao possui certa funcionalidade, fica facil de integrar a
mesma (SYMBIANBRASIL, 2009).
2.2.2 Android
O Android e um sistema operacional baseado em Linux voltado para smartphones,
criado pela Google em consorcio com mais de 40 empresas. Utiliza uma maquina virtual
que foi projetada para otimizar a memoria e os recursos de hardware em um ambiente
8/7/2019 Caso de uso JME
17/71
2.2. Sistemas Operacionais e suas tecnologias 8
movel. E a primeira plataforma open source para desenvolvimento de aplicacoes moveis,
portanto e livre para incorporar novas tecnologias. Por ser um SO mais novo no mercado
esta em aceitacao, positiva por sinal, pelos usuarios e desenvolvedores, pois agrega todas
as funcionalidades que os aparelhos moveis mais atuais fornecem. E importante ressaltar
que os servicos da Google passam a ser facilmente acoplados com as tecnologias moveisapos o surgimento do Android, ja que o interesse e os investimentos atuais da empresa
visam a mobilidade.
Entre os servicos oferecidos estao: Cliente de e-mail, programa para SMS (Short Mes-
sage Service), calendario, mapas, navegador e gerenciador de contatos. Tudo construdo
em Java, desta forma os desenvolvedores Java podem construir aplicativos e disponibiliza-
los. Os desenvolvedores tem acesso a mesma API utilizada nos aplicativos centrais, po-
dendo aproveita-las livremente.
Alem dos aplicativos feitos em Java, o Android possui um conjunto de bibliotecas
C/C++ usadas por diversos componentes que permitem trabalhar com arquivos de mdia,exibicao de conteudo em 2D e 3D, inclusive bibliotecas implementadas utilizando OpenGL
(Open Graphics Library) e um poderoso banco de dados relacional, o SQLite (Developers,
2009).
2.2.3 Windows Mobile
Windows Mobile e um sistema operacional para dispositivos moveis, projetado para
realizar boa parte das funcoes existentes no Windows para PC. Ele pode ser instalado
em PDAs, PocketPC, smartphones e aparelhos de multimdia em geral. (MICROSOFT,
2009b).Possui uma interface intuitiva, e seguro, permite acesso a Internet, inclusive envio e
recebimento de e-mails, possui conectividade bluetooth e wi-fi, alem de versoes moveis
dos aplicativos da Microsoft Office, como: Word, Excel e Power Point. O SO suporta
aplicativos desenvolvidos em linguagens como C, C#, VB.Net, Java ME, Visual Basic,
Python, FlashLite, entre outras, alem de possuir um interpretador para PHP (MICRO-
SOFT, 2009a).
2.2.4 Palm OS
Palm OS e um sistema operacional desenvolvido pela PalmSource para rodar em PDAs.Entre as versoes da linha temos: O Palm OS Garnet e, o atualmente mais usado, Palm
OS Cobalt.
No Palm OS Cobalt o sistema roda em 32 bits, possibilitando que os aplicativos fiquem
muito mais rapidos e com recursos extras. No Palm OS Garnet (5.x) apenas algumas
partes dos aplicativos sao em 32 bits, ja que maior parte simula processadores antigos da
8/7/2019 Caso de uso JME
18/71
2.2. Sistemas Operacionais e suas tecnologias 9
Motorola. A desvantagem e que as aplicacoes criadas utilizando os novos recursos nao
irao funcionar em equipamentos com versoes anteriores do sistema.
As linguagens mais utilizadas para o desenvolvimento de aplicacoes no Palm OS e
o Pascal e o C/C++. Vale ressaltar que a ultima possui uma grande quantidade de
frameworks e e mais usada no desenvolvimento de jogos. Importante dizer que existemaplicativos que convertem aplicacoes em Java para que possam ser utilizadas em Palm
OS, uma otima sada para escapar do padrao de desenvolvimento em palms. Existem
ainda outras linguagens para Palm OS, mas que nao possuem tantos recursos, tais como:
Satellite Forms, Codewarrior, AppForge, NSBasic, CASL e PDAToolBox.
Existem ferramentas RAD (Rapid Application Development) muito bem documenta-
das para auxiliar no desenvolvimento em Palm OS, e o caso da Handheld Basic (HB++),
que e muito bem aceita pela comunidade de desenvolvedores . O PocketStudio e outra
ferramenta de desenvolvimento do tipo RAD, semelhante ao Delphi, que ajuda muitos
desenvolvedores a construir aplicacoes com maior facilidade para o Palm OS. Atualmenteessas sao as mais usadas no desenvolvimento de aplicacoes comerciais para palms.
Apos a PalmSource ser comprada pela Access as proximas versoes devem ser baseadas
no sistema operacional Linux. Atualmente os dispositivos palms estao sendo comerciali-
zados tambem com Windows Mobile justamente pelas restricoes para o desenvolvimento
no sistema operacional Palm OS (PALMBRASIL, 2009b).
2.2.5 BlackBerry OS
O BlackBerry OS e o sistema operacional para smartphones BlackBerry da empresa
Canadense RIM (Research in Motion). O SO possui como ponto sobressalente a suaconsagrada ferramenta de sincronizacao de e-mails. Assim que o servidor recebe o e-mail
este e enviado para o dispositivo. Inicialmente deixava a desejar no quesito design, porem
passa por constantes aprimoramentos neste quesito e em outros recursos. Suas versoes
mais atuais apresentam recursos como menus recolhveis, navegacao por fotos, gerenciador
de arquivos dedicado e oferece suporte para aplicativos desenvolvidos em Java ME (RIM,
2009).
E o terceiro sistema operacional para dispositivos moveis mais vendido do mundo e o
segundo dos Estados Unidos. Teve um crescimento muito rapido, chegando a ser o mais
vendido nos Estados Unidos no primeiro trimestre de 2009 (ADMOB, 2009).
2.2.6 Iphone OS
O Iphone OS e o sistema operacional proprietario do Iphone, desenvolvido pela Apple.
Atualmente conhecido como Mac OS X Snow Leopard, semelhante ao sistema OS X que
roda nos computadores Macintosh. Este SO introduziu diversas tecnologias de primeira
8/7/2019 Caso de uso JME
19/71
2.3. Analise do Mercado 10
linha com uso de 64 bits, proporcionando a mais rapida implementacao de javascript e
acesso a Web, chegando a ser 53 vezes mais rapido quando usa o mini navegador Safari.
Outra poderosa tecnologia implementada e o OpenCL(Open Computing Language) que
possibilita aos desenvolvedores maior otimizacao em aplicacoes que usam recursos grafi-
cos. Possui uma tecnologia de multicondutores que agiliza a distribuicao de tarefas emmultiplos processadores (APPLE, 2009a).
Em comparacao ao Android por exemplo, e notavel que o sistema operacional do
Iphone e muito superior em qualidade e eficiencia, ainda mais se compararmos o acesso a
Web, pois o Iphone ja conquista e domina o mercado e nao deixa a desejar em nenhum
aspecto, com excecao do custo. A linguagem de desenvolvimento para o iPhone e o
Objective-C, que e muito utilizada na plataforma MAC. Ela e orientada a objetos e
difere do C no acrescimo de transmissao de mensagens, ao estilo da linguagem Smalltalk.
Tambem existem iniciativas Open Source para converter codigos em Python para C ou
tambem de Java para Objective-C.Para desenvolver aplicativos para o Iphone OS e necessario utilizar o Cocoa, um con-
junto de frameworks orientado a objetos que disponibiliza um ambiente de execucao para
as aplicacoes serem executadas em MAC OSX e Iphone OS. E o unico ambiente de apli-
cacao para Iphone OS. As aplicacoes existentes no MAC OSX e no Iphone OS sao Cocoa,
portanto para desenvolver aplicacoes Java para o sistema operacional do Iphone e neces-
sario usar ferramentas que convertem o codigo Java para a implementacao da biblioteca
Cocoa. Tambem existem frameworks para converter Python, Ruby, Perl, C# e Objective-
Basic em Objective-C, utilizando o Cocoa (APPLE, 2009b).
2.3 Analise do Mercado
As plataformas da Apple, Google e Palm sao, hoje, as que mais se destacam no mer-
cado mundial. Segundo JONES (2009), analista de mobilidade e tecnologias sem fio do
Gatener, a Microsoft esta lutando para sobreviver no celular, pois se voltou demais para
o mercado corporativo e deixou de lado o mercado domestico, ficando fraca diante do
iPhone, Symbian e Android.
Apenas tres plataformas devem sobreviver, mas e difcil dizer hoje exatamente quais
sao. E uma batalha de ecossistemas que dependem de fatores como recursos do equi-
pamento, estilo, preco e oferta de aplicativos e nao so da plataforma em si. (JONES,
2009).
8/7/2019 Caso de uso JME
20/71
Captulo 3
Java Micro Edition
Neste captulo sao apresentadas as caractersticas da plataforma Java Micro Edition
(Java ME), bem como suas tecnologias e arquitetura.
3.1 Visao geral
Segundo a SUN (2009b), o Java ME e uma colecao de tecnologias e especificacoes que criam
uma plataforma que se ajusta aos requisitos de dispositivos moveis tais como produtos de
consumo, dispositivos embarcados e dispositivos moveis avancados.
O Java ME e a plataforma Java voltada para dispositivos que possuam capacidade de
memoria, tela e processamento restritos. Foi construda com o objetivo de fornecer um
ambiente de execucao Java capaz de lidar com as caractersticas particulares de pequenos
dispositivos.
Para utilizar a mesma plataforma em dispositivos diferentes o Java ME foi baseado
em tres elementos, especificados pela comunidade JCP, que define todos requisitos da
plataforma Java, incluindo a especificacao de APIs. Os tres elementos citados sao: Con-
figuracoes, perfis e pacotes opcionais, os quais funcionam sobre uma maquina virtual
Java, por sua vez ligada a um sistema operacional. Dessa forma podemos representar a
hierarquia dos elementos nas camadas apresentadas na Figura 3.1.
11
8/7/2019 Caso de uso JME
21/71
3.1. Visao geral 12
Figura 3.1: Elementos da plataforma Java ME.
Na camada de configuracao sao definidas as bibliotecas necessarias para o funciona-
mento da maquina virtual. A JCP especificou o Java ME em duas configuracoes de acordo
com as necessidades dos dispositivos: CLDC (Connected, Limited Device Configuration)e CDC (Connected Device Configuration), de forma que:
CLDC especifica o ambiente Java para dispositivos com capacidades mais restritas,
como telefones celulares, PDAs e smartphones.
CDC e destinada a dispositivos com maior capacidade de memoria e processamento,
como TV digital, dispositivos sem fio de alto nvel e sistemas automotivos.
Dentro da configuracao existe uma outra classificacao, os perfis. Estes formam um
conjunto de aplicacoes que complementa uma configuracao e fornece funcionalidades para
desenvolver um aplicativo para determinado dispositivo.
O perfil associado a CLDC e o MIDP (Mobile Information Device Profile). E os asso-
ciados a CDC sao: FP (Foundation Profile), PP (Personal Profile), PBP (Personal Basis
Profile), RMIP (Remote Method Invocation Profile) e GP (Game Profile) (JOHNSON,
2007).
Os principais pacotes opcionais estao inseridos em um conjunto de APIs utilizadas com
as configuracoes e perfis para estender funcionalidades nao encontradas nos respectivos
pacotes, como APIs para bluetooh e wireless.
Quanto a maquina virtual, a JCP especifica a CDC HotSpot Implementaion e a CLDC
HotSpot Implementation, que substituram respectivamente a CVM (Compact VirtualMachine), vinculada a configuracao CDC e a KVM (Kilo Virtual Machine), vinculada a
CLDC. A Figura 3.2 mostra a arquitetura da plataforma Java.
8/7/2019 Caso de uso JME
22/71
3.2. Configuracoes 13
Figura 3.2: Arquitetura da plataforma Java.
3.2 Configuracoes
A configuracao define uma especificacao padrao para uma mesma classe de dispositivos,
definidos por caractersticas individuais de hardware, como interface, processamento, me-
moria, vdeo, tipo de conexao de rede, entre outras (TOPLEY, 2002). Esta camada possui
as bibliotecas basicas da linguagem, representando a plataforma mnima de desenvolvi-mento para cada tipo de dispositivo. Tais configuracoes sao definidas pelos fabricantes a
fim de proporcionar um ambiente de desenvolvimento para funcionar em um determinado
dispositivo.
Cada configuracao consiste de uma maquina virtual Java (Java Virtual Machine -
JVM), seja da Sun, do proprio fabricante, ou de terceiros e de uma colecao de classes
Java. Devido as restricoes de hardware dos dispositivos moveis, as maquinas virtuais
utilizadas na plataforma Java ME nao suportam todas as caractersticas da linguagem
Java, instrucoes bytecodes e softwares de otimizacao providenciados pela plataforma Java
SE nao sao suportados, sendo assim diferentes das demais JVMs (TOPLEY, 2002).A JCP especificou duas configuracoes para Java ME, CLDC e CDC. Dentre elas abor-
daremos a configuracao CLDC, visto que esta aborda celulares e smartphones, cujo e o
objetivo deste trabalho.
A Connected, Limited Device Configuration - CLDC e a configuracao mnima do Java
ME, formada por um subconjunto de pacotes disponveis na plataforma Java para desktop
8/7/2019 Caso de uso JME
23/71
3.2. Configuracoes 14
e abrange os dispositivos com grandes restricoes de processamento, memoria e vdeo, como
celulares, smartphones, pagers e PDAs.
Os dispositivos desta configuracao tem pelo menos 16 ou 32 bits, 160k de memoria
nao volatil (onde sao armazenadas as bibliotecas e a maquina virtual), fonte limitada de
energia e pelo menos 16 Mhz de velocidade. Alem disso e necessario 192k de memoriapara a plataforma Java e suportar conexao com rede sem fio, porem com capacidade de
transmissao limitada (JOHNSON, 2007).
A CLDC esta disponvel nas versoes 1.0 (JSR 30) e 1.1 (JSR 139) (SUN, 2006e). A
principal caracterstica da versao 1.0 e a ausencia de operacoes que use ponto flutuante,
porem ja existem classes que simulam esta propriedade para dada configuracao (CLAU-
SEN, 2003).
Segundo a SUN (2007), as classes desta configuracao estao restritas a apenas quatro
pacotes:
java.io - Tratamento de entrada e sada de dados usando streams (abstracao).
java.lang - Classes basicas da linguagem Java.
java.util - Classes de utilidades genericas (estruturas de dados e manipulacao de
dados).
java.microedition.io - Exclusivamente da plataforma Java ME, incluindo as classes
de conexao.
A CLDC 1.1 e uma configuracao que engloba os pacotes da versao 1.0 e suporta as
seguintes caractersticas:
Ponto flutuante - Possibilita operacoes com variaveis do tipo float/double.
ClassLoading - Classe abstrata responsavel por carregar outras classes.
Garbage Collector - Coletor de lixo dos objetos.
Finalize() - Com esse metodo e possvel liberar recursos e executar outras operacoes
de limpeza antes que o objeto seja recuperado por coleta de lixo (garbage collector).
JNI (Java Native Interface) - Classe de interface nativa que possibilita a maquina
virtual acessar bibliotecas acessadas com o codigo nativo de um sistema.
ThreadGroups - Possibilita que os processos sejam executados simultaneamente,
possibilitando a organizacao das threads em grupos. A multiThreading suporta
multiplas linhas de execucao atraves das funcoes start(), interrupt(), pause(), re-
sume() e stop() para o controle das threads.
8/7/2019 Caso de uso JME
24/71
3.3. Perfis 15
RMI (Remote Method Invocation) - Permite o acesso a objetos remotos que podem
ser invocados de diferentes maquinas Java.
3.3 PerfisPerfil e definido como um conjunto de APIs que especificam o nvel de interface de
aplicacoes para um classe de dispositivos (JCP, 2009c). Assim um perfil pode especificar
varios tipos de servicos e funcionalidades de alto nvel, como o ciclo de vida da aplicacao,
elementos de interface grafica, persistencia de dados e meios de comunicacao. Um perfil e
implementado no topo de uma configuracao, sendo assim intimamente ligado a esta, po-
rem compreende bibliotecas mais especficas que as disponibilizadas pelas configuracoes,
ou seja, o perfil complementa a configuracao adicionando classes que fornecem caracte-
rsticas apropriadas para um tipo particular de dispositivos. Tanto os perfis quanto as
configuracoes sao especificacoes de baixo nvel.As aplicacoes moveis sao portanto construdas sobre configuracoes e perfis e podem
apenas usar bibliotecas especificadas por estas. Uma configuracao pode conter varios
perfis, porem um perfil e ligado somente a uma configuracao. E um perfil ainda pode ter
outros perfis ligados a ele (TOPLEY, 2002).
Para a configuracao CLDC temos o perfil MIDP (Mobile Information Device Profile
- JSR 37), que e amplamente utilizado e providencia o desenvolvimento para pequenos
dispositivos, de recursos limitados e com capacidade de conexao sem fio, como os celulares,
smartphones e alguns PDAs. No proximo captulo serao abordados mais detalhes sobre o
perfil MIDP.
3.4 Maquinas Virtuais
A Sun especifica duas maquinas virtuais para a configuracao CLDC: KVM e CLDC
HotSpot Implementation.
KVM
E uma maquina virtual com funcoes reduzidas, com uma pequena memoria e com
um coletor de lixo (garbage collector) incorporado para a otimizacao da memoria
(TOPLEY, 2002). Esta e uma VM (Virtual Machine) especificada pela SUN, que
implementa as necessidades e restricoes impostas pela configuracao CLDC. O K do
termo KVM surgiu para fazer alusao aos poucos kilobytes necessarios para que a
VM execute uma aplicacao. Ela nao compila o codigo e sim o interpreta para o
sistema operacional.
8/7/2019 Caso de uso JME
25/71
3.5. Pacotes Opcionais 16
CLDC HotSpot Implementation
E uma VM de alto desempenho e robustez da SUN, para celulares e dispositivos
de caractersticas restritas. Foi implementada para ter um desempenho melhor
que a KVM, utilizando a mesma quantidade de memoria restrita que os pequenos
dispositivos oferecem. Esta maquina virtual suporta CLDC 1.0 e 1.1, porem agora
exige do processador pelo menos 32 bits com uma velocidade de clock de 60 MHz,
600KB de memoria RAM e 2 MB de memoria flash e ROM. Aplica tecnologias
utilizadas na plataforma Java SE e Java EE, incorpora diversos designs inovadores,
diminui o tempo de incio das aplicacoes, oferece vida longa a bateria e possui
compilacao dinamica das instrucoes de bytecode em instrucoes nativas, chamada de
compilacao Just-in-time (SUN, 2008a).
Segundo LUZ (2009), a compilacao Just-in-time e uma das mudancas mais impor-
tantes, pois a compilacao dinamica pode ser cinquenta vezes mais rapida que uma
instrucao interpretada.
3.5 Pacotes Opcionais
Pacotes opcionais sao componentes muito importantes da plataforma Java ME. Po-
demos enxergar como extensoes de perfis, alem de oferecerem apoio em areas com fun-
cionalidades restritas que alguns dispositivos e aplicacoes precisam, tais como troca de
mensagens, multimdia, servicos e localizacao geografica.
Os perfis podem concentrar-se em apoiar apenas as capacidades que a maioria ou
todos os dispositivos em uma classe necessitam, enquanto pacotes opcionais fornecemtipos especficos de funcionalidades. Todos os pacotes opcionais do Java ME sao definidos
pela JCP, estes pacotes tambem sao chamados de APIs. Podendo ser obrigatorios ou
nao, tal decisao cabe aos desenvolvedores ou fabricantes inclu-los em um determinado
produto.
Os pacotes opcionais passam por um processo de aprovacao atraves da MSA (Mobile
Service Architecture) apos serem construdos pelos desenvolvedores. Depois de aprovados
sao disponibilizados seguindo as especificacoes da JCP. Alguns exemplos de pacotes opcio-
nais sao: API para suporte bluetooth (JSR 82), API para acesso as funcionalidades nativas
do aparelho como agenda, calendario e acesso a arquivos (JSR 75 - File Connection API),
API de seguranca e servicos confiaveis (JSR 177), entre outras (SUN, 2009a).
8/7/2019 Caso de uso JME
26/71
Captulo 4
Perfil MIDP
Neste captulo sao apresentadas as caractersticas do perfil MIDP, bem como o fun-
cionamento de uma aplicacao. Serao apresentados os principais conceitos relacionados ainterface e armazenamento persistente.
4.1 Visao Geral do MIDP
O MIDP - Mobile Information Device Profile e um perfil suportado pela configuracao
CDLC, onde juntos providenciam um ambiente padrao de execucao Java para os mais
populares dispositivos moveis, como os celulares e PDAs. Este perfil prove um conjunto de
bibliotecas e classes que fornecem suporte ao desenvolvimento de aplicacoes que referem-
se a diferentes aspectos, como sistema de armazenamento persistente, interface com o
usuario, transacoes seguras, gerencia de sons, entre outros.
De acordo com JOHNSON (2007), o MIDP apresenta diversas funcionalidades, entre
elas estao a reproducao de multimdia, suporte a protocolos dos tipos HTTP e sockets,
suporte ao sistema de cores RGB, definicao de formularios e itens, APIs para jogos e
validacao de permissoes de seguranca e assinaturas digitais.
Segundo a SUN (2006e), os recursos mnimos de hardware do perfil MIDP sao:
130KB de memoria nao volatil para persistencia de dados e bibliotecas da CLDC
32KB de memoria volatil para a execucao do Java
Conectividade com algum tipo de rede sem fio
Interface grafica
Uma tela de pelo menos 96 pixels de largura por 54 de altura
17
8/7/2019 Caso de uso JME
27/71
4.1. Visao Geral do MIDP 18
Alguns recursos mnimos de software tambem sao requeridos, tais como: possuir re-
cursos suficientes para executar a maquina virtual Java, tratamento de excecoes, pro-
cessamento de interrupcoes, acesso de leitura e escrita a rede sem fio, mecanismos para
capturar a entrada de dispositivos de entrada, recursos para ler e gravar em memoria nao
volatil, oferecendo suporte persistente aos dados e escrita de elementos graficos na tela(JOHNSON, 2007).
As especificacoes deste perfil sao definidas pela JCP, definindo uma plataforma para
desenvolvimento seguro e dinamico. Atualmente o MIDP possui as versoes 1.0 (JSR
37), 2.0 (JSR 118), 2.1 (JSR 118) e 3.0 (JSR 271). Porem esta ultima ainda nao esta
disponvel para utilizacao. A versao 1.0 trabalha integrada com a configuracao CLDC
1.0 ou 1.1. Nao tem nenhuma API ativa para renderizacao, nao oferece suporte para
acesso direto aos pixels de imagens, nao tem suporte para full screen/full canvas sem
uma API proprietaria e tambem nao possui suporte direto para audio. Inclui APIs para
o ciclo de vida de aplicacoes, conectividade de redes HTTP, interface com o usuario earmazenamento persistente. O unico protocolo de rede que o MIDP 1.0 suporta e o
HTTP (SUN, 2002).
Segundo a SUN (2006c), os pacotes suportados pela versao 1.0 sao:
javax.microedition.io - Fornece suporte ao framework GenericConnection da confi-
guracao CLDC.
javax.microedition.lcdui - API que providencia um conjunto de caractersticas para
a implementacao de interfaces com o usuario.
javax.microedition.rms - Providencia um mecanismo de persistencia de dados para
MIDlets.
javax.microedition.midlet - O pacote MIDlet define aplicacoes MIDP e interacoes
entre as aplicacoes e o ambiente no qual a aplicacao e executada.
A versao 2.0 e compatvel com a versao 1.0 e adiciona novas melhorias como suporte
a conexao segura (HTTPS), biblioteca de multimdia, formulario de entrada de dados
aprimorada, sensvel melhoria na API de suporte a games, conceito de aplicacoes confiaveis
(trusted) e nao confiaveis (untrusted). Alem de HTTPS, o MIDP 2.0 suporta HTTP,
datagramas, sockets e SMS (Short Message Service). Quanto a multimdia, um conjunto
de APIs foram introduzidas, que sao na verdade um subconjunto da Mobile Media API(MMAPI). Com estas APIs podem ser gerados simples toques, sequencias mais completas
ou ate mesmo musicas completas no formato WAV, alem de poderem ser implementados
em outros formatos.
Dentre as mudancas nos formularios de entrada destacam-se a nova aparencia do Form
que e consideravelmente mais sofisticada do que era no MIDP 1.0 e a classe Item, onde
8/7/2019 Caso de uso JME
28/71
4.1. Visao Geral do MIDP 19
agora podem ser especificados layouts horizontais, verticais, novas linhas antes ou depois
de itens, entre outros. Um novo item tambem foi criado, o Spacer, que serve pra colocar
espacamentos entre os demais itens disponveis. Tambem foi introduzido o tipo pop up ao
item choiceGroup, que sera estudado a frente.
No MIDP 2.0 tambem foram estendidos os comandos de manuseio. Adicionar co-mandos aos itens agora e permitido. Tambem foi introduzida a classe CustomItem, que
permite ao programador criar seus proprios itens. Nesta versao o suporte a jogos ganha
uma melhoria com o suporte a camadas na tela. Uma camada pode conter um fundo, ou-
tra mostrar objetos, uma terceira camada poderia mostrar esfeitos especias ou qualquer
outra coisa. Outra mudanca e o surgimento da classe GameCanvas, uma subclasse de
Canvas - classe de baixo nvel que proporciona o desenvolvimento de jogos. Nesta versao
as imagens podem ser representadas em arrays de inteiros e tambem suporta imagens em
RGB (SUN, 2002).
Segundo a SUN (2006d), os pacotes que foram adicionados a esta versao sao:
javax.microedition.lcdui.game - Providencia classes para o desenvolvimento de con-
teudo rico para jogos em dispositivos wireless.
javax.microedition.media - Compatvel com as especificacoes da API Mobile Media
(JSR 135).
javax.microedition.media.control - Define o tipo especfico, control, que pode ser
usado como um player.
javax.microedition.pki - Autentica informacoes para conexoes seguras, atraves decertificados.
A versao 2.1 do MIDP reforca a especificacao MIDP 2.0 tornando a diretiva layout LC-
DUI obrigatoria, os pacotes javax.microedition.io.SocketConnection e javax.microedition-
.io.HTTPConnection nao sao mais opcionais, entre outros requisitos para aprimorar a
versao 2.0.
A versao 3.0 traz melhor suporte para dispositivos com telas maiores, suporte a MI-
Dlets para desenhar em telas secundarias, armazenamento RMS seguro e acesso remoto a
bancos RMS (JCP, 2009a). Esta versao requer no mnimo 1MB de memoria volatil e tela
de pelo menos 176x220 pixels. Ela e compatvel com o CLDC 1.0, mas o recomendado eo 1.1 e possui compatibilidade com as outras versoes do MIDP. No MIDP 3.0 a tela de
splash pode ser carregada sem a necessidade de ser criada uma classe em canvas com uma
imagem e tempo controlado manualmente. Isto pode ser feito atraves de um atributo no
arquivo JAD, um arquivo de descricao da aplicacao, que sera explicado posteriormente.
Os protetores de tela agora sao aplicacoes que sao destrudas pelo gerenciador quando
8/7/2019 Caso de uso JME
29/71
4.2. MIDlets 20
alguma tecla e pressionada ou algum evento e disparado. Alem destas funcionalidades,
o MIDP 3.0 apresenta suporte a IP versao 6, o que possibilita fazer parse de um ende-
reco IPv6 e a possibilidade de compartilhar bibliotecas entre os MIDlets em tempo de
execucao, conhecido como LIBlets (LUZ, 2009).
4.2 MIDlets
E uma aplicacao Java destinada para dispositivos moveis desenvolvida com a utilizacao
do perfil MIDP, que esta vinculado a configuracao CLDC (MUCHOW, 2001).
Todo dispositivo movel tem um gerenciador de aplicativos (AM - Application Mana-
ger) que controla os aplicativos a serem instalados, onde e como serao armazenados e
como serao executados. A comunicacao do gerenciador com o MIDlet acontece pela classe
MIDlet do pacote javax.microedition.midlet.MIDlet. Os MIDlets devem herdar esta classe
MIDlet que contem metodos que inicializam, resumem, interrompem a execucao e des-troem MIDlets.
Uma aplicacao e iniciada quando o AM invoca o metodo startApp(), colocando a
aplicacao no modo ativo. Enquanto estiver executando ela pode ser pausada pela AM
atraves do metodo pauseApp(), isto pode ocorrer quando uma chamada for recebida por
exemplo ou o proprio usuario pode pausar a aplicacao. E quando a aplicacao e encerrada
ela passa para o estado destrudo, atraves do metodo destroyApp(), que limpa todos os
recursos para fechar a aplicacao (JOHNSON, 2007).
O ciclo de vida do MIDlet e apresentado na Figura 4.1.
Figura 4.1: Ciclo de vida do MIDlet.
Estes tres metodos, segundo MUCHOW (2001), trata-se da comunicacao que parte
do gerenciador de aplicativos para o MIDlet. Alem destes metodos, tambem existem
outros tres onde a comunicacao parte do MIDlet para o gerenciador de aplicativos. Estes
metodos sao:
8/7/2019 Caso de uso JME
30/71
4.3. MIDlets Suite 21
notifyDestroy(): Avisa ao gerenciador que pode desligar a MIDlet.
notifyPaused(): Envia o pedido de pausa para o gerenciador caso a MIDlet queira
pausar.
resumeRequest(): Avisa ao gerenciador que a MIDlet pode tornar-se ativa novamente.
4.3 MIDlets Suite
MIDlet Suite consiste em um ou mais MIDlets que sao juntados em um Java Ar-
chive (JAR). E composto por classes Java, recursos e um arquivo de manifesto, que estao
situados dentro do arquivo JAR e um arquivo de descricao, chamado Java Application
Descriptor (JAD). Dentre os recursos estao imagens, dados da aplicacao, entre outros.
No arquivo de manifesto, cuja extensao e .mf, esta a descricao do JAR. E o arquivo JAD
descreve os detalhes da aplicacao, repetindo muitos do dados que estao no arquivo de
manifesto, porem este arquivo esta fora do JAR e pode ser acessado antes de se insta-lar o arquivo JAR no aplicativo (JOHNSON, 2007). As proximas subsecoes descrevem
detalhadamente cada um desses arquivos.
4.3.1 JAR
Todas as MIDlets sao empacotadas antes de serem transferidas a um dispositivo, isso
e feito atraves de um metodo de compressao onde sao colocadas todas as informacoes em
um unico arquivo cuja extensao e .JAR. Este arquivo engloba classes Java, recursos e
informacoes do empacotamento, com citado anteriormente (MUCHOW, 2001).
O arquivo JAR providencia muitos benefcios, como: seguranca, atraves de assinaturasdigitais; compressao; empacotamento de extensoes, juntando varios tipos de extensoes
diferentes em uma unica: o .JAR; portabilidade e o fato de quando e necessario fazer o
download de uma aplicacao apenas um arquivo deve ser baixado (SUN, 2008b).
4.3.2 JAD
Conforme estudado, alem do JAR e criado um arquivo em separado de extensao .JAD
que contem informacoes sobre o MIDlet. Este arquivo e usado muitas vezes para preparar
o JAR para ser instalado, otimizando a instalacao do aplicativo, porem nem todos os
aparelhos precisam ler o .JAD para realizar a instalacao. O arquivo JAD possui a seguinte
estrutura:
MIDlet-Name: Nome da Suite MIDlet.
MIDlet-Version: Versao da MIDlet.
MIDlet-Vendor: Desenvolvedor da MIDlet.
8/7/2019 Caso de uso JME
31/71
4.4. Interface 22
MIDlet-Icon: Especifica o cone da tela inicial da aplicacao.
MIDlet-Description: Descricao da aplicacao.
MIDlet-info-URL: Endereco para um arquivo de informacoes (JAR).
MIDlet-DATA-Size: Tamanho dos dados.
4.4 Interface
Os dispositivos moveis que implementam o perfil MIDP possuem diversas restricoes
quando se trata de interface, podendo variar em tamanho de tela, numero de cores apresen-
tadas na tela, disposicao dos botoes, etc. E estas informacoes sao acessadas pela MIDlet
somente em tempo de execucao. Sendo assim, o MIDP so permite a utilizacao de objetos
visuais simples, nao sendo permitida a implementacao de objetos comuns na versao Java
para desktop (JOHNSON, 2007).
O Java ME tem como padrao para construcao de interfaces a biblioteca LCDUI, quee responsavel pelos componentes que formam a interface de aplicacoes MIDP. Nesta se-
cao estudaremos algumas classes desta biblioteca, que estao dispostas de acordo com a
hierarquia mostrada na Figura 4.2.
Figura 4.2: Hierarquia de classes.
8/7/2019 Caso de uso JME
32/71
4.4. Interface 23
Display e Displayable
Para desenvolver interfaces que se encaixem em dispositivos moveis com diferentes
caractersticas de tela, as aplicacoes sao desenvolvidas com uma certa abstracao. Para
acessar as informacoes de um determinado aparelho existe a classe Display e cada MIDletpossui sua propria instancia desta classe que pode ser acessada pelo metodo getDisplay(),
que geralmente esta contido no metodo startApp(), pois o Display so pode ser acessado
depois que aplicacao tenha sido iniciada.
Portanto, a tela do dispositivo e representada por uma instancia da classe Display,
que representa o hardware, e para que seja mostrado algo na tela devemos passar um
objeto Displayable para o objeto da classe Display. Displayable e uma classe abstrata
que controla o que e mostrado na tela e os comandos enviados pelos usuarios. Eles
representam conteudos de uma tela na qual ha interacao com o usuario (JOHNSON,
2007). Cada aplicacao possui apenas uma instancia da classe Display, sendo assim podem
existir varios objetos Displayable mas apenas um e mostrado por vez (MUCHOW, 2001).Os objetos Displayable que estao na memoria, mas nao estao sendo mostrados estao no
chamado background e o objeto que esta sendo mostrado esta no foreground. Portanto os
objetos que estao no background nao tem acesso ao Display. Para mostrar um Displayable
na tela usamos o metodo setCurrent() e para obter qual objeto esta sendo mostrado no
Display usamos o metodo getCurrent() (JOHNSON, 2007).
A classe Displayable da origem a duas outras classes: Screen e Canvas. Ambas sao
classes para representar interfaces, porem a primeira classe, juntamente com suas subclas-
ses formam componentes de interface de alto nvel e a segunda de baixo nvel (MUCHOW,
2001).
Screen
Screen e uma classe que contem objetos graficos prontos, onde cada uma pode ter uma
aparencia, variando de acordo com o dispositivo em que esta sendo executada a aplicacao
(JOHNSON, 2007). Screen e suas herancas sao classificadas como objetos de interface de
alto nvel (High-Level APIs) e as herancas desta classe sao as classes Form, List, Alert e
Textbox (MUCHOW, 2001).
Form
Form e um formulario o qual pode conter textos, imagens e outros componentes para
serem exibidos no visor. Varios componentes podem ser colocados em um Form e se
houver necessidade ele apresenta barra de rolagem automatica para mostrar todos estes
componentes visuais. Porem nada muito extenso e viavel para aplicacoes moveis.
8/7/2019 Caso de uso JME
33/71
4.4. Interface 24
Esses componentes que podem ser adicionados em um Form sao subclasses da classe
Item e serao estudados posteriormente. Um Form possui metodos para adicionar, inserir,
apagar e substituir componentes. Estes componentes da classe Item so pode ser inseri-
dos em um Form e nao em outras telas da classe Screen, como List, Alert ou Textbox
(MUCHOW, 2001).
Item
Conforme mostrado um Item e um componente que pode ser inserido em um Form e
suas subclasses sao:
StringItem
E um simples texto estatico, ou seja, nao pode ser editado.
TextFieldE um campo para entrada e/ou edicao de texto. Podendo ser associadas regras a
este. Por exemplo: aceitar somente numeros, qualquer caracter, ser um campo de
senha, entre outros.
ImageItem
Permite inserir uma imagem.
ChoiceGroup
E uma lista de escolhas, dentro de um Form. Possui os tipos: multiplo, exclusivo
ou pop up.
1. Multiplo: Podem ser selecionadas varias opcoes, marcando uma caixa de che-
cagem que acompanha os elementos da lista;
2. Exclusivo: Pode ser selecionado apenas uma opcao e esta e marcada com um
radioButton.
3. Pop up: Pode ser selecionada apenas uma opcao. A lista e exibida como
uma comboBox, ou seja, os elementos ficam escondidos e quando clicada esta
lista toda e exibida. Apos a selecao de um elementos os outros elementos sao
escondidos novamente.
DataField
Campo utilizado para exibir e/ou entrar com data e/ou hora.
8/7/2019 Caso de uso JME
34/71
4.4. Interface 25
Gauge
E uma representacao grafica de um numero inteiro. Ele permite que o usuario
defina um nvel, como o volume por exemplo, se for um Gauge interativo. Se for
nao interativo e somente o programa que o controla (MUCHOW, 2001).
Spacer
Determina um espacamento vertical e/ou horizontal mnimo entre os componentes
de um Form. Ele e utilizado por questoes de design de layout.
CustomItem
Utilizado para criar itens especficos, atraves de desenhos, utilizando a classe Graphics
da API de baixo nvel (MATTOS, 2005).
List
E uma lista que permite ao usuario selecionar opcoes. Estas podem ser tanto uma
String quanto uma imagem. O List pode ser exclusivo, multiplo ou implcito. Implcito e
quanto a lista e exibida sem nenhum marcador e somente uma opcao pode ser escolhida,
gerando um evento quando e selecionada uma das opcoes. Os outros dois tipos funcionam
igualmente ao ChoiceGroup (MATTOS, 2005).
Alert
E uma tela de informacao ao usuario. Pode conter uma mensagem de erro, de sucesso,
de informacao, entre outras. Ele pode ser programado para ser exibido durante um tempopre determinado, pode ser composto de um texto e uma imagem e sua aparencia varia de
acordo com o dispositivo movel usado (MATTOS, 2005).
TextBox
Basicamente e uma tela que serve para entrada e edicao de texto. E como se fosse um
Item textField, porem so existe ele na tela. Em um textBox tambem podem ser usadas
regras, assim como em um textField (SUN, 2006b).
Canvas
Canvas e uma classe de baixo nvel, que proporciona maior liberdade na implementacao
dos graficos e eventos. E destinada a aplicacoes que necessitam de posicionamento preciso
dos elementos graficos, sendo portanto muito utilizada para a criacao de jogos.
8/7/2019 Caso de uso JME
35/71
4.5. Armazenamento Persistente 26
Atraves da utilizacao desta classe e possvel desenhar na tela. O desenvolvedor cria
o que sera mostrado para o usuario final. Para criar uma interface grafica com canvas e
utilizado a classe Graphics, que fornece metodos para desenhar linhas, arcos, retangulos
e textos, alem de especificar cores e fontes (MUCHOW, 2001).
Alem de desenhar interfaces, a classe canvas permite controlar eventos primitivos,como teclas pressionadas e liberadas e acessar dispositivos de entrada de dados, como
teclados em geral, toques, em telas touchScreen, entre outros (MATTOS, 2005).
Command
A classe Command permite adicionar comandos, ou seja, funcoes, aos objetos mostra-
dos na tela (JOHNSON, 2007). Os comandos sao usados para a interacao do usuario com
a aplicacao podendo ser atribudos a qualquer Displayable, de alto ou baixo nvel, e a um
Item. Quando um comando e acionado pelo usuario, e notificado a um CommandListener
que e definido no objeto Displayable. Um command contem somente uma informacaosobre o comando e nao sobre qual acao realizar. A acao e definida no CommandListener
associado ao Displayable (SUN, 2006a).
CommandListener: E uma interface usada para tratar os eventos, controlando quais
e quando os eventos foram acionados. O commandListener vincula um comando a um
gatilho, detectando quais comandos foram ativados e definindo gatilhos para eles. Quando
um comando e acionado, o commadAction o captura, juntamente com o Displayable atual
(JOHNSON, 2007).
4.5 Armazenamento Persistente
Os dispositivos moveis que usam o perfil MIDP possuem, como memoria volatil, a
memoria RAM e, como memoria de armazenamento persistente, a memoria flash. Esta
permite armazenar dados por longos perodos de tempo, sem a necessidade de ser mantida
energizada por uma bateria ou fonte eletrica.
As vantagens da memoria flash sao: o pequeno tamanho fsico, a resistencia a choques,
o alto desempenho para a leitura de dados, entre outros. E algumas de suas desvantagens
sao o fato de as operacoes de escrita serem lentas e a capacidade de armazenamento ser
restrita. Porem, a maioria dos dispositivos moveis contam com um cartao de memoria,
que serve como um drive de armazenamento. O cartao oferece solucao ao armazenamento
restrito, porem o seu acesso e mais lento se comparado com o acesso a memoria flash
interna.
Para o armazenamento persistente o perfil MIDP utiliza a API RMS (Record Mana-
gement System - Sistema de gerenciamento de armazenamento) e a API JSR-75 - File
8/7/2019 Caso de uso JME
36/71
4.5. Armazenamento Persistente 27
Connection, que implementa um sistema de armazenamento em arquivos. Porem nao sao
todos os dispositivos que fornecem acesso a esta ultima API (LUGON, 2005).
4.5.1 RMS
A API RMS e o mecanismo padrao para persistencia de dados oferecido pelo MIDP. O
RMS funciona como um banco de dados orientado a registros, apresentando-se diferente
dos tradicionais bancos de dados relacionais conhecidos. Ele e composto por Record Stores,
que sao como armazens de dados, conforme mostra a Figura 4.3.
Figura 4.3: Record Management System.
Um Record Store e identificado por um nome, que e case sensitive e e criado por um
MIDlet. Entao quando um MIDlet e removido de um dispositivos todos os Record Stores
relacionados a ele serao removidos tambem. O limite de armazenamento e o mesmo que
o dispositivo oferecer.
A API RMS nao suporta tipos caractersticos de outros banco de dados, como ta-
belas, colunas ou linhas, nela cada registro, chamado Record, e um array de bytes. Por
causa disso a aplicacao deve converter os dados para array de bytes para poderem ser
armazenados. Para ler os dados o processo inverso deve ser feito ( MUCHOW, 2001).
Contudo, podemos imaginar o Record Store como um conjunto de linhas, onde cada
linha e um registro (Record) e estes sao identificados por uma chave primaria, chamada
Record ID, que e um inteiro. Logo, cada registro e formado por um inteiro e um array de
bytes. A API fornece metodos para abrir, fechar e deletar um RecordStore inteiro. Alemdestes existem metodos para a manipulacao dos registros como, adicionar, modificar,
deletar, recuperar um registro e a quantidade de registros existentes (SOUSA, 2006).
8/7/2019 Caso de uso JME
37/71
Captulo 5
APIs e Frameworks para Java ME
Atraves de frameworks e APIs especficas e possvel construir aplicacoes com mais
recursos, dispondo de varias funcionalidades extras, que nao sao encontradas nas especi-ficacoes do perfil MIDP, alem de otimizar o desenvolvimento. Este captulo lista algumas
APIs e frameworks mais utilizados no desenvolvimento de aplicacoes para celulares e
smartphones, utilizando a plataforma Java ME, destacando-se os que foram utilizados no
estudo de caso e explica o porque da escolha destes.
5.1 APIs
Com APIs podemos desenvolver aplicacoes que se conectam a servidores remotos, com
outros aparelhos, aplicacoes que utilizam bluetooth, que executam musicas e vdeos, entre
outras. Algumas das APIs opcionais disponveis para o perfil MIDP sao citadas por
(JOHNSON, 2007).
Java APIs for Bluetooh (JSR 82) - Permite o desenvolvimento de aplicacoes para
acesso a rede bluetooh.
Location API (JSR 179) - Permite o desenvolvimento de aplicativos baseados em
localizacao fsica (LBS).
Mobile Game API (JSR 178) - Voltada para criacao de jogos.
Mobile Media API (JSR 135) - Permite reproducao de mdia.
Security and Trust Services API for J2ME (JSR 177) - Usada para adicionar segu-
ranca as aplicacoes.
Wireless Messaging (JSR 120 e 205) - Permite troca de mensagens SMS.
28
8/7/2019 Caso de uso JME
38/71
5.1. APIs 29
Entre outras APIs opcionais importantes para auxiliar no desenvolvimento de aplica-
coes temos:
File Connection API (JSR 75) - Permite acesso e armazenamento em arquivos e
acesso a programas nativos do dispositivo, como agenda, calendario, entre outros.
Mobile Sensor API (JSR 256) - Permite a recuperacao de dados de sensores internos
ou externos ao aparelho celular.
MECHART - Uma API de terceiro, ainda nao catalogada pela JCP, que permite
construir graficos de maneira simples e rapida, sem a necessidade de programar
diretamente na classe Canvas.
Dentre estas, vamos estudar a FileConnection API, pois alem de ser uma das mais
usadas por desenvolvedores da plataforma Java ME, possui maior reconhecimento e sera
de grande utilidade para o projeto que desenvolveremos posteriormente.E importante dizer que a JCP ate o momento tem catalogado 927 JSRs na plataforma
Java (JCP, 2009b). E para a plataforma Java ME foram especificadas 83 JSRs, entre elas
APIs opcionais.
File Connection API
A JSR 75 especifica dois pacotes obrigatorios para a plataforma Java ME:
O PIM - Pacote que permite desenvolvedores acessar os dados de PIM do aparelho,tais como agenda, livro de enderecos e listas de tarefas, que existe na maioria dos
dispositivos moveis.
O Pacote opcional de conexao de arquivos (FCOP) - Permite aos desenvolvedores
o acesso a diversas formas de dados, tais como: imagens, sons, vdeos, textos en-
tre outros tipos de dados do sistema de arquivo do dispositivo movel. Isto inclui
dispositivos de armazenamento removveis, como cartoes de memoria.
O PIM e os arquivos de dados permitem a integracao de aplicacoes com informacoes
sobre o dispositivo, permitindo aplicacoes mais inteligentes (SUN, 2009c).Abaixo estao as importantes classes e interfaces:
ConnectionClosedException - Lancada quando um metodo e invocado em uma Fi-
leConnection quando a conexao e fechada.
8/7/2019 Caso de uso JME
39/71
5.2. Frameworks 30
FileSystemRegistry - Classe central de registros que possui a habilidade de listar
roots montadas atraves do metodo listRoots(). Ela tambem providencia metodos
para os ouvintes de registros (Registering listeners), estes sao notificados se sistemas
de arquivos sao adicionados ou removidos durante o tempo de execucao.
A FileSystemListener interface - Usada para recepcao de notificacoes de status
quando e adicionado ou removido um sistema de arquivo raz.
A FileConnection interface - Usada para acessar diretorios e arquivos no dispositivo.
Ela estende a Connection interface e mantem inumeros metodos uteis para criar,
remover diretorios e arquivos, lista de conteudo de diretorios, configurar permissoes,
obter informacoes de arquivos e efetuar operacoes de entrada e sada nos arquivo.
Os pacotes usados sao:
javax.microedition.pim
javax.microedition.io.file
No desenvolvimento do estudo de caso foi explorado o pacote opcional de conexao de
arquivos (FCOP), dependente apenas do nucleo de classes definidas pelo CLDC.
A forma de acessar os arquivos e utilizando a FCOP atraves da interface FileConnec-
tion, muito usada por sinal. Para isto basta importar o pacote javax.microedition.io.file.-
FileConnection.
A FileConnection estende StreamConnection pela adicao de metodos de arquivo e
diretorio de manipulacao. A funcionalidade adicional e semelhante a que se encontradisponvel no J2SE, na classe java.io.File. Para a abertura de um arquivo e usado uma
URL no formato: file://host/path
Enfim, com metodos mais especficos desta API e possvel manipular arquivos dentro
do aparelho, sem a necessidade de trabalhar com classes de baixo nvel (NOKIA, 2008).
5.2 Frameworks
Entre os frameworks mais utilizados para a otimizacao no desenvolvimento de aplica-coes para dispositivos moveis estao:
Floggy - Framework para persistencia de dados.
J2MicroDB - Fornece um banco de dados relacional limitado para dispositivos mo-
veis.
8/7/2019 Caso de uso JME
40/71
5.2. Frameworks 31
Perst Lite - Banco de dados orientado a objetos para aplicacoes embarcadas.
JMESQL - Banco de dados relacional escrito em Java.
KXML - Realiza o parser de arquivos XML.
LWUIT - Possibilita o desenvolvimento de interfaces ricas (RIA) e robustas.
Java2ME Polish - Framework para personalizar a UI (User Interface) do MIDlet
sem alterar o codigo fonte.
Diamont Powder - Acelera a criacao de aplicacoes para coleta de dados.
Fire (Flexible Interface Rendering Engine) - Framework para o desenvolvimento de
interfaces mais atraentes que as compreendidas pelo MIDP.
Marge - Facilita o desenvolvimento de aplicacoes em Java que fazem uso de bluetooth
Entre os frameworks citados neste trabalho, astraves de testes, os que melhor atende-
ram ao desenvolvimento do estudo de caso foram: o Floggy, pois abstrai significativamente
a complexidade dos codigos RMS para a persistencia de dados, o LWUIT, que fornece in-
terfaces bastante atraentes, alem de estar caminhando para ser o framework referencia
em UI, por fim o KXML, para fazer o parse de XMLs, usado para interpretar os dados
trocados entre servidor e aplicacao movel.
5.2.1 Floggy
Uma das limitacoes impostas pelo perfil MIDP e a utilizacao da API RMS, na maioria
dos dispositivos, para a persistencia de dados. Visando a dificuldade dos codigos utilizados
para acessar esta API surgiu o Floggy, framework de persistencia free para J2ME/MIDP,
desenvolvido por brasileiros. Seu principal objetivo e abstrair os detalhes da persistencia
de dados para o desenvolvedor, reduzindo os esforcos de desenvolvimento e manutencao
(FLOGGY, 2009).
O Floggy utiliza comandos de alto nvel para encapsular os comandos necessarios para
o armazenamento e recuperacao de objetos, ou seja, o que esta por tras deste framework
sao codigos para acessar a API RMS (LUGON, 2005).O framework e composto por dois modulos:
- Framework: responsavel por fornecer os metodos de persistencia como salvar, remover
e recuperar os dados, atraves de um arquivo JAR (11KB) que deve ser adicionada na
aplicacao.
8/7/2019 Caso de uso JME
41/71
8/7/2019 Caso de uso JME
42/71
5.2. Frameworks 33
o acesso, parse e exibicao de XMLs e e destinado principalmente a ambientes restritos
como em dispositivos que usam o perfil MIDP (HAUSTEIN, 2007).
Possui as tres versoes. A primeira versao foi criada para dispor a tecnica pull parser
em dispositivos moveis e embarcados e e baseada em eventos de objetos. A segunda versao
e a versao corrente e possui caractersticas de cursor em vez de se basear em eventos deobjetos. A terceira versao ainda esta sendo produzida.
Segundo LECHETA (2006), as principais operacoes do KXML sao:
nextTag(): Aponta para o proximo incio ou fim de tag, pulando eventos insignifi-
cantes como espacos em branco ou comentarios.
Require(): Obriga o cursor a ser posicionado onde for indicado.
nextText(): Exige que a posicao corrente seja uma tag de incio. Retorna o texto
contido no elemento correspondente.
getName(): Obtem o nome da tag na posicao corrente.
Um analisador de XML deveria nao aceitar ou reconhecer documentos com erros,
porem devido as restricoes dos dispositivos moveis isto nao e possvel. Garantir que o
documento esteja com uma sintaxe correta faz parte da tarefa do desenvolvedor. Como
falado anteriormente este framework foi desenvolvido para ser usado em ambientes res-
tritos, o que nos leva a estuda-lo para a aplicacao que sera desenvolvida (HAUSTEIN,
2007).
5.2.3 LWUIT
O LWUIT (LightWeight User Interface Toolkit) e um framework para a criacao de
interfaces graficas ricas em dispositivos moveis, que suportam a tecnologia Java ME.
Inspirado no Swing da plataforma Java SE, foi projetado para ser o mais leve possvel,
comprometendo o mnimo possvel a aplicacao final, visto que foi desenvolvido para dis-
positivos com capacidades restritas (SUN, 2009d).
Com o LWUIT nao ha mais necessidade de se desenhar telas em canvas para construir
interfaces mais amigaveis, e uma grande evolucao visto que a complexidade para tal
tarefa e muito alta. O framework oferece melhorias a componentes graficos de alto nvelja existentes no Java ME, como List, Form, Alert, entre outros. Ainda oferece varias
outras vantagens como suporte a touch Screen, diversas fontes, animacoes, transicoes de
telas animadas e temas variados, que podem ser includos pelos proprios usuarios.
Alem das caractersticas citadas acima, o LWUIT tambem inclui: a utilizacao de
layouts, que organizam a disposicao dos componentes na tela, alem de oferecer melhor
8/7/2019 Caso de uso JME
43/71
5.2. Frameworks 34
portabilidade, integracao 3D (se o dispositivo possuir bibliotecas 3D), caixas de dialogo,
utilizacao de abas (como no Java SE) e internacionalizacao. O LWUIT roda no perfil
MIDP 2.0 e esta sob a licenca GPL v2.0 com a Classpath Excepption, o que significa que
pode ser utilizado em aplicacoes de codigos nao abertos, desde de que nao haja modificacao
nas classes do framework (NETO, 2008).O framework foi recentemente incorporado pela Sun como uma de suas bibliotecas
padroes, no Java ME Plataform SDK 3, que substitui o WTK (Wireless ToolKit) - para
CLDC e o CDC ToolKit, o que promete ainda mais alavancar a utilizacao do LWUIT
dentro da comunidade de desenvolvedores (DOEDERLEIN, 2009).
8/7/2019 Caso de uso JME
44/71
Captulo 6
Comunicacao com o Servidor
Neste captulo sao apresentadas algumas caractersticas da plataforma Java Enterprise
Edition (Java EE), a fim de estudar um metodo eficiente para a construcao de servidoresde dados remotos para alimentar qualquer sistema movel que necessite deste tipo de
comunicacao.
6.1 A Plataforma Java EE
Existem diversas tecnologias que fornecem aplicacoes com conteudo dinamico e per-
sonalizado, seja para construir um simples site de conteudo dinamico ou um sistema
complexo de e-business com banco de dados que integram sistemas corporativos. A pla-
taforma Java EE fornece um conjunto de tecnologias para o desenvolvimento de aplicacoes
robustas para a Web. Dentre as tecnologias disponveis atualmente, destacam-se para o
desenvolvimento de aplicacoes os servlets e paginas JSP (JavaServer Pages). servlets e
JSP sao duas tecnologias desenvolvidas pela Sun para desenvolvimento de aplicacoes na
Web a partir de componentes Java que executam no lado do servidor. A Figura 6.1 ilustra
a arquitetura da plataforma Java EE.
A utilizacao de servlets oferece diversas vantagens em relacao a outras tecnologias para
o desenvolvimento de aplicacoes Web. As principais vantagens sao herdadas da propria
linguagem Java, entre elas estao: Portabilidade, facilidade de programacao e a flexibilidade
da linguagem para o desenvolvimento. Em particular, os servlets sao mais eficientes,apresentam melhor usabilidade, maior poder na programacao, sao mais portateis, mais
seguros e mais baratos que um CGI (Common Gateway Interface) tradicional (HALL,
1998).
35
8/7/2019 Caso de uso JME
45/71
6.1. A Plataforma Java EE 36
Figura 6.1: Arquitetura da plataforma Java EE.
CGI e um padrao que determina a forma de comunicacao entre o servidor Web e
uma outra aplicacao rodando neste servidor e um script CGI e um programa que atende
requisicoes enviadas por um cliente e repassa para um servidor HTTP ( QUIN, 2009).
Um servlet tem um modelo de programacao parecido com um script CGI, porem os
programas de CGI necessitam de um processo para tratar cada nova solicita cao e no caso
dos servlets, podem existir varios ligados ao mesmo servidor, que estes sao executados
dentro de um mesmo processo. E este processo roda dentro de uma JVM, que gera
um encadeamento de processos para tratar cada solicitacao. Estes encadeamentos geram
muito menos overheads do que processos completos (PITTELLA, 2009).
6.1.1 Servlets
Segundo HALL (1998), servlet e uma resposta da tecnologia Java para a programacao
CGI. Sao programas que rodam em sevidores Web agindo como uma camada mediana
entre um pedido que vem de um browser Web ou outro cliente de HTTP.
O trabalho dos servlets se resumem em:
Ler qualquer dado enviado pelo usuario.
Observar qualquer outra informacao sobre o pedido que e embutido no pedido de
HTTP.
Gerar os resultados.
Formatar os resultados dentro de um documento.
Fixar parametros de resposta de HTTP apropriados.
8/7/2019 Caso de uso JME
46/71
6.1. A Plataforma Java EE 37
Enviar de volta o documento ao cliente.
Servlets sao classes Java instaladas junto a um Servidor que implemente um Servlet
Container, interagindo com clientes Web usando o paradigma request-response, ou seja,
um programa Java que estende funcionalidades de um servidor de aplicacoes Java quepermite a execucao de servlets comunicando com clientes.
O componente container, ou conteiner, e resposnsavel por dar suporte as APIs de
servlets e JSP. Gerencia as instancias dos servlets e fornece os servicos de rede necessarios
para as requisicoes e respostas. O container pode criar varias threads permitindo que
uma unica instancia servlet atenda mais de uma requisicao simultaneamente. A Figura
6.2 ilustra a relacao entre esses componentes.
Figura 6.2: Servlet container.
Os servlets sao independentes de protocolos e plataformas, podendo trabalhar comdiversos tipos de servidores, pois a API dos servlets nao assume nada a respeito do am-
biente do servidor. Diversas requisicoes podem ser feitas ao mesmo tempo em um unico
servidor.
O comportamento dos servlets que sera estudado para a construcao de aplicacoes
esta definido na classe HttpServlet do pacote javax.servlet. Tendo em vista o paradigma
request-response, cujo atende requisicoes realizadas por meio do protocolo HTTP, os ob-
jetos dos servlets podem capturar parametros desta requisicao, efetuar qualquer proces-
samento inerente a uma classe Java e enviar respostas na forma de paginas HTML, XML,
imagens entre outros (TEMPLE, 2004).Um servlet e basicamente definido pela Interface Servlet, uma classe de interface que
implementa os metodos init(), service() e destroy(), e a estrutura de uma classe servlet
contem os metodos doGet() e doPost(), como ilustrado na Figura 6.3.
Todos os seguintes metodos sao invocados por meio do metodo service() da classe de
interface.
8/7/2019 Caso de uso JME
47/71
6.2. XML - Linguaguem de marcacao extensvel 38
Figura 6.3: Ciclo de vida do servlet.
Metodo doGet: Trata requisicoes do tipo GET. Esse tipo pode ser enviado varias
vezes e alocado em um bookmark.
Metodo doPost: Trata requisicoes do tipo POST, permitindo que o cliente envie
dados do servidor Web uma unica vez.
Metodo doPut: Trata requisicoes do tipo PUT, permitindo que o cliente enviearquivos para o servidor, semelhante ao FTP.
Metodo doDelete: Trata requisicoes do tipo DELETE, permitindo que o cliente
remova determinada pagina ou documento do servidor.
Um servlet nao possui interface grafica, porem dentro de um servlet e possvel construir
um HTML, mas a visualizacao e entendimento e de alta complexidade quando se trata
de logicas extensas. Tendo em vista que o foco do estudo de caso esta em um ambiente
movel, nao e necessario a construcao de uma interface grafica para trabalhar junto com o
servlet.
6.2 XML - Linguaguem de marcacao extensvel
A Extensible Markup Language (XML) e uma linguagem de marcacao de dados sem
nenhum elemento de apresentacao embutido, ou seja, apenas com elementos de definicao
8/7/2019 Caso de uso JME
48/71
6.2. XML - Linguaguem de marcacao extensvel 39
de conteudo. O XML prove um formato para descrever dados estruturados que facilita
declaracoes mais precisas do conteudo e resultados mais significativos de busca atraves de
multiplas plataformas.
Segundo TITTEL (2002), a palavra extensvel reflete o fato de que a linguagem e
flexvel, escalonavel e adaptavel. Com esses tres fatores o desenvolvimento de aplicacoesem tres camadas (three-tier), que e o caso deste projeto, e altamente factvel com o XML.
Os dados podem ser distribudos entre as aplicacoes desktop para serem visualizados em
um navegador ou em servidores intermediarios para o processamento, permitindo que tais
dados possam ser facilmente combinados via software, com bancos de dados nas extremi-
dades da rede. Desta forma a troca de informacoes entre dispositivos moveis e servidores
remotos seria realizada de maneira mais comprimida e escalavel, alem de proporcionar
buscas mais eficientes. Esse ponto e de suma importancia, pois os dispositivos moveis
tipicamente possuem memoria limitada e baixo poder de processamento.
A estrutura de um documento XML e baseada em um modelo de arvore rotulada.Geralmente possui um no raiz especial acima do elemento raiz. Os nos internos sao
elementos rotulados com um nome e um conjunto de atributos (valor). Os nos folhas
contem:
Sequencias de caracteres
Anotacoes de processamento, normalmente no cabecalho do documento
Um comentario
Uma declaracao de entidade
Nos DTD (Document Type Declaration)
Podemos visualizar uma breve estrutura de um documento XML com sua respectiva
arvore na Figura 6.4.
6.2.1 Analise de documentos XML
A partir de um modelo no formato XML e necessario realizar a analise dos dados
embutidos atraves de uma tecnica denominada Parse. Segundo VELOSO (2007), Par-
sing e o processo de leitura e divisao do documento em elementos, atributos, entidades,comentarios e outros tipos de dados, por meio do qual poderao ser analisados e validados.
Existem algumas tecnicas para realizar o parse de um XML, como o pull parser, o
DOM e o push parser. No pull parser uma quantidade de dados e analisada de cada
vez, durante o parse sempre e solicitado a proxima parte que deve ser processada ate
chegar ao fim, geralmente isto e feito em um loop. Assim sao obtidas as informacoes do
8/7/2019 Caso de uso JME
49/71
6.2. XML - Linguaguem de marcacao extensvel 40
Figura 6.4: Estrutura do XML.
XML a medida que o parser e efetuado. Uma outra tecnica e o DOM, que utiliza ummodelo baseado em arvore e cria uma estrutura de dados na memoria, onde e possvel
acessar essa estrutura atraves de um conjunto de objetos. E muito simples de se utilizar,
porem e necessario ler o documento inteiro para montar a estrutura de arvore, para depois
exibir as informacoes que foram lidas, alem disso, pode ter muitos objetos armazenados na
memoria entao nao e recomendado para ser usado em Java ME. E o modelo push parser
e orientado a eventos, portanto ao ler um XML um objeto listener e notificado sempre
que novas tags sao encontradas.
8/7/2019 Caso de uso JME
50/71
8/7/2019 Caso de uso JME
51/71
7.2. Arquitetura do sistema 42
iteracoes. Cada iteracao contem um conjunto de estorias e no final desta o cliente pode
validar as implementacoes efetuadas e dar seu feedback. O XP utiliza ainda o conceito de
programacao em par. Enquanto uma das pessoas esta escrevendo o codigo a outra pessoa,
chamada de navegador, esta permanentemente revisando. Todo codigo desenvolvido e
coletivo, portanto utiliza-se padronizacao para simplificar o desenvolvimento (TELES,2004).
O XP oferece agilidade no processo de desenvolvimento de software e um feedback
rapido do cliente, o que e necessario quando se trata de desenvolvimento para celulares e
smartphones, por ser um sistema enxuto. Portanto, para este estudo de caso foi adotado
as praticas da metodologia agil XP, onde foram definidos dois releases, cada um composto
por duas iteracoes. As iteracoes dos releases foram descritas no decorrer deste trabalho.
7.2 Arquitetura do sistema
Para o trabalho que segue, foi abordado juntamente da plataforma Java ME, o uso
de servlets, dentro da arquitetura Java EE, interagindo com um cliente via HTTP para
estabelecer a comunicacao com o dispositivo movel. Visto que um servlet pode efetuar
qualquer processamento inerente a uma classe Java e enviar respostas na forma de docu-
mentos XML, para efetuar a troca de dados entre o dispositivo m ovel e o servidor remoto
de dados, que alimentara o sistema movel, foi utilizado os recursos que a linguagem XML
oferece.
A Figura 7.1 mostra o esquema de comunicacao para o trabalho proposto. Definido
por uma arquitetura Cliente - Servidor e baseado nas tres seguintes camadas:
Figura 7.1: Esquema de comunicacao.
8/7/2019 Caso de uso JME
52/71
7.3. Visao geral do sistema 43
7.3 Visao geral do sistema
E proposto um sistema movel gerador de pedidos para uma empresa revendedora de
bebidas. O sistema sera responsavel por cadastrar e editar clientes, gerar os pedidosrealizados, informar os dados dos pedidos, clientes e produtos. O objetivo do sistema e
informatizar e agilizar o processo de pedidos realizados pelos revendedores da empresa
distribuidora de bebidas. Atualmente a tarefa e feita manualmente atraves de consultas a
catalogos e toda informacao coletada e registrada em listas e repassada para a central da
empresa, onde os dados eram digitalizados para serem armazenados no banco de dados
central da distribuidora.
A empresa possui um sistema Web, que e o responsavel por alimentar o sistema movel.
Com este sistema a gerencia otimiza o acesso aos dados de forma segura, alem de facilitar
o trabalho dos revendedores. O revendedor realiza o pedido via celular ou smartphone, e
este e armazenado no aparelho. Quando o dispositivo acessar uma rede sem fio e possvel
atualizar o banco de dados do dispositivo e enviar os pedidos para um sistema Web que
ira armazenar as informacoes no banco de dados central da distribuidora, controlando
todas as informacoes referente a forca de vendas.
7.4 Diagrama de