universidade do oeste de santa catarina unoesc unidade chapecó

8/15/2019 Universidade Do Oeste de Santa Catarina Unoesc Unidade Chapecó

1/77

UNIVERSIDADE DO OESTE DE SANTA CATARINA

UNOESC – UNIDADE CHAPECÓ

GABRIEL CARLOS VIVIAN

PROTÓTIPO DE APLICATIVO PARA DISPOSITIVOS MÓVEIS INTEGRADO AO

ERP GESCOOPER

Chapecó – SC2011


2/77



ERP GESCOOPER

Trabalho de Conclusão de Curso apresentado ao

Curso de Sistemas de Informação, da

Universidade do Oeste de Santa Catariana

(UNOESC) para obtenção do grau de bacharel.

Prof. Orientador (a): Prof.ª Carla de A. M. Basso, M.Sc.

Chapecó – SC2011


3/77



ERP GESCOOPER

Trabalho de Conclusão de Curso apresentado aoCurso de Sistemas de Informação, da

Universidade do Oeste de Santa Catariana

(UNOESC) para obtenção do grau de bacharel.

Aprovada em: 03 / 07 / 2011

__________________________________________________________Prof. M.Sc. Carla A. Martins Basso

Universidade do Oeste de Santa Catarina - UNOESC

__________________________________________________________Prof. M.Sc. Tiago Zonta


__________________________________________________________Prof. Esp. José Luiz Cunha Quevedo



4/77

AGRADECIMENTOS

Agradeço à minha mãe, Maria, pelas palavras de incentivo e ao meu pai,

Delcino Vivian, pelo apoio.

Agradeço, com muito amor, à minha namorada, Daiane, por estar sempre ao

meu lado e pela sua compreensão.

Agradeço aos meus amigos da Infogen Sistemas pelo apoio e por

emprestarem seus celulares para os meus testes.

Agradeço aos meus amigos da faculdade.

Agradeço ao meu irmão, Rafael Vivian, que sempre leu o meu trabalho e pelo

seu apoio.

Agradeço ao professor Rafael Leite pelo material disponibilizado que tanto me

auxiliou.

Agradeço à minha orientadora, Carla Basso, que sempre respondeu as

minhas perguntas seja em sala ou pelo Skype, por acreditar no meu trabalho e

aceitar esse desafio.


5/77

"Ninguém cresce escondendo

conhecimento. Todos se desenvolvem em conjun to,

uns aprendendo com o que outros ja desbravaram"

(Autor Desconhecido)


6/77

RESUMO

Este trabalho apresenta um protótipo de aplicativo para dispositivos móveis, que tem

como objetivo agilizar o processo de geração de pedidos realizados pelos

vendedores das cooperativas agrícolas que utilizam o Enterprise Resource Planning

(ERP) desenvolvido pela Infogen Sistemas, o GesCooper. Utilizando Web Services

para integração com o GesCooper e Java Micro Edition (JME) para desenvolvimento

do aplicativo que será executado no dispositivo móvel. O trabalho inicia-se com a

revisão da literatura onde é apresentado as tecnologias e ferramentas estudadas e

que serão utilizadas para o desenvolvimento do protótipo. Em seguida é

apresentado como foram utilizadas essas tecnologias e ferramentas a fim de

desenvolver o protótipo proposto.

Palavras-Chave: Web Service, J2ME, Disposi tivos Móveis.


7/77

LISTA DE ILUSTRAÇÕES

Figura 1. Tipos de Sistema de Informação 17

Figura 2. Edições da Linguagem Java e seus alvos de aplicação 22

Figura 3. Perfil de Informação Móvel - Hierarquia de Classes 24

Figura 4. Armazém de Registros 25

Figura 5. Ciclo de vida do MIDlet 27

Figura 6. Modelo básico Web Service 30

Figura 7. Arquitetura de um Web Service baseado em SOAP 32

Figura 8. Estrutura básica do WSDL 32

Figura 9. Clientes que possuem vendedores externos 38

Figura 10. Vendedores com dificuldade de enviar os pedidos 39

Figura 11. Clientes com vendedores externos e que possuem dificuldade de

comunicação

39

Figura 12. Empresas que possuem software para envio de pedidos 40

Figura 13. Empresas com interesse na solução 40

Figura 14. Arquitetura do protótipo 41Figura 15. Diagrama de Entidade Relacionamento 45

Figura 16. WSDL Cadastro de Usuários 46

Figura 17. Resultado da execução do método validarUsuário 47

Figura 18. WDSL Transacionadores 47

Figura 19. Resultado da execução do método listarTransacionadores 48

Figura 20. WSDL Formas 49

Figura 21. Resultado da execução do método listarFormas 49Figura 22. WSDL Produtos 50

Figura 23. Resultado da execução do método listrarProdutos 50

Figura 24. WSDL ProdutosLevel4 51

Figura 25. Resultado da execução do método listrarProdutoslevel4 51

Figura 26. WSDL PedVendas 52

Figura 27. Converter J2ME MIDP (JAD) para Android pacote (APK) 53

Figura 28. Diagrama de Caso de Uso 54


8/77

Figura 29. Fluxo de execução da MIDlet 59

Figura 30. Tela de inicialização do aplicativo 60

Figura 31. Tela de login da aplicação 61

Figura 32. Tela de início do aplicativo 61

Figura 33. Tela inicial do pedido 62

Figura 34. Tela de consulta dos clientes 62

Figura 35. Tela de consulta das formas de pagamento 63

Figura 36. Tela de consulta dos produtos 64

Figura 37. Tela de consulta dos itens do pedido 64

Figura 38. Tela de confirmação do envio do pedido 65

Figura 39. Tela do pedido do ERP GesCooper 65


9/77

LISTA DE TABELAS

Tabela 1 Documentação do Caso de Uso CSU001 54








10/77

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

APK Android Pacote

BI Business intelligence

CRM Customer relationship management

CD-ROM Compact Disk Ready Only memory

CLDC Connected Limited Device Configuration

ERP Enterprise Resource Planning

EJB Enterprise JavaBeans

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

HTTPS HyperText Transfer Protocol secure

IDC International Data Corporation

IDE Integrated Development Environment

IIS Internet Information Server

J2 Java 2J2ME Java Micro Edition

JAD Java Application Descriptor

JAR Java Archive

JDBC Java Database Connectivity

JDK Java Development Kit

JNDI Java Naming and Directory Interface

JPA Java Persistence APIJSP Java Server Pages

JVM Java Virtual Machine

KVM K Virtual Machine

MIDP Mobile Information Device Profile

PHP Hypertext Preprocessor

RIM Research In Motion

UML Unified Modeling Language


11/77

XML Extensible Markup Language

WWW World Wide Web


12/77

SUMÁRIO

1. INTRODUÇÃO ................................................................................................... 13

1.1. OBJETIVOS ..................................................................................................... 14

1.1.1. OBJETIVO GERAL ............................................................................................. 14

1.1.2. OBJETIVOS ESPECÍFICOS .................................................................................. 14

2. REVISÃO DA LITERATURA .............................................................................. 15

2.1. COOPERATIVA ............................................................................................... 15

2.1.1. PRINCÍPIOS ...................................................................................................... 15

2.2. SISTEMAS DE INFORMAÇÃO ........................................................................ 17

2.3. ERP .................................................................................................................. 18

2.4. MOBILIDADE E DISPOSITIVOS MÓVEIS ....................................................... 19

2.4.1. MITOS RELACIONADOS AO DESENVOLVIMENTO DE APLICAÇÕES MÓVEL ................ 20

2.5. TECNOLOGIA PARA DISPOSITIVOS MÓVEIS ............................................... 21

2.5.1. JAVA ............................................................................................................. 21

2.5.2. J2ME - J AVA MICRO EDITION ........................................................................... 21

2.5.2.1. Configurações ............................................................................................. 232.5.2.2. Componentes visuais .................................................................................. 24

2.5.2.3. RMS – Record Management System .......................................................... 25

2.5.2.4. MIDP – Mobile Information Device Profile ................................................... 26

2.5.2.5. MIDlets ........................................................................................................ 27

2.6. FERRAMENTAS .............................................................................................. 28

2.6.1. NETBEANS ...................................................................................................... 28

2.6.2. TOMCAT .......................................................................................................... 29 2.6.3. GLASSFISH ...................................................................................................... 29

2.7. WEB SERVICES .............................................................................................. 30

2.7.1. XML - LINGUAGEM DE M ARCAÇÃO EXTENSÍVEL ................................................. 31

2.7.2. SOAP - SIMPLE OBJECT ACCESS PROTOCOL .................................................... 31

2.7.3. WSDL - WEB SERVICES DESCRIPTION L ANGUAGE ............................................. 32

3. CAMPO OU ÁREA DE ESTUDO ....................................................................... 33

3.1. DESCRIÇÃO DA EMPRESA ............................................................................ 333.2. GESCOOPER .................................................................................................. 34


13/77

4. MÉTODO ............................................................................................................ 35

4.1. DELIMITAÇÃO DO ESTUDO, MÉTODO E COLETA DE DADOS .................... 35

4.2. CARACTERIZAÇÃO DO ESTUDO .................................................................. 35

4.3. DEFINIÇÃO DA POPULAÇÃO E DA AMOSTRA .............................................. 36

4.4. TÉCNICA DE ANALISE E INTERPRETAÇÃO DE DADOS .............................. 36

4.5. QUESTOES DE PESQUISA ............................................................................ 37

