DESENVOLVIMENTO DE

APLICATIVOS PARA DISPOSITIVOS

MVEIS NA PLATAFORMA J2ME



Trabalho de Concluso de Curso

Engenharia da Computao
















Bruna Georgina Bunzen de Albuquerque Romeiro
Orientador: Srgio Castelo Branco Soares


Recife, Maio de 2005

ESCOLA POLITCNICA
DE PERNAMBUCO

Este Projeto apresentado como requisito parcial
para obteno do diploma de Bacharel em
Engenharia da Computao pela Escola
Politcnica de Pernambuco Universidade de
Pernambuco.




DESENVOLVIMENTO DE
APLICATIVOS PARA DISPOSITIVOS
MVEIS NA PLATAFORMA J2ME



Trabalho de Concluso de Curso

Engenharia da Computao
















Bruna Georgina Bunzen de Albuquerque Romeiro
Orientador: Srgio Castelo Branco Soares


Recife, Maio de 2005

ESCOLA POLITCNICA
DE PERNAMBUCO




Bruna Georgina Bunzen de Albuquerque Romeiro














DESENVOLVIMENTO DE
APLICATIVOS PARA DISPOSITIVOS
MVEIS NA PLATAFORMA J2ME


i
ESCOLA POLITCNICA
DE PERNAMBUCO

Resumo
Este trabalho apresenta um estudo sobre dispositivos mveis e as plataformas J2ME e J2EE,
explicando a implementao de um prottipo de software que auxiliar a obteno de
informaes sobre docentes e discentes do NUPEC (Ncleo de Pesquisa em Engenharia da
Computao) da Escola Politcnica da Univesidade de Pernambuco. O aplicativo cliente foi
desenvolvido em J2ME e ser responsvel por fazer requisies para um aplicativo servidor. Tais
requisies so consultas relativas a informaes disponibilizadas em uma base de dados com
informaes sobre os projetos e pessoas do NUPEC. A aplicao servidora foi implementada
utilizando a plataforma J2EE e ser responsvel por responder s requisies das aplicaes
cliente. Alm de aplicar tecnologia no sistema implementado, este trabalho descreve tais
tecnologias que utilizam a comunicao sem fio, permitindo assim avaliar o potencial das
mesmas nesta rea to promissora.

Palavras chaves: Dispositivos mveis, J2ME, J2EE, Gerenciamento de informaes.


ii
ESCOLA POLITCNICA
DE PERNAMBUCO

Abstract
This work presents a study of mobile devices, J2ME and J2EE platforms, explaining the
implementation of a software prototype that will allow information retrieval about professors and
students of NUPEC (Computing Engineering Research Center) of the Polythechnic School of
Engineering of the Pernambuco State University. The client application was developed using the
J2ME platform and will send requests to a server application. Such requests are related to reports
of information from a database that stores data related to NUPEC projects and people. The
server application was implemented using the J2EE platform and must response to the client
applications requests. Besides applying technologies in the implemented software, this work
presents such technologies that allow wireless communication, allowing to evaluate their
potential in such promising area.


Keywords: Mobile devices, J2ME, J2EE, information management

iii
ESCOLA POLITCNICA
DE PERNAMBUCO

Sumrio
ndice de Figuras v
ndice de Quadros vi
ndice de Quadros vi
Tabela de Smbolos e Siglas vii
1 Introduo 9
2 Tecnologias 11
2.1 Java 11
2.2 Plataforma Java 2 Micro Edition (J2ME) 13
2.2.1 Perfis 14
2.2.2 Configuraes 15
2.2.3 Mquina Virtual J2ME 15
2.3 Java 2 Enterprise Edition (J2EE) 16
2.4 Struts 17
2.5 Wireless 18
2.6 Arquitetura Cliente/Servidor 18
2.7 HTTP (Hypertext Transfer Protocol) 19
2.7.1 Generic Connection Framework (GCF) 21
3 Comunicao Mvel 23
3.1 Histrico da Comunicao Mvel 23
3.2 Dispositivos Mveis 24
3.2.1 Vantagens dos Dispositivos Mveis 25
3.2.2 Desafio dos Dispositivos Mveis 26
4 Uma ferramente para gerenciamento de informaes e recursos humanos 27
4.1 Ferramentas Utilizadas 29
4.2 Arquitetura da Aplicao 30
4.2.1 Arquitetura do Cliente da Aplicao 31
4.2.2 Arquitetura Servidor da Aplicao 36
4.3 Limitaes do Contexto 39
4.4 Resultados 39
5 Concluses e Trabalhos Futuros 42
5.1 Concluses 42
5.2 Trabalhos Futuros 43


iv
ESCOLA POLITCNICA
DE PERNAMBUCO




v
ESCOLA POLITCNICA
DE PERNAMBUCO

ndice de Figuras
Figura 1. Plataforma Java 2 Fonte [29] ........................................................................................................ 12
Figura 2. Diviso da Plataforma Java Fonte [23].......................................................................................... 13
Figura 3. Arquitetura J2ME.............................................................................................................................. 14
Figura 4. Camadas da Arquitetura J2EE......................................................................................................... 16
Figura 5. ConsultaAction extendendo a classe Action..................................................................................... 17
Figura 6. ActionSrvlet no web.xml .................................................................................................................... 18
Figura 7. Protocolo http ..................................................................................................................................... 20
Figura 8. Fromato de Requisio de Mensagem.............................................................................................. 21
Figura 9. Hierarquia das interfaces no GCF e Classes relacionadas Fonte [35] ........................................ 21
Figura 10. Relao entre HttpConnection e ContentConnection ..................................................................... 22
Figura 11. Dispositivos Mveis Fonte: [29]...................................................................................................... 24
Figura 12. Diagrama de Seqncia da Comunicao entre o cliente e o Servidor .......................................... 28
Figura 13. IDE Eclipse.......................................................................................................................................... 29
Figura 14. Emulador MediaControlSkin............................................................................................................ 30
Figura 15. Diagrama de Classe do Mdulo Cliente ........................................................................................... 31
Figura 16. Ciclo de Vida de um Midlet ............................................................................................................... 32
Figura 17. Resultado da Pesquisa por Professor................................................................................................ 35
Figura 18. Diagrama de Classes do mdulo Servidor........................................................................................ 37
Figura 19. Diagrama de Classes do Sistema....................................................................................................... 40


vi
ESCOLA POLITCNICA
DE PERNAMBUCO

ndice de Quadros


Quadro 1. Obtendo a conexo com o HttpConnection
22
Quadro 2. Mtodo startApp
32
Quadro 3. Mtodo destroyApp
32
Quadro 4. Envio de dados da consulta
33
Quadro 5. Classe conexo recebendo resposta do servidor
33
Quadro 6. Tratamento da resposta vinda do servidor
34
Quadro 7. Mtodo setResponse no TccMIDlet
34
Quadro 8. Propriedades do cabealho HTTP
35
Quadro 9. Construtor da classe Conexo
36
Quadro 10. Mtodo getInstance da classe Fachada
36
Quadro 11. Obtendo o tipo da pesquisa
37
Quadro 12. Exemplo da consulta de professores
38
Quadro 13. Dados encaminhados para o cliente
38
Quadro 14. Arquivo Tcc.jad
40



vii
ESCOLA POLITCNICA
DE PERNAMBUCO

Tabela de Smbolos e Siglas
J2ME Java 2 Micro Edition
NUPEC Ncleo de Pesquisa de Engenharia da Computao
DSC Departamento de Sistemas Computacionais
API Interface Programming Application
J2SE Java 2 Standard Edition
J2EE Java 2 Enterprise Edition
PDA Personal Digital Assistant
JVM Java Virtual Machine
CDC Connected Device Configuration
CLDC Connected Limited Device Configuration
MIDP Mobile Information Device Profile
KVM Kilo Virtual Machine
EIS Enterprise Information System
HTML Hiper Text Markup Language
XML Extensible Markup Language
JSP Java Server Pages
HTTP Hypertext Transfer Protocol
EJB Enterprise Java Beans
MVC Model View Controller
TCP Transmission Control Protocol
UDP User Datagram Protocol
GCF Generic Connection Framework
FDMA Frequency Division Multiple Access
TDMA Time Division Multiple Access
CDMA Code Division Multiple Access
GSM Global Standard Mobile
SIM Subscriber Indentification Module
PC Personal Computer




viii
ESCOLA POLITCNICA
DE PERNAMBUCO

Agradecimentos

A Deus, pela fora concedida e pela oportunidade de estar concluindo mais uma
etapa da minha vida.
minha me, Ana Georgina Valena Bunzen, minhas tias Iracema Ferreira
Bunzen (In memorian) e Georgiana Bunzen Gianelli e meus irmos Fbio Bunzen
Romo e Rmulo Costa Romo Jnior, pelo amor, fora e apoio em todos os
momentos.
Ao meu pai, Murilo de Albuquerque Romeiro por todo carinho e segurana que
me foi passada.
Ao meu orientador, Prof. Srgio Soares pela ajuda e dedicao para que esse
trabalho fosse concludo com sucesso.
Aos professores de Engenharia da Computao da Universidade de
Pernambuco, que sempre que solicitados se mostraram disponveis a esclarecer
dvidas e questionamentos.
Aos Professores Ricardo Massa e Marcio Cornlio por terem aceitado o convite
de compor a banca.
Ao colega Bruno Jamir, pela pacincia e pelos conhecimentos compartilhados
que foram de grande importncia para o trmino deste trabalho.
Aos colegas, Lvia Brito e Leandro Marques pelo empenho em ajudar sempre
que foram requisitados.
s amigas do Club da Lulu, por cinco anos de amizade e companheirismo.
Aos demais colegas do curso de Engenharia da Computao, com destaque
especial para Rodrigo Cursino, Fernando Antonio e Cludio Cavalcante pelos anos de
amizade que tornaram-se um grande aprendizado.





9
ESCOLA POLITCNICA
DE PERNAMBUCO


1

