UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Rafael Pacheco...
93
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
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Rafael Pacheco...
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
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
ii
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.
iii
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.
iv
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................vi LISTA DE FIGURAS...............................................................................vii LISTA DE TABELAS............................................................................... ix
RESUMO.....................................................................................................x
ABSTRACT................................................................................................xi 1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 2 1.1.1 Formulação do Problema................................................................................. 2 1.1.2 Solução Proposta ............................................................................................... 4 1.2 OBJETIVOS ........................................................................................................ 5 1.2.1 Objetivo Geral ................................................................................................... 5 1.2.2 Objetivos Específicos ........................................................................................ 5 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA ........................................................8 2.1 COMPUTAÇÃO MÓVEL ................................................................................. 8 2.1.1 Dispositivos móveis ........................................................................................... 9 2.1.2 Tecnologias de conexão sem fio ..................................................................... 11 2.1.3 Tecnologias de desenvolvimento.................................................................... 13 2.2 TECNOLOGIA JAVA...................................................................................... 15 2.2.1 J2ME ................................................................................................................ 17 2.3 TRABALHOS RELACIONADOS .................................................................. 24 2.3.1 CLOG............................................................................................................... 24 2.3.2 InvPalm e PalmPat ......................................................................................... 26 2.3.3 Considerações .................................................................................................. 27
3 DESENVOLVIMENTO ......................................................................28 3.1 CENÁRIO ATUAL ........................................................................................... 28 3.2 CARACTERIZAÇÃO DO DOMÍNIO DA APLICAÇÃO ........................... 29 3.2.1 Integração com o sistema atual...................................................................... 30 3.3 ARQUITETURA DO SISTEMA..................................................................... 30 3.4 FUNCIONAMENTO DO SISTEMA .............................................................. 32 3.5 MODELAGEM DO SISTEMA........................................................................ 36 3.5.1 Levantamento de Requisitos .......................................................................... 36 3.5.2 Projeto do Sistema .......................................................................................... 38 3.6 IMPLEMENTAÇÃO ........................................................................................ 44 3.7 TESTES E VALIDAÇÃO DO SISTEMA....................................................... 47
4 CONCLUSÕES ....................................................................................52
v
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................54
A MODELAGEM DO SISTEMA..........................................................57 A.1 CASOS DE USO ................................................................................................ 57 A.1.1 Pacote 01: Controle de acesso ........................................................................ 57 A.1.2 Pacote 02: Operações...................................................................................... 59 A.1.3 Pacote 03: Configurações ............................................................................... 63 A.2 PROTÓTIPOS DAS TELAS DO SISTEMA.................................................. 64 A.3 DIAGRAMA DE CLASSES............................................................................. 67 A.3.1 Diagrama de classes de negócio ..................................................................... 67 A.3.2 Diagrama de classes de projeto...................................................................... 67 A.4 DIAGRAMAS DE SEQUÊNCIA..................................................................... 72
vi
LISTA DE ABREVIATURAS
.NET Dot NET API Application Programming Interface AWT Abstract Window Toolkit BREW Binary Runtime for Wireless Environment CDC Connected Device Configuration CE Compact Edition CLDC Connected Limited Device Configuration CPU Central Processing Unit FP Foundation Profile GUI Graphical User Interface J2EE Java 2 Enterprise Edition J2ME Java 2 Micro Edition J2SE Java 2 Standard Edition JSP Java Server Pages JSR Java Specification Request JVM Java Virtual Machine KVM Kilo Virtual Machine LAN Local Area Network MAN Metropolitan Area Network MIDP Mobile Information Device Profile MS Microsoft PAN Personal Area Network PBP Personal Basis Profile PC Personal Computer PDA Personal Digital Assistants PDAP Personal Digital Assistant Profile PP Personal Profile RAM Random Access Memory RFID Radio-Frequency IDentification RMI Remote Method Invocation SGBD Sistema de Gerenciamento de Banco de Dados TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí VB Visual Basic WAP Wireless Application Protocol Wi-Fi Wireless Fidelity WiMax Worldwide Interoperability for Microwave Access XML Extensible Markup Language
vii
LISTA DE FIGURAS
Figura 1. Coletor Portátil MC3000 ......................................................................................................4 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 1 ......................................................................................................31 Figura 12. Arquitetura Proposta 2 ......................................................................................................31 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
viii
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
ix
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
x
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í, 2007. 91 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í, 2007. 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.
xi
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.
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 e-mails, 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.
2
1.1 PROBLEMATIZAÇÃO
1.1.1 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 MEG1, formado pela fusão das
empresas Motomil, Eletroplas e Garthen2. 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: http://www.garthen.com.br
3
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.
4
Figura 1. Coletor Portátil MC3000
Fonte: Symbol (2006).
1.1.2 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
5
1.2 OBJETIVOS
1.2.1 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.
1.2.2 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
6
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
7
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.
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:
9
• 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.
2.1.1 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
10
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,
11
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.
2.1.2 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 infra-
estrutura 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 infra-
estrutura 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”.
12
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
802.11b, o IEEE 802.11a e o IEEE 802.11g.
O padrão IEEE 802.11b, 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 802.11a e IEEE 802.11g chegam a alcançar velocidades de 54 Mbps,
sendo que a principal diferença entre eles é a freqüência de operação. O 802.11a opera na
freqüência de 5 GHz, enquanto que o 802.11g opera na freqüência de 2,4 GHz, mantendo dessa
forma, a compatibilidade com o padrão 802.11b.
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 802.16) é primeiro padrão oficial para redes wireless de longa distância, aprovado em Janeiro
de 2003.
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.
13
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 802.11b. Essa tecnologia é suportada pelo terminal portátil de dados e está presente na
estrutura de rede das empresas do Grupo MEG.
2.1.3 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.
2.1.3.1 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).
14
2.1.3.2 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).
2.1.3.3 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).
2.1.3.4 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).
2.1.3.5 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).
2.1.3.6 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).
15
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.
2.1.3.7 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 2.2.1.
2.2 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 Java3.
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.
16
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.
17
Figura 4. Arquitetura da Plataforma Java
Fonte: Muchow (2004)
2.2.1 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
18
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
19
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.
2.2.1.1 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”.
20
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.
2.2.1.2 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.
21
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.
22
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)
23
2.2.1.3 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).
2.2.1.4 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
24
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.
2.3.1 CLOG
O aplicativo CLOG foi desenvolvido pela empresa Caladan Software4 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: http://www.caladan.com.br/
25
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).
26
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).
27
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.
2.3.3 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.
28
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 embarque5, 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.
29
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.
30
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 Embarque6 (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.
3.2.1 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.
31
• 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.
32
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 negócios
Implementada no aplicativo móvel Implementada no aplicativo servidor
Acesso ao banco de dados
Implementado no aplicativo móvel, através do pacote adicional (JSR-169)
Implementado no aplicativo servidor
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).
33
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).
34
(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).
35
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
36
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.
3.5.1 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:
3.5.1.1 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;
37
• 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.
3.5.1.2 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.
3.5.1.3 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.
3.5.1.4 Restrições
Além dos requisitos e regras acima mencionados, foram identificadas algumas limitações do
sistema, como:
38
• 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;
3.5.2 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.
3.5.2.1 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.
39
Figura 20. Diagrama de Caso de Uso – Pacote Operações
Figura 21. Diagrama de Caso de Uso – Pacote Configurações
3.5.2.2 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.
40
Figura 22. Diagrama de Classes de Negócio
3.5.2.3 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 02.01 – Cadastra Dados e UC 02.02 – Valida Dados, respectivamente.
41
Figura 23. Diagrama de classe projeto – Cadastra Dados
42
Figura 24. Diagrama de classe de projeto – Valida Dados
3.5.2.4 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 02.01 -
Cadastra Dados, onde o usuário seleciona a opção Expedição do menu principal, o sistema exibe a
43
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 02.02 – 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
44
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 pode-
se 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 27.
8 IDE para plataforma J2ME distribuída pela IBM gratuitamente para avaliação em um período de 90 dias.
45
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.
46
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 re-
estabelecer 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.
47
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.
48
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
49
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.
50
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 31.
51
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.
52
4 CONCLUSÕES
O desenvolvimento deste trabalho compreendeu algumas etapas como revisão bibliográfica,
desenvolvimento do projeto do software, implementação e testes do sistema desenvolvido.
Na revisão bibliográfica destacam-se temas como computação móvel, dispositivos móveis,
tecnologias de conexão sem fio e tecnologias de desenvolvimento para dispositivos móveis. Como o
objetivo geral desse trabalho era desenvolver um aplicativo baseado em computação móvel, com a
utilização da tecnologia J2ME, esse tema foi o que teve o maior destaque, sendo apresentados
detalhes da arquitetura J2ME, o que permitiu a escolha da configuração e do perfil mais adequado
para aplicação proposta.
Com a pesquisa realizada em busca de soluções similares, verificou-se a existência de
algumas ferramentas já disponíveis no mercado. Porém, não foram encontradas ferramentas que
atendessem às necessidades específicos das empresas do Grupo MEG, conforme proposto neste
trabalho. Entretanto, o resultado dessa pesquisa foi bastante proveitoso, pois reforçou algumas
idéias que eram previstas para o projeto.
O conhecimento adquirido através da revisão bibliográfica serviu de base para elaboração do
projeto do sistema. Nesta etapa também foram absorvidos conhecimentos de consultores
especializados em gestão de processos industriais.
A modelagem do sistema proposto foi elaborada seguindo os padrões da UML. No
Capítulo 3 foram apresentados os diagramas considerados relevantes ao projeto do software, além
da descrição textual do funcionamento pretendido para o sistema, com o auxílio dos protótipos de
telas. No Apêndice A, é apresentado o projeto detalhado em UML.
A etapa de implementação foi realizada obedecendo rigorosamente os diagramas UML
elaborados na fase de projeto. A aplicação dos padrões de projeto e da arquitetura em três camadas
no momento da codificação do sistema foi importante, pois ajudou na organização e na
manutenibilidade do sistema.
Essa etapa também apresentou grandes desafios, pois muitas facilidades descritas na
documentação disponível não foram confirmadas na prática. Esperava-se que o J2ME (CDC /
Personal Profile) também tivesse o mesmo nível de portabilidade do Java. Porém, na fase de
53
codificação, pôde-se identificar uma limitação importante quanto a isso, já que algumas linhas de
código apresentaram incompatibilidade quando executadas em máquinas virtuais diferentes.
Entretanto, isso não significa que o J2ME não seja portável. Nos exemplos que se perceberam essas
discrepâncias, pôde-se notar, que na maioria dos casos, havia códigos equivalentes que poderiam
ser utilizados.
O sistema foi validado pela execução de testes tanto durante como após a implementação,
com a realização dos testes unitário, de integração, de sistema e de aceitação, os quais permitiram
confirmar o atendimento dos requisitos estabelecidos.
Considerando os objetivos deste trabalho, pôde-se verificar que todos foram cumpridos,
tendo em vista que foram realizadas pesquisas de conceitos e tecnologias para a utilização na
implementação do sistema. A modelagem do sistema foi elaborada de forma que a fase de
implementação pudesse transcorrer sem maiores problemas, o sistema foi implementado conforme
o proposto, chegando-se ao produto final que pode ser avaliado por seus usuários.
Como idéia para trabalhos futuros, cita-se o estudo da utilização de etiquetas inteligentes
(Padrão RFID - Radio Frequency Identification) junto à tecnologia J2ME.
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, L. B. de. Introdução à J2ME e programação MIDP. Mundo Java, Curitiba, n. 5, p. 20-27, maio 2004.
AMORIM, Andrea Rodrigues de. Desenvolvimento de aplicações móveis com J2ME. Canoas, 2005. Trabalho de Conclusão de Curso em Computação, Universidade Luterana do Brasil, Canoas, 2005.
BARROS, Bruno A.; COSTA, Eduardo; PEREIRA, Guilherme B.; JÁCOMO JÚNIOR, José R. R.; SILVA, Karen C. J2ME uma tecnologia “nova” e muito poderosa. 2003. (Artigo on-line publicado no site do Curso de Especialização em Tecnologia da Informação da Universidade Salgado de Oliveira). Disponível em: <http://br.geocities.com/pos_ti/artigos/J2ME.pdf>. Acesso em: 04 nov. 2006.
CALADAN SOFTWARE. Desenvolvimento de aplicativos para computadores portáteis. 2006. Disponível em: <http://www.caladan.com.br/palm.asp>. Acesso em: 04 nov. 2006.
CAMPOS, André; BRANCO, Pedro. 3GM: relatório intercalar. 2003. Disponível em: <http://immi.inesc.pt/~pjgb/3gm/pt/actividades/relatoriointercalar/relatoriointermedioanexos.pdf>. Acesso em: 04 nov. 2006.
CRISPIM JUNIOR, Carlos Fernando. Análise de tecnologias para dispositivos móveis: um estudo de caso na área da saúde. Itajaí, 2006. 124 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í, 2006.
DEMÉTRIO, Rinaldo, Internet. São Paulo: Érica, 2001.
DORNAN, A. Wireless communications. O guia essencial de comunicação sem fio. São Paulo: Campus, 2001.
FIGUEIREDO, Carlos Maurício Seródio; NAKAMURA, Eduardo. Computação móvel: novas oportunidades e novos desafios. T&C Amazônia, ano 1, no. 2, jun. 2003.
FIGUEIREDO, Thiago Henrique de Paula. MultiMAD: uma ferramenta multimodelo de desenvolvimento de aplicações para dispositivos móveis. 2005. 121 f. (Mestrado)–Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Minas Gerais, Belo Horizonte, 2005.
HADDAD, Renato. Entendendo aplicações móveis no .NET, 2006. Disponível em: <http://www.microsoft.com/brasil/msdn/tecnologias/movel/mobilidade_entendendo.aspx>. Acesso em: 04 nov. 2006.
JAVAFREE. Tutorial Java: O que é Java. 2006. Disponível em: <http://www.javafree.org/content/view.jf?idContent=84>. Acesso em: 04 nov. 2006.
LARMAN, Graig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000.
55
LAUDON, Kenneth C.; LAUDON, Jane Price. Sistemas de informação. Rio de Janeiro: LTC, 1999.
LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações móveis: arquitetura, projeto e desenvolvimento. São Paulo: Makron Books, 2005.
MATEUS, Geraldo R.; LOUREIRO, Antonio A.F. Introdução à computação móvel. In: 11a Escola de Computação, Rio de Janeiro, 1998.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à implementação. Rio de Janeiro: Brasport, 2004.
MICROSOFT. Windows CE Home Page. 2006. Disponível em: <http://msdn.microsoft.com/embedded/windowsce/default.aspx>. Acesso em: 04 nov. 2006.
MUCHOW, John W. Core J2ME: tecnologia e MIDP. São Paulo: Makron Books, 2004.
PALMSOURCE, Inc. PalmOS. 2006. Disponível em <http://www.palmsource.com/palmos/>. Acesso em: 04 nov. 2006.
QUALCOMM Incorporated. Sobre o BREW. 2006. Disponível em <http://brew.qualcomm.com>. Acesso em: 04 nov. 2006.
SALLEM, Márcio Augusto Sekeff. Java 2 Micro Edition: introdução à computação móvel. 2003. (Pós-Graduação em Ciência da Computação)–Universidade Federal do Maranhão, São Luis, 2003.
SCHMITT JUNIOR, Arno José. Protótipo de front end de controle de acesso usando J2Me. 2004. 70 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau, 2004.
SUN MICROSYSTEMS. CdC: Java platform technology for connected devices. 2005. Disponível em: <http://java.sun.com/products/cdc/wp/cdcwhitepaper.pdf>. Acesso em: 04 nov. 2006.
SUN MICROSYSTEMS. Java ME APIs & Docs. 2006. Disponível em: <http://java.sun.com/javame/reference/apis.jsp>. Acesso em: 04 nov. 2006.
SUPERWABA. Plataforma: resumo. 2006. Disponível em: <http://www.superwaba.com.br/pt/overview.asp>. Acesso em: 04 nov. 2006.
SYMBIAN. Symbian OS: the mobile operating system. 2006. Disponível em <http://www.symbian.com/symbianos/index.html>. Acesso em: 04 nov. 2006.
SYMBOL. Mobile computers. 2006. Disponível em <http://www. symbol.com/mc3000>. Acesso em: 04 nov. 2006.
TAURION, Cezar. Software embarcado: oportunidades e potencial de mercado. Rio de Janeiro: Brasport, 2005.
WHITE, James, HEMPHILL, David. Java 2 Micro Edition: Java in small things. Greenwich: Manning, 2002.
APÊNDICES
A MODELAGEM DO SISTEMA
A.1 CASOS DE USO
A modelagem dos casos de uso deste projeto está dividida em três pacotes: Controle de
Acesso, Operações e Configurações. A Figura 23 apresenta o relacionamento entre os mesmos.
Figura 32. Diagrama de Pacotes dos Casos de Uso
A.1.1 Pacote 01: Controle de acesso
Este pacote apresenta o caso de uso referente a autenticação dos usuários da aplicação e os
atores do sistemas. Sendo eles:
• Administrador: Pessoa encarregada de realizar a manutenção do sistema através do
cadastro de configurações;
• Operador: Funcionário do setor de expedição responsável por cadastrar os dados no
sistema; e
• Usuário: Ator abstrato que representa um Administrador ou um Operador que interage
com o sistema.
58
Figura 33. Casos de Uso do Pacote Controle de Acesso
A.1.1.1 UC01.01 - Efetua Login
Caso de uso responsável pela autenticação do usuário:
Relações
• RF01: O sistema deverá permitir autenticação de usuário;
• RNF03: O sistema deverá implementar controle de acesso por níveis (administrador do
sistema / operador do sistema);
• RNF04: A autenticação dos usuários deverá ser implementada utilizando a API Security
do J2ME; e
• RN04: A autenticação dos usuários deverá ser realizada através de consulta à base de
dados do sistema IBF Task.
Condições
• Pré Condição: O usuário deve estar cadastrado no sistema; e
• Pós Condição: Um usuário está autenticado no sistema.
59
Cenários
Fluxo Principal: Efetua login
1. O sistema apresenta uma tela solicitando o login e a senha do usuário. (TEL01);
2. O usuário preenche os dados (login/senha);
3. O usuário solicita a confirmação de identidade;
4. O sistema valida o login e a senha fornecidos; e
5. O sistema apresenta a tela principal com o menu de opções (TEL02 a).
Fluxo Alternativo: Acesso Administrador
Caso, entre o passo 4 e 5 o sistema identifique o usuário como um Administrador o sistema
apresenta a tela principal com o menu de opções completo (TEL02 b).
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 3 o login e/ou a senha estiver(em) em branco, o sistema apresenta mensagem:
“Conta e/ou senha em branco” (TEL06) e retorna ao passo 1.
Fluxo de Exceção 2: Dados inválidos
Se no passo 4 o login ou a senha não puderem ser validadas, o sistema apresenta uma
mensagem: “Login ou senha inválidos!” (TEL06) e retorna ao passo 1.
A.1.2 Pacote 02: Operações
Este pacote apresenta os casos de uso referente às operações que podem ser efetuadas no
sistema, além do caso de uso que registra todas as operações efetuadas.
60
Figura 34. Casos de Uso do Pacote Operações
A.1.2.1 UC02.01 – Cadastra Dados
Caso de uso responsável pelo cadastro dos dados a serem validados.
Relações
• RF02: O sistema deverá 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 deverá 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 deverá permitir a exclusão de determinado número de série da lista de
itens a serem validados; e
• RF08: O sistema deverá permitir o cancelamento da operação.
Condições
• Pré Condição: O usuário deve estar logado no sistema; e
• Pós Condição: Processar a rotina de validação de dados.
Cenários
Fluxo Principal: Cadastra Dados
1. O sistema apresenta a tela solicitando o número e a série da nota fiscal (TEL03);
61
2. O usuário preenche os dados e confirma;
3. O sistema valida os dados e preenche o nome do cliente;
4. O usuário confirma a operação (UC02.03);
5. O sistema apresenta a tela para inserção dos números de série (TEL04);
6. O usuário efetua a leitura do código de barras que identifica o número de série, através
do leitor a laser;
7. O sistema atualiza a lista de números de série lidos; e
8. O usuário seleciona a encerrar (UC02.02, UC02.03).
Fluxo Alternativo: Inserção de dados pelo teclado
No passo 6, o usuário poderá informar os números de série pelo teclado.
1. O usuário informa o número de série e seleciona a opção incluir; e
2. Retorna ao passo 7 do fluxo principal.
Fluxo Alternativo: Exclusão de número de série
Entre o passo 5 e 7, o usuário poderá excluir o número de série selecionado da lista de
números de série.
1. O usuário seleciona um número de série e seleciona a opção excluir (tecla delete); e
2. Retorna ao passo 7 do fluxo principal.
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 8 nenhum numero de série tiver sido cadastrado, o sistema apresenta mensagem:
“Não foram cadastrados números de série para validação!” (TEL06) e retorna ao passo 6 do fluxo
principal.
A.1.2.2 UC02.02 – Valida Dados
Caso de uso que responsável pela validação dos dados cadastrados.
62
Relações
• RF05: O sistema deverá consultar a base de dados do sistema IBF Task;
• RF06: O sistema deverá validar os dados fornecidos;
• RF07: O sistema deverá atualizar as informações processadas na base de dados do
sistema IBF Task;
• RF04: O sistema deverá permitir a exclusão de determinado número de série da lista de
itens a serem validados; e
• RF08: O sistema deverá permitir o cancelamento da operação.
Condições
• Pré Condição: Um número de série deve ter sido informado; e
• Pós Condição: Validação e atualização de dados efetuada.
Cenários
Fluxo Principal: Valida Dados
1. O sistema faz a leitura de todos os números de série cadastrados na lista de números de série.
2. O sistema efetua consultas no banco de dados para verificar a consistência dos números de série informados.
3. O sistema atualiza o banco de dados, gravando os dados da nota fiscal para cada
número de série cadastrado na lista de números de série.
Fluxo de Exceção 1: Números de Série Inválidos
Se no passo 2 caso algum número de série informado já tenha sido associado a uma nota
fiscal, o sistema apresenta mensagem: “O número de série ‘XXXX’ já foi utilizado pela Nota Fiscal
‘XXXX’. Verifique.” (TEL06) e retorna para o passo 5 do fluxo principal do caso de uso UC02.01.
A.1.2.3 UC02.03 – Registra Log
Caso de uso responsável por registrar todas as operações efetuadas no sistema, bem como a
data e hora da ocorrência e também o usuário que efetuou a operação. Esse caso de uso é acionado
após a execução do caso de uso UC 02.01 ou UC 02.02.
63
Relações
• RNF05: Todas as operações do sistema devem ficar registradas.
Condições
• Pré Condição: Alguma operação deve ter sido realizada; e
• Pós Condição: Log registrado no banco de dados.
Cenários
Fluxo Principal: Registra Log
1. O sistema insere no banco de dados o comando SQL executado pela operação, a data/hora e os dados do usuário que efetuou a operação;
A.1.3 Pacote 03: Configurações
Este pacote apresenta o caso de uso referente ao cadastro de parâmetros do sistema.
Figura 35. Casos de Uso do Pacote Configurações
A.1.3.1 UC03.01 – Cadastra Parâmetros
Caso de uso responsável pelo cadastro dos parâmetros do sistema.
Relações
• RF09: O sistema deverá permitir o cadastro e a atualização de parâmetros de
configuração.
64
Condições
• Pré Condição: O usuário Administrador deve estar logado no sistema; e
• Pós Condição: Parâmetros cadastrados ou atualizados.
Cenários
Fluxo Principal: Cadastra Parâmetros
1. O sistema apresenta a tela de cadastro de parâmetros (TEL05);
2. O usuário preenche os campos da tela;
3. O usuário confirma a operação; e
4. O sistema grava dos dados informados.
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 3 algum campo estiver em branco, o sistema apresenta mensagem: “Todos os
campos são de preenchimento obrigatório” (TEL06) e retorna ao passo 1.
A.2 PROTÓTIPOS DAS TELAS DO SISTEMA
Esta seção apresenta os protótipos de telas do sistema, citadas na descrição dos casos de uso
através da referência TEL seguidas de um seqüencial de identificação.
Figura 36. Tela 01 – Login
65
(a) (b)
Figura 37. Tela 02 – Principal: (a) Nível Administrador; (b) Nível Operador
Figura 38. Tela 03 – Expedição: Nota Fiscal
66
Figura 39. Tela 04 – Expedição: Número de Série
Figura 40. Tela 05 – Cadastro de Parâmetros
Figura 41. Tela 06 – Exibição de Mensagens
67
A.3 DIAGRAMA DE CLASSES
A.3.1 Diagrama de classes de negócio
Nesta seção é apresentado modelo de classes de negócio, que ilustra as entidades
participantes do domínio do sistema e seus respectivos relacionamentos.
Figura 42. Diagrama de Classes de Negócio
A.3.2 Diagrama de classes de projeto
Nesta seção é apresentado modelo de classes de projeto, que ilustra a estrutura em três
camadas e a interação entre as classes de cada caso de uso.
68
Figura 43. Diagrama de Classes de Projeto – UC01.01 – Efetua Login
Figura 44. Diagrama de Classes de Projeto – UC02.01 – Cadastra Dados
70
Figura 45. Diagrama de Classes de Projeto – UC02.02 – Valida Dados
71
Figura 46. Diagrama de Classes de Projeto – UC03.01 – Cadastra Parametros
72
A.4 DIAGRAMAS DE SEQUÊNCIA
Nesta seção serão apresentados os diagramas de seqüência que retratam os passos para a
execução das atividades e também a troca de mensagens entre os diversos componentes do sistema.
Figura 47. Diagrama de Seqüência – UC01.01 – Efetua Login
Figura 48. Diagrama de Seqüência – UC02.01 – Cadastra Dados
73
Figura 49. Diagrama de Seqüência – UC02.02 – Valida Dados
Figura 50. Diagrama de Seqüência – UC03.01 – Cadastra Parâmetros
74
ANEXOS
I DESCRIÇÃO DOS DISPOSITIVOS MÓVEIS UTILIZADOS
76
77
78
II PADRÃO DO NÚMERO DE SÉRIE DO GRUPO MEG
79
III MODELO ENTIDADE RELACIONAMENTO (ER)
80
IV ROMANEIO DE SEPARAÇÃO E EMBARQUE
81
V NOTA FISCAL