5. APRESENTACAO E ANÁLISE DOS RESULTADOS ....................................... 38

5.1. ANÁLISE DOS RESULTADOS ........................................................................ 38

5.2. DESENVOLVIMENTO DO PROTÓTIPO ......................................................... 41

5.3. REQUISITOS FUNCIONAIS ............................................................................ 42

5.4. REQUISITOS NÃO FUNCIONAIS .................................................................... 435.5. SERVIDOR ...................................................................................................... 44

5.5.1. DIAGRAMA DE CLASSE ..................................................................................... 44

5.5.2. ER – DIAGRAMA DE ENTIDADE RELACIONAMENTO ............................................. 45

5.5.3. CRIAÇÃO DO WEB SERVICE .............................................................................. 46

5.6. CLIENTE .......................................................................................................... 53

5.6.1. C ASO DE USO .................................................................................................. 54

5.6.2. DIAGRAMA DE CLASSE ...................................................................................... 58 5.6.3. FLUXO DE EXECUÇÃO DA MIDLET ...................................................................... 59

5.6.3.1. Demonstração da execução da MIDlet........................................................ 60

CONCLUSÃO .......................................................................................................... 66

REFERÊNCIAS ........................................................................................................ 67

APÊNDICES ............................................................................................................. 70

APÊNDICE A – QUESTIONÁRIO ............................................................................ 71

APÊNDICE B – DIAGRAMA DE CLASSE WEB SERVICE .................................... 72 APENDICE C – DIAGRAMA DE CLASSE MIDLET ................................................ 76


14/77

1. INTRODUÇÃO

O sucesso das empresas está totalmente vinculado à velocidade com que as

informações são assimiladas e pela rapidez que como são tomadas as decisões. Os

componentes que fundamentam a Tecnologia de Informação são os grandes

precursores desse sucesso e os dispositivos móveis são grandes aliados, permitindo

conectividade que outros dispositivos não possuem, facilitando a comunicação com

outros sistemas.

Utilizando os recursos que os dispositivos móveis oferecem, o

desenvolvimento de aplicações para esses equipamentos tende a aumentar. Entre

os recursos, há o ambiente Java, que está cada vez mais presente no dia a dia das

pessoas, seja em produtos fixos ou móveis, de uso pessoal ou de consumo

(CASTELO, 2010).

Com o intuito de colaborar com a qualidade do serviço de atendimento aos

clientes da Infogen Sistemas, oferecendo a eles um diferencial de mercado, este

trabalho visa ao desenvolvimento de um protótipo de aplicativo que permita aos

vendedores das cooperativas registrarem os seus pedidos por meio de um

dispositivo móvel, utilizando aparelhos com recursos como o Java. O aplicativo que

será implementado neste trabalho será desenvolvido com a linguagem Java para

equipamentos portáteis, conhecido como Java Micro Edition (J2ME).


15/77

14

1.1. OBJETIVOS

Nesta seção, são apresentados os objetivos gerais e específicos do trabalho.

1.1.1. Objetivo geral

O objetivo deste trabalho é prover uma solução através do desenvolvimento

de um protótipo para registrar pedidos de venda utilizando dispositivos móveis,

integrado com o sistema de gestão da Infogen Sistemas, o GesCooper.

1.1.2. Objetivos específicos

· Estudar uma linguagem de desenvolvimento voltada para dispositivos móveis;

· Desenvolver a integração com o sistema de gestão da Infogen Sistemas,utilizando tecnologias móveis;

· Propor uma solução através de um protótipo integrado ao sistema de gestão

da Infogen Sistemas, utilizando tecnologia para dispositivos móveis;

· Permitir a comunicação online entre os sistemas.


16/77

2. REVISÃO DA LITERATURA

2.1. COOPERATIVA

As cooperativas têm aumentado em todo o mundo, principalmente a partir de

meados do século passado. O Cooperativismo teve início na Inglaterra devido às

necessidades dos agricultores, artesãos e operários se organizarem como forma de

defesa frente às situações de mercado (REVISTA DE CIÊNCIAS EMPRESARIAIS,

2005).

A mais expressiva concretização do pensamento cooperativista é a

Cooperativa de Consumo dos Pioneiros de Rochdale, criada em 1843, através da

associação de 28 tecelões de Rochdale, conhecida como Sociedade dos Probos

Pioneiros de Rochdale Limitada, os quais pretendiam melhorar suas condições de

vida e realizar uma reforma social mais ampla (REVISTA DE CIÊNCIAS

EMPRESARIAIS, 2005).

Cooperativas são empresas sem fins lucrativos, pois têm o homem como sua

principal finalidade, formada pela união de pessoas voltadas para o mesmo objetivo,

buscando satisfazer suas necessidades. Trata-se de uma organização democrática

e participativa.

2.1.1. Princípios

Segundo a Revista de Ciências Empresarias (2005), a Sociedade dos Probos

Pioneiros de Rochdale, considerada a mãe das cooperativas, aplicava sete

princípios básicos que permitiram o seu crescimento.

Com o tempo surgiram outras cooperativas a exemplo de Rochdale, utilizando

como base seus princípios. Assim, a Revista de Ciências Empresariais (2005)

apresenta os princípios do sucesso do cooperativismo listados abaixo.

1º. Adesão voluntária e livre: as cooperativas são organizações voluntárias,

abertas a todas as pessoas aptas a utilizar seus serviços e assumir


17/77

16

responsabilidades com as pessoas associadas à cooperativa, sem discriminações

sociais, raciais, políticas, religiosas e de sexo.

2º. Gestão democrática pelos membros: as cooperativas são organizaçõesdemocráticas, controladas pelos seus cooperados, que participam ativamente na

formulação de suas políticas e na tomada de decisões. Os homens e as mulheres,

eleitos como representantes de outros membros, são responsáveis perante estes.

3º. Participação econômica dos membros: os cooperados contribuem

equitativamente para o capital de suas cooperativas e o controlam

democraticamente. Parte desse capital deve ser propriedade comum da

Cooperativa. Os cooperados recebem, habitualmente, uma remuneração pequena

sobre seu capital subscrito, como condição de sua adesão.

4º. Autonomia e independência: as cooperativas são organizações

autônomas, de ajuda mútua, geridas pelos seus membros. Se firmarem acordos com

outras organizações - incluindo instituições públicas - ou recorrerem a capital

externo, devem fazê-lo em condições que assegurem o controle democrático pelos

seus cooperados e nas quais se mantenha a autonomia das cooperativas.

5º. Educação, formação e informação: as cooperativas promovem a educação

e a formação dos seus cooperados, dos representantes eleitos e dos trabalhadores,

de forma que possam contribuir eficazmente para o desenvolvimento da instituição.

Informam ao público em geral, particularmente aos jovens e aos líderes de opinião, a

natureza e as vantagens da cooperação.

6º. Intercooperação: ativa cooperação entre as cooperativas em plano local,

nacional e internacional. Trabalhando em conjunto, servem de forma mais eficaz a

seus membros e dão mais força ao movimento cooperativo.

7º. Interesse pela comunidade: as cooperativas trabalham para o

desenvolvimento sustentado das suas comunidades, através de políticas aprovadas

pelos membros. Contribuem, concretamente, para tornar a sociedade mais justa e

os valores humanos mais respeitados. A boa aceitação no mercado permite que elas

façam a diferença na vida social, cultural e econômica das pessoas.

Até hoje esses princípios são mantidos e fazem com que as cooperativas se

diferenciem das empresas tradicionais.


18/77

17

2.2. SISTEMAS DE INFORMAÇÃO

Sistema de informação tem como elemento principal a informação. O objetivodo sistema de informação é armazenar informações, coletando, processando e

transformando em informação, de forma que ela possa auxiliar os processos da

organização (OLIVEIRA, 2000).

Para atender os diferentes níveis de interesse de uma organização é

necessário entender os diferentes tipos de sistemas definidos por Oliveira (2000),

em que se pode destacar quatro níveis: Nível Estratégico, Nível Gerencial, Nível

Conhecimento e Nível Operacional, o que pode ser observado na Figura 1.

Figura 1 - Tipos de Sistema de Informação.Fonte: Apostila da disciplina de Sistemas de Informação. Unoesc/SOS.

Aula do dia 05/04/2010 (Prof.ª Carla de A. M. Basso).

· Nível Estratégico: ajudam a alta administração a planejar o curso da ação,

em longo prazo. Envolvem diretamente questões e objetivos das

organizações, produtos, serviços e sobrevivência. Auxiliam no processo de

tomada de decisão (produção de novos produtos, investimento em nova

tecnologia, mudança de localidade / mercado).

· Nível Gerencial: fundamentam-se sobre problemas voltados para a gerência

intermediária, como atingir os objetivos e como controlar e avaliar o processopara atingir tais objetivos. Podem ser utilizados em aplicações tais como


19/77

18

acompanhamento de vendas para análise do sucesso das vendas anuais ou

mensais, ou ainda para revisão de orçamentos departamentais (evitar

desperdícios).· Nível de Conhecimento: sistemas utilizados para auxiliarem os especialistas

e profissionais do conhecimento, profissionais que criam, distribuem e usam o

conhecimento e informação em benefício da empresa para que estes possam

projetar produtos, racionalizar serviços e lidar com documentos.

· Nível Operacional: sistemas que registram as operações dos funcionários

técnicos, de produção, serviços e operações rotineiras das atividades da

empresa.

2.3. ERP

Enterprise Resource Planning (ERP) é um sistema integrado que pode