Introduo
Nos ltimos anos vem ocorrendo um notvel aumento na utilizao de dispositivos mveis, que
fazem uso da tecnologia de comunicao sem fio, em especial dos telefones celulares. Tais
aparelhos apesar do poder computacional limitado, a cada momento possuem uma nova forma,
tamanho, aumento na capacidade de processamento, alm de novos aplicativos agregados.
medida que a demanda por funcionalidades aumenta, as empresas de telefonia celular
vm acrescentando novas tecnologias a tais aparelhos, estimulando nos consumidores o desejo
de possuir o mais recente modelo de uma determinada marca.
Devido a esse crescente mercado, cresce tambm a motivao no sentido de desenvolver
novas aplicaes para esses dispositivos. A presena da mquina virtual Java nesses
equipamentos torna possvel o desenvolvimento de aplicaes utilizando a tecnologia Java 2
Micro Edition (J2ME), uma verso reduzida da linguagem Java utilizada para dispositivos
mveis.
O desenvolvimento de aplicativos para celulares vem tornando-se cada vez mais
freqente nas empresas especializadas em produo de software. Contudo, esses sistemas no
devem funcionar de maneira isolada. Entretanto, ignorar o fato de tais aparelhos serem
inerentemente objetos de comunicao subestimar o potencial deste artefato. Para tanto
necessrio definir um protocolo de comunicao com sistemas corporativos, de forma que, possa
ocorrer envio de informaes entre as partes. Os celulares comearam a adquirir novas
caractersticas, deixando de servir simplesmente para telefonia, ou seja, a mera transmisso de
voz est perdendo o espao para transmisso de dados.
O objetivo desse trabalho relatar como funcionou o desenvolvimento de um aplicativo
para dispositivos mveis, com o propsito de ser utilizado por discentes e docentes do NUPEC
(Ncleo de Pesquisa em Engenharia da Computao) da Escola Politcnica de Pernambuco,
unidade da Universidade de Pernambuco. O NUPEC um laboratrio onde os professores do
Departamento de Sistemas Computacionais (DSC) orientam seus alunos de iniciao cientfica.
A inteno de desenvolver um sistema para celular surgiu quando alguns usurios do
NUPEC se depararam com situaes em que era necessrio obter informaes tanto de
professores, quanto de alunos ou das atividades relacionadas com as pesquisas realizadas no
ncleo, mesmo quando no estavam presentes fisicamente no mesmo.
A aplicao prover aos usurios o servio de consulta das informaes disponibilizadas
para os freqentadores do ncleo. Um usurio que possuir o aplicativo instalado em seu celular
pode, por exemplo, saber as pessoas que esto em determinado momento no ncleo ou as que
passaram por l em um determinado dia, alm de outras consultas.
Captulo



10
ESCOLA POLITCNICA
DE PERNAMBUCO

O sistema est dividido em um mdulo cliente e um mdulo servidor. O cliente o
aplicativo que estar rodando no celular e ter como uma de suas responsabilidades, receber a
entrada de dados informados pelo usurio. Uma comunicao com o servidor deve ser
estabelecida para que os dados sejam transmitidos. Ao receber os dados, o servidor deve
process-los e ento encaminh-los de volta como resposta requisio enviada pelo cliente.
O Captulo 2 explica as tcnicas que foram utilizadas no desenvolvimento tanto do lado
cliente quando do lado servidor.
Um histrico da comunicao mvel, bem como as vantagens e desvantagens dos
dispositivos mveis apresentado no Captulo 3.
O Captulo 4 mostra como foi implementado tanto o mdulo cliente quando o mdulo
servidor com seus respectivos diagramas de classes. Por fim, o Captulo 5 apresenta concluses
que podem ser tiradas com o presente trabalho, bem como sugestes de trabalhos futuros.






11
ESCOLA POLITCNICA
DE PERNAMBUCO


2

Tecnologias
2.1 Java
Java uma linguagem de programao de alto nvel, que segue o paradigma de programao
orientada a objeto. Devido sua portabilidade, Java pode ser executada em diferentes ambientes
operacionais dentro do conceito escreva uma vez, execute em qualquer lugar (Write Once, Run
Anywhere - WORA). A linguagem tambm possui a presena de mecanismos de tratamento de
excees que tornam as aplicaes mais robustas, no permitindo que elas falhem mesmo quando
esto rodando sob condies anormais. [4]. As bibliotecas que fazem parte de Java definem
interfaces portveis.
Java tambm possui um coletor de lixo (Garbage Collector CG). A coleta de lixo
uma eficiente tcnica de liberao de memria utilizada pela linguagem Java [28]. Muitas
linguagens permitem que o programador aloque um espao de memria em tempo de execuo
utilizando ponteiros e pertencendo ao programador o dever de liberar a memria quando esta no
estiver mais sendo utilizada. Esta, geralmente, uma tarefa complexa e propensa a erros, uma vez
que deixa a cargo do programador o gerenciamento de memria da aplicao [28]. O sistema de
coleta de lixo de Java tira essa responsabilidade do programador, passando essa responsabilidade
para o coletor de lixo que verifica quais os ponteiros de memria que no tm mais referncias
apontando para eles e, ento, libera a memria.
A linguagem Java tem a inteno de ser usada em ambientes de rede/distribudos. Nessa
direo, grande nfase tem sido colocada na segurana. O Java permite a construo de sistemas
livres de vrus e adulteraes [13].
Com essas qualidades, Java pode ser utilizada para a criao de vrios tipos de aplicativos,
desde aplicaes standalone (local) at aplicaes designadas para serem controladas pelo
software que as executa, tais como APPLETS
1
[28], SERVLETS
2
[30] ou MIDLETS
3
[18] .



1
Programas escritos em Java que podem ser inseridos em documentos de hipertextos HTML, carregados
na web e executados em um brouwser.
2
Aplicaes executadas em um servidor web
3
Aplicaes executadas em dispositivos mveis
Captulo



12
ESCOLA POLITCNICA
DE PERNAMBUCO


A API (Applications Programming Interface) de Java consiste em um conjunto de
bibliotecas de tempo de execuo que fornecem ao desenvolvedor de software uma forma padro
de acessar os recursos do sistema [31]. A especificao da API Java assim como da mquina
virtual, devem ser implementados para cada plataforma que para garantir a independncia das
plataformas.
A mquina virtual Java um computador hipottico, implementado como uma aplicao
de software em uma mquina real [28]. A portabilidade e a segurana so caractersticas da
plataforma Java que so possibilitadas pela existncia da mquina virtual.
Devido ao desenvolvimento da linguagem Java e aos diferentes contextos nos quais ela
est sendo aplicada, encontrou-se a necessidade de dividi-las em 3 edies, so elas:

Java 2 Standard Edition (Java 2 Edio Padro, J2SE) : possui um conjunto de
ferramentas para o desenvolvimento de aplicaes desktop;
Java 2 Enterprise Edition (Java 2 Edio Corporativa, J2EE): um super conjunto da
J2SE, voltado para aplicaes corporativas e distribudas, voltada para servidor e
utilizando EJB (Entreprise JavaBeans);
Java 2 Micro Edition (Java 2 Edio Micro, J2ME): voltada para o desenvolvimento de
aplicativos para dispositivos mveis. J2ME um subconjunto da J2SE.
Java Card: uma soluo da unio smart card com algumas funcionalidades de
segurana de redes. uma plataforma que garante a privacidade e segurana de
informaes.


Figura 1. Plataforma Java 2 Fonte [29]





13
ESCOLA POLITCNICA
DE PERNAMBUCO

Seguindo o foco deste trabalho, ocorrer uma breve explicao das caractersticas e
funcionalidades da plataforma J2ME.



2.2 Plataforma Java 2 Micro Edition (J2ME)
Java 2 Micro Edition (J2ME) [17] a edio da linguagem Java para ser usada em dispositivos de
computao portteis e mveis, que possuem as seguintes caractersticas: mobilidade, baixa
capacidade de processamento e pouca memria disponvel, alimentao eltrica por baterias,
pequenas reas de display, e limitados e variados mtodos de entrada e sada. Alguns exemplos
destes dispositivos seriam os telefones celulares, pagers, PDAs (Assistentes Digitais Pessoais),
Palms, entre outros [11].
J2ME no um novo tipo de linguagem Java, ela foi apenas adaptada para poder executar
os programas nos dispositivos acima citados. Sendo assim um programa na plataforma J2ME
funciona corretamente nas outras duas plataformas, visto que a API utilizada na Micro Edio
um subconjunto das Edies Padro e Corporativa.
A subdiviso da plataforma Java em especial destacando a plataforma J2ME pode ser
observada na Figura 2.


Figura 2. Diviso da Plataforma Java Fonte [23]




14
ESCOLA POLITCNICA
DE PERNAMBUCO

Atravs de J2ME, torna-se possvel desenvolver, atualizar e instalar novas aplicaes segundo
as necessidades particulares de cada usurio [17]. As aplicaes que utilizam J2ME vo desde
jogos at aplicaes que acessam banco de dados, dentre outras opes.
Existe uma diversidade de dispositivos, no qual estes apresentam muitos pontos em comum,
mas diferenciam-se em suas formas, funcionalidade e caractersticas. Existem tambm
dispositivos com uma grande variedade de capacidade de processamento, memria e interao
com o mundo exterior (interface com o usurio, mtodos de entrada e sada de informaes e
dados). Afirmar que uma tecnologia serve para todos os dispositivos da mesma famlia, tal
como nas outras edies de Java, no funciona nos dispositivos de recursos limitados devido a
todas essas diferenas [11].
Devido diferena de tamanho e funcionalidade nesses dispositivos foram estabelecidos
conceitos essenciais e de grande importncia na plataforma J2ME que foi dividida em camadas
para facilitar seu entendimento. So elas: Perfis, Configuraes, JVM e o Sistema Operacional,
como pode ser observado na Figura 3.

Figura 3. Arquitetura J2ME

2.2.1 Perfis
O perfil a camada mais visvel para usurios e desenvolvedores das aplicaes, definindo um
conjunto mnimo da API disponvel em uma classe particular dos dispositivos, representando um
segmento de mercado particular. Os perfis so implementados para um tipo de configurao
particular variando de acordo com os dispositivos para o qual ele ser utilizado.
As aplicaes so feitas de acordo com um perfil especfico, podendo ser instalada em
qualquer dispositivo que possua suporte ao perfil determinado. O perfil que este trabalho ter
foco o MIDP [23] Mobile Information Device Profile (Perfil do Dispositivo de Informao
Mvel). Este perfil para aplicaes mveis e ajuda a complementar a configurao CLDC e ser
detalhado adiante.



15
ESCOLA POLITCNICA
DE PERNAMBUCO

O Perfil do Dispositivo de Informaes Mveis (MIDP) o primeiro perfil disponvel
para a plataforma J2ME. A combinao do CLDC e do MIDP fornece um ambiente completo de
desenvolvimento para a criao de aplicaes em celulares e pagers [25]. As aplicaes que
conseguem executar em dispositivos que possuem suporte a MIDP so chamados de MIDlets.
Para um dispositivo ter suporte ao MIDP, ele deve possuir um display de pelo menos 96 x
54 pixels e uma memria de pelo menos 128 Kbytes.

