UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM MÓDULO PARA BUSCA DO MENOR
CAMINHO PARA O RASTREADOR GEOGRAFICO DE SANIDADE
ANIMAL
Área de Sistema de Informação
por
Fabiano Girardi
Carlos Henrique Bughi, Bel.
Orientador
Itajaí (SC), Dezembro de 2006
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM MÓDULO PARA BUSCA DO MENOR
CAMINHO PARA O RASTREADOR GEOGRAFICO DE SANIDADE
ANIMAL
Área de Sistema de Informação
por
Fabiano Girardi
Monografia apresentado à Banca Examinadora
do Trabalho de Conclusão do Curso de Ciência
da Computação para análise e aprovação.
Orientador: Carlos Henrique Bughi, Bel.
Itajaí (SC), Dezembro de 2006
DEDICATÓRIA
A meus pais e verdadeiros amigos,
Osni e Alvina.
Aos meus queridos padrinhos de batismo,
Otávio e Bernadette.
ii
AGRADECIMENTOS
A Deus pela vida, saúde e dons concedidos para que eu pudesse alcançar meus objetivos;
Aos meus pais, Osni e Alvina, e a família pela educação e valores que me ensinaram;
O meu orientador Profº. Carlos Henrique Bughi pela motivação, ensinamentos e disponibilidade
oferecida; e
A todos os amigos que contribuíram de alguma forma para que eu concluísse este trabalho.
iii
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................vi
LISTA DE FIGURAS...............................................................................vii
LISTA DE TABELAS .............................................................................viii
RESUMO....................................................................................................ix
ABSTRACT................................................................................................. x
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO ..................................................................................... 1
1.1.1 Formulação do Problema ................................................................................. 1
1.1.2 Solução Proposta ............................................................................................... 2
1.2 OBJETIVOS ........................................................................................................ 2
1.2.1 Objetivo Geral ................................................................................................... 2
1.2.2 Objetivos Específicos ........................................................................................ 2
1.3 METODOLOGIA................................................................................................ 3
1.4 ESTRUTURA DO TRABALHO ....................................................................... 3
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 4
2.1 AGRONEGÓCIO................................................................................................ 4
2.1.1 Sanidade animal ................................................................................................ 4
2.1.2 Suporte tecnológico ao Agronegócio ............................................................... 5
2.2 SISTEMA DE INFORMAÇÃO ......................................................................... 6
2.2.1 Sistemas de informações Geográficas ............................................................. 7
2.3 RASTREADOR GEOGRÁFICO .................................................................... 17
2.3.1 Aplicações Web ............................................................................................... 18
2.3.2 Webmapping.................................................................................................... 21
2.3.3 Map Server ...................................................................................................... 22
2.3.4 Map Server Guarani....................................................................................... 22
2.3.5 Apache Web Server ........................................................................................ 23
2.3.6 PHP................................................................................................................... 24
2.4 ROTEAMENTO................................................................................................ 24
2.4.1 Atributos espaciais para o problema de roteirização.................................. 25
2.4.2 Formas de representação do grafo ................................................................ 25
2.4.3 Aspectos favoráveis e desfavoráveis da roteirização ................................... 26
2.4.4 Algoritmo Escolhido ....................................................................................... 28
3 PROJETO ............................................................................................. 36
3.1 MODELAGEM DO SISTEMA........................................................................ 36
3.2 REQUISITOS .................................................................................................... 36
3.2.1 Requisitos Funcionais ..................................................................................... 37
3.2.2 Requisitos não Funcionais.............................................................................. 39
iv
3.2.3 Diagrama de Classe......................................................................................... 41
3.2.4 Diagrama de Casos de Uso ............................................................................. 42
3.2.5 Diagrama de Entidade e Relacionamento .................................................... 46
3.3 IMPLEMENTACAO ........................................................................................ 48
3.3.1 Ambiente de desenvolvimento ....................................................................... 48
3.3.2 Ferramentas utilizadas no projeto ................................................................ 48
3.3.3 Desenvolvimento do Sistema.......................................................................... 53
3.3.4 Problemas durante a implementação do projeto......................................... 62
3.3.5 Testes e Validação do Sistema ....................................................................... 62
4 TRABALHOS FUTUROS .................................................................. 63
5 CONCLUSÃO ...................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 66
A RASTREADOR GEOGRÁFICO....................................................... 69
v
LISTA DE ABREVIATURAS
ASF
CTTMAR
GIS
GPS
HTML
HTTP
IA
IP
LCA
PDF
PHP
PNG
SGBD
SI
SIG
SFSSQL
SQL
TCC
UF
UML
UNIVALI
Apache Software Foundation
Centro de Ciências Tecnológicas da Terra e do Mar
Geographic Information System
Global Positioning System
Hyper Text Markup Language
Hyper Text Transmission Protocol
Influenza aviária
Internet Protocol
Laboratório de Computação Aplicada
Portable Document Format
Hypertext Preprocessor
Portable Network Graphics
Sistema Gerenciador de Banco de Dados
Sistemas de informação
Sistema de Informação Geográfica
Simple Feature Specification for SQL
Structure Query Language
Trabalho de Conclusão de Curso
Unidade de Federação
Unified Modeling Language
Universidade do Vale do Itajaí
vi
LISTA DE FIGURAS
Figura 1. Arquitetura de sistemas de informação geográfica...............................................................8
Figura 2. Dados adicionados ao PostGIS. ..........................................................................................11
Figura 3 Tipos de Dados ....................................................................................................................12
Figura 4. Interface do sistema de Roteamento de Embarcações Arrendadadas.................................19
Figura 5. Home Page do SIPESCA....................................................................................................20
Figura 6. Arquitetura webmapping.....................................................................................................21
Figura 7. Grafo representando um conjunto de cidades.....................................................................30
Figura 8. Matriz de Adjacência ..........................................................................................................34
Figura 9. Lista de adjacência..............................................................................................................34
Figura 10. Exemplo de um grafo bidirecionado.................................................................................35
Figura 11. Requisitos funcionais do Rastreador Geográfico com o módulo proposto. .....................38
Figura 12. Requisitos não funcionais de segurança. ..........................................................................39
Figura 13. Requisitos não funcionais de usabilidade. ........................................................................39
Figura 14. Requisitos não funcionais de confiabilidade. ...................................................................40
Figura 15. Requisitos não funcionais de Software e Hardware. ........................................................40
Figura 16. Requisitos não funcionais de Manutenibilidade. ..............................................................40
Figura 17. Diagrama de classes do módulo proposto.........................................................................41
Figura 18. Diagrama de pacotes dos casos de usos............................................................................43
Figura 19. Diagrama de casos de uso do Rastreador Geográfico.......................................................44
Figura 20. Diagrama de casos de uso de segurança. ..........................................................................45
Figura 21. Diagrama de casos de uso do módulo proposto................................................................45
Figura 22. Diagrama de Entidade e Relacionamento.........................................................................46
Figura 23. Tela principal do Rastreador.............................................................................................50
Figura 24. Tela Inicial do Pgadmin. ...................................................................................................51
Figura 25. Tela Inicial do DBdesigner com as tabelas relacionadas..................................................52
Figura 26. Tela Principal do Scriptcase. ............................................................................................53
Figura 27. Tela para cadastro de Integrados. .....................................................................................54
Figura 28. Tela para cadastro do órgão responsável. .........................................................................55
Figura 29. Tela para cadastro da área de quarentena. ........................................................................55
Figura 30. Tela para cadastro de problema sanitário. ........................................................................56
Figura 31. Tela para cadastro de divisão............................................................................................56
Figura 32. Tela para cadastro de Tipos de Integrados........................................................................57
Figura 33. Tela para manter usuário programa. .................................................................................57
Figura 34. Algoritmo de Dijkstra .......................................................................................................60
Figura 35. Algoritmo de Dijkstra .......................................................................................................61
Figura 36. Interface do Sistema Rastreador Geográfico, com destaque ao menu de configuração. ..69
Figura 37. Interface do Sistema Rastreador Geográfico, com destaque ao menu mapas temáticos. .70
Figura 38. Interface do Sistema Rastreador Geográfico, com destaque ao menu de análise de
vizinhança...................................................................................................................................71
Figura 39. Interface do Sistema Rastreador Geográfico, com destaque ao menu de análise de
espacial. ......................................................................................................................................72
Figura 40. Interface do Sistema Rastreador Geográfico, com destaque a consulta espacial para
unidade de produção...................................................................................................................73
Figura 41. Interface do Sistema Rastreador Geográfico, com destaque ao menu de cálculo de
distância......................................................................................................................................74
vii
LISTA DE TABELAS
Tabela 1. Tipos espaciais do PostgreSql ............................................................................................10
Tabela 2. Lista de operadores geométricos do PostGIS.....................................................................13
Tabela 3. Funções Geométricas .........................................................................................................14
Tabela 4. Comparativo entre banco de dados existentes no mercado ................................................17
Tabela 5. Lista de caminhos 1............................................................................................................30
Tabela 6. Lista de caminhos 2............................................................................................................31
Tabela 7. Lista de caminhos 3............................................................................................................31
Tabela 8. Lista de caminhos 4............................................................................................................32
Tabela 9. Lista de caminhos 5............................................................................................................32
Tabela 10. Lista de caminhos 6..........................................................................................................32
Tabela 11. Matriz de Adjacência........................................................................................................35
viii
RESUMO
GIRARDI, Fabiano. Desenvolvimento de um módulo de busca de menor caminho para o
rastreador geográfico de sanidade animal. Itajaí, 2006. 70 f. Trabalho de Conclusão de Curso
(Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar,
Universidade do Vale do Itajaí, Itajaí, 2006.
A sanidade animal é considerada um dos pontos cruciais na manutenção das atividades de
agronegócio, quando ela se encontra fora de controle pode colocar em risco a vida dos cidadãos,
ocasionar uma brutal queda das vendas, gerar desempregos, desperdícios, diminuindo a
rentabilidade do país, e causando insegurança e medo para todos. Uma das maneiras de impedir a
expansão de uma doença infecciosa é através da criação de áreas de quarenta ou áreas de exclusão,
isolando uma determinada região que está sob suspeita de infecção. No âmbito tecnológico, o
Laboratório de Computação Aplicada da UNIVALI desenvolveu para a empresa Seara Alimentos
S/A o Sistema Rastreador Geográfico, utilizado para criar as áreas de quarentena a partir de uma
unidade de produção com suspeita de infecção e identificar as demais unidades de produção que
estejam contidas nestas áreas. Localizar as unidades existentes em uma área de quarentena não é
suficiente para impedir que a doença se alastre. Outras medidas precisam ser tomadas, como o
isolamento das estradas que passam por essas áreas, impedindo o transito de veículos com cargas
vivas. Este trabalho disponibiliza um novo módulo ao Sistema Rastreador Geográfico para calcular
a menor rota entre duas cidades, considerando a malha viária existente e realizando o desvio das
áreas de quarentena. Estas áreas de quarentena serão cadastradas pelos usuários, conforme uma
coordenada de latitude e longitude, e um raio para a sua definição. Para realizar o desvio destas
áreas em quarentena, foi empregado o algoritmo de Dijkstra. Este algoritmo irá considerar todas as
vias que não estão envolvidas em uma área de quarentena. A visualização da rota calculada dar-se-á
através de mapas dinâmicos na Web utilizando a ferramenta de mapas Mapserver. Diversas
atividades foram cumpridas para a construção do módulo, dentre elas pode-se destacar o estudo de
outros algoritmos existentes para o cálculo de menor caminho, a implementação do algoritmo de
Dijkstra, a preparação das cartas existentes de malha viária e as alterações no Sistema Rastreador
Geográfico para atender as necessidades do módulo. Espera-se com este trabalho dar mais um
passo no controle das doenças infecciosas, mantendo o agronegócio como um dos mercados mais
importantes para a economia brasileira.
Palavras-chave: Agronegócio. Map Server. Sistemas Rastreadores Geográficos.
ix
ABSTRACT
The animal heath is considered one of the crucial points in the maintenance of the agribusiness
activities, when it gets out of control can put in risk the citizens' life, to cause a brutal fall of the
sales, to generate unemployments, resource wastes, reducing the profitability of the country, and
causing insecurity and fear for all. One in the ways of impeding the expansion of an infectious
disease is through the creation of areas of quarantine or exclusion areas, isolating a certain area
that is under infection suspicion. In the technological extent, the Laboratory of Applied
Computation of UNIVALI developed for the company Seara Alimentos S/A the Geographical
Tracker System, used to create the quarantine areas starting from an unit of production with
infection suspicion and to identify the other units of production to be contained in these areas. To
locate the existent units in a quarantine area is not enough to impede that the disease spreads.
Another measure they need to do, as the isolation of the highways that they go by those areas,
impeding it of vehicles with alive loads. This work makes available a new module to the
Geographical Tracker System to calculate smallest route between two cities, considering the
existent road mesh and accomplishing the deviation of the quarantine areas. These quarantine
areas will be registered by the users, according to a latitude coordinate and longitude, and a ray
for its definition. To accomplish the deviation of these areas in quarantine, the algorithm of
Dijkstra was used. This algorithm will consider all the roads that are not involved in a quarantine
area. The visualization of the calculated route will feel through dynamic maps in the Web using the
tool of maps Mapserver. Several activities were accomplished for the construction of the module,
among them it can stand out the study of other existent algorithms for the calculation of smaller
road, the implementation of the algorithm of Dijkstra, the preparation of the existent letters of road
mesh and the alterations in the Geographical Tracker System to assist the needs of the module. It is
expected with this work to give one more step in the control of the infectious diseases, maintaining
the agribusiness as one of the most important markets for the Brazilian economy.
Keywords: Agribusiness. Map Server. System Rastreador Geografico.
x
1 INTRODUÇÃO
No Brasil, a área de agronegócio é responsável por cerca de 1/3 do produto interno bruto,
empregando 38% da mão de obra e sendo responsável por 36% das nossas importações. Faz parte
do agronegócio toda empresa que produz, processa e distribui produtos agropecuários. A
globalização de mercados faz com que cada vez mais exista a necessidade de inter-relação entre
essas empresas e que se invista em novas tecnologias de produto, processo e gestão. Apesar do
mercado criado em torno do agronegócio parecer solidificado, existem diversos fatores que podem
contribuir com o seu declínio, entre eles, podem-se destacar fatores políticos, como embargos
fiscais e mudança de política nacional, e ainda fatores naturais, como condições meteorológicas e
problemas de sanidade animal.
Uma maneira de tentar auxiliar a sanidade animal isolando e desviando de áreas
contaminadas é através do rastreamento, identificando plantéis infectados e efetuando o isolamento
da área para poder erradicar a doença. O desvio de rotas convencionais também é um fator a ser
considerado, pois cargas vivas transportadas pelos caminhões podem entrar em uma área de
quarentena ou de exclusão, infectando animais saudáveis, transmitindo à doença a diante em outras
áreas livres.
Para atender esta necessidade, foi necessário incluir um novo módulo ao Ratreador
Geográfico para calcular e demonstrar um caminho entre dois pontos desviando das áreas em
quarentena agregando valor à ferramenta.
Nos próximos projetos, esse módulo também pode ser utilizado juntamente com um
sistema GPS (Global Positioning System), e um sistema embarcado nos caminhões onde que o
condutor do veículo possa desviar das áreas em risco, porém essa parte não será implementada neste
TCC.
1.1 PROBLEMATIZAÇÃO
1.1.1
Formulação do Problema
O sistema rastreador geográfico desenvolvido pelo LCA não possui um módulo para
efetuar o calculo na busca do menor caminho entre dois pontos distintos desviando da área de
exclusão. Também utiliza o banco de dados relacional do Oracle, que não possui instalado o
cartucho espacial instalado que dá suporte a manipulação de dados espaciais, dificultando a busca e
armazenamento de informações geográficas.
Outra restrição é que o banco de dados Oracle não é um produto livre, todas as conexões
são cobradas, e o custo para a instalação e configuração do seu cartucho espacial é bem elevado,
desta forma o rastreador deixa de ser acessível para outras empresas do ramo.
Sendo assim este será migrado para o banco de dados PostgreSQL/PostGis, sendo o mais
indicado por possuir as características desejadas e por estar em conformidade com os anseios do
LCA.
1.1.2
Solução Proposta
Adicionar um módulo ao Rastreador Geográfico para determinizar o menor caminho entre
dois pontos distintos, desviando de uma área exclusão e migrar para o banco de dados
PostgreSQL/PostGis, pois este banco possui o cartucho espacial disponível para a instalação
gratuitamente.
1.2 OBJETIVOS
1.2.1
Objetivo Geral
O objetivo geral deste trabalho é desenvolver um módulo para o rastreador geográfico do
LCA para o calculo do menor caminho entre dois pontos com desvio de áreas de exclusão.
1.2.2
Objetivos Específicos
•
Estudar, verificar a documentação e interagir com Rastreador Geográfico atual;
•
Criar um novo modelo para o Rastreador Geográfico baseando no modelo já existente;
•
Implementar um módulo de busca do menor caminho entre dois pontos distintos
desviando de áreas de exclusão;
•
Migrar o rastreador geográfico para o SGBD PostgreSQL/PostGis;
•
Alterar o módulo existente da área de exclusão permitindo o armazenamento da área
consultada; e
2
•
Testar e validar o novo módulo utilizando o framework Map Server Guarani.
1.3 Metodologia
Para alcançar os objetivos deste trabalho foi seguida a seguinte metodologia:
• Levantamento Bibliográfico: Estudo dos conceitos relacionados ao agronegócio,
sanidade animal, sistemas de informação, roteamento, rastreador geográfico, webmapping e dos
padrões e normas para estas áreas de conhecimento.
• Análise: Criação dos diagramas do sistema a fim de mostrar toda a colaboração e trocas
de mensagens entre o Rastreador e o banco de dados.
• Implementação: desenvolvimento de um novo módulo para o Rastreador Geográfico.
1.4
Estrutura do trabalho
O trabalho está estruturando em quatro capítulos:
1. Introdução: Na introdução terá a formulação do problema, a solução proposta e os
objetivos gerais e específicos;
2. Fundamentação Teórica: A fundamentação teórica trata de capítulos, sobre agronegócio,
roteamento, sanidade animal, sistemas de informações geográficas, geoprocessamento,
banco de dados geográfico, aplicações web com software livre;
3. Projeto: O projeto é composto pelas etapas de análise de requisitos funcionais e não
funcionais, modelagem conceitual com apresentação das principais funcionalidades,
diagramas do projeto, diagrama de classes e definição do algoritmo que será utilizado.
4. Conclusão: São todas as considerações sobre o projeto, as facilidades, e dificuldades
encontradas no decorrer do trabalho acadêmico, melhores práticas para o
desenvolvimento.
3
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta o estudo feito para contemplar o novo módulo do rastreador
geográfico. A fundamentação teórica encontra-se subdivida em agronegócio, sistema de
informação, rastreador geográfico e roteamento, que são assuntos relevantes ao Reastreador
Geográfico.
2.1 AGRONEGÓCIO
No cenário econômico atual é comum deparar não apenas com agricultores ou pessoas
ligadas diretamente ao campo, mas com diversos membros da sociedade sofrendo os reflexos da
falta de sanidade animal que se destaca principalmente no universo do agronegócio (COSTA,
2006).
A falta de investimentos e incentivos por parte dos governos tem influenciado não somente
as pessoas ligadas diretamente à atividade, mas a sociedade em geral já que através deste setor
movimentam-se setores como o da indústria e comércio (ibiden).
Dois exemplos mais comuns de adversidades são: a gripe do frango e febre aftosa, quem têm
mostrado seus efeitos em nossas exportações, criando barreiras nas negociações com o mercado
internacional, fechando-se as oportunidades de negócios conseguidas através da globalização.
Quando ocorrem focos dessas doenças é necessário criar uma área de isolamento a fim de
fazer análises laboratoriais na tentativa de erradicar a doença. Essas áreas isoladas ou áreas de
quarentena podem estar disponíveis para visualização e interação em mapas na internet.
O rastreador geográfico é uma dessas ferramentas, ele foi desenvolvido a partir de uma
iniciativa privada, sendo solicitada pela empresa Seara Alimentos S.A sendo um exemplo que a
maioria das empresas no ramo de corte de carnes investem cada vez mais em tecnologia, a fim de
administrar suas unidades de produção e a qualidade de seus produtos e serviços.
2.1.1
Sanidade animal
Os agentes de doenças animais prejudicam a população provocando doenças que são
chamadas de zoonoses, ou seja, as doenças que se transmitem dos animais vertebrados ao homem.
Elas representam uma grande ameaça, pois além de afetarem a saúde humana, diminuem a
produtividade dos rebanhos e reduzem a disponibilidade de alimentos saudáveis para a população
(PITUCO, 2001).
Para examinar a importância da saúde animal, o ser humano deve considerar a definição de
saúde da Organização Mundial da Saúde como um guia. “Saúde não é a mera ausência de doença
ou injúria, é um estado de completo bem estar físico, mental e social”. A Saúde Pública Veterinária
contribui diretamente para alcançar este objetivo, pois “Compreende todos os esforços comunitários
que influenciam e são influenciados pela Medicina Veterinária e Ciência aplicada para a prevenção
de doença, proteção da vida, e promoção do bem estar e eficiência do homem” e permite um campo
de trabalho ilimitado, ao participar no estudo da inter–relação de doença e saúde no homem e
animais (ibiden).
Em relação ao agronegócio, os problemas sanitários influenciam diretamente nas
exportações, devido ao fechamento dos mercados ocasionado pela insegurança dos clientes.
2.1.2 Suporte tecnológico ao Agronegócio
O avanço do setor agrícola brasileiro tem incentivado a utilização e aperfeiçoamento de
técnicas e ferramentas de gestão, fato que deve ser avaliado sob o ponto de vista da pressão exercida
pelos custos de produção, o que tem levado várias empresas rurais a priorizarem a redução dos
gastos somando-se a busca incessante por melhores índices de produtividade e conseqüentemente
determinando a sobrevivência em um mercado altamente competitivo e inovador considerando-se o
grande volume de novos produtos inseridos no mercado atual, causando a diminuição dos ciclos de
vida de inúmeras culturas em detrimento da diversificação da oferta e exigência da demanda por
alimentos mais saudáveis, acessíveis e seguros (OLIVEIRA NETO, 2004).
Espera-se que a disseminação da utilização da informação contribua efetivamente para um
progresso da administração do agronegócio brasileiro, principalmente agora, com a afirmação da
internet que auxilia as atividades agropecuárias fornecendo dados e informações ao planejamento
(ibiden).
Contudo, a atração de consumidores tem sido a máxima dos complexos agroindustriais o
que nos coloca uma importante questão: Como aumentar o potencial competitivo garantindo o
crescimento sustentável das atividades agropecuárias? É clara a necessidade da efetivação de
profissionais capazes de gerir com visão global as decisões no meio rural, entretanto, a capacidade
5
de dominar a informação com qualidade, garantindo a transformação dessas em conhecimento real e
estratégia de ação possibilitará a criação de planos táticos e operacionais elaborados a partir das
necessidades dos mais diversos consumidores mundiais inseridos em um ambiente de concorrência
efetivamente acirrada (ibiden).
Ao concluir, espera-se que a união da administração e da ciência que concentram
ferramentas capazes de inserir a eficiência no auxílio para tomadas de decisões, seja capaz de
impedir o crescimento da concorrência sobre a fatia de mercado do agronegócio, mantendo uma
aproximação do conhecimento gerado pelo processamento das informações aos interesses das
pessoas envolvidas, melhorando a qualidade dos nossos produtos e serviços em longo prazo.
2.2 SISTEMA DE INFORMAÇÃO
O crescimento da internet, a globalização do comércio e ascensão das economias da
informação deu um novo papel aos sistemas de informação (SI) nos negócios e na administração. A
tecnologia de internet está servindo de base a novos modelos empresariais, novos processos de
negócios e novos modos de distribuir conhecimento (LAUDON e LAUDON, 2004).
O termo sistema da informação serve para designar o conjunto de recursos tecnológicos e
computacionais para a geração e uso da informação, o seu principal benefício é a capacidade de
melhorar a qualidade e disponibilidade de informações e conhecimentos importantes para a empresa
(REZENDE, 2000).
Um SI também pode ser definido tecnicamente como um conjunto de componentes interrelacionados que coleta, processa, armazena e distribui informações destinadas a apoiar a tomada de
decisões, a coordenação e o controle de uma organização. Além de dar suporte para tomada de
decisões, a coordenação e ao controle esses sistemas também auxiliam os gerentes e trabalhadores a
analisar problemas, visualizar assuntos complexos e criar novos produtos. Os sistemas de
informação contêm informações sobre pessoas, locais e coisas significativas para a organização ou
para o ambiente que a cerca. No caso, informação quer dizer dados apresentados em uma forma
significativa e útil para os seres humanos. Dados, ao contrário, são correntes de fatos brutos que
representam eventos que estão ocorrendo nas organizações ou no ambiente físico, antes de terem
sido organizados e arranjados de uma forma que as pessoas possam entendê-los e usá-los
(LAUDON e LAUDON, 2004).
6
2.2.1
Sistemas de informações Geográficas
O termo sistemas de informação geográfica (SIG) é aplicado para sistemas que realizam o
tratamento computacional de dados geográficos. A principal diferença de um SIG para um sistema
de informação convencional é sua capacidade de armazenar tanto os atributos descritivos como as
geometrias dos diferentes tipos de dados geográficos. Assim, para cada lote num cadastro urbano,
um SIG guarda, além de informação descritiva como proprietário e valor do IPTU, a informação
geométrica com as coordenadas dos limites do lote. Com um (SIG) é possível inserir e integrar,
numa única base de dados, informações espaciais provenientes de meio físico-biótico, de dados
censitários, de cadastros urbano e rural, e outras fontes de dados como imagens de satélite, e GPS
(CÂMARA, 2001).
Oferecer mecanismos para combinar as várias informações, através de algoritmos de
manipulação e análise, bem como para consultar, recuperar e visualizar o conteúdo da base de
dados geográficos. Os componentes de um SIG estão mostrados na Figura 1. No nível mais
próximo ao usuário, a interface homem-máquina define como o sistema é operado e controlado.
Esta interface pode ser orientada ao ambiente de navegação da Internet, quanto baseada em
linguagens de comando como Spatial SQL (EGENHOFER, 1994).
No nível intermediário, um SIG deve ter mecanismos de processamento de dados espaciais.
A entrada de dados inclui os mecanismos de conversão de dados. Os algoritmos de consulta e
análises espaciais incluem as operações topológicas, álgebra de mapas, estatística espacial,
modelagem numérica de terreno e processamento de imagens (ibiden).
Cada sistema, em função de seus objetivos e necessidades, desenvolve um SIG de forma
distinta, mas todos os subsistemas citados devem estar presentes dentro do mesmo.
7
Figura 1. Arquitetura de sistemas de informação geográfica.
Fonte: CÂMARA et al, (2000)
Do ponto de vista da aplicação, o uso de sistemas de informação geográfica (SIG) implica
em escolher as representações computacionais mais adequadas para capturar a semântica de seu
domínio de aplicação. Do ponto de vista da tecnologia, desenvolver um SIG significa oferecer o
conjunto mais amplo possível de estruturas de dados e algoritmos capazes de representar a grande
diversidade de concepções do espaço.
O nome SIG é muito utilizado e em muitos casos é relacionado com geoprocessamento.
Entretanto, geoprocessamento é o conceito mais abrangente e representa qualquer tipo de
processamento de dados georreferenciados, enquanto um SIG processa dados gráficos e não
gráficos (alfanuméricos) com ênfase a análises espaciais e modelagens de superfícies (SPRING,
2003).
2.2.1.1
SGBD Geográfico
Os sistemas de computação possuem os mais diversos tipos de informações, em diferentes
formatos e para uma infinidade de propósitos. Para nos auxiliar na tarefa de organizar tanta
diversidade de informações, existem os SGBDs (Sistemas Gerenciadores de Bancos de dados)
(SILBERSCHATZ, 1999).
Cada tipo de aplicação necessita de um tratamento adequado para os dados que servirão de
auxílio para a geração de informações realmente úteis. A diferença entre um dado e uma informação
está relacionada com a forma a qual se enxerga o conteúdo, ou com a forma que uma aplicação nos
8
apresenta. Se o que estamos vendo for válido ou tiver algum sentido prático, se trata de uma
informação. Dados podem ser considerados fragmentos de informação, que sozinhos não ajudam
muito, mas que são importantes para a construção da mesma. De uma forma técnica, informação é o
agrupamento lógico de dados correlatos (CÂMARA, 2005).
Em um SIG, a camada de armazenamento consiste na primeira fase do desenvolvimento.
Neste momento, o mundo real será analisado e transformado em dados, organizados em tabelas
espaciais. Mais do que em qualquer outro tipo de aplicação, em um SIG, o banco de dados é
verdadeiramente o alicerce. É através da base de dados que se pode esperar muito ou pouco dos
recursos a serem oferecidos por um sistema geográfico (ibiden).
Segundo Silberschatz et al. (1999), os bancos de dados espaciais armazenam informações
relacionadas a localizações espaciais e fornecem suporte eficiente para consultas e indexações com
base nessas localizações espaciais. O diferencial da utilização de bancos de dados espaciais são
comandos e ações especiais que em bancos de dados comuns não são possíveis.
Atualmente, existem três principais extensões comerciais disponíveis no mercado para tratar
dados geográficos: Oracle Spatial, IBM DB2 Spatial Extender e Informix. No universo do código
aberto, os principais concorrentes são o MySQL e o PostgreSQL. Porém, destes dois, o PostGIS,
que é a extensão espacial do PostgreSQL, vem se firmando como o padrão aberto para
armazenamento e manipulação de dados espaciais (CÂMARA, 2005).
Todas as principais extensões espaciais do mercado, baseiam-se nas especificações do
OpenGIS, porém, apresentam variações relevantes entre os modelos de dados, semântica dos
operadores espaciais, mecanismos de indexação e esquema e sintaxe da SQL extendida com tipos
espaciais. O OpenGIS é a entidade responsável pela padronização dos sistemas que envolvem dados
espaciais e temporais (ibiden).
A base de dados escolhida para o desenvolvimento deste projeto foi o PostgreSQL com a
extensão PostGIS. A principal razão desta escolha está fundamentada no custo e na quantidade de
recursos oferecidos por este banco.
9
2.2.1.2
Dados Espaciais
Existem diversos tipos de dados espaciais, e cada um deles pode ser aplicado para armazenar
diferentes tipos de objetos e representações do mundo real. A escolha do tipo depende dos
resultados que queremos alcançar, ou, que tipo de informações é necessário recuperar.
PostGIS, como visto, é a extensão espacial para o PostgreSQL. O PostgreSQL, por padrão,
já conta com uma boa quantidade de tipos espaciais primitivos, porém com escassas funções e
operadores, tornando trabalhosa a implementação de sistemas mais completos. A Tabela 1, mostra
os tipos de dados espaciais suportados atualmente pelo PostgreSQL.
Tabela 1. Tipos espaciais do PostgreSql
Nome
Armazenamento
Point
Line
16 bytes
32 bytes
Lseg
Box
Path
32 bytes
32 bytes
16+16n bytes
Path
Polygon
16+16n bytes
40+16n bytes
Circle
24 bytes
Representação
Ponto no plano
Linha infinita (não
implementada
completamente)
Segmento de linha finito
Caixa retangular
Caminho fechado(
semelhante ao polígono)
Caminho aberto
Polígono (similar ao caminho
fechado)
Círculo
Decrição
(x,y)
((x1,y1),(x2,y2))
((x1,y1),(x2,y2))
((x1,y1),(x2,y2))
((x1,y1),....)
[(x1,y1),....]
((x1,y1),....)
<(x,y),r> centro e raio
Fonte: Adaptado de POSTGRESQLSITE (2006).
Com o PostGIS, alguns tipos foram especializados para oferecer um melhor controle sobre
suas características. A Figura 2 mostra os dados adicionados ao PostGIS.
10
Figura 2. Dados adicionados ao PostGIS.
Fonte: Adaptado de CÂMARA et al, (2000)
Cada um dos tipos pode ser usado para representar não só objetos, mas também fenômenos
climáticos, como estações do ano e aspectos políticos, e focos de doenças. Os dois tipos que irão ser
utilizados pelo Rastreador Geográfico, podem ser observados na Figura 3.
11
Figura 3 Tipos de Dados
Fonte: Adaptado de CÂMARA et al, (2000)
2.2.1.3
Operadores Geométricos
Um dos destaques da extensão PostGIS é o grande número de operadores e funções
geométricos. No caso dos operadores, eles nos permitem recuperar diversos tipos de informações
úteis, como distância, proximidade, interseção, sentido, posição vertical ou horizontal, entre outros.
A lista completa dos operadores do PostGIS está na Tabela 2.
12
Tabela 2. Lista de operadores geométricos do PostGIS.
Operador
+
*
/
#
#
@-@
@@
##
<->
&&
Descrição
Exemplo
Translação
box ‘(( 0,0 ), (1,1))’ + point ‘(2.0,0)‘
Translação
Box ‘((0,0), (1,1))’ - point ‘(2.0,0)‘
Escala / rotação
box ‘((0,0), (1,1))’ * point ‘(2.0,0)‘
Escala / rotação
box ‘((0,0), (2,2))’ / point ‘(2.0,0)‘
Ponto de intercessão entre caixas
‘((1,-1), (-1,1))’ # ‘ (( 1,1) (-1,-1))‘
Número de pontos em um caminho ou # ‘((1,0), (0,1), ( -1,0))‘
polígono
Comprimento ou circunferência
@-@ path ‘(( 0,0 ), ( 1,0 ))‘
Centro
@@ circle ‘(( 0,0 ), 10 )‘
Ponto mais próximo do primeiro
parâmetro em relação ao segundo
Distância entre
point ‘(0,0)’ ## lseg ‘((2,0), (0,2))’
Sobrepõe?
circle ‘((0,0), 1)’ < - > circle ‘((5,0) 1)’
&<
Estendido a direita de?
&>
Estendido a esquerda de?
<<
>>
<^
>^
?#
Fica a esquerda de?
box ‘((0,0), (1,1))’ && box ‘((0,0),
(2,2))’
box ‘((0,0), (1,1))’ &< box ‘((0,0),
(2,2))’
box ‘((0,0), (3,3))’ &> box ‘((0,0),
(2,2))’
circle ‘((0,0), 1)’ << circle ‘((5,0) 1)’
Fica a direita de?
circle ‘((5,0), 1)’ >> circle ‘((0,0) 1)’
???|
?|
?- |
?||
É paralelo?
@
-=
Está abaixo?
circle ‘((0,0), 1)’ <^ circle ‘((0,5) 1)’
Está acima?
circle ‘((0,5), 1)’ >^ circle ‘((0,0) 1)’
Interceptam-se?
É horizontal?
lseg ‘((-1,0), (1,0))’ ?# box ‘((-2,-2)
(2,2))’
?- lseg ‘((-1,0), (1,0))’
Está horizontalmente alinhado?
point ‘(1,0)’ ?- point ‘(0,0)’
É vertical?
?| lseg ‘((-1,0),(1,0))’
Está verticalmente alinhado?
point ‘(0,1)’ ?| point ‘(0,0)’
É perpendicular?
Contém?
lseg ‘((0,0),(0,1))’ ?-| lseg ‘((0,0),
(1,0))’
lseg ‘((-1,0),(1,0))’ ?| | lseg ‘((1,2),(1,2))’
circle ‘((0,0), 2)’ - point ‘( 1,1 )’
Contido dentro ou em?
point ‘(1,1)’ @ circle ‘((0,0),2)’
Mesmo como?
polygon ‘((0,0),(1,1))’ -=
Fonte: Adaptado de Postgresqlsite (2006).
2.2.1.4
Funções Geométricas
Para completar o conjunto de ferramentas que o PostGIS nos oferece, resta mostrar as
funções disponíveis e o que elas podem fazer. O PostGIS conta hoje com um dos melhores celeiros
de funções geométricas dentre todos os SGBDs espaciais conforme na Tabela 3.
13
Tabela 3. Funções Geométricas
Função
Tipo de Retorno
Descrição
area (object)
Box_intersect (box,
Precisão dupla
Caixa
Área
Intercessão com caixa
box)
Center (object)
Diameter (circle)
Ponto
Precisão dupla
Precisão dupla
Centro
Diâmetro do círculo
Tamanho vertical da caixa
Height (box)
Isclosed (path)
TRUE ou FALSE
TRUE ou FALSE
É caminho fechado?
É caminho aberto?
Isopen (path)
Precisão Dupla
Comprimento
Length (object)
Npoints (path)
Inteiro
Inteiro
Número de pontos
Número de pontos
Npoints (polygon)
Caminho
Número de pontos
Pclose (path)
Caminho
Fecha o caminho
Popen (path)
Caminho
Abre o caminho
Radius (circle)
Precisão Dupla
Tamanho horizontal da caixa
Exemplo
area (box ‘ ((0,0) , (1,1)) ’ )
box_intersect (box
‘((0,0),(1,1))’ ,
box ‘((0.5,0.5),(2,2)) ‘)
center (box ‘((0,0),(1,2)) ‘)
diameter(circle ‘((0,0), 2.0)
’)
height (box ‘((0,0), (1,1)) ‘)
isclosed (path ‘ ((0,0) ,
(1,1), (2,0))’)
isopen (path ‘ [ (0,0),(1,1) ,
(2,0)] )
length (path ‘((-1,0),(1,0)) ‘)
npoints (path ‘ [(0,0),(1,1),
(2,0)] ‘)
npoints (polygon ‘((1,1),
(0,0)) ‘)
pclose (path
‘[(0,0),(1,1),(2,0)] ‘)
popen (path ‘
((0,0),(1,1),(2,0)) ‘)
radius (circle ‘((0,0), 2.0) ‘)
Fonte: Adaptado de Postgresqlsite (2006).
Usando os operadores certos, é possível recuperar informações como o comprimento de
cada rua cadastrada na tabela de ruas, a exemplo deste projeto. Veja a instrução SQL que faz isso:
• SELECT name, length(GEOM) AS comprimento FROM RUAS;
O suporte aos operadores e funções geométricas é fornecido através da integração do
PostGIS com a biblioteca GEOS (Geometry Engine Open Source). Essa biblioteca é uma tradução
da API Java JTS para a linguagem C++. (POSTGRESQLSITE,2006).
2.2.1.5
Estrutura do PostGis
Por ser uma extensão do PostgreSQL, o PostGIS necessita de alguns artifícios para controlar
suas características geométricas que originalmente não fazem parte do banco de dados padrão.
Essas características envolvem os sistemas de referência de coordenadas e as propriedades dos tipos
espaciais estendidos. Por isso, sempre que for criado um novo banco de dados espacial, o PostGis
criará automaticamente duas tabelas. São elas:
SPATIAL_REF_SYS
GEOMETRY_COLUMNS
14
Essas tabelas precisam ser entendidas para que seu propósito, que é de padronizar escalas de
medidas, seja cumprido. É também uma forma de garantir, que entre outras aplicações, as
informações sejam tratadas com a mesma precisão de escalas, e respeitando a particularidade de
cada tipo. Segue abaixo uma relação das tabelas padrão do PostGIS.
SPATIAL_REF_SYS
Responsável por garantir o intercâmbio dos dados contidos em tabelas espaciais doPostGIS,
a tabela spatial_ref_sys, possui os seguintes campos. (POSTGRESQLSITE,2006)
• SRID - INTEGER NOT NULL PRIMARY KEY
• AUTH_NAME - VARCHAR(256)
• AUTH_SRID - INTEGER
• SRTEXT - VARCHAR(2048)
• PROJ4TEXT - VARCHAR(2048)
O primeiro campo serve para garantir a unicidade da referência e impedir que exista
conflitos entre esses sistemas. O segundo campo é uma referência descritiva para o sistema de
referência geográfica. O campo AUTH_SRID serve como chave estrangeira para fazer referência à
todas as informações contidas neste registro. Já o campo SRTEXT contém as normas e descrições
que realmente são usadas pelo sistema do PostGIS. O último campo armazena informações sobre as
transformações necessárias para migrar deste sistema de referência, para outros.
GEOMETRY_COLUMNS
Serve para controlar os tipos geográficos válidos para o PostGIS. Essa tabela também é
responsável por ligar cada tipo espacial utilizado, com o seu sistema de referência nativo. Segue
uma descrição desta tabela.
• F_TABLE_CATALOG - VARCHAR(256) NOT NULL
• F_TABLE_SCHEMA - VARCHAR(256) NOT NULL
• F_TABLE_NAME - VARCHAR(256) NOT NULL
15
• F_GEOMETRY_COLUMN - VARCHAR(256) NOT NULL
• COORD_DIMENSION - INTEGER NOT NULL
• SRID - INTEGER NOT NULL
• TYPE VARCHAR(30) NOT NULL
Os quatro primeiros campos guardam a referência à tabela onde o tipo é empregado e o
nome dado à coluna. O quinto campo indica em quantas dimensões foi empregado o tipo espacial.
O sexto campo é a chave estrangeira responsável por ligar o campo empregado ao registro local.
Deve-se fazer referência no momento em que dados são inseridos na tabela que contém o campo em
questão. O último campo descreve o nome do tipo empregado. (POSTGRESQLSITE, 2006).
Depois de instalado o PostGIS sobre o PostgreSQL, este assume as características de um
banco de dados geográfico completo. Por este motivo, cada novo banco criado, assumirá alguns
objetos padrões além das tabelas de auxílio discutidas anteriormente. Novas funções e operadores
também compõem os objetos criados automaticamente. Isso acontece porque o PostgreSQL define
seu formato padrão para lidar com informações espaciais, mas se necessário, é possível criar bases
de dados convencionais, bastando indicar esta opção no momento da criação do novo banco.
(ibiden).
2.2.1.6
Comparativo com outros bancos no mercado
Em comparação com outros bancos de dados espaciais, podemos notar que o PostGIS possui
todas as características dos melhores produtos disponíveis. Veja a tabela abaixo:
16
Tabela 4. Comparativo entre banco de dados existentes no mercado
Recurso
Oracle Spatial
Tipos Especiais
Indexação
Espacial
Operadores
topológicos
Operadores de
Conjunto
Operadores de
Conjunto Buffer
Region
Transformação
entre sistemas
de coordenadas
Tabela de
metadados das
colunas
geométricas
SFSSQL
R tree e Quadri
Tree
Matriz 9
interseções
Sim
PostGreSQL com
Tipos Geométricos
Tipos Simples
R-Tree nativa ou Rtree sobre GIST
Não
Não
PostGreSQL com MySql
PostGis
SFSSQL
SFSSQL
R-Tree sobre GIST R-Tree
Matriz 9 interseções Em
DE
desenvolvimento
Sim
Em
desenvolvimento
Sim
Em
desenvolvimento
Sim
Não
Sim
Não
Sim
Não
Sim (diferente
do OGIS)
Não
Sim (conforme
OGIS)
Não
Fonte: Adaptado de Postgresqlsite (2006).
2.3 RASTREADOR GEOGRÁFICO
O Rastreador Geográfico é um sistema de informações para o monitoramento e
rastreabilidade geográfica de ocorrências de doenças junto às áreas de produção animal, baseado em
internet, que visa dar suporte ao planejamento preventivo e ao apoio à decisão em situações
emergenciais, possibilitando o rápido estabelecimento de medidas de sanidade em nível empresarial
e governamental.
O conhecimento adquirido pelo Laboratório de Computação Aplicada da UNIVALI sobre
sistemas de informação com suporte geoespacial permite que o assunto seja abordado sob a
perspectiva exploratória. Ou seja, não apenas se tratando da implementação de um sistema, mas sim
da prospecção e emprego de novas concepções metodológicas e tecnológicas.
Com base nisso, propõe-se à criação de um novo módulo ao Sistema Rastreador Geográfico
que permita não somente a visualização das áreas de interdições como também a criação de rotas
alternativas de tráfego para os veículos de transporte de carga das empresas a fim de disponibilizar a
17
rota de navegação desses veículos evitando que os mesmos entrem nas áreas de exclusão. Este novo
módulo terá por finalidade demonstrar o caminho de menor custo entre dois pontos distintos,
desviando da área de exclusão ou área de quarentena.
Mais informações a respeito do Rastreador Geográfico do LCA encontra-se no Apêndice A.
2.3.1
Aplicações Web
O volume e a complexidade de conteúdos representados na Web fazem com que
encontremos inúmeros formatos para organizar e estruturar a informação. A liberdade oferecida
pela Web dificulta a atividade de definição de padrões. A W3C - World Wide Web Consortium é
um exemplo de organização que trabalha em prol do desenvolvimento de tecnologias para uso
completo e eficaz do potencial da Web (especificações, guidelines, software, ferramentas).
As aplicações Web tem sido cada vez mais utilizadas para a interação com os usuários,
principalmente na área de webmapping. Segue abaixo dois exemplos de aplicçaões que utilizaram
dessas tecnologias e que foram desenvolvidos pelo LCA.
Tecnologia Opensource para Rastreamento Online de Veículos Monitorados Via
Satélite.
Este trabalho apresenta como tecnologia OpenSource, pode ser utilizada no mapeamento e
controle de posições de veículos. Especificamente, descreve a arquitetura de um sistema para
recepção via email da informação de posição; e apresentação desta informação via web através de
mapas dinâmicos. Este sistema é designado de rastreamento online, e encontra-se funcional, sendo
utilizado pelo Grupo de Estudos Pesqueiros do Centro de Ciências Tecnológicas da Terra e do Mar,
da Universidade do Vale do Itajaí.
18
Figura 4. Interface do sistema de Roteamento de Embarcações Arrendadadas.
Fonte: LCA (2006).
As criações das imagens desse sistema foram feitas por um script PHP armazenado no
servidor de rastreamento, que manipula objetos da tecnologia MapServer/MapScript, processando
os dados de posição adquiridos em etapas anteriores, e gerando arquivos no formato PNG (Portable
Network Graphics).
Sistemas de Informação em Gestão Ambiental um Caso Aplicado à Gestão de Recursos
Pesqueiros.
Este trabalho propõe um modelo de informações estruturado para não somente permitir a
geração de estatísticas de pesca, mas também a integração entre estudos científicos, legislação e o
georreferenciamento das informações. O seu objetivo final é ter um modelo capaz de conter as
informações necessárias para o processo de tomada de decisão na gestão de recursos pesqueiros.
19
Figura 5. Home Page do SIPESCA.
Fonte: LCA (2006).
Este sistema é construído através de tecnologias computacionais modernas, capazes de
prover toda funcionalidade exigida pelo modelo conceitual proposto. O uso intenso de ferramentas
opensource (OpenSource Software - OSS) agrega ao sistema a confiabilidade resultante de esforço
de testes extensivos e diversificados. Porém neste caso a empresa já possui o banco de dados
Oracle, e os programas foram desenvolvidos em cima do mesmo.
20
2.3.2
Webmapping
O principal conceito de webmapping, é a capacidade de um sistema em proporcionar ao
usuário, navegar através da utilização de mapas para localizar as informações na Internet. Ou seja, o
uso de servidores de mapas através da Internet para divulgação de informações de forma dinâmica
com geração de consultas espaciais (SPERB et al., 2002). A arquitetura webmapping, é
representada através da Figura 6.
Figura 6. Arquitetura webmapping
Fonte: LCA (2006).
Ao conectar na internet, o usuário solicita uma requisição de uma determinada informação
ao servidor HTTP, que por sua vez identifica para quem deve enviar essa requisição e transmite ao
servidor de mapas, que tem por finalidade separar os dados espaciais dos dados descritivos, esses
dados estão em um banco de dados espacial que é gerenciado pelo Sistema de Informações
Geográficas. O retorno dessas informações poderá ser visto no browser do cliente.
Conforme Silva et al. (2004), webmapping, representa um serviço que proporciona
aplicação de análise espacial para diversos casos de estudo, utilizando mapas dinâmicos, aliados a
dados armazenados sobre os mais variados temas com a utilização da interface Web. Hoje as opções
são mais poderosas de forma que a implantação de webmapping em servidores de mapas já se
21
tornou uma necessidade para aplicações SIG atuais que tendem a ter aplicações Web com
capacidade de recuperar, administrar, filtrar e visualizar as informações espaciais.
No webmapping, existe o conceito de navegação por mapas utilizando marcadores espaciais
como referência. O usuário, além de navegar pelo mapa, pode também escolher quais informações
deseja consultar, gerando as mais diversas associações entre os dados para obter o resultado visual
que deseja.
2.3.3
Map Server
MapServer é uma tecnologia que permite a criação de aplicações para geração de mapas via
web. O software segue a licença OSS/FS, e é construído com base em outros pacotes freeware com
Shapelib, GD, Freetype, OGR, Proj.4, libTiff, regex, e outros (MAPSERVER, 2002).
O Projeto MapServer foi originalmente desenvolvido pela Universidade de Minnesota
(UMN) para o projeto ForNet, em cooperação com a NASA e o Departamento de Recursos Naturais
de Minnesota. Atualmente, é fomentado pelo projeto TerraSIP, patrocinado via NASA e mantido
pela UMN. (MAPSERVER, 2002).
MapServer é integrado à linguagem PHP via MapScript, interface desenvolvida pela
empresa canadense DM Solutions Group que também segue a linha OSS/FS. MapScript fornece um
ambiente rico para personalizar aplicações baseadas na tecnologia MapServer. O grande diferencial
do sistema proposto está no uso de MapServer/MapScript para apresentar, via web, o rastreamento
das unidades de produção.
2.3.4
Map Server Guarani
Segundo o Laboratório de Computação Aplicada (LCA, 2006) da UNIVALI, o MapServer
Guarani constitui-se de um Framework para MapServer que foi desenvolvido para permitir a
elaboração de sistemas voltados para webmapping, incluindo funcionalidade de interação através de
mapas e de navegação.
22
De acordo com Bughi (2005), as funcionalidades disponibilizadas são para sistemas SIG
para Web, e permitem que múltiplos usuários possam compartilhar das mesmas ferramentas a partir
de um único sistema. Algumas dessas funcionalidades são:
•
Conexão com banco de dados: Permite a conexão com o PostgreSQL e Oracle, também
com as extensões espaciais PostGIS e Oracle Spatial;
•
Entrega de mapas sob demanda: Permite a entrega de mapas, gerados pelo MapServer,
através das requisições do usuário;
•
Navegação aprimorada: Permite aos usuários meios de navegar no mapa através de
funções simples, como: (a) zoom aleatório; (b) aproximação do mapa (zoom in); (c)
afastamento (zoom out); e (d) movimentação (pan);
•
Cálculo de distância: Permite ao usuário definir dinamicamente pontos na tela e calcular
as distâncias entre os mesmos em diversos sistemas métricos;
•
Análise espacial: Disponibiliza a capacidade do usuário definir a área de interesse no
mapa e pesquisar quais as informações dos objetos geoespaciais inclusos nessa área;
•
Análise de vizinhança: Permite ao usuário do sistema escolher um objeto geoespacial
aleatório do sistema e definir um raio para busca dos vizinhos a esse que se encontram
inclusos dentro do perímetro; e
•
Pesquisa por atributos: Método de análise espacial que permite ao usuário definir de
forma dinâmica qual a pesquisa, as restrições, que serão aplicadas sobre os objetos
geoespaciais, demonstrando o resultado das pesquisas por atributos através do mapa.
2.3.5
Apache Web Server
O Apache é a designação para o servidor Web da ASF (Apache Software Foundation –
Fundação de Software Apache), disponível em licença estilo OSS/FS em diversas plataformas de
hardware e software. Com base no httpd (Hiper Text Transmission Protocol Daemon – Protocolo de
Transmissão de Hiper Texto ), o Apache implementa o serviço de acesso a páginas Web utilizando
o protocolo HTTP/1.1 (SPERB, 2002).
O Apache é desenvolvido por colaboradores de todo o mundo, integrantes do Apache
Group. O sistema proposto irá utilizar-se do servidor Web Apache, configurado com as extensões
23
PHP (Hypertext PreProcessor). Atualmente ocupa o posto de Web Server mais usado na Internet
(NETCRAFT, 2005).
2.3.6
PHP
PHP, que significa "PHP: Hypertext Preprocessor" é uma linguagem de programação de
ampla utilização, interpretada, que é especialmente interessante para desenvolvimento para a Web e
pode ser mesclada dentro do código HTML (PHP, 2006).
O objetivo principal da linguagem é permitir aos desenvolvedores escrever páginas que
serão geradas dinamicamente, adicionando recursos que com o HTML não são possíveis.
A versão atual, PHP5, se baseia no sistema de processamento de scripts Zend, que é parte do
pacote PHP e mantém o registro de requisições, processa arquivos scripts e manipulam variáveis e
recursos. Este sistema de processamento de scripts foi projetado desde o inicio para poder ser
facilmente incorporado aos aplicativos diferentes.
O PHP é uma das linguagens Web mais utilizadas. Seus scripts são processados no servidor
mostrando apenas o resultado no browser do cliente, tornando a execução mais rápida, outras
características são: a portabilidade do PHP, a integração com a maioria dos bancos de dados
existentes, é uma ferramenta gratuita com o código aberto, permite a criação e manipulação de
arquivos pdf em tempo de execução, entre outras.
2.4 ROTEAMENTO
Roteirização de veículos é a forma que vem sendo utilizada para designar o processo de
determinação de um ou mais roteiros ou seqüências de paradas a serem cumpridos por veículos de
uma frota, objetivando visitar um conjunto de pontos geograficamente dispersos, em locais prédeterminados. (CUNHA, 1997).
Segundo Laporte et al. (2000) o problema de roteirização de veículos consiste em definir
roteiros de veículos que minimizem o custo total de atendimento, cada um dos quais iniciando e
24
terminando nos integrados ou abatedouros, assegurando que cada ponto seja visitado exatamente
uma vez.
Alguns softwares e aplicativos comerciais encontrados no mercado para roteirização de
veículos são heurísticos, isto é, não asseguram a obtenção da solução ótima do ponto de vista
matemático. Assim, na maioria dos casos, as heurísticas propostas são bastante específicas e
particulares, e carecem de robustez, isto é, não conseguem obter boas soluções para problemas com
características, condicionantes ou restrições às vezes um pouco diferentes daquelas para as quais
foram desenvolvidas. (HALL e PARTYKA, 1997).
2.4.1
Atributos espaciais para o problema de roteirização
Nas formulações matemáticas de problemas de roteirização de veículos pressupõe-se um
grafo ou rede G=(N, A) composto de um conjunto de nós N, que representa um conjunto de pontos
a serem atendidos e a base onde se localizam os veículos, e um conjunto de arcos A, representando
as ligações entre todos os pares de nós em N, para os quais são conhecidos as distâncias e os tempos
de viagem (NOVAES, 1989).
Assim, o processamento de um algoritmo para um problema de roteirização deve ser
precedido pela etapa de obtenção do grafo G. Isto envolve a localização geográfica ou espacial dos
pontos de atendimento e a determinação das distâncias e dos tempos de viagem entre os mesmos.
Este é um aspecto pouco discutido, mas de fundamental importância para a aplicação de modelos
matemáticos a problemas reais de roteirização. (NOVAES,1989).
2.4.2
Formas de representação do grafo
Os softwares para roteirização de veículos adotam um modelo mais simplificado para
determinação do grafo: os pontos de atendimento e a base onde se localizam os veículos são
representados através de algum sistema de coordenadas, geralmente cartesianos ou georeferenciadas
(latitude e longitude) (NOVAES,1989).
Neste caso, as distâncias nos arcos são calculadas com base nas coordenadas dos pontos,
segundo alguma métrica (distância Euclideana ou retangular), podendo ser ajustadas por fatores de
25
correção, de forma a considerar o percurso adicional decorrente do sistema viário. Os tempos de
viagem são calculados com base nas distâncias e em velocidades médias, que podem variar segundo
o tipo de veículo, ou ainda segundo as zonas onde se localizam os pontos de origem e de destino e
segundo a distância a ser percorrida.
Podem oferecer ainda o recurso adicional de cadastramento de barreiras geográficas, através
de linhas ou polígonos, de modo a representar obstáculos naturais (tais como rios, montanhas, lagos,
parques, etc.) ou artificiais (ferrovias, rodovias expressas, etc.) que não podem ser atravessados.
Nesse caso, no cálculo das distâncias (em linha reta) é considerado o percurso adicional para
contornar o obstáculo ou para a sua transposição através de pontos específicos (tais como pontes
sobre rios). Utiliza interfaces com mapas digitais georeferenciados ou Sistemas de Informações
Geográficas (SIG) para representar os pontos de atendimento e a malha viária por onde trafegam os
veículos.
Um SIG possibilita a localização automática de clientes e endereços. A distância e o tempo
de viagem em cada um dos arcos A do grafo G são obtidos através do processamento prévio de
algum algoritmo de caminhos mínimos, aplicado à malha viária da região de interesse. Assim, um
software de roteirização não opera diretamente sobre o banco de dados da malha viária, a qual pode
conter até centenas de milhares de trechos de vias cadastrados (NOVAES, 1989).
2.4.3
Aspectos favoráveis e desfavoráveis da roteirização
A decisão quanto à melhor forma de obtenção de um grafo, a partir de uma representação
simplificada através de coordenadas ou de um banco de dados acoplado a um mapa digital depende
de cada situação e também da natureza do ambiente de operação. No contexto espacial, pode-se
dividir os problemas em duas categorias distintas: a dos roteiros urbanos e a dos
interurbanos/regionais. Na distribuição urbana, o problema é mais complexo, pois o sistema viário é
mais denso, o número de alternativas de roteiros é muito superior (é possível ir de algum ponto a
qualquer outro) e as restrições de circulação são mais severas (restrições de circulação, mãos de
direção, movimentos permitidos e proibidos, tais como conversões, retornos, etc.). Tal situação
recomendaria uma representação mais realista da malha viária, através de mapas digitais
(NOVAES, 1989).
26
Por outro lado, segundo Bodin et al. (1990), criar e manter um SIG pode implicar um
aumento significativo no custo de um sistema completo de roteirização e programação de veículos.
A manutenção e a atualização de uma base de dados de informações viárias é particularmente
crítica, principalmente em cidades maiores, nas quais há mudanças freqüentes de mão de direção e
de restrições à circulação de veículos (conversões e outros movimentos proibidos). Além de tudo
isso, as bases geográficas armazenam um único valor de tempo ou velocidade em cada trecho da
malha, que independe do horário do dia. Em regiões urbanas mais congestionadas, a consideração
de velocidades médias ou de tempos de viagem que variam segundo o horário do dia, refletindo
períodos de gargalo e congestionamento, é fundamental para o sucesso da roteirização,
principalmente quando restrições temporais, como janelas de tempo, estão envolvidas.
Já na roteirização em nível regional, as distâncias entre pontos de atendimento (em geral,
diferentes cidades) são geralmente mais longas, a malha muito menor em termos de extensão, assim
como o número de trechos. Além disso, são menores as incertezas associadas às restrições e
condicionantes de tráfego. Nesse contexto, é mais fácil, porém não menos importante montar um
cadastro rodoviário que contenha a matriz de distâncias e tempos de viagem entre cidades de
interesse (onde se localizam clientes e/ou atendimentos), sem a necessidade de recorrer a
coordenadas cartesianas ou à digitalização de mapas. Em geral esta matriz é suficiente para a
obtenção de uma roteirização razoavelmente acurada (BODIN, 1990).
Um último aspecto a ser destacado refere-se aos problemas de localização dos pontos de
atendimento, uma fonte de erros e imprecisões que afetam a qualidade dos roteiros obtidos. De nada
adianta um algoritmo muito eficiente, se os pontos estão localizados incorretamente. Este fato
ocorre tanto na imprecisão do cadastro quanto na existência de mais de um logradouro com o
mesmo nome em regiões metropolitanas, ruas sem nome (rua A, B, etc.), de endereços que não
constam do cadastro oficial entre outros (ibiden).
A importância da roteirização de veículos, a diversidade de problemas do mundo real e a sua
complexidade computacional, têm desafiado os pesquisadores a buscarem novos algoritmos que
permitam obter melhores resultados e resolver problemas de dimensões crescentes e cada vez mais
complexos, além de incorporar restrições que permitam tornar mais realistas os modelos que os
representam.
27
2.4.4
Algoritmo Escolhido
Existem basicamente dois algoritmos para resolver o problema de caminho mínimo em
redes com origem e destino dados. O primeiro e mais famoso deles, é o algoritmo de Dijkstra,
proposto em 1959 e aperfeiçoado desde então principalmente pelo uso de estruturas de dados mais
eficientes. Este algoritmo, quer será apresentado abaixo com detalhes, apenas funciona se os custos
associados aos arcos (pares de vértices) forem não negativos. O outro algoritmo, proposto
separadamente por Bellman (1958) e Ford (1962) admite o caso mais geral de custos negativos. Em
geral, as grandezas físicas associadas aos arcos são naturalmente não negativas, neste caso o
algoritmo de Dijkstra é o mais apropriado para a resolução do problema (DIJKSTRA, 2006).
2.4.4.1
Calculo de Menor Rota
A escolha do melhor caminho já foi motivo de muito estudo e pesquisa sobre a teoria dos
grafos valorados. Após pesquisas por possíveis algoritmos, foi escolhido o algoritmo de Dijkstra.
Edsger Wybe Dijkstra nasceu em 1930, em Rotterdam, Holanda. Seu pai era farmacêutico e a mãe
matemática. Graduou-se em Física Teórica e Matemática pela Universidade de Leyden e obteve seu
diploma de Ph.D. em Ciência da Computação na Universidade de Amsterdam. Trabalhou como
programador de computadores de 1952 a 1962 no Mathematisch Centrum em Amsterdam.
Lecionou Matemática na Eindhoven University of Technology de1962 a 1984 e atuou como
pesquisador da Burroughs Corporation de 1973 a 1984. A partir de 1984, ocupou a prestigiosa
cadeira Schlumberger Centennial Chair in Computing Sciences na University of Texas em Austin e
aposentou-se como Professor Emérito em 1999. Faleceu em sua casa no dia 6 de agosto de 2002
deixando esposa e três filhos, após longa batalha contra o câncer (DIJKSTRA, 2006).
Segundo Dijkstra, o primeiro passo do algoritmo é criar na memória uma matriz
unidimensional na mesma dimensão da matriz de distâncias, preenchida com um valor muito
grande. Esse vetor guardará a distância percorrida da origem até o ponto que seu índice representa.
Outra matriz de mesma dimensão é criada para guardar o status do ponto.
Inicialmente preenchida por valores NULL, à medida que os pontos representados por seus
índices forem expandidos, em busca de seus pontos adjacentes, receberão valor TRUE. O próximo
passo é, a partir da linha que representa o ponto de origem, expandir todos os pontos adjacentes. Os
pontos expandidos serão marcados como TRUE no vetor já citado. O vetor que recebe as distâncias
acumuladas, inicialmente preenchidas com valores grandes, recebe os valores encontrados em cada
28
célula de adjacência (por serem menores), respeitando seus respectivos índices. O menor valor
encontrado no vetor de distâncias acumuladas servirá de partida para a próxima busca, que repetirá
os processos anteriores, buscando todos os pontos adjacentes. O vetor de distâncias acumuladas irá
somar o custo de todas as arestas ao longo da busca até o ponto representado por seu índice. Ao
final do processo, quando todos os pontos forem expandidos, ou o ponto corrente for o destino, o
algoritmo retorna um vetor contendo os pontos que representam o caminho mais curto e a distância
acumulada até ele. Caso não haja caminho ligando os dois pontos, retornará FALSE. Contudo, o
algoritmo não garante a exatidão da solução caso existam arcos com valores negativos.
O algoritmo de Dijkstra é classificado como sendo de “força bruta”, porém, a vantagem de
Dijkstra, e o que dá um bom desempenho ao processo, é a forma como os dados de entrada estão
arranjados. Dijkstra visualizou uma matriz, onde cada célula não nula guardasse a distância entre
um ponto (linha da matriz) e outro (coluna da matriz). Logo, se uma célula da matriz possui valor
nulo, esses pontos (linha x coluna) não estão interligados.
A execução do algoritmo de Dijkstra é feita por um grafo G, em que G = (V,A), onde V é
um conjunto não vazio de vértices e A é um conjunto de pares de vértices denominados de arcos e
que representam uma ligação entre dois vértices, arcos esses que podem ter um determinado peso
(grafo ponderado), que será o custo necessário para percorrer o arco, pelo que uma rede de estradas
que liga diversas cidades pode ser representada através de um grafo ponderado com pesos positivos.
O grafo seguinte representa o conjunto de cidades V={A,B,C,D,E} com as respectivas
estradas e distâncias que as ligam (CARVALHO, 2006).
29
Figura 7. Grafo representando um conjunto de cidades.
Fonte: (Carvalho, 2006)
Pretende-se calcular, de entre os caminhos possíveis, aquele que é o caminho mais curto
entre a cidade A e as restantes cidades. Para resolver este problema usou-se o Algoritmo de
Dijkstra. Ele calcula o caminho de custo mínimo entre vértices de um grafo. Escolhido o vértice A
como raiz da busca (cidade origem), este algoritmo calcula a distância mínima deste vértice para
todos os demais vértices do grafo, ou seja, as restantes cidades. Este algoritmo parte de uma
estimativa inicial para a distância mínima, que é considerada infinita (∞), e vai sucessivamente
ajustando esta distância. Ele considera que uma cidade estará “fechada” quando já tiver sido obtido
um caminho de distância mínima da cidade tomada como origem da busca até ela. Este
procedimento pode ser armazenado na seguinte tabela que irá sendo alterada à medida que vão
sendo percorridos todos os caminhos possíveis: (CARVALHO, 2006)
Tabela 5. Lista de caminhos 1
Cidades
Distância
Precedente
Fechado
A
0
N
B
∞
N
C
∞
N
Fonte: (Carvalho, 2006)
30
D
∞
N
E
∞
N
Inicialmente, todos os vértices têm uma distância infinita, exceto a cidade de origem (A) que
tem, logicamente, distância zero. Posteriormente, é selecionada a cidade que tem uma distância
menor em relação a todas as outras e que se encontra “aberta” que é, no caso inicial, a cidade A. A
cidade selecionada é “fechada” e são recalculadas, a partir de A, todas as distâncias às cidades ainda
“abertas”, somando à distância da cidade selecionada as distâncias dos arcos respectivos. Nos casos
em que as novas distâncias obtidas são inferiores às que se encontram armazenadas nas tabelas,
procede-se à substituição das mesmas pelas novas distâncias e é alterada também a cidade
precedente. Após o primeiro passo, a tabela seria a seguinte:
Tabela 6. Lista de caminhos 2
Cidades
Distância
Precedente
Fechado
A
0
A
S
B
50
A
N
C
30
A
N
D
100
A
N
E
10
A
N
Fonte: (Carvalho, 2006)
De forma análoga, o segundo passo será selecionar a cidade ainda “aberta” com a menor
distância na tabela (a cidade E com distância 10), “fechá-la” e, a partir de E, recalcular as
distâncias, alterando aquelas que sejam menores que as da tabela (a distância de D é alterada para
20 com precedente E), que ficaria da seguinte forma:
Tabela 7. Lista de caminhos 3
Cidades
Distância
Precedente
Fechado
A
0
A
S
B
50
A
N
C
30
A
N
D
20
E
N
E
10
A
S
Fonte: (Carvalho, 2006)
Repete-se o algoritmo até que todas as cidades tenham sido “fechadas”. As tabelas após as
sucessivas operações são as seguintes:
31
Tabela 8. Lista de caminhos 4
A
0
A
S
Cidades
Distância
Precedente
Fechado
B
40
D
N
C
30
A
N
D
20
E
S
E
10
A
S
C
30
A
S
D
20
E
S
E
10
A
S
C
30
A
S
D
20
E
S
E
10
A
S
Fonte: (Carvalho, 2006)
- D é “fechada”;
- Distância e Precedente de B são alterados.
Tabela 9. Lista de caminhos 5
A
0
A
S
Cidades
Distância
Precedente
Fechado
B
35
C
N
Fonte: (Carvalho, 2006)
- C é “fechada”;
- Distância e Precedente de B são alterados.
Tabela 10. Lista de caminhos 6
A
0
A
S
Cidades
Distância
Precedente
Fechado
B
35
C
S
Fonte: (Carvalho, 2006)
-
B é “fechada”.
32
Quando todas as cidades tiverem sido “fechadas”, os valores obtidos são as distâncias
mínimas dos caminhos que partem da cidade A para as restantes. O caminho percorrido nesse
trajeto é obtido a partir dos valores colocados no campo “Precedente”.
É muito importante referir que o Algoritmo de Dijkstra só pode ser utilizado em grafos
ponderados e unicamente com pesos positivos e permite calcular as distâncias entre uma cidade
específica e todas as outras, ao contrário do Algoritmo de Floyd que calcula as distâncias entre
todas as cidades.
De forma computacional, o Algoritmo de Dijkstra pode ser traduzido da seguinte forma:
· Seja G(V,A) um grafo orientado e a um vértice de G:
1. Atribui-se valor zero à estimativa do custo mínimo do vértice a (a raiz da busca) e infinito
às demais estimativas;
2. Atribui-se um valor qualquer aos precedentes (o precedente de um vértice t é o vértice que
precede t no caminho de custo mínimo de a para t);
3. Enquanto houver vértice aberto:
•
seja k um vértice ainda aberto cuja estimativa seja a menor dentre todos os vértices
abertos;
•
fecha-se o vértice k
•
Para todo vértice j ainda aberto que seja sucessor de k faz-se:
•
soma-se a estimativa do vértice k com o custo do arco que une k a j;
•
caso esta soma seja melhor que a estimativa anterior para o vértice j,
substitui-se e anota-se k como precedente de j.
A implementação computacional deste algoritmo tem uma complexidade O(n²), enquanto,
por exemplo, o Algoritmo de Floyd tem uma complexidade superior de O(n³), o que é uma grande
desvantagem quando o número de vértices e arcos (ou sejam, cidades e estradas) vai aumentando,
portanto, o computador levará menos tempo a realizar os cálculos necessários se for usado o
Algoritmo de Dijkstra.
33
Como os grafos não existem como estrutura de dados pré-definida nas linguagens de
programação, a sua implementação pode ser feita através de uma matriz de adjacência ou de uma
lista de adjacência, conforme Figuras 14 e 15:
Figura 8. Matriz de Adjacência
Fonte: (Carvalho, 2006)
Figura 9. Lista de adjacência
Fonte: (Carvalho, 2006)
2.4.4.2
Estrutura de dados
Para implementar o algoritmo de Dijkstra, de forma mais simples e eficiente, foi montanda
uma matriz de duas dimensões. Essa matriz é quadrada, por isso, possui o mesmo número de
34
colunas e linhas. As linhas representariam a origem, e as colunas, o destino. O valor contido em
cada célula representa a distância de um ponto a outro. A esta matriz foi dado o nome de matriz de
distâncias. Para que se entenda melhor, a Tabela 11 ilustra a matriz de distâncias referente ao grafo
mostrado na Figura 16.
Figura 10. Exemplo de um grafo bidirecionado.
Fonte: (Carvalho, 2006)
Tabela 11. Matriz de Adjacência
A
B
C
D
E
F
A
0
100
15
0
0
0
B
100
0
40
180
200
0
C
15
40
0
45
90
0
D
0
180
45
0
0
101
E
0
200
90
0
0
120
F
0
0
0
101
120
0
Fonte: (Carvalho, 2006)
O grafo ilustrado na Figura 8 é um grafo bidirecional, ou seja, as arestas, ou arcos, possuem
duplo sentido. Neste caso, o valor da aresta pode ser usado para calcular o custo do ponto x para o
ponto y e do ponto y para o ponto x. A solução prossegue através da obtenção, no banco de dados,
35
das distâncias entre os pontos. De posse das distâncias retornadas pelo PostGIS, o restante do
algoritmo de Dijkstra poderá ser aplicado.
3 PROJETO
Esta etapa destaca os aspectos técnicos envolvidos durante a modelagem dos novos módulos
do Rastreador Geográfico, incluindo o algoritmo de cálculo de rotas e a migração do sistema para o
banco de dados PostGreSQL. Apresenta ainda a aplicação de conceitos identificados durante a
fundamentação teórica no desenvolvimento da solução.
3.1 MODELAGEM DO SISTEMA
O objetivo da modelagem é mostrar em uma representação conceitual as classes básicas, as
associações e funções que farão com que o módulo proposto seja implementado e os aspectos
lógicos e relacionais fazendo uma transcrição das informações reais para modelos lógicos de
solução.
Foi utilizada a modelagem orientada a objetos UML (Unified Model Language), onde foram
utilizados os diagramas considerados importantes no processo, pois fornece ao desenvolvedor uma
visão macro do nego ócio.
A ferramenta utilizada para modelagem do sistema é a EA Enterprise Architect, produzida
pela empresa Sparx System1. A ferramenta suporta os padrões UML, cobrindo todos os diagramas
previstos. Além da facilidade no uso interface amigável e padronizada
3.2 REQUISITOS
Um requisito de software é uma descrição dos principais recursos de um produto de
software, seu fluxo de informações, comportamento e atributos.
1
Spark System, é uma empresa autraliana, que desenvolve soluções para utilização da representação UML, site na
internet: http://www.sparxsystems.com.au/. Acesso em: 10 jun. 2006.
36
3.2.1
Requisitos Funcionais
Um requisito funcional descreve uma interação entre o sistema e seu ambiente, descrevem
como o sistema deve se comportar, considerando certo estímulo.
Segue abaixo a relação de todos os requisitos funcionais do rastreador, do RF011 em diante
são os novos requisitos que surgiram com o novo módulo.
37
cd R equisitos Funcionais
REF 001 - O sistema deve permitir a visualização dos dados de fazendas de produção de frangos de corte e
suínos, e outros (1), através de um sistema de informações com suporte espacial.
REF 002 - O sistema deve permitir que sejam realizadas consultas às fazendas e outros por nome, cpf, código ou
município, apresentando suas localizações geográficas no mapa.
REF 003 - O sistema deverá apresentar os nomes dos municpios e rodovias no mapa.
REF 004 - O sistema deve possuir um controle de usuário que possibilite a consulta aos dados somente aos
usuários cadastrados.
REF 005 - O sistema deve permitir que se faça a análise de vizinhança de uma fazenda (ou outros), apresentando
no mapa as fazendas localizadas num raio definido (em metros) pelo usuário, bem como através de uma listagem.
.
REF 006 - O sistema deverá permitir a medição da distância entre dois pontos localizados no mapa.
REF007 - O sistema deverá emitir relatórios em formato PDF das informações selecionadas para consulta.
REF008 - O sistema deverá armazenar histórico dos acessos realizados pelos usuários.
REF009 - Deverá ser possível apresentar no mapa pontos referentes a frango de corte, suínos ou ambos.
REF010 - O sistema deverá permitir que sejam feitas consultas cruzando os integrados próprios com os
concorrentes, apresentando com cores diferentes no mapa.
REF 011 - O sistema deve permitir efetuar a busca e visualizar o menor caminho entre dois pontos distintos
REF 012 - O Sistema deve permitir o Cadastro das Divisões
REF 013 - O sistema deve permitir o cadastro do tipo de integrado.
REF 014 - O sistema deverá permitir armazenar um histórico das areas de quarentena.
REF 015 - O Sistema deverá permitir o cadastro dos integrados
REF 016 - O sistema deverár permitir o cadastro das areas em quarentena.
REF 017 - O sistema deverá permitir o cadastro dos problemas sanitários
Figura 11. Requisitos funcionais do Rastreador Geográfico com o módulo proposto.
38
3.2.2
Requisitos não Funcionais
Os requisitos não funcionais são as restrições no sistema. Eles descrevem uma restrição no
sistema que limita a opção para criar soluções ao problema.
Segue abaixo a relação de Requisitos não funcionais do Rastreador:
•
Segurança
cd Segurança
RNF 01.01 - O sistema deve possuir um mecanismo de segurança para evitar que pessoas não autorizadas
tenham acesso ao sistema ou a dados privados.
RNF 01.02 - As senhas de acesso ao sistema não devem estar diretamente visíveis no banco de dados e sim de
algum modo criptografado.
Figura 12. Requisitos não funcionais de segurança.
•
Usabilidade
cd Usabilidade
RNF 02.01 - O sistema deverá apresentar legendas específicas para atributos cadastrais.
RNF 02.02 - Deve-se oferecer manual online para auxílio ao usuário.
RNF 02.03 - O espaço ocupado pelo mapa no monitor do computador deverá ser o maior possível, procurando
reduzir o espaço para as informações textuais.
RNF 02.04 - De forma a não sobrecarregar o mapa de informações, deverá ser criado um mecanismo de
apresentação dos nomes das fazendas, municípios e rodovias.
Figura 13. Requisitos não funcionais de usabilidade.
39
•
Confiabilidade
cd 03 -Confiabilidade
RNF 03.01 O sistema deverá ser suficientemente robusto para permitir acessos 24h por dia, todos os dias da
semana.
Figura 14. Requisitos não funcionais de confiabilidade.
•
Software e Hardware
cd Requisitos Não Funcionais
RNF 04.01 - Será utilizado o servidor de mapas MapServer com o SGBD PostGis.
RNF 04.02 - O hardware para implantanção do sistema será disponibilizado pela Univali
Figura 15. Requisitos não funcionais de Software e Hardware.
•
Manutenibilidade
cd M anutenibilidade
RNF 05.01 - Para facilitar a manutenção do sistema, deverão ser criados documentos do projeto apresentando
modelagem ER e de casos de uso, bem como demais diagramas necessários.
RNF 05.02 - Deverá ser entregue script para criação da estrutura do banco de dados.
Figura 16. Requisitos não funcionais de Manutenibilidade.
40
3.2.3
Diagrama de Classe
Os diagramas de classes são a essências da UML, são eles que definem a estrutura lógica e
estática do sistema. Nesse modelo são representadas as classes, juntamente com os tipos de
conteúdos, métodos e relações. Os diagramas de classe têm grande importância no sistema, devido a
enorme quantidade de elementos que podem ser visualizados para o entendimento do sistema.
O diagrama de classes esta no núcleo do processo de modelagem de objetos. Ele modela as
definições de recursos essenciais à operação correta do sistema. Todos os outros diagramas de
modelagem descobrem informações sobre esses recursos como valores de atributos, estado e
restrições no comportamento.
cd Diagram a de Classes
Div isão
-
cd_divisao:
ds_divisao:
+
+
+
+
Inserir() : void
Excluir() : void
Alterar() : void
Consultar() : void
Tipo_Integrado
0..* +
+
+
+
0..1
Unidade_Federacao
cd_tipo_integrado:
ds_tipo_integrado:
-
cd_unidade_federacao:
ds_unidade_federacao: char
Inserir() : void
Alterar() : void
Excluir() : void
Consultar() : void
+
+
+
+
Inserir() : void
Excluir() : void
Alterar() : void
Consultar() : void
0..1
0..1
0..*
-
dt_inicio_quarentena:
dt_fim_quarentena:
id_ativo_inativo:
vl_coordenada:
ds_observacao:
+
+
+
+
Alterar() : void
Inserir() : void
Excluir() : void
Consultar() : void
0..*
Integrado
Quarentena
0..* -
0..1
+
+
+
+
cd_integrado: int
ds_integrado: char
id_fisico_juridico: char
ds_localidade: char
cd_tipo_integrado: int
cd_cep: char
0..*
Cidade
0..1
Inserir() : void
Alterar() : void
Excluir() : void
Consultar() : void
-
cd_cidade:
ds_cidade: int
cd_uf: int
+
+
+
+
Inserir() : void
Consultar() : void
Excluir() : void
Alterar() : void
0..1
0..*
0..1
0..*
Problema_Sanitario
-
cd_problema_sanitario: int
ds_problema_sanitario: char
+
+
+
+
Inserir() : void
Alterar() : void
Excluir() : void
Consultar() : void
Orgao_Responsav el
0..1
0..*
Figura 17. Diagrama de classes do módulo proposto.
41
-
cd_orgao_responsavel:
ds_orgao_responsavel:
+
+
+
+
Inserir() : void
Alterar() : void
Excluir() : void
Consultar() : void
Detalhamento das Classes:
•
Divisão: esta classe identifica a divisão do negócio em si, por exemplo, à divisão de um
negócio podem ser aves, suínos, bovinos etc.
•
Tipo Integrado: Identifica o tipo de integrado ou tipo de unidade de produção, ele pode
ser incubatórios, abatedouros, granjas etc.
•
Unidade de Federação: Esta classe trata os dados referentes às unidades de federação dos
integrados.
•
Problema Sanitário: Demonstra problema sanitário ou as doenças existentes que
influenciam no negócio da empresa.
•
Órgão Responsável: Identifica conforme a doença qual o órgão a ser acionado para
tomar as devidas providências.
•
Quarentena: Área de isolação ou um perímetro determinado pelo usuário.
•
Cidade : Classe que identifica as cidades.
•
Integrado: São as unidades de produção de uma empresa.
3.2.4
Diagrama de Casos de Uso
Os diagramas de casos de uso são formas para descrever uma visão externa do sistema
apresentando através de descrições narrativas as interações do sistema com o mundo exterior. Os
diagramas representam uma visão macro do sistema mostrando a relação do mesmo com as ações
do usuário.
Use-case é uma descrição de interações típicas entre os usuários de um sistema e o sistema
propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto de
exigências do que o sistema deve fazer.
O diagrama de Caso de Uso (Use Case) modela as expectativas do usuário para usar o
sistema. As pessoas e os sistemas que interagem com o sistema alvo são chamados atores. Os
recursos do sistema que os atores utilizam são chamados casos de uso. Alguns casos de uso
interagem com outros casos de uso, um relacionamento modelado por meio de setas de
dependência.
42
ud Diagram a de Casos de Uso
Rastreador Geográfico
Segurança
+ Usuário
+ UC01.01 - Navega no mapa
+ Administrador do Sistema
+ UC01.02 - Pesquisa Pontos
+ UC02.01 - Controla usuários
+ UC01.03 - Realiza a análise de vizinhança
+ UC02.02 - Consulta acessos ao sistema
+ UC01.04 - Calcula distâncias
+ UC02.03 - Conecta no sistema
+ UC01.05 - Realiza manutenção de áreas de quarentena
+ UC02.04 - Desconecta do sistema
+ UC01.06 - Cálcula menor caminho desviando das areas de Quarentena
Cadastro
+ Usuário
+ UC00.01 - Manter Area de quarentena
+ UC00.02 - Manter Integrado
+ UC00.03 - Manter Tipo Integrado
+ UC00.04 - Manter Problema Sanitário
+ UC00.05 - Manter Divisão
Figura 18. Diagrama de pacotes dos casos de usos.
No diagrama de pacote Rastreador Geográfico, os casos de usos UC01.05 e UC01.06 serão
adicionados com o novo módulo, o mesmo ocorrerá com todo o diagrama de pacote Cadastro.
O diagrama de pacote de Segurança já está criado no Rastreador Geográfico atual. Segue
abaixo o diagrama com todos os casos de uso do Rastreador.
43
Novos Casos de
usos referentes
ao
módulo
adicional
Figura 19. Diagrama de casos de uso do Rastreador Geográfico.
No diagrama abaixo demonstra os casos de usos onde que somente o administrador do
sistema poderá manter. Eles já fazem parte do Rastreador Geográfico atual.
44
ud Segurança
UC02.01 - Controla
usuários
UC02.02 Consulta acessos
ao sistema
Administrador do
Sistema
UC02.03 - Conecta
no sistema
UC02.04 Desconecta do
sistema
Figura 20. Diagrama de casos de uso de segurança.
Segue abaixo os casos de uso que irão compor o novo módulo proposto.
ud Cadastros Diversos
UC00.05 - Manter
Div isão
UC00.01 - Manter
Area de
quarentena
UC00.04 - Manter
Problema Sanitário
UC00.02 - Manter
Integrado
UC00.03 - Manter
Tipo Integrado
Usuário
Figura 21. Diagrama de casos de uso do módulo proposto.
45
3.2.5 Diagrama de Entidade e Relacionamento
No diagrama de entidade e relacionamento são demonstradas todas as tabelas do projeto e
como elas estão relacionadas. A figura (Figura 22. Diagrama de Entidade e Relacionamento.)
apresenta o diagrama do novo módulo do rastreador.
Figura 22. Diagrama de Entidade e Relacionamento.
46
As tabelas que compõem o diagrama de Entidade e Relacionamento serão detalhadas
abaixo:
•
Usuário: Esta tabela irá conter todos os usuários que poderão acessar o sistema.
•
Programa: Esta tabela irá conter todos os programas ou módulos disponíveis ao
sistema do rastreador.
•
Usuário Programa: Nesta tabela ira conter os programas liberados por usuários, ou
seja, a relação dos programas de um determinado usuário.
•
Tipo de integrado: Esta tabela terá todos os tipos de integrados existentes em uma
empresa, exemplo: granjas, abatedouros, incubatórios etc.
•
Integrado: Aqui serão armazenados todos os logradouros das unidades de produção
de uma determinada empresa.
•
Órgão Responsável: Esta tabela irá armazenar todos os órgãos responsáveis que
quando acionados, irão atender um determinado foco de doença a fim de isolar a área
e erradicar a doença.
•
Divisão: São os tipos de carne na qual uma empresa trabalha exemplo: Aves, Suínos,
Bovinos.
•
Problema sanitário: Esta tabela irá manter os tipos de problemas sanitários
existentes.
•
Quarentena: Esta é a principal tabela de todo o sistema, pois ela irá armazenar os
locais que estão em quarentena.
•
Rodovia: Esta tabela não será mantida por nenhum usuário do sistema, os seus
registros devem ser importados do site do IBGE.
•
Rodovia Quarentena: Conforme um raio definido na tabela rodovia, esta tabela irá
conter todas as rodovias que estão dentro deste raio a fim de fazer a área de exclusão,
sendo que este processo é feito somente via programação.
47
3.3 IMPLEMENTACAO
O desenvolvimento deste TCC foi dividido em duas etapas. Na primeira etapa, denominada
Trabalho de Conclusão de Curso I, foi realizado um estudo do funcionamento do algoritmo de
dijkstra, utilizado para cálculo de rotas, Também foram analisadas as ferramentas que seriam
utilizadas no desenvolvimento do sistema e a modelagem do sistema. Nesta segunda etapa
(Trabalho de Conclusão de Curso II) foram realizadas as configurações do ambiente de
desenvolvimento e a implementação do sistema de maneira seqüencial, partindo dos conceitos
teóricos apresentados durante a fundamentação teórica (capitulo dois).
3.3.1
Ambiente de desenvolvimento
O ambiente de desenvolvimento foi montado utilizando-se um microcomputador Pentium 4
1800 Mhz, 512MB de memória, rodando o sistema operacional windows XP com o service Pack 2
instalado. Após vários testes no decorrer do desenvolvimento do sistema, este ambiente mostrou-se
estável para a execução do protótipo do sistema.
3.3.2
Ferramentas utilizadas no projeto
Após o estudo das tecnologias existentes, optou-se pela utilização das seguintes ferramentas
e tecnologias:
•
Banco de dados PostgreSQL com PostGIS habilitado, utilizado para armazenar os
dados tabulares e geoespaciais do sistema;
•
PgAdmin III, para gerenciar e administrar o banco de dados;
•
DBdesigner 4.0 para a modelagem do banco de dados;
•
Servidor Web Apache, versão 2.0;
•
Linguagem de scripts PHP, versão 5.0;
•
Framework Scriptcase para criação dos módulos basilares do sistema; e
•
Framework Mapserver Guarani para criação do WebGIS.
48
Quase todas as ferramentas utilizadas neste projeto são softwares livres, ou seja, sem
nenhum custo para executar e ou estudar os programas. O único software proprietário que detém os
direitos autorais é o Scriptcase, utilizado em uma versão acadêmica sem limitações para o
desenvolvimento do projeto, porém possuindo bloqueio por data de expiração.
Nos tópicos seguintes serão descritas as principais atividades executadas durante a
configuração/utilização das ferramentas citadas.
3.3.2.1
Mapserver Guarani
O Mapserver Guarani é um framework executado através de um servidor web configurado
com a linguagem PHP. Para iniciar sua utilização, deve-se copiar o pacote de instalação para o
diretório web do servidor. Após a cópia do Mapserver Guarani, é necessário realizar as
configurações para que ele possa se comunicar com o banco de dados Postgres.
Primeiro o Mapserver Guarani solicita ao usuário a sua matrícula e senha do banco de dados
Postgres (Figura 23. Tela principal do Rastreador.), que devem estar previamente criadas no banco,
para o campo host foi colocado o endereço de IP (Internet Protocol) 127.0.0.1, que é o endereço da
maquina que possui a instalação e configuração do banco, neste caso foi criado o banco na maquina
local. Para o campo banco, deve ser informado o banco de dados criado dentro do postgres. A
próxima figura (Figura 23) demonstra o Mapserver Guarani, utilizando o mapfile configurado com
as respectivas camadas necessárias para a aplicação. As camadas referentes a cidades, rodovias,
integrados e órgãos responsáveis, estão armazenadas diretamente do banco de dados.
Os dados para as tabelas cidade e rodovias foram tirados do site do IBGE (www.ibge.gov.br),
e foram manipulados a fim de adaptarem-se ao sistema desenvolvido.
49
Figura 23. Tela principal do Rastreador.
MapFile
O arquivo Mapfile é utilizado pelo UMN Mapserver na definição dos parâmetros utilizados
para a criação do mapa temático e suas respectivas camadas. O arquivo Mapfile utilizado por este
TCC foi baseado no arquivo já utilizado pelo sistema Rastreador Geográfico, não apresentando
somente as definições adicionais necessárias para que o mapa com a analise possa ser gerado, mas
também as cidades e rodovias que são mantidas no banco de dados postgis.
Apesar de o Mapserver Guarani utilizar o Mapserver através do modo PHP/Mapscript, ainda
assim existe a necessidade da existência do arquivo mapfile. Desta forma o arquivo contem somente
as definições que não sofrerão alteração com a execução do algortimo proposto, tais como: cores,
tipos de objetos, escala e unidades do mapa. Esta forma de acesso e parametrização permite uma
simplificação do algoritmo, pois alem de utilizar um objeto já funcional com o mapserver guarani
não existe a necessidade de definir parâmetros estáticos para o mapa no código do algoritmo.
50
3.3.2.2
PgAdmin
Para a criação da base de dados com as tabelas e a realização de consultas e manipulação de
dados foi utilizado o PgAdmin. Este ferramenta possui funções de manipulação de dados que foram
utilizadas durante o desenvolvimento do projeto. Neste caso, as funções básicas já vêem embutidas
no código do produto e disponíveis para utilização imediata após a instalação. O PgAdmin permite
que sejam mantidas mais de uma base de dados simultaneamente. A figura abaixo demonstra o
Pgadmin aberto e pronto para ser utilizado.
Figura 24. Tela Inicial do Pgadmin.
Todas as tabelas foram criadas neste ambiente conforme o diagrama de ER, desenvolvido
durante o andamento do TCC II.
51
3.3.2.3
DBDesigner
O Dbdesigner serve para gerar o modelo de entidade e relacionamento do projeto. Ele gera
scripts para o banco de dados PostGreSQL e possui todos os seus tipos de dados. No momento de
fazer as ligações entre as tabelas, ele permite escolher o tipo, por exemplo: 1 para 1, 1 para N. A
Figura 25 apresenta a tela do Dbdesigner demonstrando todas as tabelas do projeto.
Figura 25. Tela Inicial do DBdesigner com as tabelas relacionadas.
3.3.2.4
Framework Scriptcase
O ScriptCase é um ambiente para o desenvolvimento em aplicações para a Web com suporte
ao banco de dados PostGreSQL, ele permite a criação de novos sistemas como formulários,
consultas e relatórios.
52
As aplicações do ScriptCase são geradas na linguagem PHP e Javascript. O ambiente de
desenvolvimento é acessado diretamente pelo navegador web.
O ScriptCase é uma ferramenta que deu bastante agilidade e flexibilidade no
desenvolvimento e manutenção do sistema, diminuindo o tempo no desenvolvimento dos módulos
basilares (que não possuem relação direta com o WebGIS) do rastreador geográfico.
Figura 26. Tela Principal do Scriptcase.
3.3.3
Desenvolvimento do Sistema
Após a instalação e configuração das ferramentas a serem utilizadas, iniciou-se a etapa de
desenvolvimento do sistema. Para um melhor entendimento desta etapa, ele foi dividido em três
sub-etapas: (a) cadastro dos dados basilares; (b) alteração do framework Mapserver Guarani para
construção do módulo de cálculo de rotas; e (c) desenvolvimento e integração do algoritmo de
Dijkstra. Estas etapas serão descritas a seguir.
53
3.3.3.1
Cadastro dos dados basilares
Os dados que serão mantidos através dos novos módulos disponíveis aos usuários do sistema
são:
Módulo para o cadastro de Integrados.
São as Unidades de produção de uma determinada empresa, podem-se cadastrar informações
descritivas e geográficas, estas informações estarão disponíveis no módulo WebGIS do Sistema
Rastreador Geográfico. A Figura 27 apresenta a tela de cadastro de integrados.
Figura 27. Tela para cadastro de Integrados.
Sendo que esta figura esta associada ao caso de uso UC00.02.
Módulo para o cadastro de Órgãos responsáveis
Neste módulo são definidos os responsáveis que quando contatados devem tomar uma ação
preventiva ou uma ação de isolação mediante a uma determinada área de exclusão (Figura 28).
54
Figura 28. Tela para cadastro do órgão responsável.
Sendo que esta figura associada ao caso de uso UC00.06.
Módulo para o cadastrado e Áreas de Quarentena
Este módulo é responsável pelo cadastro das áreas de quarentena do sistema através da
definição de um ponto central e um raio (Figura 29). Toda área de quarentena deverá estar
associada a um problema sanitário.
Figura 29. Tela para cadastro da área de quarentena.
Sendo que esta figura esta associada ao caso de uso UC00.01.
55
Módulo para cadastro de Problema Sanitário
Neste módulo são cadastrados os tipos de problemas sanitários que serão utilizados durante
a criação das áreas de quarentena (Figura 30).
Figura 30. Tela para cadastro de problema sanitário.
Sendo que esta figura esta associada ao caso de uso UC00.04.
Módulo para cadastro de Divisão
Este módulo permite o cadastro das divisões de uma empresa, pois ela pode trabalhar com
mais de um segmento de carne (Figura 31).
Figura 31. Tela para cadastro de divisão.
Sendo que esta figura esta associada ao caso de uso UC00.05.
56
Módulo para o cadastro de Tipo de Integrado
O tipo de integrado é a especificação de uma unidade de produção de uma determinada
empresa (Figura 32).
Figura 32. Tela para cadastro de Tipos de Integrados.
Sendo que esta figura esta associada ao caso de uso UC00.03.
Todas essas telas possuem controle conforme o tipo de usuário pré-definido no seu cadastro.
Sendo que cada nova tela feita para o rastreador deve ser cadastrada no sistema, para manter o
controle de acesso. A Figura 33 mostra os programas liberados por usuários.
Figura 33. Tela para manter usuário programa.
Sendo que esta figura esta associada ao caso de uso UC02.01.
57
3.3.3.2
Alteração do Mapserver Guarani
O Framework Mapserver Guarani permite a construção de aplicativos WebGIS contendo um
conjunto padronizado de funcionalidades. Para permitir a integração entre o framework e o módulo
de cálculo de rotas foi necessário realizar algumas mudanças no Mapserver Guarani, permitindo a
adição de um novo módulo no menu flutuante do sistema, denominado Cálculo de Rotas além das
opções existentes por padrão2. Dentre as principais mudanças realizadas pode-se destacar:
•
Alteração do script Menu.js, adicionado uma nova opção denominada calculo de rotas;
•
Criado o script Rotas.js que irá efetuar o calculo de rotas conforme as duas cidades passadas
por parâmetros; e
•
Adicionado o algoritmo de Dijkstra no arquivo Mapscript.php.
3.3.3.3
Algoritmo de Dijkstra
Na pratica, para buscar o menor caminho entre duas cidades, deve-se primeiro deixar dois
campos disponíveis aos usuários que representarão à cidade origem e a cidade destino. Estes
campos estão protegidos contra digitação e os seus valores serão demonstrados em forma de lista de
valores, sendo que as informações que compõe a lista serão buscadas no banco de dados do
Rastreador.
Com a confirmação na escolha das cidades feita pelo o usuário, ele deverá clicar no botão
executar, para que o Mapscript possa executar o algoritmo de Dijkstra. Este algoritmo irá receber
como parâmetros os códigos das cidades origem e destino.
Com esses dois parâmetros, o algoritmo irá executar os seguintes passos:
•
Criar um objeto do tipo mapa que irá utilizar os dados do banco de dados postgres.
•
Definir qual layer que será utilizada, neste caso será a tabela cidade.
2
Atualmente, as opções habilitadas por padrão no Mapserver Guarani são: legenda, carta temática, temas, pesquisa,
análise espacial e calculo de distâncias.
58
•
Buscar todas as informações da tabela cidade
Após isto, o algoritmo irá buscar todas as rodovias que passam entre as cidades escolhidas
ou próximas a elas, conforme um raio pré-determinado. Com isto, é feita uma seleção dos dados na
tabela rodovias buscando todos os seguimentos adjacentes que ligam as duas cidades com os seus
devidos custos e que não estejam dentro de uma área de quarentena ativa, ou seja, não tenha data de
fim preenchida.
Quando uma área de quarentena é definida pelo usuário, ele informa latitude, longitude que
irá compor um ponto e um raio definido em quilômetros. Este raio irá gerar um buffer que é
passado como parâmetro para fazer a intersecção de todas as rodovias que estão dentro deste buffer
e inserindo na tabela rodovias_quarentena. Para isto, foi necessário criar um evento dentro do banco
de dados, que é executado após o cadastro ou atualização da área de quarentena. A figura 34
demonstra a implementação deste evento chamado pr_inserir_quarentena_rodovias. O valor do raio
da quarentena esta sendo multiplicado por 0.01 para converter em quilômetros.
59
-- Function: pr_inserir_quarentena_rodovias()
-- DROP FUNCTION pr_inserir_quarentena_rodovias();
CREATE OR REPLACE FUNCTION pr_inserir_quarentena_rodovias()
RETURNS "trigger" AS
$BODY$
declare
wcd_buffer
geometry;
wcd_rodovia
int4;
cur_buffer_rodovias CURSOR (pcd_quarentena int4) IS select
buffer(the_geom,vl_raio_quarentena * 0.01) as buffer
from quarentena
where cd_quarentena =
pcd_quarentena;
cur_rodovias_quarentena cursor (pcd_buffer geometry) is select cd_rodovia
from rodovias
where intersects(the_geom,
pcd_buffer);
BEGIN
begin
delete from rodovias_quarentena where cd_quarentena = new.cd_quarentena;
end;
--BEGIN
OPEN cur_buffer_rodovias(new.cd_quarentena);
fetch cur_buffer_rodovias into wcd_buffer;
close cur_buffer_rodovias;
null)then
OPEN cur_rodovias_quarentena(wcd_buffer);
LOOP
fetch cur_rodovias_quarentena into wcd_rodovia;
begin
if(wcd_rodovia is not null and new.cd_quarentena is not
(wcd_rodovia,
begin
insert into rodovias_quarentena (cd_rodovia,
cd_quarentena) values
new.cd_quarentena);
exception
when others then
rollback;
end;
end if;
end;
EXIT WHEN NOT FOUND;
END LOOP;
close cur_rodovias_quarentena;
RETURN new;
--END;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION pr_inserir_quarentena_rodovias() OWNER TO postgres;
Figura 34. Algoritmo de Dijkstra
60
O retorno da seleção excluindo todos os segmentos de rodovias que intersectam com o radio
será a matriz de adjacência entre as duas cidades.
A figura (Figura 35) demonstra o código fonte da principal função do sistema denominada
Dijkstra.
function dijkstra($neighbors, $start, $end = null) {
$em_visita = $start;
while (isset($em_visita)) {
$visitado[$em_visita] = 1;
if (is_array($neighbors[$em_visita])){
reset($neighbors[$em_visita]);
while(list($aresta, $distancia) = each($neighbors[$em_visita])) {
if ($visitado[$aresta]){
continue; //vai para o proximo aresta
}
//isset verifica se a variavel existe
$dist = $caminho[$em_visita]["distance"] + $distancia[0];
if (!isset($caminho[$aresta]) || ($dist <
$caminho[$aresta]["distance"])) {
$caminho[$aresta] = $caminho[$em_visita];
$caminho[$aresta][$em_visita] = $distancia[1]; //gid,
identificador unico
$caminho[$aresta]["distance"] = $dist;
}
if ($aresta == $end){
break;
}
}
unset($em_visita);
reset ($caminho);
while(list($aresta, $path) = each($caminho)) {
if ($visitado[$aresta])
continue;
$distancia = $path["distance"];
if (($distancia < $min) || !isset($em_visita)) {
$min = $distancia;
$em_visita = $aresta;
}
}
}
}
}
return $caminho;
Figura 35. Algoritmo de Dijkstra
A função Dijkstra recebe uma seqüência de parâmetros descritos abaixo conforme a ordem
de definição no algoritmo:
•
•
•
$neighbors: é a matriz de adjacência, ou seja, são todos os segmentos que estão conectados
entre si iniciados em uma cidade origem e finalizados em uma cidade destino.
$start: Ponto ou nodo inicial para a execução do laço de repetição.
$end: Ponto ou nodo final para o termino do laço de repetição.
61
Verifica se a variável “caminho” indexada de aresta não esta declarada ou a distancia for
menor que o caminho indexado de “aresta” e “distancia”, se satisfazer esta condição então a
variável “caminho” indexado por “aresta” recebe o valor de “caminho em visita”, a variável
“caminho” indexado em “aresta” e “visita” recebe o valor da “distancia” indexada em “um”
que é um identificador único e o “caminho” indexado por “aresta” e “distancia” recebe o valor
da distancia atual.
Para cada nova interação o algortimo consiste se chegou ao ultimo nodo, caso satisfaça esta
condição ele sai do laço de repetição retornando o caminho de menor custo.
Depois desta verificação este menor caminho é exibindo em forma geométrica para o
usuário através do framework Mapserver Guarani.
3.3.4
Problemas durante a implementação do projeto.
Foram encontrados alguns problemas durante o desenvolvimento do projeto, entre os
principais vale destacar:
•
A configuração do Mapserver Guarani para trabalhar em um ambiente Windows XP,
apesar de rodar em outros sistemas operacionais;
•
Identificação dos shapes files para a importação no banco de dados;
•
As tabelas importadas do IBGE não estavam normalizadas;
•
Criação de uma nova tabela de rodovias baseadas em três arquivos shape file
fornecido pelo IBGE;
•
Manipulação dos segmentos de rodovias a fim de calcular o custo de cada um deles;
•
Busca por software SIG que permita a manipulação dos segmentos de rodovias para
a criação do índice (definição dos nós do matriz de rodovias) utilizado durante o
processamento do algoritmo de Dijkstra.
3.3.5
Testes e Validação do Sistema
A etapa de testes e validação do sistema constitui em uma importante etapa do projeto,
sendo necessária para realizar a correção de eventuais problemas ocorridos durante as fases de
modelagem e implementação.
62
Cabe ressaltar que, durante a preparação da base cartográfica de rodovias e
conseqüentemente, durante os testes e validação do sistema, optou-se por restringir a área de
atuação do algoritmo, utilizando a malha viária do estado de Santa Catarina e entorno.
Esta decisão deve-se a complexidade existente para a geração dos nós e custos da malha
viária brasileira, visto que o arquivo shape file de rodovias fornecidas pelo IBGE possui uma série
de limitações, como caminhos não concluídos e desatualização da base que precisam ser sanados
antes que seja possível utilizá-lo em algoritmos de roteirização.
Os testes e avaliações contemplados nesta fase foram:
•
Funcionamento dos módulos básicos do sistema: manutenção de tipo de integrado;
manutenção de integrado; manutenção de órgão responsável; manutenção de
problema sanitário; manutenção de divisão e manutenção de usuário;
•
Cadastro de áreas de quarentena: Foram realizados os testes para verificar a criação
das áreas de quarentena e também para validar se os segmentos de rodovias foram
corretamente associados a uma determinada área de quarentena;
•
Funcionamento do algoritmo de cálculo de rotas: Durante esta etapa, foram
realizados testes de performance do algoritmo e verificação dos resultados,
principalmente em relação ao desvio das áreas de quarentena.
4 TRABALHOS FUTUROS
O novo módulo adicionado ao sistema, não faz distinção por tipo de cargas, ou seja, ele não
considera a carga viva que esta sendo transportada, pois pode haver áreas de exclusão que
influenciam somente a um determinado tipo de animal, por exemplo, deve-se fazer uma viagem
transportando aves e o sistema encontra uma área de quarentena com a doença de febre aftosa,
então o sistema irá desconsiderar todos os segmentos que estão no raio do foco da doença, sem
considerar que a carga que esta sendo transportada é de aves e que a doença não iria causar nenhum
dano, então esta viagem poderia ser feita por estes segmentos excluídos.
Pode-se adicionar ao sistema, informações como sentidos da malha viária, desvios,
bloqueios rodoviários e pedágios para que possam ser visualizados no rastreador.
63
O sistema não possui um cadastro dos caminhões que fazem o transporte das cargas vivas
para efetuar notificações necessárias como desvios de rotas e bloqueios.
Também se pode criar um novo módulo ao sistema para gerar números de viagem de
transporte contendo o lote de produção dos animais, qual a sua matriz e o seu destino.
Em próximos projetos, esse trabalho também pode ser utilizado juntamente com um sistema
GPS (Global Positioning System), e um sistema embarcado nos caminhões onde que o condutor do
veículo possa desviar das áreas em risco.
5 CONCLUSÃO
Percebe-se que a área de geotecnologia vem sendo explorada cada vez mais, tendo em vista,
que os sistemas tornam-se cada vez mais complexos e os clientes mais exigentes. Em uma empresa
o rastreador geográfico para sanidade animal deve destinar-se a auxiliar e automatizar e gerenciar as
unidades de produção.
O novo módulo adicionado ao Rastreador Geográfico deve agregar valor para o
gerenciamento logístico no transporte de cargas vivas, principalmente no caso de transporte de
animais destinados ao abate para o consumo humano, pois a perda por manuseio inadequado ou
infecção por alguma doença, acaba se transformando em prejuízo para a industria ou para o
produtor. Para evitar que isso aconteça, tanto o produtor rural quanto o industrial deve reduzir ao
mínimo o tempo de viagem e oferecer as condições necessárias para garantir que o animal chegue
ao abatedouro em perfeitas condições de sanidade. Para a realização deste projeto foi necessário
efetuar um estudo a respeito de rotas e algoritmos de roteamento.
Também foi estudado o banco de dados PostGreSQL e seu módulo PostGIS responsáveis
por manipular dados descritivos e dados geométricos. E que ele pudesse disponibilizar essas
informações através do uso de map files, para que framework Mapserver Guarani utilize essas
informações.
Para permitir a avaliação do módulo de cálculo de rotas, foram gerados alguns novos
módulos para proverem parâmetros na execução do algoritmo ou para permitirem a execução do
64
programa no banco de dados PostGreSQL, pois a versão original do Sistema Rastreador Geográfico
encontra-se desenvolvida para o banco de dados Oracle sem o suporte espacial.
Com as informações disponíveis no novo banco e com o módulo adicionado, o usuário pode
monitorar as suas unidades de produção e ou acionar os órgãos responsáveis, tomar decisões
gerenciais para não perder foco e credibilidade no mercado como, por exemplo, parar uma unidade
de produção que esta dentro de uma área de quarentena ou alterar uma reserva de estoque para uma
outra unidade de produção ou ainda aumentar ou diminuir o turno de produção.
Este gerenciamento é realizado pela internet, onde se podem identificar claramente as
unidades de produção que estão dentro de uma área de quarentena a fim de evitar a disseminação de
uma determinada doença.
65
REFERÊNCIAS BIBLIOGRÁFICAS
CARVALHO, BRUNO MIGUEL PACHECO SARAIVA Disponível em <:http://scholar.
google.com.br/url?sa=U&q=http://student.dei.uc.pt/~brunomig/CP/Artigo.pdf> Acesso em: 15
maio 2006.
BUGHI, CARLOS HENRIQUE. Framework MapServer Guarani, apresentação e treinamento
introdutório. In: ENCONTRO NACIONAL DE USUÁRIOS MAPSERVER, 2., 2005, Itajaí.
Anais… Itajaí : UNIVALI, 2005. 1 CD-ROM.
BODIN, L.D.; B. GOLDEN; A. ASSAD; M. BALL. Routing and scheduling of vehicles and
crews: the state of the art. In: Computers and Operations Research, vol.10, n.2, 1983.
CÂMARA, G. ; DAVIS, C. Introdução à Ciência da Geoinformação. Disponível em:
<http://www.dpi.inpe.br/gilberto/livro/introd/>. Acesso em: 10 abr. 2006.
COSTA M. Crise no agro negócio: reflexos na sociedade. [S.l.]: Agronline. Disponível em:
http://www.agronline.com.br/artigos/artigo.php?id=314. Acesso em: 09 maio 2006.
CUNHA, C.B. Uma contribuição para o problema de roteirização de veículos com restrições
operacionais. (Tese de Doutoramento) São Paulo: EPUSP, (1997). Departamento de Engenharia de
Transportes. 222p.
DIJKSTRA, E.W. Dijkstra Archive. Disponível em:http://www.cs.utexas.edu/use
rs/EWD/. Acesso em 25 maio 2006.
EGENHOFER, M.; FRANK, A. Objetc-Oriented Modeling for GIS. Journal of the Urban and
Regional Information System Association 4(2): 3-19, 1992.
FSF. Free Software Foundation. Disponível em www.fsf.org. Acesso em: 23 Outubro 2006.
LCA, Laboratório de Computação Aplicada da Universidade do Vale do Itajai. Itajaí, 2006.
Contribuição em 25 abr. 2006. Disponível em: <http://www.univali.br/g10>. Acesso em: 30 abr.
2006.
LAPORTE, G.; M. GENDREAU; J.Y. POTVIN; F. SEMET. Classical and modern heuristics for
the vehicle routing problem. In: International Transactions in Operational Research, v.7, n.4/5,
p.285-300, 2000.
LAUDON, K.C; LAUDON; J.P. Sistemas de Informações Gerenciais. 5ª ed. São Paulo: Prentice
Hall, 2004.
MAPSERVER. MapServer Website. Disponível em: <http://mapserver.gis.umn.edu/>. Acesso em:
10 abr. 2006.
NETCRAFT, Web Server Survey. Bath, 2006. Disponível em:
<http://news.netcraft.com/archives/2006/05/09/may_2006_web_server_survey.html>. Acesso em:
15 maio 2006.
NOVAES, A.G.N. Sistemas Logísticos: transporte, armazenagem e distribuição de produtos. São
Paulo: Edgard Blucher, 1989.
OLIVEIRA NETO, O. J. de. Redes de informação: essência do planejamento na tomada de
decisões estratégicas no agronegócio. Disponível em:
http://www.agronline.com.br/artigos/artigo.php?.id=192. Acesso em 09 maio 2006.
PHP. The PHP Group, Disponível em: <http://www.php.net/> Acesso em: 12 abr. 2006.
PITUCO, E. M. A importância da Febre Aftosa em Saúde Pública. Instituto Biológico, 2001.
Disponível em: < http://www.biologico.sp.gov.br/noticias/febre%20aftosa.htm>. Acesso em 09
maio 2006.
POSTGRESQLSITE Disponível em: http://www.postgresql.org/ Acesso em 10 maio 2006.
REZENDE, Denis A., ABREU, Aline F. Tecnologia da Informação Aplicada a Sistemas de
informação Empresariais. São Paulo: Atlas, 2000.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados:
tradução de Marília Guimarães Pinheiro e Cláudio César Canhette. 3 ed. São Paulo: Makron Books,
1999. 767p.
SPERB, R.M.;CABRAL, R.B.;TRIPODI, R.Z. Tecnologia Open Source para rastreamento on-line
de veículos monitorados via satélite. In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, 2.,
2002, Itajaí. Anais... Itajaí, 2002. CD-ROM.
SPRING: Tutorial de Geoprocessamento. São José dos Campos, 2003. Disponível em:
<http://www.dpi.inpe.br/spring/teoria/>. Acesso em: 20 abr. 2006.
67
APÊNDICES
68
A RASTREADOR GEOGRÁFICO
Segue abaixo um breve manual do Rastreador Geográfico demonstrando as suas
funcionalidades.
Menu de Configuração.
2
4
1
3
Figura 36. Interface do Sistema Rastreador Geográfico, com destaque ao menu de configuração.
Fonte: LCA (2006).
A Figura 36 apresenta a interface do sistema, com destaque ao menu de customização da
área da tela destinada ao mapa (1), conforme a preferência do usuário. Esta é uma das opções do
menu do sistema (2), que é composto ainda pelos mapeamentos temáticos (Camadas), Cálculo de
Distâncias, Análise de Concorrentes, Análise Espacial e Análise de Vizinhança. Esta interface foi
desenvolvida para aproveitar ao máximo a área disponível da tela para a realização de análises
espaciais. Assim, tanto o Menu, quanto o mapa de referência dinâmica (3) são flutuantes e podem,
eventualmente, ser minimizados. Outra funcionalidade importante do sistema consiste no registro
de um histórico para as ações anteriormente executadas (4), facilitando o retorno à tela
anteriormente preparada.
5
6
Figura 37. Interface do Sistema Rastreador Geográfico, com destaque ao menu mapas temáticos.
Fonte: LCA (2006).
A Figura 37 apresenta o menu de mapas temáticos (5), com a seleção de unidades de
produção acionado. Este menu permite que diferentes temas sejam “ligados” para visualização e
consulta. No exemplo da Figura 2, as instalações de produção de frango (6) devidamente
encontram-se geo-referenciadas.
A Figura 38 apresenta a Análise de Vizinhança, funcionalidade primordial do sistema.
Através dela o usuário pode identificar uma unidade de produção com problemas de sanidade
animal, e a partir dela determinar uma área circunvizinha, segundo um raio de segurança conhecido.
Neste procedimento, toda unidade de produção que por ventura esteja dentro desta área, será
automaticamente selecionada, e listada em um relatório em formato html ou pdf (8) como áreas de
quarentena ou exclusão.
70
7
8
Figura 38. Interface do Sistema Rastreador Geográfico, com destaque ao menu de análise de
vizinhança.
Fonte: LCA (2006).
71
9
Figura 39. Interface do Sistema Rastreador Geográfico, com destaque ao menu de análise de
espacial.
Fonte: LCA (2006).
Este tipo de informação pode ser complementarmente analisado frente outros dados
espaciais (Figura 39), como estados, municípios, rodovias, ou mesmo unidades de produção
pertencentes ao outras empresas. A consulta é realizada selecionando-se a área desejada, o que
retorna uma lista de informações agrupadas segundo sua categoria (9). No exemplo da figura, os
temas estados, municípios e rodovias foram consultados. Os detalhes de cada item podem ser
observados através de sua seleção. Este procedimento pode ser visto na Figura 40, só que para
dados associados às unidades de produção (10).
72
10
Figura 40. Interface do Sistema Rastreador Geográfico, com destaque a consulta espacial para
unidade de produção.
Fonte: LCA (2006).
Também é importante, para efeitos de análise, a possibilidade de cálculo de distâncias,
conforme apresentado na Figura 41. Esta funcionalidade permite a determinação da distância entre
dois ou mais pontos, com a opção de escolha da unidade de referência (milha, km, pés, metros).
73
10
Figura 41. Interface do Sistema Rastreador Geográfico, com destaque ao menu de cálculo de
distância.
Fonte: LCA (2006).
74