TC2 - reta final marcelo 21 11 18 22.doc

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL

FACULDADE DE INFORMÁTICA

AUTOMAÇÃO DA FORÇA DE VENDAS UTILIZANDO DISPOSITIVOS MÓVEIS E SERVIÇOS WEB

TRABALHO DE CONCLUSÃO II

Marcelo Tocchetto, Tiago da Silveira Duarte

Orientador: Professor Eduardo Augusto Bezerra

Porto Alegre, 27 de novembro de 2006.

RESUMO

Em sistemas para gerência de vendedores móveis da atualidade, pedidos são

realizados através de formulários preenchidos a campo no momento da venda, e

entregues na sede da empresa pelos próprios vendedores. Este método apresenta

deficiências que podem comprometer a realização da venda, como por exemplo, perda

de tempo no preenchimento dos formulários, possibilidade de inconsistência nas

informações, e demora na liberação das mercadorias constantes no pedido.

A fim de reduzir estas deficiências, as empresas vêm recorrendo a utilização de

sistemas de automação da força de vendas, que com o auxílio de dispositivos móveis

permitem ao vendedor criar pedidos e acessar informações sobre os clientes e

produtos da empresa (estoque) no momento da venda. Algumas das novas soluções

propõem a utilização de dispositivos móveis para armazenamento dos pedidos e

transmissão para processamento pela empresa, assim que estabelecida uma conexão

com a rede Internet. Essa solução representa uma boa alternativa para o sistema

tradicional em uso em grande parte das empresas, e é exatamente nesse contexto

que o presente projeto se insere.

2

SUMÁRIO

1 INTRODUÇÃO.....................................................................................................................7

1.1 MOTIVAÇÃO................................................................................................................... 81.2 JUSTIFICATIVA DO TRABALHO....................................................................................81.3 OBJETIVO GERAL..........................................................................................................81.4 OBJETIVOS ESPECÍFICOS...........................................................................................91.5 METODOLOGIA..............................................................................................................91.6 ORGANIZAÇÃO DO TEXTO.........................................................................................10

2 ANÁLISE DE VENDAS E SISTEMAS DE AUTOMAÇÃO SIMILARES..............................11

2.1 O PROCESSO DE VENDAS.........................................................................................112.1.1 PRÉ-VENDA.....................................................................................................112.1.2 DURANTE A VENDA........................................................................................122.1.3 PÓS-VENDA....................................................................................................12

2.2 ESTUDOS DE CASOS – SISTEMAS DE AUTOMAÇÃO SIMILARES..........................122.2.1 SOLUÇÃO EM ESTUDO: SIV Enterprise.........................................................132.2.2 SOLUÇÃO EM ESTUDO: Mercador.................................................................152.2.3 SOLUÇÃO EM ESTUDO: EASYVEN...............................................................152.2.4 ANÁLISE E CONCLUSÕES.............................................................................16

3 SUPORTE A MOBILIDADE...............................................................................................17

3.1 VISÃO GERAL..............................................................................................................173.2 DISPOSITIVO MÓVEL SELECIONADO.......................................................................173.3 TECNOLOGIA GSM/GPRS...........................................................................................183.4 BLUETOOTH.................................................................................................................19

4 FERRAMENTAS E TECNOLOGIAS..................................................................................21

4.1 TECNOLOGIA JAVA.....................................................................................................214.1.1 VISÃO GERAL..................................................................................................214.1.2 JAVA EE...........................................................................................................214.1.3 J2ME................................................................................................................22

4.2 FRAMEWORKS JAVA..................................................................................................234.2.1 STRUTS E MVC...............................................................................................244.2.2 AXIS E WEB SERVICES..................................................................................264.2.3 JAVA PERSISTENCE E MAPEAMENTO OBJETO RELACIONAL..................27

4.3 BIBLIOTECAS JAVA.....................................................................................................274.3.1 JASPER REPORTS.........................................................................................274.3.2 KSOAP2...........................................................................................................284.3.3 DOJO/AJAX......................................................................................................28

4.4 SERVIDORES...............................................................................................................294.4.1 TOMCAT..........................................................................................................294.4.2 MYSQL - BANCO DE DADOS..........................................................................30

4.5 AMBIENTE DE DESENVOLVIMENTO.........................................................................30

5 PROJETO DO SISTEMA...................................................................................................33

5.1 VISÃO GERAL..............................................................................................................335.2 APLICAÇÃO CELULAR – MÓDULO I...........................................................................34

5.2.1 DIAGRAMA DE CASO DE USO.......................................................................355.2.2 ESPECIFICAÇÃO: EFETUAR LOGIN..............................................................375.2.3 ESPECIFICAÇÃO: GERENCIAR PEDIDO.......................................................395.2.4 ESPECIFICAÇÃO: LISTAR CLIENTES DA ROTA...........................................435.2.5 ESPECIFICAÇÃO: LISTAR CLIENTES DA AGENDA......................................445.2.6 ESPECIFICAÇÃO: VISUALIZAR CLIENTE......................................................455.2.7 ESPECIFICAÇÃO: VERIFICAR STATUS DO CLIENTE..................................475.2.8 ESPECIFICAÇÃO: LISTAR PRODUTOS.........................................................485.2.9 ESPECIFICAÇÃO: VISUALIZAR ÚLTIMO PEDIDO.........................................49

5.3 SERVIÇOS WEB E APLICAÇÃO WEB – MÓDULOS II, III...........................................51

3

5.3.1 DIAGRAMA DE CASO DE USO.......................................................................515.3.2 ESPECIFICAÇÃO: EFETUAR LOGIN..............................................................545.3.3 ESPECIFICAÇÃO: GERENCIAR USUÁRIOS..................................................555.3.4 ESPECIFICAÇÃO: ALTERAR SENHA DO USUÁRIO AUTENTICADO...........585.3.5 ESPECIFICAÇÃO: GERENCIAR ROTA..........................................................605.3.6 ESPECIFICAÇÃO: GERENCIAR PEDIDOS....................................................625.3.7 ESPECIFICAÇÃO: GERENCIAR PRODUTOS................................................645.3.8 ESPECIFICAÇÃO: GERENCIAR CLIENTES...................................................675.3.9 ESPECIFICAÇÃO: GERENCIAR AGENDA.....................................................705.3.10 ESPECIFICAÇÃO: GERENCIAR VENDEDORES...........................................725.3.11 ESPECIFICAÇÃO: GERAR RELATÓRIOS......................................................75

5.4 MODELOS DE ANÁLISE...............................................................................................775.4.1 DIAGRAMA DE CLASSE: AGENDA................................................................775.4.2 DIAGRAMA DE CLASSE: HISTÓRICO DE PRODUTOS................................775.4.3 DIAGRAMA DE CLASSE: PEDIDO..................................................................785.4.4 DIAGRAMA DE CLASSE: ROTA......................................................................795.4.5 DIAGRAMA DE CLASSE: USUÁRIO...............................................................795.4.6 DIAGRAMA DE CLASSE: ENTIDADES BASE.................................................80

5.5 MODELOS DE PROJETO.............................................................................................815.5.1 DIAGRAMA DE CLASSE: APLICAÇÃO CELULAR..........................................815.5.2 DIAGRAMA DE CLASSE: APLICAÇÃO WEB – SERVLET..............................83

5.6 ORGANIZAÇÃO DA ARQUITETURA (PACKAGES)....................................................85

6 DISCUSSÃO DA IMPLEMENTAÇÃO................................................................................86

7 CONCLUSÃO.................................................................................................................... 89

BIBLIOGRAFIA.......................................................................................................................... 91

ANEXOS.................................................................................................................................... 93

APÊNDICE 1 - CRONOGRAMA................................................................................................93

APÊNDICE 2 – CELULARES PESQUISADOS..........................................................................96

4

Lista de Tabelas

Tabela 1: Comparativo de custos para transferências nos formatos XML e CSV........86

5

Lista de Figuras

Figura 1: Dispositivo móvel utilizado.............................................................................18Figura 2: Diagrama do MVC implementado pelo Struts................................................25Figura 3: Diagrama de blocos referente à arquitetura do sistema................................33Figura 4: Arquitetura da solução...................................................................................34

6

1 INTRODUÇÃO

Com o avanço da informática e de dispositivos que se utilizam dela, existe uma

tendência no setor de telefonia móvel de desenvolver aparelhos celulares mais

adaptados ao cotidiano de seus usuários, incluindo características antes exclusivas de

outros aparelhos. Por exemplo, em um único aparelho é possível encontrar mp3

player, rádio FM, navegação na Internet, download de jogos e aplicativos pela Internet.

Este avanço vem sendo consolidado graças a um esforço de padronização entre

os equipamentos em termos de sistema operacional embarcado (Ex: Symbian),

linguagens de programação suportadas nestes equipamentos (Ex: J2ME através da

máquina virtual Java) e meios de comunicação com outros dispositivos (Ex:

protocolos, redes GSM, Bluetooth, Infravermelho, USB) [1][2].

Como conseqüência desta tendência, existe a disposição uma vasta gama de

dispositivos móveis capazes de rodar aplicações sobre a plataforma J2ME e com um

promissor mercado de desenvolvimento de software, estimulado pelos próprios

fabricantes de celulares que visualizam este mercado como mais uma forma de

agregar valor a seus produtos e criar o desejo e a necessidade de consumo dos

aparelhos por seus clientes [3].

Atualmente, estes recursos tecnológicos tem sido fator fundamental para o

desenvolvimento de algumas empresas, principalmente quando se torna necessário

um controle exato de informações como preferências de clientes, histórico de vendas,

histórico de comissões de vendedores, metas de vendas, previsão de vendas, etc.

Dessa forma, a proposta deste trabalho de conclusão foi construir uma solução

acessível aos vendedores através de dispositivos móveis (ex.: telefones celulares)

capaz de gerenciar informações sobre clientes, realizar pedidos, verificar listas de

produtos, preços. Essas informações serão acessíveis pelos administradores da

empresa através de um sistema web de forma que possam atribuir rotas, cadastrar

produtos, gerenciar pedidos, verificar estoques e realizar relatórios de vendas,

produtos mais vendidos, etc.

A automação da força de vendas pode também ser justificada por dificuldades

enfrentadas por vendedores tais como perda de tempo no preenchimento de

formulários, relatórios desatualizados e dados inconsistentes. Sendo essa

comunicação entre vendedores e empresa normalmente dada de forma lenta e

imprecisa.

A solução proposta torna o processo mais fácil, mais confiável para a empresa,

para o vendedor e para o cliente, auxiliando na tomada de decisões, agilizando as

7

negociações e aumentando assim a satisfação do cliente através da integração entre

empresa e vendedor.

1.1 MOTIVAÇÃO

O desenvolvimento de aplicações sobre a plataforma J2ME é um segmento

pouco explorado pelas empresas de software brasileiras e que pode trazer novos e

eficientes recursos ao mercado para automatizar tarefas comuns às empresas, como a

venda de produtos e serviços [3]. Essa situação agregada a uma popularização dos

aparelhos celulares motiva a observar os possíveis focos onde essa solução pode ser

aplicada, surgindo então o tema deste trabalho.

A partir disto, o desenvolvimento de aplicações móveis para celulares

demonstra-se um mercado novo e promissor, o qual este trabalho visa explorar.

1.2 JUSTIFICATIVA DO TRABALHO

A capacidade de processamento e armazenamento dos celulares está evoluindo

rapidamente, associada à capacidade de acesso à rede mundial, a Internet, os

celulares estão tornando-se dispositivos mais eficientes para implantação de

aplicações móveis se comparados a outras tecnologias como PALM ou Notebooks,

além de possuírem menor custo.

Com a popularização dos aparelhos celulares e a existência de planos

empresariais se torna simples e de baixo custo à aquisição de modelos capacitados a

suportar o sistema desenvolvido.

Mediante essa realidade, é evidente a necessidade das empresas de utilizarem

esses novos recursos de forma a criarem diferenciais em relação a seus concorrentes.

Nesse contexto, se insere esse sistema de Gestão de Vendas que pode ser visto não

somente como uma ferramenta para tornar mais ágil o processo de vendas, mas como

também um diferencial competitivo para a tomada de decisão por parte dos gerentes.

1.3 OBJETIVO GERAL

O objetivo geral desse trabalho é desenvolver um sistema para auxiliar no

processo de gerência de vendas e vendedores móveis.

8

Tiago, 19/11/06,

Marcelo, tem duvida aqui nesse verbo, ele queria que fosser fornecer

1.4 OBJETIVOS ESPECÍFICOS

De forma a alcançar o objetivo geral, os seguintes objetivos específicos foram

determinados e realizados:

Entender o funcionamento de sistemas com vendedores móveis verificando

suas necessidades;

Analisar alguns modelos de negócios existentes;

Estudar as diferentes tecnologias envolvidas referentes a aplicações

móveis de forma a selecionar aquelas que melhor se enquadram no

projeto;

Modelar a arquitetura do sistema, incluindo a base de dados da empresa;

1.5 METODOLOGIA

Para a elaboração deste sistema foi utilizado o Unified Process [5] como processo

de desenvolvimento de software. Portanto, devido à utilização do UP, o

desenvolvimento é:

Centrado na arquitetura;

Orientado a casos de usos;

Ciclo de vida iterativo e incremental;

Como iterativo, podemos definir como o processo de gerenciamento de uma

seqüência de versões executáveis, que envolve a geração de uma nova versão do

sistema, como um mini-projeto, a cada iteração. Como incremental, podemos definir o

processo que envolve a integração contínua entre as diversas versões do sistema,

onde cada nova versão incorpora aperfeiçoamentos incrementais em relação a

anterior pela incorporação do produto resultante da última interação [6].

O processo unificado também faz uso da Linguagem de Modelagem Unificada

(Unified Modeling Language – UML) para a elaboração de projetos. Sendo UML,

portanto a ferramenta utilizada para elaboração de todos os diagramas e artefatos.

As atividades foram divididas em quatro fases, seguindo o desenvolvimento

utilizando o UP, que são as seguintes [6]:

9

Tiago, 19/11/06,

Me pareceu ruim, atingidos talvez...

Concepção: nessa fase foram analisados o negócio, a viabilidade e o

escopo do projeto;

Elaboração: nesta fase foi analisado o domínio do problema, sendo

também especificada a arquitetura do sistema;

Construção: envolve a elaboração do sistema completo a partir da

arquitetura desenvolvida na fase anterior;

Transição: processo de implantação do software, viabilizando sua

disponibilidade aos usuários;

Para elaboração deste projeto foi necessária a realização de uma revisão

bibliográfica através de livros, pesquisas na internet, leitura de artigos, e revistas

especializadas. Sendo também, utilizado material disponibilizado em aula referente ao

