UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UTILIZAÇÃO DA TECNOLOGIA J2ME PARA AUTOMATIZAÇÃO DO CONTROLE DE EXPEDIÇÃO DE EQUIPAMENTOS DAS EMPRESAS DO GRUPO MEG Área de Sistemas Embarcados por Rafael Pacheco Luz Cesar Albenes Zeferino, Dr. Orientador Itajaí (SC), junho de 2007

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UTILIZAÇÃO DA TECNOLOGIA J2ME PARA AUTOMATIZAÇÃO DO CONTROLE DE EXPEDIÇÃO DE EQUIPAMENTOS DAS EMPRESAS DO GRUPO MEG Área de Sistemas Embarcados por Rafael Pacheco Luz Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Cesar Albenes Zeferino, Dr. Itajaí (SC), junho de 2007

3 DEDICATÓRIA Aos meus pais, Rogério Moreira Luz e Maria Ângela Pacheco Luz, pelo apoio incontestável, dedicação, amor, carinho, educação e por todos os outros motivos que me fazem sentir orgulho de ser seu filho. A minha filha Emanuelle e meu irmão Huan por fazerem parte da minha vida. Aos verdadeiros amigos, por terem cruzado meu caminho. ii

4 AGRADECIMENTOS Aos meus pais, Rogério Moreira Luz e Maria Ângela Pacheco Luz, que não pouparam esforços para minha formação, a quem devo tudo e expresso meu eterno amor e gratidão. Ao professor Cesar Albenes Zeferino pela orientação, por me inserir e despertar a ambição pela pesquisa, pela motivação, ensinamento e disponibilidade oferecida. Aos membros da banca examinadora, Alisson Gruchowski, Fabrício Bortoluzzi, Luis Carlos Martins e Rafael Luiz Cancian pelas valiosas sugestões e críticas que fortaleceram o desenvolvimento desse trabalho. Aos amigos, Marcelo de Souza, pelo esforço aplicado na pesquisa de soluções para os problemas encontrados na fase de implementação; Heloyse Macedo e Thiago Antonio, pelo apoio e incentivo indispensáveis na fase inicial desta jornada; e Ricardo Tobaldini pela compreensão e disponibilização de equipamentos e da infra-estrutura. A todos os demais verdadeiros e grandes amigos, que mesmo estando longe, sempre me deram força e confiaram em mim. iii

5 SUMÁRIO LISTA DE ABREVIATURAS...vi LISTA DE FIGURAS...vii LISTA DE TABELAS...ix RESUMO...x ABSTRACT...xi 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA COMPUTAÇÃO MÓVEL Dispositivos móveis Tecnologias de conexão sem fio Tecnologias de desenvolvimento TECNOLOGIA JAVA J2ME TRABALHOS RELACIONADOS CLOG InvPalm e PalmPat Considerações DESENVOLVIMENTO CENÁRIO ATUAL CARACTERIZAÇÃO DO DOMÍNIO DA APLICAÇÃO Integração com o sistema atual ARQUITETURA DO SISTEMA FUNCIONAMENTO DO SISTEMA MODELAGEM DO SISTEMA Levantamento de Requisitos Projeto do Sistema IMPLEMENTAÇÃO TESTES E VALIDAÇÃO DO SISTEMA CONCLUSÕES...52 iv

6 REFERÊNCIAS BIBLIOGRÁFICAS...54 A MODELAGEM DO SISTEMA...57 A.1 CASOS DE USO A.1.1 Pacote 01: Controle de acesso A.1.2 Pacote 02: Operações A.1.3 Pacote 03: Configurações A.2 PROTÓTIPOS DAS TELAS DO SISTEMA A.3 DIAGRAMA DE CLASSES A.3.1 Diagrama de classes de negócio A.3.2 Diagrama de classes de projeto A.4 DIAGRAMAS DE SEQUÊNCIA v

7 LISTA DE ABREVIATURAS.NET API AWT BREW CDC CE CLDC CPU FP GUI J2EE J2ME J2SE JSP JSR JVM KVM LAN MAN MIDP MS PAN PBP PC PDA PDAP PP RAM RFID RMI SGBD TCC UML UNIVALI VB WAP Wi-Fi WiMax XML Dot NET Application Programming Interface Abstract Window Toolkit Binary Runtime for Wireless Environment Connected Device Configuration Compact Edition Connected Limited Device Configuration Central Processing Unit Foundation Profile Graphical User Interface Java 2 Enterprise Edition Java 2 Micro Edition Java 2 Standard Edition Java Server Pages Java Specification Request Java Virtual Machine Kilo Virtual Machine Local Area Network Metropolitan Area Network Mobile Information Device Profile Microsoft Personal Area Network Personal Basis Profile Personal Computer Personal Digital Assistants Personal Digital Assistant Profile Personal Profile Random Access Memory Radio-Frequency IDentification Remote Method Invocation Sistema de Gerenciamento de Banco de Dados Trabalho de Conclusão de Curso Unified Modeling Language Universidade do Vale do Itajaí Visual Basic Wireless Application Protocol Wireless Fidelity Worldwide Interoperability for Microwave Access Extensible Markup Language vi

8 LISTA DE FIGURAS Figura 1. Coletor Portátil MC Figura 2. Arquitetura da solução proposta...4 Figura 3. Compilador e Interpretador Java...16 Figura 4. Arquitetura da Plataforma Java...17 Figura 5. Arquitetura genérica do J2ME...18 Figura 6. Plataforma J2ME...22 Figura 7. Plataforma J2ME...22 Figura 8. Telas do Sistema CLOG...25 Figura 9. Telas do sistema InvPalm...26 Figura 10. Telas do sistema PalmPat...26 Figura 11. Arquitetura Proposta Figura 12. Arquitetura Proposta Figura 13. Atalho do sistema na tela principal do dispositivo...33 Figura 14. Tela de login...33 Figura 15. Tela principal: (a) Nível Administrador; (b) Nível Operador...34 Figura 16. Tela de entrada de dados Nota Fiscal...34 Figura 17. Tela de entrada de dados Número de Série...35 Figura 18. Tela de configuração dos parâmetros do sistema...35 Figura 19. Diagrama de Caso de Uso Pacote Controle de Acesso...38 Figura 20. Diagrama de Caso de Uso Pacote Operações...39 Figura 21. Diagrama de Caso de Uso Pacote Configurações...39 Figura 22. Diagrama de Classes de Negócio...40 Figura 23. Diagrama de classe projeto Cadastra Dados...41 Figura 24. Diagrama de classe de projeto Valida Dados...42 Figura 25. Diagrama de seqüência Cadastra Dados...43 Figura 26. Diagrama de seqüência Valida Dados...43 Figura 27. Estrutura de pacotes da aplicação...45 Figura 28. Tela de Login Dispositivo Móvel...48 Figura 29. Tela de Opções (Menu) Dispositivo Móvel...49 Figura 30. Tela de Expedição (Nota Fiscal) Dispositivo Móvel...50 Figura 31. Tela de Expedição (Número de Série) Dispositivo Móvel...51 Figura 32. Diagrama de Pacotes dos Casos de Uso...57 Figura 33. Casos de Uso do Pacote Controle de Acesso...58 Figura 34. Casos de Uso do Pacote Operações...60 Figura 35. Casos de Uso do Pacote Configurações...63 Figura 36. Tela 01 Login...64 Figura 37. Tela 02 Principal: (a) Nível Administrador; (b) Nível Operador...65 Figura 38. Tela 03 Expedição: Nota Fiscal...65 Figura 39. Tela 04 Expedição: Número de Série...66 Figura 40. Tela 05 Cadastro de Parâmetros...66 Figura 41. Tela 06 Exibição de Mensagens...66 Figura 42. Diagrama de Classes de Negócio...67 Figura 43. Diagrama de Classes de Projeto UC01.01 Efetua Login...68 Figura 44. Diagrama de Classes de Projeto UC02.01 Cadastra Dados...69 Figura 45. Diagrama de Classes de Projeto UC02.02 Valida Dados...70 Figura 46. Diagrama de Classes de Projeto UC03.01 Cadastra Parametros...71 vii

9 Figura 47. Diagrama de Seqüência UC01.01 Efetua Login...72 Figura 48. Diagrama de Seqüência UC02.01 Cadastra Dados...72 Figura 49. Diagrama de Seqüência UC02.02 Valida Dados...73 Figura 50. Diagrama de Seqüência UC03.01 Cadastra Parâmetros...73 viii

10 LISTA DE TABELAS Tabela 1. Resumo Tecnologias de Comunicação sem Fio...13 Tabela 2. Resumo Pacotes Opcionais...23 Tabela 3. Padronização do Código de Barras - Ledervin Indústria e Comércio...25 Tabela 4. Características das Arquiteturas...32 ix

11 RESUMO LUZ, Rafael Pacheco. Utilização da tecnologia J2ME para automatização do controle de expedição de equipamentos das empresas do Grupo MEG. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A evolução das tecnologias de comunicação tem possibilitado o acesso a informações remotas onde quer que se esteja, proporcionando ao usuário facilidades através de diversas aplicações e/ou serviços. A computação móvel está acompanhando essa evolução. Hoje é muito comum encontrarmos usuários utilizando os mais modernos dispositivos móveis, rodando diferentes aplicações, desenvolvidas por diversas tecnologias, que vem se aprimorando cada vez mais. O presente texto apresenta o desenvolvimento de um software, baseado em computação móvel, para automatizar o controle do processo de expedição de equipamentos industrializados e comercializados pelas empresas do Grupo MEG de Navegantes. O software consiste em uma aplicação J2ME (Java 2, Micro Edition) rodando em um terminal portátil de dados, que permite ao usuário fazer a leitura dos códigos de barras dos equipamentos a serem transportados, armazenar os dados temporariamente e solicitar a validação dos mesmos, dessa forma, eliminando-se o trabalho manual, proporcionando maior agilidade. Com o intuito complementar a formação obtida nas disciplinas do Curso de Bacharelado em Ciência da Computação da Universidade do Vale do Itajaí, foram pesquisados conceitos sobre computação móvel, dispositivos móveis, tecnologias de conexão sem fio e tecnologias de desenvolvimento para dispositivos móveis, dando-se maior destaque para a tecnologia J2ME. O projeto do software foi desenvolvido seguindo os padrões da UML (Unified Modeling Language), com auxílio da ferramenta Enterprise Architect. Foram elaborados diagramas de caso de uso, classe e seqüência, além dos protótipos de telas. A implementação do sistema foi realizada na ferramenta WebSphere Studio Device Developer (WSDD), adotando o padrão de desenvolvimento de software em três camadas, o MVC (Model, View e Controller). Palavras-chave: Sistemas Embarcados. Computação Móvel. J2ME. x

