centro estadual de educação tecnológica paula souza

Transcrição

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
LARISSA RATTIGUERI CARDOSO
LUCAS DANIEL FERREIRA
PROTÓTIPO DE SISTEMA WEB PARA GESTÃO COMERCIAL,
INTEGRADO A APLICATIVO ANDROID
LINS/SP
2º SEMESTRE/2013
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
PROTÓTIPO DE SISTEMA WEB PARA GESTÃO COMERCIAL,
INTEGRADO A APLICATIVO ANDROID
Trabalho de Conclusão de Curso
apresentado à Faculdade de Tecnologia
de Lins para obtenção do Título de
Tecnólogo (a) em Banco de Dados.
Orientador: Prof. Me. Paulo Augusto Nardi
LINS/SP
2º SEMESTRE/2013
PROTÓTIPO DE SISTEMA WEB PARA GESTÃO COMERCIAL, INTEGRADO A
APLICATIVO ANDROID
Trabalho
de
Conclusão
de
Curso
apresentado à Faculdade de Tecnologia
de
Lins,
como
parte
dos
requisitos
necessários para a obtenção do título de
Tecnólogo(a) em Banco de Dados sob
orientação do Prof. Me. Paulo Augusto
Nardi.
Data de aprovação: ___/___/___
____________________________
Orientador (Prof. Me. Paulo Augusto Nardi)
______________________________
Examinador 1 (Nome do Examinador)
______________________________
Examinador 2 (Nome do Examinador)
Aos meus pais Fátima e Sergio, a minha
irmã Micheli e ao meu irmão Vinicius. Que
sempre me deram todo o apoio que precisei.
E que estão sempre ao meu lado.
Larissa Rattigueri Cardoso
Aos meus pais Antonio e Sandra, e ao meu
irmão Danilo, que sempre incentivaram-me
a estudar e apoiaram em todos os momentos.
Lucas Daniel Ferreira
AGRADECIMENTOS
Ao fim de uma fase concluída, agradecemos primeiramente às nossas
famílias por contribuírem imensamente durante todo o decorrer do curso de
tecnologia em Banco de Dados.
Agradecemos especialmente a nosso orientador Me Paulo Augusto Nardi, por
preocupar-se para que conseguíssemos desenvolver um bom trabalho. Pela
dedicação e compromisso ao nos atender e instruir para que fosse concluída cada
etapa.
Nosso sincero agradecimento a todos os amigos que incentivaram desde o
início, principalmente ao nosso amigo Lucas Yoshioka que caminhou ao nosso lado,
trocando experiências e dividindo conhecimento durante a elaboração do trabalho.
Agradecemos ainda aos colegas de classe que proporcionaram momentos de
descontração.
Agradecemos também aos colegas de trabalho, que nos encorajaram a
persistir mesmo que a situação fosse adversa. Um agradecimento especial ao nosso
amigo Rafael Garcia, que colaborou imensamente com conselhos e dicas que foram
de enorme auxilio durante a aplicação prática do projeto.
Somos gratos também ao Paulo, gerente do Bar e Pizzaria Arena Castelli, por
disponibilizar algumas horas de seu tempo para atender-nos, sendo fundamental
para a análise de negócios e levantamento de requisitos do sistema.
Por fim, gostaríamos de registrar o sincero agradecimento a todos os
professores e funcionários da FATEC Lins, pelos ensinamentos e conselhos
compartilhados, bem como o compromisso com a educação.
RESUMO
A finalidade do projeto é o desenvolvimento de um sistema web integrado a um
aplicativo android para estabelecimentos alimentícios (lanchonetes, bares,
pizzarias). O sistema tem o intuito de agilizar o processo de pedidos e fornecer um
controle de fluxo caixa seguro para qualquer estabelecimento que queira
automatizar seus processos. A integração entre a aplicação web e o aplicativo móvel
é o foco principal do trabalho. Para o desenvolvimento do projeto foram utilizadas a
linguagem de programação Java, a linguagem de marcação HTML, frameworks que
auxiliam no desenvolvimento web como JSF e PrimeFaces, a ferramenta CASE
Astah para a criação de diagramas, e o NetBeans e Eclipse para o desenvolvimento
web e Android respectivamente.
Palavras-chave: sistema web, web service, android, aplicativo.
ABSTRACT
The purpose of the project is the development of a web system integrated to an
android application for food establishments (cafes, bars, pizzerias, etc.) to streamline
the ordering process and provide a safe control of cash flow, for any establishment
that wants to automate their processes which are done manually. For the
development of the project was used Java language, the markup language HTML,
frameworks that assist in web development as JSF and PrimeFaces, Astah CASE
tool was used to create the diagrams, NetBeans and Eclipse IDEs were used to
develop the system and android application respectively.
Keywords: web system, web service, android application.
LISTA DE ILUSTRAÇÕES
Figura 3.1 – Diagrama de Caso de Uso .................................................................... 43
Figura 3.2 – Modelo Lógico ....................................................................................... 49
Figura 3.3 – Modelo Relacional ................................................................................. 50
Figura 3.4 – Diagrama de Classe .............................................................................. 51
Figura 3.5 – Diagrama de Atividade Manter Usuários ............................................... 52
Figura 3.6 – Diagrama de Atividade Login ................................................................ 53
Figura 3.7 – Diagrama de Atividade Trocar Mesa ..................................................... 53
Figura 3.8 – Diagrama de Atividade Manter Produtos............................................... 54
Figura 3.9 – Diagrama de Atividade Manter Categorias ............................................ 54
Figura 3.10 – Diagrama de Atividade Manter Caixas ................................................ 55
Figura 3.11 – Diagrama de Atividade Manter Tipos de Acréscimos .......................... 55
Figura 3.12 – Diagrama de Atividade Manter Mesas ................................................ 56
Figura 3.13 – Diagrama de Atividade Manter Vendas ............................................... 56
Figura 3.14 – Diagrama de Atividade Manter Pagamento de Itens ........................... 57
Figura 3.15 – Diagrama de Atividade Manter Itens ................................................... 58
Figura 3.16 – Diagrama de Atividade Manter Clientes .............................................. 58
Figura 3.17 – Diagrama de Atividade Manter Entregas............................................. 59
Figura 3.18 – Diagrama de Atividade Abrir Caixa ..................................................... 59
Figura 3.19 – Diagrama de Atividade Suprir Caixa ................................................... 60
Figura 3.20 – Diagrama de Atividade Retirar do Caixa ............................................. 60
Figura 3.21 – Diagrama de Atividade Lançar em Caixa ............................................ 61
Figura 3.22 – Diagrama de Atividade Fechar Caixa .................................................. 62
Figura 3.23 – Diagrama de MVC Manter Usuários.................................................... 63
Figura 3.24 – Diagrama de MVC Login ..................................................................... 63
Figura 3.25 – Diagrama de MVC Trocar Mesa .......................................................... 64
Figura 3.26 – Diagrama de MVC Manter Categorias ................................................ 64
Figura 3.27 – Diagrama de MVC Manter Produtos ................................................... 65
Figura 3.28 – Diagrama de MVC Manter Acréscimos ............................................... 65
Figura 3.29 – Diagrama de MVC Manter Caixas ....................................................... 66
Figura 3.30 – Diagrama de MVC Manter Cliente....................................................... 66
Figura 3.31 – Diagrama de MVC Manter Entrega ..................................................... 67
Figura 3.32 – Diagrama de MVC Manter Mesa ......................................................... 67
Figura 3.33 – Diagrama de MVC Manter Item ........................................................... 68
Figura 3.34 – Diagrama de MVC Manter Pagamento ............................................... 68
Figura 3.35 – Diagrama de MVC Abrir Caixa ............................................................ 69
Figura 3.36 – Diagrama de MVC Fechar Caixa......................................................... 69
Figura 3.37 – Diagrama de MVC Retirar do Caixa .................................................... 70
Figura 3.38 – Diagrama de MVC Suprir Caixa .......................................................... 70
Figura 3.39 – Diagrama de MVC Manter Lançamento .............................................. 71
Figura 3.40 – Diagrama de MVC Manter Venda ....................................................... 71
Figura 3.41 – Diagrama de Sequência Manter Usuário ............................................ 72
Figura 3.42 – Diagrama de Sequência Login ............................................................ 73
Figura 3.43 – Diagrama de Sequência Manter Lançamento ..................................... 73
Figura 3.44 – Diagrama de Sequência Manter Caixas .............................................. 74
Figura 3.45 – Diagrama de Sequência Abrir Caixa ................................................... 74
Figura 3.46 – Diagrama de Sequência Manter Categorias ....................................... 75
Figura 3.47 – Diagrama de Sequência Manter Lançamento ..................................... 75
Figura 3.48 – Diagrama de Sequência Manter Entregas .......................................... 76
Figura 3.49 – Diagrama de Sequência Suprir Caixa ................................................. 76
Figura 3.50 – Diagrama de Sequência Manter Cliente.............................................. 77
Figura 3.51 – Diagrama de Sequência Retirar do Caixa ........................................... 77
Figura 3.52 – Diagrama de Sequência Manter Mesa ................................................ 78
Figura 3.53 – Diagrama de Sequência Trocar Mesa ................................................. 78
Figura 3.54 – Diagrama de Sequência Manter Itens ................................................. 79
Figura 3.55 – Diagrama de Sequência Manter Pagamento ...................................... 79
Figura 3.56 – Diagrama de Sequência Manter Produtos .......................................... 80
Figura 3.57 – Diagrama de Sequência Manter Venda .............................................. 80
Figura 3.58 – Diagrama de Sequência Manter Acréscimos ...................................... 81
Figura 4.1 – Login ..................................................................................................... 82
Figura 4.2 – Login módulo Android ........................................................................... 83
Figura 4.3 – Cadastro de Produtos ........................................................................... 83
Figura 4.4 – Cadastro de Produtos (Opção “Novo”) .................................................. 84
Figura 4.5 – Cadastro de Produtos (Opção “Alterar”)................................................ 85
Figura 4.6 – Tela de Vendas ..................................................................................... 85
Figura 4.7 – Itens da Venda (Aba Itens a Pagar) ...................................................... 86
Figura 4.8 – Cadastro de Item ................................................................................... 87
Figura 4.9 – Dividir Itens ........................................................................................... 87
Figura 4.10 – Itens Divididos ..................................................................................... 88
Figura 4.11 – Registrar Pagamento .......................................................................... 88
Figura 4.12 – Itens da Venda (Aba Itens Pagos)....................................................... 89
Figura 4.13 – Realizar pedido módulo Android ......................................................... 89
Figura 4.14 – Gravar pedido...................................................................................... 90
Figura 4.15 – Registro de atendimento ..................................................................... 90
Figura 4.16 – Gerar Recibo ....................................................................................... 91
Figura 4.17 – Recibo de Pagamento ......................................................................... 91
Figura 1 – Classe Principal – ValidaSocket ............................................................... 93
Figura 2 – ValidaSocketThread ................................................................................. 94
Figura 3 – Classe Valida ........................................................................................... 95
Figura 4 – Método validaLogin .................................................................................. 96
Figura 5 – Criando um Web Service ......................................................................... 96
Figura 6 – Criando um Web Service preenchendo os campos. ................................ 97
Figura 7 – Arquivo do Web Service ........................................................................... 97
Figura 8 – Pasta dos Web Services .......................................................................... 97
Figura 9 – Adicionar operação .................................................................................. 98
Figura 10 – Adicionar detalhes da operação ............................................................. 98
Figura 11 – Arquivo gerado pelo Web Service. ......................................................... 99
Figura 12 – Método selectCategoriaAndroid() ......................................................... 100
Figura 13 – LoginActivity ......................................................................................... 101
Figura 14 – Classe Valida ....................................................................................... 102
Figura 15 – Arquivos .JAR da biblioteca ksoap ....................................................... 103
Figura 16 – Classe Categoria .................................................................................. 103
Figura 17 – Classe ConexaoWS ............................................................................. 104
Figura 18 – VendaActivity ....................................................................................... 105
Figura 19 – MyAsyncTask2 parte 1 ......................................................................... 106
Figura 20 – MyAsyncTask2 parte 2 ......................................................................... 107
Figura 21 – Método preencherListaProdutos(String[])............................................. 107
LISTA DE GRÁFICOS
Gráfico 1. 1 – Índice TIOBE.............................................................................................24
LISTA DE ABREVIATURAS E SIGLAS
API - Application Programming Interface
ARO - Army Research Office
ASP - Active Server Pages
CASE - Computer Aided Software Engeneering
CSS - Cascading Style Sheet
DARPA - Defense Advanced Research Projects Agency
DER - Diagrama de Entidade e Relacionamento
DNS - Domain Name System
ERP - Enterprise Resource Planning
GUI - Graphical User Interfaces
HTC - High Tech Computer Corporation
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol Secure
IBM - International Business Machines
IDE - Integrated Development Environment
IP - Internet Protocol
JAR - Java Archive
JCP - Java Community Process
JDBC - Java Database Connectivity
JSF - JavaServer Faces
JSP - JavaServer Pages
JVM - Java Virtual Machine
MVC - Model-View-Controller
NSF - National Science Foundation
OMG - Object Management Group
OO - Orientado a Objeto
PHP - Hypertext Preprocessor
PL/SQL - Procedural Language/Structured Query Language
SDK - Software Development Kit
SGBD - Sistema Gerenciador de Banco de Dados
SGML - Standard Generalized Markup Language
SQL - Structured Query Language
TCP - Transmission Control Protocol
UML - Unified Modeling Language
W3C - World Wide Web Consortium
WS - Web Service
XML - eXtensible Markup Language
LISTA DE SÍMBOLOS
% – Porcentagem
@ – Arroba
SUMÁRIO
INTRODUÇÃO .......................................................................................................... 19
1 FERRAMENTAS E TECNOLOGIAS ...................................................................... 21
1.1 UML ..................................................................................................................... 21
1.2 ASTAH ................................................................................................................ 23
1.3 JAVA ................................................................................................................... 23
1.3.1 JavaServer Faces (JSF) ................................................................................... 24
1.3.2 PrimeFaces ...................................................................................................... 26
1.3.3 Netbeans IDE ................................................................................................... 27
1.3.4 Eclipse .............................................................................................................. 28
1.3.5 JDBC ................................................................................................................ 29
1.4 SQL ..................................................................................................................... 29
1.4.1 PostgreSQL ...................................................................................................... 29
1.4.2 Plpg/SQL .......................................................................................................... 30
1.5 XML ..................................................................................................................... 31
1.6 ANDROID ............................................................................................................ 32
2 ANÁLISE DE NEGÓCIO ........................................................................................ 34
2.1. INSTRUÇÃO DO PROBLEMA ........................................................................... 34
2.2 ANÁLISE DE MERCADO .................................................................................... 35
2.3 ATORES ENVOLVIDOS ..................................................................................... 35
2.3.1 Gerente ............................................................................................................ 36
2.3.2 Atendente ......................................................................................................... 36
2.3.3 Cozinha ............................................................................................................ 37
2.3.4 Caixa ................................................................................................................ 37
2.4 DESCRIÇÕES DO AMBIENTE ATUAL............................................................... 38
2.5 PERSPECTIVAS DO PRODUTO........................................................................ 38
2.6 CARACTERISTICAS ........................................................................................... 39
2.6.1 Alta Prioridade .................................................................................................. 39
2.6.2 Média Prioridade .............................................................................................. 39
2.6.3 Baixa Prioridade ............................................................................................... 40
2.7 OUTROS REQUISITOS ...................................................................................... 40
3 ARQUITETURA DO SOFTWARE ......................................................................... 42
3.1 ANÁLISE DE REQUISITOS FUNCIONAIS ......................................................... 42
3.1.1 Atendente ......................................................................................................... 42
3.1.2 Gerente ............................................................................................................ 42
3.1.3 Caixa ................................................................................................................ 42
3.2 DIAGRAMA DE CASO DE USO ......................................................................... 43
3.3 ESPECIFICAÇÕES DE HISTÓRIAS ................................................................... 43
3.3.1 Efetuar Login .................................................................................................... 43
3.3.2 Manter Usuários ............................................................................................... 44
3.3.3 Manter Produtos ............................................................................................... 44
3.3.4 Manter Categorias ............................................................................................ 44
3.3.5 Manter Caixas .................................................................................................. 44
3.3.6 Emitir Relatórios ............................................................................................... 44
3.3.7 Manter tipos de acréscimos.............................................................................. 45
3.3.8 Manter Mesas................................................................................................... 45
3.3.9 Trocar Mesas ................................................................................................... 45
3.3.10 Manter Vendas ............................................................................................... 45
3.3.11 Manter Itens da Venda ................................................................................... 45
3.3.12 Manter Pagamento de Itens ........................................................................... 46
3.3.13 Manter Clientes .............................................................................................. 46
3.3.14 Manter Entregas ............................................................................................. 46
3.3.15 Abrir Caixa ...................................................................................................... 47
3.3.16 Suprir Caixa .................................................................................................... 47
3.3.17 Retirar do Caixa ............................................................................................. 47
3.3.18 Lançar em Caixa ............................................................................................ 47
3.3.19 Fechar Caixa .................................................................................................. 47
3.4 PROJETO DE BANCO DE DADOS .................................................................... 48
3.4.1 Modelo Lógico .................................................................................................. 49
3.4.2 Mapeamento para Modelo Relacional .............................................................. 50
3.5 DIAGRAMA DE CLASSE .................................................................................... 51
3.6 DIAGRAMA DE ATIVIDADE ............................................................................... 52
3.6.1 Manter Usuários ............................................................................................... 52
3.6.2 Login................................................................................................................. 53
3.6.3 Trocar Mesa ..................................................................................................... 53
3.6.4 Manter Produtos ............................................................................................... 54
3.6.6 Manter Caixas .................................................................................................. 55
3.6.7 Manter Acréscimos ........................................................................................... 55
3.6.8 Manter Mesas................................................................................................... 56
3.6.9 Manter Vendas ................................................................................................. 56
3.6.10 Manter Pagamentos ....................................................................................... 57
3.6.11 Manter Itens ................................................................................................... 58
3.6.12 Manter Cliente ................................................................................................ 58
3.6.13 Manter Entregas ............................................................................................. 59
3.6.14 Abrir Caixa ...................................................................................................... 59
3.6.15 Suprir Caixa .................................................................................................... 60
3.6.16 Retirar do Caixa ............................................................................................. 60
3.6.17 Lançar em Caixa ............................................................................................ 61
3.6.18 Fechar Caixa .................................................................................................. 62
3.7 MVC .................................................................................................................... 62
3.7.1 Manter Usuários ............................................................................................... 63
3.7.2 Manter Login .................................................................................................... 63
3.7.3 Trocar Mesa ..................................................................................................... 64
3.7.5 Manter Produtos ............................................................................................... 65
3.7.6 Manter Acréscimos ........................................................................................... 65
3.7.7 Manter Caixas .................................................................................................. 66
3.7.8 Manter Cliente .................................................................................................. 66
3.7.9 Manter Entrega ................................................................................................. 67
3.7.10 Manter Mesa .................................................................................................. 67
3.7.11 Manter Item .................................................................................................... 68
3.7.12 Manter Pagamento ......................................................................................... 68
3.7.13 Abrir Caixa ...................................................................................................... 69
3.7.14 Fechar Caixa .................................................................................................. 69
3.7.15 Retirar do Caixa ............................................................................................. 70
3.7.16 Suprir Caixa .................................................................................................... 70
3.7.17 Manter Lançamento ....................................................................................... 71
3.7.18 Manter Venda ................................................................................................. 71
3.8 DIAGRAMA DE SEQUÊNCIA ............................................................................. 72
3.8.1 Manter Usuário ................................................................................................. 72
3.8.2 Login................................................................................................................. 73
3.8.3 Manter Lançamento ......................................................................................... 73
3.8.4 Manter Caixas .................................................................................................. 74
3.8.5 Abrir Caixa........................................................................................................ 74
3.8.7 Fechar Caixa .................................................................................................... 75
3.8.8 Manter Entregas ............................................................................................... 76
3.8.9 Suprir Caixa ...................................................................................................... 76
3.8.10 Manter Cliente ................................................................................................ 77
3.8.11 Retirar do Caixa ............................................................................................. 77
3.8.12 Manter Mesa .................................................................................................. 78
3.8.13 Trocar Mesa ................................................................................................... 78
3.8.14 Manter Itens ................................................................................................... 79
3.8.15 Manter Pagamento ......................................................................................... 79
3.8.16 Manter Produtos ............................................................................................. 80
3.8.17 Manter Venda ................................................................................................. 80
3.8.18 Manter Acréscimos ......................................................................................... 81
4 PROTÓTIPO FUNCIONAL..................................................................................... 82
4.1 LOGIN ................................................................................................................. 82
4.2 CADASTROS ...................................................................................................... 83
4.3 MOVIMENTAÇÕES VIA NAVEGADOR WEB ..................................................... 85
4.4 MOVIMENTAÇÕES VIA DISPOSITIVO MÓVEL ................................................ 89
4.5 EMISSÃO DE RELATÓRIOS .............................................................................. 91
CONCLUSÃO............................................................................................................ 92
APÊNDICE A – Integração entre Android e Aplicação Web. .................................... 93
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................ 108
19
INTRODUÇÃO
A Tecnologia da Informação mostra-se indispensável para que um
estabelecimento comercial consiga alcançar ascensão no mercado, pois um sistema
de informação é capaz de aprimorar seus processos e métodos de gerenciamento,
promovendo uma maior eficiência na execução das atividades e consequentemente
colaborando para uma excelência operacional. (CABRAL, 2004)
O trabalho proposto tem como tema o desenvolvimento de um software que
auxilie no gerenciamento das operações de um bar ou restaurante. O sistema deve
oferecer ao usuário ferramentas práticas para que seja efetuada a gestão das
vendas, o controle do fluxo de caixa e o atendimento ágil e preciso aos pedidos dos
clientes.
O projeto será embasado em análises de negócios e levantamento de
requisitos, com o intuito de identificar as funcionalidades a serem aplicadas na
solução proposta, para que posteriormente o sistema seja implementado.
Sem o controle automatizado, um estabelecimento acaba por ter vários
prejuízos. A perda de informações importantes pode acarretar diretamente na perda
de lucro. A manipulação e controle das informações de forma manual dificulta a
integridade dos dados, pois falhas humanas ocorrem com frequência. O tempo
utilizado para realizar as tarefas é mais longo, deixando o atendimento ao cliente
mais lento e menos eficaz. As operações efetuadas no fluxo de caixa não são
confiáveis, podendo conter erros de cálculo, e não podem ser controladas através de
relatórios, que mostram com precisão os produtos mais vendidos, os produtos mais
lucrativos, o melhor período de venda, entre outros.
Todos esses problemas fazem com que o estabelecimento tenha menor
vantagem competitiva pela perda da otimização dos serviços e aumento
desacelerado de sua receita.
O trabalho tem como objetivo a implementação de um sistema capaz de
solucionar os problemas descritos. Separado por módulos, o projeto atenderá a
diversos estágios da atividade da empresa, fornecendo auxilio desde o cadastro de
produtos até a cobrança no caixa.
A proposta contém ainda o desenvolvimento de um aplicativo móvel
conectado ao sistema, a fim de permitir aos funcionários do estabelecimento a
20
anotação dos pedidos de forma prática e acessível. O projeto inclui também a
implementação de ferramentas que automatizem a cobrança das contas, visando a
organização e a praticidade ao efetuar dos pagamentos.
Com o constante crescimento do mercado de tablets e smartphones, foi
proposto o desenvolvimento de um aplicativo Android como complemento do
sistema, com o intuito de expandir a mobilidade dos dados. Optou-se pela área de
bares e restaurantes por existir um amplo mercado de atuação com um grande
número de estabelecimentos deste segmento que não são automatizados e
precisam de melhorias no setor tecnológico. Além disso, a integração do sistema
web com o aplicativo móvel mostra-se útil para este tipo de comércio.
Para que o produto planejado seja alcançado, foram definidas estratégias e
reunidos os métodos que devem compor o processo de trabalho. Inicialmente será
realizada uma analise de negócios, tomando como base estabelecimentos não
informatizados, e também outros software deste segmento. Em seguida propõe-se a
diagramação das funcionalidades identificadas e a definição da modelagem do
banco de dados. A etapa seguinte corresponde à implementação das funções de
manipulação dos dados, além do desenvolvimento da interface com o usuário. A
seguir o projeto prevê a execução dos testes de software e por fim a redação dos
relatórios finais e a apresentação da conclusão obtida com o trabalho.
No
capítulo
um
são
abordadas
as
tecnologias
utilizadas
para
o
desenvolvimento do trabalho, desde ferramentas aplicadas na modelagem dos
diagramas e do banco de dados, até a implementação do sistema web e aplicativo
Android.
O capitulo dois trata-se da análise de negócio. Nele são compreendidas as
especificações do projeto, onde são detalhados os processos e etapas necessárias
para a construção do software. A análise fornece ainda a descrição dos problemas
identificados através de uma análise de mercado, oferecendo uma visão geral do
produto a ser desenvolvido e suas principais características.
No capítulo três, é apresentada a arquitetura do software por meio dos
diagramas referentes ao projeto. Entre os diagramas estão o de classe, caso de uso,
atividades, MVC, sequência, bem como o projeto de banco de dados.
No capítulo quatro são apresentadas as telas do sistema web e do aplicativo
Android conforme a visão do usuário, exibindo parte suas funcionalidades.
21
1 FERRAMENTAS E TECNOLOGIAS
O capítulo a seguir apresenta resumidamente as ferramentas e tecnologias a
serem utilizadas para desenvolver o sistema. Esse levantamento tecnológico
engloba itens como linguagens de programação, frameworks e software de apoio ao
desenvolvimento.
A descrição tem como objetivo detalhar as funcionalidades aplicadas no
trabalho, com informações como o histórico, objetivos, ramificações (se houverem),
recursos disponíveis nas ferramentas e também a função desempenhada dentro do
projeto.
1.1 UML
A Unified Modeling Language (UML) é uma linguagem gráfica e textual usada
no desenvolvimento orientado a objetos (OO) para visualização, especificação,
construção e documentação de informações referentes a um software. (SPINOLA,
2010)
Segundo Spinola (2010), a UML formalizou um conjunto de conceitos
compostos por vários elementos, relacionamentos e tipos de diagrama, que permitiu
a unificação na representação de modelos na orientação a objeto.
Para Silva (2007), quando se fala em modelagem, muitos pensam na geração
de uma coleção de diagramas, mas o que não se pode perder de vista é que essa
produção de diagramas não é um fim, mas um meio para se chegar a um programa
que compila, executa, e cumpre os requisitos definidos para ele, sem entrar em
colapso.
Spinola (2010), diz que a linguagem foi criada em 1996, como o resultado da
integração dos métodos orientados a objetos propostos por Booch (1994),
Rumbaugh (1991) e Jacobson (1993), padronizando as notações utilizadas. Na
versão 1.1, foi aprovada como linguagem padrão para a modelagem orientada a
objetos pela Object Management Group (OMG) em 1997.
De acordo com Macêdo e Leal (2010), um diagrama é a representação gráfica
de um conjunto de elementos, ou seja, usam-se os diagramas para visualizar,
analisar e modelar o sistemas sob diferentes perspectivas, permitindo que cada
diagrama complete os demais.
22
O Diagrama de Atividades descreve os passos a serem percorridos para a
conclusão de uma atividade especifica. Ele é um gráfico que mostra o fluxo de
controle de uma atividade para outra. Ao contrário de um gráfico de fluxo tradicional,
um diagrama de atividades mostra a concorrência, bem como as ramificações de
controle. (MACÊDO e LEAL, 2010)
Macêdo e Leal (2010) definem o diagrama de caso de uso como sendo a
especificação de uma sequência completa de interações entre um sistema e um ou
mais agentes externos a esse sistema. O Diagrama de Caso de Uso é utilizado
normalmente nas fases de levantamento e análise de requisitos do sistema. Ele
apresenta uma linguagem simples para que o usuário possa compreender o
funcionamento do sistema. Este diagrama procura identificar atores (usuários, outros
sistemas etc.) que utilizaram o software, e os serviços que o sistema disponibilizará
para eles, conhecidos nesse diagrama como Caso de Uso.
O diagrama de sequência representa a ordem temporal em que as
mensagens são trocadas entre os objetos envolvidos em um determinado processo.
Ele é baseado no Caso de Uso definido pelo diagrama de mesmo nome e usa o
Diagrama de Classes para determinar quais objetos das classes envolvidas em um
processo. Ele identifica o evento gerador do processo modelado, e o ator
responsável pelo evento, e determina como o processo deve se desenrolar e ser
concluído por meio da chamada de métodos disparados por mensagens enviadas
entre objetos. (MACÊDO e LEAL, 2010)
O objetivo do Diagrama de Classe é permitir a visualização das classes que
serão implementadas no sistema, com seus respectivos atributos e métodos, e
também demonstrar como elas se relacionam e transmitem informações entre si. Ele
apresenta uma visão estática de como as classes estão organizadas e preocupa-se
em definir a estrutura lógica delas. Este diagrama ainda é usado para a construção
de outros diagramas, como por exemplo, o de Sequência. (SPINOLA, 2010)
A UML será utilizada no projeto para a confecção dos casos de uso,
diagramas de classe, sequencia e atividade, assim a descrição do sistema ficará
documentada
da
forma
correta,
desenvolvimento do software em si.
facilitando
possíveis
manutenções
e
o
23
1.2 ASTAH
O Astah é uma ferramenta Computer Aided Software Engeneering (CASE),
que auxilia no processo de desenvolvimento de um sistema, desde a identificação
de requisitos até a geração de diagramas, ele veio para substituir o Jude em 2010
como ferramenta da empresa Change Vision. (LEAL, MACÊDO e SPINOLA, 2010)
De acordo com Leal, Macêdo e Spinola (2010), o Astah possui suporte para
desenvolvimento dos seguintes diagramas da UML 2.x: Diagrama de Classes;
Diagrama de Casos de Uso; Diagrama de Sequência; Diagrama de Colaboração;
Diagrama de Estados; Diagrama de Atividades; Diagrama de componente; Diagrama
de Desenvolvimento; Diagrama de estrutura composta.
O Astah possui três licenças: Astah Professional, onde a licença é paga, e a
versão da ferramenta é mais robusta, suportando a criação de diagramas, mapas
mentais, diagrama de entidade e relacionamento (DER), gráfico de fluxo de dados,
algumas operações de banco de dados relacionais e diagrama e tabela de
requisitos; Astah UML, possui licença paga, que suporta a criação de diagramas e
mapas mentais; Astah Community, o único com uma licença livre ou acadêmica, que
suporta apenas o desenvolvimento de diagramas.(LEAL, MACÊDO e SPINOLA,
2010)
1.3 JAVA
De acordo com Lozano (2012), a plataforma Java é um dos ambientes de
aplicações mais utilizados na atualidade. Desde suas primeiras novidades como o
JavaBeans, JDBC, Applets, o Java foi adotado muito rapidamente e hoje é uma
referencia no mercado de desenvolvimento de software. Lançada pela Sun
Microsystems no inicio de 1995, a tecnologia Java revolucionou o desenvolvimento
de aplicações, introduzindo o conceito de independência de plataforma, apresentado
pela primeira Java Virtual Machine (JVM). Além disso, a tecnologia mostrou-se ideal
para a computação em rede, sendo fundamental para a evolução das aplicações
Web.
A linguagem Java é orientada a objetos e possui sintaxes semelhantes às das
linguagens C/C++, é considerada segura, pois não possui ponteiros de memória,
24
garantindo
o assim uma maior proteção contra programas que procuram acessar
ponteiros de memória indevidos. (DOEDERLEIN, 2012).
Segundo Lozano (2012), o índice Tiobe apresenta uma lista de linguagens de
programação classificadas de acordo com dados públicos da Internet,
Intern
como
pesquisas Google, Bing, Yahoo e Twitter, quantidades de livros e artigos publicados,
publicado
entre outras fontes. O gráfico 1.1 ilustra a variação da popularidade dessas
linguagens, apontando a liderança da linguagem Java nos últimos anos.
Gráfico 1.1 - Índice TIOBE
Fonte:
Com o constante crescimento do mercado de computação móvel, a
linguagem
Java
torna se
torna-se
essencial
devido
à
sua
portabilidade,
pois
é
constantemente aplicada no desenvolvimento para Android, sendo executada a
partir da Dalvik VM, a máquina virtual similar à JVM desenvolvida pelo Google.
(LOZANO, 2012)
1.3.1
.1 JavaServer Faces (JSF)
Um dos principais motivos que tornou a internet e, consequentemente, a
plataforma web, tão populares mundialmente, foi a facilidade da
d criação das páginas
estáticas, restritas a conteúdos textuais, acompanhados de imagens, links e
25
limitados recursos multimídia. Com pouco conhecimento em uma linguagem de
marcação, como o HyperText Markup Language (HTML), qualquer pessoa podia
divulgar seu site a um público em crescimento exponencial. No entanto, o
comportamento dos usuários passou a necessitar de experiências de navegação
cada vez mais interativas, versáteis e seguras, onde os simples sites foram
ganhando status de aplicações. Neste contexto, a Java Community Process (JCP)
envolveu-se em especificações para o desenvolvimento de páginas dinâmicas,
agora processadas no servidor e interpretadas pelo navegador cliente. Entre elas,
destacam-se a tecnologia JavaServer Pages (JSP) e a especificação para
frameworks
JavaServer
Faces
(JSF)
baseada
em
componentes
para
desenvolvimento web, úteis na construção das chamadas Graphical User Interfaces
(GUI). (GUIMARÃES, 2010).
Atualmente na versão 2.0, a tecnologia JSF foi lançada há pouco mais de seis
anos, e é adotada por inúmeras empresas do cenário atual. JavaServer Faces é um
framework orientado a componentes que abstrai o desenvolvimento de interfaces
com o usuário, controlando a geração de código HTML enviado para os
navegadores, permitindo ao desenvolvedor, implementar a camada de visão do
sistema web de forma simples, organizada, legível e gerenciável. Não é, portanto,
sua função cuidar de aspectos relacionados à lógica de negócio, persistência de
dados, serviços web, integração entre sistemas ou conexões com sistemas de
informação em geral, havendo outras tecnologias dedicadas exclusivamente a esses
propósitos. (BRIGATTO, 2010)
Para Brigatto (2012), encapsular comportamentos e características das
marcações HTML através de classes e interfaces pré-compiladas, torna menos
penosa a construção das páginas web e possibilita que o desenvolvedor concentre a
maior parte de seus esforços na lógica de negócio.
As principais vantagens de utilizar esse framework ao desenvolver uma
aplicação web são a aceleração da produção e a padronização do código final, pois
a geração do HTML será de responsabilidade do framework, que utiliza de técnicas
e algoritmos que seguem padrões pré-definidos. Isso elimina grande parte das
falhas estruturais que ocorrem com maior frequência no processo manual.
(PAGANINI, 2012)
Segundo Brigatto (2012), a escrita em JSF depende de todo o ciclo de vida da
requisição, composto de várias fases, diferentemente do JavaServer Pages, que a
26
escrita é feita imediatamente na resposta gerada à medida que a página é
processada. Uma das vantagens desse framework é a estabilidade, ou seja, a
compatibilidade com versões anteriores é garantida. Além disso, o JSF possui
suporte de ferramentas e fornecedores de servidores de aplicações, sendo
suportado pelas principais IDEs e servidores.
1.3.2 PrimeFaces
O PrimeFaces é considerado uma das implementações mais populares do
JavaServer Faces. O framework possibilita programar valendo-se de uma vasta
biblioteca de componentes de interface de usuário providos de acessibilidade digital,
tanto para ambiente web como para dispositivos móveis. Desde o seu lançamento
em 2009, são desenvolvidos componentes e recursos interativos através dos
pacotes PrimeUI e PrimeMobile. (DANTAS, 2010).
De acordo com Dantas (2010), o site oficial do PrimeFaces oferece suporte
para a codificação dos componentes dentro das melhores práticas de programação.
Disponibiliza, associados a uma documentação gratuita, um blog e um fórum
mantidos pela comunidade, que é ativa e comprometida com o projeto. Este texto
auxilia o desenvolvedor Java a se iniciar com o framework, por meio de exemplos
que demonstram suas funcionalidades.
Segundo Dantas (2010), conhecer as vantagens e as funcionalidades do
framework PrimeFaces é de grande conveniência aos desenvolvedores que desejam
implementar aplicações web com mais agilidade, rapidez e maior produtividade.
Cada nova versão do PrimeFaces é desenvolvida pela empresa turca Prime
Teknoloji. Além da correção de erros, novos componentes vão sendo acrescentados
em sua biblioteca, com a filosofia de apresentarem codificações leves e livres de
dependências, baseadas em um único arquivo binário compactado do tipo Java
Arquive (JAR). Seu uso estendeu-se além do desenvolvimento de interfaces web
como, também, rumo às interfaces de utilitários em dispositivos móveis de diferentes
plataformas. O PrimeFaces oferece suporte, ainda, ao Ajax Push, que dá liberdade
ao servidor para enviar respostas sem haver solicitações vindas do cliente, evitando
a necessidade de recarregar a página para que as informações da tela sejam
atualizadas.
27
“O Guia do Usuário do PrimeFaces relaciona uma documentação com
informações, atributos, melhores práticas e demonstrações para os mais de cem
integrantes do seu conjunto de componentes. Eles estão de acordo com a
arquitetura Modelo-Visão-Controle (MVC) que controla o fluxo do aplicativo na
especificação JSF. Isolando o código Java da camada de apresentação, os
componentes PrimeFaces são pré-codificados, funcionando como abstrações
responsáveis por unir os códigos HTML, CSS e JavaScript que tratam os seus
comportamentos. Exemplos práticos estão expostos no mostruário online, dispondo,
em seções, os elementos de entrada de dados e de saída de informações, botões,
painéis, menus, gráficos, diálogos, juntamente com todos os recursos, efeitos e
interações do framework, além das respectivas implementações em código aberto.”
(GUIMARÃES, 2010)
A galeria de temas prontos para download permite a alteração de vários
aspectos de um componente, tais como as definições da fonte aplicada nos textos,
as cores dos elementos constituintes, afora outros efeitos visuais e interativos.
Essas opções do PrimeFaces, tanto em número de componentes, como em
personalização dos mesmos, partindo dos elementos de interface mais simples aos
mais elaborados, garantem a criação de interfaces ricas para as mais diversas
pretensões gráficas e funcionais. (GUIMARÃES, 2010)
1.3.3 Netbeans IDE
Segundo Doederlein (2008), o Netbeans é um Ambiente de Desenvolvimento
Integrado, do inglês Integrated Development Environment (IDE), de código aberto
originado na universidade de Charles, em Praga, no ano de 1996, a partir da ideia
de dois estudantes tchecos. A ferramenta foi criada com o intuito de auxiliar
desenvolvedores na produção de software de forma simples e dinâmica.
O IDE fornece uma interface gráfica que colabora com a criação de
programas desktop, web ou móveis, não se limitando apenas ao desenvolvimento
Java. Possui também recursos para a implementação de aplicações em outras
linguagens, como C, C++, PHP, Groovy e Ruby, podendo ser executado a partir de
diversas plataformas, entre elas Windows, Linux, Solaris e Mac OS. (DOEDERLEIN,
2012)
28
“O domínio de uma linguagem de programação pode não ser suficiente para
que um desenvolvedor desempenhe com eficiência o seu trabalho. Considera-se tão
importante quanto o conhecimento da linguagem, a habilidade em um Ambiente
Integrado de Desenvolvimento (IDE)”. (ARAUJO, 2012)
De
acordo
com
Araujo
(2012),
a
utilização
de
um
ambiente
de
desenvolvimento é fundamental para um projeto de implementação de software, pois
contribui para o aumento da produtividade, poupando o programador de grande
parte do trabalho manual.
Segundo Araujo (2012), o Netbeans IDE proporciona ao desenvolvedor auxilio
para escrever, compilar, depurar e instalar aplicações, e também fornece aos
usuários um conjunto de bibliotecas pré-instaladas, entre elas o JSF, Struts e
Hibernate.
1.3.4 Eclipse
O Eclipse é uma plataforma gratuita usada para o desenvolvimento de
aplicações, criado originalmente pela IBM em 2001. Foi criada a Fundação Eclipse,
em janeiro de 2004, uma organização sem fins lucrativos que permitiu o surgimento
de uma comunidade transparente e aberta. Essa Fundação é mantida por seus
associados, que hospedam os projetos do Eclipse e ajudam a manter uma
comunidade de software livre. (GIRELLI e ARAÚJO, 2012)
Apesar de a plataforma Eclipse ser desenvolvida em Java, o uso da IDE não
se limita apenas ao desenvolvimento de aplicações escritas nesta linguagem.
Existem plugins de suporte a várias outras linguagens como, C/C++, Cobol e PHP,
entre outras. (GIRELLI e ARAÚJO, 2012)
No final de Junho de 2012, a Fundação Eclipse lançou sua nona distribuição,
que recebe o codinome Juno. A nova plataforma já está disponível na versão 4.2.
Nesta nova plataforma, novos recursos foram adicionados e os existentes foram
melhorados,
tendo
como
objetivo
simplificar
e
facilitar
o
processo
de
desenvolvimento de aplicações que tem como ferramenta a plataforma Eclipse.
(BLEWITT, 2012)
Segundo Blewitt (2012), o Eclipse Juno vem sendo desenvolvido há mais de
três anos, e caracteriza o primeiro lançamento da plataforma Eclipse 4.x. A nova
versão da IDE inclui 72 projetos.
29
Para Girelli e Araújo (2012), o Eclipse é uma das plataformas de
desenvolvimento mais utilizadas e por isso, está sempre em crescimento, visando
oferecer aos seus usuários uma plataforma estável e que facilite o processo de
desenvolvimento de aplicações.
1.3.5 JDBC
Para acessar um banco de dados, uma aplicação Java necessita, além da
própria máquina virtual, de um driver Java Database Connectivity (JDBC). Esse
driver geralmente é fornecido pelo órgão responsável pelo banco de dados sem
nenhum custo adicional. O JDBC também não precisa de nenhuma configuração
prévia, e não há necessidade de editar nenhum arquivo de configuração nem
executar algum painel de controle administrativo. Drivers JDBC são na grande
maioria simples bibliotecas Java, arquivo JAR, que podem ser copiados para
qualquer sistema operacional. (LOZANO, 2011)
Segundo Lozano (2011) por meio do JDBC, uma aplicação Java pode se
conectar a qualquer banco relacional e assim submeter comandos SQL para
execução e recuperação dos resultados gerados pelo comando. Além disso, o JDBC
permite acesso aos metadados do banco de dados, permitindo a construção de
ferramentas para a administração do próprio banco e apoiando o desenvolvimento
de sistemas.
1.4 SQL
Segundo Gonçalves (2011), Structured Query Language (SQL) é a linguagem
padrão ANSI para a manipulação de bancos de dados relacionais. Por ser um
padrão aceito pela indústria, é suportada por todos os SGBD's relacionais, o que
inclui produtos como Oracle, Microsoft SQL Server, MySQL, PostgreSQL, SQLite e
IBM DB2. O escopo da SQL é oferecer instruções para manipulação de dados,
definição de objetos, gerenciamento de transações e controle de acessos.
1.4.1 PostgreSQL
De Acordo com Smanioto (2007), o Sistema Gerenciador de Bancos de
Dados (SGBD) PostgreSQL começou a ser desenvolvido em 1986, na universidade
30
de Berkeley, na Califórnia. Seu código-fonte tomou por base a codificação do banco
de dados INGRES, de onde surgiu o nome Postgres (uma abreviação do inglês para
pós-INGRES). O projeto liderado pelo Professor Michael Stonebraker foi
financiado pela Agência de Pesquisa de Projetos Avançados de Defesa dos EUA
(DARPA), pelo Departamento de Pesquisa do Exército Americano (ARO), pela
Fundação Nacional de Ciência (NSF) e pela ESL, Inc.
Em 1994, o código-fonte do Postgres, foi publicado na internet. No ano
seguinte, o SGBD ganhou suporte à linguagem SQL, motivo pelo qual em 1996 o
Postgres passou a chamar-se PostgreSQL. (SMANIOTO, 2010)
Segundo Stern (2010), o PostgreSQL é um SGBD de código aberto que utiliza
a licença BSD, dando aos seus usuários total liberdade para alterar seu código-fonte,
além de isenção para comercializar o produto.
De acordo com Stern (2010), o gerenciador Postgre tem como principais
características o suporte aos padrões ANSI SQL 89, 92 e 99, a integridade
referencial, o suporte a funções e stored procedures definidas pelo usuário, o
suporte a diversas linguagens de desenvolvimento como PHP, Java, C, ASP, .Net,
Perl, entre outras e a linguagem de programação de funções PLpgSQL.
Podendo ser instalado nas plataformas Linux, FreeBSD, Solaris, OpenBSD,
Windows, entre várias outras, o banco de dados pode ser acessado pela rede
através do protocolo TCP/IP. Por padrão as conexões são feitas pela porta 5432,
podendo ser alterada pelo administrador do sistema. Para se conectar ao
PostgreSQL, uma aplicação cliente necessita apenas do IP ou nome DNS do
servidor, da porta TCP/IP, usuário e senha para acesso e o nome da base de dados.
(STERN, 2010)
1.4.2 Plpg/SQL
De acordo com Gonçalves (2012), PLpg/SQL pode ser entendida como uma
extensão da linguagem SQL, acrescentada de funcionalidades que a tornam uma
linguagem de programação completa, oferecendo recursos para o controle de fluxo,
tratamento de exceções, orientação a objetos, possibilitando assim a escritura de
programas que são armazenados, compilados e executados dentro do servidor do
SGBD PostgreSQL, utilizando instruções SQL.
31
Segundo Oliveira (2009) a PLpg/SQL é semelhante à linguagem PL/SQL, do
Oracle, que foi criada anteriormente, com o propósito de oferecer uma solução de
programação para os usuários que precisavam escrever trechos de código para
tratamento de exceções no banco de dados e também definir regras e condições ao
manipular registros.
Segundo Gonçalves (2012), o conceito de linguagem procedural extendida da
SQL foi introduzido no ano de 1998 como parte das funcionalidades que
compunham a versão 6.0 do Sistema Gerenciador de Bancos de Dados(SGBD)
Oracle. A PLpg/SQL é normalmente utilizada para a criação de funções ou
procedimentos críticos, requerendo alto desempenho ao processar as tarefas, além
disso, é significativamente mais confiável do que a maioria das outras linguagens de
programação.
Outra vantagem dos programas PLpg/SQL é sua durabilidade, não
necessitando de manutenção quando a versão do PostgreSQL é atualizada. Isso
deve-se ao fato das versões da linguagem serem compatíveis. (GONÇALVES, 2012)
1.5 XML
A
linguagem
recomendada
para
de
a
marcação
criação
de
eXtensible
Markup
documentos
com
Language
dados
(XML)
é
organizados
hierarquicamente, como textos ou banco de dados. A linguagem XML é classificada
como extensível porque permite definir elementos de marcação. (PEREIRA, 2009)
Cada dia é mais comum o uso do XML para armazenamento ou transporte
dos dados entre aplicações. O arquivo XML tem estrutura similar a de arquivos
HTML, pois ambos são organizados em tags de marcação, a diferença é que no
XML você pode criar as suas próprias tags, construindo arquivos para armazenar a
sua estrutura de dados específica. (SENDIN, 2010)
O XML traz uma sintaxe que pode ser utilizada para compartilhar informações
entre diferentes computadores e aplicações. Quando combinado com outros
padrões, torna possível definir o conteúdo de um documento separadamente de seu
formato, deixando assim que se reutilize o código em outras aplicações para
diferentes propósitos. Por exemplo, um banco de dados pode escrever um arquivo
XML para que outro banco consiga lê-lo. Portanto uma das suas principais
características é a portabilidade. (PEREIRA, 2009)
32
Para Pereira (2009), alguns dos propósitos do XML são: auxiliar sistemas de
informação no compartilhamento de dados, especialmente via internet e codificar
documentos.
Segundo Sendin (2010), O XML é um padrão amplamente utilizado por
aplicações Web, e recomendado pelo World Wide Web Consortium (W3C). Iniciado
por volta de 1990 o projeto que deu origem ao XML, surgiu da insatisfação quanto à
falta de padronização dos formatos existentes até então.
Surgiu então o formato XML, que combina a flexibilidade da Standard
Generalized Markup Language (SGML), ou Linguagem Padronizada de Marcação
Genérica com a simplicidade do HTML. (SENDIN, 2010)
1.6 ANDROID
O Android é um sistema operacional criado exclusivamente para os celulares
de maior capacidade, conhecidos como handsets ou smartphones, sendo pensado
desde o principio em facilitar o desenvolvimento de aplicações. (FERRARINI, 2012).
Lançado em estágio beta no final de 2007, o Android estreou sem muito
alvoroço, devido ao baixo nível de maturidade do produto naquele momento. A API
contida no SDK, do inglês Software Development Kit, estava incompleta, o sistema
estava ainda em fase de testes pelos engenheiros da Google e nenhum aparelho
rodando Android estava disponível para uso. (FERRARINI, 2012)
A empresa HTC foi a primeira a lançar um aparelho com Android, em outubro
de 2008, o inicio das vendas do modelo G1 foi um marco importante para o projeto.
Desde então o Android vem evoluindo consideravelmente, sendo considerada uma
das plataformas mais inovadoras entre os sistemas operacionais móveis atualmente
disponíveis. (FERRARINI, 2012)
Segundo Lecheta (2010), para o usuário final o Android tem o objetivo de ser
um sistema extremamente personalizável e, acima de tudo, tirar proveito da Internet
e dos serviços em Nuvem. Para o desenvolvedor de software, permite a criação
rápida e simples de aplicações, incorporando no seu framework diversas
ferramentas que auxiliam o processo de codificação e preparação de software para
o mercado, como por exemplo, o uso do XML para a concepção de interfaces
gráficas, recursos avançados de internacionalização e distribuição de aplicativos
pelo Google Play sem processos burocráticos de aprovação.
33
Sempre evoluindo, a equipe de desenvolvedores do Android geralmente
incorpora novos padrões e tecnologias a cada nova atualização. As versões mais
recentes possuem inúmeras APIs e componentes de comunicação com diferentes
funcionalidades, como por exemplo, o WIFI-Direct, para conexão direta entre
dispositivos sem a necessidade de um Access Point, o Cloud To Device Messaging,
para o envio de mensagens da Nuvem diretamente para aplicações Android. Essas
tecnologias estão totalmente disponíveis para desenvolvedores e criam um leque de
possibilidades muito interessante para uso em suas aplicações. (FERRARINI, 2012)
Segundo Lecheta (2010) o Android permite desenvolver e integrar aplicações
de forma simplificada utilizando a linguagem de programação Java e utilizar um
ambiente de desenvolvimento de alto nível e produtividade como o Eclipse.
34
2 ANÁLISE DE NEGÓCIO
A análise de negócios compreende as especificações que o projeto precisa
atingir para que seja comprovada sua utilidade, bem como entender todos os
processos e etapas a serem realizadas para a construção do software e do
aplicativo móvel. A análise fornece uma descrição detalhada sobre o problema,
análise de mercado, atores envolvidos em seus respectivos processos e descrição
do ambiente. O capítulo oferece também, uma visão geral do produto, assim como
suas principais características.
2.1. INSTRUÇÃO DO PROBLEMA
Bares, restaurantes, lanchonetes, pizzarias e qualquer outro estabelecimento
que comercialize alimentos têm uma elevada quantidade de clientes. O fluxo de
informações nesses ambientes é alto, e a empresa visa sempre aumentar seu
número de clientes, oferecendo um atendimento ágil e de qualidade. Com essa
demanda alta por um processo operacional que seja cada vez mais rápido e
eficiente, o estabelecimento acaba por ter alguns problemas caso não faça o
gerenciamento das informações de forma adequada.
O maior problema encontrado por esses estabelecimentos é a perda de
informações importantes, pois os papéis utilizados para anotações podem se perder
facilmente, sendo um contratempo manter tantos documentos organizados, tornando
difícil a recuperação dessas informações.
As operações realizadas no caixa, ao efetuar a cobrança da conta, se feitas
de forma manual, podem conter erros de cálculo, gerando prejuízo para o
estabelecimento ou para o cliente, e o tempo desperdiçado com essa tarefa pode
ser demorado, causando filas no caixa.
Esse projeto busca facilitar o gerenciamento operacional do estabelecimento,
evitando inconsistências nos pedidos e nas operações efetuadas pelos atendentes,
e acelerando processos como o pagamento da conta, ganhando assim praticidade
para atender melhor os clientes.
35
2.2 ANÁLISE DE MERCADO
A velocidade em que mudanças ocorrem no cenário econômico atual, está a
exigir sempre produtos rápidos e eficazes para controlar a gestão das empresas e
fundamentar decisões. Esse controle é essencial para que o administrador
mantenha sua empresa competitiva.
Segundo Zanella (2001), “administrar custos não é apenas eliminar despesas,
é acima de tudo gerir seus recursos de forma competente e racional, através de
instrumentos adequados e eficientes.” o que acaba não acontecendo com empresas
de micro e pequeno porte, que não têm muito capital para investir na área
tecnológica. Por esse motivo, essas empresas foram escolhidas como cliente alvo,
pois suas principais necessidades podem ser supridas com o projeto proposto.
A automação do gerenciamento e atendimento em estabelecimentos
alimentícios não é novidade, mas o crescimento do mercado a tornou indispensável
para quem pensa em prosperar nesse setor. (CAPOBIANCO, 2010). Maricato
(2001), diz que “a velocidade de crescimento é particularmente assustadora nas
áreas de informática e da tecnologia. Os equipamentos se tornam obsoletos com
dois ou três anos de uso. Qualquer empresário que quiser espaço no futuro tem de
equipar e informatizar sua empresa”.
Porém com sistemas cada vez maiores, mais complexos e mais caros, muitas
empresas não conseguem acompanhar esse desenvolvimento acelerado da
tecnologia. Por isso, o produto proposto atinge um publico que quer simplicidade e
eficiência, sem fazer um investimento muito grande, trazendo apenas os módulos
onde a empresa mais necessita de um controle preciso e rápido.
2.3 ATORES ENVOLVIDOS
Um ator é todo o indivíduo que desempenha alguma função dentro do modelo
de negócios da empresa. A identificação de suas atividades é essencial para o
projeto de desenvolvimento de um software, compondo assim um mapeamento do
processo de trabalho. Este tópico tem como objetivo, apresentar os atores
envolvidos no modelo de negócios de um restaurante, detalhando resumidamente
suas responsabilidades dentro do estabelecimento.
36
2.3.1 Gerente
O gerente do estabelecimento é o responsável por controlar o fluxo das
tarefas atribuídas no setor operacional, além de supervisionar o andamento das
atividades realizadas.
Uma das funções específicas desse profissional é manter as informações
referentes aos produtos oferecidos pelo estabelecimento, listando as características
relevantes de cada item. É fundamental que haja a constante manutenção e
atualização da tabela de preços dos produtos comercializados pela empresa.
O gerente também é responsável pela gestão da equipe, instruindo os demais
funcionários e atribuindo tarefas, a fim de garantir a sincronia entre a execução do
trabalho, podendo definir regras de bônus ou compensações para os funcionários
mais efetivos. Esse ator também administra as regras de cobrança, condições de
pagamento e demais normas aplicadas no processo de vendas. Ele define em quais
situações serão oferecidos descontos ou somados acréscimos ao valor da conta.
Outra função do gerente é determinar se existem promoções na aquisição de
algum serviço ou produto oferecido pelo estabelecimento, e caso existam,
especificam-se as condições da promoção, tais como período de vigência e valor ou
percentual descontado no valor líquido.
Fica a cargo do gerente do estabelecimento, supervisionar o fluxo de
operações no caixa. Para isso é necessário determinar quais são os funcionários da
empresa com permissão de acesso ao caixa. Os valores de abertura e fechamento
de caixa são registrados e documentados a fim de contabilizar o total recebido no
dia, semana ou mês. Esse total é calculado, somando os valores em dinheiro,
cheque e notas de cartão de crédito armazenadas no caixa.
2.3.2 Atendente
O atendente é responsável pela anotação dos pedidos feitos, permanecendo
sempre à vista dos clientes para atendê-los. Ao atender uma mesa, o atendente
inicia uma nova venda e registra todos os itens consumidos pela mesa em uma
comanda. Após o registro dos itens, o ator notifica a cozinha a respeito do que foi
solicitado.
37
Fica a cargo do atendente, registrar e notificar o cancelamento de algum item
que compõe a venda, a pedido do cliente. Caso os integrantes da mesa desejem
trocar de mesa, esse funcionário é responsável por efetuar a troca e também
registrá-la.
2.3.3 Cozinha
Os funcionários que fazem parte da cozinha são os responsáveis por
providenciar os produtos que foram registrados pelo atendente e posteriormente
entregá-los à mesa correspondente.
2.3.4 Caixa
O caixa é o responsável pelo gerenciamento e segurança dos valores
recebidos pela empresa.
O funcionário encarregado de manipular o caixa do estabelecimento tem
como função efetuar a cobrança das comandas preenchidas pelo atendente. Ele
pode dividir a conta entre os diversos integrantes da mesa, recebendo os
pagamentos referentes a cada parte individualmente.
O caixa pode registrar o pagamento parcial de uma conta, caso um dos
integrantes da mesa solicite a dedução do valor de sua parte antes do fechamento
da mesa. Além disso, esse funcionário pode incluir acréscimos ou descontos
determinados pelo gerente, ao valor total da comanda.
Ao fim da cobrança o caixa encerra o atendimento à mesa, arquivando a
comanda com a identificação de que já foi paga. Caso o cliente solicite, é preenchida
uma nota que detalha os itens consumidos juntamente com seus valores unitários e
o valor total da nota.
É responsabilidade desse colaborador, gerenciar a abertura e o fechamento
do caixa, mantendo registros dos valores em dinheiro, cheque e cartão. Além disso,
são realizados e registrados os suprimentos e retiradas do caixa.
O funcionário encarregado do caixa é quem faz o atendimento via telefone,
anotando os pedidos e encaminhando para a cozinha, em processo semelhante ao
do atendente. Ao registrar a entrega, o caixa mantém as informações relevantes do
38
cliente, como por exemplo, o nome e o endereço que devem ser direcionados aos
entregadores.
2.4 DESCRIÇÕES DO AMBIENTE ATUAL
Considerando que o sistema atual de administração da empresa utiliza de
planilhas e comandas preenchidas manualmente, o projeto propõe uma solução
tecnológica para estabelecimentos com até cinquenta colaboradores, com três a dez
atendentes, e até cinco caixas.
O espaço físico de um bar ou restaurante pode ser composto por vários
ambientes para a escolha do cliente. Essa condição requer que funcionários
responsáveis pelo atendimento, fiquem próximos das mesas o tempo todo. Os
clientes fazem suas escolhas através do cardápio que fica na mesa, contendo os
produtos e seus respectivos preços.
Após anotar um pedido, o atendente desloca-se fisicamente até o balcão ou
depósito, para providenciar a entrega do produto à mesa correspondente.
Para efetuar o pagamento da conta, o cliente dirige-se até o balcão do caixa e
comunica a forma de pagamento de sua escolha. O funcionário responsável pelo
caixa calcula o total a ser cobrado, e após armazenar os valores no caixa, mantém o
registro em um caderno ou ficha cadastral.
Por fim, caso o cliente solicite, o caixa preenche um recibo, com o
detalhamento do consumo.
2.5 PERSPECTIVAS DO PRODUTO
O desenvolvimento do produto é uma proposta de solução de qualidade para
uma área com amplo mercado. A área de comercio de alimentos em geral precisa
de um software de apoio, porém não necessariamente um sistema robusto ou um
ERP. O produto tem como clientes alvos as micro e pequenas empresas, portanto é
importante que a solução leve em conta o baixo investimento em insfraestrutura e
licenças de software, motivando por exemplo, a escolha do PostgreSQL como
SGBD, por ser um software gratuito.
39
2.6 CARACTERISTICAS
A partir da análise de negócios do público alvo do produto, são apresentados
nesse tópico os requisitos identificados durante o estudo de caso. Agrupadas por
prioridade, as funcionalidades listadas têm como objetivo sanar os problemas do
estabelecimento, visando sempre a excelência operacional e a praticidade no
gerenciamento.
2.6.1 Alta Prioridade
Identifica-se como maior prioridade, a informatização dos processos que
representam o eixo dos problemas do cliente. Considerando como principais
adversidades o tempo gasto e o risco de falhas humanas no procedimento atual, a
automatização dos métodos de venda e de fluxo de caixa é prioritária.
Visto que o atendimento ao cliente e o controle de itens consumidos pela
mesa são as principais atividades desempenhadas em um estabelecimento que
comercializa alimentos, é fundamental que esse trabalho seja feito de forma prática
e eficiente. Além disso, o gerente necessita de relatórios de vendas para embasarse ao tomar decisões, podendo, por exemplo, considerar a demanda dos produtos
ao atribuir preços.
Ao automatizar seus processos a partir de um software, além de agilizar seus
métodos, a empresa almeja possuir recursos para administrar suas finanças. É
considerado de alta prioridade o desenvolvimento de uma solução confiável para o
controle de entrada e saída de capital, de forma que a cobrança das contas esteja
sempre correta. O administrador da empresa precisa de relatórios gerais, anuais,
mensais e diários para analisar e gerenciar o setor financeiro, levando em conta as
movimentações do caixa.
2.6.2 Média Prioridade
São considerados de prioridade média, os requisitos importantes para o
modelo de negócios da empresa, mas não correspondem a problemas críticos do
processo de trabalho. Dentre esses requisitos estão a opção de registro de entregas
e a manutenção dos produtos e seus preços.
40
As entregas sem registros, ou com controle manual, estão sujeitas a perdas, o
que causa uma insatisfação do cliente que fez o pedido. A automatização desse
processo garante ao estabelecimento uma considerável diminuição nesse tipo de
falha, e consequentemente o numero de clientes insatisfeitos.
A informatização dos cadastros de produtos e preços torna prática a
atualização desses dados, que é feita com frequência pelo gerente.
2.6.3 Baixa Prioridade
Alguns itens são identificados como prioridades baixas em relação ao projeto.
São funcionalidades úteis que tornam o sistema robusto, porém não são
fundamentais para a conclusão do sistema como um todo. Entre essas
funcionalidades destacam-se a manutenção automatizada de promoções e a
emissão de recibos impressos pelo caixa.
Restaurantes não informatizados não registram promoções formalmente,
portanto não há um controle preciso para descontar o valor cobrado das vendas.
A emissão de recibos é feita apenas quando o cliente solicita, através do
preenchimento manual de notas, ocupando tempo do funcionário. Nos casos em que
há fila de clientes para efetuar pagamentos, o caixa pode apressar-se para
preencher o recibo, aumentando o risco de erros. A impressão automática de notas
para o cliente torna o processo mais ágil e confiável.
2.7 OUTROS REQUISITOS
Nesse tópico são descritos os itens que o cliente solicita para facilitar a
implantação e o uso do sistema, mas que não fazem parte das regras de negócio.
É preferível que o sistema seja web, pois o cliente almeja portabilidade para
acessá-lo de qualquer lugar, necessitando apenas de um dispositivo que esteja
conectado à internet. Gastos com hardware também são diminuídos, pois as
máquinas não precisam de nenhuma configuração avançada para a sua utilização,
apenas um navegador. As informações não ficam presas a um computador local,
evitando assim possíveis perdas de informações devido a falhas ou formatação de
disco.
41
Além disso, é requisitado um sistema com a interface amigável e intuitiva, que
facilite a sua utilização para qualquer um dos funcionários, simplificando o
treinamento, e não necessitando de profissionais especializados para a utilização do
sistema.
42
3 ARQUITETURA DO SOFTWARE
No capítulo é oferecida uma visão do produto através de diagramas que
descrevem as características e funcionalidades do sistema. O desenvolvimento da
arquitetura baseia-se na Unified Modeling Language (UML), e tem como intuito
auxiliar as futuras manutenções no software.
A ferramenta Astah é utilizada para produzir os diagramas de caso de uso,
classe, sequência, MVC e atividade, enquanto o Data Modeler produz o projeto de
banco de dados.
3.1 ANÁLISE DE REQUISITOS FUNCIONAIS
A análise de requisitos funcionais tem como objetivo listar as funcionalidades
identificadas pelo cliente durante a fase de análise de negócios. Para cada ator do
sistema, são mapeados os recursos que o software deve oferecer, para que se
alcance a solução tecnológica desejada pela empresa. (HUZITA, 2003)
3.1.1 Atendente
Manter a venda e gerenciar pedidos
3.1.2 Gerente
Manter os usuários
Manter os produtos e seus preços
Manter caixas e seus responsáveis
Emitir relatórios de produtos, vendas e fluxo de caixa
3.1.3 Caixa
Gerenciar o fluxo de caixa
Manter a venda e gerenciar pedidos
Manter clientes
Manter entregas
Emitir recibos
43
3.2 DIAGRAMA DE CASO DE USO
Figura 3.1 – Diagrama de Caso de Uso
Fonte: Elaborado pelos autores, 2013.
3.3 ESPECIFICAÇÕES DE HISTÓRIAS
Neste tópico são descritas as histórias de cada caso de uso, informando
passo a passo como os processos serão realizados no sistema, bem como o ator
responsável por cada função.
3.3.1 Efetuar Login
Ator: Gerente, Caixa e Garçom.
Pré- requisito: Ser cadastrado como usuário do sistema.
Descrição: Ao iniciar uma sessão do sistema, deve ser exibida a tela de
autenticação de usuários, que contem o número identificador de usuário e a senha.
Após a confirmação do login, a aplicação é redirecionada para a página principal do
sistema.
44
3.3.2 Manter Usuários
Ator: Gerente.
Descrição: A manutenção de usuários possibilitará a inclusão de novos logins,
além de alteração de senha e a opção de ativar/desativar usuários.
3.3.3 Manter Produtos
Ator: Gerente.
Pré-requisito: Existir a categoria do produto cadastrada.
Descrição: Cadastrar ou alterar informações sobre produtos. Caso o produto
saia de comercialização o usuário poderá alterar seu status para inativo, visto que a
exclusão não será permitida.
3.3.4 Manter Categorias
Ator: Gerente.
Descrição: As categorias dos produtos podem ser cadastradas e alteradas
pelo usuário. Caso alguma categoria deixe de ser utilizada, seu status pode ser
alterado para inativo. A categoria pode ser associada a uma categoria-pai, formando
assim uma árvore de categorias.
3.3.5 Manter Caixas
Ator: Gerente.
Descrição: Essa funcionalidade tem o intuito de permitir o cadastro dos caixas
do estabelecimento. Nela há a opção de incluir usuários habilitados a manipular
cada caixa.
3.3.6 Emitir Relatórios
Ator: Gerente.
Descrição: O gerente pode emitir relatórios variados. Entre eles os relatórios
de vendas semanais, mensais e anuais. Relatórios de produtos oferecidos pelo
estabelecimento. Relatórios semanais, mensais e anuais do fluxo de caixas.
45
3.3.7 Manter tipos de acréscimos
Ator: Gerente.
Descrição: O gerente pode realizar o cadastro, alteração ou exclusão de tipos
acréscimos. A exclusão só pode ser feita se o acréscimo não foi utilizado em
nenhuma venda.
3.3.8 Manter Mesas
Ator: Gerente.
Descrição: O gerente pode cadastrar, alterar ou desativar as mesas do
estabelecimento.
3.3.9 Trocar Mesas
Ator: Atendente.
Pré-requisito: Selecionar uma mesa aberta como origem, e selecionar uma
mesa qualquer como destino.
Descrição: Caso algum cliente troque de mesa no restaurante, o atendente
pode realizar uma troca via aplicativo Android, passando todos os produtos da
mesa de origem para a mesa de destino.
3.3.10 Manter Vendas
Ator: Caixa e Atendente.
Descrição: O software deve oferecer ao cliente o gerenciamento das vendas
ocorridas no restaurante, permitindo o registro de abertura e fechamento das mesas.
A opção poderá ser acessada via navegador web pelo gerente ou aplicativo móvel
pelo garçom.
3.3.11 Manter Itens da Venda
Ator: Caixa e Atendente.
Pré-requisito: Ter uma venda ou entrega aberta.
46
Descrição: A funcionalidade deve permitir que o usuário selecione uma venda
ou entrega que esteja aberta, e inclua os itens que a compõem. Cada item pode ser
composto por produtos ou acréscimos. A opção poderá ser acessada via navegador
web ou aplicativo móvel.
3.3.12 Manter Pagamento de Itens
Ator: Caixa.
Pré-requisito: Ter um caixa aberto.
Descrição: O funcionário responsável pelo caixa do estabelecimento deve
poder selecionar um ou vários itens de uma venda, e efetuar o pagamento. Para
registrar o pagamento, o usuário deve informar o valor pago, a forma de pagamento
e o caixa em que o valor será depositado. Cada item da venda pode ser pago com
diferentes formas de pagamento. Após a confirmação, o sistema deve lançar o valor
no caixa selecionado.
3.3.13 Manter Clientes
Ator: Caixa.
Descrição: O usuário pode cadastrar dados pessoais do cliente como
endereços, documentos e telefones. Pode também realizar alteração de informações
ou excluir um cliente.
O cadastro de clientes é fundamental para o gerenciamento de entregas.
3.3.14 Manter Entregas
Ator: Caixa.
Pré-requisito: Existir o cliente cadastrado no sistema.
Descrição: As entregas são normalmente solicitadas por clientes que realizam
ligações telefônicas para o estabelecimento. A busca de cliente poderá ser feita
através do nome ou telefone, para facilitar a recuperação de endereço para entrega.
A opção deve funcionar de forma semelhante ao processo de venda, porém os itens
são associados a um cliente e não a uma mesa.
47
3.3.15 Abrir Caixa
Ator: Caixa.
Pré-requisito: Ser cadastrado como responsável pelo caixa.
Descrição: O usuário deve poder selecionar um caixa ao qual tem permissão
de acesso, e informar data, hora e valor de abertura. O valor de abertura deve estar
em conformidade com o valor do último fechamento do caixa.
3.3.16 Suprir Caixa
Ator: Caixa.
Pré-requisito: Ser o usuário responsável pela abertura do caixa.
Descrição: Somente o usuário que realizou a abertura do caixa pode realizar
a reposição de dinheiro no caixa, informando o valor, a data e hora do suprimento.
3.3.17 Retirar do Caixa
Ator: Caixa.
Descrição: Somente o usuário que realizou a abertura do caixa pode realizar
a retirada de dinheiro do caixa, informando o valor, a data, hora e a forma do débito,
que pode ser em dinheiro, cartão ou cheque.
3.3.18 Lançar em Caixa
Ator: Caixa.
Descrição: Somente o usuário que realizou a abertura do caixa pode fazer
lançamentos de valores variados depositados em caixa.
3.3.19 Fechar Caixa
Pré-requisito: Ator: Caixa.
48
Descrição: O fechamento do caixa só pode ser feito por quem realizou a
abertura. Ao fechar o caixa o usuário confere os valores que tem no sistema e
informa os totais de dinheiro, cartão e cheque existentes no caixa físico. O caixa não
pode ser fechado caso haja diferença entre o sistema e o caixa.
3.4 PROJETO DE BANCO DE DADOS
Um banco de dados bem projetado fornece um acesso conveniente e rápido
às informações desejadas. Com uma boa estrutura e projeto bem definidos, menos
tempo é gasto na sua construção e ao mesmo tempo, asseguram-se resultados
precisos. O projeto visa capturar as necessidades da organização em termos de
armazenamento de dados. (BATTISTI, 2005)
Segundo Heuser (1998), um modelo lógico é uma descrição de um banco de
dados no nível de abstração visto pelo usuário do SGBD. Assim, o modelo lógico é
dependente do tipo particular de SGBD que está sendo usado, o projeto atual utiliza
o modelo relacional onde os dados estão organizados na forma de tabelas.
O modelo lógico define como o banco de dados será implementado no SGBD.
O modelo lógico já leva em conta algumas limitações do SGBD e desenvolve
recursos, proporcionando ampla e flexível capacidade de estruturação. São lógicos
porque sua implementação não precisa ser conhecida. Nele já são definidas as
chaves primárias e estrangeiras. (REZENDE, 2004)
O modelo relacional representa os dados em um banco de dados como uma
coleção de tabelas. Cada tabela deve possuir um nome, que será único, e um
conjunto de atributos com seus respectivos nomes e tipos. Todos os valores de uma
coluna são do mesmo tipo de dados. (BAPTISTA, 2010)
Nesta seção é oferecida uma visão do projeto de banco de dados através dos
modelos lógico e relacional.
49
3.4.1 Modelo Lógico
Figura 3.2 – Modelo Lógico
50
3.4.2 Mapeamento para Modelo Relacional
Figura 3.3 – Modelo Relacional
51
3.5 DIAGRAMA DE CLASSE
Figura 3.4 – Diagrama de Classe
52
3.6 DIAGRAMA DE ATIVIDADE
Os diagramas de atividade são representações gráficas que ilustram o fluxo
de atividades envolvendo as etapas de um único processo, e são utilizados para
fazer a modelagem de aspectos dinâmicos do sistema. Uma atividade pode ser
considerada uma ação executada no sistema que resulta em uma mudança de
estado ou no retorno de um valor. (DUARTE, 2012)
Neste tópico são apresentados todos os diagramas de atividade relacionados
ao presente projeto, que descrevem os passos necessários para a conclusão de
uma atividade no sistema.
Figura 3.5 – Diagrama de Atividade Manter Usuários
53
3.6.2 Login
Figura 3.6 – Diagrama de Atividade Login
3.6.3 Trocar Mesa
Figura 3.7 – Diagrama de Atividade Trocar Mesa
54
Figura 3.8 – Diagrama de Atividade Manter Produtos
Figura 3.9 – Diagrama de Atividade Manter Categorias
55
3.6.6 Manter Caixas
Figura 3.10 – Diagrama de Atividade Manter Caixas
3.6.7 Manter Acréscimos
Figura 3.11 – Diagrama de Atividade Manter Tipos de Acréscimos
56
3.6.8 Manter Mesas
Figura 3.12 – Diagrama de Atividade Manter Mesas
3.6.9 Manter Vendas
Figura 3.13 – Diagrama de Atividade Manter Vendas
57
3.6.10 Manter Pagamentos
Figura 3.14 – Diagrama de Atividade Manter Pagamento de Itens
58
3.6.11 Manter Itens
Figura 3.15 – Diagrama de Atividade Manter Itens
3.6.12 Manter Cliente
Figura 3.16 – Diagrama de Atividade Manter Clientes
59
Figura 3.17 – Diagrama de Atividade Manter Entregas
3.6.14 Abrir Caixa
Figura 3.18 – Diagrama de Atividade Abrir Caixa
60
3.6.15 Suprir Caixa
Figura 3.19 – Diagrama de Atividade Suprir Caixa
Fonte: Elaborado
ado pelos autores, 2013.
Figura 3.20 – Diagrama de Atividade Retirar do Caixa
61
3.6.17 Lançar em Caixa
Figura 3.21 – Diagrama de Atividade Lançar em Caixa
62
3.6.18 Fechar Caixa
Figura 3.22 – Diagrama de Atividade Fechar Caixa
3.7 MVC
O MVC é um padrão de arquitetura de desenvolvimento de softwares que tem
como objetivo a divisão das regras de negócio e as interfaces em diferentes
camadas, facilitando assim a manutenção e a adição de novos componentes no
software. (GAMA, 2011)
Esse padrão tem três elementos conhecidos como Modelo, Visão e
Controlador, onde cada um desempenha um papel diferente na aplicação. Na
camada de modelo são especificadas as regras de negócio, definindo validações,
acesso a banco de dados, cálculos entre outros tratamentos. A visão é responsável
exclusivamente para a entrada e visualização de dados. O controlador é criado para
receber os dados da visão e encaminha-los para o modelo, não contendo nenhuma
regra de negócio implementada. (GAMA, 2011)
Neste tópico são apresentados os diagramas de MVC que compõem o projeto
do software.
63
Figura 3.23 – Diagrama de MVC Manter Usuários
3.7.2 Manter Login
Figura 3.24 – Diagrama de MVC Login
64
3.7.3 Trocar Mesa
Figura 3.25 – Diagrama de MVC Trocar Mesa
Figura 3.26 – Diagrama de MVC Manter Categorias
65
Figura 3.27 – Diagrama de MVC Manter Produtos
Figura 3.28 – Diagrama de MVC Manter Acréscimos
66
3.7.7 Manter Caixas
Figura 3.29 – Diagrama de MVC Manter Caixas
Figura 3.30 – Diagrama de MVC Manter Cliente
67
3.7.9 Manter Entrega
Figura 3.31 – Diagrama de MVC Manter Entrega
3.7.10 Manter Mesa
Figura 3.32 – Diagrama de MVC Manter Mesa
68
3.7.11 Manter Item
Figura 3.33 – Diagrama de MVC Manter Item
3.7.12 Manter Pagamento
Figura 3.34 – Diagrama de MVC Manter Pagamento
69
3.7.13 Abrir Caixa
Figura 3.35 – Diagrama de MVC Abrir Caixa
3.7.14 Fechar Caixa
Figura 3.36 – Diagrama de MVC Fechar Caixa
70
Figura 3.37 – Diagrama de MVC Retirar do Caixa
3.7.16 Suprir Caixa
Figura 3.38 – Diagrama de MVC Suprir Caixa
71
3.7.17 Manter Lançamento
Figura 3.39 – Diagrama de MVC Manter Lançamento
3.7.18 Manter Venda
Figura 3.40 – Diagrama de MVC Manter Venda
72
3.8 DIAGRAMA DE SEQUÊNCIA
O diagrama de sequência representa a troca de mensagens entre os
componentes do sistema, em determinada ação, mostrando o fluxo de controle entre
as instâncias de classes, subsistemas ou atores. (BAESSO, 2004)
Este diagrama tem como objetivo representar graficamente o comportamento
dos componentes da aplicação em tempo de execução. (BAESSO, 2004)
Neste tópico são apresentados todos os diagramas de sequência do projeto.
3.8.1 Manter Usuário
Figura 3.41 – Diagrama de Sequência Manter Usuário
73
3.8.2 Login
Figura 3.42 – Diagrama de Sequência Login
3.8.3 Manter Lançamento
Figura 3.43 – Diagrama de Sequência Manter Lançamento
74
3.8.4 Manter Caixas
Figura 3.44 – Diagrama de Sequência Manter Caixas
3.8.5 Abrir Caixa
Figura 3.45 – Diagrama de Sequência Abrir Caixa
75
Figura 3.46 – Diagrama de Sequência Manter Categorias
3.8.7 Fechar Caixa
Figura 3.47 – Diagrama de Sequência Manter Lançamento
76
Figura 3.48 – Diagrama de Sequência Manter Entregas
3.8.9 Suprir Caixa
Figura 3.49 – Diagrama de Sequência Suprir Caixa
77
Figura 3.50 – Diagrama de Sequência Manter Cliente
Figura 3.51 – Diagrama de Sequência Retirar do Caixa
78
3.8.12 Manter Mesa
Figura 3.52 – Diagrama de Sequência Manter Mesa
3.8.13 Trocar Mesa
Figura 3.53 – Diagrama de Sequência Trocar Mesa
79
3.8.14 Manter Itens
Figura 3.54 – Diagrama de Sequência Manter Itens
3.8.15 Manter Pagamento
Figura 3.55 – Diagrama de Sequência Manter Pagamento
80
Figura 3.56 – Diagrama de Sequência Manter Produtos
3.8.17 Manter Venda
Figura 3.57 – Diagrama de Sequência Manter Venda
Fonte: Elaborado pelos autores, 2013
81
Figura 3.58 – Diagrama de Sequência Manter Acréscimos
82
4 PROTÓTIPO FUNCIONAL
Neste capítulo é apresentado o protótipo do sistema, através de imagens das
aplicações web e móvel em funcionamento. É exposta apenas parte das
funcionalidades oferecidas pelo software, com o intuito de demonstrar a visão do
usuário final.
4.1 LOGIN
Nas figuras 4.1 e 4.2 são ilustradas a tela de login do sistema web, e do
aplicativo Android respectivamente. A autenticação de usuários é a tela inicial do
sistema, essencial para manter o controle de sessões e as permissões de acesso
dentro da aplicação.
Figura 4.1 – Login
83
Figura 4.2 – Login módulo Android
4.2 CADASTROS
As telas de cadastro do sistema seguem um padrão, onde inicialmente é
exibida uma lista com todos os registros, dando ao usuário as opções de inserir,
alterar e excluir informações.
Na figura 4.3 é ilustrado o cadastro de produtos. Ao carregar a página, o
usuário tem também a opção de filtrar os produtos por uma categoria específica.
Figura 4.3 – Cadastro de Produtos
Fonte: Elaborada pelos autores, 2013.
84
Ao ser acionado o botão “Novo”, situado logo abaixo da lista de registros, é
exibido para o usuário o formulário de cadastro. A janela é carregada com os
campos vazios para que seja efetuada a inserção de novos dados como mostra a
figura 4.4.
Figura 4.4 – Cadastro de Produtos (Opção “Novo”)
Para cada linha da lista de registros, existem os botões “Alterar” e “Excluir”. A
opção “Alterar” exibe para o usuário o mesmo formulário acionado através do botão
“Novo”, porém nele são carregados os dados do registro selecionado. As
informações referentes ao cadastro podem ser atualizadas no banco de dados
através do botão “Gravar”, como é ilustrado na figura 4.5. Os botões “Excluir”,
disponíveis tanto na tabela de registros quanto no formulário, quando acionados,
apagam o registro do banco de dados de forma permanente.
O padrão de manutenção de dados do sistema abrange as telas de cadastros
dos módulos de usuários, produtos, caixas e vendas.
85
Figura 4.5 – Cadastro de Produtos (Opção “Alterar”)
4.3 MOVIMENTAÇÕES VIA NAVEGADOR WEB
A manutenção das vendas dos estabelecimentos e seus respectivos itens é a
principal movimentação de dados dentro do sistema. A funcionalidade está
disponível na aplicação web através do menu “Vendas”, como mostra a figura 4.6.
São exibidas inicialmente todas as mesas cadastradas. A coluna “Aberta” aparece
checada caso a mesa já possua uma venda em andamento.
Figura 4.6 – Tela de Vendas
86
Ao selecionar uma mesa, o usuário tem acesso à tela de “Itens da Venda”
como ilustra a figura 4.7. Caso a mesa não possua nenhuma venda em andamento,
uma nova venda pode ser iniciada através do botão “Abrir/Fechar”, caso contrário a
venda será encerrada. Para que a mesa possa ser fechada, todos os itens devem
estar pagos.
Figura 4.7 – Itens da Venda (Aba Itens a Pagar)
Os itens que compõem a venda estão divididos em duas abas. A primeira é
identificada por “Itens a pagar”, onde todos os itens que foram consumidos na mesa
e ainda não foram pagos são visualizados. Três operações podem ser realizadas
nessa aba através dos botões “Novo”, “Dividir Itens” e “Registrar Pagamento”.
Ao acionar o botão “Novo”, é exibido ao usuário o formulário de cadastro de
itens da venda, que permite a inclusão de produtos ou acréscimos cadastrados
previamente, como mostra a figura 4.8.
87
Figura 4.8 – Cadastro de Item
O botão “Dividir Itens” figura 4.9, realiza a divisão do(s) item(ns) conforme a
quantidade informada pelo usuário. Essa opção tem o intuito de repartir igualmente o
valor total dos itens que serão pagos por mais de uma pessoa. Após a divisão é
criado um item para cada parte do produto dividido, conforme ilustra a figura 4.10.
Figura 4.9 – Dividir Itens
88
Figura 4.10 – Itens Divididos
A opção “Registrar Pagamentos” permite que, depois de selecionados um ou
mais itens a pagar, sejam informados os dados referentes ao pagamento. É
necessário preencher a informação do caixa em que será depositado o valor. Ao fim
da operação, os itens passam a ser visualizados na aba de “Itens Pagos”, conforme
é apresentado na figura 4.11.
Figura 4.11 – Registrar Pagamento
89
A aba “Itens Pagos” apresenta todos os itens que já estão quitados. Nela
encontra-se a opção “Estornar Pagamento”, para o caso de problemas com o
pagamento realizado. Se estornado, o lançamento é cancelado e os itens ficam
habilitados para pagamento novamente.
Figura 4.12 – Itens da Venda (Aba Itens Pagos)
4.4 MOVIMENTAÇÕES VIA DISPOSITIVO MÓVEL
O cadastro de itens do aplicativo Android é ilustrado na figura 4.13. O usuário
seleciona uma mesa e a categoria do produto desejado. Após isso é exibida a lista
de produtos pertencentes à categoria informada, para que seja anotado o pedido.
Figura 4.13 – Realizar pedido módulo Android
90
Ao selecionar um produto da lista, é aberta uma nova janela, onde podem ser
informadas a quantidade de itens e uma observação, como ilustrado na figura 4.13.
Figura 4.14 – Gravar pedido
A interface de “Registro de Atendimento”, figura 4.15, tem como finalidade
exibir os itens de vendas cadastrados tanto pelo aplicativo Android quanto pelo
sistema web. Um processo em background atualiza automaticamente a interface
para que então a cozinha, ou o atendente responsável pelo estoque providencie o
produto, e posteriormente o encaminhe para entrega à mesa.
Figura 4.15 – Registro de atendimento
91
4.5 EMISSÃO DE RELATÓRIOS
A aba “Itens Pagos”, figura 4.16, permite que o usuário selecione um ou mais
itens, para que seja emitido o relatório através do botão “Gerar Recibo”.
Figura 4.16 – Gerar Recibo
O sistema apresenta ao usuário a pré-visualização do relatório, como
ilustrado na figura 4.17, com as opções “Salvar” e “Imprimir”. O arquivo pode ser
salvo na máquina cliente com a extensão pdf, docx, HTML ou xls.
Figura 4.17 – Recibo de Pagamento
92
CONCLUSÃO
O curso de tecnologia em banco de dados tem o intuito de formar
profissionais
capacitados
e
especializados,
aptos
a
desenvolver
soluções
tecnológicas que colaborem com o desenvolvimento científico e econômico.
Tomando por base essa afirmação, o projeto construído busca oferecer um software
para a área de comercial, focando inicialmente o ramo de alimentos, porém com a
possibilidade de futuras adaptações para outros tipos de comércio.
O tema do trabalho desenvolvido foi escolhido devido à grande crescente do
mercado de dispositivos móveis, que causou o desejo por aprender a trabalhar com
software desse segmento. O projeto tem como objetivo a pesquisa, compreensão e
aplicação prática de uma conexão entre sistema web e aplicativo móvel. Sendo
assim, é possível concluir que o objetivo foi alcançado com êxito, de modo que
ambos os aplicativos trabalham de forma síncrona através do Web Service
especificado durante o trabalho.
Foi fundamental para o projeto o aprendizado de novas tecnologias através
de diversos meios, tais como internet, livros, artigos e revistas, visto que um dos
principais benefícios do trabalho de conclusão de curso é a oportunidade de o aluno
buscar conhecimento fora da sala de aula. Os Frameworks JSF e PrimeFaces foram
empregados com sucesso no projeto, bem como o assistente de desenvolvimento
de relatórios iReports, ocasionando maior produtividade para a evolução do trabalho
de graduação. O sistema gerenciador de bancos de dados PostgreSQL apresentou
bom desempenho e interface prática e intuitiva para o desenvolvedor.
Considerado o curso de banco de dados como um todo, foi possível aplicar
grande parte do aprendizado adquirido ao longo dos semestres, visto que o projeto
emprega de forma prática os conceitos e paradigmas oferecidos pelas disciplinas
referentes a Engenharia de Software, Bancos de Dados, Linguagens de
Programação, entre outras.
O trabalho pode ser evoluído através do desenvolvimento de novos módulos
do sistema, tais como "Recursos Humanos" e "Business Inteligence", e também da
implementação de interfaces voltadas para o consumidor final, permitindo que o
cliente realize pedidos por conta própria via navegador web ou dispositivo Android.
Pode-se ainda ser realizada a pesquisa e aplicação de um aplicativo para plataforma
iOS integrado ao sistema web.
93
APÊNDICE A – Integração entre Android e Aplicação Web.
Enviar e receber dados do aplicativo Android para o sistema web foi um dos
desafios desse projeto. Segundo Lecheta, o Android usa como banco de dados o
SQLite, que na verdade é uma biblioteca em linguagem C, que implementa um
banco de dados SQL embutido. É recomendado o uso do SQLite quando poucas
requisições são feitas ao aplicativo, ou quando o sistema é embarcado, ou seja, a
aplicação fica completamente encapsulada ou dedicada ao dispositivo.
Para que a requisição do usuário via dispositivo móvel fosse inserida no
mesmo banco de dados que o sistema web, era necessário criar uma conexão entre
os dois. Para o envio de dados foram usadas as classes Socket e ServerSocket do
pacote java.net. Para receber os dados do sistema foi utilizado um web service, que
trabalha em conjunto com a biblioteca ksoap2.
Para começar, dentro do projeto do sistema web no NetBeans é criada a
classe “ValidaSocket”, Figura 1, onde são instanciados um objeto da classe
ServerSocket e um da classe Socket. A constante “PORTA” é utilizada para declarar
a porta que será utilizada para o acesso do aplicativo móvel. Esse arquivo necessita
do método main, para que possa ser executado e assim permanecer aguardando a
requisição do aplicativo Android.
Figura 1 – Classe Principal – ValidaSocket
94
A segunda classe a ser implementada é a ValidaSocketThread, Figura 2.
Essa classe abre a InputStream e OutputStream do socket e delega a lógica de
leitura e escrita no canal de comunicação com o socket-cliente para as classes
Valida, TrocaMesa e VendaAndroid. Mais detalhes sobre como criar sockets,
threads e manipular streams em Java não são fornecidos, pois não é esse o objetivo
dessa seção. Para leitura de variáveis que são enviadas pelo Android, é utilizada a
DataInputStream, e para transmitir dados para o aplicativo é utilizada a
DataOutputStream.
A String “func” recebe o primeiro parâmetro enviado pela aplicação Android,
sendo acionado o método readUTF() que lê Strings. Outros métodos podem ser
empregados para ler as variáveis dependendo de seus tipos, como por exemplo,
readInt(), para ler inteiros, readDouble(), para ler variáveis do tipo Double.
Figura 2 – ValidaSocketThread
A variável “func” é utilizada para distinguir qual será a funcionalidade ativada
pelo sistema web. Cada tela que envia dados do aplicativo Android passa um valor
diferente, definindo o procedimento a ser exercido a partir da aplicação.
Quando o valor é “valida”, a classe “Valida” é instanciada, passando como
parâmetro para o método construtor o objeto “in” que é uma instancia da classe
95
DataInputStream. Posteriormente é acionado o método “validar” que realiza a
autenticação de usuário e senha através dos valores recebidos da tela de login do
aplicativo Android, e então disparado o método “enviar”, que obtém a resposta da
DAOUser e retorna a resposta para o Android.
Na classe “Valida”, Figura 3, é instanciada a DAO do usuário e então
definidas as variáveis que recebem os valores passados pelo aplicativo. O método
“validar”, aciona o método validaLogin(User) que está na DAOUser, passando como
parâmetro as variáveis lidas de usuário e senha, retornando um valor booleano true
se as informações forem validas ou false se as informações não coincidirem com as
que estão no banco. A partir da variável de retorno, é enviada a resposta para o
Android através do método “enviar”.
Figura 3 – Classe Valida
96
Na figura 4, é ilustrado o método da DAOUser responsável pela validação de
dados de usuário e senha, recuperando as informações do banco de dados.
Figura 4 – Método validaLogin
Para recuperar informações do banco e enviá-las para o aplicativo Android, foi
utilizado um Web Service (WS) criado junto ao sistema web. Para adicionar um WS
basta clicar com o botão direito no projeto Java e, no menu “Novo”, procurar pela
opção “Web Service” como ilustra a figura 5.
Figura 5 – Criando um Web Service
97
Após preencher o “Nome do Web Service” e escolher o pacote onde ele ficará
localizado, como ilustra a figura 6, é preciso acionar o botão “Finalizar”.
Figura 6 – Criando um Web Service preenchendo os campos.
Um arquivo localizado no pacote selecionado será criado como mostra a
figura 7. E uma nova pasta será adicionada contendo o novo Web Service, como
mostra a figura 8.
Figura 7 – Arquivo do Web Service
Figura 8 – Pasta dos Web Services
98
Para incluir um método, acione o ícone do Web Service com o botão direito e
selecione “Adicionar Operação” como mostra a figura 9.
Figura 9 – Adicionar operação
Na tela de adicionar operação, o nome do método precisa ser preenchido,
bem como seu tipo de retorno. Como ilustra a figura 10, o método é identificado por
“getCategoriaAndroid”, que retorna uma lista de categorias, List<CategoriaAndroid>.
Figura 10 – Adicionar detalhes da operação
99
No arquivo, figura 11, existe a programação detalhada da operação criada
anteriormente. No método getCategoriaAndroid por exemplo, é instanciada a
DAOCategoria, depois é definida uma variável do tipo List<CategoriaAndroid>, que é
uma lista do modelo CategoriaAndroid. Essa variável é preenchida pelo método da
DAOCategoria, selectCategoriaAndroid(), que retorna uma lista de CategoriaAndroid
que é atribuída pra dentro da variável listCat. E então essa variável é retornada,
preenchida com uma lista de objetos da classe CategoriaAndroid.
Figura 11 – Arquivo gerado pelo Web Service.
Fonte: Elaborado pelos autores,2013.
A Figura 12 ilustra o método selectCategoriaAndroid() da DAOCategoria. Ele
acessa o banco de dados Postrgre e retorna as categorias juntamente com seus
produtos. As categorias são adicionadas em uma ArrayList<CategoriaAndroid>, que
é uma lista de objetos da classe CategoriaAndroid.
Essa classe contém os atributos: “codcategoria”, que contém o código da
categoria, “descategoria”, que contém a descrição da categoria, e “prods”, que é
100
uma variável do tipo String, que contém os nomes de todos os produtos da categoria
separados por ponto e vírgula.
Figura 12 – Método selectCategoriaAndroid()
Agora os dados serão enviados do aplicativo Android para o sistema web via
socket, e recebidos do Web Service para então exibir na tela.
A classe LoginActivity, Figura 13, é responsável por gerenciar as informações
de login do usuário e realizar sua validação. Para enviar os dados via aplicativo
móvel, duas constantes precisam ser criadas para definir o endereço de conexão do
socket, “IP” e “PORTA”. A primeira com o valor de 10.0.2.2, e a segunda com o valor
7777. É importante ressaltar que o IP geralmente usado pela máquina é o 127.0.0.1
ou localhost, pois o acesso é local. Porém esses endereços já são utilizados
internamente pelo Android para referenciar o emulador, por isso opta-se pelo
10.0.2.2.
O método loginOnClick é acionado pelo botão de login da tela principal do
sistema. Detalhes sobre a implementação das telas não serão fornecido, pois não é
esse o objetivo dessa seção. Após recuperar as informações referentes a usuário e
senha, dentro de um bloco de try-catch, é instanciada a classe Valida, passando
como parâmetro as constantes de IP e porta. Lembrando que em aplicações reais
esse endereço de IP seria um endereço válido de internet.
101
Uma variável int é criada para recuperar o valor que é retornado pelo método
validar(int,String), que pode ser encontrado na classe Valida, onde o primeiro
parâmetro é o usuário e o segundo é a senha. O valor retornado por esse método é
que influenciará na ação da classe. Se a resposta for 0, então a aplicação deve
exibir a tela MainActivity, que é a segunda tela do sistema, onde então o usuário tem
permissão de navegar pelo aplicativo. Caso a resposta seja diferente disso, o
aplicativo informa ao usuário através de uma mensagem de erro que o usuário ou
senha estão incorretos.
Figura 13 – LoginActivity
A classe Valida, figura 14, ilustra como são enviados os valores do aplicativo
móvel para o sistema web. Alguns atributos são criados para a classe Valida. Um int
para armazenar a resposta da validação, um objeto do tipo Socket, um objeto do tipo
DataOutputStream e um do DataInputStream. O método construtor da classe deve
102
receber uma String e um int como parâmetros, que representam respectivamente o
IP e a PORTA para conectar com o socket. O método validar(int, String) recebe os
valores de usuário e senha.Tudo que é enviado do aplicativo usa o “out”, e tudo que
é recebido do sistema web usa o “in”.
O primeiro valor é uma String a ser enviada pelo método writeUTF(), outros
tipos de dados utilizam outros métodos, como writeInt(), para inteiros, writeDouble()
para ler variáveis do tipo Double, etc. A ordem em que os dados são enviados e
lidos é de extrema importância, pois eles devem ser lidos no Sistema Web na
mesma ordem em que são enviados do aplicativo Android.
O “out.flush()” é responsável por enviar os dados, e o “in.readInt()” é o
responsável por ler a resposta do Sistema Web. A resposta é então armazenada na
variável “res”, que posteriormente é retornada. Por fim, todos os atributos são
fechados através do método “close()”.
Figura 14 – Classe Valida
103
Para recuperar os dados via Web Service, é necessário adicionar o JAR da
biblioteca ksoap, como ilustra a figura 15.
Figura 15 – Arquivos .JAR da biblioteca ksoap
Para recuperar as informações de categoria é necessário criar a classe de
Categoria, como ilustra a Figura 16, contendo os atributos: “codCategoria”,
“desCategoria” e “prods”. Criam-se também todos os getters e setters dos atributos.
O método toString() precisa ser implementado, para retornar os valores que
aparecerão no combo box de categoria na tela para o usuário.
Figura 16 – Classe Categoria
104
A classe ConexaoWS, figura 17, recupera os dados de categoria, através do
método getCategoriaAndroid do Web Service. Na constante NAMESPACE é
informado o pacote onde o Web Service é encontrado, no exemplo o pacote é o
“android”. METHOD_NAME define o nome do método que está no WS.
SOAP_ACTION recebe o nome do pacote/nome do método. E a URL recebe o valor
da URL de acesso ao Web Service.
O método getCategoria() da classe ConexaoWS retorna um vetor de objetos
do tipo categoria. Dentro desse método, é feita a comunicação entre o Web Service
e o Android, que através do objeto, soapObject, recupera os valores das categorias,
que são inseridos no objeto de Categoria “ca”. Então esse objeto é adicionado para
o vetor de categoria “cat”, que é então retornado.
Figura 17 – Classe ConexaoWS
105
A classe vendaActivity é responsável por recuperar as informações das
categorias e preencher um Spinner (componente Android semelhante a um Combo
Box) com as informações de categoria. Essas informações são preenchidas através
do MyAsyncTask2(), pois a recomendação é para que o aplicativo não tenha que
processar todas as informações no método onCreate(), para que não tenha
problemas de performance.
Figura 18 – VendaActivity
A classe MyAsyncTask2() faz a conexão com o Web Service através da
classe ConexaoWS, e recupera as descrições das categorias, preenchendo assim o
Spinner com essas informações, como as figuras 19 e 20 ilustram. As figuras foram
divididas apenas para uma melhor leitura do código, mas elas pertencem à mesma
classe.
Para que a lista de produtos mude conforme a categoria selecionada pelo
usuário, todos dos produtos foram passados por uma String chamada “prods”, onde
os nomes dos produtos estavam separados por ponto e virgula, nesse método é
feito um tratamento onde os nomes são separados um por um, preenchendo um
vetor de String, que é utilizado para preencher um list, onde o usuário pode ver
106
todos os produtos da categoria selecionada, para fazer então a solicitação do
pedido.
Por fim, a figura 21 ilustra como preencher a lista de produtos através do
método preencherListaProdutos(String[]) que recebe como parâmetro um vetor de
String, com os nomes dos produtos, e abre uma nova janela a partir de um item
clicado dessa lista. São passados para essa nova tela os seguintes parâmetros:
numero da mesa que está realizando o pedido, recuperado a partir de um spinner, o
produto selecionado na lista e o ID do usuário.
Figura 19 – MyAsyncTask2 parte 1
107
Figura 20 – MyAsyncTask2 parte 2
Figura 21 – Método preencherListaProdutos(String[])
108
REFERÊNCIAS BIBLIOGRÁFICAS
ARAUJO, C. O IDE NetBeans. Easy Java Magazine. Rio de Janeiro, n. 5, p. 15-29,
abr. 2011.
ARAUJO, E. Comparando as IDEs NetBeans e Eclipse. Easy Java Magazine. Rio
de Janeiro, n. 22, set. 2012.
BLEWITT, A. Eclipse Juno traz Eclipse 4 como padrão. Disponível em:
<http://www.infoq.com/br/news/2012/07/eclipse-juno> Acesso em: 10 abr. 2013.
BRIGATTO, P. C. JSF 2 e o PrimeFaces. Java Magazine. São Paulo, n. 108, p. 6998, out. 2012.
DANTAS, C. E. Desenvolvimento com Primefaces. Java Magazine. São Paulo, n.
112, jan. 2013.
CABRAL, J. E. O. A inovação tecnológica da indústria de alimentos. Disponível
em: <http://www.embrapa.br/imprensa/artigos/2000/artigo.2004-12-07.2406531424>
Acesso em: 20 mar. 2013.
DOEDERLEIN, O. P. Java: maduro, mas com o pé no acelerador. Java Magazine.
São Paulo, n. 100, p. 04-10, fev. 2012.
FERRARINI,
A.
Conhecendo
o
Android.
Disponível
<http://www.devmedia.com.br/conhecendo-o-android-revista-mobile-magazine42/24688#ixzz2QUkz3Us3> Acesso em: 17 abr. 2013.
em:
GIRELLI, F. C.; ARAÚJO, E. C. As novidades do Eclipse 4. Disponível em:
<http://www.devmedia.com.br/as-novidades-do-eclipse-4-revista-java-magazine111/26803> Acesso em: 10 abr. 2013.
GUIMARÃES, L. C. Primefaces. Java Magazine. São Paulo, n. 112, jan. 2013.
GONÇALVES,
E.
C.
Conhecendo
o
PL/SQL.
Disponível
em:
<http://www.devmedia.com.br/conhecendo-o-pl-sql/24763 > Acesso em: 18 abr.
2013.
LEAL, A.; MACÊDO, A. B.; SPINOLA, R. O. Introdução sobre UML: Mecanismos
gerais.
Disponível
em:
<http://www.devmedia.com.br/introducao-sobre-umlmecanismos-gerais-revista-sql-magazine-91/22261> Acesso em: 10 abr. 2013.
LEAL, A.; MACÊDO, A. B.; SPINOLA, R. O. Astah. Disponível em:
<http://www.devmedia.com.br/websys.5/webreader.asp?cat=2&artigo=3891&revista=
sqlmagazine_91#a-3891> Acesso em: 10 abr. 2013.
LECHETA, Ricardo R. Google Android. 2. ed. São Paulo: Novatec, 2010.
SILVA, R. P. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual
Books, 2007.
109
LOZANO, F. Por que Java?. Java Magazine. São Paulo, n. 100, fev. 2012.
LOZANO, F. JDBC de Ponta a Ponta: Parte 1. Disponível em:
<http://www.devmedia.com.br/artigo-java-magazine-41-jdbc-de-ponta-a-ponta-parte1/10187> Acesso em: 13 abr. 2013.
OLIVEIRA, P. R. PostgreSQL Stored Procedures – Parte 1. SQL Magazine. São
Paulo, n. 7, abr. 2007.
PEREIRA,
A.
P.
O
que
é
XML?
Disponível
em:
<http://www.tecmundo.com.br/programacao/1762-o-que-e-xml-.htm> Acesso em: 10
abr. 2013.
SENDIN, R. XML. Disponível em: <http://www.devmedia.com.br/artigo-webmobile25--xml/13867> Acesso em: 13 abr. 2013.
SMANIOTO, C. E. Conheça na prática os novos recursos do PostgreSQL 8.4. SQL
Magazine. São Paulo, n. 73, mar. 2010.
STERN, E. H. PostgreSQL – Introdução e Conceitos. SQL Magazine. São Paulo, n.
6, nov. 2007.

centro estadual de educação tecnológica paula souza

Transcrição

Documentos relacionados

Fluxograma

Laboratório IF43B TOO Prof. Tacla Conversor Celsius para

DIAGRAMA DE ESTADOS - Compra de e

PMR2440 – Programação para Automação

Bảng biểu, hình ảnh (Tiếng Bồ Đào Nha-Tiếng Bồ Đào Nha)

as 7 ferramentas da qualidade

Decodificadores

Identificação de causas pelo diagrama de espinha de peixe (Ishikawa)

Reunião 10 - Diagrama de Ishikawa

Diagramas de Contexto - PM Tech Capacitação em Projetos