otimizar os trabalhos da empresa. O software integra dados de diferentes

departamentos da empresa, compartilhando informações através doprocessamento lógico, alimentando todos os módulos do sistema, em tempo real,

automatizando tarefas repetitivas que não geram valor à empresa, permitindo

realocar funcionários para outras tarefas, gerando maior produtividade à empresa e

a redução do trabalho (NORRIS et al., 2001).

A implantação de um ERP pode afetar a estrutura da empresa, podendo levá-

la a rever seus processos de negócio, comprometendo principalmente os

funcionários e forçando a realinhar seus processos (NORRIS et al., 2001).O ERP é um sistema importante para as organizações, pois, através da

integração de seus módulos e seus inúmeros relatórios, podem disponibilizar

informações importantes de transações, as quais são utilizadas pelo gestor como

apoio as decisões.


20/77

19

2.4. MOBILIDADE E DISPOSITIVOS MÓVEIS

A capacidade de se movimentar ou ser movimentado com facilidade pode serdefinido como mobilidade. Segundo Lee (2005), no contexto de computação móvel,

mobilidade se refere ao uso pelas pessoas de dispositivos móveis portáteis, que têm

a capacidade de realizar funções capazes de conectar-se, obtendo dados e

apresentando-os para os usuários (LEE et al., 2005).

Para que um dispositivo seja considerado móvel, ele deve possuir certas

características como portabilidade, permitindo que seja transportado com facilidade

pelo usuário. De acordo com Lee (2005), o dispositivo que pode oferecer melhormobilidade tem as seguintes características: portabilidade, usabilidade,

funcionalidade e conectividade (LEE et al., 2005).

Segundo Araujo (2006) dispositivos móveis podem ser celulares, pagers,

PDAs ou qualquer aparelho que permita a comunicação em qualquer lugar e a

qualquer hora. Com o passar do tempo e usuários mais exigentes, esses

dispositivos evoluíram, ganhando cada vez mais novos recursos e design.

Sofisticados recursos como a transferência de voz vêm se tornando apenasfuncionalidade básica.

O Smatphone, também conhecido como telefone inteligente, é um dispositivo

móvel capaz de rodar aplicativos que podem facilitar a comunicação enquanto o

usuário se movimenta (ARAUJO, 2006).

Esses pequenos computadores de bolso têm como destaque a possibilidade

de navegação pela internet e a utilização de outros aplicativos que podem

transformar a utilização, tornando o aparelho mais útil e eficiente.

De acordo com Cavalcanti (2009), estudos realizados pela International Data

Corporation (IDC), a pedido da Research In Motion (RIM), uma das líderes no

mercado de Smartphones, revelou que Chile e Colômbia são os países da América

Latina mais adiantados na adoção da mobilidade corporativa.


21/77

20

2.4.1. Mitos relacionados ao desenvolvimento de aplicações móvel

Conforme Lee (2005) existem alguns mitos com relação ao desenvolvimentode aplicações para dispositivos móveis:

· É fácil: as pessoas parecem pensar que desenvolver aplicações para

dispositivos móveis é fácil. De fato, provavelmente é mais difícil. Há muitas

dificuldades que precisam ser vencidas, incluindo ergonomia,

conectividade e considerações sobre telas de comando reduzido.

· É rápido: existe a noção de que desenvolver aplicações em dispositivos

móveis é, de certo modo, rápido. Na verdade, provavelmente, não serámais rápido ou mais lento que qualquer outro esforço de desenvolvimento

de uma aplicação.

· É barato: nem o desenvolvimento de aplicações móveis nem os

dispositivos são necessariamente baratos. A compra de um dispositivo

móvel pode sair tão caro quanto um computador desktop.


22/77

21

2.5. TECNOLOGIA PARA DISPOSITIVOS MÓVEIS

Nesta seção, são apresentados os recursos e tecnologias utilizadas para odesenvolvimento do protótipo.

2.5.1. JAVA

Segundo Niemeyer (2000), Java é uma linguagem de programação que

segue o paradigma de programação orientada a objetos desenvolvida pela Sun. Na

década de 90, o projeto Java teve início pelo pesquisador Bill Joy, que, segundo

Deitel (2001), tornou-se conhecido com o uso da internet, graças a sua capacidade

para a criação de aplicações para World Wide Web (WWW).

Java é independente de sistema operacional, assim, todo software escrito

nessa linguagem de programação pode ser executado em dispositivos com sistema

operacional como Symbian, Windows CE, Pocket PC, Palm OS, entre outros. Dessa

forma, esses sistemas operacionais requerem uma Java Virtual Machine (JVM)compatível (NIEMEYER, 2000).

2.5.2. J2ME - Java Micro Edition

Java 2 Micro Edition é uma Application Programming Interface (API) Java

voltada para o desenvolvimento de aplicativos que rodam em micro processadores

como celulares, PDA, Smartphone que têm poder limitado de processamento

(FIORESI, 2007).

Segundo Muchow (2004) a inclusão mais revolucionária na família do Java é

a Micro Edition, que objetiva ferramentas de informação, variando desde máquinas

ligadas à TV habilitadas a internet até telefones celulares.

Com a inclusão do Java para dispositivos móveis, tem-se agora acesso aos

recursos de uma linguagem de programação fácil de dominar e um ambiente em


23/77

22

tempo de execução que fornece uma plataforma segura e portável (MUCHOW,

2004).

O Java 2, segundo Fioresi (2007), está dividido em:

· Java 2 Standard Edition (J2SE): tecnologia projetada para

computadores pessoais e ambientes de trabalho.

· Java 2 Enterprise Edition (J2EE): tecnologia direcionada para

aplicações baseadas no servidor, contendo suporte interno para JSP

(JavaServer Pages), XML (eXtensible Markup Language) e servlets.

· Java 2 Micro Edition (J2ME): tecnologia direcionada para dispositivos

com poucos recursos computacionais como, por exemplo, Palm’s e

telefones celulares.

A Figura 2 mostra as edições do Java, de acordo com Fioresi (2007).

Figura 2 - Edições da Linguagem Java e seus alvos de aplicaçãoFonte: Adaptado de Fioresi (2007)

Em dezembro de 1998, a Sun apresentou o nome “Java 2” (J2) para

coincidir com o lançamento do Java 1.2. Essa nova convenção de atribuição

de nomes se aplica a todas as edições do Java: Standart Edition (J2SE),

Enterprise Edition (J2EE) e Micro Edition (J2ME) (MUCHOW, 2004, p.

2).


24/77

23

2.5.2.1. Configurações

Segundo Muchow (2004, p.3), “com o objetivo de suportar uma amplavariedade de produtos que se encaixam dentro do escopo do J2ME, a Sun

Microsystems (Sun) introduziu a Configuração”.

A Configuração está vinculada a uma máquina virtual Java, a qual define uma

plataforma Java para ampla variedade de dispositivos. Os recursos da linguagem

Java e as bibliotecas básicas da JVM são definidos para cada configuração em

particular (MUCHOW, 2004).

A divisão entre as possíveis configurações está baseada na memória, novídeo, na conectividade de rede e no poder de processamento dos dispositivos

(MUCHOW, 2004).

De acordo com Muchow (2004), a seguir estão as características típicas dos

dispositivos, dentro das duas configurações disponíveis.

CDC – Configuração de Dispositivo Conectado

·

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;

· conectividade de rede, largura de banda possivelmente persistente e

alta.

CLDC – Configuração de Dispositivo Conectado Limitado

·

128 kilobytes de memória para executar o Java;· 32 kilobytes para alocação de memória em tempo de execução;

· interface restrita com o usuário;

· baixo poder, normalmente alimentado por bateria;

· conectividade de rede, normalmente dispositivos sem fio com largura

de banda baixa e aceso intermitente.


25/77

24

2.5.2.2. Componentes visuais

Segundo Muchow (2004), através da classe Screen e suas heranças,classificadas como objetos de Interface ou componentes visuais, podem-se

adicionar comandos, possibilitando gerenciar as ações do usuário. A seguir,

destacam-se quais são os possíveis componentes visuais disponíveis para

implementação.

Figura 3 - Perfil de Informação Móvel - Hierarquia de ClassesFonte: Adaptado de Muchow (2004, p. 98)

TextBox: Tela que permite a entrada de texto. É possível definir qual o tipo

de caractere que deve ser digitado e o seu tamanho.

Forms: o objeto que pode oferecer algumas limitações, não existem janelas

sobrepostas e barra de menus em cascata, mas ele permite adicionar vários

componentes na tela, fornecendo rolagem conforme for necessário para acomodar

os componentes.

List: o objeto que apresenta uma lista de escolhas a qual pode ter três

formatos; Múltiple, em que se podem ter n números de elementos selecionais;

Exclusive, em que se pode ter apenas um elemento selecionado; e Implicit, em que

a seleção de um elemento gera um evento.

Alert : o objeto que suporta texto e objetos do tipo Image. Seu uso é opcional

e normalmente é utilizado para mostrar mensagens de erro. Existem dois tipo de


26/77

25

objetos Alert: Modal, em que o objeto fica na tela até o momento em que o usuário

dispense ou Cronometrado, em que o objeto fica na tela por um tempo determinado.

2.5.2.3. RMS – Record Management System

Quando se faz referência ao armazenamento e à recuperação de dados em

dispositivos móveis, seja qual for a informação que se deseja armazenar, é preciso

encontrar uma maneira de gerenciar os dados relacionados ao aplicativo. Quando se