12 ABSTRACT The evolution of the technologies of communication has made possible the access to remote information from anywhere, allowing the development of new applications and services. The mobile computer is following this evolution. Today, it is very common to find users using the most modern mobile devices and running different applications based one several technologies, that are improving more and more. This work presents the development of a mobile computing-based application to automate the expedition control of equipments produced and commercialized by the companies of MEG Group, from Navegantes, Brazil. The developed software is a J2ME (Java 2, Micro Edition) application running on a portable terminal of data that allows the user to read barcodes of the equipments, store data in a temporarily way, and request the validation these data, so eliminating the manual work and providing more efficiency in the expedition process. To carry out this research, it was necessary to study new concepts and technologies beyond the ones studied at Computer Science Course of UNIVALI, like mobile computing, mobile devices, wireless technologies, J2ME and integrated environments for the developing of mobile applications. The design of the software was carried out by using UML (Unified Modeling Language). Use case, class and sequence diagrams were elaborated, besides the prototypes of screens. System implementation was accomplished with the use of WebSphere Studio Device Developer (WSDD) tool, using MVC (Model, View and Controller) design pattern to develop the software. Keywords: Embedded Systems. Mobile Computing. J2ME. xi

13 1 INTRODUÇÃO Nos últimos anos, pôde-se notar um grande incremento no uso de tecnologias para comunicação. A evolução dessas tecnologias tem possibilitado o acesso a informações remotas onde quer que se esteja, proporcionando ao usuário muitas facilidades através de diversas aplicações e/ou serviços. Os dispositivos computacionais móveis também têm evoluído da mesma forma, alcançando uma grande popularização. Hoje é muito comum se encontrar usuários desses dispositivos, sendo os mais comuns: celulares, PDAs (Personal Digital Assistants) e laptops. Conforme Muchow (2004, p.3), os equipamentos eletrônicos para consumidor modificam nossas vidas. Os telefones móveis nos permitem comunicar quando estamos longe de casa ou do escritório. Os PDAs nos permitem ler s, navegar na internet e executar aplicativos de todas as formas e modalidades. Segundo Mateus e Loureiro (1998, p.1), a computação móvel surge como uma quarta revolução na computação antecedida pelos grandes centros de processamento de dados da década de sessenta, o surgimento dos terminais nos anos setenta, e as redes de computadores na década de oitenta. Esses autores também afirmam que a computação móvel ainda amplia o conceito tradicional de computação distribuída. Isso é possível graças à comunicação sem fio, o que elimina a necessidade do usuário manter-se conectado a uma infra-estrutura fixa e, em geral, estática. Para Figueiredo e Nakamura (2003, p.16), A computação móvel pode ser representada como um novo paradigma computacional que permite que usuários desse ambiente tenham acesso a serviços independentemente de sua localização, podendo inclusive, estar em movimento. Mais tecnicamente, é um conceito que envolve processamento, mobilidade e comunicação sem fio. Ainda, de acordo com Lee, Schneider e Schell (2005, p.1), No contexto da computação móvel, mobilidade se refere ao uso pelas pessoas de dispositivos móveis portáteis poderosos que oferecem a capacidade de realizar facilmente um conjunto de funções de aplicação, sendo também capaz de conectar-se, obter dados e fornecê-los a outros usuários, aplicações e sistemas.

14 1.1 PROBLEMATIZAÇÃO Formulação do Problema Este trabalho proporcionou a automatização de um processo manual de controle de expedição de equipamentos produzidos pelas empresas do grupo MEG 1, formado pela fusão das empresas Motomil, Eletroplas e Garthen 2. Localizado na BR-470, no município de Navegantes, o grupo conta com uma área de mais de cem mil metros quadrados. Cada empresa do grupo é responsável por um segmento de produção, conforme segue: Motomil: produz compressores de ar, motoesmeris, serras de cortar ferro e alumínio, furadeiras de bancada e coluna e politrizes; Eletroplas: fabrica motobombas elétricas e a gasolina, geradores e peças de plástico injetadas; Garthen: produz cortadores de grama elétricos e a gasolina, aparadores de grama, roçadeiras elétricas e a gasolina, sopradores / sugadores de grama, podadores de cerca viva, tratores roçadores de grama, trituradores e picadores forrageiros e trituradores de resíduos orgânicos. Todos os produtos do Grupo MEG são identificados por um número de série único, impresso em uma etiqueta na forma numérica e em código de barras. Atualmente, o processo de expedição dos equipamentos industrializados pelas empresas do Grupo MEG é realizado basicamente em duas etapas. Inicialmente, ao carregarem os equipamentos para os caminhões de transporte, há uma conferência, validando esses equipamentos com os itens relacionados na nota fiscal de saída. Essa conferência é feita de modo manuscrito em um formulário, dando início à segunda etapa do processo, que é a digitação desses dados no sistema, para então poder liberar o transporte dos equipamentos. Por se tratar de uma indústria com fluxo intenso de embarque de equipamentos, o pátio reservado para a área de expedição ocupa uma grande parte do espaço territorial da empresa, que 1 A primeira letra do nome de cada uma das empresas deu origem ao nome do grupo (M, E e G). 2 O site do grupo está disponível no endereço eletrônico: 2

15 por sua vez, se localiza um pouco distante do prédio administrativo, onde se encontra o Setor de Expedição. Para a empresa, o maior problema é a morosidade do processo, causado pela necessidade de conferência manual dos equipamentos que serão transportados, locomoção do pátio de expedição até o escritório, entrada de dados no sistema e posterior validação dos mesmos. Mediante tal situação, algumas soluções foram discutidas, como a utilização de leitores de código de barras ligado ao computador do Setor de Expedição. Essa solução resolveria parte do problema, eliminando o trabalho manuscrito, porém apresentaria ainda alguns inconvenientes, como a limitação do tamanho do cabo de conexão do leitor de código de barras com o PC (Personal Computer) e locomoção de todos os produtos até a sala de expedição, o que inviabiliza essa solução. Outra alternativa consistiria na utilização de leitores de códigos de barras sem fio, o que proporcionaria maior mobilidade. Entretanto, identifica-se, ainda, uma limitação de alcance, podendo variar de acordo com o tipo de conexão utilizada pelo equipamento. Desconsiderando essa limitação, a mobilidade proporcionada com esse tipo de equipamento resolveria a questão da entrada de dados, porém a validação ainda deveria ser feita no PC, o que exigiria o deslocamento do funcionário do pátio até o escritório. Uma terceira opção, adotada neste projeto, foi o desenvolvimento de um software para rodar em um coletor de dados com interface de comunicação wireless, que permite ao funcionário do Setor de Expedição fazer a leitura de código de barras dos equipamentos em qualquer lugar do pátio da empresa, solicitar a validação dos dados informados e receber o retorno da validação, sem que para isso o funcionário tenha que se deslocar até sua sala. O equipamento que a empresa dispõe para que se possa aplicar essa solução é um terminal portátil de dados, que oferece mecanismos de imagem como leitura (1D e 2D) ou laser. Possui sistema operacional Windows CE 4.2, que, de acordo com Cezar Taurion (2005), oferece uma gama abrangente de ferramentas de apoio ao desenvolvimento de soluções embarcadas, inclusive com soluções de emulação, que permitem o rápido desenvolvimento de aplicações. Além disso, o equipamento possui um processador de 312 MHz, 32 MB de memória RAM (Random Access Memory) e uma interface para comunicação de dados em radiofreqüência. A Figura 1 apresenta uma imagem deste equipamento. 3

16 Figura 1. Coletor Portátil MC3000 Fonte: Symbol (2006) Solução Proposta Segundo Lee, Schneider e Schell (2005, p.15), Os profissionais querem que seu dispositivo ou aplicação móvel tornem de alguma forma o seu trabalho mais fácil. Buscando satisfazer essa condição, foi desenvolvido uma aplicação para dispositivos móveis com a tecnologia J2ME (Java 2, Micro Edition), capaz de proporcionar aos funcionários do Setor de Expedição das empresas do Grupo MEG, funcionalidades como leitura dos códigos de barras dos equipamentos, armazenamento e validação dos dados. As informações obtidas com o terminal portátil de dados são validadas através de consultas ao servidor de banco de dados do sistema atual da empresa. A comunicação entre o aplicativo móvel e o servidor de banco de dados se dá através de uma rede local sem fio. A Figura 2 ilustra a arquitetura do sistema. Figura 2. Arquitetura da solução proposta 4

17 1.2 OBJETIVOS Objetivo Geral Desenvolver um aplicativo baseado em computação móvel, com a utilização da tecnologia J2ME, para automatizar o processo de expedição das empresas do Grupo MEG Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são: Pesquisar e analisar soluções similares; Adquirir competência no desenvolvimento de soluções para computação móvel baseadas na tecnologia J2ME; Conhecer as demais tecnologias necessárias à implementação do sistema; Determinar os requisitos exigidos para o sistema; Selecionar a arquitetura a ser utilizada; Realizar a modelagem conceitual do sistema; Implementar o sistema; Testar e validar a implementação do sistema; e Documentar o desenvolvimento e os resultados do sistema. 1.3 Metodologia Este TCC incluiu a execução das seguintes etapas, previstas na proposta deste trabalho: (i) leitura e levantamento de conceitos; (ii) análise e projeto; (iii) implementação; (iv) validação e (v) documentação. Na etapa de leitura e levantamento de conceitos, foram pesquisados conceitos sobre computação móvel, dispositivos móveis, tecnologias de conexão sem fio, tecnologias de desenvolvimento para dispositivos móveis, entre outros conceitos não menos importantes, mas que acabam agregados nesses considerados maiores. Essa pesquisa, cujo objetivo foi adquirir competência no desenvolvimento de soluções para computação móvel baseadas na tecnologia 5