2.2.2 Configuraes
Uma configurao define uma plataforma mnima para um grupo de dispositivos com
caractersticas similares, tanto na memria quanto no poder de processamento. Sendo assim, uma
configurao define as caractersticas suportadas tanto pela prpria linguagem de programao
Java quanto pela mquina virtual e tambm suas bibliotecas de classes e APIs, as quais um
determinado fabricante pode esperar que estaro disponveis em todos os dispositivos de uma
mesma categoria [17].
Apenas duas configuraes so aceitas pela Sun e sero descritas a seguir:
CDC Connected Device Configuration (Configurao para dispositivos
conectados) rege as configuraes para aparelhos mveis um pouco maiores,
com um mnimo de 2 megabytes de memria disponveis. Alguns exemplos desses
dispositivos so: televiso com internet, sistema de navegao de carros, entre
outros;
CLCD - Connected, Limited Device Configuration (Configurao para
dispositivos com limite de conexo) responsvel pela configurao de
aparelhos pequenos e com algumas restrio de recursos como celulares e pagers.
Utiliza uma mquina virtual chamada de KVM (Kilo Virtual Machine). Esta bem
reduzida em relao a mquina virtual Java tradicional e faz uso de um conjunto
de bibliotecas de classes para ser utilizada dentro de um Perfil MIDP;

2.2.3 Mquina Virtual J2ME

A mquina virtual um dos principais fundamentos da tecnologia Java, permitindo que as
aplicaes escritas possam ser portveis para diversos tipos de hardware e diferentes sistemas
operacionais.
Em J2ME deve-se utilizar uma mquina virtual Java que seja apropriada para os
dispositivos como telefones celulares, pagers e PDAs que possuem tamanho de memria
reduzido [17].
A mquina virtual que o aplicativo do trabalho em questo faz referncia a KVM (Kilo
Virtual Machine), utilizada pela configurao CLDC, possuindo cerca de 80K de memria. A
KVM pode executar em qualquer sistema que possua um processador de 16 a 32 bits e um total
de memria de 160 a 512K, devido a essas restries no possui suporte a tipos de dados longos e
pontos flutuantes. Seu projeto foi baseado em algumas importantes consideraes, incluindo o
tamanho reduzido para conservar um melhor espao em memria quanto possvel (tanto em
termos de armazenamento quanto execuo) e a capacidade de rodar em processadores de
pequeno poder computacional [17].




16
ESCOLA POLITCNICA
DE PERNAMBUCO

2.3 Java 2 Enterprise Edition (J2EE)
A arquitetura J2EE foi desenvolvida sobre a plataforma J2SE (Java 2, Standard Edition)
utilizando assim as APIs bsicas para o desenvolvimento de programas e aplicaes. Logo,
baseada na linguagem Java e segue a mesma lgica de escrever apenas uma vez e conseguir rodar
em qualquer plataforma.
J2EE faz uso do modelo de aplicao multicamadas onde cada aplicao lgica dividida
em componentes de acordo com sua funcionalidade e vrios componentes das aplicaes podem
ser instalados em diferentes mquinas dependendo da camada em que ele se encontra.
As camadas podem ser divididas da seguinte forma:
A camada cliente que roda em uma mquina cliente;
A camada de componentes WEB, aplicaes J2EE que rodam no servidor.;
A camada de informaes (EIS Enterprise Information System) que tambm
roda no servidor;
Essas camadas podem ser melhor observadas na Figura 4.

Figura 4. Camadas da Arquitetura J2EE

O lado cliente pode ser dividido em duas partes:
Pginas web dinmicas como, por exemplo, HTML (Hiper Text Markup
Language) ou XML (Extensible Markup Language) [33] que so geradas pelos
componentes web presentes na camada web.
Web browser que so os responsveis por redirecionar as pginas a medida que
so recebidas pelo servidor.



17
ESCOLA POLITCNICA
DE PERNAMBUCO

O servidor Web quem executa as tecnologias servlets e JSP (Java Server Pages) vindas
de clientes externos. Os servlets so programas Java desenvolvidos no lado servidor e que trata
das requisies HTTP feitas pelos clientes, podendo responder essas requisies dinamicamente
ou simplesmente repassar essas requisies para outros servlets ou outros servidores.
Um arquivo JSP possui tanto cdigo Java como HTML e logo aps a primeira execuo
ento transformado em um servlet, esse servlet compilado para que possa ser executado.
Quando um protocolo HTTP recebe uma requisio de um JSP, ele repassa essa requisio para o
container [2], uma interface entre o servidor e um componente, neste caso o JSP, e este ento
chama o respectivo servlet compilado e devolve o HTML para o servidor HTTP.
O container EJB uma interface entre o servidor EJB e os componentes de negcio ou
componentes EJB, ou ainda beans. Os beans so os objetos da especificao EJB e executam o
servio funcional, como transferncia bancria, compra de produtos pela Web, inscrio para um
congresso, etc., e o servidor EJB executa o servio nofuncional que configurado pelo
desenvolvedor da aplicao EJB [24].

2.4 Struts
O Struts [14] um framework open source da Jakarta [16]. Esse framework utiliza as mesmas
tecnologias de aplicaes Java, porm organiza-se de maneira diferente. A idia principal do
Struts separar os cdigos responsveis pelo processamento, daqueles cdigos voltados para a
apresentao de dados. Essa separao pode ser feita sem a utilizao desse framework, porm
fica sob responsabilidade do desenvolvedor. O Struts implementa a arquitetura Model View
Controller (MVC Modelo Visualizao - Controle) [10].
A arquitetura MVC [10] define a total separao do Modelo (objetos pertencentes
camada de negcios), da Visualizao ( interface com o usurio ou com outro sistema qualquer) e
do Controlador, que controla o fluxo do sistema. de responsabilidade do controlador interceptar
as requisies HTTP vindas do cliente.
O Struts possui a classe Java denominada Action, onde est a lgica para obter cada
requisio. Um objeto Action o responsvel pelo processamento dos dados que so enviados
atravs de uma determinada requisio. Para escrever um Action necessrio herdar da classe
org.apache.struts.action.Action e deve-se sobrescrever o mtodo execute. A
Figura 5 mostra um trecho de cdigo do sistema em questo onde uma classe Action criada e
o mtodo execute sobre-escrito.


Figura 5. ConsultaAction extendendo a classe Action



18
ESCOLA POLITCNICA
DE PERNAMBUCO


A classe ActionServlet o controle do Struts e deve ser configurada para interceptar todas
as requisies e ento direcion-las para os Actions correspondentes. Um trecho de cdigo
referente a configurao do ActionServlet no web.xml pode ser visto na Figura 6.




Figura 6. ActionSrvlet no web.xml

Para que o ActionServlet consiga fazer o direcionamento de requisies corretamente,
necessrio configurar os Actions existentes em um arquivo de configurao chamado
struts-config.xml e este arquivo que deve conter todas as informaes necessrias para
o funcionamento desse framework.

2.5 Wireless
Redes sem fio [8] so uma nova alternativa s redes convencionais com fio, fornecendo as
mesmas funcionalidades, porm de forma flexvel pois permite uma comunicao entre diversos
pontos sem a necessidade de utilizar cabos (wire = fio, less = sem). Essa tecnologia faz uso de um
sistema de antenas interligado entre si que transmite as informaes via onda de rdio ou
infravermelhas, disponibilizando a portabilidade e a praticidade da informao independente do
lugar, perdendo assim a dependncia de objetos fixos.
As redes sem fio vm sendo amplamente utilizadas, pois permitem uma comunicao de
alta velocidade a baixo custo. O custo semelhante ao de uma conexo discada, porm enquanto a
velocidade via modens chega a no mximo de 56Kbits, o acesso via rdio possui uma velocidade
mnima de 64Kbits.

2.6 Arquitetura Cliente/Servidor
O trabalho tema desta monografia foi desenvolvido em um ambiente distribudo, onde um cliente
se comunica com um servidor depois de estabelecida uma conexo. Ou seja, uma tpica relao
cliente/servidor onde a conexo feita entre a plataforma Java 2 Plataform, Enterprise Edition
(mdulo servidor) e a Java 2 Plataform, Micro Edition (mdulo cliente).




19
ESCOLA POLITCNICA
DE PERNAMBUCO

No servidor, aplicaes J2EE podem ser desenvolvidas e implantadas utilizando qualquer
uma das vrias aplicaes servidoras disponveis nesta plataforma. Este trabalho faz uso do
framework Struts, desenvolvido pela Jakarta, como explicado na Seo 2.5.
No cliente, aplicaes so desenvolvidas e essas aplicaes podem executar em qualquer
dispositivo com suporte a MIDP como, por exemplo, aparelhos celulares, pagers ou assistentes
pessoais (PDA). Dessa forma, possvel abranger diversos tipos de clientes tornando as
aplicaes mais acessveis.
Muitas aplicaes s conseguem o resultado desejado aps estabelecer uma conexo com
o ambiente servidor. Esta conexo pode permanecer ativa durante todo ciclo de vida da aplicao
ou ser ativada apenas quando for necessria uma comunicao com o servidor.
Para obter uma soluo na tecnologia J2ME, importante ser observado que tanto a
conexo de rede quanto os recursos so bastante limitados, o que no reflete um desenvolvimento
tpico em um computador que possui um ambiente fixo de rede. Em um servio mvel nem
sempre possvel ter uma conexo ativa de rede, variando de acordo com a localizao
geogrfica.
O HTTP (Hypertext Transfer Protocol) o nico protocolo de transporte que suportado
pela plataforma J2ME, conseqentemente o protocolo HTTP prov a comunicao entre a
aplicao MIDP e o servidor J2EE.


2.7 HTTP (Hypertext Transfer Protocol)

Um dos mais crticos aspectos de J2ME a questo de obter conexo com uma rede de
computadores. Embora alguns servios J2ME possam ser utilizados sem ser necessrio estar
conectado a uma rede, a habilidade de fazer conexo com uma rede de computadores prov
plataforma J2ME acesso aos recursos disponveis nesta rede.
Muitos servios J2ME suportam essa capacidade, como, por exemplo, abrir uma porta
para mandar e receber emails, exatamente como ocorre em um computador padro, s que dentro
do espao mvel. Essa plataforma tornou-se um cliente capaz de interagir com sistemas padres,
bancos de dados, Intranet corporativas e a Internet [34].
O HTTP [36] um protocolo de requisio e respostas, ou seja, o MIDP cliente manda
um HTTP request para o servidor J2EE que analisa a requisio e retorna um HTTP response,
como pode ser visto na Figura 7. Esse protocolo no mantm ligao permanente entre o cliente e
o servidor, ou seja, depois de enviar a resposta para o cliente, o servidor toma a iniciativa de
fechar a conexo.