fala em desktop, as opções são das mais variadas: Compact Disk Ready Only

memory (CD-ROM), unidade de disco local, unidade de disco de rede, Pen Drive etc

(MUCHOW, 2004).

No caso dos dispositivos móveis, isso se torna um pouco mais complicado e

existem algumas preocupações com o tamanho, desempenho e as diferenças entre

os fabricantes no que diz respeito ao suporte para sistemas de arquivo e interligação

em rede (MUCHOW, 2004).

“Como uma alternativa ao uso de um sistema de arquivos, o RMS utilizamemória não volátil para armazenar informações. Esse banco de dados

orientado para registros, freqüentemente referido como arquivo puro, pode

ser imaginado como uma série de fileiras em uma tabela, com um

identificador exclusivo para cada fileira”. (MUCHOW, 2004, p. 296).

A seguir, pode-se visualizar a representação de um Record Management

System (RMS), de acordo com Muchow (2004) :

Figura 4 - Armazém de RegistrosFonte: Adaptado de Muchow (2004, p. 296)


27/77

26

2.5.2.4. MIDP – Mobile Information Device Profile

Baseando-se na configuração Connected Limited Device Configuration (CLDC), o Mobile Information Device Profile (MIDP) utiliza a K Virtual Machine (KVM)

para executar aplicativos em dispositivos móveis, como telefones celulares

(GOMES, 2005).

Segundo MUCHOW (2004), não há melhor maneira de citar os requisitos de

hardware do que simplesmente listá-los um a um. Abaixo os requisitos de Hardware

e Software de acordo com MUCHOW (2004):

· a tela deve suportar pelo menos 96 X 54 pixels;· deve haver pelo menos um tipo de entrada de usuário disponível:

teclado de mão (teclado de telefone), teclado de duas mãos (teclado

padrão dos computadores) ou tela de toque;

· 128 kilobytes de memória não-volátil (ROM) para executar os

componentes Mobile Information Device (MID);

· pelo menos 8 kilobytes de memória não-volátil (ROM) para os

aplicativos armazenarem dados persistentes, como configuração edados do aplicativo;

· 32 kilobytes de memória volátil (RAM) para executar o Java;

· conectividade de rede sem fio.

Testar aplicações em equipamentos reais aumenta os custos de

desenvolvimento, por este motivo os emuladores são recursos importantes

para o desenvolvimento de aplicações Mobile Information Device Profile

(MIDP), fornecendo ao desenvolvedor uma ferramenta de testes e

correções com todas as características do dispositivo real (SOUZA,2008, p. 22).


28/77

27

2.5.2.5. MIDlets

O aplicativo Java projetado para ser executado em um dispositivo móvel éconhecido como MIDlet e tem como classes do Java básicas a CLDC e o Information

Device Profile (MIDP) (MUCHOW, 2004).

Dispositivos com suporte ao profile MIDP são capazes de executar aplicações

MIDlet desenvolvidas em J2ME. Quando os MIDlets são agrupados, possuem

funcionalidades semelhantes em um mesmo pacote, que é chamado de MIDlet

Suíte. Os recursos do dispositivo móvel são compartilhados com os membros da

mesma Midlet Suíte e executam a mesma KVM (GOMES, 2008).Segundo Gomes (2005), o software de gerenciamento da aplicação do

dispositivo interage diretamente com o MIDlet com os métodos de iniciar, pausar e

destruir, conforme representado na figura abaixo:

Figura 5 - Ciclo de vida do MIDletFonte: Adaptado de Gomes (2005)

Iniciar: é feita a aquisição de recursos, inicializando a execução através do

startApp().

Pausar: é feita a liberação de recursos em que o aplicativo fica em modo de

espera, permitindo atender ao telefone enviar ou receber SMS. Esse processo

ocorre através do método pauseApp().

Destruir: é feita a liberação de todos os recursos, finalizando o aplicativo.

Esse processo acorre através do método detroyApp().


29/77

28

Segundo Muchow (2004), o MIDlet pode ser executado em qualquer

dispositivo contendo a KVM, porém os dispositivos variam de tamanho de tela,

cores, teclados e outros aspectos, tornando difícil essa flexibilidade.

2.6. FERRAMENTAS

Nesta seção, estão fundamentadas as ferramentas utilizadas para o

desenvolvimento do protótipo.

2.6.1. NetBeans

Em meados dos anos 90, dois estudantes de Praga, na República Checa,

iniciaram o desenvolvimento do Integrated Development Environment (IDE) Xelfi,

desenvolvido totalmente em Java. O nome NetBeans vinha da integração que a

ferramenta deveria ter para os então modernos componentes Java Beans

(MAGALHÃES et al., 2007).

A ligação da Sun com o NetBeans começou em 1999, quando a empresa

desistiu de sua IDE Java Workshop e procurou por novas iniciativas. O NetBeans foi

adquirido e teve seu nome, durante alguns meses, mudado para Forte for Java. Em

2000, a Sun anunciava que o NetBeans seria uma plataforma Open Source

(MAGALHÃES et al., 2007).

NetBeans é um ambiente de desenvolvimento integrado de código-fonteaberto gratuito para desenvolvedores de software, escrever, compilar e debugar

programas. Esse IDE disponibiliza todas as ferramentas necessárias para criar

aplicativos profissionais de área de trabalho, corporativos, Web e móveis, com a

plataforma Java, podendo suportar outras linguagens de programação como C/C++,

PHP, JavaScript, Groovy e Ruby (MAGALHÃES et al., 2007).

A versão do NetBeans utilizada para o desenvolvimento deste trabalho é a

versão 6.9 .


30/77

29

2.6.2. Tomcat

O Tomcat é um servidor de aplicações Java para web. É software livre e decódigo aberto. Surgido dentro do conceituado projeto Apache Jakarta, o Tomcat é

robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de

produção (APACHE TOMCAT, 2010)

Tecnicamente, o Tomcat é um Container Web, que abrange as tecnologias

Servlet e Java Server Pages (JSP), incluindo tecnologias de apoio relacionadas e

segurança, Java Naming and Directory Interface (JNDI) Resources e Java Database

Connectivity (JDBC) DataSources (APACHE TOMCAT, 2010).O Tomcat tem a capacidade de atuar também como servidor Web/HTTP, ou

pode funcionar integrado a um servidor web dedicado como o Apache HTTP ou o

Microsoft Internet Information Server (IIS) (APACHE TOMCAT, 2010).

2.6.3. GlassFish

O projeto do Glassfish foi lançado pela Sun em junho de 2005. A primeira

versão foi lançada em maio de 2006, a segunda, em setembro de 2007 e,

atualmente, a versão mais recente é a terceira versão (PELEGRI et al., 2007).

O GlassFish é um servidor de aplicações de código aberto de nível

corporativo que oferece desempenho, confiabilidade, produtividade e facilidade de

uso superiores a uma fração do custo de servidores de aplicações proprietários.

(PELEGRI et al., 2007).Por ser um produto da própria Sun, tem 100% de compatibilidade com o

JAVA, permitindo a utilização de ferramentas e serviços como o Enterprise Java

Beans (EJB).


31/77

30

2.7. WEB SERVICES

Web Services têm a capacidade de interagir entre sistemas enviando ourecebendo informações, independentemente da linguagem de programação ou

sistema operacional. Web Services tem o objetivo de integrar softwares diferentes

por meio de um protocolo padronizado para que a troca de dados seja realizada no

formato Extensible Markup Language (XML) (GOMES, 2010).

A transparência de linguagens é a principal atração do Web Service. O

serviço e seus clientes não precisam ser escritos na mesma linguagem.

Transparência de linguagem é a chave para a interoperabilidade do Web Service,isto é, a habilidade de Web Services e solicitantes interagirem apesar das

diferenças nas linguagens de programação, bibliotecas de suporte e plataformas

(KALIN, 2010).

Conforme o conceito de Web Services de STREIBEL (2005, p. 18),

Web Services são serviços distribuídos na WEB que processam

mensagens SOAP codificadas em XML enviadas através do protocolo

HTTP. Podemos observar que a Arquitetura de um Web Services (WSA) éformada por um conjunto de tecnologias que agregadas conseguem

grandes resultados para os programadores WEB.

Figura 6 - Modelo básico Web Service


32/77


33/77

32

Figura 7 - Arquitetura de um Web Service baseado em SOAPFonte: Kalin (2010, Pag. 2)

2.7.3. WSDL - Web Services Description Language

Web Services Description Language (WSDL): “É um arquivo do tipo XML, cuja

finalidade é descrever detalhadamente um web service. Essa descrição especifica

as operações que compõem o Web Service e define de forma clara como deve ser o

formato de entrada e saída de cada operação” (GOMES, 2010, p. 16).A Figura 8 ilustra de forma básica a estrutura de um Web Description

Language (WSDL):

Figura 8 - Estrutura básica do WSDL


34/77

3. CAMPO OU ÁREA DE ESTUDO

Este trabalho tem como área de estudo de Sistemas de Informação o

desenvolvimento de aplicativos para dispositivos móveis integrado ao sistema de

gestão com foco na área de cooperativas, possibilitando a mobilidade dos

vendedores através de dispositivos móveis.

3.1. DESCRIÇÃO DA EMPRESA

A Infogen Sistemas foi fundada em 2000, na cidade de Chapecó – SC e tem

como foco principal as cooperativas agropecuárias, de consumo e transportes,

cerealistas, laticínios e indústrias do ramo do agronegócio (INFOGEN SISTEMAS,

2010).

