Bruna Romeiro

ESCOLA POLITCNICA 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
Trabalho de Concluso de Curso Engenharia da Computao

Este Projeto apresentado como requisito parcial para obteno do diploma de Bacharel em Engenharia da Computao pela Escola Politcnica de Pernambuco Universidade de Pernambuco.
Bruna Georgina Bunzen de Albuquerque Romeiro Orientador: Srgio Castelo Branco Soares Recife, Maio de 2005
Bruna Georgina Bunzen de Albuquerque Romeiro
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
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
Sumrio
ndice de Figuras ndice de Quadros ndice de Quadros Tabela de Smbolos e Siglas 1 2 Introduo Tecnologias
2.1 Java 2.2 Plataforma Java 2 Micro Edition (J2ME) 2.2.1 Perfis 2.2.2 Configuraes 2.2.3 Mquina Virtual J2ME 2.3 Java 2 Enterprise Edition (J2EE) 2.4 Struts 2.5 Wireless 2.6 Arquitetura Cliente/Servidor 2.7 HTTP (Hypertext Transfer Protocol) 2.7.1 Generic Connection Framework (GCF)
v vi vi vii 9 11
11 13 14 15 15 16 17 18 18 19 21
Comunicao Mvel
3.1 Histrico da Comunicao Mvel 3.2 Dispositivos Mveis 3.2.1 Vantagens dos Dispositivos Mveis 3.2.2 Desafio dos Dispositivos Mveis
23
23 24 25 26
Uma ferramente para gerenciamento de informaes e recursos humanos

4.1 Ferramentas Utilizadas 4.2 Arquitetura da Aplicao 4.2.1 Arquitetura do Cliente da Aplicao 4.2.2 Arquitetura Servidor da Aplicao 4.3 Limitaes do Contexto 4.4 Resultados
27
29 30 31 36 39 39
Concluses e Trabalhos Futuros