curso de Ciência da Computação.

1.6 ORGANIZAÇÃO DO TEXTO

O texto está dividido em 7 capítulos. Neste primeiro capítulo é introduzido o

assunto deste projeto, motivação e justificativa.

No capítulo 2, é apresentado o processo de vendas e alguns casos de estudo de

soluções desenvolvidas, possibilitando assim o levantamento prévio de alguns

requisitos do sistema a ser desenvolvido.

No capítulo 3, é especificado o dispositivo móvel escolhido e são descritas as

tecnologias que promovem a mobilidade da aplicação móvel.

No capítulo 4, são descritas as bibliotecas, frameworks e ferramentas envolvidas

no desenvolvimento deste sistema.

No capítulo 5, é apresentado o projeto do sistema, suas funcionalidades, seus

módulos, características principais, diagramas e especificações.

No capítulo 6, é realizada uma discussão sobre como esse projeto foi

desenvolvido, acertos, erros e soluções alternativas.

No capítulo 7, são apresentas as conclusões finais deste trabalho.

10

2 ANÁLISE DE VENDAS E SISTEMAS DE AUTOMAÇÃO SIMILARES

No desenvolvimento de uma solução para automatizar a forças de vendas é

necessário compreender as atividades realizadas pela equipe de vendas, desde o

planejamento das vendas até sua conclusão, que constituem o chamado processo de

vendas.

A análise deste processo de vendas aliada ao estudo de caso de soluções

desenvolvidas com o mesmo propósito permitiu a identificação dos requisitos,

equipamentos e tecnologias utilizadas pelo mercado de soluções móveis.

A comparação destes dados possibilitou a determinação de um planejamento

inicial deste projeto em termos de arquitetura, dispositivos e serviços desenvolvidos.

2.1 O PROCESSO DE VENDAS

O processo de vendas pode ser dividido em 3 fases [7]:

Pré-Venda

Durante a Venda

Pós-Venda

2.1.1 PRÉ-VENDA

A fase de “pré-venda” constitui-se no planejamento e criação dos artefatos

necessários para a realização da venda.

Antes de realizar uma venda deve-se fazer uma prospecção do mercado, a fim

de identificar quem são os potenciais clientes, ou seja, dentre os possíveis clientes

seleciona-se apenas aqueles que apresentam maiores chances de fechamento da

venda. Com base nesta seleção deve-se entrar em contato com os potenciais clientes

para agendar entrevistas e visitas.

Antes de realizar as visitas deve ser elaborada uma proposta comercial que seja

bem documentada e descreva detalhadamente o produto ou serviço, citando dados

reais e apresentando informações gráficas e estatísticas. Ao elaborar a proposta

devem ser identificadas as possíveis objeções e preparados argumentos para

respondê-las.

Ao realizar a visita e fechar a venda o vendedor deve emitir o pedido e certificar-

se de que o mesmo foi preenchido corretamente, solicitando ao cliente que confirme

seus dados, as quantidades e as condições da venda.

11

Após a visita, o vendedor deve elaborar relatórios comerciais detalhando como

foi realizada a negociação, para que a empresa tenha um histórico do cliente e possa

identificar suas preferências.

2.1.2 DURANTE A VENDA

A fase “durante a venda” constitui-se nas seguintes etapas:

Acompanhamento do pedido: fornece informações para que o vendedor

acompanhe a situação atual dos pedidos emitidos, entrando em contato com o cliente

caso ocorra algum imprevisto com o fechamento da venda. (Ex: dados cadastrados

inconsistentes, demora na entrega do pedido, rejeição de crédito do cliente);

Informação ao cliente sobre o pedido: deve-se manter o cliente sempre informado

sobre o andamento do pedido. Caso ocorra algum imprevisto capaz de comprometer a

data de entrega deve-se fornecer alternativas que não prejudiquem a negociação;

Acompanhamento do recebimento do produto: deve-se certificar de que o produto

foi recebido pelo cliente conforme especificado no pedido, através de contato com o

cliente;

2.1.3 PÓS-VENDA

A fase de “pós-venda” constitui-se basicamente no suporte ao cliente após ter sido

realizada a venda.

Dependendo do produto, exemplos de atividades seriam:

Acompanhamento da instalação e utilização do produto;

Atendimento ao cliente;

Assistência técnica;

Fornecimento de peças de reposição e manutenção;

Troca rápida no caso de defeito;

Acompanhamento da cobrança;

2.2 ESTUDOS DE CASOS – SISTEMAS DE AUTOMAÇÃO SIMILARES

Para a realização dos estudos de casos foram selecionadas três empresas que

oferecem soluções de mobilidade na área de automação da força de vendas.

12

Empresa Solução analisada

Wealth Systems [8] SIV Enterprise - Automação da Força de Vendas

Cia Quatro [9] Mercador

Easyven [10] EASYVEN

Estas soluções operam sobre diferentes tipos de dispositivos móveis, permitindo

uma análise das vantagens e desvantagens de se desenvolver uma aplicação

específica para telefones celulares.

Para cada solução em estudo serão identificados seus objetivos, os

equipamentos utilizados ou disponíveis, a arquitetura, os módulos e funcionalidades

da solução.

2.2.1 SOLUÇÃO EM ESTUDO: SIV Enterprise

A solução SIV Entreprise tem como objetivo disponibilizar uma ferramenta de

Gestão Comercial para auxiliar o processo da força de vendas e o relacionamento com

os clientes.

A arquitetura do SIV é composta por dispositivos móveis, um servidor remoto e

um banco de dados próprio que realiza a comunicação entre o sistema e o banco de

dados do ERP da empresa, mantendo assim as informações automaticamente

atualizadas entre eles.

Os equipamentos disponíveis não estão restritos a dispositivos específicos, mas

sim as plataformas sobre as quais o sistema foi desenvolvido. Dessa forma é possível

utilizar pocket PC, palmtops ou celulares, desde que os dispositivos suportem J2ME.

Para a aplicação no servidor remoto, também conhecida como software de

retaguarda, é utilizada a tecnologia Java J2EE.

Um software de retaguarda é um sistema responsável por garantir a

compatibilidade de dados entre a solução e os sistemas presentes na empresa [11].

O SIV Enterprise é composto dos seguintes Módulos:

Módulo Vendedor / Representante – SIV Mobile

Módulo Supervisor / Gerencial – SIV Manager

Módulo Retaguarda Operacional – SIV Manager

13

Módulo Vendedor / Representante - SIV Mobile

Este módulo é destinado a força de vendas e aos representantes comerciais.

Suas principais funcionalidades são:

Cadastro de clientes e manutenção da base de contatos do cliente;

Rastreamento / Acompanhamento do atendimento ao cliente;

Gerenciamento de vendas sob estoque e cota de venda por produto;

Histórico detalhado de vendas;

Impressão de nota fiscal para faturamento a campo (venda ambulante);

Gerenciamento da rota de visita;

Títulos financeiros e limite de crédito do cliente;

Módulo Supervisor / Gerencial – SIV Manager

Este módulo é destinado aos supervisores e gerentes, tem como objetivo

fornecer informações de apoio e tomada de decisão.


Gerenciamento do atendimento ao cliente;

Personalização e criação de consultas gerenciais pelo usuário final;

Gerenciamento de cotas de venda por produto;

Gerenciamento de metas de venda por vendedor, cliente e regiões;

Gerenciamento de restrições de vendas;

Módulo Retaguarda Operacional - SIV Manager

Este módulo é destinado a operadores de tele-vendas, coordenadores de vendas

internos e ao setor de call center, tem como objetivo realizar o gerenciamento do

workflow de vendas integrado com faturamento e logística.


Controle do workflow de atendimento e vendas;

Gerenciamento financeiro de títulos e limite de crédito, integrado ao

SERASA para análise de crédito;

Relatórios operacionais e gerenciais;

Sistema de comercialização, permitindo a criação de uma ou mais políticas

de comercialização de produtos.

14

2.2.2 SOLUÇÃO EM ESTUDO: Mercador

A solução Mercador tem como objetivos automatizar a força de vendas,

disponibilizar informações gerenciais de apoio à decisão, integrar a solução Mercador

com os sistemas de gestão da empresa, padronizar o atendimento de clientes e a

realização de pedidos e outros.

A arquitetura do Mercador é composta por dispositivos móveis (notebooks,

palmtops e pocket pc), computadores desktop e um servidor remoto que realiza a

replicação dos dados entre o banco de dados da solução e o banco de dados da

empresa.

O Mercador está disponível em quatro versões chamadas de Mercador Server,

Mercador Pocket, Mercador WIN e Mercador WEB, totalmente integradas e

desenvolvidas utilizando a tecnologia Microsoft através das linguagens Visual

Basic, .NET(ASPx) e C#.

Para simplificar a extensa lista de funcionalidades desta solução, serão

apresentadas apenas as principais funcionalidades do Mercador. São elas:

Agenda de visitas;

Análise de vendas diárias e mensais;

Cobranças pendentes;

Condições de venda e pagamento;

Consulta a situação do cliente;

Contas a receber;

Orçamento de venda;

Relatório de regularidade de vendas por cliente;

Usuários e permissões;

Vendas por produto X período;

2.2.3 SOLUÇÃO EM ESTUDO: EASYVEN

A solução EASYVEN tem como objetivo automatizar a força de vendas, fazendo

com que a equipe de vendas seja mais eficiente e produtiva.

A arquitetura desta solução envolve a utilização de dispositivos móveis e um

servidor remoto, para os quais foram desenvolvidos os softwares EASYVEN-Mobile e

EASYVEN-Server.

O EASYVEN-Mobile é destinado aos vendedores em campo e pode ser utilizado

em equipamentos que suportem as plataformas Windows CE e PalmOS, ou seja

dispositivos handheld e palmtops, ou em celulares suportem as plataformas Symbian

ou J2ME.

15

O EASYVEN-Server realiza a integração entre a solução e o sistema ERP

utilizado pela empresa.

Os principais módulos disponíveis são:

Módulo de pré-venda, responsável pela geração de pedidos;

Módulo de venda pronta-entrega permite realizar a venda com a impressão

de notas fiscais;

Módulo de visita permite gerenciar as rotas de visita dos vendedores;

Módulo de objetivos e cotas permite que o vendedor verifique se atingiu

suas cotas e outros objetivos atribuídos ao vendedor;

Módulo de cobrança e depósito de valores;

Módulo do supervisor permite verificar o desempenho e o cumprimento das

metas dos vendedores;

2.2.4 ANÁLISE E CONCLUSÕES

Algumas das funcionalidades relevantes ao projeto, retiradas a partir do estudo

dos softwares descritos nesse capítulo e que estão incluídas no sistema são as

seguintes:

Rastreamento / Acompanhamento do atendimento: permite ao vendedor

verificar a situação atual de um pedido. Dessa forma, o vendedor poderá se

manter informado caso ocorra algum problema no fechamento de um pedido.

Impressão de pedido a campo: permite ao vendedor fechar a venda junto

ao cliente. Dessa forma, a empresa pode iniciar os processos necessários para

o envio dos produtos comprados pelo cliente no momento do fechamento do

pedido.

Orçamento de venda: permite ao vendedor informar um orçamento sobre

os produtos, preços e quantidades sem a necessidade de fechar a venda em

sua visita ao cliente.

Condições de venda: permite ao vendedor proceder à venda de acordo

com as regras de negócio estabelecidas pela situação financeira atual do

cliente junto à empresa.

16

3 SUPORTE A MOBILIDADE

3.1 VISÃO GERAL

Para a implementação deste projeto foi necessário fazer uso de um conjunto de

tecnologias que possibilitaram ao dispositivo móvel selecionado a mobilidade e a

conectividade necessária para atingir os objetivos deste projeto. As tecnologias

utilizadas mais importantes que possibilitaram tal mobilidade e o dispositivo

selecionado serão apresentados neste capítulo.

3.2 DISPOSITIVO MÓVEL SELECIONADO

Este projeto envolve a utilização de um dispositivo móvel com uma série de

características, dessa forma todas estas funcionalidades deverão ser suportadas pelo

dispositivo escolhido. As principais funcionalidades exigidas por este projeto são as

seguintes:

Possibilidade de comunicação com dispositivos externos, como por

exemplo: impressoras, computadores;

Visor com boa resolução;

Suporte a instalação de aplicativos;

Suporte a cartão de memória;

Conexão com a Internet.

Após pesquisa realizada em aparelhos celulares disponíveis no mercado (maiores

detalhes no apêndice 2), chegou-se a conclusão que o Nokia 6600 é o aparelho que

melhor atende as necessidades do projeto. A Figura 1 mostra o aparelho selecionado.

17

Figura 1: Dispositivo móvel utilizado.

Os recursos disponibilizados por este aparelho necessários para a elaboração do

sistema são os seguintes [12]:

Sistema operacional Symbian 7.0s que permite execução de programas

Java (CDLC 1.0 e MIDP 2.0);

Comunicação utilizando Bluetooth;

Tamanho de aplicativo Java limitado à quantidade de memória disponível;

Inserção de cartão de memória;

Resolução de tela de 176 x 208;

Conexão com a Internet via GSM/GPRS

Detalhes referentes às tecnologias citadas acima serão vistos a seguir.

3.3 TECNOLOGIA GSM/GPRS

GSM (Global System for Mobile Communications) é um dos sistemas digitais para

comunicação celular líderes no mundo, sendo considerada a tecnologia digital celular

mais avançada atualmente. Diferencia-se muito das tecnologias predecessoras sendo

que o sinal e os canais de voz são digitais, dessa forma as redes GSM são vistas

como de segunda geração (2G) [16].

GPRS (General Packet Radio Service) é uma tecnologia que aumenta as taxas de

transferência de dados nas redes GSM existentes. Esta tecnologia permite o

transporte de dados por pacotes (comutação por pacotes) tornando a taxa de

18

transferência de dados mais elevada que as taxas de transferência das tecnologias

anteriores, que usavam comutação por circuito [17].

Redes GPRS podem ser vistas como sub-redes da Internet, terminais GPRS

podem ter endereço IP. Portanto, através desse mecanismo torna-se transparente e

viável ao dispositivo celular a comunicação através de HTTP, FTP, IRC e e-mail.

Do ponto de vista do consumidor a tecnologia GSM/GPRS oferece novos serviços

com baixos custos, pois a cobrança é feita pela quantidade de pacotes de dados

transmitidos e não pelo tempo de conexão à rede. Isto ocorre, pois os recursos são

atribuídos aos usuários apenas quando for necessário enviar ou receber dados [16]

[17]. Dessa forma vários usuários compartilham os recursos da rede, tornando a rede

mais eficiente e de menor custo a seus usuários.

