Modelo Relatório Final - Word - Versão 1.0

UNIVERSIDADE DO OESTE DE SANTA CATARINA
ÁREA DE CIÊNCIAS EXATAS E DA TERRA - ACET
CURSO DE ENGENHARIA DA COMPUTAÇÃO
VAGNER LUCAS GOMES
GEOLOGE – SOFTWARE DE LOGÍSTICA – PESQUISA, ESTUDO E
DESENVOLVIMENTO DE UM SOFTWARE DE LOGÍSTICA PARA
ROTEIRIZAÇÃO DE VEÍCULOS DE TRANSPORTE DE RAÇÃO,
LATICÍNIOS, ANIMAIS PARA ABATE.®
Joaçaba
2013
VAGNER LUCAS GOMES
GEOLOGE – SOFTWARE DE LOGÍSTICA – PESQUISA, ESTUDO E
DESENVOLVIMENTO DE UM SOFTWARE DE LOGÍSTICA PARA
ROTEIRIZAÇÃO DE VEÍCULOS DE TRANSPORTE DE RAÇÃO,
LATICÍNIOS, ANIMAIS PARA ABATE.®
Relatório de projeto de pesquisa do Curso
de Engenharia da Computação da
Universidade do Oeste de Santa Catarina.
Orientador: Prof. Ricardo Antonello, Me.
Joaçaba
2013
ii
Resumo
Este trabalho surgiu da necessidade de um grande empresa do agro negócio (Brf Foods) que
necessitava reorganizar todas sua logística de entregas de insumos agrícolas para seus
produtores. Assim, o projeto inicial desenvolvido em Delphi tinha a funcionalidade de sugerir
as fabricas quais produtores devem receber os insumos de quais fabricas determinado por um
raio de ação usando um distancia em linha reta. Neste projeto o sistema desenvolvido
inicialmente todo em Delphi foi reescrito e desenvolvido novamente em Java para web.
Também surgiu a demanda de novas funcionalidades para o sistema que formam o modulo de
carregamento de ração, modulo Sanidade e o modulo Frigorifico. O modulo de carregamento
de ração tem funcionalidades, cadastros de veículos, de rotas de fabricas para produtos,
agrupamentos de cargas para entregas, relatórios de históricos de entregas por veículos. O
modulo de Sanidade é para a parte ambiental da empresa, de forma simples verificar lotes de
alojamento de animais que estão em um raio de ação e possam estar contaminados. O modulo
frigorifico tem rotas entre frigoríficos e propriedades, para coleta de animais para o abate. O
sistema mostrou-se eficaz para auxiliar a empresa em decisões estratégicas, também para
obter as quilometragens exatas de distancias entre fabricas e propriedades já que grande parte
de mapas de interior não possui mapeamento, também reduz significativamente o tempo de
fechamento de cargas já que o sistema sugere vários agrupamentos. Mediante a tudo isso
obteve resultados de economia de tempo e serviços entre atividades de colaboradores da
empresa. Assim o sistema se mostra de grande utilidade para realização das atividades dentro
da empresa.
Palavras-chave: Rotas. Entrega. Logística.
iii
ABSTRACT
This work arose from the need for a large agribusiness company ( Brf Foods ) in the region
that needed to reorganize all their logistics supplies of agricultural inputs for its producers.
So the initial design was developed in Delphi functionality suggest the factories which
producers must receive inputs from factories which determined by a radius of action using a
distance in a straight line. In this design the whole system initially developed in Delphi was
rewritten and redeveloped in Java for web. The demand for new features to the system that
make up the module loading ration module and module Sanity Refrigerator also emerged. The
module load feed has features, registration of vehicles, routes factories for products, groups
of charges for deliveries, historical reports of deliveries by vehicles. The module for
Environmental Health is part of the company, simply check lots of housing animals that are in
a range and may be contaminated. The refrigerator module has routes between refrigerators
and properties, to collect animals for slaughter. The system proved effective to assist the
company in strategic decisions, also to get the exact mileage of distances between factories
and properties since most maps do not have indoor mapping, also significantly reduces the
time of closing charges since the system suggests multiple groupings. Through all this got
results time and services among the company's employee’s economy activities. Thus the
system
is
shown
useful
for
performance
of
activities
within
the
company.
Keywords: Routes. Delivery. Logistics.
iv
LISTA DE ILUSTRAÇÕES
Figura 1 - Tabela de linguagens de programação mais utilizadas .............................................. 7
Figura 2 - Modelo Conceitual................................................................................................... 25
Figura 3 - Diagrama de sequencia ............................................................................................ 26
Figura 4 - Diagrama de Classes de projeto ............................................................................... 27
Figura 5 - Diagrama de comunicação ....................................................................................... 28
Figura 6 - Modelo da Base de dados ....................................................................................... 29
Figura 7 - Tela de importação da Demanda ............................................................................. 31
Figura 8 - Tela para fechamento de cargas ............................................................................... 32
Figura 9 - Tela de Impressão de Cargas ................................................................................... 33
Figura 10 - Tela de vinculação de carga ................................................................................... 33
Figura 11 - Veículos que entregaram no Produtor ................................................................... 34
Figura 12 - Entregas realizadas pelo veículo com possível contaminação............................... 35
Figura 13 - Produtores em um Raio de 10 mil metro do produtor ........................................... 35
Figura 14 - Rotas para coleta de aves, suinos, etc .................................................................... 36
Figura 15 - Representação de um grafo não-orientado............................................................. 37
v
LISTA DE TABELAS
Tabela 01 – Custos do Sistema.............................................................12
LISTA DE SIGLAS
CSS - Cascading Style Sheets
HTML5 - Linguagem de Marcação de Hipertexto
JSP – Java Servers Pages
Java EE – Java Enterprise Edition
XHTML - Xtensible Hypertext Markup Language
SQL – Linguagem de Consulta Estruturada
PDF - Portable Document Format
RTF - Rich Text Format
XML - eXtensible Markup Language
XLS - Microsoft Excel file format
CSV - comma-separated values
HTML - HyperText Markup Language
DOCX - default Word document format
vii
SUMÁRIO
1
INTRODUÇÃO ...................................................................................................... 3
1.1
APRESENTAÇÃO .............................................................................................. 3
1.2
DESCRIÇÃO DO PROBLEMA .................................................................................. 3
1.3
JUSTIFICATIVA ...................................................................................................... 4
1.4
OBJETIVO GERAL .................................................................................................. 4
1.5
OBJETIVOS ESPECÍFICOS...................................................................................... 4
1.6
CRONOGRAMA ................................................................................................. 5
2
FUNDAMENTAÇÃO TEÓRICA ......................................................................... 6
2.1 SOFTWARE ......................................................................................................... 6
2.1.1 NetBeans IDE ...................................................................................................... 6
2.1.2 Linguagem Java................................................................................................... 6
2.1.3 i-Report/Jasper Report ........................................................................................ 8
2.1.4 Hibernate ............................................................................................................. 9
2.1.5 MySQL ................................................................................................................ 9
2.1.6 HTML5.............................................................................................................. 10
2.1.7 Inteface Grafica – BootStrap ............................................................................. 10
2.2 METODOLOGIAS DE DESENVOLVIMENTO ......................................................... 11
2.2.1 UML (Unified Modeling Language) ................................................................. 11
2.2.2 SCRUM – Metodologia Ágil ............................................................................ 11
3
3.1
ANÁLISE E PROJETO DE SOFTWARE ........................................................ 13
RECURSOS UTILIZADOS ...................................................................................... 13
3.2 LEVANTAMENTO DE REQUISITOS ...................................................................... 13
3.2.1 Requisitos Funcionais e não funcionais ............................................................ 14
3.2.2 Requisitos Suplementares ................................................................................. 17
3.2.3 Casos de Uso ..................................................................................................... 18
3.3 FASE DE ELABORAÇÃO ............................................................................... 19
3.3.1 Expansão do Caso de Uso ................................................................................. 19
3.3.2 Estórias de Usuário............................................................................................ 21
3.3.3 Plano de Release................................................................................................ 22
3.3.4 Lista de Operações e Consultas do Sistema. ..................................................... 23
3.3.5 Modelo Conceitual ............................................................................................ 25
3.3.6 Diagrama de Sequencia ..................................................................................... 26
3.3.7 Diagrama de Classes de projeto ........................................................................ 27
3.3.8 Diagrama de Comunicação ............................................................................... 28
3.3.9 Base de Dados ................................................................................................... 29
4
DESENVOLVIMENTO DO SISTEMA ............................................................ 30
4.1 O SISTEMA ........................................................................................................... 30
4.1.1 Modulo Fechamento de Cargas e Rotas ............................................................ 30
4.1.2
4.1.3
4.2
Modulo Sanidade............................................................................................... 34
Modulo Frigorifico ............................................................................................ 36
ROTEIRIZAÇÃO ................................................................................................... 37
5
RESULTADOS E CONCLUSÕES ..................................................................... 39
6
CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ............................. 41
REFERÊNCIAS .......................................................................................................... 42
2
1
1.1
INTRODUÇÃO
APRESENTAÇÃO
Este relatório apresenta os resultados obtidos durante a realização do Estágio
Curricular Obrigatório na empresa GEOLGE softwares de Gestão, que é uma empresa voltada
para softwares, iniciando em desenvolvimento de hardwares.
O objetivo final do estágio será o desenvolvimento de um sistema de
monitoramento de coleta de leite, onde este possibilitará a análise das coletas feitas pelo
caminhão e a geração de relatórios, que auxiliem o entreposto a tomar decisões estratégicas
quanto a coleta em tempo hábil, para manter um qualidade nos serviços e produtos.
Um projeto piloto será realizado em 13 cidades do oeste catarinense descritas no
item 4.2 deste trabalho.
1.2
DESCRIÇÃO DO PROBLEMA
Após a união das empresas Perdigão e Sadia – BR FOODS – houve um problema de
logística envolvendo as unidades de distribuição da empresa, principalmente no meio oeste
Catarinense. Algumas entregas/coletas de polos mais distantes passaram a ser desnecessários,
por exemplo, ao invés de um antigo polo da SADIA entregar uma carga de ração a um
integrado que se localiza nas proximidades de uma fábrica da PERDIGÃO, o caminhão
poderia sair direto de um antigo polo da PERDIGÃO, sendo assim, os gastos de transportes
poderiam ser otimizados.
Para facilitar o remanejo dessas rotas, é proposto o desenvolvimento de um software
inteligente que indica qual a melhor rota com origem e destino para ser utilizada. Com o
sistema, além da redução de custos, obtemos o benefício de economizar com combustível e
diminuir a emissão de gases poluentes. Na entrega de ração para animais, algumas
dificuldades serão encontradas ao analisar o processo de escolha de rotas. Cada produtor tem
uma capacidade de armazenamento de ração diferente, para saber quando ele precisa de ração,
existe um cálculo com um coeficiente, usando a capacidade de alojamento da granja, o tempo
do animal (frango, porco, peru), aonde se obtém a produção, quanto de ração é consumida e a
data prevista para fazer o carregamento dos animais.
Também no processo de laticínio o caminhão tanque para transporte de leite sai vazio
para voltar cheio, com essa ideia ele deve ir ao ponto mais distante para voltar o mais cheio
3
possível, ao ir mais longe vazio e ir carregando enquanto retorna, a economia de combustível
pode ser consideravelmente visível. Hoje o custo de frete da empresa com entrega de rações
aos seus integrados é gigantesco.
Com o sistema proposto GeoLOGE, a empresa poderá ter uma significativa redução
nesse valor, pois o software pretende informar/mostrar quais integrados de toda a rede (cerca
e seis mil) ficam mais próximos de cada uma das oito fábricas de rações da Regional Santa
Catarina. Após o projeto piloto na região meio oeste de Santa Catarina, pretende-se expandir
para Rio Verde/GO e Marau/RS.
Para realizarmos este estudos, e também fazer seu desenvolvimento teremos que adaptar
ao caso alguns algoritmos, como o A*(A-star), Djkistra, caixeiro viajante. Desenvolvendo
nossos próprios mapas através de imagens de satélites e utilizando grafos.
1.3
JUSTIFICATIVA
Devido ao grande tempo que pode levar a análise de remanejamento de rotas feita de
forma manual foi proposto a criação de um software que possa diminuir o tempo de análise
dessas rotas.
Também no mercado atual não existir nenhum software especifico para esta
funcionalidade de ajustes de rotas e gerenciamento de entregas de insumos agrícolas a
propriedades com alojamento para animais.
1.4
OBJETIVO GERAL
Desenvolver um sistema que possibilite uma melhor analise, auxiliando
colaboradores da empresa, reduzindo tempo de serviço e gerando economias.
1.5
OBJETIVOS ESPECÍFICOS