18 J2ME, foi realizada através de revisão bibliográfica em livros, artigos e em outros trabalhos de graduação e pós-graduação. Nesta etapa também foi realizado o estudo de soluções similares. A etapa de análise e projetos iniciou-se com o levantamento de todos os requisitos que o sistema deveria atender, bem como as regras de negócio. A modelagem do sistema buscou apresentar de forma detalhada, através de textos e diagramas, o funcionamento do sistema, a estrutura de classes, as principais operações e a seqüência de passos necessários à execução das mesmas. O projeto do software foi desenvolvido seguindo os padrões da UML, com auxílio da ferramenta Enterprise Architect, sendo elaborados diagramas de caso de uso, classes de negócio, classes de projeto e seqüência, além dos protótipos de telas. A etapa de implementação consistiu na codificação do projeto do sistema, através da tecnologia Java, obedecendo a análise e o projeto realizados. A aplicação foi desenvolvida dentro dos padrões da edição J2ME, com base nas especificações da configuração CDC e perfil Personal Profile versão 1.0, com suporte da ferramenta WebSphere Studio Device Developer (WSDD). A etapa de validação foi subdividida em duas fases. A primeira fase ocorreu em paralelo a implementação e compreendeu a aplicação do teste unitário, uma das fases do processo de teste, cujo objetivo é encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo. Já a segunda fase compreendeu os testes de aceitação, realizados por um grupo restrito de usuários finais do sistema, simulando operações de rotina do sistema de modo a verificar se seu comportamento. A etapa de documentação compreendeu o registro de todos os processos referentes às etapas: (i) leitura e levantamento de conceitos, (ii) análise e projeto, (iii) implementação e (iv) validação, seguindo as normas exigidas pela Coordenação de TCC. 1.4 Estrutura do trabalho O restante desta monografia está estruturado em três capítulos adicionais: Fundamentação Teórica, Desenvolvimento e Considerações Finais. No capítulo Fundamentação Teórica, são apresentados conceitos base para o entendimento do processo de desenvolvimento de aplicações para dispositivos móveis. Nesse capítulo, também é feita uma descrição de algumas ferramentas similares. O capítulo seguinte, Desenvolvimento, apresenta detalhadamente, o sistema desenvolvido, incluindo sua especificação e a sua modelagem em UML (complementada no 6

19 Apêndice A), detalhes da implementação do sistema bem como os testes aplicados. Por fim, no último capítulo são apresentadas conclusões pertinentes ao desenvolvimento do TCC. 7

20 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo, serão abordados os principais conceitos necessários ao entendimento e desenvolvimento de aplicações para dispositivos móveis, incluindo temas como: Computação Móvel, Dispositivos Móveis, Tecnologias de Conexão sem Fio, Tecnologias de Desenvolvimento, com maior ênfase para a tecnologia J2ME, além da descrição de algumas soluções similares, que são apresentadas sob o tema Trabalhos Relacionados. 2.1 Computação móvel A computação móvel vem surgindo como uma nova proposta de paradigma computacional advinda da tecnologia de rede sem fio e dos sistemas distribuídos. Nela, os dispositivos móveis, como palmtops, notebooks e celulares, têm acesso a uma infra-estrutura compartilhada independente de sua localização física (DEMÉTRIO, 2001). Para Figueiredo e Nakamura (2003, p.16), a computação móvel pode ser representada como um novo paradigma computacional que permite que usuários desse ambiente tenham acesso a serviços independentemente de sua localização, podendo inclusive, estar em movimento. Segundo Dornan (2001), Um sistema de computação móvel tem como principal característica a possibilidade de comunicação entre componentes físicos e móveis, como por exemplo um computador pessoal e um telefone celular. Os sistemas móveis utilizam tecnologia sem fio para poder dar mobilidade, transparência e confiança enquanto os usuários se deslocam. A mobilidade é um fator preponderante para computação móvel. Para Lee, Schneider e Schell (2005, p.1), a mobilidade se refere ao uso pelas pessoas de dispositivos móveis portáteis poderosos que oferecem a capacidade de realizar facilmente um conjunto de funções de aplicação, sendo também capaz de conectar-se, obter dados e fornecê-los a outros usuários, aplicações e sistemas. Lee, Schneider e Schell (2005) destacam ainda, a importância das características da mobilidade, na qual o dispositivo móvel ou a solução móvel que oferece a melhor mobilidade geralmente terá alguma combinação dessas características. Esse autor enumera e descreve as principais características da mobilidade:

21 Portabilidade: É definida como a capacidade de ser facilmente transportável, considerando como fatores mais importantes o tamanho e o peso do dispositivo; Usabilidade: É dependente de vários fatores, sendo os mais relevantes: o usuário, o ambiente e as características do dispositivo; Funcionalidade: Os dispositivos móveis servem a múltiplos propósitos e têm diversos tipos de funcionalidade. A funcionalidade é implementada na forma de uma aplicação móvel; e Conectividade: Os dispositivos móveis em geral operam em um de três modos, sendo eles: sempre conectado a um sistema back-end; conectado de forma intermitente a um sistema back-end; e inteiramente sem conexão a um sistema back-end Dispositivos móveis Muito mais do que assistentes pessoais ou agendas eletrônicas, os dispositivos móveis 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 segurança no acesso a informações corporativas e pessoais (LAUDON e LAUDON, 1999). Esses dispositivos devem ter a capacidade de realizar processamento, trocar informações via rede e poder ser transportado facilmente por seu usuário (FIGUEIREDO e NAKAMURA, 2003). Algumas características físicas marcantes desses equipamentos são: o tamanho e a não dependência de cabos. Os dispositivos móveis devem ser bem menores que as estações de trabalho do tipo desktop, devem possuir uma bateria e ter acesso a dados através de tecnologias de redes sem fio. Para Figueiredo e Nakamura (2003), os dispositivos usados para os fins da computação móvel, basicamente são laptops, palmtops (ou PDAs Personal Digital Assistants) e celulares. Já Lee, Schneider e Schell (2005), incluem, além desses, os pagers e os tablet PCs (conforme descrito a seguir). Os pagers são utilizados principalmente pelas pessoas que precisam estar acessíveis em função da sua perícia ou capacidade de fazer algo. Exemplos comuns são os profissionais de saúde, o pessoal de suporte de computadores e os comerciantes. Não chegam a ter muitas aplicações 9

22 rodando neles. Recentemente, no entanto, as capacidades desses dispositivos móveis aumentaram de tal forma que rapidamente estão se tornando verdadeiros PDAs. Os telefones celulares surgiram, originalmente, como dispositivos para conversação por voz, exclusivamente. Porém, com o avanço da tecnologia e a evolução das gerações da telefonia celular, esses dispositivos adquiriram também capacidade de processamento e comunicação através da integração da rede celular com a rede de dados, em especial a Internet (FIGUEIREDO e NAKAMURA, 2003). Atualmente, há no mercado uma gama muito ampla de telefones celulares destinados a todos os tipos de usuários móveis, oferecendo múltiplos serviços e funções, além dos serviços mais básicos de telefonia. Os PDAs foram inicialmente projetados para serem uma versão eletrônica de uma agenda pessoal, com funcionalidades básicas, como agenda de compromissos, cadastro de contatos telefônicos, etc. Atualmente, com o advento de CPUs (Central Processing Unit) mais poderosas, sistemas operacionais e maior disponibilidade de memória, os PDAs têm muitas outras funções, incluindo: correio eletrônico; acesso a internet; jogos; e aplicações personalizadas (por exemplo,.net, Java). Um tablet PC é um computador móvel de uso geral integrado a uma grande tela interativa que permite ao usuário escrever diretamente sobre a tela usando uma caneta. Possui quase todas as funções de um computador desktop, como: correio eletrônico; acesso a Internet; jogos; aplicações de escritório; multimídia; e aplicações personalizadas. O laptop é um computador móvel de uso geral com uma grande tela integrada que apresenta um mouse e um teclado como dispositivos típicos de entrada. É uma versão móvel completa com todos os recursos de um computador desktop, sendo, provavelmente o maior dispositivo móvel que de modo geral pode ser considerado portável. Para Figueiredo (2005), além dos dispositivos já mencionados, existem os smartphones, definidos pelo autor como aparelhos de telefonia celular que provêm funcionalidades de PDA. Crispim Junior (2006, p.16), complementa, afirmando que smartphones são caracterizados pela fusão das funções de telefonia móvel e assistente pessoal em um mesmo aparelho, com a finalidade de contornar as limitações das categorias: celulares e PDAs. Esse mesmo autor cita que os smartphones tratam-se de dispositivos mais poderosos em questões de processamento, 10

23 armazenamento, mobilidade e entrada de dados em relação a seus antecessores, pois fundem suas melhores características, aumentando os recursos de desenvolvimento para novas aplicações. Os dispositivos utilizados durante o desenvolvimento do TCC fogem um pouco da classificação apresentada acima. Tratam-se de terminais portáteis de dados, com sistema operacional Windows CE, processador Intel XScale, sendo que a capacidade de processamento e memória variam de 312Mhz a 550Mhz e de 32 MB a 128MB, respectivamente, de acordo com cada modelo. Mais detalhes sobre esses equipamentos são apresentados no Anexo I Tecnologias de conexão sem fio Computadores móveis são fortemente dependentes de tecnologias de comunicação sem fio para assegurar a mobilidade necessária. Conforme Figueiredo e Nakamura (2003, p.19), uma vez que dispomos de dispositivos computacionais móveis com capacidade de comunicação em rede, devemos manter uma infraestrutura que permita a comunicação entre dispositivos móveis e a rede fixa para troca de dados e acesso às informações desejadas. A comunicação entre o dispositivo e a rede deve ser feita por meio de uma conexão wireless. Isso é destacado por Mateus e Loureiro (1998, p.1), os quais afirmam que a computação móvel amplia o conceito tradicional de computação distribuída. Isso é possível graças à comunicação sem fio que elimina a necessidade do usuário manter-se conectado a uma infraestrutura fixa e em geral estática. Existem vários mecanismos sem fio que um dispositivo móvel pode utilizar para se conectar a uma rede para enviar e receber informações, como, por exemplo, celulares, interfaces Bluetooth e conexões wireless LAN (Local Area Network). Conforme Lee, Schneider e Schell (2005, p. 62), as redes celulares são compostas de conjuntos de áreas contíguas de coberturas de rádio chamadas células. Segundo Taurion (2005, p. 85), a célula é a área de cobertura de uma única estação base. À medida que um telefone móvel se desloca em uma rede, ele tem acesso aos serviços por intermédio da estação base da célula em que se encontra naquele momento. 11