Tais tecnologias são utilizadas para permitir a transferência de dados entre os

dispositivos celulares e o servidor da empresa.

3.4 BLUETOOTH

Nesta seção é apresentada a forma de comunicação para transferência de dados

entre dispositivos móveis e computadores que foi escolhida para ser utilizada neste

projeto.

A tecnologia Bluetooth inicialmente será utilizada apenas para auxiliar o

desenvolvimento do software embarcado no telefone celular, possibilitando a

transferência do software em desenvolvimento entre o PC e o telefone celular. Sendo

também utilizada para permitir a comunicação entre o celular e uma impressora

portátil.

O Bluetooth é uma tecnologia criada em 1994 pela Ericsson Mobile

Communications para permitir a conexão sem fio entre seus dispositivos móveis e

acessórios, com baixo consumo de energia, proporcionando maior mobilidade em

relação as demais tecnologias já desenvolvidas como infravermelho, interfaces USB e

outras [18].

Em 1998 foi fundado o Bluetooth Special Interest Group (SIG), uma associação

comercial sem fins lucrativos formada por empresas como Nokia, Ericsson, Motorola,

Intel, IBM, Microsoft e outras devido ao interesse comum em promover o estudo e o

desenvolvimento da tecnologia, a qual pode ser implementada e vendida livremente

como parte dos produtos de seus membros.

19

A tecnologia opera sobre uma banda de radiofreqüência compreendida na faixa

entre 2.4 GHz e 2.48 GHz denominada ISM (Industrial Scientific and Medicine), e

divide a banda passante em 79 canais, alterando a sua freqüência cerca de 1600

vezes por segundo, tornando muito pouco provável a ocorrência de interferências de

outros dispositivos.

Atualmente encontra-se na versão 2.0, a qual permite um alcance de até 100m e

taxas de transferência de dados de até 2.1 Mbps. As versões anteriores (1.0 e 1.2)

permitem um alcance de 10m e taxas de transferência de dados de 1 Mbps [18].

Com estas faixas de alcance é possível a formação de pequenas redes privadas

conhecidas como Personal Area Networks (PANS) ou Piconets. Uma Piconet é uma

rede formada por até oito dispositivos, na qual um dispositivo deve assumir a função

de mestre e os demais de escravos. Um mesmo dispositivo pode atuar como escravo

em mais de uma Piconet, sendo até mesmo mestre em outra Piconet, dizendo-se

assim que ele faz parte de uma Scatternet. A única restrição é que um dispositivo

pode ser mestre de apenas uma rede Piconet ao mesmo tempo.

Atualmente os aparelhos celulares modernos têm como meio de comunicação

usual com dispositivos externos a tecnologia Bluetooth, dessa forma a implantação de

nossa aplicação no dispositivo celular será utilizando essa tecnologia.

Este projeto tinha como parte dos requisitos a comunicação direta com uma

impressora Bluetooth para impressão de um recibo do pedido realizado, porém não foi

possível obter uma impressora que suportasse essa tecnologia para auxiliar no

desenvolvimento. Tentou-se realizar o aluguel do dispositivo, porém em Porto Alegre

não havia impressoras com tal forma de conectividade.

Dessa forma, com o objetivo de manter o envio de pedidos via Bluetooth

implementado neste projeto. Foi desenvolvida uma aplicação Java desktop que

através de um adaptador, tornou possível que um computador convencional seja um

servidor Bluetooth. Assim, nossa aplicação simula uma impressora, e a aplicação

celular envia os dados do pedido para o computador, ao invés de enviar para uma

impressora real.

20

4 FERRAMENTAS E TECNOLOGIAS

4.1 TECNOLOGIA JAVA

4.1.1 VISÃO GERAL

Desenvolvido pela Sun Microsystems, Java é uma linguagem de programação

independente de plataforma, sendo até então utilizada largamente na Internet para o

desenvolvimento de aplicações web dinâmicas [13].

Com a evolução dos aparelhos celulares, dos PDA’s e das tecnologias de

comunicação, Java também ganhou importância no mundo dos aparelhos móveis,

disponibilizando uma plataforma segura e muito bem fundamentada para

programadores e fabricantes de celulares.

A tecnologia Java subdivide-se em 3 grandes partes: J2EE, J2SE e J2ME. O

Java 2 Micro Edition (J2ME) é uma API Java voltada para elaboração de aplicações

para dispositivos móveis como celulares e PDA’s, sendo este o enfoque principal

deste projeto[13].

4.1.2 JAVA EE

O J2EE (Java 2 Enterprise Edition) ou Java EE é uma plataforma de programação

de computadores que faz parte da plataforma Java. Ela é voltada para aplicações

multi-camadas, baseadas em componentes que são executados em um servidor de

aplicações. A plataforma Java EE é considerada um padrão de desenvolvimento já

que o fornecedor de software nesta plataforma deve seguir determinadas regras se

quiser declarar os seus produtos como compatíveis com Java EE. Ela contém

bibliotecas desenvolvidas para o acesso a base de dados, RPC, CORBA, etc. Devido

a essas características a plataforma é utilizada principalmente para o desenvolvimento

de aplicações web.

A plataforma J2EE contém uma série de especificações, cada uma com

funcionalidades distintas. Entre elas, tem-se:

JDBC (Java Database Connectivity), utilizado no acesso a bancos de

dados;

Servlets, são utilizados para o desenvolvimento de aplicações Web com

conteúdo dinâmico. Ele contém uma API que abstrai e disponibiliza os

recursos do servidor Web de maneira simplificada para o programador.

21

JSP (Java Server Pages), um especialização do servlet que permite que

conteúdo dinâmico seja facilmente desenvolvido.

JTA (Java Transaction API), é uma API que padroniza o tratamento de

transações dentro de uma aplicação Java.

EJBs, utilizados no desenvolvimento de componentes de software. Eles

permitem que o programador se concentre nas necessidades do negócio

do cliente, enquanto questões de infra-estrutura, segurança, disponibilidade

e escalabilidade são responsabilidade do servidor de aplicações.

JCA (Java Connector Architecture), é uma API que padroniza a ligação a

aplicações legadas.

Servlets é uma tecnologia Java para estender as funcionalidades de um servidor

web, permitindo que o servidor gere conteúdo dinâmico e interaja com os clientes,

utilizando o modelo request/response. Servlet tem acesso a toda API Java, incluindo

JDBC API, utilizada para fazer acesso a bases de dados [15].

Atualmente, servlets são uma popular escolha para construção de aplicações web

interativas. Utilizado em conjunto com a tecnologia JSP que é uma extensão da

tecnologia servlet é possível criar páginas HTML e XML combinando conteúdo estático

e dinâmico [15].

Dessa forma, devido aos benefícios acima citados, neste projeto foram utilizadas

as tecnologias Java Servlet e JSP para a implementação dos módulos da aplicação

web e de serviços web.

4.1.3 J2ME

A plataforma J2ME fornece uma máquina virtual Java, compacta o suficiente

para ser suportada pelas restrições de memória destes dispositivos. Porém, essa

máquina não suporta todas as classes e funcionalidades do Java. Sendo formada

basicamente por duas camadas: Configuration e Profile [13][14].

As Configurations provêem os serviços mais básicos para que as aplicações

possam rodar, tais como: sistemas de comunicação, a segurança interna da máquina

virtual e o acoplamento com o dispositivo.

Existem dois tipos de Configurations, o CDC (Connected Device Configuration),

que é usada em dispositivos um pouco maiores como: aparelhos de TV por assinatura

e sistemas de telemetria de carros, os quais possuem um processamento razoável e

uma memória um pouco maior. E o CLDC (Connected Limited Device Configuration)

22

que é usada por dispositivos com pouca memória e um processador relativamente

fraco, como é o caso dos celulares, PDA’s e pagers.

Para este projeto apenas o CLDC é relevante, pois se aplica aos celulares,

fornecendo as classes responsáveis pela conexão, entrada e saída de dados,

manipulação de literais e operações matemáticas.

Os Profiles provêem uma série de API’s padrões que combinados com uma

configuration, provêem um serviço completo para que as aplicações possam ser

executadas. Existem vários tipos de Profiles, porém vamos destacar o MIPD (Mobile

Information Device), utilizado para dispositivos móveis como celulares. O MIDP

oferece a biblioteca de interfaces gráficas. Provê ainda as classes para memória

persistente e algumas de definição de objetos de formulário.

Existem atualmente duas versões: a 1.0 e a 2.0. A versão 1.0 está integrada

praticamente em todos os celulares atuais. Quanto a 2.0, existem apenas alguns

modelos de celulares com esta versão, sendo o dispositivo Nokia 6600 usuário desta

nova versão.

Utilizando-se dessas API’s podem ser listadas uma série de razões para a

escolha do J2ME como a plataforma de desenvolvimento ideal para este projeto, entre

elas pode-se ressaltar as seguintes [14]:

Segurança, pois o código executa sempre dentro dos limites da JVM;

Programação robusta fazendo uso de tratamento de exceções, orientação

a objeto;

Suporte a manipulação da tela gráfica e do teclado dos dispositivos;

Maior suporte à conectividade com outros dispositivos;

Programação em rede fazendo uso do protocolo HTTP e outros;

A tecnologia J2ME foi utilizada no desenvolvimento do módulo da aplicação

celular deste projeto.

4.2 FRAMEWORKS JAVA

No desenvolvimento de software, um framework é definido como uma estrutura na

qual outros projetos de software podem ser organizados e desenvolvidos. Um

framework pode incluir bibliotecas, scripts ou outros programas que ajudam no

desenvolvimento e unem os diferentes componentes de um projeto de software.

Frameworks são elaborados com a intenção de facilitar o desenvolvimento de

software, permitindo aos desenvolvedores gastarem menos tempo com detalhes de

implementação e mais com a modelagem dos requisitos. Dessa forma, visando estes

23

benefícios uma série de frameworks foram utilizados neste projeto. Os principais

frameworks utilizados podem ser visto nas subseções a seguir.

4.2.1 STRUTS E MVC

Struts é um framework para o desenvolvimento da camada de controle seguindo o

padrão Model 2 (uma variante do MVC oficializada pela Sun), de aplicações web

construído em Java para ser utilizado em um container web. É uma extensão da Java

Servlet API para encorajar os desenvolvedores a adotarem o padrão MVC como

arquitetura. Originalmente criado por Craig McClanahan e doado para o Apache

Foundation em maio de 2000.

Este framework permite que a implementação de grandes aplicações web seja

feita por diferente grupos de desenvolvedores. Em outras palavras, web designers,

desenvolvedores de componente e outros desenvolvedores podem realizar suas

atividades individualmente devido ao baixo acoplamento provido pelo padrão MVC.

Em um projeto de software baseado no padrão MVC, define-se uma arquitetura

básica com 3 camadas possivelmente abstratas:

Model: Implementa o modelo de domínio da aplicação, suas entidades e

regras de negócio;

Controller: Implementa a camada respónsavel pelo gerenciamento de

eventos no projeto, tais como cliques do usuario, chamada a camada Model

para processar os eventos, também pode manter informações de estado do

usuario na aplicação.

View: É a camada de apresentação, a interface com usuário de modo que

esta somente requisite o processamento de eventos através Controller.

A seguir pode ser visto na figura 2 a forma como o struts implementa o padrão

MVC.

24

Figura 2: Diagrama do MVC implementado pelo Struts.

Na figura acima é ilustrado o funcionamento do MVC criado pelo Apache Struts. O

passo 1, representa a página de entrada de dados, no caso o viewer. Após o usuário

ter entrado com seus dados, ele submete o form, passo 2, para um determinado

endereço através de um clique em um botão, por exemplo. Neste momento, o

controller assume, verificando que ação está sendo chamada, o controle verifica no

arquivo struts-config.xml quem é a ação que tratará essa requisição e quem é a classe

form que será preenchida com as informações do formulário submetido. Dessa forma,

um objeto ActionForm com todos os dados do formulário de entrada será passado a

uma classe Action, passo 3, que realizará as operações necessárias, passo 4, sobre

esses dados como persisti-los em um banco de dados. Logo após a ação ser

executada pelo controller, ocorre o redirecionamento para uma página de operação

concluída, passo 5.

Neste projeto, struts é largamente utilizado para possibilitar uma correta

implementação do padrão MVC/Model2 permitindo uma clara separação entre Model,

View e Controller.

25

4.2.2 AXIS E WEB SERVICES

Atualmente, torna-se comum a necessidade de aplicações diferentes em

computadores diferentes trocarem informações, nosso projeto é um exemplo dessa

necessidade, pois necessitamos trocar informações entre um dispositivo móvel e um

servidor apache. Algumas vezes, essa troca de informações necessita do envio e

retorno de mensagens mais complexas. O objetivo dos web services é padronizar o

formato dessas mensagens de forma a reduzir a complexidade. A idéia consiste em

simplesmente chamar métodos de objetos residentes em computadores remotos. O

Apache Axis é um framework que permite a elaboração destes web services.

O Axis é um framework de código aberto, baseado na linguagem Java e no padrão

XML, utilizado para construção de web services no padrão SOAP. Através do Axis os

desenvolvedores podem criar aplicações distribuídas. Além da versão para Java,

existe uma implementação baseada na linguagem C++. O projeto Apache Axis é

suportado pela Apache Software Foundation.

Tal framework disponibiliza dois modos para "expor" os métodos de uma classe

através de web services. O modo mais simples utiliza os arquivos JWS (Java Web

Service) do Axis. O outro método, que foi utilizado no desenvolvimento deste projeto,

utiliza um arquivo WSDD (Web Service Deployment Descriptor), que descreve com

detalhes como serão criados os web services a partir dos recursos (classes Java)

existentes. Neste arquivo são mapeados os metodos disponíveis pela aplicação web.

Também é possível, através do Axis, gerar automaticamente o arquivo WSDL

(Web Service Description Language). O WSDL contém a definição da interface dos

web services, ou seja, descreve exatamente o que o serviço faz.

O Apache AXIS é uma das implementações mais versáteis do protocolo SOAP, ele

permite a criação de web services tanto no padrão xml/rcp como doc/literal (.NET).

SOAP é um protocolo leve para troca estruturada de mensagens usando HTTP.

Ele é um protocolo baseado em XML que consiste basicamente em três partes:

Envelope que define um framework para descrever o que é a mensagem e

como ela deve ser processada;

Conjunto de regras de codificação para representar instancias da aplicação

e seus tipos;

Convenção para representar chamadas remotas de procedimento e suas

respostas;

26

Com o objetivo de fazer uso das vantagens e da transparência do uso de

chamadas remotas de procedimento. Este framework foi utilizado para o

desenvolvimento dos serviços que serão acessados pelo dispositivo móvel.