20
ESCOLA POLITCNICA
DE PERNAMBUCO



Figura 7. Protocolo HTTP

O HTTP um protocolo de comunicao ideal para aplicaes mveis utilizando Java,
visto que o MIDP 1.0 suporta o HTTP, j outros protocolos como o TCP (Transmission Control
Protocol) e o UDP (User Datagram Protocol) so opcionais no MIDP 1.0, uma vez que no so
todos os servios do MIDP que suportam socket ou o UDP.
Os principais mtodos que existe no protocolo HTTP so:
GET: recupera as informaes identificadas no recurso da rede. Se o recurso for
um processo executvel, ele retornar a resposta do processo e no seu texto,
Tambm existe o GET Condicional que s trar a informao se ela foi modificada
depois da data da ltima transferncia;
HEAD: variante do mtodo GET, porm no possui a transferncia de dados da
entidade para o cliente. Solicita ao servidor apenas o cabealho com informaes
sobre o recurso, normalmente utilizadas para depurao;
POST: permite que o cliente envie mensagens e contedos de formulrio para o
servidor que vai manipular os dados da maneira desejada. Atravs desse mtodo,
pode-se, por exemplo, postar uma mensagem em uma lista de discusso;
PUT: esse mtodo permite que um cliente, que possua autoridade, atualize ou
armazene dados em um recurso, se o recurso j existir. Caso no exista, permite
que o recurso seja criado;
DELETE: um cliente autorizado solicita ao servidor a remoo dos dados
identificado na URI;
LINK: estabelece uma ligao entre pginas.

Um exemplo do formato de mensagem do protocolo HTTP pode ser visto na Figura 8.




21
ESCOLA POLITCNICA
DE PERNAMBUCO


Figura 8. Formato de Requisio de Mensagem


Na primeira linha da solicitao contm o mtodo, seguido do local de onde o recurso foi
solicitado indicado pela URL e a verso do HTTP que est sendo utilizado. Dos mtodos
disponveis, o GET e o POST so os mais utilizados.
O MIDP possui um suporte padro para HTTP 1.1, APIs para gerao de requisies de
HTTP GET, POST e HEAD, manipulao bsica de cabealho e gerao de mensagens.
O subconjunto da arquitetura J2ME responsvel por conseguir estabelecer uma conexo
com uma rede desejada chamado Generic Connection Framework (GCF).

2.7.1 Generic Connection Framework (GCF)
O Generic Connection Framework fica localizado no pacote javax.microedition.io e possui uma
classe (Connector), um exceo (ConnectionNotFoundException) e oito interfaces,
como pode ser vista na Figura 9.


Figura 9. Hierarquia das interfaces no GCF e Classes relacionadas Fonte [35]



22
ESCOLA POLITCNICA
DE PERNAMBUCO


No incio da hierarquia est a interface Connection, o tipo mais bsico de conexo, e
todas as outras interfaces herdam dela. medida que se percorre para baixo nos nveis da
hierarquia, as conexes vo tornando-se mais complexas.
A classe Connector utilizada para gerar instncias de conexo utilizando os mtodos
que possui. A instncia gerada suportada pela interface Connection ou uma de suas
descendentes no nvel da hierarquia. Essa classe possui trs mtodos open, com as seguintes
assinaturas:
open(String url)
open(String url, int mode)
open(String url, int mode, boolean timeouts)

Os parmetros passados por estes mtodos significam:

A url a URL da conexo;
O mode a mtodo de acesso;
O timeout uma forma de indicar que uma exceo ser levantada ou no, caso
ocorra um estouro no tempo
Esse trabalho fez uso da interface HttpConnection que herda da
ContentConnection, como pode ser visto na Figura 10 .

Figura 10. Relao entre HttpConnection e ContentConnection

Aps obtida uma instncia de HttpConnection,para abrir a conexo com entre o
cliente e o servidor foi utilizado o mtodo open, da classe Connector, sendo passada apenas a
URL como parmetro, podendo ser observado no Quadro 1.







Quadro 1. Obtendo a conexo com o HttpConnection
String url = "http://localhost:8080/tcc/consulta.do";
HttpConnection conn = null;
conn = (HttpConnection) Connector.open(this.url);
conn.setRequestMethod(HttpConnection.POST);




23
ESCOLA POLITCNICA
DE PERNAMBUCO


3

Comunicao Mvel
3.1 Histrico da Comunicao Mvel
Um sistema de comunicao mvel tem como caracterstica a possibilidade de movimento
relativo entre as partes como, por exemplo, a comunicao entre o telefone celular e a estao
base na telefonia celular. Sistemas mveis usam a tecnologia sem fio para possibilitar uma
comunicao transparente enquanto o usurio se desloca [7].
O desejo da humanidade em comunicar-se livre de fios ocorre desde os primrdios da
civilizao. Na Grcia antiga o uso de sinais de fumaa mencionado como forma de
comunicao. No final do sculo XVIII, Claude Chape inventa a telegrafia ptica (1794),
possibilitando a comunicao sem fio para longas distncias. Em 1820, Hans Christian Oersted
descobre experimentalmente que a corrente eltrica produz um campo magntico [7]. Em 1864,
James C. Maxwell lana os fundamentos tericos sobre campos magnticos com suas famosas
equaes. Em 1876, Alexander Graham Bell inventa o telefone [7].
A comunicao mvel teve alguns marcos importantes dentre eles podem ser destacados:
O aparecimento dos primeiros sistemas pblicos de telefonia mvel dos Estados
Unidos, at ento com poucos usurios, sendo utilizado apenas por alguns
negociantes e por policiais que possuam rdios receptores e transmissores nos
veculos. [6]
Surgimento de pesquisas realizadas por algumas telefnicas do mundo todo, com o
intuito de resolver as limitaes existentes na telefonia mvel. [6]
Na dcada de 80, unidades mveis comearam a ser instaladas em veculos, dessa
forma a comunicao era veicular e no pessoal. Nesta mesma dcada foi
projetada e construda pela Motorola a rede ARDIS (Advanced Radio Data
Information Service), primeira grande rede de dados sem fio dos Estados Unidos,
especializada para clientes da IBM. [6]
A era da telefonia celular teve seu incio efetivo no incio dos anos 90, quando o
usurio podia portar o aparelho embora suas dimenses iniciais fossem grandes
[7].
Foram adotados vrios padres em diferentes pases para a telefonia celular e ficaram
conhecidos com a Primeira Gerao (1G). Os sistemas de 1G utilizam a transmisso de dados de
modo analgicos e a tcnica de utilizada de acesso ao meio a FDMA (Frequency Division
Captulo



24
ESCOLA POLITCNICA
DE PERNAMBUCO

Multiple Access Acesso Mltiplo por Diviso de Frequncia) [6], que possua uma baixa
qualidade e uma incompatibilidade com os diversos sistemas existentes.
Depois da 1G ocorreu o surgimento da Segunda Gerao (2G), com o objetivo de
aumentar a capacidade da primeira gerao. A 2G utilizava o TDMA (Time Division Multiple
Access Acesso mltiplo por diviso de tempo) [6] e o CDMA (Code Division Multiple Access
Acesso mltiplo por diviso de cdigo). [6]
Atualmente as redes celulares digitais possuem o servio GSM (Global Standard Mobile)
[6], que foi criado para prover servios celulares modernos. Uma inovao encontrada no
sistema GSM a utilizao do SIM (Subscriber Indentification Module) que contm algumas
identificaes do usurio assim como chave de cdigo de privacidade. O SIM conectado a um
terminal GSM, pode ser removido de um aparelho e conectado em outro; sem o SIM o terminal
fica impossibilitado de operar.
3.2 Dispositivos Mveis
Muito mais do que assistentes pessoais ou agendas eletrnicas, os dispositivos mveis passaram a
ser computadores que podem ser facilmente levados a qualquer lugar, criados para atender
profissionais e pessoas em movimento que necessitam de rapidez, facilidade e segurana no
acesso a informaes corporativas e pessoais. Alm disso, as grandes inovaes trazidas pela
tecnologia wireless fizeram com que a indstria deste setor tenha tido um crescimento explosivo
nos ltimos anos, tornando-se uma das mais eficientes e rpidas reas tecnolgicas do mundo,
permitindo que as pessoas comuniquem-se de forma barata e fcil sem ficarem presas aos seus
telefones ou computadores de mesa [19].
Quando so mencionados dispositivos mveis (celulares e PDA), feito uma referncia a
aparelhos que so encontrados facilmente no cotidiano das pessoas e que esto se tornando cada
vez mais eficazes quando se fala de comunicao e, de preferncia, on-line. Esses equipamentos
permitem que os usurios se desloquem junto com seu ambiente computacional e tenham um
acesso constante s fontes de informaes.


Figura 11. Dispositivos Mveis Fonte: [29]




25
ESCOLA POLITCNICA
DE PERNAMBUCO

Em se tratando especificamente do aparelho celular, h proximadamente uma dcada foi
um artigo de luxo, hoje em dia tornou-se um bem de consumo bastante acessvel. medida que a
demanda por funcionalidades aumenta, as empresas de telefonia celular vm acrescentando novas
tecnologias a tais aparelhos, variando seus tamanhos, fazendo modificaes desde hardware at
software, estimulando nos consumidores o desejo de possuir o mais recente modelo de um
determinado celular.
Os celulares ainda possuem como principal funo o servio de voz, porm a transmisso
de dados vem tornando cada vez mais freqente. Como exemplo pode-se citar a possibilidade de
ter acesso a informao e servios a qualquer hora acessando a Internet. Pode-se dizer que os
celulares esto tornando-se pequenos computadores, possuindo a vantagem do tamanho reduzido.
O nmero total de telefones celulares excedeu 600 milhes no ano de 2001 e a estimativa
era de haver 1 bilho em 2003 [27]. Em contraste, os PC ficaram em torno de 311 milhes no
incio do ano 2000 [27].

3.2.1 Vantagens dos Dispositivos Mveis

Do ponto de vista empresarial, os dispositivos mveis so timos geradores de informao,
podendo ser utilizado na automatizao do processo, at nas coletas de informaes estratgicas,
pois com suas reduzidas dimenses podem ser transportados e estar presentes em todas as
situaes em que um profissional pode atuar [29].
Algumas vantagens dos dispositivos mveis em relao aos micro-computadores so
listadas a seguir:

Tamanho: bastante reduzidos e muito mais leves do que os PCs, podendo ser
transportados de forma muito mais prtica;
Fcil manuseio: os dispositivos mveis possuem uma interface grfica simples de
manusear se comparado aos computadores;
Consumo de energia: por serem menores e mais econmicos gastam menos energia
que os computadores visto que o tempo de recarga menor;
Custos operacionais: como os dispositivos mveis so mais compactos e possuem
atividades especficas, estes aparelhos no possuem alguns perifricos internos, como
discos rgidos e discos flexveis, diminuindo consideravelmente os custos com a
manuteno;

Outra caracterstica que ajuda no desenvolvimento da comunicao sem fio o fato de
que as pessoas esto cada vez mais dependentes das informaes disponibilizadas na Internet, o
que antes poderia ser feito apenas via terminal remoto, agora pode ser acessado via dispositivo
mvel. A tecnologia sem fio disponibiliza ao usurio a possibilidade de obter informaes que
lhes sejam teis, a qualquer momento ou qualquer lugar.
A mobilidade outra caracterstica que deve ser levada em considerao. A capacidade de
poder continuar uma comunicao e manter o envio de dados constante mesmo quando em
movimento pode ser considerada uma das melhores vantagens de um dispositivo mvel.




26
ESCOLA POLITCNICA
DE PERNAMBUCO

3.2.2 Desafio dos Dispositivos Mveis
Toda mudana requer adaptao, com as redes sem fio no foi diferente. Pelo crescente mercado
de dispositivos mveis foi necessria uma grande adaptao das tecnologias j desenvolvidas
para os computadores remotos, para que estas tambm estejam disponveis para os dispositivos
mveis. Essa adaptao no trivial.
Um fato de grande importncia a ser observado relacionado forma como os celulares e
dispositivos portteis so utilizados. Alm de algumas limitaes como tela e bateria, esses
dispositivos no so usados da mesma forma que um computador, mesmo que consiga obter o
mesmo desempenho tecnolgico. Um aparelho celular utilizado em situaes especficas como,
por exemplo, no trnsito. Esse fato deve ser levado em considerao para no ficar limitado no
momento dos produtos serem construdos.
A tecnologia sem fio precisa trabalhar dentro de restries dos dispositivos, alguns
problemas podem ser destacados:
Recurso de memria limitado: dispositivos como celulares e PDAs (Personal
Digital Assistant Assistente Pessoais Digitais ) possuem pouca memria,
exigindo assim que o gerenciamento de memria seja fundamental;
Baixa capacidade: o processamento de um dispositivo mvel pode variar de
32Kbytes a 64Mbytes, o que faz com que este seja um dos principais desafios
enfrentados pelas operadoras de telefonia celular;
Entrada de dados: a capacidade de entrada de dados nesses dispositivos ocorre de
forma limitada, quando relacionado a um telefone celular, possuem doze teclas ,
sendo dez delas nmeros e as outras duas caracteres especiais, j nos palmtops a
entrada de dados realizada atravs de uma caneta ou de teclas alfanumricas;
Largura de banda: mesmo obstculo possudo pela computao convencional, a
segurana, j que os dados so transmitidos pelo ar atravs de ondas
eletromagnticas, onde a confiabilidade bastante questionada. As redes wireless
esto sujeitas a mais erros do que as redes com fio;
Interface Reduzida: normalmente esses dispositivos possuem uma tela de pequena
dimenso, tornando limitada a quantidade de informaes que pode ser
visualizada, sem disponibilidade de janelas;
Pela caracterstica de possuir grande mobilidade, pode acarretar perda de conexo;

Mas atualmente grandes fabricantes fazem investimentos acentuados nesta rea para fazer com
que tenhamos mais recurso tecnolgico nos dispositivos mveis, embora ainda no se faa uso de
todos esses recursos. O mercado est esperando um crescimento grande no nmero de usurios
conectados a rede sem fio.




.









27
ESCOLA POLITCNICA
DE PERNAMBUCO


4

Uma ferramente para gerenciamento
de informaes e recursos humanos
Foi desenvolvido um prottipo de software para simulao de transmisso de dados atravs de
uma comunicao entre o emulador de um dispositivo MIDP e um servidor que disponibiliza
informaes dos projetos, professores e alunos do Ncleo de Pesquisa do Departamento de
Sistemas Computacionais da Escola Politcnica da Universidade de Pernambuco.
O aplicativo est dividido em duas partes: a primeira delas, um prottipo do software do
celular, ser executado utilizando um emulador, que simule o comportamento de um dispositivo
mvel, tendo suporte a tecnologia J2ME com o perfil MIDP. Esse dispositivo deve interagir com
o servidor depois de estabelecida uma conexo HTTP, onde so passados alguns parmetros. Os
parmetros informados variam de acordo com a consulta a ser realizada, e atravs deles que o
servidor saber qual a base de dados referenciada na consulta, dentre outras informaes.
A segunda parte responsvel pelo servidor da aplicao e foi desenvolvida utilizando os
recursos disponveis na plataforma J2EE. Aps o aplicativo servidor receber a requisio vinda
do mdulo cliente, este executa os dados recebidos e encaminha de volta o resultado do
processamento. Os dados, ento, podem ser visualizados na tela do dispositivo mvel, que neste
caso estar sendo executa no emulador. A forma como ocorre a comunicao entre o cliente e o
servidor pode melhor ser observada atravs do diagrama de seqncia[5] que pode ser
visualizado na Figura 12.
Entretanto, para tornar possvel estabelecer uma conexo entre essas duas partes, o
mdulo que trata as requisies dever estar associado a um servidor de aplicao que oferea
suporte a J2EE. No caso em questo aplicado o Tomcat [1] que mantido em execuo em um
PC (Personal Computer) que funciona como um servidor. Neste so instalados servlets que sero
responsveis por tratar as requisies recebidas do cliente. O Tomcat um subprojeto do projeto
Jakarta Apache Software Foundation [16], que tem como objetivo o desenvolvimento de
aplicativos com cdigo aberto baseado na plataforma Java. Essas tecnologias foram apresentadas
no Captulo 2.
Dessa forma, necessrio que o servidor da aplicao seja iniciado como um processo
ativo para tornar possvel o recebimento das requisies vindas do cliente e assim poder
estabelecer a conexo entre o dispositivo mvel e o sistema corporativo desenvolvido na
arquitetura J2EE.
O NUPEC possui um sistema cujo nome CIAP Controle Inteligente de Acesso de
Pessoas, que tem o objetivo de gerenciar informaes de pessoas que freqentam o ncleo, bem
Captulo



28
ESCOLA POLITCNICA
DE PERNAMBUCO

como monitoramento de horrios de acesso. Baseado neste sistema e aps algumas pesquisas e
conversas com os professores do NUPEC, foram levantados alguns requisitos a serem
implementados. Esses requisitos sero listados a seguir e mais bem explicados e exemplificados
no decorrer do Captulo.
Informar as pessoas que esto no NUPEC no momento da consulta;
Informar os horrios em que os professores e alunos possivelmente estaro no
NUPEC;
Informar as pessoas que passaram pelo NUPEC em um determinado dia
Informar dados acadmicos dos alunos;
Informar dados dos professores
Informar a quantidade de horas que uma pessoa permaneceu no NUPEC durante a
semana
Informar dados sobre projetos em desenvolvimento no NUPEC



Figura 12. Diagrama de Seqncia da Comunicao entre o cliente e o Servidor




29
ESCOLA POLITCNICA
DE PERNAMBUCO

4.1 Ferramentas Utilizadas
A implementao do mdulo servidor foi feita utilizando a linguagem Java coorporativa (J2EE)
atravs da IDE Eclipse [9] onde o cdigo foi escrito, compilado e depurado. A plataforma Eclipse
foi desenvolvida por empresas que apiam o uso de uma arquitetura aberta para criao de
ambientes integrados de desenvolvimento nas iniciativas de cdigo livre. A estrutura da IDE
pode ser observada na Figura 13.
Para o desenvolvimento do mdulo cliente foi utilizada a linguagem Java para
dispositivos mveis (J2ME) com perfil MIDP 1.0. Encontra-se disponvel no site da Sun
Microsystems [9] a ferramenta utilizada que denominada Wireless Toolkit que prov a
implementao do MIDP junto com um emulador genrico de terminais para poder ser
visualizado o comportamento do Midlet. Como o Toolkit no possui uma IDE, para completar o
desenvolvimento do cdigo foi acrescentado o plugin Eclipse J2ME [26] na IDE Eclipse.
A verso utilizada do Wireless Toolkit foi a 2.1_01 e o emulador escolhido foi o
MediaControlSkin [15], como demonstrado na Figura 14.


Figura 13. IDE Eclipse







30
ESCOLA POLITCNICA
DE PERNAMBUCO


Figura 14. Emulador MediaControlSkin

4.2 Arquitetura da Aplicao
O aplicativo foi desenvolvido baseado na arquitetura cliente/servidor, onde o cliente estabelece
uma conexo atravs do protocolo HTTP e ento as requisies so enviadas para o servidor
Tomcat atravs do mtodo POST. O Servidor recebe as requisies, verifica os parmetros
recebidos para saber qual base de dados est sendo referenciada e, s ento, os dados so
processados. Depois de obtido o resultado, uma mensagem com resposta da requisio
devolvida para o mdulo cliente da aplicao e ento exibida na tela do emulador.



31
ESCOLA POLITCNICA
DE PERNAMBUCO

No escopo da aplicao, o cliente um aparelho celular com a caracterstica MIDP,
rodando o aplicativo desenvolvido na plataforma J2ME. J o servidor um PC com o Tomcat
instalado rodando a aplicao J2EE.

4.2.1 Arquitetura do Cliente da Aplicao
A implementao cliente foi totalmente desenvolvida utilizando a linguagem Java para
dispositivos mveis, tendo como ponto de partida a classe TccMIDLet, MIDLet responsvel
pela aplicao. Uma viso geral da arquitetura cliente pode ser visualizada na figura seguinte que
apresenta o diagrama de classe para este mdulo.

Figura 15. Diagrama de Classe do Mdulo Cliente

Quando o usurio deseja inicializar a aplicao, uma mensagem enviada para a KVM do
dispositivo MIDP e esta ento chama o mtodo startApp. de responsabilidade deste mtodo
carregar o aplicativo, criar a imagem que passada como parmetro do alert que ser mostrado
por um tempo pr-determinado no momento da inicializao, s ento, a tela que possui o menu
principal do aplicativo exibida. O cdigo referente ao mtodo startApp pode ser visto no
Quadro 2.










