universidade regional de blumenau -...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
SISTEMA DE PEDIDOS DE PIZZA PARA OTIMIZAÇÃO DE
ROTAS NO GOOGLE MAPS
THOMAS ALEXANDRE SENS
BLUMENAU
2009
2009/2-25
THOMAS ALEXANDRE SENS
SISTEMA DE PEDIDOS DE PIZZA PARA OTIMIZAÇÃO DE
ROTAS NO GOOGLE MAPS
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Francisco Adell Péricas, Mestre - Orientador
BLUMENAU
2009
2009/2-25
SISTEMA DE OTIMIZAÇÃO GEOGRÁFICA PARA UMA
REDE DE DISTRIBUIDORAS
Por
THOMAS ALEXANDRE SENS
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Francisco Adell Péricas, Mestre – Orientador, FURB
______________________________________________________
Membro: Paulo César Rodacki Gomes, Doutor – FURB
______________________________________________________
Membro: Adilson Vahldick, Mestre – FURB
Blumenau, 10 de dezembro de 2009
Dedico este trabalho aos meus pais, que
sempre me apoiaram nos estudos, a minha
namorada, que me apoiou, compreendeu e
abdicou minha presença em alguns finais de
semana.
AGRADECIMENTOS
À minha família, que sempre me apoiou.
Aos meus amigos e namorada, pelos empurrões e cobranças.
Ao meu orientador, Francisco Adell Péricas, por ter acreditado na conclusão deste
trabalho.
RESUMO
Este trabalho apresenta o desenvolvimento de um sistema web de logística de entrega para
uma rede de distribuidoras, que tem por objetivo encontrar o melhor caminho para cada
entregador e passar por diversos pontos de entrega, e representá-los graficamente em um
mapa. A rota é obtida através da resolução de Problemas de Roteamento de Veículos (PRV),
onde são explanadas diversas técnicas para a resolução do problema de custos de rota. Foram
utilizadas as técnicas de Model View Controller (MVC) na linguagem Hypertext Preprocessor
(PHP), sendo usado o Zend Framework e Google Maps API como biblioteca e o MySql como
base de dados.
Palavras-chave: Logística de entrega. Problemas de roteamento de veículos.
ABSTRACT
This paper presents the development of a web delivery logistics to a network of distributors,
which aims to find the best way for each delivery and through several points of delivery, and
represent them graphically on a map. The route is obtained by solving Vehicle Routing
Problems (PRV), which are explained various techniques to solve the problem of route cost.
Have used the Model View Controller (MVC) in the Hypertext Preprocessor (PHP) language,
and used the Zend Framework and Google Maps API as a library and MySql as database.
Keywords: Delivery logistics. Vehicle routing problem.
LISTA DE ILUSTRAÇÕES
Quadro 1 – Algoritmo do carteiro chinês .............................................................................. 17
Quadro 2 – Problema do caixeiro viajante - método algébrico .............................................. 17
Quadro 3 – Probabilidades de rotas ...................................................................................... 18
Quadro 4 – Requisitos não funcionais .................................................................................. 23
Quadro 5 – Requisitos funcionais ......................................................................................... 23
Figura 1 – Diagrama de casos de uso do administrador ........................................................ 24
Quadro 6 – Detalhamento do caso de uso UC01.01 Efetua login .............................. 24
Figura 2 – Diagrama de casos de uso do operador ................................................................ 25
Quadro 7 – Detalhamento do caso de uso UC02.09 Cadastrar restaurante ......... 26
Quadro 8 – Detalhamento do caso de uso UC02.01 Visualiza rota dos pedidos
.......................................................................................................................... 26
Quadro 9 – Detalhamento da manutenção de dados no sistema restrito ................................. 27
Figura 3 – Diagrama de casos de uso do consumidor ............................................................ 28
Quadro 10 – Detalhamento do caso de uso UC03.02 Cadastrar dados pessoais 28
Quadro 11 – Detalhamento do caso de uso UC03.03 Avaliar pedido ....................... 29
Quadro 12 – Detalhamento do caso de uso UC03.04 Cadastra endereços para
entrega .......................................................................................................... 29
Quadro 13 – Detalhamento do caso de uso UC03.05 Efetuar pedido de entrega
.......................................................................................................................... 30
Quadro 14 – Detalhamento do caso de uso UC03.06 Consultar situação do
pedido ............................................................................................................ 30
Figura 4 – Diagrama de atividades do processo de pedido .................................................... 32
Figura 5 – Diagrama de atividades do cálculo de rotas ......................................................... 33
Figura 6 – Diagrama de classes ............................................................................................ 34
Quadro 15 – Código fonte do método initialize() ...................................................... 35
Quadro 16 – Código fonte do método calculaRota(int,int).................................... 35
Quadro 17 – Código fonte do método calcular() ........................................................... 36
Quadro 18 – Código fonte do método imprimirMatrizDeRotas(array,array) ... 36
Quadro 19 – Código fonte do método buscaProximaDistancia() ............................. 37
Quadro 20 – Código fonte do método
calculaMelhorRota(array,boolean,array) .................................. 38
Figura 7 – Debug da função calculaMelhorRota(array,boolean,array) ......... 39
Quadro 21 – Código fonte do método buscaRotaMaisCurta(debug) ........................ 39
Figura 8 – Diagrama de sequência do processo de pedido .................................................... 40
Figura 9 – Diagrama de sequência do cálculo de rotas .......................................................... 41
Figura 10 – Diagrama de estados .......................................................................................... 42
Figura 11 – Página inicial do aplicativo ................................................................................ 43
Figura 12 – Escolha do restaurante ....................................................................................... 44
Figura 13 – Escolha do tamanho de pizza ............................................................................. 44
Figura 14 – Seleção de sabores para a pizza ......................................................................... 45
Figura 15 – Seleção de adicionais......................................................................................... 45
Figura 16 – Informações para entrega................................................................................... 46
Figura 17 – Informações adicionais ...................................................................................... 46
Figura 18 – Detalhes do pedido ............................................................................................ 47
Figura 19 – Acesso a área restrita ......................................................................................... 48
Figura 20 – Tabela de registros da área restrita ..................................................................... 48
Figura 21 – Alteração de situação do pedido ........................................................................ 49
Figura 22 – Representação visual da rota.............................................................................. 50
Figura 23 – Resultado do cálculo de rotas ............................................................................ 50
Quadro 22 – Comparação entre trabalhos ............................................................................. 51
LISTA DE SIGLAS
API – Application Programming Interface
CEP – Código de Endereçamento Postal
HTML – HiperText Markup Language
IBGE – Instituto Brasileiro de Geografia e Estatística
IP – Internet Protocol
MVC – Model View Control
ODBC – Open Database Connectivity
PHP – Hypertext Preprocessor
PRV – Problemas de Roteamento de Veículos
UML – Unified Modeling Language
URL – Universal Resource Locator
XML – eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO..................................................................................... 13
1.2 ESTRUTURA DO TRABALHO .................................................................................. 14
2 FUNDAMENTAÇÃO TEÓRICA................................................................................. 15
2.1 PROBLEMÁTICA DO CÁLCULO DE CUSTOS DE ROTA ....................................... 15
2.1.1 Estratégias para resolução do problema de custos de rota ............................................ 16
2.1.1.1 Algoritmos genéticos ................................................................................................ 16
2.1.1.2 Problema do Carteiro Chinês .................................................................................... 16
2.1.1.3 Problema do Caixeiro Viajante. ................................................................................ 17
2.2 GOOGLE MAPS .......................................................................................................... 18
2.3 FRAMEWORK ZEND ................................................................................................... 19
2.4 WEB SERVICES .......................................................................................................... 19
2.5 TRABALHOS CORRELATOS .................................................................................... 20
2.5.1 Projeto do SIG Geo-Rota ............................................................................................ 20
2.5.2 Dissertação de mestrado de Formigoni (2005) ............................................................. 21
3 DESENVOLVIMENTO ................................................................................................ 23
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ..................... 23
3.2 ESPECIFICAÇÃO ........................................................................................................ 23
3.2.1 Diagrama de casos de uso ........................................................................................... 24
3.2.2 Diagrama de atividades ............................................................................................... 31
3.2.3 Diagrama de classes .................................................................................................... 33
3.2.3.1 Classe Rota ............................................................................................................. 34
3.2.4 Diagrama de seqüência ............................................................................................... 40
3.2.5 Diagrama de estados ................................................................................................... 41
3.3 IMPLEMENTAÇÃO .................................................................................................... 42
3.3.1 Técnicas e ferramentas utilizadas ................................................................................ 42
3.3.2 Operacionalidade da implementação ........................................................................... 43
3.3.3 ValePizza.com ............................................................................................................ 43
3.3.4 Módulo de pedido ....................................................................................................... 44
3.3.5 Módulo de administração ............................................................................................ 47
3.3.6 Cálculo de rotas .......................................................................................................... 49
3.4 RESULTADOS E DISCUSSÃO ................................................................................... 50
4 CONCLUSÕES ............................................................................................................. 52
4.1 EXTENSÕES ............................................................................................................... 52
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................. 54
12
1 INTRODUÇÃO
Este trabalho teve origem em função da carência de serviços de logística de entrega
pela internet para pequenas empresas, e foi impulsionado pela grande demanda destes
serviços, pouco explorados até hoje.
A motivação para o desenvolvimento deste trabalho ocorreu devido à falta de
informações na internet sobre restaurantes na região do Vale do Itajaí. Foi então pensado na
possibilidade de ter uma ferramenta para dispor estas informações, e ao mesmo tempo, poder
efetuar um pedido diretamente pela internet.
Como atualmente a maioria dos restaurantes não utilizam um sistema de otimização
geográfico para roteamento de seus veículos de entrega, foi decidido agregar este recurso a
ferramenta.
Atualmente, empresas de diversos setores disponibilizam seus produtos através de
entregas em domicílio, também conhecida como no inglês delivery. Delivery é o serviço de
entrega de materiais, bens, serviços ou produtos a um determinado local, através de uma
requisição utilizando algum meio de comunicação como telefone ou internet pelo cliente ou
consumidor. A entrega ao cliente é a transferência da posse de um bem de uma entidade, o
fornecedor, para aquela à qual o bem se destina (MILLER et al., 2006). Segundo Kohlrausch
(2005 apud SOMENZI, 2005), a confiança na entrega ao cliente do produto, no prazo
contratado, é o principal ponto a ser considerado na relação cliente - fornecedor.
Este assunto merece ser abordado, pois faz parte do dia-a-dia de milhares de empresas
que tem por objetivo a entrega de seus produtos de forma rápida e prática.
A verificação de uma melhor rota para entrega requer um tempo de processamento
polinomial em relação ao tamanho da entrada. Tendo a necessidade da elaboração de um
algoritmo que chegue ao resultado em um curto espaço de tempo, sem demandar muito
processamento, já que o aplicativo estará sendo executado em um servidor por diversos
distribuidores concorrentemente. Neste trabalho é feito um estudo de heurísticas para
descobrir qual a que melhor se encaixa neste tipo de aplicação.
Por fim, esta logística de entrega disponibiliza aos fornecedores uma forma econômica
e rápida de entregar seus materiais, bens, serviços ou produtos para seus clientes ou
consumidores.
Para atender as necessidades do fornecedor, com o intuito de diminuir o prazo de
entrega agilizando o processo e tornando a empresa mais competitiva no mercado, tem-se a
13
necessidade da utilização de um sistema de logística de entrega.
Diante desta necessidade, foi desenvolvido um sistema de logística de entrega que
detalha as melhores rotas de um ponto a outro da entrega, tendo em vista que um único
entregador pode ter mais de uma rota por viagem. Sendo necessário encontrar um caminho
que passe em cada um dos pontos de entrega e que tenha um custo menor, onde o custo do
caminho é a soma dos custos das rotas percorridas.
As origens e os destinos são obtidos através de Código de Endereçamento Postal
(CEP), que são convertidos em unidades de latitude e longitude, para serem representados
através de mapas, obtidos de um serviço gratuito da Google, chamado Google Maps. Este
serviço oferece uma poderosa tecnologia de mapas incluindo informações sobre percursos
entre rotas. Parte desta representação é desenvolvida utilizando uma Application
Programming Interface (API) de desenvolvimento web criada pela Google, que utiliza como
linguagem padrão o Java Script.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho foi o desenvolvimento de um sistema de entrega com
otimização geográfica para uma rede de distribuidoras.
Os objetivos específicos do trabalho são:
a) desenvolver um aplicativo de interação entre os consumidores e fornecedores
escrito em PHP;
b) calcular a melhor origem (entre várias de uma distribuidora) que mais se aproxima
dos destinos;
c) calcular a melhor rota para entrega, partindo de uma origem para um ou mais
destinos;
d) visualizar as rotas de entrega através de mapas.
14
1.2 ESTRUTURA DO TRABALHO
O trabalho está dividido em quatro capítulos. O segundo capítulo contempla a
fundamentação teórica, onde são apresentados conceitos e características sobre o problema do
cálculo de custos de rotas, assim como alguns métodos de resolução. São abordados também
assuntos referentes a tecnologia empregada no desenvolvimento do trabalho, como Google
Maps, Framework Zend, Web Services e os trabalhos correlatos.
No capítulo 3 são descritos os requisitos, a especificação dos scripts, a análise da
entrada, a especificação e a implementação da ferramenta, bem como a funcionalidade da
mesma.
Por fim, são apresentados os resultados obtidos. No último capítulo são apresentadas a
conclusão e sugestões para trabalhos futuros.
15
2 FUNDAMENTAÇÃO TEÓRICA
No presente capítulo são detalhados algoritmos e estratégias para a resolução do
problema de custos de rota, bem como as formas de representar as rotas a serem traçadas no
mapa através do Google Maps API. É abordado também a vantagem do uso de framework
para aplicações desenvolvidas em PHP, e sobre a utilização de Web Services para a
funcionalidade de custos de rotas. Por fim, são descritas ferramentas existentes no mercado
com funções similares as da ferramenta proposta.
2.1 PROBLEMÁTICA DO CÁLCULO DE CUSTOS DE ROTA
O roteamento de veículos é um problema presente na maioria das empresas de
transporte, logística e distribuição. Seu objetivo é determinar, dentre todas as possíveis rotas
alternativas, qual é a que representa o menor custo, ou seja, qual é a solução ótima
(GOLDBARG; LUNA, 2000, p. 35).
A resolução para descobrir qual é a melhor rota parece ser simples, bastando calcular o
custo de todas as possíveis combinações e selecionar a que apresentar o menor custo. Para um
pequeno conjunto de locais a serem visitados, isso é perfeitamente viável, mas à medida que
vão sendo adicionados novos locais, a solução vai se tornando cada vez mais complexa do
ponto de vista computacional, pois o número de combinações possíveis torna-se muito
grande, fazendo com que o cálculo possa demorar até vários dias dependendo do número de
locais a serem visitados.
Tendo em vista o problema de complexidade computacional, os Problemas de
Roteamento de Veículos (PRV), assim como a maioria dos problemas combinatórios, são
classificados como sendo NP-Completos (CORMEN et al., 2002), ou seja, a complexidade de
tempo é não polinomial. Até o momento, não foi possível encontrar nenhuma solução de
tempo polinomial para problemas da classe NP-Completo, assim sendo, atualmente não existe
nenhuma solução exata para o problema de roteamento de veículos em tempo polinomial.
16
2.1.1 Estratégias para resolução do problema de custos de rota
A seguir são mencionadas algumas estratégias para resolução do problema de custos
de rotas.
2.1.1.1 Algoritmos genéticos
Segundo Araújo (2008, p. 21), os algoritmos genéticos são os que melhor se
enquadraram nos problemas de roteirização clássicos como o do caixeiro-viajante e o de
roteirização de veículos.
Os algoritmos genéticos são uma família de modelos computacionais inspirados na
evolução, que incorporam uma solução potencial para um problema específico numa estrutura
semelhante a de um cromossomo. Uma das vantagens de um algoritmo genético é a
simplificação que eles permitem na formulação e solução de problemas de otimização.
Conforme Herrera, Lozano e Verdegay (1998), existem três tipos de representações
possíveis para os cromossomos: binária, inteira ou real. De acordo com a classe de problema
que se deseja resolver pode-se usar qualquer um dos três tipos. A função objetivo de um
problema de otimização é construída a partir dos parâmetros envolvidos no problema. Ela
fornece uma medida da proximidade da solução em relação a um conjunto de parâmetros. Os
parâmetros podem ser conflitantes, ou seja, quando um aumenta o outro diminui. O objetivo é
encontrar o ponto ótimo.
Os algoritmos genéticos são apropriados para problemas complexos de otimização, que
envolvem muitas variáveis e um espaço de soluções de dimensão elevada, abrangendo um
grande número de aplicações.
2.1.1.2 Problema do Carteiro Chinês
Segundo Rabuske (1993, p. 42), um grafo euleriano, é um grafo onde é possível achar
um caminho fechado, passando em cada aresta uma única vez. Caso o grafo for euleriano,
então o menor caminho pode ser encontrado através do algoritmo de Fleury (RABUSKE,
1993, p. 50). Como o desenvolvimento deste trabalho não tem restrições quanto ao número de
17
passagens pelos caminhos, então algumas arestas poderão se repetir, sendo sugerido o
algoritmo do Carteiro Chines, apresentado por Christofides, descrido no Quadro 1, o qual
determina o menor caminho entre dois vértices num grafo não euleriano.
ALGORITMO: CARTEIRO CHINES
P1 Determine os vértices de grau ímpar;
P2 Construa a matriz de distância D, com apenas os vértices de grau ímpar;
P3 Determine através da matriz D o par de vértices e que contém o menor caminho;
P4 Construa um caminho artificial de para com o custo encontrado em P3; [Este caminho
representa as arestas de menor custo que serão repetidas entre e ].
P5 Elimine da matriz D as linhas e colunas correspondente a e .
P6 Se ainda houver linha e coluna, então volte para P3
P7 Oriente o grafo;
P8 O custo será igual a soma dos custos de todas as arestas acrescida dos custos das arestas encontradas em P3.
Quadro 1 – Algoritmo do carteiro chinês
2.1.1.3 Problema do Caixeiro Viajante.
De acordo com Rabuske (1993, p. 54), o problema do caixeiro viajante também
consiste em determinar o menor caminho, passando por todos os vértices, e retornando ao
vértice de origem. Uma das formas de se resolver este problema é através do método
algébrico, também apresentado por Christofides, representado no Quadro 2, que envolve a
geração de todos os caminhos simples por multiplicação sucessiva de matriz.
MÉTODO ALGÉBRICO
P1 Construa inicialmente a matriz de adjacência A do grafo;
P2 Construa a matriz B(nxn) da seguinte forma
P3 Faça ;
P4 Faça onde
para todo
Quadro 2 – Problema do caixeiro viajante - método algébrico
Segundo UFRGS (2000), havendo quatro vértices distintos A, B, C e D, uma rota que
o caixeiro pode considerar seria a saída de A para B, dessa para C, e daí para D e então
voltando a A. Sendo assim existem seis possibilidades de caminhos diferentes, representados
no Quadro 3.
18
PROBABILIDADES DE ROTAS
ABCDA
ABDCA
ACBDA
ACDBA
ADBCA
ADCBA
Quadro 3 – Probabilidades de rotas
Para se achar o número R(n) de rotas para o caso de n vértices, é necessário fazer um
raciocínio combinatório. No caso de n=4 vértices, a primeira e última posição são fixas, de
modo que elas não afetam o cálculo, já na segunda posição podemos colocar qualquer um dos
três vértices restantes B, C e D, e uma vez escolhida uma delas, pode-se colocar qualquer uma
das duas restantes na terceira posição, de tal forma que na quarta posição não haverá
necessidade de nenhuma escolha, pois sobrou apenas um vértice. Consequentemente, o
número de rotas é 3 x 2 x 1 = 6, resultado obtido no Quadro 3 contando diretamente a lista de
rotas (UFRGS, 2000).
2.2 GOOGLE MAPS
Segundo Google (2008), Google Maps é um serviço de pesquisa e visualização de
mapas e imagens de satélite da Terra gratuito na web fornecido pela empresa Google.
Atualmente, o serviço disponibiliza mapas e rotas para diversas localizações do globo, com
possibilidade de aproximação das imagens em grandes cidades.
Ele disponibiliza também uma API (Application Programing Interface é um conjunto
de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades por
programas aplicativos) (WIKIPEDIA, 2008) chamada Google Maps API. Desta forma os
programadores não se atêm a detalhes de suas implementações, sendo utilizadas apenas suas
funções, compartilhando seu geo-processamento.
A API do Google Maps permite criar aplicações inovadoras de mapeamento online e
ajuda a integrar mapas e geo-codificações em seus sites. Com ele, pode-se facilmente
apresentar o conteúdo geo-referenciado em qualquer navegador.
Combinando as diversas funcionalidades disponibilizadas pela API, pode-se construir
um mapa com informações selecionadas e funções escolhidas para melhor navegação,
oferecendo inúmeras possibilidades de união de recursos para o desenvolvimento do mapa,
19
assim como o trajeto das rotas a serem seguidas e seus pontos de entrega.
Para poder ter acesso a estes recursos, é necessário obter uma chave de validação da
Google, que estará amarrada a Universal Resource Locator (URL), definida na solicitação de
uso do serviço.
Google Maps API torna possível a utilização de ferramentas simples e eficientes, que
disponibilizam acesso a conteúdo prático e dinâmico, que são retornados em arquivos
HyperText Markup Language (HTML).
Existem, contudo, algumas restrições de uso, definidas pelo Google Maps, impedindo
que se criem aplicações que excedam o grau de tecnologia existente nos aplicativos Google
Maps, de tal forma que os processamentos de imagens que utilizam os recursos destas APIs
estarão limitados por esta tecnologia.
2.3 FRAMEWORK ZEND
―Frameworks são projetados com a intenção de facilitar o desenvolvimento de
software, habilitando designers e programadores a gastarem mais tempo determinando as
exigências do software do que com detalhes de baixo nível do sistema.‖ (WIKIPEDIA, 2008).
Johnson (1992) define um framework como sendo ―um projeto reutilizável de um
programa, ou parte de um programa, expresso como um conjunto de classes‖.
O Zend Framework é um framework de desenvolvimento de aplicações web em PHP 5
que utiliza o padrão MVC, que separa a parte lógica da apresentação (ZEND
TECNOLOGIES, 2008).
Uma de suas importantes características é a reutilização de código, ou seja, o
desenvolvedor utiliza não só o seu próprio código, mas também aproveita os códigos já
escritos da ferramenta.
2.4 WEB SERVICES
Um Web Service é um sistema de software. Identificado através de uma URI, na qual
interfaces públicas e contratos são definidos e descritos em Extensible Markup Language
20
(XML). Estas definições podem ser descobertas por outros sistemas de software. Estes
sistemas podem então interagir com o Web Service em uma maneira prescrita pela sua
definição, usando mensagens baseadas em XML e transportadas por protocolos da Internet
(W3C, 2002).
Entre as principais vantagens do uso de Web Services, podem ser citadas:
a) interface abstrata: os Web Services fornecem uma interface abstrata para acesso
aos métodos disponibilizados, ocultando detalhes de implementação do usuário
do serviço;
b) semântica acompanha dados: ao invés de trafegarem somente os dados, a
comunicação entre o servidor e o cliente carrega consigo metadados;
c) portabilidade: por se tratar de um padrão aberto, baseado em XML, garante-se a
portabilidade das mensagens mesmo sob diferentes plataformas de operação;
d) segurança: opcionalmente, as informações trafegadas podem ser criptografadas;
e) utilização de recursos: os Web Services são sistemas não invasivos, pois não
consomem recursos de comunicação enquanto em estado de espera.
2.5 TRABALHOS CORRELATOS
A seguir são abordados dois trabalhos correlatos, que tem por objetivo melhorar os
serviços de distribuição ao consumidor.
2.5.1 Projeto do SIG Geo-Rota
O projeto do SIG Geo-Rota foi iniciado em meados de 1999, motivado pela elaboração
de um sistema computacional capaz de resolver problemas logísticos de distribuição em
pequenas e médias empresas (PÓVOA, 2000, p. 43), devido ao alto custo de aquisição de
dados geográficos. A versão inicial do sistema manipulava de forma simples os dados
necessários para a correta utilização dos algoritmos de otimização aplicados a problemas
logísticos de distribuição física de produtos (caminho mais curto, caixeiro viajante e
roteamento de veículos). Na versão atual, buscou-se uma modelagem mais detalhada dos
dados que fazem parte do sistema.
21
O Geo-Rota na sua versão customizada para problemas de delivery tem as seguintes
funções:
f) gerenciamento de projetos: responsável pela abertura, gravação e gerenciamento
dos arquivos que compõem o mapa, bem como os parâmetros de configuração;
g) gerenciamento de mapas: responsável pelo gerenciamento das camadas que
compõem o mapa utilizado em cada projeto de roteamento. Engloba funções de
adicionar e remover camadas, ferramentas de zoom, representação cartográfica,
geração de toponímia a partir de um atributo não geográfico, montagem de o
regras de endereçamento automáticas, utilizadas para transformar um endereço
(Rua y, nº x) em uma par de coordenadas geográficas GeoCode e ligação com
banco de dados externo via Open Database Connectivity (ODBC) chamado de
GeoLink;
h) gerenciamento de clientes: responsável pelo gerenciamento das camadas de
clientes a serem roteados. Engloba funções de criação de novos arquivos, remoção
e inserção de novos clientes. Possibilita a inserção de duas maneiras distintas, via
mapa ou via endereçamento GeoCode. Tem uma função específica para o cadastro
de novas lojas;
i) roteamento: resolve o problema do caminho mais curto entre dois clientes e
otimiza a escolha da loja mais próxima do cliente;
j) análise de mercado: responsável pela análise espacial dos clientes, possibilitando o
estabelecimento de logradouros em potencial que não estão sendo atendidos.
Permite fazer análises utilizando os setores censitários do Instituto Brasileiro de
Geografia e Estatística (IBGE).
2.5.2 Dissertação de mestrado de Formigoni (2005)
A dissertação de mestrado apresentada por Formigoni (2005) aborda como
preocupação principal o tratamento de problemas referentes à distribuição de produtos no
setor avícola, tendo como objetivo verificar a possibilidade de melhoria em serviços de
distribuição ao consumidor. Seu objetivo é estudar a utilização e o comportamento de alguns
métodos matemáticos frente a um determinado problema real. O que se procura é obter uma
solução mais apropriada do que aquela utilizada pelas empresas atualmente.
Para atingir este objetivo, foram analisadas diversas técnicas de pesquisa operacional,
22
visando à obtenção de uma solução quase ótima, através de métodos exatos, heurísticos e
meta-heurísticos.
Ele procura através da análise de diversos métodos construir soluções de fácil
implementação computacional, utilizando programas prontos para a solução de métodos
exatos com a criação de uma interface com o usuário e o desenvolvimento de um programa
para a resolução heurística, viabilizando assim a implantação nas empresas.
23
3 DESENVOLVIMENTO
Nesta seção, serão abordados os requisitos, a especificação e a implementação do
sistema de pedidos e seu recurso de otimização geográfica.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
No Quadro 4 e 5 são apresentados, respectivamente, os requisitos não funcionais e
funcionais da ferramenta.
REQUISITOS NÃO FUNCIONAIS
RNF01 Utilizar Web Services para disponibilizar o serviço de rotas
RNF02 Ser implementado utilizando o ambiente Zend Studio com suporte ao Zend
Framework
RNF03 O cálculo de uma rota de até 6 pontos distintos não poderá ultrapassar 5 segundos
RNF04 Utilizar a Google Maps API para o desenvolvimento da interface para visualização de
rotas
Quadro 4 – Req uisitos não funcionais
REQUISITOS FUNCIONAIS
RF01 Disponibilizar interface para emissão de pedidos para consumidores
RF02 A emissão de pedidos só poderá ser acessada mediante cadastro prévio
RF03 O pedido só poderá ser efetuado se o fornecedor estiver com a situação ―atendendo‖
na interface de emissão de pedidos
RF04 O fornecedor muda sua situação para ―atendendo‖ após acessar o gerenciamento de pedidos
RF05 O consumidor poderá consultar a situação do pedido
RF06 Disponibilizar interface para gerenciamento de pedidos para fornecedores
RF07 O gerenciamento de pedidos deverá ser somente acessado pelos fornecedores
RF08 No gerenciamento de pedidos deverão ser mantidos os dados referentes à elaboração de pedidos e sua manutenção
RF09 O gerenciador de pedidos deverá informar o fornecedor mediante aviso na tela
quando for emitido um novo pedido
RF010 Calcular a melhor rota entre uma origem e um ou mais pontos de entrega
RF011 Disponibilizar uma interface para visualização de rotas para fornecedores
Quadro 5 – Req uisitos funcionais
3.2 ESPECIFICAÇÃO
Para a especificação do projeto, foi utilizada a Unified Modeling Language (UML),
24
com auxílio da ferramenta Enterprise Architect, sendo criados os diagramas de casos de uso,
atividades, classes, sequência, posteriormente é apresentado o diagrama de estados.
3.2.1 Diagrama de casos de uso
Na Figura 1 são demonstradas as ações realizadas pelo administrador do sistema, que
tem a função de aceitar um restaurante previamente cadastrado, para que este restaurante
passe a atender pedidos pelo portal, assim como cadastrar novos operadores para estes
restaurantes, que terão a função de atender os pedidos e cadastrar os dados do restaurante.
Figura 1 – Diagrama de casos de uso do administrador
No quadro 6, é representado o processo de acesso ao sistema restrito, que corresponde
ao caso de uso UC01.01 Efetuar Login.
UC01.01 Efetuar login
Pré-condições Ter conta cadastrada para acesso ao sistema restrito
Cenário principal 01) Usuário acessa a área restrita através do endereço:
http://www.valepizza.com/adm
02) Sistema apresenta página com usuário e senha.
03) Usuário preenche os dados e confirma.
04) Sistema valida usuário e senha fornecidos.
05) Sistema registra hora, data e Internet Protocol (IP) que o usuário se
conectou ao sistema.
Exceção Se no passo 04, o usuário ou a senha não puderem ser validados, o sistema
apresenta uma mensagem mencionando o erro.
Quadro 6 – Detalhamento do caso de uso UC01.01 Efetua login
A aceitação do restaurante e o cadastro de operadores pelo administrador demonstrada
25
na Figura 1 é representada pelo Quadro 6, onde para aceitar um restaurante, o administrador
pode editar os dados do restaurante, informando se o restaurante será aceito ou não.
Na figura 2, podem-se observar as ações realizadas pelo operador do restaurante, que
tem a função de informar todos os dados referentes ao restaurante, manter os pedidos e
visualizar suas rotas.
Figura 2 – Diagrama de casos de uso do operador
O Quadro 7, designado Cadastrar restaurante, é o caso que descreve quais são as
ações realizadas pelo operador, para cadastrar seu restaurante.
26
UC02.09 Cadastrar restaurante
Cenário principal 01) Operador acessa o formulário de cadastro através do endereço
http://www.valepizza.com/associe-se
02) Sistema apresenta página de cadastro
03) Operador informa dados do restaurante. (nome, endereço, formas de
pagamento)
04) O sistema valida os dados, efetua o cadastro e envia um e-mail de
aviso para o administrador com o seguinte conteúdo: "Novo restaurante
cadastrado no sistema, favor acessar a administração e efetuar a
aceitação. <<link admin>>".
Exceção No passo 04, caso ocorra alguma inconsistência na validação como campo
obrigatório, o sistema apresenta mensagem referente ao problema encontrado.
Pós-condições O restaurante deve estar registrado, aguardando aceitação do administrador
Quadro 7 – Detalhamento do caso de uso UC02.09 Cadastrar restaurante
O caso de uso UC02.01 Visualiza rota dos pedidos é representado através do
Quadro 8.
UC02.01 Visualiza rota dos pedidos
Pré-condições Acessar área restrita com usuário e senha.
Ter no mínimo um pedido em aberto
Cenário principal 01) Operador acessa o menu rotas
02) Sistema apresenta página com uma matriz de distâncias entre os
pontos de entrega e restaurante.
02) Operador informa que deseja calcular a melhor rota.
03) O sistema calcula a melhor rota e a mostra visualmente através da
API Google Maps.
Pós-condições Representação da melhor rota através de mapa
Quadro 8 – Detalhamento do caso de uso UC02.01 Visualiza rota dos pedidos
Os demais casos de uso de cadastros como UC02.02 Cadastrar alimento, UC02.03
Cadastrar sabor, UC02.04 Cadastrar ingrediente, UC02.05 Cadastrar tipo de
alimento, UC02.06 Cadastrar tamanho do alimento, UC02.07 Cadastrar
complemento e UC02.08 Cadastrar promoções, seguem as mesmas lógicas de cenário
representadas pelo Quadro 9. Que consistem na edição, inserção e exclusão de registros.
27
Manutenção dos dados no sistema restrito
Pré-condições Acessar área restrita com usuário e senha Cenário principal 01) Operador acessa o recurso através do menu.
02) Sistema apresenta a listagem dos registros já cadastrados.
03) Operador opta por inserir, editar ou excluir um registro.
04) Sistema retorna mensagem referente à ação tomada e retorna ao
passo 02.
Fluxo alternativo 01 No passo 03, caso o operador opte por inserir:
03.01) Sistema apresenta formulário. 03.02) Operador preenche os dados e confirma.
Fluxo alternativo 02 No passo 03, caso o operador opte por editar: 03.03) Sistema apresenta formulário com os dados preenchidos
03.04) Operador altera os dados e confirma.
Fluxo alternativo 03 No passo 03, caso o operador opte por excluir um registro: 03.05) Sistema remove registro.
Exceção 01 No passo 03.02 e 03.04, caso ocorra alguma inconsistência na validação
como campo obrigatório, ou dados informados incorretamente, o sistema apresenta mensagem referente ao problema encontrado.
Pós-condições 01 No passo 03, caso o operador opte por inserir, deverá ser criado um novo registro para este recurso.
Pós-condições 02 No passo 03, caso o operador opte por editar, o registro editado, deverá ser
salvo.
Pós-condições 03 No passo 03, caso o operador opte por excluir um registro, o registro deve ser removido do recurso.
Quadro 9 – Detalhamento da manutenção de dados no sistema restrito
Na Figura 3, será abordado o diagrama de casos de uso do consumidor, que tem o
papel de efetuar pedidos, onde cada pedido terá um endereço com coordenadas de latitude e
longitude, que será utilizado para o cálculo de rotas. Estas coordenadas são obtidas através do
Google Maps API.
28
Figura 3 – Diagrama de casos de uso do consumidor
De acordo com o Quadro 10, é possível visualizar o cadastro de dados pessoais
representados na figura 3.
UC03.02 Cadastrar dados pessoais
Cenário principal 01) O consumidor acessa o formulário de cadastro através do endereço
http://www.valepizza.com/cadastre-se
02) Sistema apresenta página de cadastro
03) O consumidor informa seus dados pessoais e dados para acesso a sua
conta. (nome, data de nascimento, endereço, e-mail e senha)
04) O sistema valida os dados, efetua o cadastro e envia um e-mail de
confirmação com os dados do cadastro para o consumidor.
Exceção No passo 04, caso ocorra alguma inconsistência na validação como campo
obrigatório, o sistema apresenta mensagem referente ao problema encontrado.
Pós-condições O consumidor deve estar registrado
Quadro 10 – Detalhamento do caso de uso UC03.02 Cadastrar dados pessoais
No Quadro 11 é detalhada a avaliação de um pedido, que para ser feita deve estar com
a situação entregue. A avaliação é composta por dois campos, um com breve descrição, e
outro com uma nota de um a cinco, que posteriormente será visualizado em área pública do
portal.
29
UC03.03 Avaliar pedido
Pré-condições Ter efetuado o login e no mínimo um pedido entregue
Cenário principal 01) O consumidor acessa menu ―meus pedidos‖
02) Sistema apresenta listagem de pedidos efetuados
03) O consumidor informa o comentário, e uma nota de 1 a 5
04) Sistema registra avaliação
Exceção No passo 02, caso o consumidor não tenha pedidos entregues
02.01) O sistema avisa o consumidor de que não existem pedidos entregues
Quadro 11 – Detalhamento do caso de uso UC03.03 Avaliar pedido
O caso de uso UC03.04 Cadastrar endereços para entrega é representado no
Quadro 12, onde um consumidor pode ter diversos endereços para entrega, e escolher um
deles antes de iniciar o processo de pedido.
UC03.04 Cadastrar endereços para entrega
Pré-condições Ter efetuado o login
Cenário principal 01) O consumidor acessa menu ―meus endereços‖
02) Sistema apresenta página de endereços
03) O consumidor informa que deseja cadastrar um novo endereço
04) Sistema apresenta formulário de cadastro de endereços
05) O consumidor informa os dados do novo endereço e confirma
06) O sistema valida os dados, efetua o cadastro do novo endereço
Exceção No passo 06, caso ocorra alguma inconsistência na validação como campo
obrigatório, o sistema apresenta mensagem referente ao problema encontrado.
Pós-condições O novo endereço deve estar registrado
Quadro 12 – Detalhamento do caso de uso UC03.04 Cadastra endereços para entrega
O Quadro 13 tem o objetivo de explicar o funcionamento do processo de pedido, de
acordo com o caso de uso UC03.05 Efetuar pedido, tendo em vista que será utilizado um
sistema de fidelização de consumidores por pontos, onde a cada compra o consumidor recebe
pontos, que podem ser trocados por produtos em pedidos futuros.
30
UC03.05 Efetuar pedido
Pré-condições Ter efetuado o login
Cenário principal 01) O consumidor acessa menu ―novo pedido‖
02) Sistema apresenta listagem para seleção do endereço de entrega
03) O consumidor seleciona um endereço
04) Sistema apresenta listagem dos restaurantes que atendem a este
endereço
05) O consumidor seleciona a qual restaurante deseja efetuar o pedido
06) O sistema apresenta os tamanhos de pizza deste restaurante
07) O consumidor seleciona um tamanho de pizza
08) O sistema lista os sabores do restaurante para este tamanho de pizza
09) O consumidor seleciona os sabores desejados, e clica em avançar
10) O sistema lista os adicionais do restaurante
11) O consumidor seleciona os adicionais desejados, e clica em avançar
12) O sistema lista os produtos que podem ser trocados por pontos
13) O consumidor troca os itens que desejar, e clica em avançar
14) O sistema lista opções de entrega
15) O consumidor informa suas preferências, e clica em finalizar pedido
16) O sistema finaliza o pedido, e emite comunicado para o restaurante Cenário alternativo No passo 09, caso o consumidor queira adicionar outro tamanho de pizza:
09.01) O consumidor clica em ―quero mais uma pizza‖ 09.02) Sistema encaminha o consumidor para o passo 06
Exceção No passo 12, caso o consumidor não tenha pontos suficientes:
12.01) O sistema avisa o consumidor de que seus pontos são insuficientes
Pós-condições Pedido efetuado
Quadro 13 – Detalhamento do caso de uso UC03.05 Efetuar pedido de entrega
A consulta da situação do pedido é demonstrada no Quadro 14, onde além da situação,
o consumidor pode visualizar informações sobre a data e hora em que o pedido foi aberto,
assim como seus itens, local de entrega, valores e taxas.
UC03.06 Consultar situação do pedido
Pré-condições Ter efetuado o login e no mínimo um pedido
Cenário principal 01) O consumidor acessa menu ―meus pedidos‖
02) Sistema apresenta listagem de pedidos efetuados
03) O consumidor informa qual pedido deseja visualizar
04) Sistema apresenta a situação do pedido juntamente com o resumo do
pedido.
Exceção No passo 02, caso o consumidor não tenha efetuado pedido
02.01) O sistema avisa o consumidor de que não existem pedidos
Quadro 14 – Detalhamento do caso de uso UC03.06 Consultar situação do pedido
31
3.2.2 Diagrama de atividades
O diagrama de atividades apresentado na Figura 4 ilustra o processo de pedido do
consumidor.
O pedido pode ser efetuado de duas maneiras:
k) com um pré-cadastro, onde são cadastrados os dados do usuário e de sua conta,
sendo que após seu cadastro, é dado início ao processo de pedido, onde o
consumidor seleciona o endereço do cadastro, ou cria um novo endereço para
serem contabilizadas as taxas de entrega;
l) o pedido pode ser elaborado para mais tarde serem informados os dados do
cadastro e conta, tendo as taxas de entrega referentes ao bairro de entrega
selecionado no início do processo.
O pedido só pode ser feito para um restaurante, de tal forma que não será possível
emitir um pedido com itens de dois ou mais restaurantes distintos.
32
Figura 4 – Diagrama de atividades do processo de pedido
33
O diagrama de atividades representado na Figura 5 demonstra como é feito o processo
de cálculo de rotas.
Após acessar a tela de cálculo de rotas, o sistema busca as coordenadas de latitude e
longitude, que são cadastradas durante o caso de uso UC03.02 Cadastra dados pessoais,
de acordo com o endereço do Consumidor, descritos no Quadro 9. São feitas requisições para
o Google Maps API destas coordenadas, solicitando a distância entre todos os pontos, que são
carregadas em uma matriz pelo sistema para dar início ao cálculo da melhor rota entre estes
pontos.
Figura 5 – Diagrama de atividades do cálculo de rotas
3.2.3 Diagrama de classes
O diagrama de classes representado na Figura 6 exibe as principais classes encontradas
no sistema com seus devidos atributos. Algumas classes e métodos foram abstraídos para uma
melhor visualização do diagrama, não comprometendo o entendimento do mesmo.
34
Figura 6 – Diagrama de classes
3.2.3.1 Classe Rota
Esta classe é responsável pelo cálculo de rotas e representação geográfica através do
mapa. Os dados contidos nesta classe são gerados dinamicamente pelo PHP para serem
executados diretamente pelo navegador do operador através de scripts Java. Nos quadros a
seguir são detalhados seus métodos já gerados dinamicamente pelo PHP, para um melhor
entendimento.
O método initialize(), representado no Quadro 15, tem o objetivo de buscar as
coordenadas de latitude, longitude e nome do ponto de entrega, para serem instanciadas pelo
35
navegador do operador, através de variáveis da linguajem Java script. Os nomes das variáveis
funcionam como índices.
function initialize()
{
if (GBrowserIsCompatible()) {
latLng0 = new GLatLng(-26.929022,-49.132899);
local0 = "Juliana Baesso de Alcantara";
latLng1 = new GLatLng(-26.893243,-49.098249);
local1 = "Eduardo Yago Blankenburg";
latLng2 = new GLatLng(-26.95456,-49.067514);
local2 = "Daniel Arnon Silva";
latLng3 = new GLatLng(-26.913154,-49.093995);
local3 = "Solange Mari Sens";
latLng4 = new GLatLng(-26.923398,-49.091964);
local4 = "Antonio João Mandel Junio";
latLng5 = new GLatLng(-26.915527,-49.084554);
local5 = "Restaurante";
buscaProximaDistancia();
}
}
Quadro 15 – Código fonte do método initialize()
O método calculaRota(int,int), representado no Quadro 16, tem como
parâmetros, os índices das variáveis instanciadas durante o método initialize(), a função
deste método é buscar a distância entre os dois pontos da entrada de parâmetros. O serviço
para obter estas distâncias é disponibilizado pela API do Google Maps, onde é informado um
array de pontos e retornando informações como distância, tempo de percurso entre outros.
function calculaRota(j,k) {
var pointsArray = [ eval('latLng'+j),eval('latLng'+k)];
var dir = new GDirections(map);
dir.loadFromWaypoints(pointsArray, {locale:"pt-br", getSteps:false});
GEvent.addListener(dir,"load", function() {
var rota = new Array(2);
rota[1] =
roundNumber(dir.getDistance().meters/1000,3);
rota[2] =
roundNumber(dir.getDuration().seconds/60,2);
eval('aresta'+j+'[k] = rota[1]');
buscaProximaDistancia();
});GEvent.addListener(dir, "error", function() {
alert("Erro ao calcular rota." + "\nNúmero: " +
dir.getStatus().code);
});
}
Quadro 16 – Código fonte do método calculaRota(int,int)
O método calcular(), representado no Quadro 17, disponibiliza na interface o
botão para efetuar o cálculo de rotas. Ele é exibido somente após o sistema já ter carregado a
matriz de rotas.
36
function calcular()
{
destinos[0] = aresta0;
destinos[1] = aresta1;
destinos[2] = aresta2;
destinos[3] = aresta3;
destinos[4] = aresta4;
destinos[5] = aresta5;
var html = "<input type='button' onclick='resultado()'
value='calcular'>debug:<input type='checkbox' id='debug'>";
document.getElementById('calculo').innerHTML =
html+imprimiMatrizDeRotas(destinos);
}
Quadro 17 – Código fonte do método calcular()
O método imprimirMatrizDeRotas(array,array), representado no Quadro 18,
disponibiliza na interface via HTML uma matriz com as distâncias entre todos os pontos
informados no array do parâmetro de entrada, ordenados pelo parâmetro índice, que é um
array de posições.
function imprimirMatrizDeRotas(arrDest,indice)
{
var ind = new Array();
for (j=0;j<arrDest.length;j++){
ind.push(j);
}
if (!indice) {
indice = ind;
}
var html = "";
html += "<table border=1 cellpadding=1 cellspacing=1>";
html += "<tr><td></td>";
for (j=0;j<arrDest.length;j++){
html += "<td><b>"+ind[j]+"-"+ eval('local'+ind[j]) +
"</b></td>";
}
html += "</tr>";
for (i=0;i<arrDest.length;i++){
html += "<tr>";
html += "<td><b>"+indice[i]+"-" + eval('local'+indice[i]) +
"</b></td>";
for (j=0;j<arrDest[i].length;j++){
html += "<td align=right>" + arrDest[i][j] +
"</td>";
}
html += "</tr>";
}
html += "</table>";
return html;
}
Quadro 18 – Código fonte do método imprimirMatrizDeRotas(array,array)
O método buscaProximaDistancia(), representado no Quadro 19, é chamado pelo
método initialize(), e faz com que sejam calculadas as rotas de todos os pontos
37
disponíveis recursivamente.
function buscaProximaDistancia() {
if (destinos) {
if (jx == destinos.length) {
kx++;
jx = 0;
}
if (kx < destinos.length) {
valorj = jx;
valork = kx
calculaRota(valorj,valork);
calcular();
jx++;
} else {
map = new GMap2(document.getElementById("mapa"));
map.addControl(new GLargeMapControl());
map.setCenter(latLng5,13);
calcular();
}
}
}
Quadro 19 – Código fonte do método buscaProximaDistancia()
O método calculaMelhorRota(array,boolean,array), representado no Quadro
20, é o método que varre todos os pontos de entrega atrás de uma melhor rota, e tem o
parâmetro de entrada debug, que se estiver como true serve para visualizar detalhadamente
todas as ações tomadas pelo método, conforme Figura 7.
38
function calculaMelhorRota(arrayDestinos,debug,indices) {
var rota = new Array(arrayDestinos.length-1);
var retorno = [];
var custo;
var melhor;
var totalCusto = 0;
var visitado = new Array(arrayDestinos.length);
for (i=0;i<arrayDestinos.length;i++){
visitado[i]=false;
}
for (var i in indices){
custo = 999999999;
melhor = null;
for (var j in indices){
if (debug) {
msg('('+i+','+indices[j]+')
valor:'+arrayDestinos[i][indices[j]]+' menor custo:'+custo+'
vizitado:'+visitado[indices[j]]+'<br>');
}
if (arrayDestinos[i][indices[j]] < custo &&
arrayDestinos[i][indices[j]] != 0 && !visitado[indices[j]]) {
custo = arrayDestinos[i][indices[j]];
melhor = indices[j];
}
}
if (debug) {
msg('(Linha:'+i+') Melhor
custo:<b>'+arrayDestinos[i][melhor]+'</b>, Melhor rota:(de:'+indices[i]+'
para:<b>'+melhor+'</b> )<br>');
}
visitado[melhor] = true;
visitado[indices[i]] = true;
if (i==arrayDestinos.length-1) {
break;
}
if (melhor==null) {
rota[i] = null;
totalCusto += 99999999;
} else {
rota[i] = melhor;
totalCusto += arrayDestinos[i][melhor];
}
}
retorno['rota'] = rota;
retorno['custo'] = totalCusto;
return retorno;
}
Quadro 20 – Código fonte do método calculaMelhorRota(array,boolean,array)
Na Figura 7 é possível visualizar um trecho da execução do método
calculaMelhorRota(). Pode-se verificar que as linhas das duas matrizes de distância
explanadas são transpostas de acordo com a numeração dos índices de pontos de entregas
informados no parâmetro de entrada. Este processo é repetido até serem feitas todas as
transposições dos índices.
39
Figura 7 – Debug da função calculaMelhorRota(array,boolean,array)
O método buscaRotaMaisCurta(boolean), representado no Quadro 21, verifica
quais dos destinos tem a rota mais curta.
function buscaRotaMaisCurta(debug) {
var custo = 999999999;
var retornoRota = [];
melhor = null;
for (pd=0;pd<permutaDestinos['resultado'].length;pd++){
if (debug) {
msg('<br>verificando destino ['+pd+'] de
'+permutaDestinos['resultado'].length+', melhor=
'+melhor+'<br>'+imprimiMatrizDeRotas(permutaDestinos['resultado'][pd],permu
taDestinos['indices'][pd])+'<br>');
}
retornoRota =
calculaMelhorRota(permutaDestinos['resultado'][pd],debug,permutaDestinos['i
ndices'][pd]);
//if (debug) {
msg(' --> destino ['+pd+'] -
Custo:<b>'+retornoRota['custo']+'</b>
Rota:<b>'+retornoRota['rota']+'</b><br>');
//}
if (retornoRota['custo'] < custo) {
custo = retornoRota['custo'];
melhor = pd;
} }
return melhor;
}
Quadro 21 – Código fonte do método buscaRotaMaisCurta(debug)
40
3.2.4 Diagrama de seqüência
O diagrama de sequência representado na Figura 8 demonstra o processo de pedido até
sua finalização.
Figura 8 – Diagrama de sequência do processo de pedido
O diagrama de sequência representado na Figura 9 demonstra o processo de
roteamento.
41
Figura 9 – Diagrama de sequência do cálculo de rotas
3.2.5 Diagrama de estados
Na Figura 10, estão representados os estados do pedido, sendo que o estado aberto e
avaliado é dado pelo consumidor, os estados andamento e entregue são cadastrados pelo
operador do restaurante, já o estado cancelado pode ser atribuído por ambas as partes.
42
Figura 10 – Diagrama de estados
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.3.1 Técnicas e ferramentas utilizadas
O desenvolvimento do projeto foi elaborado utilizando a linguagem PHP5 no lado do
servidor e JavaScript no lado do cliente. Foi utilizada a ferramenta Zend Studio 7.0,
juntamente com a biblioteca de classes Zend Framework 1.9, que utiliza o padrão de
desenvolvimento MVC.
43
3.3.2 Operacionalidade da implementação
Este tópico aborda o teste de operacionalidade da implementação, através de um
estudo de caso que compreende a utilização do ponto de vista do usuário.
3.3.3 ValePizza.com
A usabilidade do sistema foi uma das prioridades do projeto: fazer com que o usuário
faça o pedido de forma simples e completa, como se fosse pedir ao balcão.
A Figura 11 ilustra a página inicial do aplicativo, que será o ponto de partida para o
consumidor, sendo acessado através do endereço http://www.valepizza.com, onde o
consumidor pode iniciar o processo de pedido, selecionando a cidade e posteriormente o
bairro a que deseja que seja feita a entrega.
Se o visitante não desejar fazer um pedido, ele pode navegar por outros recursos
disponíveis, como mapa de pizzarias, e perfis de pizzarias com informações.
Figura 11 – Página inicial do aplicativo
44
3.3.4 Módulo de pedido
O processo de pedido é feito de acordo com o restaurante selecionado na Figura 12.
Figura 12 – Escolha do restaurante
Após a escolha do restaurante, são listados os tamanhos de pizza, conforme Figura 13.
Figura 13 – Escolha do tamanho de pizza
Sendo selecionado um tamanho de pizza, o consumidor monta a pizza de acordo com
os sabores disponíveis para o restaurante em questão, conforme Figura 14.
45
Figura 14 – Seleção de sabores para a pizza
Os adicionais para o pedido são apresentados no passo seguinte, onde é possível notar
que os itens dos pedidos se encontram no extrato localizado ao lado esquerdo da Figura 15.
Figura 15 – Seleção de adicionais
Após a edição do pedido, é apresentado um formulário para informar os dados para
entrega e acesso à conta do usuário, como mostrado na Figura 16.
46
Figura 16 – Informações para entrega
O próximo passo consiste em informações adicionais sobre o pedido, mostradas na
Figura 17.
Figura 17 – Informações adicionais
Na Figura 18, após a finalização do pedido são detalhadas informações sobre o pedido,
sendo possível acompanhar seu andamento.
47
Figura 18 – Detalhes do pedido
3.3.5 Módulo de administração
Neste módulo são encontrados todos os cadastros referentes ao restaurante, cálculo de
rotas, manutenção dos pedidos e usuários.
O módulo de administração é acessado através de uma área restrita, encontrado no
endereço http://www.valepizza.com/adm, onde o operador acessa através de seu usuário e
senha, conforme Figura 19.
48
Figura 19 – Acesso a área restrita
A Figura 20 demonstra como é feita a manutenção dos dados do restaurante na área
restrita, representando a manutenção de pedidos. Os registros são dispostos em uma tabela,
com opções de edição, remoção e adição de novo registro.
Figura 20 – Tabela de registros da área restrita
49
Após selecionar um registro da tabela de pedidos, é exemplificada na Figura 21 sua
visualização e edição. O operador modifica a situação do pedido nesta tela, conforme sua
situação real.
Figura 21 – Alteração de situação do pedido
3.3.6 Cálculo de rotas
A representação visual da rota é feita através de serviços disponibilizados pelo Google
Maps API, onde é passado um array com os pontos e suas devidas direções, previamente
calculadas pelo sistema. O mapa mostrado na Figura 22 retrata um caminho gerado pelo
sistema, entre quatro pontos distintos.
50
Figura 22 – Representação visual da rota
Após executar o cálculo de rotas, é mostrado o resultado conforme Figura 23, sendo
que na primeira tabela, existe a matriz de distâncias entre todos os pontos, e na segunda
tabela, as direções tomadas através do cálculo.
Figura 23 – Resultado do cálculo de rotas
3.4 RESULTADOS E DISCUSSÃO
O sistema desenvolvido neste trabalho atendeu as expectativas propostas,
possibilitando aos restaurantes receberem pedidos pela internet visualizando suas rotas de
entrega. Atualmente existem dois restaurantes disponibilizando o serviço de entrega pela
internet e utilizando este sistema de roteamento, que já calculou a rota para mais de vinte
pedidos efetuados pelo portal.
Este projeto foi desenvolvido em um ambiente web, portanto foram utilizadas as
51
tecnologias disponíveis para a representação de rotas, como o Google Maps API,
diferentemente do projeto SIG Geo-rota, que utiliza uma tecnologia própria para
representações de rotas. Por um lado é vantajoso ter sua própria forma de representação de
rotas, pois caso sejam detectados problemas, é possível a correção dos mesmos, mas
dependendo da expansão do software para outras regiões, acaba sendo trabalhosa a
manutenção de todas estas regiões, havendo um lado positivo na representação de rotas
utilizando um serviço já disponível.
A dissertação de mestrado de Formigoni (2005) conseguiu explanar os princípios
básicos de métodos de solução via métodos heurísticos capazes de resolver o problema de
roteirização, explorando as características de cada técnica utilizada, elaborando métodos para
resolução de um problema real. Foram utilizados também princípios de métodos de solução
via formulação inteira, que procura minimizar a distância total percorrida, maximizando a
carga de cada entregador, podendo ser considerado também o custo de transporte por
quilômetro rodado para cada entregador, como mostra o Quadro 3.
COMPARACAO ENTRE TRABALHOS
Este trabalho Formigoni (2005)
Otimização de rotas X X
Disposição das rotas através de mapa X X
Maximização de carga por entrega X
Quadro 22 – Comparação entre trabalhos
52
4 CONCLUSÕES
Tendo em vista o problema da falta de um software de otimização geográfica com
custo acessível e de fácil acesso, optou-se por recorrer a uma API gratuita com todos os
recursos necessários para obtenção de distância e representações gráficas. Descartando todo o
processo de entrada de dados geográficos ao sistema, como é feito pelo projeto SIG Geo-
Rota. De certa forma, esta escolha acaba resultando certas questões como a devida atualização
geográfica do mapa, pois fica sob cuidados de terceiros, tendo algumas divergências como
novas ruas e suas direções.
Pelos testes feitos durante o desenvolvimento, foram verificados poucos erros
referentes aos caminhos encontrados pelo Google Maps API. A maioria dos erros são
referentes a direções, havendo em certos momentos passagens contra-mão durante a trajetória
da rota, implicando no retorno incorreto de distâncias entre pontos.
A escolha do melhor framework muitas vezes é difícil e pessoal, assim como a escolha
de uma linguagem de desenvolvimento, um sistema operacional, ou um Sistema de
Gerenciamento de Banco de Dados (SGBD).
O uso do Google Maps API está virando uma tendência nos serviços que necessitam
de representação visual através de mapas na web, juntando este recurso com a praticidade e
solidez do Zend Framework, que serve para facilitar o trabalho e poupar tempo, a qualidade
no desenvolvimento é um ponto forte na execução deste trabalho.
Dentre os frameworks pesquisados, foi escolhido o Zend, por ser um framework que
reúne uma ótima documentação, integração com diversas tecnologias, uma boa curva de
aprendizado, por ter empresas grandes apoiando a ferramenta e por não necessitar de arquivos
de configuração para sua publicação e utilização.
4.1 EXTENSÕES
Conforme a evolução do desenvolvimento do trabalho, tornou-se possível à análise de
diversas propostas para trabalhos futuros, sendo elas:
m) modificar algoritmo para encontrar a melhor rota para restaurantes com filiais, de
tal forma que o pedido seja entregue pela filial mais próxima;
53
n) modificar o algoritmo para poder utilizar mais de um veículo para as entregas;
o) calcular o tempo de entrega para cada pedido decorrente da rota.
54
REFERÊNCIAS BIBLIOGRÁFICAS
API. In: WIKIPÉDIA. A enciclopédia livre. [S.l.]: Wikimedia Foundation, 2008. Disponível
em: <http://pt.wikipedia.org/wiki/API> Acesso em: 20 set. 2008.
ARAÙJO, C. E. G. Algoritmos genéticos híbridos sem delimitadores de rotas para
problemas de roteirização de veículos. 2008. 89 f. Dissertação (Mestrado em Engenharia de
Sistemas Logísticos) – Escola Politécnica da Universidade de São Paulo; São Paulo.
CORMEN, T. H. et al. Algoritmos teoria e prática. 2. ed. Rio de Janeiro: Campus, 2002.
FORMIGONI, E. E. Resolução de problemas de roteamento de veículos na entrega de
produtos da indústria avícola. 2005. 127 f. Dissertação (Mestrado em Ciências Exatas) –
Universidade Federal do Paraná; Curitiba.
FRAMEWORK. In: WIKIPÉDIA. A enciclopédia livre. [S.l.]: Wikimedia Foundation, 2008.
Disponível em: <http://pt.wikipedia.org/wiki/API> Acesso em: 20 set. 2008.
GOLDBARG, M. C.; LUNA, H. P. Otimização combinatória e programação linear:
modelos e algoritmos. Rio de Janeiro: Campus, 2000.
GOOGLE. Google Maps API. [S.l.], 2008. Disponível em:
<http://code.google.com/more/#products-geo-maps>. Acesso em: 20 set. 2008.
HERRERA, F.; LOZANO, M.; VERDEGAY, J. L. Tackling real-coded genetic
algorithms: operators and tools for behavioural analysis. Artificial Intelligence
Review. v. 12, 1998.
JOHNSON, R. E. Documenting frameworks using patterns. Vancouver. 1992. Disponível
em:
<http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B3B26E0F912C941F3ADEBF41
B51A38C6?doi=10.1.1.46.6077&rep=rep1&type=pdf>. Acesso em: 21 set. 2008.
MILLER, G. A. et al. WordNet. Princeton, 2006. Disponível em:
<http://wordnet.princeton.edu/perl/webwn?s=delivery>. Acesso em: 14 set. 2008.
PÓVOA, C. L. Geo-rota: sistema de informação geográfica aplicado à distribuição física de
produtos em pequenas e médias empresas. [2000]. 82 f. Dissertação (Mestrado em Ciências
de Engenharia) - Universidade Estadual do Norte Fluminense; Campos dos Goytacazes.
RABUSKE, M. A. Introdução à teoria dos grafos. 1993. 173 f. Universidade Federal de
Santa Catarina; Florianópolis.
55
SOMENZI, S. Qual o principal ponto a ser considerado na relação cliente - fornecedor?
Baguete, 2005. Disponível em: <http://www.baguete.com.br/colunasDetalhes.php?id=1654>.
Acesso em: 14 set. 2008.
UFRGS. O problema do caixeiro viajante. Porto Alegre, 2000. Disponível em:
<http://www.mat.ufrgs.br/~portosil/caixeiro.html>. Acesso em: 20 jan. 2010.
W3C. Web Services architecture. [S.l.], 2002. Disponível em:
<http://www.w3.org/TR/2002/WD-ws-arch-20021114/>. Acesso em: 14 set. 2008.
ZEND TECNOLOGIES. About Zend framework. [S.l.], 2008. Disponível em:
<http://framework.zend.com/about/overview>. Acesso em: 14 set. 2008.