4.2.3 JAVA PERSISTENCE E MAPEAMENTO OBJETO RELACIONAL

Java Persistence é uma nova API ou framework introduzido como parte do Java

EE 5. Primeiro, tem como objetivo simplificar o desenvolvimento de aplicações Java

EE e Java SE usando persistência de informações. Segundo, a Sun introduziu essa

API como tentativa de padronizar o desenvolvimento de aplicações que fazem uso de

persistência de dados.

Segundo a Sun, a API Java Persistence capturou as melhores idéias das

tecnologias de persistência atuais como Hibernate, TopLink e JDO e as integrou em

sua nova biblioteca. Dessa forma, os desenvolvedores não terão que continuar

enfrentando os problemas da falta de padronização que impedia que uma mesmo

framework de persistência fosse utilizado em ambientes Java SE e Java EE.

Esta API realiza o mapeando objeto relacional, ou seja, através de anotações no

código Java ou através de descritores XML, podemos definir um mapeando entre os

objetos Java e o banco de dados relacional. Também é suportado uma poderosa

linguagem SQL (rica extensão do EJB QL) para queries estáticas e dinâmicas.

Dessa forma, Java Persistence foi definido como a API para persistência de dados

deste projeto baseado nas características ressaltadas acima e nas recomendações da

Sun.

4.3 BIBLIOTECAS JAVA

4.3.1 JASPER REPORTS

Jasper Reports é uma poderosa ferramenta open source para desenvolvimento de

relatórios na tela e para impressão. Sendo também, possível a exportação desses

relatórios de forma transparente para vários formatos como PDF, HTML, XLS, CVS e

XML.

Inteiramente escrito em Java pode ser utilizado em uma grande variedade de

aplicações, incluindo J2EE e aplicações Web, para geração de conteúdo dinâmico. O

27

propósito principal é realizar a criação de páginas e relatórios prontos para impressão

de uma maneira simples e flexível.

A parte visual do relatório é toda construída sobre XML servindo com um descritor

de design. Neste projeto para a elaboração do design do relatório se faz uso de uma

ferramenta chamada iReport, que permite a criação de forma visual do arquivo XML e

posterior compilação do mesmo.

Dessa forma, torna-se muito mais prática e rápida a elaboração de complexos

relatórios com conteúdo dinâmico.

4.3.2 KSOAP2

Com a popularização dos aparelhos celulares e a possibilidade de conexão com a

internet, os desenvolvedores passaram a desejar, como acontece neste projeto, que

suas aplicações possam acessar serviços web usando XML e SOAP. Porém, algumas

dificuldades são encontradas devido à restrita capacidade de memória e

processamento, que torna inviável que as bibliotecas padrões de desenvolvimento de

aplicações clientes de web services como AXIS sejam utilizadas nestes dispositivos.

Microdispositivos são simplesmente muito pequenos para trabalharem com as

bibliotecas originalmente desenvolvidas para aplicações desktop.

Em virtude desta situação, a Sun desenvolveu uma especificação JSR172 que

prevê o uso de XML e SOAP em microdispositivos. Porém, nem todos os celulares

possuem suporte a essa biblioteca, sendo que a maioria deles não suporta. O

dispositivo Nokia 6600 definido como dispositivo móvel para a implantação da

aplicação celular, não possui suporte a essa biblioteca, e nem possui a possibilidade

de instalação.

Em virtude desse problema, neste projeto está sendo usada uma biblioteca

alternativa open source para o desenvolvimento de web services em microdispositivos

chamada KSOAP2, que possui um ótimo desempenho e está de acordo com as

restrições impostas por tais dispositivos.

4.3.3 DOJO/AJAX

Durante o desenvolvimento deste projeto, foram constatadas algumas dificuldades

no desenvolvimento de interfaces com o usuário que fossem tão agradáveis quanto às

interfaces normalmente desenvolvidas para sistemas desktop. O principal problema

28

era a falta de combos com autocompletar e excesso de reloads das páginas. Já que

necessitávamos em várias páginas criar mecanismos para selecionar os nomes de

vendedores e clientes.

Uma possível solução alternativa para esse problema era a abertura de janelas

popup com a possibilidade de digitar o nome da pessoa procurada e em seguida

submeter o formulário, porém essa solução ainda era pouco prática, pois, se o usuário

não soubesse o nome completo ele teria que realizar várias requisições gerando o

reload da página inúmeras vezes, atividade que costuma ser bem desagradável para o

usuário. Baseado nesse problema, verificou-se a existência do ajax e o fato de que

essa tecnologia resolve vários deste tipo.

AJAX é uma abreviatura para Asynchronous JavaScript e XML, é uma técnica de

desenvolvimento web para a criação de aplicação web interativas. A intenção é criar

páginas com uma maior comunicação entre servidor e o navegador, sem reload,

através da troca de pequenas quantias de informação a cada atividade do usuário na

página. AJAX aumenta a interatividade e velocidade das páginas web tornando a

usabilidade dessas aplicações tão boa quanto das aplicações desktop.

Alguns componentes disponíveis gratuitamente já implementam o ajax de forma

transparente para os desenvolvedores. Entre esses, podemos destacar o que

utilizamos neste projeto: o Dojo Toolkit.

Essa biblioteca possui o combo de autocompletar que neste projeto é utilizado

para todas as telas com seleção de nomes, aumentando de forma expressiva a

usabilidade das interfaces do projeto.

4.4 SERVIDORES

4.4.1 TOMCAT

Apache Tomcat é um container Web, desenvolvido pela Apache Software

Foundation. Ele implementa parte da especificação J2EE, no caso, Servlet e

JavaServer Pages(JSP) que pertecem a Sun Microsystems, provendo um ambiente

onde é possível rodar código Java junto de um servidor Web.

Possui um servidor http interno, também provê tanto páginas estáticas quanto

dinâmicas, fornecendo suporte a outras tecnologias como: Realms e segurança, JNDI

Resources e JDBC DataSources.

29

Neste projeto Tomcat foi escolhido como o servidor, por ser um projeto open

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

produção.

4.4.2 MYSQL - BANCO DE DADOS

O MySQL tornou-se o banco de dados open source mais popular no mundo,

devido sua rápida e consistente performance, alta confiabilidade e fácil uso. Tem sido

usado em mais de dez milhões de instalações, sendo usado tanto por grandes

corporações quanto por softwares embarcados.

O MySQL foi criado na Suécia por dois Suecos e um finlandês: David Axmark,

Allan Larsson e Michael "Monty" Widenius, que trabalham juntos desde a década de

1980. Hoje seu desenvolvimento e manutenção empregam aproximadamente 70

profissionais no mundo inteiro, e mais de mil contribuem testando o software,

integrando-o a outros produtos, e escrevendo a respeito do mesmo.

O sucesso do MySQL deve-se em grande medida à fácil integração com o PHP

incluído, quase que obrigatoriamente, nos pacotes de hospedagem de sites da Internet

oferecidos atualmente. Empresas como Yahoo! Finance, MP3.com, Motorola, NASA,

Silicon Graphics e Texas Instruments usam o MySQL em aplicações de missão crítica.

O MySQL hoje suporta Unicode, Full Text Indexes, replicação, Hot Backup, GIS,

OLAP e muitos outros recursos.

A seguir algumas razões para o MySQL ter sido adotado neste projeto:

Alta performance;

Forte controle de falhas;

Suporte robusto a transação;

Forte proteção das informações;

Facil administração;

Baixo custo;

4.5 AMBIENTE DE DESENVOLVIMENTO

A escolha do ambiente de desenvolvimento para dispositivos móveis está

vinculada a tecnologia em que a aplicação será desenvolvida. As tecnologias

30

escolhidas terão de ser suportadas pelos equipamentos que integram a arquitetura do

projeto.

Realizada a escolha pelo dispositivo Nokia 6600, existem apenas duas opções de

plataformas de desenvolvimento para este dispositivo, sendo elas: Symbian C++ ou

J2ME [12]. Sendo J2ME a plataforma escolhida para o desenvolvimento do sistema

aqui projetado, devido a sua portabilidade, orientação a objetos, programação robusta

e outras características definidas na subseção Java e J2ME vista anteriormente.

J2ME pode ser justificado como uma escolha mais adequada se comparado ao

Symbian C++ por não estar ligado a um sistema operacional em específico e sim a

qualquer SO que implemente sua máquina virtual. Nesse sentido se torna muito maior

a aplicabilidade de nossa solução. Outro fator importante é que a tecnologia Java

permite que tanto o módulo celular quanto o módulo web sejam desenvolvidos

utilizando a mesma linguagem, o que permite um melhor rendimento por parte dos

desenvolvedores.

A plataforma J2ME pertence a Sun Microsystems, que disponibiliza o ambiente

SUN Java Wireless Toolkit, conhecido como WTK. Com este ambiente é possível

compilar, preparar o projeto para a distribuição e realizar testes utilizando-se

emuladores disponíveis para diversos dispositivos [19] [20].

Contudo, o WTK não é um ambiente para a edição de código-fonte da aplicação,

sendo desejável o uso de um Ambiente de Desenvolvimento Integrado (IDE), que

facilite o processo de desenvolvimento permitindo a realização de todas as tarefas

necessárias em um único ambiente, tornando assim mais eficiente o desenvolvimento

do sistema.

Para a plataforma Java existem duas principais ferramentas de desenvolvimento

disponíveis no mercado, que são gratuitas e oferecem suporte ao WTK:

Eclipse: possui uma arquitetura extensível, a qual permite a instalação do WTK na

forma de plugin, conhecido como Eclipse ME;

Netbeans: possui uma extensão chamada NetBeans Mobility Pack, que incorpora

o WTK como parte do ambiente de desenvolvimento;

Uma alternativa ao WTK é a utilização da ferramenta de desenvolvimento

distribuída pela empresa Nokia, chamada Carbide.j (formalmente conhecida como

Nokia Developer´s Suite for J2ME) e que também pode ser integrada ao Eclipse como

um plugin ou ao NetBeans como um módulo [12].

31

Devido ao melhor suporte a desenvolvimento de aplicações web e a conhecida

eficiência e estabilidade, o NetBeans foi escolhido como o ambiente de

desenvolvimento a ser utilizado e o NetBeans Mobility Pack como plugin necessário

para a integração com o WTK.

32

5 PROJETO DO SISTEMA

5.1 VISÃO GERAL

O sistema aqui definido busca acrescentar ao vendedor móvel a capacidade de

comunicar-se com a empresa matriz de uma forma ágil, prática e econômica reduzindo

a necessidade de que funcionários da empresa sejam alocados para atenderem as

necessidades dos vendedores.

Para a empresa é necessário também um controle gerencial das atividades de

seus vendedores, de forma que seja simples ao gerente consultar as vendas dos

vendedores e os pedidos dos clientes, por exemplo. Tornando facilitada a tomada de

decisões e a elaboração de novas estratégias de negócio.

O sistema permite a comunicação e troca de dados entre os vendedores e a

empresa através de aparelhos celulares. Dessa forma o vendedor deve registrar os

dados da venda diretamente em seu celular e após a finalização da venda, dados

referentes ao pedido são enviados imediatamente através da internet para o servidor

da empresa o qual processa as informações recebidas e as armazena em um banco

de dados. Essa comunicação é representada na Figura 3.

Figura 3: Diagrama de blocos referente à arquitetura do sistema.

Depois de realizado o login no sistema, o celular automaticamente estabelece

conexões a um conjunto de serviços web e recebe as informações referentes à lista de

clientes da rota, da agenda e a lista de produtos da empresa. Estas informações são

necessárias para o correto funcionamento da aplicação celular de forma a manter a

integridade dos dados entre o celular e a empresa.

33

Módulo IAplicação

Celular

Módulo IIServiços Web

Módulo IIIAplicação Web

Banco de Dados

Aplicação Celular - Módulo I

Aplicativo embarcado para celular que fornece um conjunto de facilidades ao

vendedor, dentre as quais se destaca a emissão de pedidos a campo iniciando o

processo da venda.

Serviços Web - Módulo II

Aplicação rodando no servidor da empresa com capacidade para armazenar e

fornecer informações. Este módulo disponibiliza uma série de serviços a Aplicação

móvel. Ele centraliza o acesso à base de dados da empresa.

Aplicação Web - Módulo III

Aplicativo que permite o controle das vendas através de relatórios, cadastro de

rotas, consulta a pedidos, entre outras funcionalidades.

A arquitetura da solução pode ser visualizada na Figura 4.

Figura 4: Arquitetura da solução

5.2 APLICAÇÃO CELULAR – MÓDULO I

O módulo I foi desenvolvido utilizando a tecnologia J2ME para a implementação

do software embarcado do celular.

As funcionalidades deste módulo são as seguintes:

Listagem de clientes da rota: Através da rota, os vendedores podem

visualizar no celular o cadastro de cada cliente, bem como sua situação

34

Guilherme Bradasch, 20/11/06,

Revisar todo este trecho introdutório

financeira junto à empresa e o último pedido realizado pelo cliente a ser

visitado.

Listagem de clientes da agenda: Através da agenda, os vendedores

podem visualizar no celular o cadastro de cada cliente, bem como sua

situação financeira junto à empresa. A fim de reduzir os custos de

comunicação o último pedido realizado pelos clientes da agenda não esta

disponível logo após a inicialização do sistema, podendo ser atualizado

caso o vendedor efetue um pedido a algum cliente desta listagem.

Verificação da situação de um cliente, se o mesmo está em débito com a

empresa, ou se sua situação está OK. Esse tipo de verificação é

importante para que o vendedor não realize outras vendas para clientes

nesta situação;

Listagem dos produtos da empresa com seus respectivos valores e

quantidades em estoque. Produtos dessa lista poderão ser adicionados

ao pedido;

Criação de pedido para um cliente, assim como a gerência do pedido

propriamente dita, permitindo a inclusão de produtos e exclusão de itens

do pedido, alteração de quantidades, definição da forma de pagamento,

impressão via bluetooth e finalização do pedido. Durante a finalização do

pedido os dados são enviados ao servidor da empresa e as quantidades

disponíveis de cada produto deste pedido são atualizadas no celular;

A rota e a agenda de cada vendedor são gerenciadas através da aplicação web,

onde os usuários do tipo gerente e funcionário têm permissão para atribuir e remover

clientes aos vendedores, sendo que para usuários do tipo vendedor apenas é possível

gerenciar a sua própria rota e agenda.

Neste projeto foi utilizado o celular Nokia 6600, porém outro dispositivo com

suporte a tecnologia J2ME poderia ter sido utilizado.

5.2.1 DIAGRAMA DE CASO DE USO

Após o levantamento de requisitos realizado, foi possível definir uma lista de todas