Desenvolver um modulo para gerenciamento de entregas de rações;

Desenvolver um metodologia para roteirização;

Desenvolver relatórios que possam auxiliar em decisões estratégicas.
4
1.6
CRONOGRAMA
Etapas
Levantamento dos requisitos
abr/13
mai/13
jun/13
jul/13
x
x
x
x
x
x
Análise de sistema
Codificação
ago/13
set/13
x
x
x
x
Testes
Correções
out/13
nov/13
dez/13
jan/14
x
x
X
x
fev/14
mar/14
x
x
x
x
X
x
x
5
2
FUNDAMENTAÇÃO TEÓRICA
Neste item será descrito todas as tecnologias utilizadas para a realização deste
projeto de estágio. Tanto para tecnologias de hardware que é desenvolvida em outro trabalho,
como para de Software que é desenvolvido neste projeto.
2.1
SOFTWARE
O Sistema é desenvolvido no ambiente de desenvolvimento NetBeans, utilizando
linguagem Java para Web (JSP, HMTL5, Java
Script, CSS3), para permitir desenvolver
uma aplicação robusta com interface web, que se adequa as necessidades da empresa.
2.1.1 NetBeans IDE
O netbeans é uma ferramenta de desenvolvimento open source, que permite
desenvolver, compilar e instalar programas, pode-se fazer uso de várias linguagens, o
netbeans é um produto livre, permitindo a sua utilização. Atualmente o netbeans é
desenvolvido pela Oracle®.
O NetBeans IDE é um ambiente de desenvolvimento - uma ferramenta para
programadores, que permite escrever, compilar, depurar e instalar programas. O IDE é
completamente escrito em Java, mas pode suportar qualquer linguagem de programação.
Existe também um grande número de módulos para estender as funcionalidades do IDE
NetBeans. O NetBeans IDE é um produto livre, sem restrições à sua forma de utilização.
2.1.2 Linguagem Java
Desde 1995 quando o Java foi formalmente anunciado pela Sun, ele chamou
atenção da comunidade de negócios por causa do enorme interesse na Web. O Java é utilizado
para aplicativos corporativos de grande porte (DEITEL, 2010, p. 6).
DEITEL vem afirmar que o com o Java pode ser possível criar aplicações seguras
na Web e tão eficazes quanto as Desktop.
No Java, um serviço web é implementado como uma classe. A classe que
represente um serviço Web reside em um servidor – ela não é parte do aplicativo cliente.
Disponibilizar um serviço Web para receber solicitações de cliente é conhecido como publicar
um serviço Web (DEITEL, 2010, p. 1019).
Atualmente a Sun pertence a Oracle que foi comprada em 2009 aonde o Java se
fortaleceu mais ainda, podemos ver no gráfico que Java é uma das linguagens mais utilizadas
no mundo.
Figura 1 - Tabela de linguagens de programação mais utilizadas
Fonte: TecMundo.com.br
NETO (2009, p. 19) diz que “A linguagem Java é muito versátil, podendo ser
utilizada para construir vários tipos de aplicativos, para diferentes meios e finalidades.”
2.1.2.1 Java Server Pages
JSP é o padrão do Java EE para aplicações web, ideal para criar aplicações robustas
na web, com grande capacidade de processamento no lado do servidor. NETO (2002, p. 3)
7
afirma que JSP pode ser usada para desenvolver aplicações web eficientes, escaláveis e
seguras rapidamente.
“As tecnologias Web do Java evoluem continuamente a fim de fornecer aos
desenvolvedores níveis mais altos de abstração e melhor separação das camadas do aplicativo,
o que torna aplicativos Web mais fáceis de manter e mais extensíveis.” Afirma DEITEL
(2010, p. 950).
Assim podemos manter funcionalidades no sistema que teríamos em um sistema
Desktop, isso que nos permite o Java Web.
Não podemos falar de JSPs sem mencionar o funcionamento de uma Servelet.
“Servlets estendem a funcionalidade de um servidor, permitindo que
ele gere conteúdo dinâmico. Servlets podem gerar XHTML,
personalizados, ajudar a fornecer acesso seguro para um site Web,
interagir com banco de dados sem nome de um cliente e manter
informações de sessão únicas para cada cliente.” (DEITEL, 2010, p
951)
Assim uma JSP é uma extensão de um tecnologia de servlet. Segundo DEITEL
(2010, p. 851) “As JavaServes Pages permitem aos programadores de aplicativos Web criar
conteúdo dinâmico reutilizando componentes predefinidos e interagindo com componentes
que utilizam scripts do lado do servidor”.
Em conformidade com a questão Temple et al. (2004, p. 11) diz “Assim, um JSP
consiste de uma página HTML com alguns elementos especiais, que conferem o caráter
dinâmico da página. Esses elementos podem tanto realizar um processamento por si, como
podem recuperar o resultado do processamento realizado em um Servlet,”
2.1.3 i-Report/Jasper Report
iReport é gratuito, designer de relatório de código aberto para JasperReports e
Servidor JasperReports. Criar layouts muito sofisticados contendo gráficos, imagens, subrelatórios, tabelas cruzadas e muito mais. Permite acessar dados através de JDBC,
TableModels, JavaBeans, XML, Hibernate, CSV e fontes personalizadas. Em seguida,
publicar os relatórios em formato PDF, RTF, XML, XLS, CSV, HTML, XHTML, textos,
DOCX ou OpenOffice.
8
2.1.4 Hibernate
Hibernate permite que você desenvolva classes persistentes seguintes idiomas
orientada a objetos naturais, incluindo herança, polimorfismo, associação, composição e o
framework Java coleções.
Persistência transparente: Hibernate não necessita de interfaces ou classes de base
para classes persistentes e permite que qualquer estrutura de classes ou de dados a ser
persistente. Além disso, o Hibernate permite construir procedimentos mais rápidos, uma vez
que não apresenta o tempo de compilação de código-fonte ou geração de código de byte ou
processamento. Alta Performance: Hibernate suporta a inicialização lenta, muitas estratégias
de ir buscar, e bloqueio otimista com versionamento automático e estampagem tempo.
Hibernate não necessita de tabelas especiais ou campos e gera grande parte do SQL em tempo
de inicialização do sistema, em vez de tempo de execução. Hibernate consistentemente
oferece desempenho superior em linha reta JDBC codificação.
Confiabilidade e Escalabilidade: Hibernate é bem conhecido por sua excelente
estabilidade e qualidade, comprovada pela aceitação e uso por dezenas de milhares de
desenvolvedores Java. Hibernate foi projetado para trabalhar em um cluster de servidor de
aplicativos e oferecer uma arquitetura altamente escalável. Hibernate escalas bem em
qualquer ambiente: Use-o para conduzir a sua in-house Intranet que atende a centenas de
usuários ou para aplicações de missão crítica que servem centenas de milhares.
Instalações de consultas abrangentes: Incluindo suporte para Hibernate Query
Language (HQL), Query Language Java Persistence (JPAQL), consultas de critérios, e
"nativas" consultas SQL; tudo o que pode ser rolada e paginado para atender às suas
necessidades de desempenho exatas.
2.1.5 MySQL
O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a
linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language)
como interface. É atualmente um dos bancos de dados mais populares, com mais de 10
milhões de instalações pelo mundo.
9
MySQL é a solução robusta para quase todo tipo de aplicação, combine a
estabilidade do MySQL com seu baixo custo de propriedade e rapidamente você irá
considerá-lo indispensável. O MySQL oferece o melhor cenário de todos SGBD, executa em
muitas plataformas, oferece um baixo TCO (custo total de propriedade) e é muito estável.
2.1.6 HTML5
HTML e uma linguagem de marcação para produzir páginas Web, através do
HTML o navegador processa imagens, texto, vídeo, sons, etc.
“O HTML é baseado no conceito de Hipertexto. Hipertexto são
conjuntos de elementos – ou nós – ligados por conexões. Estes
elementos podem ser palavras, imagens, vídeos, áudio, documentos
etc. Estes elementos conectados formam uma grande rede de
informação. Eles não estão conectados linearmente como se fossem
textos de um livro, onde um assunto é ligado ao outro seguidamente.
A conexão feita em um hipertexto é algo imprevisto que permite a
comunicação de dados, organizando conhecimentos e guardando
informações relacionadas (FERREIRA, 2013 p. 7).”
FERREIRA mostra que é possível desenvolver várias aplicações utilizando HTML,
contudo a nova versão do HTML, o HTML5, anteriormente o HTML4, mudou muitos
paradigmas que se tinham quanto ao mudo da internet. O HTML5 já fornece ferramentas que
facilitam a manipulação de elementos como CSS1 e JavaScript2.
Integrado com Java Web, podemos fazer sistemas que tenham funcionalidades
importantes e com ótima segurança.
2.1.7 Inteface Grafica – BootStrap
O BootStrap é uma camada de estilos (CSS) para ser usado em sites, ela é mantida
pelo Twitter em um projeto open source, disponível para usar como quiser. “Bootstrap é uma
estrutura elegante, intuitivo e poderoso front-end para o desenvolvimento web mais rápido e
1
Folhas de Estilos em cascata (Cascading Style Sheets). Usadas para mudanças visuais em paginas
web
2
JavaScript é uma linguagem de programação intepretada pelo navegador, posibilita a execução de
script do lado do cliente.
10
fácil, criado e mantido por Mark Otto e Jacob Thornton3.” (https://github.com/twbs/bootstrap,
tradução nossa).
Existem versões pagas do BootStrap, a versão adquirida para este trabalho foi a
Ace – Responsive Admin Template, na versão comercial, que pode ser encontrada neste site
wrapbootstrap.com.
2.2
METODOLOGIAS DE DESENVOLVIMENTO
2.2.1 UML (Unified Modeling Language)
Conforme Wazlawick (2011), UML é uma maneira de pensar sobre problemas,
através de modelos organizados em função de ideias do mundo real. Os modelos são úteis
para Compreensão de problemas, Comunicação c/ qualquer pessoa envolvida em um projeto,
clientes, especialistas de domínio, projetistas, analistas de sistemas, modelagem de
empreendimentos, preparação de documentação, projeto de programas e bancos de dados.
2.2.2 SCRUM – Metodologia Ágil
Conforme Wazlawick (2011), é uma maneira de pensar sobre problemas, através de
modelos organizados em função de ideias do mundo real. Os modelos são úteis para
Compreensão de problemas, Comunicação c/ qualquer pessoa envolvida em um projeto,
clientes, especialistas de domínio, projetistas, analistas de sistemas, modelagem de
empreendimentos, preparação de documentação, projeto de programas e bancos de dados.
O Scrum é uma metodologia ágil para gestão de projetos de softwares, ideais para
vários tipos de projetos principalmente os de pequeno porte, pois possui uma metodologia
simples e rápida de ser implementada em uma equipe de trabalho. “O Scrum pode ser
utilizado em vários contextos sem algum tipo de adaptação, um bom conhecimento das
funções do movimento Ágil e de seus processos lhe permitirá saber como adaptar o Scrum
para seu ambiente”, afirma PHAN, 2011 (p. 50). Assim usamos o Scrum juntamente com o
UML para fazer a modelagem do sistema e a gerencia do projeto.
3
Bootstrap é um frameword poderoso de front-end para desenvolvimento web. Foi criado e é mantido
por Mark Otto e Jacob Thornton.
11
Segundo PHAN, 2011 (p. 39) com as metodologias Ágeis começamos a valorizar:

“Indivíduos e interações em vez de processos e ferramentas”;

“Software funcional em vez de documentação extensiva”;

“Colaboração com o cliente em vez de negociação de contrato”;

“Resposta a mudanças em vez de seguimento de um plano”;
12
3
ANÁLISE E PROJETO DE SOFTWARE
Abordaremos a seguir as fases de análise de requisitos e projeto de software que
englobam os requisitos funcionais, não funcionais e suplementares, artefatos UML como
casos de uso, estórias de usuário, operações e consultas de sistema além de vários outros
diagramas necessários no desenvolvimento bem estruturado de um software deste porte.
3.1
RECURSOS UTILIZADOS
O sistema foi desenvolvido utilizando a linguagem Java para Web, mencionada no
item 2.1.2 deste trabalho, hospedado em um servidor Apache Tomcat4 na empresa KingHost®
que possui servidores Linux que podem rodas aplicações Java Web.
Para o desenvolvimento do sistema teve gastos com servidores e interfaces gráficas
que estão descritas na tabela abaixo
Tabela 01 – Custos para desenvolvimento do Sistema
Descrição
Valor
Servidor
R$ 308,00 (7 meses)
Ace – Responsive Admin
R$ 122,00 (U$ 50,00)
Template – versão
comercial
Total
3.2
R$ 430,00
LEVANTAMENTO DE REQUISITOS
Os requisitos especificam ações que um sistema deve ou não ser capaz de executar.
O sistema proposto nesse trabalho tem os requisitos funcionais, não funcionais e
suplementares descritos abaixo.
4
Os servidores Apache Tomcat, são servidores para aplicações Java Web que utilizam o Java EE
desenvolvido pela Apache Software Foundation.
13
3.2.1 Requisitos Funcionais e não funcionais
Os requisitos funcionais especificam ações que um sistema deve ser capaz de
executar. O sistema proposto nesse trabalho terá os seguinte requisitos.
F1 Manter registro de veículos
Oculto ( )
Descrição: O sistema deve registrar todos os veículos
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Placa Grupo de animal
Especificação
de veículos
pertencente, categoria de ração, capacidade, tipo de
veículo.
Fonte: o autor
F2 Manter registro de todos os tipos de Veiculo Oculto ( )
Descrição: O sistema deve registrar todos os tipos de veículos
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Codigo, descrição e
Especificação
de tipos de veículos
capacidade.
Fonte: o autor
F3 Manter registro de todos os produtores
Oculto ( )
Descrição: O sistema deve registrar todos os produtores
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código, Nome, Sistema
Especificação
de produtores
Produtos, Área, Caminhão, Capacidade, Distancia
Fabrica, Latitude Longitude, Município, Silo 1, Silo 2,
Altitude
Fonte: o autor
F4 Manter registro de todos as categorias
animais
Oculto ( )
Descrição: O sistema deve registrar todos as categorias animais
14
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código e Descrição
Especificação
de categorias animais
Fonte: o autor
F5 Manter registro de todos os grupos de ração Oculto ( )
Descrição: O sistema deve registrar todos os grupos de ração
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código e nome do
Especificação
de grupos de ração
grupo
Fonte: o autor
F6 Manter registro de todas as Rações
Oculto ( )
Descrição: O sistema deve registrar todas as rações
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código, Id Ração,
Especificação
de rações
Nome, Categoria Animal, Grupo de ração
Fonte: o autor
F7 Manter registro de todas as demandas
Oculto ( )
Descrição: O sistema deve registrar todas as demandas
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código, código
Especificação
de demandas
produtor, data, distancia, item, linha, município,
pedido, nome produtor, quantidade carga, status,
tonelada, Ração
Fonte: o autor
F8 Manter registro de todas as cargas
Oculto ( )
Descrição: O sistema deve registrar todas as cargas
Requisitos Não-Funcionais
Nome
Restrição
Categoria
15
NF 1.1 Registro de informações
O registro será composto por: Código, data, distancia,
de cargas
item, linha, município, nome integrado, pedido,
Especificação
quantidade de carga, ração, demanda, veiculo, ticket
Fonte: o autor
F9 Manter registro de todos os tickets
Oculto (X)
Descrição: O sistema deve registrar todos os tickets
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: código, data, número do Especificação
de tickets
ticket, veiculo, capacidade.
Fonte: o autor
F10 Manter registro de todos os Fabricas
Oculto ( )
Descrição: O sistema deve registrar todas as fabricas
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: código, nome, latitude,
Especificação
de fabricas
longitude, tipo, capacidade
Fonte: o autor
F11 Manter registro de todos os Logins
Oculto ( )
Descrição: O sistema deve registrar todas as login
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: código, nome, senha,
Especificação
de login
nível.
Fonte: o autor
F12 Manter registro de todas as Distancias
Oculto (X)
Descrição: O sistema deve registrar todas as distancias
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: código, distancia, nome
Especificação
de distancias
Fonte: o autor
16
F13 Manter registro de todas as Trilhas
Oculto (X)
Descrição: O sistema deve registrar todas as Trilhas
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código, azimute,
Especificação
de trilhas
latitude Inicial, Longitude Inicial, Latitude Final,
Longitude Final, nome, peso, estilo, distancia, cor,
adjacente.
Fonte: o autor
F14 Manter registro de todas as adjacentes
Oculto (X)
Descrição: O sistema deve registrar todas as adjacentes
Requisitos Não-Funcionais
Nome
Restrição
Categoria
NF 1.1 Registro de informações
O registro será composto por: Código, distancia,
Especificação
de adjacentes
nome, azimute, cor, estilo, latitude, longitude, peso,
trilha.
Fonte: o autor
3.2.2 Requisitos Suplementares
Segundo Wazlawick (2004), os requisitos suplementares são restrições colocadas
sobre como o sistema deve realizar os requisitos funcionais.
Nome
Restrição
Categoria
S1 Tipo de
As interfaces do sistema devem ser implementadas como Interface
interface
formulários acessíveis via web.
S2
A camada de persistência deve ser implementada de forma que Persistência
Armazenamento diferentes tecnologias de banco de dados possam vir a ser utilizadas
de dados
no futuro
S3 Tolerância a
Não permitir a exclusão de informações do sistema. Apenas que Confiabilidade
falhas
ocorra a ativação ou inativação de produtores e veículos.
S4 Acesso,
O sistema deve prover um meio rápido de geração de relatórios, Desempenho
consulta e
consultas e registros, não sendo tolerados mais de 20 segundo de
registro.
espera para a geração de qualquer relatório no sistema e mais de 5
segundos de espera para registro ou consulta, levando em
consideração a velocidade da internet.
17
S5 Tecnologia
O sistema deverá ser produzido em linguagem que permita a Implementação
de construção
separação em camadas e os aspectos de orientação a objetos
S6 Tecnologia
O sistema deve ser mantido em um servidor, que fica em atividade
de hospedagem
garantida em 99,6 % do tempo do dia, não podendo baixar essa
porcentagem.
Fonte: o autor
3.2.3 Casos de Uso
As grandes ações de negócio da empresa são também chamadas de casos de uso. Eles
devem descobrir as principais atividades das empresas ligadas ao sistema que será
implantado, cada caso de uso será relacionado a um conjunto de requisitos funcionais do
sistema.
Segundo Wazlawick (2011, p. 36), cada caso de uso tem por objetivo levantar
informações sobre como o sistema interage como possíveis usuários e quais consultas e
operações da informação são necessárias para que processos completos de interação sejam
verdadeiramente executados.
Nome
Importar
Atores
Usuário
demanda
Descrição
A demanda é gerada no sistema SAP-R3 aonde
exporta toda uma demanda de cargas para um dia,
após é importada para o sistema Geologe.
Gerar Carga
Usuário
O usuário vai digitar apenas a quantidade de carga
par o caminhão, total ou parcial, em algum casso
que necessite metade da carga.
Gerar Ticket
Usuário
Gerar um relatório com os ticket e os tipos de
veículos que poderão levar aquela carga.
Vincular Veiculo Usuário
O usuário vai digitar a placa do veículo para qual
ticket aquele veículo vai ser vinculado, ou seja, qual
veículo vai entregar em qual produtor.
Raio de Ação de Usuário
Visualizar em um mapa um raio de ação entre
produtores
produtores escolhe o produtor e digita o raio, um
relatório com todos os produtores neste raio é
gerado.
18
Raio de Ação a Usuário
Visualiza em um mapa um raio de ação entre
partir de fabricas
fabricas e produtores com todas os produtores neste
raio de ação da fábrica, um relatório é gerado com
todos os produtores.
Agrupar cargas
Sistema
O sistema agrupa cargas que possam ser geradas
com proximidades, cidade e comunidades de
interior, para facilitar a geração das cargas.
Distancias de
Sistema
Todas
as
menores
melhores
distância
entre
fabricas -
produtores até as fabricas levando em considerações
Produtores
algumas restrições de rotas.
Histórico de
Sistema
Relatório com entregar realizadas por veículo.
cargas por
veiculo
Fonte: o autor
3.3
FASE DE ELABORAÇÃO
3.3.1 Expansão do Caso de Uso
Um caso de uso expandido descreve detalhadamente o que ocorre, quando se está
expandindo um caso de uso é preciso proceder a um exame detalhado do processo de negócio.
3.3.1.1 Importar demanda
NOME: UC1 – Importar demanda
ATOR: Usuário
FLUXO PRINCIPAL
PASSO
DESCRIÇÃO
1
O usuário escolhe um demanda exportada do Sistema SAP R3
2
O sistema importa a demanda para aquela data.
3
O sistema identifica cada item da demanda e classificados
19
3.3.1.2 Gerar Carga
NOME: UC1 – Gerar Carga
ATOR: Usuario
FLUXO PRINCIPAL
PASSO
DESCRIÇÃO
1
O usuário escolhe uma categoria animal, tipo de ração e tipo de veículo, e seleciona um
veículo.
2
O usuário degita a quantidade da carga para ser carregada.
3
O sistema identifica o veículo, se ele é valido para aquela categoria, se a capacidade
para a quantia de carga é válida.
4
O sistema atualiza a capacidade do veiculo
5
O sistema cria um ticket
FLUXOS ALTERNATIVOS
2a – Veículo não cadastrado
2a.1 – O Administrador informa a placa, e capacidade do veículo, tipo, tipo de ração e
categoria animal.
2a.2 – O Sistema registra o novo veículo.
3a – Demanda não importada
3a.1 – Realizar o processo do UC1
Fonte: o autor
3.3.1.3 Gerar Ticket
NOME: UC3 – Gerar Carga
ATOR: Usuario
FLUXO PRINCIPAL
PASSO
DESCRIÇÃO
1
Ao incluir uma carga o sistema gera um ticket
20
2
Os tickets são impressos selecionando uma categoria anima, um tipo de veículo e um
tipo de ração
3
É gerado um arquivo PDF para impressão
FLUXOS ALTERNATIVOS
2a – Carga não gerada
2a.1 – Deve ser feito o processo do UC1.
Fonte: o autor
3.3.2 Estórias de Usuário
As Estórias de usuário são identificadas juntamente com o usuário, o que ele quer
que aconteça cada ação do sistema, ela é um atividade do SCRUM.
Titulo
CRUD Veiculo
Prioridade
Média
Prioridade
Média
Prioridade
Alta
Prioridade
baixa
Inserir, Consultar, Alterar veículos
Fonte: o autor
Titulo
CRUD tipo de veiculo
Inserir, Consultar, Alterar tipo de veiculo
Fonte: o autor
Titulo
CRUD Ração
Inserir, Consultar, alterar ração
Fonte: o autor
Titulo
CRUD Categoria Animal
Inserir, Consultar, alterar categoria animal
Fonte: o autor
21
Gerar Carga
Titulo
Prioridade
Alta
Incluir uma carga em um veiculo, que esteja apto a carregar aquele tipo de ração para o
produtor
Fonte: o autor
Gerar ticket
Titulo
Prioridade
Alta
Imprimir os tickets gerados em PDF para que possam ser entregues aos caminhoneiros
Fonte: o autor
Raio de Ação Unidades/produtor
Titulo
Prioridade
Alta
Digitar um valor para o raio e traçar um círculo ao redor do produtor/unidade identificando
todos os outros produtores dentro deste raio de ação.
Fonte: o autor
Pesquisa Por Raio
Titulo
Prioridade
Alta
Selecionar unidades e Categorias animais para saber a distância de cada unidade ao
produtor em linha reta, e identificar os produtores que ficam dentro do raio de ação de duas
ou mais unidades.
Fonte: o autor
3.3.3 Plano de Release
O plano de release demostra todas as sprints deste projeto cada uma representa um
momento de desenvolvimento do sistema, cada Sprint possui um ciclo individual mas de
processo igual durante sua execução, que pode durar de duas semanas a um mês.
Ao final de cada Sprint é feita uma reunião para que se possa ter o feedback do que
foi desenvolvido. Existem também reuniões diária para ver o que foi desenvolvido, essas
reuniões diária duram no máximo 5 minutos e são feitas no final do dia e em pé para que não
se prolonguem.
As Sprints definidas neste projeto são as seguintes:
Plano de Release
Sprint # 1
Objetivos
Conceitos
Registrar Informações Básica no sistema
Veículo, produtor, ração, demanda, unidade
22
Sprint # 2
Objetivo
Conceitos
Registrar Carga, Gerar Ticket
Veículo, Produtor, demanda, rações
Sprint # 3
Objetivo
Conceitos
Gerar Relatório de Cargas Ticket
Veículo, Produtor, demanda, rações
Sprint # 4
Objetivo
Conceitos
Sobreposição por raio
Unidade, Produtor
Sprint # 5
Objetivo
Conceito
Gerar relatório de contaminação
Produtor, Carga, Veiculo, Ração
Sprint #
Objetivo
Conceito
Indicar Rota
Trilhas, Adjacentes, produtor
3.3.4 Lista de Operações e Consultas do Sistema.
Neste passo, encontrasse uma lista de consultas e operações do sistema.
Lista de Consultas do Sistema
listarProdutores()
listarCarga()
listarVeiculos()
Listarickets()
ListarUnidades()
ListarRacoes()
ListarDemanda()
listarTickets()
Lista de Operações Do Sistema
cadastraProdutor(nome, código, latitude, longitude, silo1, silo2, município, area,
sistema)
registrarCarga(volume, veiculo, produtor)
23
cadastrarVeiculo(Placa, capacidade, tipo ração, categoria animal)
gerarTicket(Carga)
raioDeAcao(produto, unidade, latitude, longitude, raio)
cadastraRacao(nome, grupo de ração, categoria)
cadastraCategoria(nome)
cadastraGrupo(descrição)
cadastraTipoVeiculo(descrição, capacidade)
24
3.3.5 Modelo Conceitual
A figura 2 apresenta o modelo conceitual do projeto aonde estão descritos os
atributos de cada entidade do modelo logico do sistema.
Figura 2 - Modelo Conceitual
Fonte: o autor
25
3.3.6 Diagrama de Sequencia
O diagrama de sequencia tem o intuido de facilitar a identificação das operações do
sistema.
No diagrama abaixo observamos o processo de gerar a carga, desde o momento de
importar a demanda, ate gerar a carga.
Figura 3 - Diagrama de sequencia
Fonte: o autor
26
3.3.7 Diagrama de Classes de projeto
O diagrama de classes de projetos, esse diagrama define as estruturas das classes
utilizadas pelo sistema, talvez o diagrama mais importante, pois serve de base para todos os
outros diagramas.
Figura 4 - Diagrama de Classes de projeto
Fonte: o autor
27
3.3.8 Diagrama de Comunicação
O Diagrama de comunicação apresenta os objetos e suas ligações, mostrando a
implementação e descrevendo as variáveis locais utilizadas.
Figura 5 - Diagrama de comunicação
Fonte: o autor
28
3.3.9 Base de Dados
O banco de dados será armazenado em uma base de dados MySql5 oferecida pelo
própria empresa de servidor KingHost® sem acréscimo de custos.
Figura 6 - Modelo da Base de dados
Fonte: o Autor
5
MySql é um sistema de gerenciamento de banco de dados que utiliza a linguagem SQL, é um dos
bancos de dados mais usados no mundo.
29
4
DESENVOLVIMENTO DO SISTEMA
Para apresentar a necessidade do sistema, reuniões com funcionários da empresa
que atuam no departamento de transporte extensionista, foram realizadas, deste modo foram
definidos os requisitos do sistema e suas características.
Durante todo desenvolvimento do trabalho o NetBeans IDE 7.4 e um servidor
Tomcat foram utilizados para o desenvolvimento do software e também para realizar testes.
Diferentes framework foram utilizados no desenvolvimento para agilizar e facilitar.
Existem muitos pós e contras no uso de frameworks, mas acabamos optando por utilizar
alguns como Hibernate, Jasper Report, Apache POI.
4.1
O SISTEMA
Em reuniões realizadas com a BRF® avaliou as necessidades operacionais, assim
foram desenvolvidos os seguintes módulos que serão descritos nos próximos itens.
4.1.1
Modulo Fechamento de Cargas e Rotas
O Modulo de Fechamento de cargas é o mais complexo entre todos os módulos, pois
existem vários fatorem que envolvem esta funcionalidade e também a sua grande importância
no processo de entrega de ração e expedição da empresa.
O processo consiste na seguinte logica de excussão dentro da empresa, aonde existe
uma demanda de pedidos de entregas de ração, que são feitas pelos produtores com
antecedência, essa demanda é impressa e então acontece separação das entregas de ração por
grupos INICIAL, INTERMEDIARIO e FINAL. O grupo INICIAL são animais que são
recém-nascido, INTERMDIARIO são animais em faze de desenvolvimento e FINAL animais
que estão prontos para o abate ou produção de matrizes.
Também existem várias categorias animais como Frango de Corte, Peru, SVT
(Sistema vertical de Terminação), SPL (Sistema produtor de Leitão), SPO (Sistema Produtor
de Ovos) entre outros.
Assim os veículos possuem categorias de animais que são fixas, e categorias de
rações que podem ser alteradas, mas em determinas situações que consistem em que grupos
30
de rações possuem medicamentos que podem contaminar outros grupos de rações, alguns
veículos podem fazer essa transição efetuando um limpeza.
Então cada pedido da demanda é agrupado em uma carga, como por exemplo:

Um veículo com capacidade de 18 mil quilos, fará entrega para o produtor A que
receberá 8000 kg de ração inicial para porco, 10 mil quilos para o produtor B que
possui a mesma ração;

Um veículo não deve carregar rações diferentes em uma mesma carga.
Varia situações ainda podem ocorrer em uma entrega como por exemplo dois
veículos realizarem uma mesma entrega em um produtor
Esse agrupamento de cargas é feita de forma manual, o sistema auxilia essa
formação de carga, localizando produtores que estão próximos, para que o operador
identifique esses produtores próximos (vizinhos), e agrupe de uma forma mais eficiente essas
cargas, assim consegue-se algumas economias no processo.
A demanda que é gerada pelo sistema de gestão da empresa em questão e é
importada para o sistema Geologe, aonde utilizamos as bibliotecas do Apache Poi para fazer a
importação desses dados para o mesmo.
Figura 7 - Tela de importação da Demanda
Fonte: o Autor
Assim a importação é feita de forma simples pelo usuário do sistema.
Após a importação da demanda é feita então o fechamento de cargas aonde o
usuário deve escolher um grupo de ração, um categoria animal e um veículo disponível para
estas cargas, assim incluir a carga no veículo, desta forma a carga será grifada de vermelho
acusando que já foi fechada, então a página é recarregada no estado em que estava
anteriormente para que o processo possa ocorrer com agilidade, a imagem abaixo demonstra a
tela desse processo
31
Figura 8 - Tela para fechamento de cargas
Fonte: o Autor
Durante o processo de criação das cargas não é preciso saber qual veículo (placa)
irá fazer a carga, pois as cargas são entregues aleatoriamente para os caminhões, assim existe
uma tela para fazer a vinculação de um veículo com uma carga. Toda carga gerada vai possuir
um número de “Ticket” e um “Item”, o número do ticket é gerado aleatoriamente pelo sistema
Geologe e será utilizado para o fazer a vinculação com o caminhão e o item é utilizado para a
emissão da nota que é um número gerado pelo sistema de gestão da empresa.
Os veículos também são marcados com cheio quando sua capacidade chega ao
máximo, assim não podem ser mais utilizados, porem existe uma função para zerar a
capacidade destes veículos para que em caso de necessidade possam ser criadas outras cargas
com esses veículos.
Ainda é feita a impressão das cargas, aonde vários os tickets geram uma carga
inteira, esses ticket já vem pronto para ser entregue ao motorista junto com a ordem de
carregamento para efetuar a carga, no momento em que é entregue o ticket, e feita a
vinculação do veículo à carga, a imagem a seguir demonstra esse processo.
32
Figura 9 - Tela de Impressão de Cargas
Fonte: o Autor
Figura 10 - Tela de vinculação de carga
Fonte: o Autor
Após a vinculação da carga podem ser tiradas várias consultas para o gerenciamento,
com consumo médio de ração, entregas por produtor, entregas por veículo, consulta de
demandas, entre outros.
Os dados recebido por este modulo são utilizados no modulo de sanidade
apresentado no item a seguir.
33
4.1.2 Modulo Sanidade
O modulo sanidade é mais simples, este consiste em criar raios de ação de uma
fábrica de ração localizando todos os produtor ao redor desta fabrica, ou o raio de um
produtor localizando todos os produtores ao seu redor.
Este modulo também identifica produtores que receberão insumo de veículos que
sofrera troca de categoria animal na ração, assim pode-se identificar o produtor que pode estar
contaminado, localizar o veículo, e as entregas que esse veículo fez, então aplicar um raio de
ação X quilômetros nesta propriedade (o raio é definido conforme a contaminação) e
identificar as propriedades que possam ser contaminadas.
A tela abaixo mostra uma consulta que acusa um produtor com uma entrega
irregular:
Figura 11 - Veículos que entregaram no Produtor
Fonte: o Autor
34
Figura 12 - Entregas realizadas pelo veículo com possível contaminação
Fonte: O autor
Foi identificado que o produtor pode estar com contaminação, então eu posso buscar
um raio de ação neste produtor e identificar seus vizinhos, que também correm risco de
contaminação, a imagem abaixo mostra a consulta.
Figura 13 - Produtores em um Raio de 10 mil metro do produtor
Fonte: o Autor
35
A equação para o cálculo de distância é a seguinte:
Equação 1 - Calculo de Distancia
a  (cos( (90  latitudeIn icial )  180)  cos((90  latitudeIn icial )  
)
180
b  sin((90  latitudeFi nal )  
)  sin((90  latitudeIn icial )  
)
180
180
c  cos((longitudeI ncial  longitudeF inal )  
)
180
dist  6731  arccos(( a  b)  c)
Fonte: o Autor
Esta fórmula leva em consideração a terra sendo um esfera perfeita com o raio de
6371 Metros.
Para que esse modulo tenha utilidade é preciso que o modulo de carregamento de
ração seja atualizado corretamente.
4.1.3 Modulo Frigorifico
O modulo frigorifico é o mais simples deles, ele cria rotas de veículos que coletam
animais nas propriedades e levam para o frigorífico para abate, isto apenas é utilizado para um
controle de coletas e também de distância percorridas por veículos.
Figura 14 - Rotas para coleta de aves, suinos, etc
Fonte: o autor
36
4.2
ROTEIRIZAÇÃO
Os mapas da região oeste de Santa Catarina foram todos desenhado para o
desenhados em cima de imagens satélites par serem usadas no algoritmo, existem três
categoria de trilhas, ou seguimentos de mapas, principal, secundaria e terciaria cada
seguimento tem um ponto inicial e um ponto final, que são pontos de georeferenciamento e
um valor de distância, cada categoria tem definições de que tipos de veículos podem percorrer
nela, e velocidade média na estrada. Então é criada uma matriz de trilhas que são adjacentes a
outras trilhas, assim temos todos as trilhas ligadas, temos uma lista de adjacente que formam
grafos não-direcionados que segundo PREISS (p. 478). “Um grafo é um conjunto de pontos
de linha que conectam vários pontos.”
Um grado não-orientado pode ser representado pela figura abaixo:
Figura 15 - Representação de um grafo não-orientado
Fonte: O autor
A matriz de adjacentes para o grafo da figura 18:
Equação 2 - Matriz de Adjacentes

39
a
 41



 
59  26

 26  
39 41
 59
Existem diversos algoritmos de roteamento, como por exemplo o de Dijkstra, A* (AStar), Bellman-Ford, busca em largura e busca em profundidade.
A equação geral é simples:
37
Equação 3 - Chave para determinar o caminho
F G  H
Aonde segundo LESTER (2004)
“G = é o custo do movimento para se mover do ponto de início até o
quadrado determinado na malha seguindo o caminho criado para
chegar lá.
H = é o custo estimado do movimento para mover daquele quadrado
determinado até o destino final, ponto B. Isto é frequentemente
referido como a heurística, o que pode ser um pouco confuso. A razão
pela qual recebe este nome é porque isto é uma adivinhação. Nós não
sabemos realmente a distância real entre os pontos até que
encontremos o caminho, isto porque podemos ter todos os tipos de
coisas no caminho (paredes, água, etc.).”
O H é aonde acontece tudo, ele pode ser calculado de várias maneiras, uma delas é o
método de Manhattam aonde se conta o número total de nós movidos horizontalmente e
verticalmente para chegar ao no de destino.
As heurísticas que podem ser adicionadas ao algoritmo são de estradas que podem
rodar veículos de quais tipos, ir por um caminho e voltar por outro, pontes, pequenas serras
que quando o clima não permitir a passagem de veículos podem ser ignorados.
As rotas são criadas incialmente em fora do sistema, pois não foi encontrado um
melhor desempenho trabalhando junto com o servidor. Então o as rotas são geradas fora do
sistemas, após isso elas são apenas exibidas em camadas no sistema Geologe.
38
5
RESULTADOS E CONCLUSÕES
Desde a primeira versão do sistema Geologe alcançou alguns resultados
significativos na empresa em questão neste trabalho. Os resultados foram apresentado em
reuniões com diretores de transportes das unidades da BRF em Videira-SC.
Dentre várias categorias animais que a empresa possui, o software foi utilizado
apenas para o remanejo de rotas para Frango na unidade de Herval d’Oeste e os resultados
com tempo de serviço e economia foram os seguintes.
Utilizando Geologe
Dias
Pessoas
4
1
Previsão sem o uso do 60
4
sistema
Em dias de trabalho isso representa uma economia de 93 % de tempo de serviço com apenas
25 % do quadro de funcionários necessários caso não se utilizasse o sistema.
Também se obtiveram resultado econômicos no custo dos fretes com o remanejo
das rotas, muitas das rotas ficaram em unidades aonde a distância é menor que a distância
antiga, por exemplo: um veículo que pertencia a unidade de Concórdia fazia entrega em
Catanduvas, então o sistema identifica o produtor e sugere que essa entrega passe a ser de
responsabilidade da unidade de Catanduvas.
Os valores em R$ das economias realizadas para Frango não foram autorizadas a
serem divulgadas mas podemos fazer alguns cálculos simples para estimar esses ganhos.

São aproximadamente 1000 produtores para categoria frango

Com uma média de 75 km da unidade ao produtor (ida e volta)

Com o remanejo das rotas foram diminuídos de 4 à 8 km em média (alguns produtores
tem valores mais significativos).

São 8000 km que deixar de ser rodados em média.

Representam uma economia de 6 a 10 % com fretes.

Caminhões rodam menos

Economia de Combustível

Diminui índices de poluição
39
O Modulo de carregamento de ração pode agilizar em o processo de escolha de
carregamentos, em processos internos da empresa, os testes realizados com segunda versão
ainda serão realizados.
O modulo de sanidade aumenta a vigilância quanto aos riscos de contaminação,
com uma agilidade maior para o sanitarista verificar quais são os produtores naquele raio de
ação, e quais tem risco de contaminação, sem precisar fazer cálculos manuais durante sua
análise.
40
6
CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
O trabalho mostra que tecnologias de baixo custo podem trazer resultados
importantes para a indústria agropecuária, assim a tecnologia mostra que pode estar presente
para auxiliar qualquer processo do ser humano.
O sistema agilizou o processo de análise das rotas que reduziu custos tempo de
serviços e quilometragem rodada de veículos. Também pode melhorar e auxiliar o processo
de criação de cargas, tendo um controle maior de qual veículo entregou em qual produtor,
podendo conter riscos de contaminação, tendo relatórios de quantidade média de ração
consumida, por produtor, por período, e vários outros relatórios que podem ser
personalizáveis.
Para trabalhos futuros, pode-se melhorar algoritmos de roteamento, pois ainda
precisam de uma análise muito especifica e está rodando fora do servidor, assim
desenvolvendo, analisando padrões e definindo melhor as heurísticas o sistema pode auxiliar
efetivamente em uma resposta para a logística.
Com os módulos do sistema desenvolvido durante o projeto obtivesse uma grande
experiência tanto no desenvolvimento de sistemas, projetos de software e analises de
necessidades de mercado.
41
REFERÊNCIAS
Bootstrap, Disponível em: < http://getbootstrap.com/2.3.2/> acesso em 11 de nov. 2013
DEITEL, P. DEITEL, H. Java: Como Programar. São Paulo. 8ª ed. Ed. Person. 1144 p.
FERREIRA, E. EIS. D. HTML5, Curso W3C Escritório Brasil. Disponível em
<http://www.w3c.br/pub/Cursos/CursoHTML5/html5-web.pdf> Acesso em: 10 de nov. 2013.
GUOCHANG X. GPS, Theory Algorithms and Applications. Potsdam, Alemanha. 2ª ed.
Ed. Springer. 340 p.
LESTER, P. A* Pathfinding para Iniciantes. Disponível em:
<http://www.policyalmanac.org/games/aStarTutorial_port.htm> Acesso em 12 de dez. 2013.
NetBeans IDE. Disponível em: < https://netbeans.org/index_pt_PT.html> Acesso em 07 de
nov. 2013.
NETO, R.H. Curso de JSP: UFSC. Florianópolis, Santa Catarina. 1ª ed., 2002. 66 p.
NETO, O. M. Entendendo e Dominando o Java. São Paulo. 3ª ed. Ed. Digerati Book, 2009.
414 p.
PREISS, Bruno R. Estrutura de dados e algoritmos: Padrões de projeto orientados a objeto
com java ; Tradução de Elizabeth Ferreira – Rio de Janeiro. 8ª ed. Editora Campus. 560 p.
PHAM, Andrew. Scrum em ação: gerenciamento e desenvolvimento Ágil de projetos de
software. São Paulo. Editora Novatec, 2013. 287 p.
RUSSEL and NORVIG, Artificial Intelligence: A modern approach, Prentice Hall, 2010
TEMPLE, A. MELLO, R. F de. CALEGARI, D. T. SCHIEZARO, M. JSP, Servlts e J2EE.
São Paulo. 2004, p 267.
WASLAWICK, Raul. S. Análise e Projeto de sistemas de Informação Orientados a
Objetos. 2. ed. Rio de Janeiro: Elsevier, 2011.
___________, Raul. S. Análise e Projeto de Sistemas de Informação Orientado a
Objetos. 1. ed. Rio de Janeiro: Elseiver, 2004.