24 O Bluetooth é uma especificação e uma tecnologia que adota comunicações de rádio (ondas curtas), em distâncias pequenas, para transmitir dados e voz (TAURION, 2005). A tecnologia Bluetooth permite aos usuários conectarem seus dispositivos móveis, proporcionando uma interligação de curto alcance (até 10 metros), com o objetivo maior de eliminar fios de conexão. A taxa de transmissão de dados bruta do Bluetooth varia de 56 Kbps 721 Kbps. Uma característica importante do Bluetooth é que, por utilizar tecnologia de rádio, os dispositivos não precisam ficar em linha reta entre si, tornando-o mais flexível que o infravermelho. Uma wireless LAN é uma rede local que usa tecnologias wireless para suportar a comunicação entre dispositivos. Existem alguns padrões de rede local sem fio, incluindo o IEEE b, o IEEE a e o IEEE g. O padrão IEEE b, conhecido como Wi-Fi (Wireless Fidelity), é o mais difundido para redes locais sem fio, oferecendo, teoricamente, 11 Mbps. Na prática, a taxa de transferência fica em torno de 2 Mbps. Segundo Figueiredo e Nakamura (2003, p. 21), o Wi-Fi é a tecnologia ideal para substituir infra-estrutura de cabos onde não for possível ou conveniente utilizá-la. Os padrões IEEE a e IEEE g chegam a alcançar velocidades de 54 Mbps, sendo que a principal diferença entre eles é a freqüência de operação. O a opera na freqüência de 5 GHz, enquanto que o g opera na freqüência de 2,4 GHz, mantendo dessa forma, a compatibilidade com o padrão b. Segundo Lee, Schneider e Schell (2005), uma outra categoria sem fio, com muito maior velocidade que o Wi-Fi é a WiMax (Worldwide Interoperability for Microwave Access), que permitirá redes sem fio metropolitanas, onde uma única antena atenderá uma área muito maior que a tecnologia Wi-Fi, podendo atingir até 50 quilômetros, com velocidade de até 74 Mbps. O Wimax (IEEE ) é primeiro padrão oficial para redes wireless de longa distância, aprovado em Janeiro de A tabela a seguir apresenta um resumo das tecnologias de comunicação sem fio, onde destaca-se, além das principais características, o raio de abrangência de cada uma delas. 12

25 Tabela 1. Resumo Tecnologias de Comunicação sem Fio Tecnologia Taxa de Transmissão de Dados Aplicação Raio de Alcance Bluetooth 56 Kbps 721 Kbps Redes pessoais (PAN) 10 m Wireless LAN (802.11a) Até 54 Mbps Redes locais (LAN) 25 a 100 m Wireless LAN (802.11b) Até 11 Mbps Redes locais (LAN) 50 a 100 m Wireless LAN (802.11g) Até 54 Mbps Redes locais (LAN) 100 a 150 m WiMax (802.16) Até 74 Mbps Redes metropolitanas (MAN) 50 Km Fonte: Adaptado de Sun (2005). Neste trabalho, a tecnologia de comunicação sem fio utilizada é a Wireless LAN padrão IEEE b. Essa tecnologia é suportada pelo terminal portátil de dados e está presente na estrutura de rede das empresas do Grupo MEG Tecnologias de desenvolvimento Uma das primeiras tecnologias criadas para oferecer um serviço de Web móvel foi a WAP (Wireless Application Protocol), permitindo o acesso a Internet por meio de telefones celulares e PDAs. Atualmente, existem algumas outras tecnologias que permitem não só o acesso a Internet e transferência de dados, como também o desenvolvimento de jogos e aplicativos para os dispositivos móveis. Nesta seção, serão descritas, brevemente, as principais tecnologias e plataformas de desenvolvimento para dispositivos móveis estudadas neste TCC, como: PalmOS, Symbian OS, Windows CE, SuperWaba, BREW, Visual Studio.NET e J2ME PalmOS A plataforma PalmOS é específica para PDAs. Suas aplicações nativas são escritas na linguagem C com APIs (Application Programming Interface) específicas para o sistema operacional PalmOS. Uma característica importante é a tecnologia HotSyncTM, que permite sincronizar os dados do dispositivo para um computador pessoal apenas apertando o botão HotSyncTM do dispositivo. Outra forma de transferir dados para um computador pessoal, é a utilização de conduits (Plugins escritos pelo desenvolvedor da aplicação que serão executados através do botão HotSyncTM) (PALMSOURCE 2006). 13

26 Symbian OS O Symbian OS é um sistema operacional para telefones celulares. A conectividade com computadores pessoais é suportada através de SyncML (Synchronization Markup Language), um padrão aberto de sincronização de informação independente de plataforma (SYMBIAN, 2006) Windows CE O Windows CE é um sistema operacional desenvolvido pela Microsoft Corporation para dispositivos móveis. Sua característica mais interessante é a possibilidade de escolha de quais componentes do sistema operacional serão realmente colocados no dispositivo. Isso pode ser feito através da ferramenta Platform Builder, parte do Microsoft.NET Compact Framework, ferramenta de desenvolvimento do Windows CE (MICROSOFT, 2006) SuperWaba SuperWaba é uma plataforma de desenvolvimento de software voltada para aplicações para PDAs e smartphones, derivada de um outro projeto de software livre chamado Waba da Wabasoft. Utiliza uma estrutura composta de uma máquina virtual e bibliotecas básicas e de extensão. As aplicações SuperWaba podem ser desenvolvidas utilizando-se as ferramentas de desenvolvimento para Java. Porém, o SuperWaba não implementa nenhuma parte das especificações Java e também não possui nenhum vínculo com a Sun Microsystems (SUPERWABA, 2006) BREW BREW é uma plataforma de aplicações para telefones celulares criada pela Qualcomm. Trata-se de uma camada de software que é executada sobre o hardware do dispositivo. Suas aplicações nativas podem ser escritas nas linguagens C e C++. A plataforma BREW possui suporte a J2ME, o que significa que o dispositivo terá condições de executar também aplicativos desenvolvidos nesta tecnologia (QUALCOMM, 2006) Visual Studio.NET O Visual Studio é um ambiente de desenvolvimento que permite a elaboração de diversos tipos de aplicações voltados para a plataforma.net da Microsoft, incluindo ferramentas para o desenvolvimento de aplicações para dispositivos móveis (HADDAD, 2006). 14

27 O.NET Compact Framework é um subconjunto do.net Framework, desenvolvido para oferecer a estrutura necessária ao desenvolvimento de aplicações para os dispositivos móveis, através do C# e VB.NET que acompanham o Visual Studio.NET. Segundo Campos e Branco (2003), o.net Compact Framework visa aparelhos móveis, tais como: telefones móveis, smartphones, PDAs e Pocket PCs. Porém, este ambiente de desenvolvimento só permite desenvolver aplicações para aparelhos Pocket PC que executem o sistema operacional Windows CE J2ME A plataforma Java 2 Micro Edition, da Sun Microsystems, é uma edição da plataforma Java para dispositivos tais como telefones celulares e PDAs, entre outros com baixo poder de processamento. Sua arquitetura, em três camadas (máquina virtual, configuração e perfil), permite que a plataforma possa ser implementada de acordo com os requisitos e limitações de uma grande variedade de dispositivos. Maiores detalhes dessa tecnologia são apresentados na Subseção Tecnologia Java A tecnologia Java define uma linguagem de programação e uma plataforma de software. Sua principal característica é a portabilidade, que permite que o mesmo programa seja executado em sistemas operacionais diferentes. Conforme Schmitt Junior (2004), os programas criados com a linguagem Java não geram códigos nativos do sistema operacional, ao invés disso geram código compilado, chamado de bytecode, que são interpretados através de outro programa chamado Java Virtual Machine (JVM), este por sua vez, interpreta o bytecode e gera o código binário para o sistema operacional onde está sendo executado o programa. A Figura 3 mostra como acontece a compilação e a execução de um programa Java 3. 3 Ao contrário dos compiladores tradicionais, os compiladores Java não geram arquivos executáveis, mas sim bytecode que são interpretados pelas máquinas virtuais Java. 15

28 Figura 3. Compilador e Interpretador Java Fonte: Adaptado de JavaFree (2006). Atualmente Java é uma tecnologia muito utilizada para os mais diversos tipos de aplicação, entre elas: web, desktop, servidores, mainframes, jogos, aplicações móveis, chips de identificação, etc. Com o objetivo de padronizar o desenvolvimento para os diversos tipos de aplicações, a Sun lançou a Java 2 Platform, subdividindo-a em três partes, que passaram a ser chamadas de edições de Java, sendo elas: Java 2 Platform, Standard Edition (J2SE): projetada para execução em máquinas simples de computadores pessoais a estações de trabalho; Java 2 Platform, Enterprise Edition (J2EE): com suporte interno a servlets, JSP (Java Server Pages) e XML (Extensible Markup Language), essa edição é destinada a aplicativos baseados no servidor; e Java 2 Platform, Micro Edition (J2ME): projetada para dispositivos com memória, vídeo e poder de processamento limitados. A Figura 4 ilustra a arquitetura da plataforma Java e suas edições. 16

29 Figura 4. Arquitetura da Plataforma Java Fonte: Muchow (2004) J2ME A plataforma J2ME é a edição da linguagem Java que foi projetada para dispositivos com memória, vídeo e poder de processamento limitados, variando desde eletrodomésticos à telefones celulares. Segundo Amorim (2005, p. 156), antes do surgimento da tecnologia J2ME as aplicações tinham que ser escritas na linguagem nativa de cada dispositivo usando bibliotecas proprietárias, o que as tornavam incompatíveis com dispositivos diferentes. De acordo com Sun Microsystems (2006), Java 2 Micro Edition (J2ME) é um padrão que provê um ambiente flexível para aplicações que executem em dispositivos como celulares, PDAs, TVs, eletrodomésticos entre outros. Conforme Almeida (2004), a arquitetura da plataforma J2ME permite ao desenvolvedor conhecer informações específicas sobre as diferentes famílias de dispositivos e as Application Program Interfaces (APIs) disponíveis para cada uma delas. Por estar direcionada aos dispositivos com poucos recursos de processamento e memória, a API do J2ME não oferece todos os recursos disponíveis na versão J2SE do Java. Foram feitas 17