as funcionalidades para a aplicação celular. Essa lista de funcionalidades pode ser

melhor descrita pelo diagrama de caso de uso que pode ser visto na página seguinte.

Logo após são descritas as especificações de cada um dos casos de uso

apresentados.

35

Reservado para imagem do caso de uso do celular

Diagrama de caso de uso da aplicação celular.

Em seguida são apresentadas as especificações de cada um dos casos de uso do

diagrama acima.

36

5.2.2 ESPECIFICAÇÃO: EFETUAR LOGIN

DESCRIÇÃO

Todos os vendedores devem realizar a autenticação no celular para acessar o

sistema.

PRÉ-CONDIÇÕES

O vendedor deve possuir um usuário cadastrado no site.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema apresenta uma tela no seguinte formato:

Título: Login

Conteúdo:

- Campos: Usuário e senha.

Menus: OK e Fechar.

2. Se o vendedor selecionar o menu Fechar, o subfluxo A1 (Fechar) é executado.

3. O usuário digita o seu usuário e senha (V1) e seleciona o menu OK;

4. O sistema verifica se o usuário e senha conferem e realiza autenticação no

sistema. (E1, E2);

Deve ser observado que a senha utilizada na aplicação celular para autenticação

do vendedor é a mesma de acesso a aplicação web. Após a autenticação no sistema a

aplicação conecta-se aos serviços disponíveis no site da empresa para receber as

informações referentes à rota e agenda cadastrados para o vendedor autenticado e a

lista de produtos da empresa.

Fluxos Alternativos

A1. Fechar

1. O sistema finaliza a aplicação.

Fluxos de Exceção

E1. Erro ao realizar a operaçãoEste erro pode ocorrer sempre que não for possível executar alguma operação

solicitada, normalmente devido à falha de acesso à base de dados. A ocorrência deste

erro implica na exibição de uma mensagem para o vendedor.

E2. Falha ao realizar loginEste erro indica que não foi possível realizar a autenticação utilizando o usuário e

senha fornecidos. A ocorrência deste erro implica na exibição de uma mensagem para

o vendedor.

37

Fluxos de Validação

V1. Campos obrigatórios

Todos os campos da tela são obrigatórios, portanto devem ser preenchidos.

Caso não sejam preenchidos, o sistema irá informar uma mensagem de erro

solicitando a informação dos campos.

38

5.2.3 ESPECIFICAÇÃO: GERENCIAR PEDIDO

DESCRIÇÃO

O vendedor pode criar um pedido para um cliente através do celular, sendo

possível inserir, remover e alterar a quantidade de cada produto, visualizar o pedido,

definir forma de pagamento, finalizar pedido e imprimir o pedido.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e o sistema deve ter disponíveis

as informações do vendedor sobre os clientes da rota, da agenda e a lista de produtos.

FLUXO DE EVENTOS

Fluxo Principal


Título: “Pedido: Cód 0”

Conteúdo:

- Itens chamados Cliente, Produto, Pagamento e Finalizar Pedido.

Menus: Imprimir e Fechar

2. Se o item escolhido for:

Cliente, o subfluxo A1 (Definir Cliente) é executado.

Produto, o subfluxo A2 (Visualizar Pedido) é executado.

Pagamento, o subfluxo A3 (Definir Forma de Pagamento) é

executado.

Finalizar Pedido, o subfluxo A4 (Finalizar Pedido) é executado.

3. Se o menu escolhido for:

Fechar, o subfluxo A5 (Fechar) é executado.

Imprimir, o subfluxo A6 (Imprimir pedido) é executado.

Cada item desta tela possui uma imagem associada que atua como um indicador

das etapas realizadas pelo vendedor no processo de criação do pedido, por exemplo:

se a imagem associada ao item Cliente estiver verde, significa que já foi definido o

cliente deste pedido, caso contrário a sua imagem será vermelha. Ao iniciar este caso

de uso todas as imagens associadas aos itens devem estar na cor vermelha.

Obs.: Deve ser observado que caso o cliente que esteja sendo visitado não esteja

na lista de clientes da rota nem na agenda, o vendedor deverá coletar os dados deste

cliente manualmente através do preenchimento de um formulário. O pedido deverá ser

impresso sem cliente definido e o vendedor deverá entregar junto à empresa o

39

formulário com os dados do cliente e o pedido impresso para a efetiva finalização da

venda.

Fluxos Alternativos

A1. Definir Cliente

1. O sistema mostra duas opções ao cliente: Rota e Agenda.

2. Se a opção escolhida for Rota, o sistema mostra a lista de clientes da rota e

solicita que um cliente seja selecionado. Após selecionado segue ao passo 4.

3. Se a opção escolhida for Agenda, o sistema mostra a lista de clientes da

agenda e solicita que um cliente seja selecionado. Após selecionado segue ao

passo 4.

4. Tendo um cliente selecionado, o sistema retorna ao passo 1 do fluxo principal e

a imagem associada ao item Cliente deve ficar verde, indicando que um cliente

foi definido.

A2. Visualizar Pedido1. O sistema utiliza o caso de uso Visualizar Último Pedido para

visualizar as informações referentes ao pedido que está sendo criado e

adiciona ao caso de uso os menus: Inserir Produto, Remover Produto e Alterar

Quantidade. .


Inserir Produto, o passo 3 é executado.

Remover Produto, o passo 4 é executado.

Alterar Quantidade, o passo 5 é executado.

Voltar, o passo 6 é executado.

3. O sistema mostra a lista de produtos e solicita que o vendedor

selecione um produto e informe a quantidade desejada, inserindo estes dados

no pedido e retorna ao passo 1.

Obs.: Caso o produto selecionado já faça parte do pedido o sistema deve

apresentar a quantidade definida anteriormente para que seja modificada.

4. O sistema remove um produto apenas se ele for o item selecionado ao

executar o menu Remover Produto. Após retorna ao passo 1.

5. O sistema altera a quantidade de um produto apenas se ele for o item

selecionado ao executar o menu Alterar Quantidade. Caso o produto seja o

item selecionado o sistema deve informar a quantidade atual e solicitar que

seja modificada. Após retorna ao passo 1.

6. O sistema retorna ao passo 1 do fluxo principal e se existir no mínimo 1

produto inserido no pedido a imagem associada ao item Produto deve ficar

40

verde indicando que existem itens no pedido, caso contrário a imagem deve

ficar vermelha.

A3. Definir Forma de Pagamento

1. O sistema solicita ao vendedor que informe o número de vezes em que o

pagamento será parcelado e se a forma desejada é Cheque ou Boleto.

2. O vendedor informa o número de vezes e a forma de pagamento. Após retorna

ao passo 1 do fluxo principal.

A4. Finalizar Pedido

1. O sistema verifica se o pedido possui um cliente definido (E3), se a lista de

produtos não está vazia (E3) e se a forma de pagamento está definida (E3).

2. O sistema realiza a conexão (E2) com a aplicação web, envia as informações

do pedido (V1), recebe o número do pedido e atualiza o título da tela com este

número.

3. O sistema automaticamente associa o pedido ao último pedido do cliente.

4. As opções de definir cliente, inserir produto, remover produto, alterar

quantidade, definir forma de pagamento e finalizar pedido devem ser

desabilitadas e a imagem associada ao item Pedido emitido deve ficar em

verde para indicar que o pedido foi emitido à aplicação web.

A5. Fechar

1. O sistema retorna a tela anterior ao início caso de uso. O pedido que está

sendo criado ou já finalizado é descartado.

A6. Imprimir pedido

1. O sistema envia as informações do pedido através de sinal bluetooth à

impressora.

Obs.: Se o pedido foi finalizado a impressão deve conter também o número do

pedido gerado pela aplicação web.

Fluxos de Exceção

E1. Cancelar

O sistema volta para o passo 1 do fluxo principal.

E2. Conexão Indisponível

Se não houver sinal no momento da conexão deve ser exibida uma mensagem

para o vendedor.

41

E3. Dados do pedido não informados

O sistema exibe uma mensagem informando ao vendedor que há dados não

preenchidos e solicita que ele insira os dados necessários para finalizar o pedido.


V1. Quantidade em Estoque dos Pedidos

Caso o estoque de algum produto solicitado seja insuficiente, o sistema exibe

uma tela informando ao vendedor quais itens do pedido possuem uma quantidade em

estoque disponível inferior à solicitada pelo cliente, indicando para cada produto a

quantidade solicitada e a quantidade disponível na aplicação web. O sistema solicita

ao vendedor que confirme a realização do pedido ou cancele o envio do pedido ao

servidor da empresa. Caso o vendedor confirme o pedido, o sistema retorna ao passo

2 do subfluxo Finalizar Pedido, mas desta vez enviando uma flag para a aplicação web

informando que ela deve prosseguir com a realização do pedido independentemente

da quantidade em estoque dos produtos solicitados. Caso o vendedor cancele o

pedido, o sistema retorna ao fluxo principal.

42

5.2.4 ESPECIFICAÇÃO: LISTAR CLIENTES DA ROTA

DESCRIÇÃO

O vendedor pode visualizar através do celular a lista de clientes da sua rota, sendo

possível acessar o cadastro de cada cliente desta lista, a situação financeira do cliente

junto à empresa e seu último pedido.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e o sistema deve ter a rota

disponível.

FLUXO DE EVENTOS

Fluxo Principal


Título: Rota

Conteúdo:

- Lista de clientes da rota, exibindo a razão social de cada cliente ou nome

do cliente caso não exista razão social.

Menus: Abrir e Voltar

O sistema seleciona o primeiro cliente da lista ao apresentar a tela.

Obs.: Será visível ao lado de cada cliente da lista um símbolo representando o

status financeiro do cliente. Se o cliente estiver com o status OK o símbolo será

da cor verde, se estiver inadimplente será da cor vermelha.

2. O vendedor seleciona o cliente desejado.

3. Se o vendedor selecionar o menu Voltar, o subfluxo A1 (Voltar) é executado.

4. Se o vendedor selecionar o menu Abrir, o sistema executa o caso de uso

Visualizar Cliente.

Fluxos Alternativos

A1. Voltar

1. O sistema retorna a tela anterior ao início caso de uso.

43

5.2.5 ESPECIFICAÇÃO: LISTAR CLIENTES DA AGENDA

DESCRIÇÃO

O vendedor pode visualizar através do celular a lista de clientes da sua agenda,

sendo possível acessar o cadastro de cada cliente desta lista e a situação financeira

do cliente junto à empresa.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e o sistema deve ter a agenda

disponível.

FLUXO DE EVENTOS

Fluxo Principal


Título: Agenda

Conteúdo:

- Lista de clientes da agenda, exibindo a razão social de cada cliente ou

nome do cliente caso não exista razão social.

Menus: Abrir e Voltar.

O sistema seleciona o primeiro cliente da lista ao apresentar a tela.

Obs.: Será visível ao lado de cada cliente da lista um símbolo representando o

status financeiro do cliente. Se o cliente estiver com o status OK o símbolo será

da cor verde, se estiver inadimplente será da cor vermelha.

2. O vendedor seleciona o cliente desejado.

3. Se o vendedor selecionar o menu Voltar, o subfluxo A1 (Voltar) é

executado.

4. Se o vendedor selecionar o menu Abrir, o sistema executa o caso

de uso Visualizar Cliente.

Obs.: Ao realizar o login e receber a agenda de clientes o sistema não recebe o

último pedido dos clientes da agenda. Esta é uma decisão de projeto que tem como

objetivo a redução de custos na comunicação entre o celular e a empresa. Ainda

assim é possível que seja associado um último pedido a clientes da agenda caso o

vendedor efetue um novo pedido pelo celular a um destes clientes.

Fluxos Alternativos

A1. Voltar

1. O sistema retorna a tela anterior ao início do caso de uso.

44

5.2.6 ESPECIFICAÇÃO: VISUALIZAR CLIENTE

DESCRIÇÃO

O vendedor pode visualizar através do celular o cadastro de um cliente da rota ou

da agenda de clientes, tendo a possibilidade de acessar o status financeiro dos

clientes junto à empresa e o último pedido.

PRÉ-CONDIÇÕES

O sistema deve fornecer um cliente como parâmetro de entrada para este caso de

uso.

FLUXO DE EVENTOS

Fluxo Principal

1. O Sistema busca na memória o cadastro do cliente e apresenta uma

tela no seguinte formato:

Título: Cliente

Conteúdo:

- Razão Social

- Nome

- Endereço.

- Bairro

- Cidade

- Estado

- CEP

- Telefones, categorizados em celular, comercial e residencial.

- CPF/CNPJ

Menus: Status, Último Pedido e Voltar.


executado.


Status, o sistema executa o caso de uso Verificar Status do

Cliente.

Último pedido, o sistema executa (E1) o caso de uso

Visualizar último pedido.

Voltar, o subfluxo A1 (Voltar) é executado.

Fluxos Alternativos

A1. Voltar

45

1. O sistema retorna a tela anterior ao início deste caso de uso.

Fluxos de Exceção

E1. Último pedido não disponível

1. Caso o cliente não possua um último pedido definido deve ser exibida uma

mensagem ao vendedor.

46

5.2.7 ESPECIFICAÇÃO: VERIFICAR STATUS DO CLIENTE

DESCRIÇÃO

O vendedor pode visualizar através do celular o status financeiro de um cliente

junto à empresa.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e ter disponível o status do

cliente armazenado na memória do celular.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema busca na memória o status financeiro do cliente

cadastrado e apresenta uma tela com seguinte formato:

Título: Status

Conteúdo:

- Situação, pode ser OK ou Inadimplente.

Menu: Voltar

2. O vendedor seleciona o menu Voltar e o sistema retorna a tela

anterior à execução deste caso de uso.

47

5.2.8 ESPECIFICAÇÃO: LISTAR PRODUTOS

DESCRIÇÃO

O vendedor pode visualizar através do celular a lista de produtos disponíveis na

empresa, tendo a possibilidade de ver as informações sobre cada produto e sua

quantidade em estoque.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e o sistema deve ter a lista de

produtos disponível.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema apresenta uma tela com o seguinte formato:

Título: “Produtos”

Conteúdo:

- Lista com os nomes dos produtos da empresa

Menus: Abrir e Voltar

O sistema seleciona o primeiro produto da lista ao apresentar a tela.

2. O vendedor seleciona o produto desejado;


executado.

4. Se o vendedor selecionar o menu Abrir, o subfluxo A2 (Visualizar

produto) é executado.

Fluxos Alternativos

A1. Voltar

1. O sistema retorna a tela anterior à execução deste caso de uso.

A2. Visualizar produto

1. O sistema mostra uma tela com o título “Produto”, na qual deve mostrar o

