INTEGRANDO A TECNOLOGIA J2ME NO ÂMBITO ACADÊMICO Ramon R. Rabello, Pedro J. Treccani, Thienne M Johnson Universidade da Amazônia, Av Alcindo Cacela, 287, Belém, PA CEP 66092-010 ramon.rabello@gmail.com, pedrotreccanni@gmail.com, thienne@ieee.org ABSTRACT This article intends to show, through a software solution for mobile devices, the need of integration of the Java technology for devices in the academic context. Such solution has as objective that facilitates and automates the teacher's daily task of updating their students' frequencies, and that updating will be accomplished remotely of a mobile device directly for the academic database. Key-words: J2ME; Mobility; Java; Mobile devices. RESUMO Este artigo pretende mostrar, por meio de uma solução de software para dispositivos móveis, uma alternativa de integração da tecnologia Java para micros dispositivos no âmbito acadêmico. Tal solução tem como objetivo facilitar e automatizar a tarefa cotidiana do docente de atualizar as freqüências de seus alunos, sendo que essa atualização será realizada remotamente de um dispositivo móvel diretamente para a base de dados acadêmica. Palavras-chaves: J2ME; Mobilidade; Java; Dispositivos Móveis. 1. INTRODUÇÃO A qualquer hora, em qualquer lugar, as pessoas sentem a necessidade de estarem informadas, quer seja por meio de jornais televisivos quer seja por uma simples consulta em uma página de notícias na Rede Mundial de Computadores. Atualmente, já é cotidiano poder checar sua caixa de e-mails pelo celular no momento que estiver andando pelas ruas ou atualizar sua agenda de compromissos direta para o servidor de sua empresa. A mobilidade aliada à tecnologia sem fio trouxe para o mercado um novo paradigma de comunicação: a comunicação móvel sem fio. Este artigo tem como objetivo discutir a necessidade de integração da tecnologia J2ME (linguaguem Java para computação móvel) no âmbito acadêmico A tecnologia J2ME, além de fornecer todos os recursos (conectividade, persistência de dados) para o desenvolvimento do sistema em questão, a portabilidade foi o motivo primordial na adoção desta tecnologia. Sendo assim, a aplicação irá funcionar independente de plataforma, bastando somente que o dispositivo (que pode ser um PDA ou um celular) suporte a configuração e o perfil desejado.
Este artigo está dividido em 7 partes. A seção 1 mostrou a introdução deste trabalho. Na seção 2, são mostradas as tecnologias disponíveis para aplicações móveis, os problemas enfrentados no desenvolvimento para dispositivos móveis e restrições das aplicações móveis. A seção 3 mostra a tecnologia J2ME, o conceito de configuração e perfil. Na seção 4, é realizada a descrição do sistema como um todo, e suas funcionalidades; os padrões de projetos utilizados. A seção 5 mostra a parte de modelagem do sistema, apresentando alguns diagramas da UML. A seção 6 demonstra os testes realizados, e finalmente, na seção 7 mostra as conclusões. 2. TECNOLOGIAS PARA APLICAÇÕES MÓVEIS Ultimamente, As empresas vêm investindo maciçamente nas tecnologias para dispositivos sem fio. O resultado disso foi o surgimento de várias tecnologias disponíveis para o desenvolvimento de aplicações móveis, como SMS (Simple Message Service), MMS (Multimedia Message Service), BREW (Binary Runtime Enviroment for Wireless) e J2ME (Java 2 Micro Edition). Ainda há outras tecnologias como WAP (Wireless Application Protocol) que aliada ao WML (Wireless Markup Language) permite que o usuário visualize determinado conteúdo da Web, como se estivesse em uma página da Web, só que seu conteúdo é formatado e otimizado especificamente para dispositivos móveis. Para os Palms e PDAs existe ainda o suporte à linguagem C++, que pode ser utilizada para o desenvolvimento de aplicações para esses dispositivos. 2.1 RESTRIÇÕES DAS APLICAÇÕES MÓVEIS Programar para dispositivos móveis requer um pouco de cautela, haja vista as limitadas configurações da maioria dos dispositivos. Restrições como poder de processamento baixo, capacidade de memória limitada e escassez de recursos gráficos devem permear o pensamento do desenvolvedor no momento em que estiver escrevendo sua aplicação móvel J2ME. Em dispositivos celulares mais antigos, por exemplo, não há suporte para cores. Porém, há anos que os fabricantes de dispositivos já estão produzindo telefones celulares com suporte a cores. Com a evolução da tecnologia, hoje é comum perceber um celular com suporte de 262 mil cores. Outro fator restritivo é o limite da tela na maioria dos dispositivos. Pro exemplo, em um celular, que possui uma resolução de 12.288 pixels (96 x 128), se torna complicado
tentar exibir um simples nome completo de uma pessoa, ou o endereço da mesma. 3. TECNOLOGIA J2ME J2ME (Java 2 Platform Micro Edition) é uma especificação da plataforma Java que foi projetada para suportar aplicações desenvolvidas para dispositivos móveis sem fio, como PDAs, pagers, telefones celulares, entre outros. Nesta especificação estão inclusos máquinas virtuais Java (JVM) e um conjunto de padrões da Java API desenvolvido pelo Java Community Process (JCP). Embora a J2ME tenha sido desenvolvida para dispositivos móveis, ela ainda dá suporte para uma amigável e flexível Interface Gráfica com Usuário (GUI), um modelo de segurança robusto, um conjunto de protocolos de redes embutidos e um extenso suporte para aplicações simples e aplicações que utilizam o conceito de redes. 3.1 CONFIGURAÇÕES A especificação J2ME implementa a idéia de configuração e perfil. De acordo com a Sun Microsystems (2002), uma configuração diz respeito a dispositivos que possuem restrições e limitações de recursos, como poder de processamento, de memória e de capacidade gráfica. Esta é composta por um conjunto de bibliotecas e uma máquina virtual que varia para cada ambiente J2ME. A versão móvel de Java dá suporte a dois tipos de configurações, denominadas CLDC (Connected Limited Device Configuration) e CDC (Connected Device Configuration). CLDC refere-se a dispositivos como telefones celulares, PDAs (Personal Data Assistent), pagers, etc. Para que um dispositivo pertença a esta configuração, este deve possuir as seguintes restrições: Um processador de 16 ou 32 bits com uma velocidade de clock de 16 MHz ou mais; Pelo menos 160 KB de memória não volátil alocada para as bibliotecas e a máquina virtual da CLDC; A configuração CLDC ainda dá suporte a pacotes opcionais, que são o Wireless Messaging API(WMA) para implementar recursos de envio e recebimento de mensagens como SMS, MMS; e o Media Mobile API (MMA), que possui recursos de multimídia, como vídeo, áudio, streaming, etc. e sejam adicionados para agregar determinada funcionalidade.
3.2 PERFIS Um perfil é um conjunto de padrões de APIs que oferece suporte para uma gama de dispositivos que são construídos sobre uma determinada configuração (SUN MICROSYSTEMS, 2002). A combinação de um perfil com uma configuração forma uma aplicação em J2ME. A seguir será explicado em mais detalhes o perfil suportado pela configuração CLDC: o MIDP. MIDP (Mobile Information Device Profile) é o perfil suportado pela CLDC e possui as seguintes características: Suporte para interface gráfica com o usuário (GUI): A interface GUI é otimizada para o tamanho da tela, variados métodos de entradas (teclado de telefones celulares, eventos em telas touchscreen, entradas por pequenos teclados QWERTY, etc); Extensiva Conectividade: O perfil MIDP proporciona ao desenvolvedor maior flexibilidade no desenvolvimento de aplicações cliente/servidor, implementando padrões de protocolos como o HTTP, HTTPS, sockets e datagramas por meio do framework GCF (Generic Connection Framework), além de serviços Short Message Service (SMS), GSM e CDMA implementada pela WMA API; Há ainda os perfis suportados pela configuração CDC, que são: Foundation Profile: perfil para dispositivos que utilizam redes. Não possui suporte gráfico e suporta alta capacidade; Personal Basis e Personal Profile: base para dispositivos com suporte gráfico e alta capacidade; Como a aplicação em questão foi projetada baseada na CLDC e MIDP, esta configuração e este perfil serão mais explorados. 3.3 MÁQUINA VIRTUAL K A KVM foi projetada para ser a menor e mais eficiente possível, e ainda permanecer rápida para as linguagens Java. Com a memória sendo normalmente um recurso precioso em dispositivos pequenos de recursos restritos, a base de tempo de execução é de apenas 60 kilobytes,aproximadamente. (MUCHOW, 2004). E o termo K da sigla KVM surgiu para fazer alusão aos poucos kilobytes necessários para que a máquina virtual execute uma aplicação na configuração CLDC.
4. O SISTEMA DOCENTE MOBILE O sistema Docente Mobile foi desenvolvido na plataforma Java baseada na especificação J2ME, configuração CLDC 1.0 e perfil MIDP 1.0. Tal sistema tem como funcionalidade facilitar e automatizar a tarefa do docente de atualizar as freqüências de seus alunos. Por meio de uma interface com um outro sistema o Docente On-line (já em uso pela Instituição), o educador pode atualizar remotamente todas as freqüências de seus alunos que antes estavam gravadas internamente em um dispositivo móvel sem fio. Além de permitir a gravação de informações discentes, o diário de classe virtual também permite que o educador possa pesquisar, no registro interno do dispositivo, informações de seus alunos pelo nome e matrícula. A funcionalidade de persistência de dados no dispositivo é implementada pelo RMS (Record Management System Sistema de Gerenciamento de Registro). Para cada mês, o sistema se encarrega de avisar o professor de que o dia limite chegou e este deve enviar as freqüências para o servidor, evitando assim que o docente não se preocupe em saber qual o último dia de atualizar as freqüências. Para realizar o papel de servidor, foi utilizado o contêiner web Tomcat e criado um projeto web que faz a interface com o sistema utilizado pelos docentes da universidade. Nesse projeto, foram criados pacotes que contêm os beans, representando as classes de negócios e de acesso a banco de dados; e um servlet que seleciona a ação a ser processada e posteriormente enviada ao dispositivo sem fio. No servlet estão implementadas todas as regras de negócio necessárias para estabelecer de forma transparente a conexão com o dispositivo móvel. Por meio da GCF (Generic Connection Framework Estrutura de Conexão Genérica), a MIDlet interpreta as requisições e respostas vindas do servlet remoto. A comunicação do dispositivo móvel com o servidor é realizada por meio do protocolo HTTP (HyperText Transfer Protocol) que é implementado pela classe HttpConnection. A vantagem de se utilizar o protocolo HTTP é que qualquer tecnologia do lado do servidor, como Servlets, CGI, JSP, PHP, ASP pode ser utilizada. A fim de melhorar o desempenho e permitir que o usuário continue realizando outras tarefas enquanto dados são recebidos pelo dispositivo, o envio e recebimento de dados foram implementados em uma linha de execução separada que, na plataforma Java, pode ser representada pela classe Thread. 4.1 PADRÕES DE PROJETO A MIDlet utilizou o conceito de padrões de projetos a fim de melhorar a
modularidade do sistema, adaptar o sistema à ações mais complexas do mundo real e permitir que futuras alterações sejam realizadas sem muitos custos. Considerando a limitada capacidade de recursos dos dispositivos móveis (principalmente os celulares), para a aplicação móvel foi utilizado o padrão de projeto Singleton, que garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a ela (METSKER, 2002). A utilização de padrões de projeto, por mais que diminua o grau de acoplamento entre os módulos do sistema, estes devem ser utilizados com cuidado quando se estiver trabalhando com desenvolvimento para aplicações para dispositivos móveis, pois na maioria das vezes um padrão de projeto utiliza várias classes para solucionar determinado problema. Todavia, o crescimento do número de classes implica no aumento do tamanho da aplicação e, conseqüentemente, na redução do desempenho da aplicação. 4.2 INTERFACE GRÁFICA COM O USUÁRIO (GUI) O perfil MIDP, por mais que seja restrito em recursos referentes aos componentes gráficos, disponibiliza uma amigável interface gráfica com o usuário (GUI). A MIDlet utiliza vários componentes deste perfil com a finalidade de realizar a comunicação visual com o usuário. Esses componentes são representados pelas seguintes classes: Form, que se assemelha a um formulário de aplicação. Dentro dos Forms, foram adicionados componentes TextField, para entrada de texto (informar o login e a senha, por exemplo); Alert, para mostrar o progresso ou resultado de determinada operação; Command, que representa a ação ou comando que o usuário quer realizar (como gravar ou enviar as freqüências dos alunos, por exemplo). Segundo Muchow (2004, p.78), o modo mais simples de pensar em um objeto Command é como um botão, algo que você pressiona ou seleciona. Para representar as opções de seleção que o usuário escolher (como a turma a qual deseja listar os alunos, o tipo de pesquisa) e as caixas de seleção, (para representar o status da freqüência dos alunos se ele está presente ou ausente) foi utilizado o componente ChoiceGroup. A classe DateField, que representa um tipo abstrato de calendário, foi utilizada para a escolha do dia em que se deseja gravar as freqüências dos alunos. A seguir, na Figura 1, é mostrado a tela seleção de turmas com os compoentes ChoiceGroups representando as turmas disponíveis para o docente.
Figura 1. Tela de Seleção de Turmas. 5. MODELAGEM DO SISTEMA Para realizar a modelagem do sistema a linguagem UML (Unified Modeling Language) foi utilizada. A seguir, serão mostrados o diagrama de caso de uso para a realização da conexão da MIDlet com o servidor web; e o diagrama de seqüência, para demonstrar os passos necessários para que o professor grave as freqüências de seus alunos. Todos os diagramas a seguir foram criados com o software de modelagem JUDE Community 2.5.1. 5.1 Diagrama de Casos de Uso Este diagrama é muito utilizado no momento em que se deseja mostrar as funcionalidades que o sistema dispõe. Na Figura 2, é mostrado o caso de uso para realizar a conexão com o servidor remoto. Figura 2. Diagrama de Caso de Uso.
Para que o docente possa realizar a conexão com o servlet, são necessários os seguintes passos: 1. Na tela de Autenticação, o docente informa o login e a senha que são os mesmos do sistema Docente On-line; 2. Clicar no comando de conectar e esperar o resultado da conexão; 2.1 Caso a conexão seja realizada com sucesso, o docente poderá escolher a turma para qual deseja gravar as freqüências; 2.2 Caso ocorra algum erro durante a realização da conexão - como usuário e senha inválida ou servidor fora do ar - a aplicação informará sobre o erro que ocorreu e retornará para a tela de autenticação para que o docente possa entrar com as informações novamente. 5.2 Diagrama de Seqüência O diagrama de seqüência é muito interessante, pois mostra qual o fluxo das mensagens entre os objetos participantes do modelo. A Figura 3 mostra todo o processo de gravação das freqüências, desde a seleção dos alunos presentes até a sua gravação interna no dispositivo. Figura 3. Diagrama de Seqüência. 1. Na tela de lista de alunos, o docente pode editar a freqüência de cada aluno ou pode selecionar todos de uma vez, em caso de presença total. Ao ter selecionado uma das opções de seleção, o professor seleciona o comando de gravação. 2. As freqüências dos alunos são retornadas como um array de String 3. Os nomes dos alunos são retornados como um array de String
4. As matrículas dos alunos são armazenadas em um array de String 5. A data escolhida é formata para o padrão brasileiro. 6. Um objeto da classe RMSAluno é criado. Esse objeto será responsável por ações de armazenamento e recuperação das informações dos alunos. 7. As informações dos alunos são armazenadas no dispositivo interno por meio do RMS. 8. O registro de alunos é fechado. 6. TESTES Para que pudesse ser realizada a comunicação do sistema móvel com o sistema servidor, vários testes foram realizados (testes de interfaces, de conexão, de desempenho). Para isso, foi utilizado o simulador Sun Java Wireless Toolkit 2.3, que é uma ferramenta de desenvolvimento do J2ME que vem empacotada com um simulador que pode imitar vários telefones móveis, assim como PDAs e pagers.(muchow, 2004). Este simulador permite que o programador configure seu ambiente de desenvolvimento a fim de prever qual seria o comportamento de uma aplicação J2ME rodando em um dispositivo móvel real. Variáveis reais como capacidade de armazenamento, velocidade de processamento e velocidade da rede podem ser configuradas. 7. CONCLUSÃO O sistema Docente Mobile foi desenvolvido acima de tudo para auxiliar o profissional docente na ação rotineira e um tanto quanto custosa de atualizar diariamente as freqüências de seus alunos. O projeto ainda não foi adotado pela Instituição, portanto poderá futuramente fazer parte do contexto acadêmico. O projeto está em sua primeira versão. Futuramente, se pretende incorporar ao sistema mais funções de sua versão Web, como lançamento de notas, aviso dos dias das avaliações e outras funções relevantes ao contexto acadêmico; porém sempre levando em consideração os limites dos recursos dos dispositivos. AGRADECIMENTO Agradecemos antes de tudo a Deus, que está sempre nos orientando em nossos caminhos da vida. À professora Thienne, orientadora deste artigo e do projeto Docente
Mobile, por ter-nos dado a oportunidade de conhecer mais afundo a tecnologia J2ME que, até então, não fazia parte do nosso contexto. Ao coordenador do curso de Ciência da Computação, professor Cláudio Alex Jorge da Rocha, por ter disponibilizado os laboratórios para que os testes pudessem ser realizados. E finalmente, à Universidade da Amazônia, por ter nos permitido acesso às referencias bibliográficas. REFERÊNCIAS Muchow, John, 2004.Core J2ME Tecnologia & MIDP. Pearson Makron Books, São Paulo. Sun Microsystems, 2002.Connected Limited Device Configuration (CLDC); JSR 30, JSR 139 Overview. Disponível em: java.sun.com/products/cldc/overview.html. Acesso em 03 abr. 2006. Sun Microsystems, 2002. Mobile Information Device Profile (MIDP); JSR 37, JSR 118 Overview. Disponível em: java.sun.com/products/cdc/overview.html. Acesso em: 03 abr. 2006. Metsker, Steven J., 2002. Padrões de Projeto em Java. Bookman, São Paulo.