30 remoções e algumas modificações em partes fundamentais do J2SE, para que houvesse a possibilidade de rodar a linguagem nos dispositivos que a micro edição se propõe. Figueiredo e Nakamura (2003) afirmam que as principais características do J2ME são: Modularidade e escalabilidade; Possibilidade de personalização; Possui um conjunto de tecnologias e ferramentas para o desenvolvimento de aplicação Java para os mais diversos dispositivos móveis; e Facilidade de integração com outras soluções Java, como por exemplo, J2EE para aplicações corporativas e baseadas na Web. Os autores justificam que essas características são possíveis devido à arquitetura em três camadas do J2ME (Figura 5), que é composta de: Java Virtual Machine Layer: Máquina virtual Java; Configuration Layer: Bibliotecas mínimas para uma família de dispositivos específica; e Profile Layer - Interfaces de programação (API) para uma categoria de dispositivos específica. Figura 5. Arquitetura genérica do J2ME Fonte: Adaptado de Muchow (2004) Conforme Muchow (2004), em função da diversidade de dispositivos móveis existentes e das diferentes características que cada tipo de dispositivo apresenta, os recursos dentro do J2ME 18

31 podem variar bastante. Portanto, uma única plataforma Java não seria capaz de suportar a grande variedade de dispositivos existentes, surgindo então os conceitos de configurações e perfis Configurações Conforme Barros et al. (2003), uma configuração define o menor denominador comum dos recursos da plataforma Java suportados por todos os dispositivos com características similares que pertencem a uma determinada categoria, tanto pela própria linguagem Java como pela máquina virtual, assim como suas bibliotecas de classes e APIs. Já Figueiredo (2005, p. 17) define que: Configurações são compostas de uma máquina virtual Java e um conjunto mínimo de bibliotecas de classes. Elas provem uma funcionalidade básica para um determinado conjunto de dispositivos que tem em comum algumas características tais como conectividade a redes e limitações de memória. Em resumo, Muchow (2004, p. 3) afirma que uma configuração define os recursos da linguagem Java e as bibliotecas Java básicas da JVM para essa configuração em particular. Essa padronização garante que as aplicações podem ser desenvolvidas sem se preocupar em qual dispositivo específico elas irão rodar, desde que o dispositivo tenha implementada a configuração escolhida. Há duas configurações disponíveis para a utilização do J2ME, a Connected Limited Device Configuration (CLDC) e a Connected Device Configuration (CDC). O CLDC é a uma configuração direcionada a dispositivos com maiores limitações, contendo uma API mínima para execução de aplicativos em dispositivos como celulares, smartphones, pagers e PDAs. Segundo Sallem (2003, p.12), o objetivo do CLDC é padronizar uma plataforma Java mínima de desenvolvimento de aplicações, altamente portável, para dispositivos conectados com restrições de recursos. Já o CDC é uma configuração voltada para dispositivos com maior capacidade de memória e processamento, como settop boxes digitais, screen-phones e alguns PDAs mais poderosos. Conforme Sallem (2003, p.20), o CDC é uma configuração do J2ME ligeiramente mais rica em funcionalidade do que o CLDC. Seu objetivo é atender a uma ampla gama de consumidores de dispositivos móveis e embutidos, tais como PDAs e televisores. 19

32 A seguir são listadas as características típicas dos dispositivos suportados por cada uma das configurações, conforme apresentado por Muchow (2004): Configuração de Dispositivo Conectado (CDC) 512 kilobytes (no mínimo) de memória para executar o Java; 256 kilobytes (no mínimo) de memória para alocação de memória em tempo de execução; e Conectividade de rede, largura de banda possivelmente persistente e alta. Configuração de Dispositivo Conectado Limitado (CLDC) 128 kilobytes de memória para executar o Java; 32 kilobytes de memória em tempo de execução; Interface restrita com o usuário; Baixo poder, normalmente alimentado por bateria; e Conectividade de rede, normalmente dispositivos sem fio com largura de banda baixa e acesso intermitente Perfis Os perfis funcionam como um complemento para as configurações, oferecendo uma série de APIs padrões que combinadas com alguma configuração, provém serviços mais completos para as aplicações. De acordo com Muchow (2004), um perfil pode ser considerado uma extensão de uma configuração, fornecendo as bibliotecas necessárias para o desenvolvimento de aplicativos para um tipo em particular de dispositivo. Estas bibliotecas podem ser de interface gráfica, armazenamento persistente, segurança e conectividade. Sallem (2003, p.25) complementa, afirmando que um perfil estende uma configuração e especializa-a para um determinado segmento do mercado, ou um domínio de aplicação ou um grupo particular de dispositivos. Segundo Sun Microsystems (2006), os perfis definem APIs de alto nível e podem trabalhar em conjunto com outros perfis; além disso, definem o modelo do ciclo de vida da aplicação, assim como interface com o usuário e acesso a características específicas do dispositivo. 20

33 Cada configuração do J2ME pode ter um ou mais perfis associados. Essa divisão em perfis permite que um telefone celular possua um perfil enquanto um PDA possua outro perfil. Ambos compartilhando a mesma configuração. Os perfis estão acima das configurações na hierarquia da arquitetura do J2ME e usufruem os serviços providos por ela. Conforme White e Hemphill (2002) alguns perfis associados à configuração CDC são: Foundation Profile, Personal Profile, Remote Method Invocation (RMI) Profile, e Personal Basis Profile. Os mesmos autores citam os seguintes perfis para a configuração CLDC: Mobile Information Device Profile (MIDP) e Personal Digital Assistant Profile (PDAP). Eles também consideram que os perfis Multimedia, Gaming e Telephony Profile atendem tanto a configuração CDC como CLDC. Já em Sun Microsystems (2005), alguns dos perfis definidos por White e Hemphill (2002), são considerados com pacotes adicionais. Os perfis definidos pela Sun são brevemente descritos abaixo. Os pacotes adicionais são discutidos na próxima subseção. Foundation Profile (FP): é o perfil o mais básico do CDC. Em combinação com a biblioteca fornecida pelo CDC, o Foundation Profile fornece suporte básico a aplicações, tais como o suporte à rede e o suporte à E/S (entrada e saída). Em particular, não inclui nenhum suporte para gráficos ou serviços GUI (Graphical User Interface). Personal Basis Profile (PBP): - fornece uma estrutura para construir componentes simples baseados em um conjunto de ferramentas GUI limitado baseado em AWT (Abstract Window Toolkit), suporte à execução de JavaBeans e suporte a aplicações xlet. Além disso, o Personal Basis Profile inclui toda a API do Foundation Profile. Personal Profile (PP): fornece suporte total ao AWT, suporte a applets e suporte limitado a JavaBeans. Além disso, o Personal Profile inclui toda a API do Personal Basis Profile. Mobile Information Device Profile (MIDP): trabalha sobre a configuração CLDC e habilita recursos de conectividade, armazenamento de dados local e interface gráfica com usuário. Por padrão, esse perfil carece de recursos avançados de segurança e interface gráfica, recursos que podem ser oferecidos pelos fabricantes dos dispositivos móveis, com a finalidade de minimizar essa carência. Uma aplicação que implementa o perfil MIDP é chamada de MIDlet e roda sobre a máquina virtual KVM (Kilo Virtual Machine) proposta pela configuração CLDC. 21

34 As figuras a seguir apresentam os perfis com suas respectivas configurações. A primeira de acordo com White e Hemphill (2002) e a segunda conforme Sun Microsystems (2005). Figura 6. Plataforma J2ME Fonte: White e Hemphill (2002) Figura 7. Plataforma J2ME Fonte: Sun Microsystems (2005) 22

35 Pacotes Opcionais Os pacotes opcionais estendem a plataforma J2ME, acrescentado funcionalidades às configurações e seus perfis. Criado para atender propósitos específicos das aplicações, os pacotes opcionais oferecem APIs para tecnologias existentes tais como: conexão com banco de dados, Bluetooth, multimídia, gráficos e Web Services. (SUN 2005). Os pacotes opcionais são tratados como módulos, portanto, para o desenvolvimento de aplicações, pode-se otimizar a codificação, incluindo somente os pacotes que uma aplicação realmente necessita. Esses pacotes podem ser executados com qualquer combinação de configuração com seus respectivos perfis. Cada pacote opcional é composto por uma série de classes que disponibilizam os recursos para atender determinada funcionalidade. As classes de cada pacote opcional são definidas através das JSR (Java Specification Request). A Tabela 2 apresenta uma breve descrição dos pacotes opcionais. Tabela 2. Resumo Pacotes Opcionais Pacote Opcional JSR Descrição RMI 66 Fornece um subconjunto do J2SE RMI, através de protocolos de aplicações distribuídas. As classes abstraem os detalhes de comunicações de rede. JDBC 169 Fornece um subconjunto da API JDBC 3.0, utilizada pelas aplicações Java para acessar bases de dados. AGUI 209 Suporte a tecnologia GUIs e Java 2D para fornecer gráficos e características avançados da imagem. Security 219 Fornece uma estrutura da segurança baseada no J2SE, incluindo SSL, criptografia e autenticação. Web Services 172 Fornece suporte aos serviços de Web Services. Fonte: Adaptado de Sun (2005) Máquina Virtual Java O J2ME disponibiliza duas máquinas virtuais distintas que podem ser usadas, a JVM (Java Virtual Machine) que é a máquina virtual clássica do Java e a KVM (Kilo Virtual Machine). Conforme Muchow (2004), a primeira é utilizada para a configuração CDC, tendo a mesma especificação da JVM da versão J2SE. Já a KVM, foi desenvolvida pela Sun como sendo uma 23

36 implementação de referência de uma máquina virtual, projetada para manipular considerações especiais dos dispositivos de recurso restrito, destinada para a configuração CLDC. Segundo Barros et al. (2003), a Máquina Virtual Java é uma máquina abstrata que é implementada através de sua emulação em um software contido em uma máquina real. As instruções nos programas Java são compiladas para se obter os bytecodes, que serão executados em qualquer processador e sistema operacional que possua um interpretador Java. Este mesmo autor define KVM como: A Kilo Virtual Machine é uma nova implementação da máquina virtual clássica, obtendo o melhor resultado para que se consiga o efeito desejado que é o uso em dispositivos de recursos limitados, para isso ela teria que ser pequena, mas também deveria possuir os principais aspectos da linguagem Java. A KVM aceita o mesmo conjunto de bytecodes e o mesmo formato para o arquivo.class que a máquina virtual clássica, a sua principal tarefa é carregar esses arquivos e executar os bytecodes neles presentes. Algumas das características da KVM citadas por Muchow (2004) são: De 40 a 80 kilobytes de memória; De 20 a 40 kilobytes de memória dinâmica; e Pode ser executa em processadores de 16 bits, com freqüência de apenas 25 MHz. 2.3 Trabalhos Relacionados Esta seção tem o objetivo de apresentar soluções similares à proposta neste TCC, com o intuito de levantar as características relevantes de cada ferramenta, bem como identificar a tecnologia e a plataforma de desenvolvimento CLOG O aplicativo CLOG foi desenvolvido pela empresa Caladan Software 4 especialmente para a Ledervin Indústria e Comércio para automação de controles logísticos de inventário e expedição. É uma solução baseada em computação móvel, desenvolvida para a plataforma Palm, tendo como requisitos PalmOS 3.0 ou versões posteriores. 4 Mais detalhes disponíveis em: 24