nome do produto, a marca, a descrição, a categoria, o preço e o número de

unidades em estoque deste produto. Esta tela disponibiliza apenas o menu

Voltar que retorna ao fluxo principal.

48

5.2.9 ESPECIFICAÇÃO: VISUALIZAR ÚLTIMO PEDIDO

DESCRIÇÃO

O vendedor pode visualizar através do celular o último pedido realizado aos

clientes da sua rota ou agenda.

PRÉ-CONDIÇÕES

O vendedor deverá estar previamente autenticado e ter disponível o último pedido

do cliente armazenado na memória do celular.

FLUXO DE EVENTOS

Fluxo Principal


Título: “Pedido: Cód XX”

Conteúdo:

- Cliente, mostra a razão social do cliente que iniciou este caso de uso ou o

próprio nome se a razão social não existir.

- Valor total do pedido, soma do valor total de cada item do pedido.

- Lista com os nomes dos produtos vendidos

Menu: Voltar

2. Se o vendedor selecionar um produto, o subfluxo A1 (Visualizar Item

de Pedido) é executado.

3. Se o vendedor selecionar o menu Voltar o subfluxo A2 (Voltar) é

executado.

Fluxos Alternativos

A1. Visualizar Item de Pedido

1. O sistema deve buscar na memória as informações do pedido referentes ao

item selecionado e apresentá-las em uma tela com o seguinte formato:

Título: mostrar o nome do produto vendido

Conteúdo:

- Quantidade vendida;

- Valor unitário pelo qual foi vendido;

- Valor total, quantidade vendida multiplicada pelo valor unitário;

Obs.: O valor unitário deste caso de uso não corresponde necessariamente

ao valor unitário atual, pois o último pedido pode ter preços mais antigos

em relação aos preços unitários dos produtos disponíveis através do caso

de uso Listar produtos.

49

Menu: Voltar

2. O vendedor seleciona o menu Voltar e o sistema retorna ao passo 1 do

fluxo principal.

A2. Voltar

1. O sistema retorna a tela anterior ao início do caso de uso.

50

5.3 SERVIÇOS WEB E APLICAÇÃO WEB – MÓDULOS II, III

O módulo Serviços Web é o responsável pelo envio e recebimento de todas as

informações compartilhadas entre a Aplicação Celular e a Aplicação Web.

Através de um conjunto de serviços este módulo é responsável pela realização

do login dos vendedores no celular, pelo envio ao celular das listas de rota, agenda e

produtos e pelo registro dos pedidos no sistema. Para a implementação deste módulo

esta sendo utilizada a tecnologia Java Servlet em conjunto com o Apache Axis

Framework.

O módulo Aplicação Web utiliza a tecnologia JSP. A aplicação web fornece a

interface necessária para o cadastramento e gerenciamento das informações

disponibilizadas pelo Serviços Web para a aplicação celular e o acesso de

informações de tomada de decisão, como os dados fornecidos em relatórios e

quantidades disponíveis dos produtos na empresa. A aplicação web é composta

exclusivamente por um conjunto de páginas JSP hospedadas no servidor da empresa.

5.3.1 DIAGRAMA DE CASO DE USO

Após o levantamento de requisitos realizado, foi possível definir uma lista de todas

as funcionalidades para a aplicação web. Essa lista de funcionalidades pode ser

melhor descrita em dois diferentes diagramas de caso de uso a seguir.

Logo após são descritas as especificações de cada um dos casos de uso

apresentados.

51

Diagrama de Aplicação Web – Ator: vendedor

52

Reservado para caso de uso da aplicação web

Diagrama de Aplicação Web – Atores: Gerente e Funcionário

53

5.3.2 ESPECIFICAÇÃO: EFETUAR LOGIN

DESCRIÇÃO

Todos os usuários devem realizar autenticação no sistema para acessar as

funcionalidades do site.

PRÉ-CONDIÇÕES

Não se aplica.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema solicita que o usuário informe seu usuário e sua senha (V1);

2. O usuário digita as informações solicitadas;

3. O sistema verifica se usuário e senha conferem e realiza autenticação do

usuário no sistema. (E1);

Fluxos de Exceção

E1. Erro ao realizar a operação

Este erro pode ocorrer sempre que não for possível executar alguma operação

solicitada, normalmente devido a problemas de acesso a base de dados. A ocorrência

deste erro implica na exibição de uma mensagem para o usuário.



Todos os campos da tela são obrigatórios, portanto devem ser preenchidos. Caso

não seja preenchido, o sistema irá informar uma mensagem de erro solicitando a

informação dos campos.

54

5.3.3 ESPECIFICAÇÃO: GERENCIAR USUÁRIOS

DESCRIÇÃO

Os usuários do tipo gerente e funcionário podem realizar a manutenção dos

diferentes tipos de usuários através das opções: incluir, alterar, excluir e consultar.

PRÉ-CONDIÇÕES

O usuário deverá estar previamente autenticado e ser do tipo gerente ou

funcionário.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema solicita ao usuário que ele escolha alguma das seguintes atividades:

Incluir ou Consultar;

Se a atividade selecionada é:

Incluir, o subfluxo A1 (Incluir usuário) é executado;

Consultar, o subfluxo A4 (Consultar usuário) é executado.

Fluxos Alternativos

A1. Incluir usuário

1. O sistema mostra a tela de inclusão do usuário. A tela possui os seguintes

campos:

Campo de texto: Login;

Campo de texto: Senha;

Campo de texto: Repetir senha;

Campo de escolha: Tipo (Vendedor, Funcionário ou Gerente);

Botão: Cadastrar;

Botão: Limpar;

2. O sistema solicita o preenchimento dos campos listados acima, após

preenchimento deve ser selecionada uma ação: cadastrar ou limpar.

Se o tipo selecionado for vendedor o sistema deve solicitar ao usuário que

selecione o vendedor que deve ser associado a este novo usuário;

3. Usuário informa os dados (V1), e pressiona o botão Cadastrar;

55

4. Sistema realiza o cadastro do novo usuário (E1).

A2. Alterar usuário

1. Sistema mostra tela com as respectivas informações do usuário possibilitando

a alteração de seus dados. Na tela são apresentados também os botões

Confirmar e Cancelar.

2. Usuário realiza as alterações (V1) e pressiona Confirmar.

3. Sistema realiza as alterações na base de dados (E1).

A3. Excluir usuário

1. A exclusão do usuário é realizada (E1) e o sistema retorna ao fluxo principal.

A4. Consultar usuário:

1. O sistema executa o subfluxo A5 (Listar usuários) e solicita que seja

selecionado o usuário a ser visualizado;

2. Usuário seleciona na lista o usuário que deseja visualizar;

3. O sistema recupera as informações (E1) e mostra na tela;

4. O sistema oferece as ações de Alterar ou Excluir o usuário que esta sendo

visualizado.

5. Se o usuário selecionar a ação:

Alterar, o subfluxo A2 (Alterar usuário) é executado;

Excluir, o subfluxo A3 (Excluir usuário) é executado;

A5. Listar usuários:

1. Sistema acessa a base de dados e recupera a lista de usuários existentes (E1);

2. Sistema mostra a lista de usuários existentes;

Fluxos de Exceção



deste erro implica na exibição de uma mensagem para o usuário e em seguida no

redirecionamento do usuário para o fluxo principal.


V1. Validação dos campos Login, Senha e Repetir senha.

56

As regras de validação dos campos Senha e Repetir senha são:

Os campos Senha e Repetir senha devem possuir o mesmo valor.

Nenhum dos campos desta tela pode ter valor em branco.

Se os campos não forem preenchidos baseados nas regras acima é mostrada

uma mensagem de erro solicitando que os valores sejam preenchidos corretamente.

57

5.3.4 ESPECIFICAÇÃO: ALTERAR SENHA DO USUÁRIO AUTENTICADO

DESCRIÇÃO

Os usuários podem realizar a alteração da própria senha de acesso ao sistema.

PRÉ-CONDIÇÕES

O usuário deverá estar previamente autenticado.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema mostra tela de alteração da senha do usuário. A tela possui os

seguintes campos:

Campo de texto: Senha Antiga

Campo de texto: Nova senha

Campo de texto: Confirmar Nova Senha

Botão: Alterar;

Botão: Limpar;


preenchimento deve ser selecionada uma ação: alterar ou limpar (A1);

3. O usuário informa a senha antiga, a nova senha e a confirmação da senha

(V1), logo após aperta o botão Alterar;

4. O sistema realiza a alteração da senha do usuário (E1).

Fluxos Alternativos

A1. Limpar Campos

O sistema limpa todos os campos do formulário.

Fluxos de Exceção




58


V1. Validação dos campos Senha Antiga, Nova senha e Confirmar Nova Senha.

As regras de validação dos campos Senha Antiga, Nova senha e Confirmar Nova

Senha são:

A Senha Antiga deve conferir com a senha cadastrada no sistema.

Os campos Nova senha e Confirmar Nova Senha devem possuir o

mesmo valor.

Nenhum dos campos pode ter valor em branco.

Se os campos não forem preenchidos de acordo com as regras acima deve ser

exibida uma mensagem de erro solicitando que os valores sejam preenchidos

corretamente.

59

5.3.5 ESPECIFICAÇÃO: GERENCIAR ROTA

DESCRIÇÃO

Os usuários do tipo gerente e funcionário podem realizar a configuração da rota

de seus vendedores. Os usuários do tipo vendedor podem gerenciar apenas sua

própria rota.

PRÉ-CONDIÇÕES


FLUXO DE EVENTOS

Fluxo Principal

1. O sistema identifica se o usuário autenticado é do tipo gerente ou funcionário,

se for mostra lista de vendedores e solicita que o usuário selecione o vendedor

que deseja configurar a rota. Se o usuário autenticado é do tipo vendedor, o

sistema automaticamente seleciona o vendedor autenticado, e o fluxo segue

para o passo 3;

2. O usuário seleciona o vendedor desejado;

3. Sistema recupera as informações sobre a rota configurada para o vendedor

selecionado;

4. Usuário visualiza rota do vendedor, se houver;

5. Sistema solicita ao usuário que escolha uma das seguintes atividades:

Adicionar cliente à rota, Remover cliente da rota ou Configurar outro vendedor

(Somente para usuário do tipo funcionário ou gerente);


Adicionar cliente à rota, o subfluxo A1 (Adicionar cliente à rota) é

executado;

Remover cliente da rota, o subfluxo A2 (Remover cliente da rota) é

executado;

Configurar outro vendedor, volta ao passo 1 do fluxo principal;

60

Fluxos Alternativos

A1. Adicionar cliente à rota

1. O sistema mostra a lista de clientes (E1) existentes na base de dados e solicita

que o usuário selecione o cliente que deseja adicionar a rota do vendedor

selecionado;

2. Usuário seleciona o cliente que deseja adicionar;

3. Sistema realiza a inclusão do cliente na rota (E1).

A2. Remover cliente da rota:

1. Sistema solicita que o usuário selecione o cliente que deseja remover da rota;

2. Usuário seleciona o cliente a ser removido;

3. Sistema acessa a base de dados e exclui o cliente selecionado da rota do

vendedor (E1).

Fluxos de Exceção





61

5.3.6 ESPECIFICAÇÃO: GERENCIAR PEDIDOS

DESCRIÇÃO

Os usuários do tipo gerente e funcionário podem realizar consultas aos pedidos

realizados por um determinado vendedor, verificando suas vendas. O acesso também

é permitido para o usuário do tipo vendedor, porém com a restrição de o vendedor

poder acessar somente os pedidos realizados por ele próprio.

PRÉ-CONDIÇÕES


FLUXO DE EVENTOS

Fluxo Principal

1. O sistema identifica se o usuário autenticado é do tipo vendedor, se for apenas

os pedidos realizados por este vendedor serão retornados. O sistema informa

que as seguintes informações podem ser digitadas de modo a limitar o

resultado da pesquisa por pedido:

Nome do vendedor desejado (Campo existente apenas para usuários

do tipo funcionário ou gerente);

Nome do cliente;

Período;

Situação do pedido.

2. Usuário entra com os dados desejados;

3. Sistema lista os pedidos encontrados, baseando-se nas informações digitadas

pelo usuário, exibindo as seguintes informações sobre cada pedido:

Código do pedido;

Data da realização do pedido;

Nome do cliente;

Situação do pedido;

Nome do vendedor que realizou o pedido.

4. Usuário seleciona um pedido;

5. Sistema exibe os botões Entrar e Remover (disponível apenas para usuários

do tipo gerente e funcionário).

Se o botão pressionado for:

Entrar, o subfluxo A1 (Visualizar Pedido) é executado;

Remover, o subfluxo A2 (Remover Pedido) é executado;

62

Fluxos Alternativos

A1. Visualizar Pedido

1. O sistema exibe uma tela com as seguintes informações referentes ao pedido:

Campo de texto: Código do Pedido;

Campo de texto: Data da Venda;

Campo de texto: Vendedor que realizou a venda;

Campo de texto: Nome do Cliente;

Campo de texto: Forma de pagamento;

Campo de texto: Número de vezes em que foi parcelado o pedido;

Campo de combo: Situação;

Campo de texto: Observação;

Tabela com detalhes dos itens solicitados no pedido;

2. O sistema permite que um usuário do tipo gerente ou funcionário modifique a

situação e a observação do pedido, através da alteração dos respectivos

campos e do pressionamento do botão Alterar; Para um usuário do tipo

vendedor o sistema não permite a alteração destes campos;

3. Se o usuário modificar os campos e pressionar o botão Alterar o sistema

realiza a alteração do pedido na base de dados (E1) e retorna ao passo 1 do

fluxo principal;

A2. Remover Pedido

1. O sistema remove na base de dados o pedido selecionado (E1) e retorna ao

passo 1 do fluxo principal;

Fluxos de Exceção





63

5.3.7 ESPECIFICAÇÃO: GERENCIAR PRODUTOS

DESCRIÇÃO

Os usuários do tipo gerente e funcionário podem realizar a manutenção da base

de dados de produtos da empresa através das opções: incluir, alterar, excluir e

consultar.

PRÉ-CONDIÇÕES


funcionário.

FLUXO DE EVENTOS

Fluxo Principal




Incluir, o subfluxo A1 (Incluir produto) é executado;

Consultar, o subfluxo A4 (Visualizar produto) é executado.

Fluxos Alternativos

A1. Incluir produto

1. O sistema mostra a tela de inclusão do produto. A tela possui os seguintes

campos:

Campo de texto: Nome do produto;

Campo de texto: Marca;

Campo de texto: Descrição;

Campo de texto: Categoria;

Campo de texto: Preço;

Campo de texto: Quantidade em Estoque;

Botão: Cadastrar;