A Infogen Sistemas diferencia-se no mercado pela sua especialização,

profissionalismo e competência, além da abrangência e profundidade com que seus

sistemas informatizam, integram, qualificam e realizam as operações (INFOGEN

SISTEMAS, 2010).

Os sistemas da Infogen são construídos de forma a permitir que os usuários

possam definir, por meio de parâmetros, suas necessidades, minimizando as

ocorrências de customizações e possibilitando que as implantações aconteçam no

menor espaço de tempo e custo, além de facilitar e simplificar futuras atualizações

(INFOGEN SISTEMAS, 2010).

Através do emprego e uso de avançadas tecnologias e metodologias de

desenvolvimento, a Infogen Sistemas garante a permanente evolução e adaptação

de suas soluções, visando a atender e suportar as mais modernas técnicas e

modelos de gestão empresarial (INFOGEN SISTEMAS, 2010).


35/77

34

3.2. GESCOOPER

O GesCooper é um Enterprise Resource Planning (ERP), software de gestão,projetado especificamente para atender empresas do segmento do agronegócio e

cooperativas, as quais apresentam necessidades e particularidades que,

normalmente, não são atendidas pelos tradicionais sistemas de ERP, os quais

exigem grande esforço e altos investimentos para adequação e customização

(INFOGEN SISTEMAS, 2010).

A solução para gestão empresarial GesCooper tem como objetivo principal o

controle informatizado de todos os setores de uma empresa, e é composta por cincograndes subsistemas com seus respectivos módulos (INFOGEN SISTEMAS, 2010).


36/77

4. MÉTODO

4.1. DELIMITAÇÃO DO ESTUDO, MÉTODO E COLETA DE DADOS

O presente trabalho foi realizado em conformidade com as exigências do

curso de Sistemas de Informação da Universidade do Oeste de Santa Catarina –

UNOESC, pelo acadêmico Gabriel C. Vivian, no período de agosto de 2010 a junho

de 2011, utilizando abordagem indutiva, através da técnica de documentação direta,

com a aplicação de questionários.

O questionário foi aplicado tendo como base a definição de Roesch (2009, p.

142), para o qual questionário é um

[...] Instrumento mais utilizando em pesquisa quantitativa, [...] o questionário

não é apenas um formulário, ou um conjunto de questões listadas sem

muita reflexão. O questionário é um instrumento de coleta de dados que

busca mensurar alguma coisa.

O protótipo foi desenvolvido utilizando como base um sistema ERP,desenvolvido pela Infogen Sistemas, localizada na Rua Jorge Lacerda, 80 E, com o

CEP 89.802-105, no centro da cidade de Chapecó (SC), que, atualmente, atende a

um grande número de cooperativas regionais, com o objetivo de criar um protótipo

para solucionar o problema de envio de pedidos dos vendedores, procurando-se

desenvolver funcionalidades em que havia deficiência ou até mesmo funcionalidades

que a empresa não possuía.

4.2. CARACTERIZAÇÃO DO ESTUDO

Através do estudo de caso aplicado sobre os clientes questionados, verificou-

se como o processo de envio de pedidos estava sendo realizado, para

posteriormente, possibilitar o desenvolvimento de um protótipo a fim de solucionar o

possível problema de envio desses pedidos, otimizando a comunicação entre ovendedor e a empresa.


37/77


38/77

37

adquirir uma solução para registrar pedidos de venda por meio de dispositivos

móveis, integrado com o sistema de gestão da Infogen Sistemas, o GesCooper.

O questionário foi disponibilizado aos entrevistados através da ferramentaGoogle Docs, possibilitando aplicar a pesquisa de forma online, agilizando o

processo de análise dos resultados que serão apresentados através de gráficos

oferecidos pelo próprio Google Docs.

4.5. QUESTOES DE PESQUISA

As questões da pesquisa visa verificar a possibilidade do desenvolvimento de

um aplicativo integrado ao ERP, GesCooper, que possa melhorar a comunicação do

vendedor com a cooperativa.


39/77

5. APRESENTACAO E ANÁLISE DOS RESULTADOS

Neste capitulo, serão apresentados no item 5.1 os dados obtidos através do

questionário o qual pode ser encontrado no Apêndice A. Aplicado aos membros da

amostra, com o intuito de verificar a viabilidade de desenvolver um aplicativo para o

problema apresentado nesse projeto, o questionário tem como objetivo avaliar a

necessidade dos clientes para tal solução a fim de comprovar a existência do

problema relatado.

Após a apresentação dos resultados levantados através do questionário, será

apresentado o protótipo proposto como solução para o problema e sua estrutura decomunicação e integração com o Enterprise Resource Planning (ERP) o GesCooper.

5.1. ANÁLISE DOS RESULTADOS

Sendo os vendedores um fator fundamental para a implementação do

protótipo proposto neste trabalho, a primeira pergunta busca verificar os clientes que

possuem vendedores externos.

Quanto aos resultados obtidos, pode-se observar, através da Figura 9, que a

maioria dos clientes, sendo ela 70% dos clientes questionados, possui vendedores.

Sua empresa possui vendedores externos?N %

Sim 7 70Não 3 30

Figura 9 – Clientes que possuem vendedores externosFonte: O autor.

Tendo o pedido de venda como peça fundamental para o faturamento da

empresa, a segunda pergunta busca verificar a dificuldade de comunicação entre o


40/77

39

vendedor e a empresa questionada, permitindo indicar a necessidade de uma

ferramenta que possa sanar essa dificuldade.

Quanto aos resultados obtidos, pôde-se observar, através da Figura 10, quemetade dos clientes, sendo ela 50% dos clientes questionados, têm dificuldade em

receber os pedidos de venda dos seus vendedores.

Seus vendedores externos têm dificuldade de enviar os pedidos de seusclientes?

N %Sim 5 50Não 5 50

Figura 10 – Vendedores com dificuldade de enviar os pedidosFonte: O autor.

Utilizando como base apenas os clientes que possuem vendedores externos,

é possível visualizar, através da Figura 11, que a maioria dos clientes questionados

que possuem vendedores, sendo ela 71%, têm problemas em receber os pedidos de

venda e 29% dos clientes questionados que possuem vendedores não enfrentam adificuldade de comunicação para receber os pedidos de venda.

Possui vendedores e tem dificuldade de comunicaçãoN %

Sim 5 71Não 2 29

Figura 11 – Clientes com vendedores externos e que possuem dificuldade de comunicaçãoFonte: O autor.

Considerando que, dos clientes questionados, o possível motivo por não

terem problemas com o processo de envio de pedidos de venda fosse o fato de já

possuírem um software que permita comunicar eletronicamente esses pedidos, a

terceira pergunta busca verificar os clientes que já possuem um software para tal

finalidade.


41/77

40

Quanto aos resultados obtidos, pôde-se observar, através da Figura 12, que a

minoria, sendo ela 10% dos clientes questionados, possui um software que permita

enviar eletronicamente os pedidos de venda.

A sua empresa já possui um software que permita enviar os pedidos de seusrepresentantes?

N %Sim 1 10Não 9 90

Figura 12 – Empresas que possuem software para envio de pedidosFonte: O autor.

Tendo como fator fundamental agilizar o processo de entrega de mercadoria,

a quarta pergunta busca verificar o interesse do cliente em um software que possa

solucionar o problema de comunicação entre a empresa e o vendedor, permitindo

receber os pedidos de venda com maior segurança e velocidade.

Quanto aos resultados obtidos, pôde-se observar, através da Figura 13, que

a grande maioria, sendo ela 90% dos clientes questionados, tem interesse em tal

solução.

Sua empresa tem interesse nesse tipo de software?N %

Sim 9 90Não 1 10

Figura 13 – Empresas com interesse na soluçãoFonte: O autor.

A pesquisa possibilitou identificar a necessidade do cliente de agilizar a

comunicação com o representante, permitindo agilizar a entrega de mercadoria,

proporcionando mais satisfação ao cliente.


42/77

41

5.2. DESENVOLVIMENTO DO PROTÓTIPO

Apresentam-se, neste item, os passos para o desenvolvimento do protótipo ea sua arquitetura. O protótipo desenvolvido neste projeto está dividido em duas

partes principais, descritas a seguir:

· um módulo Enterprise Java Beans (EJB), utilizando Beans de sessão, em que

eles serão disponibilizados através de Web Service para possibilitar a

comunicação com a MIDlet desenvolvida em J2ME, que será executada no

dispositivo móvel;

· a MIDlet que é executada em um dispositivo móvel, utilizando a tecnologiaJ2ME, sendo que a comunicação é realizada através de um Web Service via

protocolo HTTP e SOAP.

A Figura 14 representa a arquitetura do trabalho proposto, no qual o

dispositivo móvel com suporte ao JAVA realiza suas interações com o Servidor Web,

através de uma conexão Hyper Text Transfer Protocol (HTTP), tanto nas requisições

quanto nas respostas.

Figura 14 - Arquitetura do protótipoFonte: O autor.


43/77

42

5.3. REQUISITOS FUNCIONAIS

São apresentados neste item as funcionalidades do protótipo, isto é, asfunções que o protótipo poderá executar para que o objetivo do trabalho seja

atingido, representados através de requisitos funcionais relacionados abaixo através

das letras RF seguido do número do requisito:

· RF01 – Login - essa funcionalidade deverá permitir ao vendedor informar o

seu usuário e senha e deverá identificar o código de vendedor do usuário que

efetuou o login.