5.1 5.2 Concluses Trabalhos Futuros
42
42 43
iv
ndice de Figuras
Figura 1. Figura 2. Figura 3. Figura 4. Figura 5. Figura 6. Figura 7. Figura 8. Figura 9. Figura 10. Figura 11. Figura 12. Figura 13. Figura 14. Figura 15. Figura 16. Figura 17. Figura 18. Figura 19. Plataforma Java 2 Fonte [29] ........................................................................................................ 12 Diviso da Plataforma Java Fonte [23].......................................................................................... 13 Arquitetura J2ME.............................................................................................................................. 14 Camadas da Arquitetura J2EE ......................................................................................................... 16 ConsultaAction extendendo a classe Action ..................................................................................... 17 ActionSrvlet no web.xml .................................................................................................................... 18 Protocolo http ..................................................................................................................................... 20 Fromato de Requisio de Mensagem .............................................................................................. 21 Hierarquia das interfaces no GCF e Classes relacionadas Fonte [35] ........................................ 21 Relao entre HttpConnection e ContentConnection ..................................................................... 22 Dispositivos Mveis Fonte: [29]...................................................................................................... 24 Diagrama de Seqncia da Comunicao entre o cliente e o Servidor .......................................... 28 IDE Eclipse.......................................................................................................................................... 29 Emulador MediaControlSkin............................................................................................................ 30 Diagrama de Classe do Mdulo Cliente ........................................................................................... 31 Ciclo de Vida de um Midlet ............................................................................................................... 32 Resultado da Pesquisa por Professor................................................................................................ 35 Diagrama de Classes do mdulo Servidor........................................................................................ 37 Diagrama de Classes do Sistema ....................................................................................................... 40
vi
ndice de Quadros
Quadro 1. Quadro 2. Quadro 3. Quadro 4. Quadro 5. Quadro 6. Quadro 7. Quadro 8. Quadro 9. Quadro 10. Quadro 11. Quadro 12. Quadro 13. Quadro 14. Obtendo a conexo com o HttpConnection Mtodo startApp Mtodo destroyApp Envio de dados da consulta Classe conexo recebendo resposta do servidor Tratamento da resposta vinda do servidor Mtodo setResponse no TccMIDlet Propriedades do cabealho HTTP Construtor da classe Conexo Mtodo getInstance da classe Fachada Obtendo o tipo da pesquisa Exemplo da consulta de professores Dados encaminhados para o cliente Arquivo Tcc.jad 22 32 32 33 33 34 34 35 36 36 37 38 38 40
vii
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
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.
Captulo 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.
10
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
Captulo 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 APPLETS1 [28], SERVLETS2 [30] ou MIDLETS3 [18] .
Programas escritos em Java que podem ser inseridos em documentos de hipertextos HTML, carregados na web e executados em um brouwser.
2 3
Aplicaes executadas em um servidor web Aplicaes executadas em dispositivos mveis
12
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
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
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
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
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
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
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
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
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
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
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.
String url = "http://localhost:8080/tcc/consulta.do"; HttpConnection conn = null; conn = (HttpConnection) Connector.open(this.url); conn.setRequestMethod(HttpConnection.POST); Quadro 1. Obtendo a conexo com o HttpConnection
23
Captulo 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
24
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
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
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
Captulo 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
28
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
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
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
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 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); } {
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.
if (c = = exitCommand) { destroyApp(false); notifyDestroyed(); } 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
33
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;
else if (c == pesquisarCommand) { String professor = professorField.getString(); Conexao conexao; conexao = new Conexao("0", "1", 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.
if (rc == HttpConnection.HTTP_OK) { dis = new DataInputStream(conn.openInputStream()); int len = (int) conn.getLength(); formMsg.receber(dis, len); } 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.
34
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(); } 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.
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); } Quadro 7. Mtodo setResponse no TccMIDlet
O procedimento descrito resulta no seguinte comportamento no emulador. (Ver Figura 17)
35
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.
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 + ""); Quadro 8. Propriedades do cabealho HTTP
36
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;
public Conexao(String metodoConexao, String tipoPesquisa, String dadoPesquisa) { this.metodoConexao = metodoConexao; this.tipoPesquisa = tipoPesquisa; this.dadoPesquisa = dadoPesquisa; } 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.
37
public static Fachada getInstance(){ if(Fachada.fachada == null){ fachada = new Fachada(); } return fachada; } 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.
38
String tipoPesquisa = request.getHeader("tipoPesquisa"); 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.
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. 10. 11. 12.
18.
+ + + + 13. + 14. + 15. + 16. + 17. + data =
prof.getNomeProf() + "\n" "Responsvel pelo Projeto: " prof.getProjetoOrienta() + "\n" "Ttulo: " prof.getTitulo() + "\n" "Dias no Ncleo: " prof.getDias() + "\n" "Horrio no Ncleo: " prof.getHorarios()); baos.toByteArray();
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.
39
response.setStatus(HttpServletResponse.SC_OK); response.setContentLength(data.length); response.setContentType("application/octet-stream"); OutputStream os = response.getOutputStream(); os.write(data); os.close(); 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
40
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.
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 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
41
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
Captulo 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.
43
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
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
[19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
[30] [31] [32] [33] [34] [35] [36]
LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas de informao. Rio de Janeiro: LTC, 1999. MADIS RODBEL. Disponvel em: <http://www.rodbel.com.br> . Acesso em fev 2005. 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. MAHMOUD, Q. H. Wireless Software Design Techniques What every wireless software 2002. Disponvel em developer should know. <http://wireless.java.sun.com/midp/articles/uidesign/ > . Acesso em: nov 2004. MUCHOW, John W. Core J2ME - Technology & MIDP. Pearson MakronBooks, 2004. 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. 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. J2ME Wireless Toolkit 2.2. Disponvel em: <http://java.sun.com/products/j2mewtoolkit/download-2_2.html>. Acesso em fev 2005 RIGGS, Roger, et al. Programming wireless devices with the Java 2 platform, micro edition. Boston: Addison Wesley, 2001. ROCHA, H. Desenvolvimento de Applets & Aplicaes em Java. Belm, 1998. 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. SERVLET ESSENTIALS. Disponvel em: <http://www.novocode.com/doc/servletessentials/>. Acesso em maio 2005 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. PLUGIN ECLIPSEME. Disponvel em: <http://eclipseme.sourceforge.net>. Acesso em nov 2004. TITTLEL. So Paulo: Ed. XML. Bookman, 2003. WHITE, James P.; HEMPHIL, David A. Java 2 Micro Edition, UK: Ebook Edition, 2003. SUN. Disponvel em : <http://www.sun.com >. Acesso em: nov 2004 Making HTTP Connections with MIDP. Disponvel em :http://developers.sun.com/techtopics/mobility/midp/ttips/httpcon/. Acesso em fev 2005.
46
Apndice A
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
47
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
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
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

Bruna Romeiro

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bruna Romeiro

Enviado por

Direitos autorais:

Formatos disponíveis

ESCOLA POLITCNICA DE PERNAMBUCO

DESENVOLVIMENTO DE APLICATIVOS PARA DISPOSITIVOS MVEIS NA PLATAFORMA J2ME

Trabalho de Concluso de Curso Engenharia da Computao

ESCOLA POLITCNICA 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

DESENVOLVIMENTO DE APLICATIVOS PARA DISPOSITIVOS MVEIS NA PLATAFORMA J2ME

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

Keywords: Mobile devices, J2ME, J2EE, information management

ESCOLA POLITCNICA DE PERNAMBUCO

Uma ferramente para gerenciamento de informaes e recursos humanos

Concluses e Trabalhos Futuros

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

Tabela de Smbolos e Siglas

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

ESCOLA POLITCNICA DE PERNAMBUCO

Aplicaes executadas em um servidor web Aplicaes executadas em dispositivos mveis

ESCOLA POLITCNICA DE PERNAMBUCO

Figura 1. Plataforma Java 2 Fonte [29]

ESCOLA POLITCNICA DE PERNAMBUCO

2.2 Plataforma Java 2 Micro Edition (J2ME)

Figura 2. Diviso da Plataforma Java Fonte [23]

ESCOLA POLITCNICA DE PERNAMBUCO

Figura 3. Arquitetura J2ME

ESCOLA POLITCNICA DE PERNAMBUCO

Mquina Virtual J2ME

ESCOLA POLITCNICA DE PERNAMBUCO

2.3 Java 2 Enterprise Edition (J2EE)

ESCOLA POLITCNICA DE PERNAMBUCO

ConsultaAction extendendo a classe Action

ESCOLA POLITCNICA DE PERNAMBUCO

2.6 Arquitetura Cliente/Servidor

ESCOLA POLITCNICA DE PERNAMBUCO

2.7 HTTP (Hypertext Transfer Protocol)

ESCOLA POLITCNICA DE PERNAMBUCO

Figura 7. Protocolo HTTP

ESCOLA POLITCNICA DE PERNAMBUCO

Figura 8. Formato de Requisio de Mensagem

Generic Connection Framework (GCF)

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

ESCOLA POLITCNICA DE PERNAMBUCO

Figura 10. Relao entre HttpConnection e ContentConnection

ESCOLA POLITCNICA DE PERNAMBUCO

Captulo 3 Comunicao Mvel

ESCOLA POLITCNICA DE PERNAMBUCO

3.2 Dispositivos Mveis

Figura 11. Dispositivos Mveis Fonte: [29]

ESCOLA POLITCNICA DE PERNAMBUCO

Vantagens dos Dispositivos Mveis

ESCOLA POLITCNICA DE PERNAMBUCO

Desafio dos Dispositivos Mveis

ESCOLA POLITCNICA DE PERNAMBUCO

Captulo 4 Uma ferramente para gerenciamento de informaes e recursos humanos

ESCOLA POLITCNICA DE PERNAMBUCO

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

ESCOLA POLITCNICA DE PERNAMBUCO