Botão: Cancelar;


preenchimento deve ser selecionada uma ação: cadastrar ou cancelar;

64

3. Usuário informa os dados (V1), e pressiona o botão Cadastrar (E1);

4. Sistema realiza o cadastro do produto (E2).

A2. Alterar produto

1. Sistema mostra tela com as respectivas informações do produto selecionado

possibilitando a alteração de seus dados. Na tela são apresentados também os

botões Confirmar e Cancelar.

2. Usuário realiza as alterações (V1) e pressiona Confirmar (E1).


A3. Excluir produto

1. Sistema remove o produto na base de dados e retorna ao fluxo principal;

A4. Visualizar produto:

1. O sistema executa o subfluxo A5 (Listar produtos) e solicita que o usuário

selecione o produto a ser visualizado;

2. Usuário seleciona na lista o produto que deseja visualizar;


4. O sistema oferece as ações de Alterar ou Excluir o produto que esta sendo

visualizado.


Alterar, o subfluxo A2 (Alterar produto) é executado;

Excluir, o subfluxo A3 (Excluir produto) é executado;

A5. Listar produtos:

1. Sistema acessa a base de dados e recupera a lista de produtos existentes

(E1);

2. Sistema mostra a lista de produtos existentes;

Fluxos de Exceção

E1. Operação cancelada

65

O cancelamento implica no descarte das informações digitadas pelo usuário e

redirecionamento para o passo 1 do fluxo principal.







Os campos nome, preço e quantidade em estoque são obrigatórios, portanto

devem ser preenchidos. Caso não sejam preenchidos, o sistema irá informar uma

mensagem de erro solicitando a informação dos campos.

66

5.3.8 ESPECIFICAÇÃO: GERENCIAR CLIENTES

DESCRIÇÃO

Os usuários do tipo gerente ou funcionário podem realizar o gerenciamento da

lista de clientes da empresa através das opções: incluir, alterar, excluir e consultar.

PRÉ-CONDIÇÕES


funcionário.

FLUXO DE EVENTOS

Fluxo Principal




Incluir, o subfluxo A1 (Incluir cliente) é executado;

Consultar, o subfluxo A4 (Visualizar cliente) é executado.

Fluxos Alternativos

A1. Incluir cliente

1. O sistema mostra a tela de inclusão do usuário. A tela possui os seguintes

campos:

Campo de texto: Nome/Nome Fantasia;

Campo de texto: Razão social;

Campo de texto: CNPJ/CPF;

Campo de texto: Endereço;

Campo de texto: CEP

Campo de texto: Bairro;

Campo de texto: Cidade;

Campo de combo: Estado;

Campo de texto: E-mail;

Campo de texto: Telefone residencial;

Campo de texto: Telefone comercial;

Campo de texto: Telefone celular;

67

Campo de combo: Situação (OK ou Inadimplente)

Botão: Cadastrar;

Botão: Cancelar;




4. Sistema realiza o cadastro do novo usuário (E2).

A2. Alterar cliente

1. Sistema mostra tela com as respectivas informações do cliente selecionado





A3. Excluir cliente

1. Sistema remove o cliente na base de dados e retorna ao fluxo principal;

A4. Visualizar cliente:

1. O sistema executa o subfluxo A5 (Listar clientes) e solicita que o usuário

selecione o cliente a ser visualizado;

2. Usuário seleciona na lista o cliente que deseja visualizar;


4. O sistema oferece as ações de Alterar ou Excluir o cliente que esta sendo

visualizado.


1. Alterar, o subfluxo A2 (Alterar cliente) é executado;

2. Excluir, o subfluxo A3 (Excluir cliente) é executado;

A5. Listar clientes:

1. Sistema acessa a base de dados e recupera a lista de clientes existentes (E2);

2. Sistema mostra a lista de clientes existentes;

Fluxos de Exceção

E1. Operação cancelada

68

Em qualquer tela o botão Cancelar pode ser pressionado. O cancelamento implica

no descarte das informações digitadas pelo usuário e redirecionamento para o passo 1

do fluxo principal.







Todos os campos da tela são obrigatórios, portanto devem ser preenchidos. Caso

não sejam preenchidos, o sistema irá informar uma mensagem de erro solicitando a

informação dos campos.

69

5.3.9 ESPECIFICAÇÃO: GERENCIAR AGENDA

DESCRIÇÃO

Os usuários do tipo gerente e funcionário podem realizar a configuração da

agenda de seus vendedores. Os usuários do tipo vendedor podem gerenciar apenas

sua própria agenda.

PRÉ-CONDIÇÕES


FLUXO DE EVENTOS

Fluxo Principal

1. O sistema identifica se o usuário autenticado é do tipo gerente ou funcionário,

se for mostra lista de vendedores e solicita que o usuário selecione o vendedor

que deseja configurar a agenda. Se o usuário autenticado é do tipo vendedor, o

sistema automaticamente seleciona o vendedor autenticado, e o fluxo segue

para o passo 3;

2. O usuário seleciona o vendedor desejado;

3. Sistema recupera as informações sobre a agenda configurada para o vendedor

selecionado;

4. Usuário visualiza agenda do vendedor, se houver;

5. Sistema solicita ao usuário que escolha uma das seguintes atividades:

Adicionar cliente à agenda, Remover cliente da agenda ou Configurar outro

vendedor (Somente para usuário do tipo funcionário ou gerente);


Adicionar cliente à agenda, o subfluxo A1 (Adicionar cliente à agenda) é

executado;

Remover cliente da agenda, o subfluxo A2 (Remover cliente da agenda) é

executado;

Configurar outro vendedor, volta ao passo 1 do fluxo principal;

70

Fluxos Alternativos

A1. Adicionar cliente à agenda

1. O sistema mostra a lista de clientes (E1) existentes na base de dados e solicita

que o usuário selecione o cliente que deseja adicionar a agenda do vendedor

selecionado;

2. Usuário seleciona o cliente que deseja adicionar;

3. Sistema realiza a inclusão do cliente na agenda (E1).

A2. Remover cliente da agenda:

1. Sistema solicita que o usuário selecione o cliente que deseja remover da

agenda;

2. Usuário seleciona o cliente a ser removido;

3. Sistema acessa a base de dados e exclui o cliente selecionado da agenda do

vendedor (E1).

Fluxos de Exceção





71

5.3.10 ESPECIFICAÇÃO: GERENCIAR VENDEDORES

DESCRIÇÃO

Os usuários do tipo gerente ou funcionário podem realizar a manutenção da lista

de vendedores da empresa através das opções: incluir, alterar, excluir e consultar.

PRÉ-CONDIÇÕES


funcionário.

FLUXO DE EVENTOS

Fluxo Principal




Incluir, o subfluxo A1 (Incluir vendedor) é executado;

Consultar, o subfluxo A4 (Visualizar vendedor) é executado.

Fluxos Alternativos

A1. Incluir vendedor

1. O sistema mostra a tela de inclusão do vendedor. A tela possui os seguintes

campos:

Campo de texto: Nome;

Campo de texto: CPF/CNPJ;

Campo de texto: Endereço;

Campo de texto: CEP;

Campo de texto: Bairro;

Campo de texto: Cidade;

Campo de combo: Estado;

Campo de texto: Telefone;

Campo de texto: E-mail;

Botão: Cadastrar;

Botão: Cancelar;

72




4. Sistema realiza o cadastro do novo vendedor (E2).

A2. Alterar vendedor

1. Sistema mostra tela com as respectivas informações do vendedor selecionado





A3. Excluir vendedor

1. Sistema remove o vendedor na base de dados e retorna ao fluxo principal;

A4. Visualizar vendedor:

1. O sistema executa o subfluxo A5 (Listar vendedores) e solicita que o usuário

selecione o vendedor a ser visualizado;

2. Usuário seleciona na lista o vendedor que deseja visualizar;


4. O sistema oferece as ações de Alterar ou Excluir o vendedor que esta sendo

visualizado.


Alterar, o subfluxo A2 (Alterar Vendedor) é executado;

Excluir, o subfluxo A3 (Excluir Vendedor) é executado;

A5. Listar vendedores:

1. Sistema acessa a base de dados e recupera a lista de vendedores existentes

(E2);

2. Sistema mostra a lista de vendedores existentes;

Fluxos de Exceção

E1. Operação canceladaO cancelamento implica no descarte das informações digitadas pelo usuário e

redirecionamento para a tela anterior.

73







Os campos nome, cpf/cnpj, endereço, cep, bairro e cidade são obrigatórios,

portanto devem ser preenchidos. Caso não sejam preenchidos, o sistema irá informar

uma mensagem de erro solicitando a informação dos campos.

74

5.3.11 ESPECIFICAÇÃO: GERAR RELATÓRIOS

DESCRIÇÃO

Os usuários do tipo Gerente podem visualizar diversos tipos de relatórios, com

base nas informações disponíveis na base de dados.

PRÉ-CONDIÇÕES

O usuário deverá estar previamente autenticado e deve ser do tipo gerente.

FLUXO DE EVENTOS

Fluxo Principal

1. O sistema mostra a tela de geração de relatórios. O sistema oferece os

seguintes tipos de relatórios:

Produtos Mais Vendidos;

Produtos Mais Lucrativos;

Clientes Mais Lucrativos;

Vendedores Mais Lucrativos;

2. O sistema solicita que o usuário selecione o tipo de relatório desejado;

3. Usuário seleciona o relatório desejado;

4. Para todos os relatórios, o sistema apresenta uma tela solicitando que o

usuário preencha o seguinte parâmetro de entrada:

Campo de texto: Ano.

5. O usuário preenche o campo ano e pressiona o botão Gerar Relatório (V1)(V2);

6. O sistema gera o relatório solicitado, restringindo os dados ao ano informado

pelo usuário (E1);

Fluxos de Exceção




75


V1. Campo obrigatório

O campo ano é obrigatório e portanto deve ser preenchido. Caso não seja

preenchido, o sistema irá informar uma mensagem de erro solicitando a informação do

campo.

V2. Campo numérico

O campo ano deve conter apenas números. Caso o usuário não utilize apenas números o sistema deve exibir uma mensagem ao usuário solicitando que utilize apenas números ao especificar o ano.

76

5.4 MODELOS DE ANÁLISE

Nesta seção são descritas entidades básicas do sistema e o relacionamento entre

as mesmas.

5.4.1 DIAGRAMA DE CLASSE: AGENDA

Essa classe aplica-se principalmente nos seguintes casos de uso: Listar clientes

da agenda (Aplicação celular) e Gerenciar agenda (Aplicação web).

Diagrama de análise: Agenda

5.4.2 DIAGRAMA DE CLASSE: HISTÓRICO DE PRODUTOS

Essa classe aplica-se principalmente no seguinte caso de uso: Visualizar histórico

(Aplicação web)

Diagrama de análise: Histórico de produtos

77

5.4.3 DIAGRAMA DE CLASSE: PEDIDO

Essa classe aplica-se principalmente nos seguintes casos de uso: Gerenciar

pedido (Aplicação celular), Visualizar último pedido (Aplicação celular) e Consultar

pedido (Aplicação web)

Diagrama de análise: Pedido

78

5.4.4 DIAGRAMA DE CLASSE: ROTA

Essa classe aplica-se principalmente nos seguintes casos de uso: Listar clientes

da rota (Aplicação celular) e Gerenciar rotas (Aplicação web).

Diagrama de análise: Rota

5.4.5 DIAGRAMA DE CLASSE: USUÁRIO

Essa classe aplica-se principalmente no seguinte caso de uso: Efetuar login

(Aplicação celular, Aplicação web).

Diagrama de análise: Usuário

79

5.4.6 DIAGRAMA DE CLASSE: ENTIDADES BASE

O diagrama a seguir visa fornecer uma visão geral dos relacionamentos entre as

entidades básicas. Essas entidades serão vistas mais adiante nos diagramas de

classes de projeto relacionando-se com as classes de controle responsáveis por cada

caso de uso.

Diagrama de análise: Entidades Base

80

5.5 MODELOS DE PROJETO

5.5.1 DIAGRAMA DE CLASSE: APLICAÇÃO CELULAR

O diagrama de classe de projeto da aplicação celular com todas as classes de

controle que implementam os casos de uso descritos na subseção 4.2 (Aplicação

Celular) pode ser visto na página a seguir:

81

DIAGRAMA DE CLASSE APLICAÇÃO CELULAR

Diagrama de classe: Aplicação Celular

82

5.5.2 DIAGRAMA DE CLASSE: APLICAÇÃO WEB – SERVLET

O diagrama de projeto aplicação web com todas as classes de controle que

implementam os casos de uso descritos na subseção 4.3 (Serviços Web e Aplicação

Web) pode ser visto na página a seguir:

83

APLICAÇÃO WEB DIAGRAMA DE CLASSE

Diagrama de classe: Aplicação Web

84

5.6 ORGANIZAÇÃO DA ARQUITETURA (PACKAGES)

O diagrama abaixo representa a organização através de packages das classes

deste projeto. Podendo ser observado que foi utilizado um mesmo conjunto de

entidades e listas básicas tanto na aplicação celular quanto na aplicação web.

Relacionamento entre packages

85

6 DISCUSSÃO DA IMPLEMENTAÇÃO

No decorrer do desenvolvimento deste projeto, inúmeros problemas surgiram e

foram contornados de alguma forma. O objetivo deste capítulo é colocar em pauta

alguns destes problemas e suas soluções.

A transferência de dados entre o dispositivo móvel e a aplicação web foi uma

questão que gerou dúvidas no momento de sua implementação. Após ter sido

realizada uma pesquisa, verificou-se que atualmente se faz uso largamente da

tecnologia de webservice para a troca de informações entre diferentes sistemas. Entre

seus benefícios está a transparência na chamada dos recursos da aplicação servidora,

através da chamada remota de métodos dos objetos que estão no servidor. A

transferência dos objetos ocorre de forma transparente através de objetos mapeados

via SOAP/XML trafegando sobre HTTP.

Dessa forma, nesse projeto foi adotado a tecnologia de webservices, por ser

uma tecnologia robusta e consolidada para a transferência de objetos, já possuindo

controle de erros e uma forma própria e transparente de mapear cada um dos objetos

a serem transferidos, suas informações e serviços disponíveis.

No entanto, a utilização desta tecnologia gerou um overhead grande que elevou

a quantidade de informações transferidas entre as a aplicação móvel e o servidor

aumentando assim o custo de utilização de nosso solução. Uma solução alternativa

para esse problema que reduz a quantidade de informações transmitidas seria não

utilizar a tecnologia de webservices, perdendo assim os benefícios decorrentes disto já

citados, e utilizar uma simples transferência de arquivos em algum formato