· RF02 – Novo pedido - essa funcionalidade deverá permitir ao vendedor criarum novo pedido. As funcionalidades que deverão estar disponíveis são:

Consultar cliente, Consultar produto, Itens do pedido, Cancelar Pedido e

Finalizar Pedido.

· RF03 – Listar os clientes - essa funcionalidade deverá permitir abrir uma lista

de clientes já cadastrados e disponíveis para realizar o pedido de venda,

possibilitando selecionar o cliente desejado.

· RF04 – Listar produtos - essa funcionalidade deverá permitir abrir uma lista deprodutos já cadastrados e disponíveis, possibilitando selecionar o produto

desejado.

· RF05 – Listar formas - essa funcionalidade deverá permitir ao vendedor

visualizar as formas de pagamento já cadastradas e disponíveis,

possibilitando selecionar a forma de pagamento desejada.

· RF06 – Confirmar produto - essa funcionalidade deverá permitir ao vendedor

visualizar o preço do produto e especificar a quantidade desejada.· RF07 – Itens do pedido - essa funcionalidade deverá permitir ao vendedor

consultar os produtos que fazem parte do pedido.

· RF08 – Cancelar pedido - essa funcionalidade deverá permitir ao vendedor

cancelar o pedido, limpando todos os dados do pedido.

· RF09 – Finalizar pedido - essa funcionalidade deverá permitir ao vendedor

finalizar o pedido, enviando-o à base de dados central do sistema.


44/77

43

· RN01 – O preço do produto não pode ser alterado pelo vendedor.

· RN02 – O pedido só pode ser cancelado pelo vendedor se ainda não estiverfinalizado.

5.4. REQUISITOS NÃO FUNCIONAIS

São apresentados neste item os requisitos não funcionais do protótipo

representados através das letras RNF seguido do número do requisito.

· RNF01 – O Aplicativo deve garantir a segurança das informações.

· RNF02 – Custo de implantação baixo.

· RNF03 – Entrada mínima de dados.

· RNF04 – Aparência simples.

· RNF04 – Independente se Sistema Operacional.


45/77

44

5.5. SERVIDOR

O Servidor Web desenvolvido utiliza como base de implementação o padrãoSOAP e trafega as mensagens XML sobre o protocolo HTTP. Para seu

desenvolvimento, foi utilizada a Interface de Desenvolvimento (IDE) NetBeans 6.9.

O ambiente de desenvolvimento foi composto por:

· NetBeans IDE 6.9;

· Servidor GlassFish 3;

· Versão Java J2EE6;

· Microsoft SQL Server 2008.

5.5.1. Diagrama de Classe

A Documentação de todos os diagramas de classe pode ser encontrada no

Apêndice B.


46/77

45

5.5.2. ER – Diagrama De Entidade Relacionamento

O Web Service, através das classes de entidade do banco de dados, acessao banco de dados SQL Server 2008 do ERP, o GesCooper. A figura 15 permite

visualizar a estrutura do banco de dados utilizada para o desenvolvimento do

protótipo.

Figura 15 - Diagrama de Entidade RelacionamentoFonte: O autor.

Transacionadores: na tabela Transacionadores são armazenados todos os clientes

e fornecedores.

Produtos: na tabela Produtos são armazenados todos os produtos.

ProdutosLevel4: na tabela ProdutosLevel4 são armazenadas as tabelas de preço

do produto. É onde uma tabela de preço é referenciada ao produto.

PedVendas: na tabela PedVendas são armazenados os pedidos de vendas e é

onde será registrado o pedido através do protótipo desenvolvido neste trabalho.

PedVendasLevel1: na tabela PedVendasLevel1 são armazenados os produtos

referentes a um determinado pedido e é onde serão registrados os itens do pedido

gerado através do protótipo desenvolvido neste trabalho.


47/77

46

CadUsuarios: na tabela CadUsuarios são armazenadas todas as informações

referentes ao usuário. Essa tabela está ligada ao cadastro de transacionadores e

através dela é possível identificar o vendedor.

5.5.3. Criação do Web Service

Com os requisitos definidos, o passo seguinte foi desenvolver um Web

Service a fim de disponibilizar as funções necessárias para que os requisitos do

aplicativo móvel sejam atendidos.Utilizando os recursos do Netbeans 6.9, foi possível criar o Web Service com

as funções necessárias para a funcionalidade do protótipo, através dos recursos do

EJB e as annotations @WebService, @WebMethod e @WebParam.

A seguir, será apresentada cada WSDL criada e os resultados de cada

operação disponível, representada no arquivo WSDL pelo elemento .

A Figura 16 apresenta a WSDL CadUsuariosWs. Nela está implementado o

método validarUsuario, o qual tem como parâmetros de entrada o nome do usuárioe sua senha.

Figura 16 - WSDL Cadastro de UsuáriosFonte: O autor.

O resultado do método validarUsuario executado a partir do navegador é

apresentado através da Figura 17, onde se têm como resultado todas as

informações referentes ao perfil do usuário, sendo que, para os vendedores, pode-

se destacar a Tag , utilizada para reconhecer o código do vendedor no

momento do login.


48/77

47

Figura 17 – Resultado da execução do método validarUsuario Fonte: O autor.

A Figura 18 apresenta a WSDL TransacionadoresWs. Nela está

implementado o método listarTransacionadores.

Figura 18 - WDSL TransacionadoresFonte: O autor.

O resultado do método listarTransacionadores, executado a partir do

navegador, é apresentado através da Figura 19, onde se tem como resultado uma

lista de transacionadores já cadastrados no sistema GesCooper.


49/77

48

Figura 19 – Resultado da execução do método listarTransacionadoresFonte: O autor


50/77

49

A Figura 20 apresenta a WSDL FormasWs. Nela está implementado o

método listarFormas.

Figura 20 - WSDL FormasFonte: O autor

O resultado do método listarFormas, executado a partir do navegador, é

apresentado através da Figura 21, onde se tem como resultado uma lista de formas

de pagamento já cadastradas no sistema GesCooper. A Tag representa o

código da forma de pagamento e a Tag representa a descrição da forma

de pagamento.

Figura 21 – Resultado da execução do método listarFormas Fonte: O autor


51/77

50

A Figura 22 apresenta a WSDL ProdutosWs. Nela está implementado o

método listarProdutos.

Figura 22 – WSDL ProdutosFonte: O autor

O resultado do método listarProdutos, executado a partir do navegador, é

apresentado através da Figura 23, onde se tem como resultado uma lista de

produtos disponíveis para venda via dispositivo móvel.

Figura 23 – Resultado da execução do método listrarProdutosFonte: O autor


52/77

51

A Figura 24 apresenta a WSDL ProdustosLevel4Ws. Nela está implementado

o método listarProdutosLevel4, onde se tem como parâmetros de entrada o código

do produto.

Figura 24 – WSDL ProdutosLevel4Fonte: O autor

O resultado do método listarProdutosLevel4, executado a partir do navegador,

é apresentado através da Figura 25, onde se tem como resultado o valor do produto

solicitado através do parâmetro de entrada. No caso da figura 25, o parâmetro de

entrada foi o produto 62640. A Tag representa o preço desse

produto.

Figura 25 - Resultado da execução do método listrarProdutoslevel4Fonte: O autor


53/77

52

A Figura 26 apresenta a WSDL PedVendasWs. Nela está implementado o

método gerPvdNumero, cuja finalidade é retornar o código para um novo pedido, e o

método finalizar pedido, onde se tem como parâmetros de entrada o cliente, a formade pagamento, o código do vendedor, os produtos e suas quantidades.

Figura 26 – WSDL PedVendasFonte: O autor

Todas as informações necessárias para a formação do pedido podem serencontradas a partir das WSDL criadas e apresentadas anteriormente. Assim, com

os arquivos WDSL definidos, foi possível iniciar o desenvolvimento do cliente. Com

os recursos do próprio NetBenas 6.9 foi possível gerar as classes Stubs que são

responsáveis pela comunicação do cliente e o serviço baseado em WSDL.

No próximo item, apresenta-se o processo de desenvolvimento do aplicativo

cliente.


54/77

53

5.6. CLIENTE

O desenvolvimento da MIDlet foi realizado utilizando a linguagem deprogramação JAVA, especificamente o J2ME, pois sua portabilidade permite que o

aplicativo não seja dependente de um único sistema operacional, sendo que, para

ele rodar o dispositivo móvel, precisa apenas ter suporte a aplicativos JAVA.

O protótipo foi testado durante o processo de desenvolvimento com um

emulador disponibilizado pelo próprio editor de código utilizado no projeto, o

NetBeans 6.9, e também com o Smartphone da LG o P500h.

O ambiente de desenvolvimento foi composto por:· NetBeans IDE 6.9;

· Tipo de Plataforma: CLDC/MIDP;

· Plataforma do emulador: Java(TM) Platform Micro Edition SDK 3.0;

· Dispositivo: DefaultFxTouchPhone1;

· Configuração do dispositivo: CLDC 1.1;

· Perfil do dispositivo: MIDP 2.1;

O Smartphone LG P500h permite executar aplicações Java. Esse dispositivovem com o sistema operacional Android 2.2.1 e por isso é necessário converter os

arquivos Java Application Descriptor (JAD) e Java Archive (JAR) para Android

Pacote (APK), possibilitando, então, que a MIDlet seja instalada no Smartphone,

conforme representado na Figura 27.

Figura 27 - Converter J2ME MIDP (JAD) para Android pacote (APK)Fonte: O autor