37 A tela inicial do aplicativo CLOG (Figura 8a), apresenta as principais funções do sistema, dentre elas, a função de expedição que interessa a esse TCC será descrita abaixo. A função de expedição mostra inicialmente uma lista dos pedidos (Figura 8b). Após selecionar o pedido desejado o aplicativo mostra a lista de itens para separação (Figura 8c). A separação consiste em ler o código do produto e do lote conforme especificado para o item, seguido do código da caixa ou pallet e do peso líquido (Figura 8d). Após uma leitura correta o aplicativo marca a opção já concluída. (a) (b) (c) (d) Figura 8. Telas do Sistema CLOG Este aplicativo está programado para capturar a leitura de código de barras nos equipamentos com leitor laser integrado. Para garantir o sucesso dessa funcionalidade, todo código de barras utilizado pela aplicação recebeu um identificador normalizado pela Ledervin Indústria e Comércio. A Tabela 3 apresenta o padrão adotado pela empresa. Tabela 3. Padronização do Código de Barras - Ledervin Indústria e Comércio Identificado Identificação Código X Código do Material 5 a 12 caracteres numéricos. Y Código do Lote 5 a 10 caracteres alfanuméricos. Z Código da Caixa 10 caracteres numéricos. W Kg Líquido 7 dígitos onde os 4 primeiros representam a parte inteira e os 3 últimos a parte fracionária. E Código do Pallet 6 caracteres numéricos. Fonte: Adaptado de Caladan (2006). 25

38 2.3.2 InvPalm e PalmPat InvPalm é um aplicativo para contagem de estoques. Permite o inventário separado por loja, contagem automática através de leituras sucessivas ou informando-se a quantidade. Já o PalmPat é um sistema de inventário patrimonial, com suporte a importação e exportação de dados com outros sistemas. Suporta formatos de dados texto ASCII e compatível com planilhas MS-Excel. Ambos os sistemas permitem a utilização do leitor laser para código de barras embutido nos equipamentos da Symbol série SPT. Os sistemas foram desenvolvidos através da ferramenta Satellite Forms Mobile AppDesigner para uso em equipamento portátil da plataforma PalmOS 3.1 ou posterior. As figuras abaixo apresentam algumas telas dos sistemas, sendo a Figura 9 referente ao InvPalm e a Figura 10 referente ao PalmPat. Figura 9. Telas do sistema InvPalm Fonte: Caladan (2006). Figura 10. Telas do sistema PalmPat Fonte: Caladan (2006). 26

39 Uma das características relevantes dos sistemas acima descritos em relação ao projeto deste TCC é a utilização do leitor de código de barras, que vem integrado em alguns modelos de equipamentos. Tal relevância se dá pelo fato de que o equipamento utilizado neste TCC, também possui o recurso de leitura de código de barras Considerações Através da pesquisa realizada em busca de soluções similares, conclui-se que existem algumas opções já disponíveis no mercado. Considerando-se que a aplicação a ser construída atende a requisitos muito particulares às empresas do Grupo MEG, não foram encontradas ferramentas com as mesmas especificações. No entanto, pode-se afirmar que auxiliaram no projeto fornecendo novas idéias para o desenvolvimento do mesmo. 27

40 3 DESENVOLVIMENTO Este capítulo refere-se às etapas pertinentes ao desenvolvimento do projeto. Inicialmente, é caracterizado o cenário atual do processo de expedição nas empresas do Grupo MEG. Após, é descrito o contexto da aplicação e apresentada a modelagem do sistema. Na seqüência são discutidos aspectos referentes à implementação, testes e validação do sistema. 3.1 CENÁRIO ATUAL Atualmente, o processo de expedição das empresas do Grupo MEG envolve quatro funcionários, os quais atendem a dois pátios de expedição. O primeiro pátio, denominado de Local de Embarque 1, é reservado para as empresas Motomil e Garthen. O segundo, chamado de Local de Embarque 2, atende exclusivamente a empresa Eletroplás. Existe ainda um terceiro pátio em construção que terá maior capacidade de armazenamento. No Local de Embarque 1, o funcionário A confere a nota fiscal com as quantidades que devem ser separadas. No Local de Embarque 2, o funcionário B realiza o mesmo processo. Os funcionários C e D são responsáveis por separar, carregar e conferir (em cima do veículo de transporte) as mercadorias. Ambos atuam nos locais de embarque 1 e 2, realizando suas atividades com o auxílio do romaneio de separação e embarque 5, gerado a partir da nota fiscal. A quantidade de pessoas envolvidas nesta etapa do processo pode variar. Em determinados momentos, são requisitados funcionários de outros setores, como, por exemplo, do setor de produção, para auxiliar nas operações de conferência e carregamento. A conferência é realizada de forma manual, visualizando item a item. Para separação dos produtos, são utilizadas empilhadeiras e carrinhos de circulação. Na separação, é adotado o critério primeiro que entra, primeiro que sai. Teoricamente, os produtos mais antigos devem sair primeiro, mas nem sempre os funcionários conseguem aplicar esse conceito, devido à distribuição dos produtos em seus locais de armazenamento. 5 O romaneio é um documento de embarque que lista todas as mercadorias embarcadas, ou todos os componentes de uma mesma mercadoria. 28

41 A seguir é apresentado um resumo do fluxo de operações do processo de expedição: 1. O escritório emite a nota fiscal e gera o romaneio de separação e embarque; 2. O romaneio é entregue aos funcionários responsáveis pela separação; 3. O separador seleciona os itens de acordo com o critério FIFO (First In, First Out); 4. O separador/carregador remove o(s) item(s) do armazém (Garthen, Eletroplás e Motomil) e encaminha(m) à expedição; 5. O conferente valida as quantidades e características dos itens separados; 6. O carregador realiza a última conferência de quantidades já em cima do caminhão; e 7. Depois de tudo conferido, encerra-se o processo de expedição. De acordo com o cenário atual, a aplicação desenvolvida permitirá agilizar o processo de expedição, reduzindo o tempo gasto nos processos associados. Para tanto, estima-se a utilização de cinco coletores de dados distribuídos nos locais de embarque e no almoxarifado. 3.2 CARACTERIZAÇÃO DO DOMÍNIO DA APLICAÇÃO A aplicação interage (através de consultas e atualizações) com a base de dados dos sistemas atualmente utilizados pelas empresas do Grupo MEG: IBF Task e IBF PCP. Para um maior entendimento, estes sistemas serão brevemente descritos a seguir. O IBF Task é um sistema que integra as atividades administrativas e gerenciais das empresas do Grupo MEG. É a partir dele que são cadastrados os pedidos de venda, os quais dão origens às notas fiscais. Entre a etapa de cadastramento dos pedidos e a geração de notas fiscais, é acionado o controle de produção, que é gerenciado por outro sistema. O IBF PCP é o sistema responsável pelo controle de produção. Nele são cadastradas as ordens de produção para os equipamentos que constam nos pedidos cadastrados através do IBF Task. Esse sistema é o responsável pela geração do número de série dos produtos. A padronização do número de série foi definida pelas empresas do grupo conforme apresentado no Anexo II. Os sistemas IBF Task e IBF PCP compartilham a mesma base de dados. O modelo ER (Entidade Relacionamento) pode ser verificado no Anexo III. Nele constam apenas as tabelas relevantes para esse projeto. 29

42 Para melhor compreensão do funcionamento do sistema (apresentado a seguir na Subseção 0), é importante destacar que os dados iniciais de entrada (número e série da nota fiscal) são extraídos do Romaneio de Separação e Embarque 6 (Anexo IV), que deve estar de posse do operador do sistema. Por sua vez, o romaneio é montado com os dados da nota fiscal, ficando esta, por medida de segurança, arquivada no setor administrativo até o momento do embarque dos equipamentos. O modelo de nota fiscal utilizado por uma das empresas do Grupo MEG pode ser visualizado no Anexo V Integração com o sistema atual Conforme mencionado anteriormente, o sistema desenvolvido interage com a base de dados dos sistemas IBF Task e IBF PCP. Para garantir a integridade dos dados a serem atualizados, o aplicativo J2ME utiliza os recursos de controle de transações providos pelo SGBD (Sistema de Gerenciamento de Banco de Dados). Além da integridade dos dados, é importante garantir que as informações atualizadas estejam corretas. Para tanto, o sistema foi desenvolvido de forma a implementar dentro da sua rotina de validação, a verificações dos seguintes critérios: Itens duplicados no mesmo processo de leitura de código de barras; Equipamento não pertencente a nota fiscal informada; Equipamento já associado a alguma nota fiscal; e Quantidade de números de série lidos deve ser compatível com a quantidade de equipamentos cadastrado na nota fiscal. 3.3 ARQUITETURA DO SISTEMA Com base nas limitações da tecnologia J2ME, inicialmente, foram previstas duas alternativas arquiteturais para o sistema, sendo elas: Arquitetura 1: O aplicativo J2ME ser responsável pelo processamento, fazendo consultas no servidor de banco de dados e obtendo os resultados (Figura 11); e 6 Documento de embarque que descrimina todas as mercadorias embarcadas, ou todos os componentes de uma mesma mercadoria. 30

43 Arquitetura 2: O aplicativo J2ME não ser responsável pelo processamento, ficando, desta forma, encarregado de disparar a execução de um aplicativo servidor, que por sua vez realizará todo processamento, retornando ao aplicativo J2ME os resultados obtidos (Figura 12). Figura 11. Arquitetura Proposta 1 Figura 12. Arquitetura Proposta 2 Conforme descrito na Subseção 1.1.2, a arquitetura considerada mais adequada para esse sistema foi a Arquitetura 1. Chegou-se a essa conclusão após a análise de alguns fatores descritos na Tabela 4. 31

