tc2 - reta final marcelo 21 11 18 22.doc
DESCRIPTION
TRANSCRIPT
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
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
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.
Suas principais funcionalidades sã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.
Suas principais funcionalidades são:
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
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
1. O sistema apresenta uma tela no seguinte formato:
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. .
2. Se o menu escolhido for:
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.
Fluxos de Validação
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
1. O sistema apresenta uma tela no seguinte formato:
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
1. O sistema apresenta uma tela no seguinte formato:
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.
2. Se o vendedor selecionar o menu Voltar, o subfluxo A1 (Voltar) é
executado.
3. Se o menu escolhido for:
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;
3. Se o vendedor selecionar o menu Voltar, o subfluxo A1 (Voltar) é
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
1. O sistema apresenta uma tela no seguinte formato:
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.
Fluxos de Validação
V1. Campos obrigatórios
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
E1. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
Fluxos de Validação
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;
2. O sistema solicita o preenchimento dos campos listados acima, após
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
E1. Erro ao realizar a operaçãoEste 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.
58
Fluxos de Validação
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
O usuário deverá estar previamente autenticado.
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);
Se a atividade selecionada é:
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
E1. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
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
O usuário deverá estar previamente autenticado.
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
E1. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
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
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 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;
2. O sistema solicita o preenchimento dos campos listados acima, após
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).
3. Sistema realiza as alterações na base de dados (E2).
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;
3. O sistema recupera as informações (E2) e mostra na tela;
4. O sistema oferece as ações de Alterar ou Excluir o produto que esta sendo
visualizado.
5. Se o usuário selecionar a ação:
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.
E2. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
Fluxos de Validação
V1. Campos obrigatórios
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
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 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;
2. O sistema solicita o preenchimento dos campos listados acima, após
preenchimento deve ser selecionada uma ação: cadastrar ou cancelar;
3. Usuário informa os dados (V1), e pressiona o botão Cadastrar (E1);
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
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).
3. Sistema realiza as alterações na base de dados (E2).
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;
3. O sistema recupera as informações (E2) e mostra na tela;
4. O sistema oferece as ações de Alterar ou Excluir o cliente que esta sendo
visualizado.
5. Se o usuário selecionar a ação:
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.
E2. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
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.
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
O usuário deverá estar previamente autenticado.
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);
Se a atividade selecionada é:
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
E1. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
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
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 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
2. O sistema solicita o preenchimento dos campos listados acima, após
preenchimento deve ser selecionada uma ação: cadastrar ou cancelar;
3. Usuário informa os dados (V1), e pressiona o botão Cadastrar (E1);
4. Sistema realiza o cadastro do novo vendedor (E2).
A2. Alterar vendedor
1. Sistema mostra tela com as respectivas informações do vendedor 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).
3. Sistema realiza as alterações na base de dados (E2).
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;
3. O sistema recupera as informações (E2) e mostra na tela;
4. O sistema oferece as ações de Alterar ou Excluir o vendedor que esta sendo
visualizado.
5. Se o usuário selecionar a ação:
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
E2. Erro ao realizar a operaçãoEste 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 e em seguida no
redirecionamento do usuário para o fluxo principal.
Fluxos de Validação
V1. Campos obrigatórios
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
E1. Erro ao realizar a operaçãoEste 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.
75
Fluxos de Validação
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
Modelagem de Projeto
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.
Modelagem de Projeto
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
Modelagem de Projeto
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
97
98
99
100