Essa conversão pode ser realizada através do site netmite.com através da

opção Converter J2ME MIDP (JAD) para Android pacote (APK), onde os arquivos

JAD e JAR serão convertiidos para um arquivo APK que então será reconhecidopelo android como um arquivo válido, permitindo a sua execução.


55/77


56/77

55

Caso de Uso CSU002 – Registrar Pedido Ator pr incipal Vendedor Atores

secundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor pararegistrar um novo pedido.

Pré-Condições Estar logado no aplicativoPós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: O vendedor seleciona aopção Novo Pedido.

2: O sistema apresenta uma tela comas opções, Cliente, Produto, Itens,Cancelar e Finalizar.

3: CSU003 6: O sistema preenche o campocliente do pedido com os dados docliente selecionado.

7: CSU005 10: O sistema preenche o campoforma do pedido com os dados daforma selecionada

11: CSU004 14: O sistema apresenta uma telacom o valor unitário do produto e ocampo quantidade.

15: O vendedor informa aquantidade desejada econfirma.

16: O produto é adicionado ao pedidoe o sistema apresenta o valor total dopedido.

17: CSU007 18: O pedido é enviado ao banco dedados central do sistema onde seráanalisado por um responsável.

Referência RF02, RF03, RF04, RF05, RF06, RF07, RF08, RF09, RN01, RN02.Tabela 2 - Documentação do Caso de Uso CSU002


57/77

56

Caso de Uso CSU003 – Selecionar Cliente Ator pr incipal Vendedor

AtoressecundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor para

consultar um cliente.Pré-Condições Ter iniciado um Novo Pedido.Pós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: O vendedor seleciona aopção de consulta de cliente.

2: São listados os Clientes jácadastradas (Código, Nome).

O vendedor clica sobre ocliente desejado e depoisclica em Confirmar.

Referência RF03Tabela 3 - Documentação do Caso de Uso CSU003

Caso de Uso CSU004 – Selecionar Produto Ator pr incipal Vendedor AtoressecundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor para

consultar um produto.Pré-Condições Ter iniciado um Novo Pedido. Pós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: Selecionar a opção deconsulta de produto.

2: São listados os Produtos jácadastradas (Código, Nome).

O vendedor clica sobre oproduto desejado e depois

clica em Confirmar. Referência RF04.

Tabela 4 - Documentação do Caso de Uso CSU004


58/77

57

Caso de Uso CSU005 – Selecionar forma de pagamento Ator pr incipal Vendedor

AtoressecundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor para

consultar um produto.Pré-Condições Ter iniciado um Novo Pedido. Pós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: O vendedor seleciona aopção Menu\Forma.

2: São listadas as formas de pagamentodisponível (Código, Descrição).

3: O vendedor clica sobre a

forma desejada e depoisclica em Confirmar.

Referência RF05.Tabela 5 - Documentação do Caso de Uso CSU005

Caso de Uso CSU006 – Cancelar Pedido Ator pr incipal Vendedor AtoressecundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor para

cancelar um pedido.Pré-Condições Ter iniciado um pedido.Pós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: O vendedor seleciona aopção Menu\Cancelar.

2: O pedido é cancelado e o sistemaretorna a tela inicial.

Referência RF06, RN02.Tabela 6 - Documentação do Caso de Uso CSU006


59/77

58

Caso de Uso CSU007 – Final izar Pedido Ator pr incipal Vendedor Atores

secundáriosResumo Esse caso de uso descreve as etapas percorridas pelo vendedor parafinalizar o pedido.

Pré-Condições Ter iniciado um pedido.Pós-Condições

Fluxo Base

Ações do Ator Ações do Sistema1: O vendedor seleciona aopção Menu\Finalizar.

2: O pedido é enviado ao banco dedados central, o sistema retorna umamensagem com o número do pedido.

Referência RF09.Tabela 7 - Documentação do Caso de Uso CSU007

5.6.2. Diagrama de classe

A Documentação de todos os diagramas de classe pode ser encontrada no

Apêndice C.


60/77

59

5.6.3. Fluxo de execução da MIDlet

Na Figura 29, é apresentado o fluxo de execução da implementação jáconcluída da MIDlet, retirado do IDE NetBeans 6.9.

Figura 29 - Fluxo de execução da MIDletFonte: NetBeans 6.9 O autor.

Através da Figura 29 é possível visualizar que o protótipo foi composto por

uma tela de Splash, uma tela de Login, três objetos do tipo formulário, quatro objetos

to tipo List, dois objetos do tipo waitScreen e dois objetos do tipo Alert.

Através dos formulários foi possível solicitar a entrada de dados do usuário.

Com os objetos do tipo List foi possível criar uma lista de dados em que o usuário

pode selecionar um determinado registro, utilizado no protótipo para listar os cliente,

formas de pagamento, produtos e itens do pedido. Em caso de demora com a

listagem de dados, foram utilizados os objetos do tipo waitScreen em que é

apresentada uma imagem de espera para que o usuário não pense que o sistema

parou de funcionar. Em caso de erro de comunicação na listagem dos clientes ou

dos produtos, foram utilizados os objetos do tipo Alert para comunicar o problema ao

usuário através de uma mensagem de alerta.

A interação entre essas telas e os passos para sua utilização é apresentada

no item a seguir.


61/77

60

5.6.3.1. Demonstração da execução da MIDlet

A seguir, serão apresentadas as telas do protótipo desenvolvido neste projetoe os passos para sua utilização. Para a apresentação das telas, foi utilizado um

emulador disponibilizado pela ferramenta de desenvolvimento o NetBeans 6.9.

Ao iniciar a aplicação, é apresentada uma tela de inicialização do aplicativo,

conforme apresentado na Figura 30.

Figura 30 – Tela de inicialização do aplicativoFonte: O autor

Depois de inicializada a aplicação, é apresentada ao vendedor uma tela de

login em que o vendedor informa o usuário e senha. Através da opção login o

aplicativo inicia a validação.


62/77

61

Figura 31 – Tela de login do aplicativoFonte: O autor

Se o usuário e senha estiverem corretos, o sistema retorna o código principal

do vendedor, ou seja, o código que corresponde ao cadastro de

transacionador/cliente do vendedor vinculado ao cadastro de usuário. Na tela inicial,

conforme Figura 32, têm-se as opções Novo Pedido e Sair. A opção sair faz comque o aplicativo seja finalizado, e a opção Novo Pedido permite que seja realizado

um novo pedido.

Figura 32 – Tela de inicio do aplicativoFonte: O autor


63/77

62

Selecionando a opção Novo Pedido um novo pedido será iniciado, conforme

apresentado na Figura 33. Através do Menu, têm-se as opções, Cliente, Forma,

Produto, Itens, Cancelar e Finalizar.

Figura 33 – Tela inicial do pedidoFonte: O autor

Selecionando a opção Menu\Cliente será apresentada uma lista de clientes.

Tem-se disponível a opção voltar, em que o vendedor pode Voltar à tela inicial do

pedido e a opção Confirmar que irá incluir o cliente selecionado ao pedido, conforme

apresentado na Figura 34.

Figura 34 – Tela de consulta dos clientesFonte: O autor


64/77

63

Selecionando Menu\Forma será apresentada uma lista de formas de

pagamento. Tem-se disponível a opção voltar, em que o vendedor pode Voltar à tela

inicial do pedido e a opção Confirmar que irá incluir a forma de pagamentoselecionada ao pedido, conforme apresentado na Figura 35.

Figura 35 – Tela de consulta das formas de pagamentoFonte: O autor

Selecionando Menu\Produto será apresentada uma lista de produtos. Tem-se

disponível a opção voltar, em que o vendedor pode Voltar à tela inicial do pedido e a

opção Confirmar. Quando um produto é selecionado e a opção Confirmar é

executada, o aplicativo abre uma tela com o preço do produto selecionado onde o

vendedor informa a quantidade desejada, conforme apresentado na Figura 36.


65/77

64

Figura 36 – Tela de consulta dos produtosFonte: O autor

Após informar a quantidade, selecionando a opção Menu\Incluir, o produto é

adicionado aos itens do pedido. Tem-se, então, disponível a opção Produto que

permite que mais produtos sejam adicionados ao pedido e Confirmar, que irá

totalizar o pedido, conforme apresentado na Figura 37.

Figura 37 – Tela de consulta dos itens do pedidoFonte: O autor

Com os itens já adicionados ao pedido é possível finalizar e enviar o pedido

através da opção Menu\Finalizar. Essa opção irá finalizar o pedido, enviando-o à

base de dados do ERP. Assim que o pedido é enviado, uma mensagem é gerada na


66/77

65

tela, através de um alerta, mostrando o número do pedido gerado, conforme Figura

38. O número do pedido gerado no exemplo é o 8336.

Figura 38 – Tela de confirmação do envio do pedidoFonte: O autor

Após a finalização do pedido é possível consultá-lo através do GesCooper,

conforme se mostra na Figura 39.

Figura 39 – Tela do pedido do ERP GesCooperFonte: Infogen Sistemas ERP GesCooper


67/77

CONCLUSÃO

Com este trabalho foi possível analisar a evolução dos dispositivos móveis

bem como a tecnologia Java Micro Edition (J2ME), disponível para o

desenvolvimento de aplicativos para esses dispositivos e os benefícios que essa

tecnologia pode trazer, quando integrada ao Enterprise Resource Planning (ERP) da

empresa.

Conclui-se que, utilizando dispositivos móveis com informações atualizadas, é