simplificado, como por exemplo CSV (Comma-separated values).

Essa solução alternativa também possui alguns problemas consideráveis, como a

necessidade da elaboração de uma estrutura complexa para o armazenamento de

listas de itens, para tratar os casos de objetos que possuem coleções dentro de sua

estrutura. Os benefícios desta nova solução podem ser melhor compreendidos a partir

da análise do custo para o recebimento através do celular de uma quantidade de 100

e 200 produtos no formato XML definido pelo webservice e no formato CSV.

100 Produtos 200 ProdutosFormato Kb R$ Formato Kb R$Webservice 114 0,72 Webservice 228 1,44CSV 9 0,057 CSV 18 0,11

Tabela 1: Comparativo de custos para transferências nos formatos XML e CSV

86

A partir da tabela 1 é possível verificar uma diminuição do custo de doze vezes

para o recebimento das informações da aplicação celular, porém essa constatação só

foi percebida assim que o sistema já estava em funcionamento através dos testes de

performance realizados.

A quantidade de informação transferida entre as aplicações sempre foi a questão

crucial deste sistema, pois se o mesmo tivesse um custo muito elevado não seria

interessante para as empresas que desejavam automatizar suas vendas. Dessa

forma, quando este projeto foi proposto a idéia era apenas sincronizar com o servidor

os dados recebidos, apenas verificando que informações foram inseridas e quais

foram alteradas, recebendo essas informações durante a abertura do aplicativo

celular.

No entanto, na prática essa sincronização não foi possível realizar, pois havia a

necessidade de sincronizar as informações que foram apagadas do servidor, para isso

era necessário que fossem criados mecanismos de exclusão lógicas no servidor, com

flags que indicassem quais itens foram excluídos, porém tal mecanismo necessitaria

que a aplicação celular realizasse uma série de trocas de informações com o celular

para verificar se alguma de suas informações foi apagada e isso geraria um alto custo.

Dessa forma, se tornaria inviável a implementação desta sincronização. A solução

encontrada foi realizar a sincronização de todas as informações cada vez que a

aplicação celular for iniciada, que deverá ocorrer apenas uma vez ao dia, embora

também possua um alto custo, essa solução garante a sincronização dos dados,

necessários a uma aplicação deste gênero. A manutenção dos dados por parte dos

gerentes e funcionários, como alteração de preços deverão ser feito apenas em

horários estabelecidos pela empresa em que não esteja havendo vendas pelo

aparelho, de forma a evitar vendas com valores inconsistentes.

Mais tarde, verificou-se que nossa solução que tinha como objetivo se destacar

entre suas concorrentes pelo uso do celular como dispositivo móvel, explorou esses

recursos de uma forma errada, buscando a inovação e não o complemento as

soluções existentes.

Algumas soluções existentes, como aplicações para Palm Top, que oferecem

soluções interessantes que deveriam ter sido integradas a nossa, tem sua base de

dados transferida na sede da empresa. Funcionalidades como essa deveriam ter sido

agregadas a aplicação celular e mudanças em relação a sincronização das

informações trariam significativas melhoras a solução, como por exemplo, realizar a

atualização dos produtos, clientes e outros apenas quando inseridos em um pedido,

87

ou seja conforme demanda, quando um produto ou cliente é selecionado uma

atualização dessas informações poderia ser feita, dessa forma não haveria a

necessidade de receber todos os tentar verificar a atualização de todos os registros do

celular e sim somente daqueles que fazem parte da venda. Ocorrendo o recebimento

da maior parte das informações sem custo telefônico na sede da empresa através de

transferência por cabo. Essa solução manteria a principal característica de nossa

solução que é a capacidade de deixar o vendedor se afastar da base, e despachar

seus pedidos para a empresa no momento da venda, porém diminuirá bastante os

custos para as empresas.

Um fator positivo no desenvolvimento deste projeto, foi a capacidade de integrar

diversas novas tecnologias, de forma a acelerar o processo de desenvolvimento

utilizando uma série de bibliotecas e frameworks open source que auxiliam no

desenvolvimento. Entre algumas dessas bibliotecas podemos salientar o uso de

combos autocompletar que fazem uso da tecnologia ajax, que torna mais fácil a

seleção de pessoas na aplicação web, aumentando consideravelmente a usabilidade

da aplicação se comparado a aplicações web convencionais, que fazem uso de

mecanismo de busca abrindo janelas popup, etc.

Os problemas destacados neste capítulo relativo a implementações realizadas não

tem como objetivo tornar inválidas tais soluções, porém apenas demonstram que a

pesquisa realizada durante o desenvolvimento deste projeto, possibilitaram uma série

de constatações que tornam possível a elaboração de um sistema mais robusto e

eficiente do que o aqui desenvolvido se não fosse o tempo reduzido do projeto.

88

7 CONCLUSÃO

O desenvolvimento de uma solução na área de automação da força de vendas

envolve uma série de desafios que exigem um estudo multidisciplinar e uma análise

cuidadosa dos fatores envolvidos.

A pesquisa e o desenvolvimento inicial deste projeto permitiram explorar assuntos

abordados durante o curso de bacharelado em ciência da computação, auxiliando na

consolidação de conhecimentos e técnicas estudadas em disciplinas do curso tais

como engenharia de software, programação entre outras. O projeto possibilitou

também a investigação em novas áreas e assuntos não abordados diretamente no

curso de graduação, servindo para posicionar os autores no estado da arte do tópico

em questão.

Através deste projeto foi possível conhecer as tecnologias oferecidas pelos

aparelhos celulares atuais e suas inúmeras limitações como, por exemplo, o baixo

poder de processamento e baixa quantidade de memória. Essas limitações tornam

evidente que as tecnologias para dispositivos móveis encontram-se no seu estágio

inicial e devemos estar preparados e atentos acompanhando o crescimento desta

nova área de atuação que promete ter muito potencial a ser explorado.

A escolha do uso de aparelhos celulares no processo de vendas já é uma

realidade fora do meio acadêmico, porém normalmente os recursos disponibilizados

pelas tecnologias existentes tem sido pouco explorados. Algumas soluções propõem a

utilização de Palms ou Notebooks, porém essas soluções proporcionam um grande

inconveniente aos vendedores que em alguns casos possuem rotas longas, muitas

vezes em outras cidades ou estados, já que limitam a transmissão das informações

sobre os pedidos realizados a horários pré-estabelecidos ou ao fim do dia,

conectando-se a internet através de linhas telefônicas convencionais em hotéis ou lan-

houses, ou através do acoplamento de telefones celulares aos dispositivos para

permitir a comunicação com a empresa.

Outras soluções se utilizam da visita do vendedor a sede da empresa como única

forma de entrega das informações dos pedidos. Esta é uma opção bastante

rudimentar e pouco automatizada para uma solução que propõe tal informatização do

processo.

O sistema projetado possui uma série de pontos fortes ligados diretamente a sua

arquitetura centrada no dispositivo celular para promover a automação. Um desses

89

pontos fortes é o fato do sinal para dispositivos celulares cobrir praticamente todas as

zonas urbanas no território nacional possibilitando que um mesmo vendedor

instantaneamente, não importando o local em que esteja, possa iniciar os processos

de entrega das mercadorias junto à empresa no momento do fechamento do pedido.

Alguns pontos fracos deste sistema que podem ser salientados seriam as

limitações existentes entre a comunicação vendedor e empresa estabelecidas pelos

altos valores cobrados pela utilização da telefonia celular e as baixas taxas de

transferências de dados, que faz com que o sistema utilize a comunicação celular

apenas quando realmente necessário como no fechamento dos pedidos, impedindo

uma série de outros recursos que seriam possíveis caso houvesse uma conexão

permanente entre vendedor e empresa.

Outras características interessantes também não foram implementadas neste

projeto devido ao caráter acadêmico do mesmo, como a possível integração deste

sistema com sistemas financeiros, que possibilitaria um novo conjunto de

funcionalidades que não são incluídas neste projeto.

Apesar destas deficiências, através deste projeto novas portas para a exploração

deste promissor mercado serão abertas, sendo este o primeiro de vários projetos que

ainda desenvolveremos tanto no âmbito da automação de forças de vendas, quanto na

solução de outros problemas que também envolvem as tecnologias envolvidas neste

projeto.

90

BIBLIOGRAFIA

[1] Edwards, Leigh. Developing series 60 applications: a guide for symbian OS C++ developers. Boston: Addison-Wesley, 2004. 749 p.

[2] Lee, Valentino. Mobile applications: architecture, design, and development. Upper Saddle River: Pearson Education, 2004. 340 p.

[3] Pavetits, Lenke. Conexão em movimento, Rio de Janeiro, ano. 1, n. 1, p. 4-7, fev. 2005.

[4] Brown, Stanley A.. CRM customer relationship management: uma ferramenta estratégica para o mundo e-Business. São Paulo: Makron Books, 2001. 331 p.

[5] Jacobson, Ivar. The unified software development process. Addison-Wesley, 1999. 463 p.

[6] Hunt, John. The unified process for practitioners: object-oriented design, UML and Java. London: Springer, 2000. 280 p.

[7] Moreira, Júlio. Administração de vendas. São Paulo: Saraiva, 2001. 306 p.

[8] Wealth Systems, SIV - Solução Integrada de Vendas. Disponível em: <http://www.wealthsystems.com.br/pages/siv.php>. Acesso em: 25 mar. 2006.

[9] Cia Quatro, Mercador Circuito. Disponível em: <http://www.ciaquatro.com.br/mercador/>. Acesso em: 25 mar. 2006.

[10] Easyven, Mobile Integration. Disponível em: <http://www.easyven.com/portugues/produtos/vendas.htm>. Acesso em: 25 mar. 2006.

[11] Burlamaqui, Paulo. Informatização da força de vendas. Análise, v.14, n.1, 2003, 2003. p.171-183.

[12] NOKIA, Forum. Device Details - Nokia 6600. Disponível em: <http://www.forum.nokia.com/main/0,,018-2209,00.html?model=6600>. Acesso em 10 mar. 2006.

[13] Piroumian, Vartan. Wireless J2ME platform programming. Palo Alto: Sun Microsystems, 2002. 374 p.

[14] Keogh, James. J2ME: The complete reference. New York: McGraw-Hill, 2003. 745 p.

[15] Hunter, Jason. Java servlet programming. Beijing: O'Reilly, 2001. 780 p.

[16] Heine, Gunnar. GSM networks: protocols, terminology, and implementation. Artech House, 1998. 416 p.

[17] Andersson, Christoffer. GPRS and 3G Wireless Applications. John Wiley & Sons, 2001. 352 p.

91

[18] Pedralho, André. Bluetooth: da teoria à prática. O mundo sem cabos – Parte I. Rio de Janeiro, ano. 1, n. 3, p. 16-20, jun. 2005.

[19] Gallardo, David. Eclipse in action: a guide for java developers. Greenwich: Manning, 2003. 383 p.

[20] Knudsen, Jonathan. Wireless Java: developing with J2ME 2. Berkeley: Apress, 2003. 364 p.

92

ANEXOS

APÊNDICE 1 - CRONOGRAMA

ATIVIDADES

Para a relação de atividades é importante ressaltar que o sistema final possui

uma série de limitações. Foram incluídas apenas funcionalidades mínimas em relação

a uma aplicação do gênero, pois uma versão comercial para esse sistema só poderá

ser obtida após um trabalho considerável de desenvolvimento, tendo em vista uma

equipe e número de horas maiores para o projeto e desenvolvimento do mesmo. As

limitações do sistema final dizem respeito principalmente as funcionalidades dos

módulos, que foram reduzidas, considerando o potencial a ser explorado em uma

aplicação como essa.

Na Tabela 1, é apresentado o cronograma de atividades realizadas durante o

desenvolvimento do projeto no primeiro semestre de 2006.

Tabela 1: Cronograma das Atividades do TC1

Fases Concepção Elaboração

Semestre 2006/1 Março Abril Maio Junho

Revisão Bibliográfica

Estudo das Tecnologias Envolvidas

Modelagem do Negócio e Cases

Redação da Proposta

Levantamento de Requisitos

Modelagem de Análise

Modelagem de Projeto

Redação do Trabalho de Conclusão I

Na Tabela 2, é apresentado o cronograma de atividades previstas para o

desenvolvimento do projeto para o segundo semestre de 2006.

Tabela 2: Cronograma das Atividades para TC2

93

Fases Construção Transição

Semestre 2006/2 Agosto Setembro Outubro Novembro


Implementação

Testes

Análise dos Resultados

Redação do Trabalho de Conclusão II

DESCRIÇÃO DAS ATIVIDADES

Atividades realizadas em 2006/1

Revisão Bibliográfica

Revisão da literatura disponível sobre dispositivos móveis, processos de vendas e

tecnologias relevantes à elaboração deste projeto.

Estudo das Tecnologias Envolvidas

Elaboração de exemplos envolvendo aplicações web, aplicações para celulares,

acesso HTTP via celular. Testes com diferentes ambientes de desenvolvimentos.

Testes de implantação de aplicativos Java em diferentes modelos de celulares.

Modelagem do Negócio e Cases

Análise do negócio e dos processos de vendas, estudos de caso baseado na

automação de outras empresas.

Redação da Proposta

Elaboração da descrição da proposta de Trabalho de Conclusão I.

Levantamento de Requisitos

Detalhamento das funcionalidades do sistema, com base em estudo de casos de

automação de empresas, em entrevistas a possíveis usuários do sistema e

vendedores.

94

Modelagem de Análise

Elaboração de artefatos em nível de análise referentes ao processo unificado.


Elaboração de artefatos em nível de projeto referentes ao processo unificado.

Redação do Trabalho de Conclusão I

Elaboração do Trabalho de Conclusão I.

Atividades para 2006/2


Refinamento de artefatos em nível de projeto referentes ao processo unificado.

Implementação

Implementação do sistema projetado no Trabalho de Conclusão I

Testes

Execução de diversos tipos de testes na aplicação celular, no serviço web e na

aplicação web.

Análise dos Resultados

Análise dos resultados dos testes e execução de possíveis ajustes necessários na

implementação do sistema.

Redação do Trabalho de Conclusão II

Elaboração do documento final de Trabalho de Conclusão II.

95

APÊNDICE 2 – CELULARES PESQUISADOS

Foi realizada uma pesquisa com o objetivo de verificar quais tecnologias os

celulares disponíveis no mercado suportam visando encontrar o aparelho celular que

melhor se enquadra de acordo com as necessidades deste projeto. A tabela resultante

dessa pesquisa pode ser vista nas páginas seguintes.

96

TC2 - reta final marcelo 21 11 18 22.doc

Documents

Transcript of TC2 - reta final marcelo 21 11 18 22.doc