44 Tabela 4. Características das Arquiteturas Arquitetura 1 Arquitetura 2 Sistema Baseado em um único sistema hospedado no aplicativo móvel Baseado em um sistema hospedado no aplicativo móvel e outro no servidor (web service) Manutenção Somente em um sistema Pode ser necessária em dois sistemas Regras de Implementada no aplicativo móvel Implementada no aplicativo servidor negócios Acesso ao banco Implementado no aplicativo móvel, Implementado no aplicativo servidor de dados através do pacote adicional (JSR-169) Processamento Realizado no dispositivo móvel Realizado no equipamento utilizado como servidor Com a utilização de um web service, seria possível retirar do dispositivo móvel quase toda a necessidade de processamento, cabendo a este somente interagir com o usuário através da sua interface. Porém, os equipamentos utilizados neste projeto possuem capacidade de processamento suficiente para atender os processos associados à aplicação. Essa característica, associada ao suporte oferecido pelo J2ME, faz da Arquitetura 1 a melhor alternativa para o sistema proposto e, por isso, esta foi a arquitetura escolhida. 3.4 FUNCIONAMENTO DO SISTEMA Com o objetivo de proporcionar ao leitor desta monografia o melhor entendimento do uso do sistema, nesta sessão, são apresentados os passos para a sua utilização, baseados nos desenhos das telas desenvolvidas, conforme segue. Para iniciar o sistema, o usuário deverá acessá-lo através de atalho na tela principal ou no menu Iniciar do dispositivo (Figura 13). Em seguida, deverá ser efetuado o login (Figura 14). 32

45 Figura 13. Atalho do sistema na tela principal do dispositivo Figura 14. Tela de login Tendo efetuado o login com sucesso, será exibida a tela principal do sistema com as opções disponíveis de acordo com o nível de acesso do usuário (Figura 15). Nessa tela, o usuário deverá selecionar a opção Expedição, sendo então apresentada a tela de entrada de dados (Figura 16). 33

46 (a) (b) Figura 15. Tela principal: (a) Nível Administrador; (b) Nível Operador Figura 16. Tela de entrada de dados Nota Fiscal Para efetuar o preenchimento dos dados dessa tela, o usuário deverá estar de posse do romaneio. Nele estarão registrados, além de outras informações, o número e a série da nota fiscal. Esses dados poderão ser informados pelo teclado do dispositivo ou através da leitura do código de barras que vem no romaneio. Preenchidos esses campos, o sistema preencherá o campo cliente e aguardará a confirmação do usuário. Após a confirmação será apresentada a tela para entrada dos números de série (Figura 17). 34

47 Figura 17. Tela de entrada de dados Número de Série Os números de série poderão ser informados através do leitor de código de barras ou pelo teclado. Quando cadastrados através do leitor de código de barras, os números de série serão transferidos para a tabela de dados logo após a sua leitura. Para os que forem cadastrados pelo teclado, o usuário deverá selecionar a opção incluir. Cadastrados os números de série, o usuário deve selecionar a opção encerrar. O sistema apresentará uma mensagem validando a operação ou mensagens de inconsistências se houverem problemas. O usuário com perfil de Administrador poderá ter acesso à tela de configurações (Figura 18). Nessa tela serão definidos parâmetros como time-out e servidor. No parâmetro time-out, deverá ser informado o tempo em segundos para que o sistema solicite novamente o login do usuário quando o sistema estiver ocioso. O parâmetro servidor será utilizado para definir o servidor de banco de dados que deverá ser acessado. Figura 18. Tela de configuração dos parâmetros do sistema 35

48 3.5 MODELAGEM DO SISTEMA A modelagem do sistema foi realizada utilizando a UML (Unified Modeling Language), com apoio da ferramenta Enterprise Architect na diagramação e na especificação de requisitos. Foram elaborados diagramas de Caso de Uso, Classes de Negócio, Classes de Projeto e Seqüência. Nesta seção é apresentada parte da descrição dos diagramas, ilustrando funções de maior importância para o sistema. A descrição integral está contida no Apêndice A Levantamento de Requisitos O levantamento de requisitos corresponde à etapa de compreensão do problema aplicada ao desenvolvimento de software. Segundo Larman (2000), os requisitos são uma descrição das necessidades do sistema que se pretende construir, nesta fase o objetivo é identificar e documentar o que é realmente necessário, com uma comunicação clara que seja compreendida ao cliente e as pessoas envolvidas ao projeto. Com base na análise realizada no processo aplicado pelas empresas do Grupo MEG e em entrevistas com consultores e operadores do sistema, os seguintes requisitos foram especificados: Requisitos Funcionais RF01: O sistema deve permitir autenticação de usuário; RF02: O sistema deve permitir ao usuário informar o número e a série da nota fiscal através do leitor de código de barras ou do teclado; RF03: O sistema deve permitir ao usuário informar o número de série dos equipamentos através do leitor de código de barras ou do teclado; RF04: O sistema deve permitir a exclusão de determinado número de série da lista de itens a serem validados; RF05: O sistema deve consultar a base de dados do sistema IBF Task; RF06: O sistema deve validar os dados fornecidos; RF07: O sistema deve atualizar as informações processadas na base de dados do sistema IBF Task; 36

49 RF08: O sistema deve permitir o cancelamento da operação; e RF09: O sistema deve permitir o cadastro e a atualização de parâmetros de configuração Requisitos Não Funcionais RNF01: O sistema deve ser executado em um coletor portátil de dados, modelo Symbol MC3000 ou modelos compatíveis; RNF02: O sistema deve ser implementado utilizando a tecnologia J2ME; RNF03: O sistema deve implementar controle de acesso por níveis (administrador do sistema/ operador do sistema); RNF04: A autenticação dos usuários deve ser implementada utilizando a API Security do J2ME; e RNF05: Todas as operações do sistema devem ficar registradas Regras de Negócio RN01: Somente poderão ser excluídos números de série que ainda não foram validados; RN02: O sistema deverá exigir nova autenticação de usuário quando o aplicativo ficar ocioso por um determinado período de tempo; RN03: O tempo de inatividade e todos os demais parâmetros de configuração do sistema devem ser acessados somente por usuários com nível de Administrador; e RN04: A autenticação dos usuários deverá ser realizada através de consulta à base de dados do sistema IBF Task Restrições Além dos requisitos e regras acima mencionados, foram identificadas algumas limitações do sistema, como: 37

50 O sistema não suporta a leitura de etiquetas inteligentes (Padrão RFID - Radio Frequency Identification) 7 ; e A aplicação está voltada para o processo de expedição de equipamentos, excluindo-se, portanto, peças em geral que por ventura venham a ser comercializadas pelas empresas do Grupo MEG; Projeto do Sistema Nesta seção serão apresentados os diagramas de Caso de Uso e Classe de Negócio, Classe de Projeto e Seqüência Diagrama de casos de uso Um caso de uso descreve uma seqüência de ações que representam um cenário principal e os cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema, através de interações com atores (MELO, 2004). Os diagramas de caso uso deste projeto estão divididos em três pacotes: Controle de Acesso, Operações e Configurações. Representados respectivamente pelas figuras que seguem. Figura 19. Diagrama de Caso de Uso Pacote Controle de Acesso 7 Diferentemente do feixe de luz utilizado no sistema de código de barras para captura de dados, essa tecnologia utiliza a freqüência de rádio. Essa tecnologia facilita o controle do fluxo de produtos por toda a cadeia de suprimentos de uma empresa, permitindo o seu rastreamento desde a sua fabricação até o ponto final da distribuição. Tal tecnologia utiliza as Etiquetas Inteligentes etiquetas eletrônicas com um microchip instalado que são colocadas nos produtos. 38

51 Figura 20. Diagrama de Caso de Uso Pacote Operações Figura 21. Diagrama de Caso de Uso Pacote Configurações Diagrama de classes de negócio Os diagramas de classe descrevem as classes que formam a estrutura do sistema e suas relações. As relações entre as classes podem ser associações, agregações ou heranças. As classes possuem, além de um nome, os atributos e as operações que desempenham para o sistema. A Figura 22 apresenta o modelo de classes de negócio, que ilustra as entidades participantes do domínio do sistema e seus respectivos relacionamentos. 39

52 Figura 22. Diagrama de Classes de Negócio Diagrama de classes de projeto Os diagramas de classes de projeto foram elaborados seguindo o padrão MVC (Model, View e Controller). Essa estrutura em três camadas permite maior portabilidade de código, proporciona maior organização e facilita futuras manutenções no sistema. A seguir são apresentadas algumas classes de projeto, correspondentes a visão de implementação das classes de negócio. As figuras a seguir representam os diagramas de classe de projeto dos casos de uso UC Cadastra Dados e UC Valida Dados, respectivamente. 40

53 Figura 23. Diagrama de classe projeto Cadastra Dados 41

54 Figura 24. Diagrama de classe de projeto Valida Dados Diagrama de seqüência Os diagramas de seqüência foram elaborados a partir dos casos de uso, evidenciando os passos para a execução das atividades e também a troca de mensagens entre os diversos componentes do sistema. A Figura 25 apresenta o diagrama de seqüência referente ao caso de uso UC Cadastra Dados, onde o usuário seleciona a opção Expedição do menu principal, o sistema exibe a 42

55 tela de Expedição (Nota Fiscal). O usuário preenche os campos disponíveis na tela e solicita a confirmação. O sistema valida os dados preenchendo o campo cliente. O usuário verifica o cliente e confirma a operação. O sistema exibe a tela de Expedição (Número de Série). O usuário informa os números de série e solicita a validação. Neste momento, o sistema chama a rotina de validação, que é descrita no caso de uso UC Valida Dados e sua seqüência representada na Figura 26. Figura 25. Diagrama de seqüência Cadastra Dados Figura 26. Diagrama de seqüência Valida Dados 43