32
ESCOLA POLITCNICA
DE PERNAMBUCO









Quadro 2. Mtodo startApp

Devido a classe MIDlet ser abstrata, tem alguns mtodos que precisam ser
implementados para que ocorra uma mudana de estados. Dentre eles temos o startApp, que j
foi discutido no pargrafo anterior, como tambm o pauseApp e o destroyApp.
O mtodo pauseApp faz parte do ciclo de vida de um MIDlet e quando chamado,
sinaliza para o MIDlet suspender temporariamente alguns processos. O mtodo deve fazer parte
do cdigo mesmo que no seja utilizado no aplicativo.
J o destroyApp geralmente utilizado para liberar recursos e salvar algum dado na
persistncia pois , aps sua execuo, o ciclo de vida do MIDlet encerrado. Nesse trabalho, no
foi utilizada persistncia de dados, visto que, o resultado de uma pesquisa varia a cada nova
consulta. Esse mtodo ser chamado sempre que o usurio apertar o boto SAIR,
interrompendo o aplicativo. O Quadro 3 mostra onde o destroyApp chamado.






Quadro 3. Mtodo destroyApp

Na Figura 16 temos um exemplo do ciclo de vida de um MIDlet.


Figura 16. Ciclo de Vida de um Midlet



protected void startApp() throws MIDletStateChangeException {
midlet = this;
initialImage = Image.createImage("/tcc.png");
alert = new Alert ("Monografia", "Tcc", initialImage,
AlertType.INFO);
this.theDisplay.setCurrent(alert, menuPrincipalList);
}

if (c = = exitCommand) {
destroyApp(false);
notifyDestroyed();
}



33
ESCOLA POLITCNICA
DE PERNAMBUCO

Quando o aplicativo inicializado, uma tela com as opes do menu inicial exibida. No
momento em que o usurio escolhe um item para pesquisa, uma conexo com o servidor deve ser
estabelecida, passando os parmetros da consulta. Esses dados devem ser entregues ao servidor e
o cliente fica espera de uma resposta.
Ao receber uma resposta requisio, a classe de comunicao (classe Conexao)
encaminha a resposta para a classe responsvel por trat-la (classe Mensagem) e tambm deve
notificar ao Midlet sobre a resposta. Para isso foi criada a interface ResponseListener, que
possui o mtodo setResponse e recebe como parmetro a String de resposta. Tambm foi
criado um mtodo setListener de um objeto que implementa a interface
ResponseListener na classe Mensagem.
No caso em questo, como o Midlet deve ser notificado, ento a classe TccMIDlet
implementa a interface ResponseListener, e no corpo do mtodo setResponse faz o
tratamento apropriado da resposta enviada pelo servidor. Dessa forma a classe Mensagem
chama simplesmente o mtodo de seu listener quando recebe a resposta, notificando assim ao
Midlet que a mensagem chegou.
Usando um exemplo para o melhor entendimento do que foi descrito acima, no Quadro 4
est o cdigo referente ao pedido de conexo quando um usurio deseja saber as informaes de
um determinado professor. Os parmetros passados no construtor da classe Conexao significam:

O mtodo utilizado: no caso como foi 0 o mtodo foi o POST;
A base de dados da consulta: como foi 1 significa que a pesquisa referente a
professores;
A String de consulta, que neste caso o login do professor;








Quadro 4. Envio de dados da Consulta

No Quadro 5 est descrita a forma como foi implementado o momento em que a classe
Conexao recebe a resposta do servidor. A resposta chega em formato de stream e passada
junto com o tamanho como parmetro do mtodo receber para sofrer o tratamento adequado.








Quadro 5. Classe Conexo recebendo resposta do servidor

No Quadro 6 est a demonstrao de como ocorre o tratamento da resposta, realizado pela
classe Mensagem. A mensagem recebida lida no formato UTF e transformada para String onde
ser passada como parmetro do mtodo setResponse.
else if (c == pesquisarCommand) {
String professor = professorField.getString();
Conexao conexao;
conexao = new Conexao("0", "1", professor);
}
if (rc == HttpConnection.HTTP_OK) {
dis = new DataInputStream(conn.openInputStream());
int len = (int) conn.getLength();
formMsg.receber(dis, len);
}




34
ESCOLA POLITCNICA
DE PERNAMBUCO

















Quadro 6. Tratamento da resposta vinda do servidor


Ao final do ciclo executado o tratamento atravs do mtodo setResponse no Midlet
da aplicao, como mostra o Quadro 7. Como pode ser visto, a varivel resultadoForm do
tipo Form. Um Form um componente grfico que faz parte da interface de alto nvel de J2ME
e pode conter alguns itens. No exemplo abaixo est sendo utilizado uma StringItem, que
como um prprio nome diz um item em formato de texto. Tambm esto sendo adicionados ao
Form dois Commands.
Um Command responsvel por encapsular as informaes de uma determinada ao. No
exemplo do Quadro 7 podemos ver o voltarCommand e o sairCommand. Se o usurio
escolher a opo de voltarCommand, ser exibida a tela anterior, caso contrrio o mtodo
destroyApp ser chamado interrompendo o aplicativo.















Quadro 7. Mtodo setResponse no TccMIDlet

O procedimento descrito resulta no seguinte comportamento no emulador. (Ver Figura 17)