possível melhorar os processos das empresas. O protótipo desenvolvido neste

trabalho comprovou que é possível utilizar J2ME para desenvolver o aplicativo e

Web Service para integrar ao Sistema de Gestão das empresas.

Para trabalhos futuros, durante o desenvolvimento do protótipo, surgiu a idéia

de implementar o armazenamento dos dados, como consulta de clientes, formas de

pagamento e produtos no próprio dispositivo, permitindo que o aplicativo possa

trabalhar sem conexão com a internet, outros estudos poderão ser realizados a fim

de implementar as telas, utilizando o Canvas, que permite criar telas mais

apresentáveis ao usuário.

O trabalho atendeu os seus objetivos, apesar de simples, o protótipo

apresentado nesse trabalho pode atender as funcionalidades básicas para a

formulação de um pedido.


68/77

REFERÊNCIAS

AHMED, Khawar Zaman; UMRYSH, Cary E. Desenvolvendo aplicações

comerciais em Java com J2EE e UML. Rio de Janeiro: Editora Ciência Moderna

Ltda, 2002. 302 p.

APACHE TOMCAT, Disponível em: http://tomcat.apache.org/. Acesso em:

25/09/2010.

ARAUJO, Fábio Bicalho de. Desenvolvimento de Software para DispositivosMóveis. Disponível em:

http://www.pucrio.br/pibic/relatorio_resumo2006/relatorio/CTC/Cetuc/F%E1bio%20Bi

calho%20de%20Araujo.pdf . Acesso em 19/09/2010.

CASTELO, Marcelo. 24h Online - A popularização dos smartphones está

chegando, 21 Janeiro 2010. Disponível em:

http://www.mobilepedia.com.br/artigos/24h-online-a-popularizacao-dos-smartphones-esta-chegando. Acessado em: 26/09/2010.

CASTRO, Elizabeth, 2001. XML para World Wide Web. Rio de Janeiro: Editora

Campus, 2001. 269 p.

CAVALCANTI, Vitor, 2009. Smartphones: o que será do futuro? . Disponível em:

http://www.itweb.com.br/noticias/index.asp?cod=58677. Acesso em 11/09/2010.

DEITEL, H. M; DEITEL, P. J.. Java Como Programar . 3. Ed. Porto Alegre:

Bookman, 2001. 1201 p.

FIORESI, Cristiano. Conceitos básicos das plataformas Java e J2ME, 2007.

Disponível em:

http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=6484. Acesso em

12/09/2010.


69/77

GOMES, Daniel Andorno. Web Services SOAP em Java: Guia prático para o

desenvolvimento de web service em Java. 1. Ed. São Paulo: novatec, 2010. 183

p.

GOMES, Lucas de Souza Reis. Desenvolvimento de Aplicações de Dispositivos

Móveis com J2ME e Integração com Web Service. 2005. Trabalho de conclusão

de curso (Bacharelado em Sistemas de Informação) – Universidade Federal de

Santa Catarina, UFSC. Florianópolis – SC.

GUEDES, Gilleanes T. A.. UML Uma Abordagem Prática. São Paulo: Novatec,

2006. 336p.

INFOGEN SISTEMAS. Conheça-nos. Disponível em: http://www.infogen.inf.br.

Acesso em: 25/09/2010.

LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações móveis:

Arquitetura pro jeto e desenvolvimento . São Paulo: Pearson Education do Brasil,

2005. 328 p.

MAGALHÃES, Leitão; MARGALHO, Nelson Antonio. Comparação de ferramentas

para implementação de Web Service. 2007. Trabalho de conclusão de curso

(Bacharelado em Ciência da Computação na área de Engenharia de Software) -

Universidade da Amazônia, UNAMA. Belém – PA.

MUCHOW, John W. Core J2ME Tecnologia e MIDP. São Paulo: Pearson MakronBooks, 2004. 600 p.

NIEMEYER, Patrick; KNUDSEN, Jonathan. Aprendendo Java 2 sdk. Rio de

Janeiro: Campus, 2000. 700 p.

NORRIS, Grant; HURLEY R, James; HARTLEY M, Kenneth; DUNLEAVY R, John;

BALLS D, John. E-Business e ERP: Transformando as organizações. Rio de

Janeiro: Qualitymark, 2001. 193 p.


70/77

OLIVEIRA, Jayr Figueiredo de. Sistemas de Informação: Um enfoque Gerencial

Inserido no Contexto Empresarial e Tecnológico. São Paulo: Érica, 2000. 300p.

REVISTA DE CIENCIAS EMPRESARIAIS. Maringá Management, v. 2, n.1, p. 7-19,

jan. /jun. 2005.

ROESCH, Sylvia Maria Azevedo. Sistemas Projeto de estágio e de pesquisa em

administração: Guia para Estágios, Trabalhos de Conclusão, Dissertações e

Estudos de caso. São Paulo: Atlas, 2009. 300p.

PELEGRI, Eduardo; YOSHIDA, Yutaka; MOUSSINE, Aléxis, 2007. The GlassFish

Community: Delivering a Java EE Application Server. Disponível em

https://glassfish.dev.java.net/faq/v2/GlassFishOverview.pdf.

SIERRA, Kathy; BATES, Bert. Use a Cabeça! Java. 2. Ed. Rio de Janeiro: Alta

Books, 2010. 484 p.

SOUZA, Adilson Silveira de. Utilização de Tecnologia J2ME para

Desenvolvimento de Sistemas de M-Banking. 2008. Trabalho de conclusão como

requisito parcial para a obtenção do grau de Especialista – Universidade Federal do

Rio Grande do Sul, UFRGS. Porto Alegra – RS.

STREIBEL, Martin, 2005. Implementando Web Service. Disponível em:

http://palazzo.pro.br/artigos/martin.htm. Acesso em 12/09/2010.KALIN, Martin. Java Web Services: Implementando. Rio de Janeiro: Alta Books,

2010. 312 p.


71/77

APÊNDICES


72/77

71

APÊNDICE A – Questionário

Razão social da empresa:

E-mail:

1. Sua empresa possui vendedores externos? *

( ) Sim ( ) Não

2. Seus vendedores externos têm dificuldade de enviar os pedidos de seus

clientes?*

( ) Sim ( ) Não

3. Quantos vendedores sua empresa possui? (aproximadamente)

4. A sua empresa já possui um software que permita enviar os pedidos de seusrepresentantes?* (Utilizando, Palm, Celulares, SmartPhone ou outro dispositivo

portátil)

( ) Sim ( ) Não

5. Qual o software que sua empresa possui? (Se você respondeu sim para a

questão 4)

6. Sua empresa tem interesse nesse tipo de software?*

( ) Sim ( ) Não


73/77

72

APÊNDICE B – Diagrama de classe Web Service

class Class WS CadUsuarios

Serializable

Cadusuarios

- serialVersionUID: long = 1L {readOnly}

- usuCod: String

- empCod: Short

- usuFilCod : Short

- usuTraCod: Integer

- usuSenha: String

- usuEmail : String

- usuConCod: Strin g

- usuHisPreCod: Intege r

+ Cadusuarios()

+ Cadusuarios(String)

+ getUsuCod() : Strin g

+ setUsuCod(Strin g) : void

+ getEm pCod() : Short

+ setEmpCod(Short) : void

+ getUsuFilCo d() : Short

+ setUsuFil Cod(Short) : void

+ getUsuTraCod() : Intege r

+ setUsuTraCod (Integer) : void

+ getUsuSenha() : String

+ setUsuSenh a(String ) : void

+ getUsuEmail () : String

+ setUsuEmail (String) : void

+ getUsuConCod() : String

+ setUsuConCod(Stri ng) : void

+ getUsuHisPreCod() : Intege r

+ setUsuHisPreCod(Intege r) : void

+ setUsuWorkstati on(Strin g) : void

+ hashCode() : int

+ equals(Object) : boolean

+ toString() : String

CadusuariosFacade

- em: EntityManager

+ validarUsuario(String, String) : List

«interface»

CadusuariosFacadeLocal

«interface»

CadusuariosFacadeRemote

+ valida rUsuario(String, String) : List

CadusuariosWs

- ca dusuario sFacadeBean: CadusuariosFacadeRem ote

+ valida rUsuario(String, String) : List

-cadusuariosFacadeBean

class Class WS Formas

Serializable

Formas

- serialVersionUID: long = 1L {readOnly}

- pagCod: Short

- pagNom: String

+ Formas()

+ Formas(Short)

+ getPagCod() : Short

+ setPagCod(Short) : void

+ getPagNom() : String

+ setPagNom(String) : void

+ hashCode() : int

+ equals(Object) : boolean

+ toString() : String

FormasFacade

- em: EntityManage r

+ li starFormas() : List

«interface»

FormasFacadeLocal

«interface»

FormasFacadeRemote

+ listarFormas() : List

FormasWs

- formasFaceBean: FormasFacadeRemote

+ li starFormas() : Li st

-

formasFaceBean


74/77

73

APÊNDICE B – Diagrama de classe Web Service (Cont.)

clas s Class WS Transaci onadores

Serializable

Transacionadores

- serialVe rsionUID: long = 1L {readOnly}

- traCod: Integer

- traNom: String

- traEnd: String

- traNumEnd: String

- traBairro: String

- traPaiCod: String

- traEstCod: Strin g

- traMunCod: Integer

- traFone: String

- traEmail : String

- traCpf: String

- traCnpj: Stri

universidade do oeste de santa catarina unoesc unidade chapecó

Documents