56 3.6 IMPLEMENTAÇÃO A etapa de implementação compreende a codificação do projeto do sistema, através da tecnologia Java, consolidando o projeto elaborado em um produto final. A aplicação foi desenvolvida dentro dos padrões da edição J2ME, com base nas especificações da configuração CDC e do perfil Personal Profile versão 1.0. Sua codificação foi realizada na ferramenta WebSphere Studio Device Developer 5.5 (WSDD) 8. Optou-se por essa ferramenta por ela oferecer recursos da tecnologia J2ME sem a necessidade de se adicionar plugins, além de prover praticamente todos os recursos encontrados em outras plataformas de desenvolvimento como, por exemplo, o Eclipse. A vantagem da utilização do WSDD é a criação de projetos para configuração e perfil específicos, restringindo a codificação às limitações de cada configuração e perfil. Inicialmente, foi adotada a plataforma Eclipse, um excelente ambiente de desenvolvimento que provê recursos como controle de projetos, compilação, depuração e execução de programas Java. Sua característica extensível possibilita a instalação de plugins que auxiliaram em atividades específicas dentro do desenvolvimento do trabalho, oferecendo também recursos de ajuda para montar projetos com todas as restrições necessárias a um projeto Java, embora isso ainda não se aplica à configuração CDC. Outro ambiente de desenvolvimento testado foi o NetBeans, uma ferramenta que proporciona maior agilidade na programação, principalmente na criação das interfaces, onde podese utilizar componentes visuais, de forma flexível e facilitada, por meio de comandos do mouse arrastar / soltar. O NetBeans oferece suporte à configuração CDC através da instalação do pacote NetBeans Mobility Pack for CDC. Porém, os recursos utilizados por ele ainda não são suportados pela maioria das máquinas virtuais para J2ME. A codificação seguiu os padrões do projeto, isso significa que cada classe de interface possui sua classe de negócios e, quando necessário, possui também sua classe de persistência. As classes implementadas foram divididas em pacotes conforme apresentado na Figura IDE para plataforma J2ME distribuída pela IBM gratuitamente para avaliação em um período de 90 dias. 44

57 Figura 27. Estrutura de pacotes da aplicação Os pacotes view, business e dao representam respectivamente as camadas de interface, controle e persistência, cada qual contendo as classes correspondentes às suas finalidades. O pacote bean é uma coleção de objetos em que estão as classes de cada objeto criado pela aplicação, excluindo-se os objetos da linguagem de programação. Por fim, tem-se o pacote util, que implementa classes genéricas que não se encaixam em nenhum dos outros pacotes e podem servir para qualquer uma outra classe. Além das operações que ficam evidentes à sua existência, pelas opções disponíveis nas telas, foi implementada uma rotina que fica transparente para o usuário e que registra todas as operações executadas por ele. Essa rotina foi codificada dentro do pacote util e, a cada momento que um método de manipulação de dados do pacote dao é executado, são inseridos registros na tabela de logs, com informações como data, hora, usuário e o comando executado. Embora tenha se buscado atender rigorosamente todos os requisitos levantados durante o projeto, não foi possível atingir esse objetivo plenamente, sendo que dois requisitos foram atingidos apenas parcialmente, sendo eles o RF02 e o RNF04. No segundo requisito funcional (RF02), estava previsto que o sistema deveria permitir ao usuário informar o número e a série da nota fiscal através do leitor de código de barras ou do teclado. Porém, a leitura do código de barras que identificaria a nota fiscal não foi realizada, pois essa funcionalidade exigiria a definição de um padrão de identificação único e isso não foi realizado ainda pelo Grupo MEG. Algumas alternativas poderiam ser adotadas no sistema, como por exemplo, a utilização de x caracteres para cada campo. Mas, como a própria empresa não implementou essa metodologia em seus procedimentos internos, não resolveria muito aplicá-la ao software. 45

58 O quarto requisito não funcional (RNF04), que previa que a autenticação dos usuários deveria ser implementada utilizando a API Security do J2ME, não foi atendido pois, atualmente, a senha do usuário do sistema já está sendo criptografada através de uma função do banco de dados. Como o sistema desenvolvido apenas consulta o usuário na base de dados para permitir que o mesmo possa utilizar o sistema, não tem como se aplicar a criptografia da API Secutiry. A sua utilização só seria possível se, no momento do cadastramento do usuário (Sistema IBF Task), fosse utilizada a mesma API para criptografar a senha. Ou, para não alterar a estrutura do sistema atual, poderia ser desenvolvida uma aplicação servidora que recebesse a senha criptografada do aplicativo móvel e se encarregasse de descriptografá-la e, juntamente com o login do usuário, consultasse-os no banco de dados, retornando para o aplicativo móvel o resultado da consulta. Outra possibilidade seria o próprio aplicativo móvel inserir os seus usuários. Porém, isso implicaria em elementos duplicados na tabela de usuários ou a criação de uma nova tabela específica para usuários do aplicativo móvel. Como todas as opções implicariam em modificações que fogem do escopo desse projeto e, atualmente, a senha é tratada por uma função do banco de dados, optou-se por utilizar-se esse mesmo recurso no momento da autenticação do usuário. O sistema foi projetado seguindo uma arquitetura cliente-servidor, com a aplicação J2ME armazenada no dispositivo responsável por interagir com o usuário (classes do pacote view), tratar os dados (classes do pacote business) e comunicar-se com o servidor de banco de dados (classes do pacote dao). Essa comunicação com um servidor de banco de dados não é originalmente suportada pelo J2ME. A API padrão do CDC/Personal Profile, não inclui nenhuma API de acesso a dados, mas permite a inclusão de um pacote opcional de JDBC (Java Database Connectivity) definido pela JSR-169. Entretanto, ainda existem alguns inconvenientes na utilização de pacotes adicionais, pois nem todas as máquinas virtuais oferecem suporte para os mesmos. Apesar da aplicação J2ME basear-se na arquitetura cliente-servidor, o que torna necessário estar conectada à rede para comunicação com o servidor de banco de dados, algumas de suas funcionalidades continuam operando mesmo com a perda da conexão, como por exemplo, a leitura dos códigos de barras contendo a identificação dos números de série, sendo necessário apenas reestabelecer a conexão no momento em que for solicitada a validação dos dados. Alguns fatores relevantes que puderam ser percebidos na fase de implementação estão relacionados a uma das mais marcantes características do Java, a portabilidade, a qual permite que o mesmo programa seja executado em sistemas operacionais diferentes. 46

59 Durante a pesquisa bibliográfica, verificou-se que a padronização estabelecida na edição J2ME garante que as aplicações possam ser desenvolvidas sem se preocupar em qual dispositivo específico elas irão rodar, desde que ele tenha implementada a configuração escolhida. Entretanto, na prática, utilizando recursos diversos da programação Java para J2ME, pôde ser observado, que, pelo menos, para CDC / Personal Profile, essa teoria ainda não é válida. Isso pôde ser comprovado por meio dos testes realizados com três máquinas virtuais diferentes: a Jeode, a J9 e a CrEme. A Sun, até o presente momento, ainda não disponibilizou nenhuma JVM para configuração CDC e perfil Personal Profile. Inicialmente foi adotada a J9 da IBM, por ter um ambiente de desenvolvimento que trabalha em cima das suas características (o WSDD). Porém, no momento em que foi necessária a instalação de pacotes externos, para acesso ao banco de dados, por exemplo, ela apresentou algumas incompatibilidades. Esses erros só puderem ser detectados quando a aplicação estava rodando no dispositivo físico, pois no ambiente de desenvolvimento ela funcionava corretamente. Optou-se então pela Jeode, uma máquina virtual Java oferecida pelo fabricante de um dos modelos de equipamentos utilizados nos testes. Essa máquina virtual apresentou problemas de interpretação de código. Alguns trechos de código que foram escritos no WSDD, originalmente para a J9, dentro dos padrões das especificações do Java (J2ME / CDC / Personal Profile), não foram reconhecidos pela Jeode. Essa incompatibilidade foi identificada, por exemplo, nos comandos de leitura e de gravação de arquivos. Como a Jeode também não oferece nenhuma ferramenta de desenvolvimento própria, tornou-se inviável a sua utilização, pois programar em um ambiente que não ofereça suporte para a JVM, apenas consultando a sua documentação, tornaria o processo de desenvolvimento muito lento. A terceira JVM testada foi a CrEme, que apesar de não ter uma IDE própria, não apresentou nenhuma incompatibilidade com os códigos escritos no WSDD e ainda reconheceu os comandos para adicionar os pacotes externos. 3.7 TESTES E VALIDAÇÃO DO SISTEMA A etapa de testes e validação do sistema foi subdividida em duas etapas, sendo que a primeira ocorreu em paralelo à implementação, com aplicação do teste unitário e do teste de integração, e a segunda foi realizada após a implementação, compreendendo os testes de sistema e de aceitação. 47

60 O teste unitário é uma das fases do processo de teste cujo objetivo é encontrar falhas de funcionamento dentro de uma pequena parte do sistema. O teste de integração objetiva encontrar falhas provenientes da integração interna dos componentes do sistema. Esses testes foram aplicados pelo próprio desenvolvedor, avaliando cada classe do sistema isoladamente, seus métodos e a troca de mensagens entre elas. O teste de sistema tem por objetivo a execução do sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas. Eles deveriam ser realizados em condições similares àquelas que um usuário utilizaria no seu dia-a-dia de manipulação do sistema, porém, devido à natureza deste projeto, ele também foi aplicado pelo desenvolvedor. Já o teste de aceitação foi realizado por um grupo de usuários finais do sistema, simulando operações de rotina do sistema de modo a verificar se seu comportamento estava de acordo com os requisitos levantados na elaboração do projeto. Um dos testes realizados no dispositivo móvel pode ser observado na seqüência de figuras demonstradas a seguir. Figura 28. Tela de Login Dispositivo Móvel 48

61 A Figura 28 apresenta a tela de Login do sistema. Nesse teste utilizou-se o usuário gerente, que possui perfil de administrador. Figura 29. Tela de Opções (Menu) Dispositivo Móvel Na Figura 29, pode ser observado o menu do sistema. Como o usuário que logou no sistema possui o perfil de administrador, todas as opções do menu estão disponíveis. 49

62 Figura 30. Tela de Expedição (Nota Fiscal) Dispositivo Móvel Na tela de preenchimento dos dados referentes a nota fiscal (Figura 30), utilizou-se uma nota fiscal cadastrada na base de dados de testes. O usuário informou os campos número da nota fiscal e série. O campo com o nome da empresa, neste exemplo preenchido como Empresa Teste, foi preenchido pelo sistema, consultando no banco de dados o cliente da nota fiscal informada. Com todos os dados preenchidos, o usuário selecionou a opção confirmar, sendo exibida a tela de leitura de números de série, apresentada na Figura

63 Figura 31. Tela de Expedição (Número de Série) Dispositivo Móvel A nota fiscal selecionada possuía apenas um tipo de produto com cinco unidades. Foram efetuadas as leituras dos códigos de barras contendo os números de série de cada equipamento. Na Figura 31, não pode ser visualizado o botão de confirmação, devido as dimensões da tela. No momento dos testes utilizou-se a barra de rolagens para selecionar a opção Encerrar que dispara os métodos internos de validação dos dados. Neste exemplo, a validação foi efetuada com sucesso. 51