public void receber(DataInputStream dis, int len){
try{
if(len > 0){
String respostaServidor =
dis.readUTF();

this.listener.setResponse(respostaServidor);
}
} catch(IOException e){
e.printStackTrace();
} catch(Exception e){
e.printStackTrace();
}

public void setResponse(String resp) {
resultadoForm = new Form("Resultado da
Pesquisa");
StringItem item = null;
item = new StringItem("",resp);
resultadoForm.append(item);
resultadoForm.addCommand(voltarCommand);

resultadoForm.addCommand(sairCommand);
resultadoForm.setCommandListener(this);
theDisplay.setCurrent(resultadoForm);
}



35
ESCOLA POLITCNICA
DE PERNAMBUCO




Figura 17. Resultado da Pesquisa por Professor

Na Figura 17 pode-se ver inicialmente a tela de professores, onde foi informado o login
do professor e depois o usurio clicou no command PESQ. No momento de estabelecer a
conexo informado ao cliente que vai ocorrer uma transferncia de dados. Caso o usurio
escolha a opo YES o resultado da pesquisa informado na tela seguinte, caso contrrio no
ocorrer o envio dos dados.
Como foi visto, a classe Conexao responsvel por estabelecer conexo com o servidor
da aplicao, atravs do protocolo HTTP, sendo assim, fica sob a responsabilidade dessa classe
preencher as propriedades do cabealho necessrio ao protocolo HTTP como pode ser visto no
Quadro 8.











Quadro 8. Propriedades do cabealho HTTP
conn.setRequestProperty("User-Agent","Profile/MIDP-1.0
Configuration/CLDC-1.0");
conn.setRequestProperty("Content-Type", contentType);
conn.setRequestProperty("Content-Language", "en-US");
conn.setRequestProperty("Accept", accept);
conn.setRequestProperty("Content-Length", tamanhoBytes
+ "");



36
ESCOLA POLITCNICA
DE PERNAMBUCO



no construtor da classe Conexao onde so informados :
metodoConexao: apenas o mtodo POST foi utilizado para estabelecer a
conexo;
tipoPesquisa: informa a base de dados que deve ser utilizada;
dadoPesquisa: texto que varia conforme a consulta a ser realizada;









Quadro 9. Construtor da classe Conexao

Os valores do tipoPesquisa podem variar da seguinte forma:
0: Consulta referente a projetos;
1: Consulta referente a professores;
2: Consulta referente a alunos;
3: Consulta referente a horrios;
4: Consulta referente s pessoas que esto no NUPEC;
5: Consulta referente s pessoas que passaram no NUPEC em um determinado dia;

4.2.2 Arquitetura Servidor da Aplicao
O aplicativo que executado no mdulo servidor foi desenvolvido utilizando a linguagem
Java coorporativa, e possui o importante papel de capturar as solicitaes vindas do cliente para
fazer o processamento necessrio.
Visando diminuir a complexidade na implementao, a arquitetura foi criada de forma que
apenas a classe ConsultaAction receba as requisies.
O sistema servidor foi desenvolvido seguindo os padres Facade [10], Singleton [10] e
Bridge [10]. A estruturao do sistema em subsistemas essencial para a reduo de
complexidade, facilitando a manuteno.
O padro Facade prope uma interface unificada para um conjunto de interfaces de um
subsistema, definindo uma nica interface de alto nvel, que torna o subsistema mais fcil de ser
utilizado. Sendo assim as solicitaes ao sistema servidor sero feitas a classe Fachada e no a
cada objeto particular. O objeto Fachada se encarrega de encaminhar a solicitao ao objeto
correspondente.
O objetivo da utilizao do padro Singleton garantir que a classe Fachada possua
apenas uma instncia, e possibilitar o acesso global a essa instncia. A forma como foi utilizado
esses dois padres podem ser visto no Quadro 10.
O padro Bridge tem como inteno separar a camada de dados da camada de negcios
utilizando interfaces, de modo que elas possam variar fcil e independentemente.
A Fachada contm instncias das interfaces IRepAlunos, IRepProfessores,
IRepHorasSemanais e IRepProjetos.
public Conexao(String metodoConexao, String
tipoPesquisa, String dadoPesquisa) {
this.metodoConexao = metodoConexao;
this.tipoPesquisa = tipoPesquisa;
this.dadoPesquisa = dadoPesquisa;
}



37
ESCOLA POLITCNICA
DE PERNAMBUCO













Quadro 10. Mtodo getInstance da classe Fachada


A Figura 18 mostra uma viso geral do comportamento do mdulo servidor.


Figura 18. Diagrama de Classes do mdulo Servidor

Seguindo o exemplo utilizado no mdulo cliente, no momento em que o usurio informa o
login do professor e aperta o boto PESQ, uma conexo estabelecida e o cliente envia uma
requisio ao servidor.
A solicitao chega ao sistema coorporativo atravs da classe ConsultaAction, e
este captura o parmetro (tipoPesquisa) que informa a base de dados que ser utilizado,
como pode ser visto no Quadro 11.


public static Fachada getInstance(){
if(Fachada.fachada == null){
fachada = new Fachada();
}
return fachada;
}



38
ESCOLA POLITCNICA
DE PERNAMBUCO




Quadro 11. Obtendo o tipo da pesquisa

No exemplo que est sendo ilustrado o tipoPesquisa recebe o valor igual a 1, o
que significa que a consulta referente a professores e que a pesquisa deve ser realizada na base
de dados dos professores.



















Quadro 12. Exemplo da consulta dos Professores
O acesso aos dados dos professores feito atravs da Fachada, chamando o mtodo
selectProf passando como parmetro o idProf que chegou atravs da solicitao do
cliente, como pode ser visto na linha 3 no Quadro 12.
A classe RepositorioProfessores responsvel pela manipulao do
armazenamento de dados e isola os dados referente a professores do resto do aplicativo. Esta
classe est simulando uma base de dados com informaes dos professores, utilizando
armazenamento em memria, de forma que se for necessria uma troca no meio de
armazenamento (arquivos, banco de dados, etc.), apenas esta classe, referente a professores,
dever ser trocada ou modificada. O mesmo ocorrendo para os demais repositrios de dados do
sistema.
Depois de processar os dados, o servidor escreve a mensagem utilizando o formato
UTF-8 atravs do mtodo writeUTF na linha 7 do Quadro 12, visto que, a leitura desse array
de byte realizado no lado cliente com o mtodo readUTF. Finalizando o ciclo, a mensagem
enviada de volta para mdulo cliente e assim apresentada na tela do emulador. O cdigo fonte
responsvel por essa etapa pode ser visto no Quadro 13.






String tipoPesquisa = request.getHeader("tipoPesquisa");
1. else if (tipoPesquisa.equals("1") ) {
2. String idProf = request.getParameter("id");
3. Professores prof = fachada.selectProf(idProf);
4. ByteArrayOutputStream baos = new
5. ByteArrayOutputStream();
6. DataOutputStream dos = new DataOutputStream(baos);
7. dos.writeUTF("Nome do Professor: "
8.
9. + prof.getNomeProf() + "\n"
10. + "Responsvel pelo Projeto: "
11. + prof.getProjetoOrienta() + "\n"
12. + "Ttulo: "
13. + prof.getTitulo() + "\n"
14. + "Dias no Ncleo: "
15. + prof.getDias() + "\n"
16. + "Horrio no Ncleo: "
17. + prof.getHorarios());
18. data = baos.toByteArray();



39
ESCOLA POLITCNICA
DE PERNAMBUCO









Quadro 13. Dados encaminhados para o cliente
4.3 Limitaes do Contexto
O NUPEC possui um relgio de ponto MADIS RODBEL [20] modelo 3707 TCP / IP, onde
discentes e docentes devem passar um carto de identificao tanto no momento de entrada
quanto no momento de sada do ncleo. O relgio ento, deveria comunicar-se com um sistema
existente no NUPEC e armazenar essas informaes em um banco de dados. A partir desse ponto,
o prottipo de software referente a esta monografia, utilizaria as devidas informaes enviadas
pelo relgio.
Entretanto, o protocolo utilizado para realizar a transferncia de dados entre o sistema
existente e o relgio de ponto no funcionou corretamente. O relgio no consegue entender o
formato da mensagem que chega at ele, o que indica que a especificao de formato da
mensagem, enviada pela empresa do relgio, possui algum erro.
Com essa falha de comunicao o banco de dados impedido de ser alimentado. Dessa
forma, o sistema referente a esse trabalho no teria os dados disponveis para realizar as consultas
necessrias de acordo com a preferncia do usurio.
De acordo com o que foi descrito acima, o aplicativo em questo foi desenvolvido usando
uma simulao dos dados para consulta, utilizando armazenamento em memria. O fato que,
independente do mecanismo de persistncia que foi utilizado, foram construdas interfaces com
as assinaturas dos mtodos que devem ser implementados em cada forma de persistncia. Com
isto, se o mecanismo de persistncia for modificado, ou seja, o relgio consiga alimentar o banco
de dados, ento o mtodo de persistncia mude de memria para banco de dados, basta criar um
novo repositrio que acesse o banco de dados e implemente a mesma interface j utilizada. Ou
seja, no ser necessrio modificar qualquer outra classe que no esteja na camada de dados.
Um outro problema encontrado no decorrer da implementao, foi falta de
familiaridade com o Tomcat, sua instalao e integrao com o Struts. Foram encontrados vrios
erros decorrentes a falta de libs e arquivos de configurao necessrios para o correto
funcionamento do Struts junto com o servidor de aplicao.
4.4 Resultados
Foi desenvolvido um prottipo de software, onde um aplicativo cliente comunica-se com um
sistema servidor atravs de uma conexo HTTP e ento transmite os dados para uma determinada
consulta. Os dados so processados pela aplicao servidora e depois uma mensagem enviada
para o cliente como resposta requisio.
A aplicao foi testada usando um PC (Personal Computer) com um processador de
1.4GHz e 256 de RAM com o servidor Tomcat hospedando a aplicao do mdulo servidor. J o
response.setStatus(HttpServletResponse.SC_OK);
response.setContentLength(data.length);
response.setContentType("application/octet-stream");
OutputStream os = response.getOutputStream();
os.write(data);
os.close();



40
ESCOLA POLITCNICA
DE PERNAMBUCO

aplicativo cliente foi executado utilizando o emulador Wireless Toolkit para simular o dispositivo
mvel.
Ao executar uma aplicao J2ME so gerados dois novos arquivos. Um arquivo no
formato jar (Java Application Resources) e outro no formato jad (Joint Application
Development) . O arquivo jar encapsula todas as classes de um aplicativo Java. Em especial para
J2ME esse arquivo encapsula toda a aplicao, incluindo o Midlet, as outras classes e figuras se
existirem. O arquivo jad contm todas as informaes da aplicao, tais como nome do Midlet,
tamanho do arquivo jar, a verso do aplicativo, o caminho do arquivo jar, dentre outras. O
arquivo jar do aplicativo em questo tem o tamanho de 100K, como pode ser visto no Quadro 14.
O aplicativo gerado pelo mdulo cliente s pode ser instalado em dispositivos mveis que
possuam as seguintes caractersticas:

suporte a MIDP 1.0;
transferncia de dados ;
memria que suporte um aplicativo de 100k.












Quadro 14. Arquivo Tcc.jad
A unio dos dois mdulos, resultou no diagrama de classes que pode ser observado na
na Figura 19.


Figura 19. Diagrama de Classes do Sistema
MIDlet-1: Tcc, Tcc.png, TccMIDlet
MIDlet-Jar-Size: 100
MIDlet-Jar-URL: Tcc.jar
MIDlet-Name: Tcc
MIDlet-Vendor: Unknown
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0




41
ESCOLA POLITCNICA
DE PERNAMBUCO





O diagrama de casos de usos do sistema em questo pode ser observado na Figura 20.



Figura 20. Diagrama de casos de usos


Os arquivos do sistema em questo esto disponibiliados na web no endereo:
http://www.cin.ufpe.br/~dpm/Arquivos/mono.zip .






















42
ESCOLA POLITCNICA
DE PERNAMBUCO









5

Concluses e Trabalhos Futuros
5.1 Concluses
No presente trabalho foi constatada a evoluo da comunicao mvel bem como o crescente
aumento na utilizao de dispositivos mveis, sendo destacados os telefones celulares. Foram
realizados estudos detalhados sobre as tecnologias J2ME e J2EE, seus conceitos e caractersticas.
Tambm foram utilizados os recursos necessrios para estabelecer a comunicao entre os
aplicativos que rodavam em suas respectivas plataformas.
O prottipo desenvolvido nesse trabalho comprovou, atravs de testes realizados, ter
cumprido seus objetivos, ou seja, permite o usurio escolher qual consulta deseja realizar e
informar os dados de entrada. Esses dados so enviados corretamente para a aplicao servidora
que os recebe, processa de acordo com a base de dados referente consulta realizada e manda de
volta a resposta para o aplicativo cliente. O mdulo cliente aceita a mensagem com o resultado da
consulta e mostra na tela do emulador, encerrando o ciclo da pesquisa.
medida que cresce o mercado de telefonia celular, aumenta tambm a diversidade de
aplicativos que so desenvolvidos para esses aparelhos. Empresas de desenvolvimento criam cada
vez mais softwares que trocam dados na rede e se comunicam com servidores. Contudo, apesar
de todo avano tecnolgico, a transferncia de grandes quantidades de dados via rede sempre
um fator problemtico devido s limitaes de envio de dados comuns tecnologia de telefonia
mvel. Por exemplo, ainda no existe um aplicativo que faa processamento grfico em um
servidor e envie imagens para o celular. Portanto, uma aplicao que faa consultas, como o
aplicativo do trabalho em questo, essencial que estas sejam simples e diretas, tanto a
mensagem de solicitao quanto a resposta.


Captulo



43
ESCOLA POLITCNICA
DE PERNAMBUCO

5.2 Trabalhos Futuros
Como trabalho futuro, poderia ser desenvolvido um sistema interno de envio de mensagens para
celular, onde as mensagens poderiam ser enviadas em broadcast com um aviso ou algo referente
a um determinado grupo de pesquisas. Um administrador poderia cadastrar no sistema
informaes como datas de reunies ou seminrios, e estas seriam enviadas para os usurios em
uma data estipulada.
Relacionado ao trabalho em questo, seria interessante a adio de novas funcionalidades
que agregassem mais valores a aplicao. Atualmente o sistema no faz nenhuma distino entre
professores e alunos, j que apenas consultas podem ser realizadas, e estas no exigem tal
controle. Contudo, podem ser acrescentados novos requisitos que levem a necessidade de
controlar algumas reas de acesso. Para tanto, os professores deveriam receber tratamento
diferenciado em relao aos alunos utilizando alguma forma de validao, podendo os docentes
ter acesso s reas restritas.
Dentre outros, podemos citar tais exemplos como possibilidade de novos requisitos que
poderiam enriquecer o aplicativo:
bloquear/desbloquear a entrada de alunos ao NUPEC;
modificar informaes relativas tanto a projetos quanto a discentes e docentes;
clculo mensal de horas trabalhadas por cada aluno, podendo ser dividido em
projetos caso algum aluno esteja alocado em mais de um projeto.
O sistema pode ser adaptado de forma que possa funcionar como um gerenciador de
recursos, dessa maneira pessoas podem ser cadastradas e descadastradas e tambm dados podem
ser modificados.
Uma outra possibilidade de melhoria tornar a interface grfica mais rica de detalhes.
Como j foi informado em Captulos anteriores, o mdulo cliente foi desenvolvido utilizando
apenas a API nativa de J2ME, que composta por alguns componentes pr-definidos, como por
exemplo, Forms, Alerts, DateFields, TextBoxs, dentre outros. Essa interface de alto nvel fcil
de ser implementada, porm, possui um design simples e no muito atraente.
Seria interessante migrar o cdigo da interface grfica para utilizar componentes
otimizados pertencentes a API de baixo nvel. Esses componentes herdam da classe Canvas e so
responsveis por pintar a tela pixel a pixel. Tornando assim, as telas do aplicativo cliente,
personalizadas, possuindo um design muito mais bonito, com detalhes atrativos e possibilidade de
animaes grficas.





















44
ESCOLA POLITCNICA
DE PERNAMBUCO

Bibliografia
[1] APACHE TOMCAT. Disponvel em <http://jakarta.apache.org/tomcat/>. Acesso em: mar -
2005.
[2] ARMSTRONG, Erik et al. The J2EE 1.4. Disponvel em <http://www.java.sun.com>.
Acesso em: fev - 2005
[3] CAVANESS, Chuck. Programming Jakarta Struts, ORelly & Associates, Inc, 2002.
[4] CESTA, A. A linguagem de programao Java. Instituto de Computao, So Paulo, 1996.
Disponvel em: <http://www.dcc.unicamp.br/~aacesta >. Acesso em: nov 2004
[5] CHEESEMAN John, DANIELS, John . UML Components: A Simple Process for Specifying
Component-Based Software. Addison-Wesley, 2001.
[6] DIAS, Clessis; FONTES, Wescley. Desenvolvimento de Aplicaes para Dispositivos Mveis
utilizando a Plataforma J2ME. 2003. Trabalho de Concluso de Curso (Bacharelado em
Cincias da Computao) Centro de Cincias Exatas e Naturais, Universidade Federal
do Par, Belm.
[7] DIAS, K. L; Sadok, D. F.H. Internet Mvel: Tecnologias, Aplicaes e QoS. XIX Simpsio
Brasileiro de Redes de Computadores, Florianpolis, 2001.
[8] DORNAN, Andy. Wireless communication: O guia essencial de comunicao sem fio. Rio de
Janeiro: Campus, 2001.
[9] FERRAMENTA ECLIPE. Disponvel em: <http://www.eclipse.org/>. Acesso em: dez
2004.
[10] GAMMA,E. HELM,R. JOHNSON,R VLISSIDES, J Design Patterns: Elements of
Reusable Object-Oriented Software (GOF) Addison Wesley, 1995.
[11] GOMES, A. J2ME Viso Geral. Disponvel em: <http://www.mundooo.com.br/> .
Acesso em: jan 2005.
[12] GUPTA, V.; DASS, A.; CHAUHAN, Y. Cracking the Code Wireless Programming
with J2ME. Hungry Minds, Inc, 2002.
[13] HORSTMANN, Cay S., CORNELL, Gary. Core Java: fundamentos. v.1, So Paulo:
Pearson MakronBooks, 2003. cap.1, p. 1-14.
[14] HUSTED, Ted et al. Struts em ao, So Paulo: Editora Cincia Moderna, 2004.
[15] J2ME Wireless Toolkit 2.2. Disponvel em:
<http://java.sun.com/products/j2mewtoolkit/download-2_2.html>. Acesso em fev - 2005.
[16] JAKARTA APACHE SOFTWARE FOUNDATION. Disponvel em:
<http://jakarta.apache.org>. Acesso em mar 2005.
[17] JAVA 2 Platform Micro Edition (J2ME ) Technology for Creating Mobile Devices.
White Paper. Sun, 2000. Disponvel em
<http://java.sun.com/developer/technicalArticles/ConsumerProducts/intro/#j2me>.
Acesso em jan 2005.
[18] KEOGH, James. J2ME: The Complete Reference. McGraw-Hill/Osborne, 2003.




45
ESCOLA POLITCNICA
DE PERNAMBUCO

[19] LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas de informao. Rio de Janeiro:
LTC, 1999.
[20] MADIS RODBEL. Disponvel em: <http://www.rodbel.com.br> . Acesso em fev 2005.
[21] MAGAN, M.; VARGAS, P.; AZZOLIN, D. Tcnicas para desenvolvimento de
aplicaes orientadas a objetos utilizando a linguagem Java. III Simpsio Brasileiro de
Linguagens de Programao, Porto Alegre, 1999.
[22] MAHMOUD, Q. H. Wireless Software Design Techniques What every wireless software
developer should know. 2002. Disponvel em
<http://wireless.java.sun.com/midp/articles/uidesign/ > . Acesso em: nov 2004.
[23] MUCHOW, John W. Core J2ME - Technology & MIDP. Pearson MakronBooks, 2004.
[24] PASIN, Mrcia. Rplicas para alta disponibilidade em arquiteturas orientadas a
componentes com suporte de comunicao de grupo. 2003. 127 p. Tese de Doutorado
Instituto de Informtica, Universidade do Rio Grande do Sul, Rio Grande do Sul, 2003.
[25] BANSAL, V.; DALTON, A. Performance analysis of web services on wireless PDAs. Duke
University Computer Science, Duke, Disponvel em:
<http://www.cs.duke.edu/~vkb/advnw/project/index.html>. Acesso em : abr 2005.
[26] J2ME Wireless Toolkit 2.2. Disponvel em:
<http://java.sun.com/products/j2mewtoolkit/download-2_2.html>. Acesso em fev 2005
[27] RIGGS, Roger, et al. Programming wireless devices with the Java 2 platform, micro
edition. Boston: Addison Wesley, 2001.
[28] ROCHA, H. Desenvolvimento de Applets & Aplicaes em Java. Belm, 1998.
[29] SCHAEFER, Carina. Prottipo de aplicativo para transmisso de dados a partir de
dispositivos mveis aplicados a uma empresa de transporte. 2004. 53f. Trabalho de
Concluso de Curso (Bacharelado em Cincias da Computao) Centro de Cincias
Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
[30] SERVLET ESSENTIALS. Disponvel em: <http://www.novocode.com/doc/servlet-
essentials/>. Acesso em maio 2005
[31] SILVA, W. Tecnologias Java para Sistemas Embarcados. Trabalho de Concluso de
Curso (Bacharelado em Cincias da Computao) Centro de Informtica, Universidade
Federal de Pernambuco, Recife, 2001.
[32] PLUGIN ECLIPSEME. Disponvel em: <http://eclipseme.sourceforge.net>. Acesso em
nov 2004.
[33] TITTLEL. So Paulo: Ed. XML. Bookman, 2003.
[34] WHITE, James P.; HEMPHIL, David A. Java 2 Micro Edition, UK: Ebook Edition, 2003.
[35] SUN. Disponvel em : <http://www.sun.com >. Acesso em: nov 2004
[36] Making HTTP Connections with MIDP. Disponvel em
:http://developers.sun.com/techtopics/mobility/midp/ttips/httpcon/. Acesso em fev 2005.















46
ESCOLA POLITCNICA
DE PERNAMBUCO




Testes
Apresentaremos aqui as principais telas do sistema, com suas respectivas entradas de dados, para
consultar informaes sobre projetos, alunos e professores do NUPEC (Ncleo de Pesquisa em
Engenharia da Computao) da Escola Politcnica de Pernambuco.

Horas Semanais no Ncleo

Essa pesquisa diz respeito a quantidade de horas passadas no NUPEC, por uma determinada
pessoa, durante a semana correspondente.
Ao inicializar o aplicativo, o usurio pode escolher a primeira opo que indica: Horas
semanais no ncleo e apertar no boto SELEC. Em seguida, o aplicativo passa para a tela
seguinte onde pedido o login da pessoa a qual deve ser feita a consulta. Se o usurio escolher a
possibilidade de voltar, o sistema retorna a tela anterior, caso contrrio mostrada a tela com o
resultado da busca. O ciclo descrito pode ser observado na Figura 21.


Figura 21. Horas Semanais no Ncleo

Apndice A



47
ESCOLA POLITCNICA
DE PERNAMBUCO


Busca On-Line
A consulta de busca On-line deve ser realizada caso ocorra a necessidade de saber quem est
presente no NUPEC em um determinado momento.
Caso seja desejada realizar essa busca, ao inicializar o aplicativo, no Menu Principal deve
ser escolhida da opo: On-Line. O aplicativo ser direcionado para a tela de Resultado da
Pesquisa onde estar sendo informado o login dos professores e alunos que esto no ncleo.
A lgica de implementao dessa consulta foi feita simulando a comunicao do relgio
de ponto com a base de dados. Levando em considerao que sempre que uma pessoa for entrar
ou sair do Ncleo, o carto de identificao deve ser passado no relgio, ento toda vez que um
determinado login aparecer em uma quantidade mpar de vezes, significa que a pessoa est
presente no NUPEC. As telas referentes a essa consulta, pode ser vista na Figura 22.


Figura 22. Busca On-Line

Projetos
A consulta referente a Projetos informa os dados de um determinado projeto que esta sendo
desenvolvido no Ncleo. Tais dados so o nome do projeto, o nome do professor responsvel e a
principal tcnica utilizada. A navegao das telas pode ser vista na Figura 23. Na tela de
Resultados, caso a opo SAIR for escolhida acarretar na sada do aplicativo.


Figura 23. Projetos





48
ESCOLA POLITCNICA
DE PERNAMBUCO

Informaes
Caso a opo Informaes, disponvel no Menu principal, for escolhida, o aplicativo ser
direcionado para uma nova tela com trs outras opes. Como pode ser visto na Figura 24.


Figura 24. Informaes

Se a opo escolhida for Professores, uma busca ser realizada na base de dados de
professores. O usurio informa o login do professor e em seguida o aplicativo mostra uma tela
com as informaes do mesmo. O comportamento dessa busca pode ser visto na Figura 25.


Figura 25. Consulta de Professores

Caso a opo escolhida for aluno, o usurio ir informar o login do aluno e o sistema
mostrar na tela as informaes referente ao aluno, como mostra a Figura 26.


Figura 26. Consulta Alunos



49
ESCOLA POLITCNICA
DE PERNAMBUCO

Se a escolha for Info. do dia, ser mostrada na tela um calendrio onde o usurio poder
escolher uma data para consulta. Depois de escolhida a data, deve ser clicado no boto SELEC
e ento os dados da consulta sero mostrados na tela do celular. O ciclo descrito, pode ser visto
da Figura 27.


Figura 27. Consulta Info.Dia