TCC - EIDER - DESENVOLVIMENTO DE UM MÓDULO SIG WEB PARA REPRESENTAÇÃO ESPACIAL DE PROPRIEDADES...

UNIVERSIDADE FEDERAL DO ACRE

CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

DESENVOLVIMENTO DE UM MÓDULO SIG WEB PARA REPRESENTAÇÃO

ESPACIAL DE PROPRIEDADES RURAIS E GLEBAS

RIO BRANCO

2012

EIDER CARLOS PAULINO SILVA



Monografia apresentada como exigência parcial para obtenção do grau de bacharel em Sistemas de Informação da Universidade Federal do Acre. Profª. Orientadora: Laura Costa Sarkis, M.Sc. Prof. Co-orientador: Paulo Guilherme Salvador Wadt, D.Sc.

RIO BRANCO

2012

TERMO DE APROVAÇÃO

EIDER CARLOS PAULINO SILVA



Esta monografia foi apresentada como Trabalho de Conclusão de Curso de Bacharelado em Sistemas de Informação da Universidade Federal do Acre, sendo aprovado pela banca constituída pelo professor orientador e membros abaixo mencionados.

Compuseram a banca:

Profª. Laura Costa Sarkis, M.Sc. (Orientadora) Curso de Bacharelado em Sistemas de Informação

Prof. Luiz Augusto Matos da Silva, M.Sc. Curso de Bacharelado em Sistemas de Informação

Prof. Manoel Limeira de Lima Junior, Esp. Curso de Bacharelado em Sistemas de Informação

Rio Branco, 31 de Janeiro de 2012

À Deus, Família e Amigos

AGRADECIMENTOS

“Com carinho especial dedico esta obra àquele que é fonte de iluminação

permanente e em quem todos os tesouros da sabedoria estão ocultos. Àquele cuja

graça me alcançou e me fez seu Servo. Àquele que é poderoso para fazer

infinitamente mais do que tudo quanto pedimos ou pensamos conforme Seu poder

opera em nós.” (Leandro Tarrataca)

À Maria da Conceição, minha mãe que suportou todas as dificuldades para

cuidar da família.

Ao meu Pai Ediu Carlos da Silva, que incentivou e ajudou diretamente, se

esforçando sempre em levar eu e meu irmão juntos pra estudar, em sua super moto,

mesmo nas piores chuvas e com muita lama no Ramal do Moreira.

À meu irmão gêmeo Ediu Carlos da Silva Júnior, pelo companheirismo nos

estudos, principalmente nos “Corujões” de competição para ver quem ficava mais

tempo acordado e estudando.

À meu irmão mais velho Javã Sousa Costa, que me incentivou e proporcionou

que eu pudesse amar a área de computação. Além de ter proporcionado meu

primeiro computador, um dos presentes inesquecíveis para mim.

Aos meus avós Oscarina e Sinval que mesmo tendo mais de 80 anos,

demonstram esforço e força de vontade, e ao observar a atitude deles, tenho mais

inspiração, tentando ao máximo me esforçar em tudo que faço.

À EMBRAPA-AC, equipe de informática do laboratório de solos, onde fiquei

por mais de três anos estagiando e especialmente ao Dr. Paulo Guilherme Salvador

Wadt que contribuiu substancialmente na evolução de meus conhecimentos, Rogério

de Castro Mesquita dos Santos e Olacir Rodrigues Castro Júnior que foram os

pioneiros da equipe a explorar a tecnologia abordada neste trabalho.

À orientadora Laura Costa Sarkis, pela paciência e auxílio durante a

elaboração deste trabalho.

Aos professores da UFAC, pelo empenho e a preocupação em nos

proporcionar conhecimentos importantes.

À todos os colegas de turma, destacando-se Allan Alves que me deu um

Notebook em um dos momentos de dificuldade, Victor Henrique por ter

proporcionado o companheirismo durante os estudos em sua casa, Leandro

Ferrarezi e Natanael Castro, considerado por mim os “Pais” dessa turma, se

disponibilizando sempre para ajudar os colegas.

Que os vossos esforços desafiem as impossibilidades,

lembrai-vos de que as grandes coisas do homem foram

conquistadas do que parecia impossível.

Charles Chaplin

RESUMO

A utilização de Sistemas de Informações Geográficos (SIG) tem se tornado essencial para a realização de estudos precisos sobre fenômenos que ocorrem na superfície terrestre. Diversas áreas de conhecimento estão adquirindo e se beneficiando do apoio desta tecnologia, que tem evoluído substancialmente possibilitando o gerenciamento de dados geográficos na web. Dessa forma, este trabalho visa o desenvolvimento de um módulo SIG WEB (Sistema de Informação Geográfica baseada em ambiente web) para representar geograficamente as áreas de propriedades rurais e glebas tratadas pelo Sistema Integrado de Diagnose e Recomendação (DRIS). Para a construção deste módulo, foram desenvolvidas as atividades de levantamento de requisitos e modelagem, configuração do banco de dados geográficos, instalação e configuração do servidor de mapas, prototipação, implementação e testes. Dentre várias funcionalidades, o sistema DRIS aplica a automatização no processo de avaliação nutricional de culturas agrícolas. Por isso, ao ampliar a capacidade deste sistema, o desenvolvimento do módulo visa a contribuição com a eficiência no processo de avaliação nutricional de plantas.

Palavras-chave: SIG WEB, avaliação nutricional de culturas agrícolas, DRIS.

ABSTRACT

The use of Geographic Information Systems (GIS) has become essential to perform accurate studies on phenomena that occur on Earth's surface. Several areas of expertise are acquiring and benefiting from the support of this technology, which has evolved substantially enabling management of geographic data on the web Thus, this work aims to develop a module WEB GIS (Geographic Information System web-based environment) to represent geographical areas of farms and plots addressed by the Diagnosis and Recommendation Integrated System (DRIS). To build this module, was developed the activities requirements elicitation and modeling, database configuration of spatial data, installation and configuration of the map server, prototyping, implementation and testing. Among many features, the system applies DRIS automation in the process of evaluating nutritional status of crops. Therefore, by expanding the capacity of this system, the development of the module aims to contribute to efficiency in the process of nutritional assessment of crops.

Key-words: WEB GIS, nutritional assessment of crops, DRIS.

LISTAS DE QUADROS

QUADRO 1 - EXEMPLO DE LOCALIZAÇÕES REPRESENTADAS POR

COORDENADAS GEOGRÁFICAS. ......................................................................... 20

QUADRO 2 - PRINCIPAIS FUNÇÕES DO POSTGIS. ............................................. 32

QUADRO 3 - CÓDIGO PARA ADICIONAR ÍNDICE GIST EM UMA TABELA. ....... 32

QUADRO 4 - REPRESENTAÇÃO DE DADOS NO FORMATO WKB. .................... 33

QUADRO 5 - PRINCIPAIS VANTAGENS E DESVANTAGENS DA

PROTOTIPAÇÃO DE BAIXA- E ALTA-FIDELIDADE. ............................................. 44

QUADRO 6 - EXEMPLO DE CENÁRIO DE USO. .................................................... 46

QUADRO 7 - LEIS DE LEHMAN. ............................................................................. 47

QUADRO 8 - TRECHO DE TEXTO CAPTURADO DO ANEXO A – UTILIZAÇÃO

DO SISTEMA DRIS................................................................................................... 65

QUADRO 9 - LISTA DE REQUISITOS FUNCIONAIS PARA IMPLEMENTAÇÃO NO

MÓDULO. ................................................................................................................. 66

QUADRO 10 - EXEMPLIFICAÇÃO DE CÓDIGO PARA INCLUSÃO DA

BIBLIOTECA OPENLAYERS E DA API GOOGLE MAPS. ..................................... 79

LISTA DE FIGURAS

FIGURA 1 - ARQUITETURA DE UM SIG. ................................................................ 26

FIGURA 2 - ELEMENTOS DE UM SIG WEB. .......................................................... 28

FIGURA 3 - TIPOS DE DADOS GEOGRÁFICOS DO POSTGIS. ............................ 31

FIGURA 4 - ESTRUTURA DA TABELA SPATIAL_REF_SYS DA EXTENSÃO

POSTGIS. ................................................................................................................. 34

FIGURA 5 - ESTRUTURA DA TABELA GEOMETRY_COLUMNS DA EXTENSÃO

POSTGIS. ................................................................................................................. 35

FIGURA 6 - ESQUEMA DE FUNCIONAMENTO DO SERVIÇO WFS. .................... 37

FIGURA 7 - EXEMPLO DE APLICAÇÃO IMPLEMENTADA COM OPENLAYERS.

.................................................................................................................................. 38

FIGURA 8 - APLICAÇÃO CRIADA COM A API DO GOOGLE MAPS PARA

REPRESENTAR GEOGRAFICAMENTE OS PRINCIPAIS PONTOS DA

UNIVERSIDADE FEDERAL DE VIÇOSA. ................................................................ 40

FIGURA 9 - MODELO DE PROTOTIPAGEM DE SISTEMA DE SOFTWARE. ........ 43

FIGURA 10 - REPRESENTAÇÃO DE UM DIAGRAMA DE CASO DE USO. .......... 45

FIGURA 11. ESQUEMA DO TESTE DE UNIDADE. ................................................ 50

FIGURA 12 - ESTRUTURA BÁSICA DE UM DOCUMENTO HTML. ....................... 52

FIGURA 13 – ESTRUTURA DE UMA REGRA EM CSS. ......................................... 53

FIGURA 14 – ESQUEMA DE FUNCIONAMENTO DO PHP. ................................... 56

FIGURA 15 - MODELO CONVENCIONAL DE APLICAÇÃO WEB. ........................ 57

FIGURA 16 - MODELO DE APLICAÇÃO WEB BASEADA EM AJAX. ................... 58

FIGURA 17 – ESQUEMA DE FLUXO DAS ATIVIDADES DESENVOLVIDAS

DURANTE O ESTUDO DE CASO. ........................................................................... 59

FIGURA 18 – INTERFACE DO SISTEMA DRIS VISUALIZADA APÓS A ESCOLHA

DE UMA CULTURA AGRÍCOLA. ............................................................................. 61

FIGURA 19 – INTERFACE DO SISTEMA DRIS PARA CADASTRO DE ANÁLISE

FOLIAR. .................................................................................................................... 62

FIGURA 20 – RELATÓRIO COM DIAGNÓSTICO NUTRICIONAL DE CULTURAS

AGRÍCOLAS DO SISTEMA DRIS. ........................................................................... 63

FIGURA 21 - DIAGRAMA DE CASO DE USO DO MÓDULO. ................................. 66

FIGURA 22 – ESTRUTURA DAS TABELAS “ESTABELECIMENTOS” E

“GLEBAS”. ............................................................................................................... 68

FIGURA 23 - REGISTROS DA TABELA “ESTABELECIMENTOS”. ...................... 68

FIGURA 24 - REGISTROS DA TABELA GLEBAS. ................................................. 69

FIGURA 25 - CÓDIGO PARA ADICIONAR CAMPOS GEOMÉTRICOS NAS

TABELAS “ESTABELECIMENTOS” E “GLEBAS”. ............................................... 69

FIGURA 26 - CÓDIGO PARA ACRESCENTAR ÍNDICES NAS TABELAS

“ESTABELECIMENTOS” E “GLEBAS”. ................................................................. 69

FIGURA 27 - ETAPA FINAL DO PROCESSO DE INSTALAÇÃO E

CONFIGURAÇÃO DO GEOSERVER. ...................................................................... 71

FIGURA 28 - PROTOTIPAÇÃO PARA AGRUPAR EM UMA TELA O

GERENCIAMENTO DE DADOS CONVENCIONAIS E GEOGRÁFICOS. ............... 72

FIGURA 29 - ESQUEMA DE PROTOTIPAÇÃO PARA SEPARAÇÃO DE DADOS

CONVENCIONAIS E GEOGRÁFICOS DO MÓDULO. ............................................. 73

FIGURA 30 - INTERFACE PARA LISTAGEM DE ESTABELECIMENTOS. ............ 74

FIGURA 31 - INTERFACE PARA LISTAGEM DE GLEBAS. ................................... 75

FIGURA 32 - RESULTADO DA INTERFACE PARA LISTAGEM DE

ESTABELECIMENTOS. ........................................................................................... 76

FIGURA 33 - TRECHO DE CÓDIGO QUE ENVIA DADOS DE FORMA

ASSÍNCRONA PARA O ARQUIVO “GEO_SISTEMA.PHP”. .................................. 76

FIGURA 34 - TRECHO DE CÓDIGO DO ARQUIVO “GEO_SISTEMA.PHP”,

RESPONSÁVEL POR EXECUTAR UMA CONSULTA SQL VINDA DE UMA

SOLICITAÇÃO ASSÍNCRONA. ................................................................................ 77

FIGURA 35 - EXEMPLO DE INTERFACE CLIENTE PARA CADASTRO DE

INFORMAÇÕES CONVENCIONAIS. ....................................................................... 78

FIGURA 36 - TRECHO DE CÓDIGO PARA CRIAÇÃO DO MAPA, CAMADA BASE,

PRINCIPAIS CONTROLES E CONEXÃO COM O SERVIÇO WFS. ........................ 80

FIGURA 37 - INTERFACE IMPLEMENTADA COM OPENLAYERS PARA

MANIPULAR DADOS ADQUIRIDOS DA CAMADA DE INFORMAÇÕES DO

GEOSERVER. ........................................................................................................... 80

FIGURA 38 - JANELA PARA CRIAR GEOMETRIA POR MEIO DE


FIGURA 39 - TRECHO DE CÓDIGO PARA CAPTURA E CÁLCULO DE


FIGURA 40 - JANELA PARA SELEÇÃO DE UM SISTEMA DE REFERÊNCIA

ESPACIAL. ............................................................................................................... 83

FIGURA 41 - EXEMPLO DE GEOMETRIA ADICIONADO POR COORDENADAS

GEOGRÁFICAS PARA REPRESENTAÇÃO GEOGRÁFICA DE UM

ESTABELECIMENTO. .............................................................................................. 84

FIGURA 42 - EXECUÇÃO DE TESTES UTILIZANDO A FERRAMENTA PARA

DESENVOLVEDORES INTEGRADA AO NAVEGADOR GOOGLE CHROME. ...... 86

LISTA DE FIGURAS - APÊNDICE C

FIGURA 1 - SOLICITAÇÃO DO DIRETÓRIO ONDE O JDK ESTÁ INSTALADO. 102

FIGURA 2 - SOLICITAÇÃO DE USUÁRIO E SENHA DURANTE A INSTALAÇÃO

DO GEOSERVER. .................................................................................................. 102

FIGURA 3 - TELA PRINCIPAL DO SERVIDOR DE MAPAS GEOSERVER. ........ 103

FIGURA 4 - CADASTRAMENTO DE UM WORKSPACE PARA IDENTIFICAR OS

SERVIÇOS DISPONIBILIZADOS PELO GEOSERVER A UMA DETERMINADA

APLICAÇÃO. .......................................................................................................... 104

FIGURA 5 - FONTES DE DADOS SUPORTADOS PELO GEOSERVER.............. 104

FIGURA 6 - INFORMAÇÕES DO BANCO DE DADOS PARA CONEXÃO COM O

GEOSERVER. ......................................................................................................... 105

FIGURA 7 - LISTA DE TABELAS RECUPERADAS PELO GEOSERVER PARA

QUE O USUÁRIO POSSA SELECIONAR QUAIS SÃO FONTES DE DADOS

GEOGRÁFICOS. .................................................................................................... 106

FIGURA 8 - CONFIGURAÇÃO DE LAYER PARA PUBLICAÇÃO DOS DADOS

GEOGRÁFICOS ARMAZENADOS NAS TABELAS. ............................................. 107

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 16

1.1 PROBLEMA DA PESQUISA .................................................................... 17

1.2 OBJETIVOS DA PESQUISA ...................................................................... 19

1.2.1 OBJETIVO GERAL .......................................................................... 19

1.2.2 OBJETIVOS ESPECÍFICOS ............................................................ 19

1.3 JUSTIFICATIVA .......................................................................................... 20

1.1 METODOLOGIA ....................................................................................... 21

1.5 ORGANIZAÇÃO DO ESTUDO ................................................................... 22

2 SISTEMAS DE INFORMAÇÕES GEOGRÁFICAS ................................................ 24

2.1 BREVE HISTÓRICO ................................................................................... 24

2.2 DEFINIÇÃO E ARQUITETURA .................................................................. 25

2.3 SIG WEB ..................................................................................................... 27

2.4 ARMAZENAMENTO E MANIPULAÇÃO DE DADOS GEOGRÁFICOS .... 29

2.4.1 POSTGRESQL E A EXTENSÃO POSTGIS ..................................... 29

2.4.2 FORMATO DE DADOS GEOGRÁFICOS WKT E WKB ................... 32

2.4.3 SISTEMA DE REFERÊNCIA ESPACIAL ......................................... 34

2.5 TECNOLOGIAS E SERVIÇOS WEB PARA SISTEMAS GEOESPACIAIS35

2.5.1 SERVIDOR DE MAPAS GEOSERVER............................................ 35

2.5.2 SERVIÇO WFS ................................................................................ 36

2.5.3 BIBLIOTECA OPENLAYERS ........................................................... 37

2.5.4 API GOOGLE MAPS ........................................................................ 39

3 ENGENHARIA E MODELAGEM DE SOFTWARE ................................................ 41

3.1 MODELOS DE PROCESSO DE SOFTWARE E PROTOTIPAÇÃO........... 41

3.2 MODELAGEM DE CASO DE USO ............................................................. 45

3.3 MANUTENÇÃO E EVOLUÇÃO DE SOFTWARE ...................................... 47

3.4 TESTE DE UNIDADE DE SOFTWARE ...................................................... 48

4 TECNOLOGIAS PARA DESENVOLVIMENTO WEB ............................................ 51

4.1 LINGUAGEM HTML ................................................................................... 52

4.2 CASCADING STYLE SHEETS ................................................................... 53

4.3 LINGUAGEM JAVASCRIPT E BIBLIOTECA JQUERY ............................. 54

4.4 LINGUAGEM DE PROGRAMAÇÃO PHP .................................................. 55

4.5 TECNOLOGIA AJAX .................................................................................. 57

5. ESTUDO DE CASO .............................................................................................. 59

5.1 VISÃO GERAL ............................................................................................ 60

5.2 FERRAMENTAS UTILIZADAS ................................................................... 64

5.3 LEVANTAMENTO DE REQUISITOS E MODELAGEM.............................. 65

5.4 CONFIGURAÇÃO DO BANCO DE DADOS GEOGRÁFICO ..................... 68

5.5 INSTALAÇÃO E CONFIGURAÇÃO DO SERVIDOR DE MAPAS ............. 70

5.6 PROTOTIPAÇÃO ....................................................................................... 71

5.7 IMPLEMENTAÇÃO DA INTERFACE CLIENTE ......................................... 74

5.7.1 GERENCIAMENTO DE DADOS CONVENCIONAIS ....................... 74

5.7.2 GERENCIAMENTO DE DADOS GEOGRÁFICOS .......................... 78

5.8 TESTES ...................................................................................................... 85

5.9 RESULTADOS OBTIDOS .......................................................................... 86

6 CONSIDERAÇÕES FINAIS E RECOMENDAÇÕES ............................................. 88

6.1 CONSIDERAÇÕES FINAIS ........................................................................ 88

6.2 RECOMENDAÇÕES ................................................................................... 89

REFERÊNCIAS ......................................................................................................... 91

APÊNDICES ............................................................................................................. 95

APÊNDICE A – CENÁRIO DE USO DO MÓDULO .................................................. 96

APÊNDICE B – DOCUMENTO DE REQUISITOS DO MÓDULO ............................. 98

APÊNDICE C – INSTALAÇÃO E CONFIGURAÇÃO DO GEOSERVER ............... 101

APÊNDICE D – VALIDAÇÃO TOPOLÓGICA DE GLEBAS .................................. 108

ANEXOS ................................................................................................................. 111

ANEXO A – UTILIZAÇÃO DO SISTEMA DRIS .............................................. 112

1 INTRODUÇÃO

A representação de áreas geográficas em mapas é uma necessidade humana

desde épocas antigas, tendo o seu desenvolvimento fortalecido na época em que

atividades como, o comércio, viagens e a pesca eram dependentes das navegações

marítimas, que geralmente aconteciam a quilômetros de distância da costa

continental. Essas atividades também envolviam riscos, tendo como motivo principal

a falta de conhecimento sobre a localização do ponto de origem, de destino, de onde

se encontrava e a rota que deve ser percorrida. Por este motivo, houve um grande

avanço no estudo e desenvolvimento de técnicas, que compreendem desde cálculos

complexos que envolvem o estudo da álgebra, equipamentos como a bússola,

astrolábio e outros que utilizam como parâmetro a observação das estrelas, até o

GPS (Global Positioning System) como resultado do desenvolvimento tecnológico

atual. Este avanço ocorreu com o objetivo de não apenas facilitar as navegações

marítimas, mas também auxiliar na localização e estudo do ambiente terrestre, por

meio de técnicas para verificação de fenômenos que levam em conta a localização

espacial onde ocorrem, como é o caso do sensoriamento remoto feito através do

processamento computacional de imagens.

A constante evolução da geoinformação tem de maneira notável melhorado a

forma de manipular as informações espaciais. Observa-se principalmente porque

antes, a área ou localização de uma superfície terrestre era representada por mapas

estáticos, ou seja, em um papel, em imagens ou por caracteres alfanuméricos

composto por coordenadas geográficas. Já nos dias atuais, principalmente após o

17

surgimento dos aplicativos Google Maps e Google Earth, a representação geográfica

se tornou dinâmica e a disponibilidade é totalmente diferente, estando acessível a

todos por meio da internet (SILVA, 2011; CÂMARA et al., 2003).

Um dos exemplos de representação geográfica por caracteres alfanuméricos

é o sistema web DRIS (Sistema Integrado de Diagnose e Recomendação) disponível

no endereço (www.dris.com.br). O DRIS é utilizado para mensurar o nível de

nutrição de lavouras agrícolas e posteriormente fornecer a informação necessária

para tomadas de decisões. Portanto, o fator mais importante a ser observado é o

forte relacionamento entre as lavouras e suas respectivas localizações, ou seja,

onde foram plantadas, o que é constantemente explorado durante a utilização deste

sistema, e sem dúvidas requer um aprimoramento em sua capacidade de

georreferenciamento.

Este trabalho tem como escopo, utilizar a tecnologia da informação aliada aos

recursos fornecidos pela internet, e aplicar os conhecimentos de SIG WEB

(Sistemas de Informações Geográficas baseados na web) no desenvolvimento de

um módulo para o sistema DRIS, com o objetivo de melhorar a forma como as

informações com características geográficas são processadas neste sistema, além

de apoiar e tornar mais eficiente as avaliações nutricionais de lavouras.

1.1 PROBLEMA DA PESQUISA

O Sistema Integrado de Diagnose e Recomendação (DRIS) consiste em uma

metodologia para a avaliação do estado nutricional de culturas agrícolas com a

finalidade de gerenciar as adubações. Por ser um método que exige grande volume

de cálculos matemáticos, sua aplicação depende da informatização para que possa

ser utilizado, o que tem sido feito por meio de planilhas eletrônicas ou softwares em

diversas plataformas operacionais.

Os diferentes sistemas disponíveis baseados na metodologia DRIS possuem

níveis variáveis de complexidade, incluindo sistemas que utilizam planilhas

eletrônicas com restrições à gestão dos dados e das informações, bem como

sistemas baseados em banco de dados como o Microsoft Access, com maior

18

amplitude na utilização dos dados, até mesmo sistemas baseados em banco de

dados gerenciado pela internet.

Uma das formas automatizadas que aplica a metodologia DRIS, encontra-se

acessível a partir do endereço (www.dris.com.br), que consiste num software web

desenvolvido e mantido pela equipe do laboratório de solos da Empresa Brasileira

de Pesquisa Agropecuária (EMBRAPA-AC) na cidade de Rio Branco/AC.

Este software trabalha com o tratamento de várias informações que envolvem

o processo de avaliação nutricional de culturas agrícolas, incluindo desde os

responsáveis pelas áreas de terras que abrigam as lavouras até as análises que são

realizadas para mensurar o nível de nutrição das plantas.

As áreas de terras consistem em estabelecimentos (propriedades rurais) e

suas glebas (unidades de produção), as quais possuem uma localização real na

superfície terrestre, o que são representadas no sistema DRIS em forma de

caracteres alfanuméricos das coordenadas geográficas.

Com base nesses fatores, foi estudada uma forma de evoluir o sistema DRIS

adotando os principais conceitos de SIG WEB, verificando a necessidade de

representar geograficamente não apenas a localização (que é feita no sistema por

meio de caracteres alfanuméricos de coordenadas geográficas), mas a delimitação

geométrica das áreas de propriedades rurais e glebas, organizando e relacionando

dados convencionais e geográficos em um mesmo banco de dados relacional.

Diante do exposto questiona-se, como ampliar o sistema DRIS, possibilitando

a representação geográfica das áreas de propriedades rurais e glebas e

relacionando os dados convencionais com os geográficos?

19

1.2 OBJETIVOS DA PESQUISA

1.2.1 OBJETIVO GERAL

Desenvolver um módulo de Sistemas de Informações Geográficas baseado

na web para representar geograficamente as áreas de propriedades rurais e glebas

manipuladas pelo sistema DRIS e, por meio de uma interface, relacionar os dados

geográficos com os dados convencionais.

1.2.2 OBJETIVOS ESPECÍFICOS

a) Descrever conceitos relacionados à Engenharia de Software, que apóiam o

desenvolvimento do módulo SIG WEB;

b) Apresentar as principais tecnologias web utilizadas na construção do

módulo;

c) Apresentar os conceitos relacionados aos Sistemas de Informação

Geográficas na web;

d) Fazer configurações necessárias para o armazenamento de dados

convencionais e geográficos em um mesmo banco de dados relacional;

e) Instalar e configurar o servidor de mapas (GeoServer), a fim de estabelecer

uma comunicação entre a aplicação e o banco de dados;

f) Explorar os recursos oferecidos pela biblioteca OpenLayers, utilizada na

criação de mapas interativos na web;

g) Projetar e desenvolver um módulo SIG WEB a ser integrado no sistema

DRIS para prover a capacidade de geoprocessamento.

20

1.3 JUSTIFICATIVA

Conforme empresas e instituições ligadas à área da geoinformação

especializam-se, os Sistemas de Informações Geográficas (SIG’s) apresentam-se

como ferramentas de grande utilidade na tomada de decisões. Isto ocorre em

diversas áreas, dentre elas, a área de agronomia, a qual compõe o objeto de estudo

deste trabalho.

O sistema DRIS, mantido pela equipe do laboratório de solos da EMBRAPA-

AC, oferece uma interface web para automatizar as avaliações nutricionais de

lavouras, que por sua vez estão associadas a uma localização geográfica, feito

apenas por caracteres de coordenadas geográficas, conforme exemplo visualizado

no Quadro 1. Além disso, o sistema não oferece nenhuma forma de delimitação

geométrica das áreas compreendidas por propriedades rurais e glebas.

Subestações de coletas

Coordenadas geográficas

P1 10º03’43,2’’ S; 067º36’41,1’’ W

B1 10º03,52.5’’ S; 067º36’45,2’’ W

F1 10º04’15,4” S; 067º36’52,6” W

P2 10º05’30,0’’ S; 067º36’46,7’’ W

B2 10º05’19,5’’ S; 067º36’51,3’’ W

P3 10º04’53,4’’ S; 067º36’17,4’’ W

B3 10º04’52,3’’ S; 067º36’28,5’’ W

F3 10º04’39,6” S; 067º36’48,4” W

Quadro 1 - Exemplo de localizações representadas por coordenadas geográficas. Fonte: (BRITO, 2009).

Quanto à adoção de um SIG WEB como recurso de apoio ao sistema DRIS,

tal procedimento é argumentado por Câmara et al. (2003), onde afirmam que “Se

onde é importante para seu negócio, então Geoprocessamento é sua ferramenta de

trabalho”. De forma mais clara, nessa afirmação os autores explicam que quando o

onde, ou seja, a posição geográfica aparecer como problema a ser resolvido por um

sistema de informação, existe então a oportunidade de considerar a adoção de um

SIG (CÂMARA et al., 2003). Da mesma forma, este argumento serve também como

base para o desenvolvimento deste trabalho, uma vez que o posicionamento

21

geográfico das lavouras é um fator importante, destacado como problema a ser

resolvido.

Portanto, busca-se com este trabalho ampliar a noção geográfica apresentada

aos usuários do sistema DRIS, permitindo a interação com os dados geográficos

armazenados em um Sistema Gerenciador de Banco de Dados (SGBD) apropriado e

fornecer a este sistema recursos para torná-lo uma ferramenta mais eficiente nas

tomadas de decisões.

1.1 METODOLOGIA

Do ponto de vista de sua natureza, este projeto é classificado como uma

pesquisa aplicada, pois objetiva a geração de conhecimentos diversos sobre os SIG

WEB atuando como ferramenta para a representação geográfica de áreas e para

fornecer apoio à avaliação nutricional de culturas agrícolas, sendo que estes

conhecimentos são voltados para uma aplicação prática (SILVA & MENEZES, 2001).

Quanto à sua forma de abordagem, classifica-se como uma pesquisa

qualitativa, pois demonstra o problema de forma descritiva e aprofunda neste

conhecimento desenvolvendo o estudo de caso (SILVA & MENEZES, 2001).

Quanto ao objetivo, é caracterizado por exploratório, pois visa demonstrar o

conhecimento sobre a tecnologia de SIG WEB com uma aplicação prática (SILVA &

MENEZES, 2001).

No ponto de vista de procedimentos técnicos, é classificado como pesquisa

bibliográfica, pois é estabelecido em parte por este tipo de pesquisa, composta por

documentação, exemplos práticos de aplicações, e materiais diversos na internet e

outra parte pelo desenvolvimento do estudo de caso (SILVA & MENEZES, 2001).

Durante o desenvolvimento do estudo de caso foram utilizados os

componentes principais da estrutura de banco de dados geográficos, manipulado

pelo SGBD PostgreSQL com sua extensão espacial PostGIS (POSTGIS, 2011), o

servidor de mapas GeoServer para provimento do serviço WFS (Web Feature

Service) (GEOSERVER, 2011) e a biblioteca OpenLayers (OPENLAYERS, 2011)

22

para implementação da interface, sendo que todos são voltados para o

desenvolvimento específico de aplicações geoespaciais. Sendo utilizado também o

editor de texto Notepad++ em todo o processo de codificação do sistema.

O Desenvolvimento do estudo de caso foi composto pelas seguintes etapas:

a) Levantamento de requisitos e modelagem: Nesta fase foram elaborados

cenários de uso e documento de requisitos a fim de definir as principais

funcionalidades do sistema;

b) Configuração do banco de dados geográfico: Tendo posse do banco de

dados convencional do sistema DRIS, mantendo todos os registros

armazenados, foram adotados procedimentos para torná-lo apto a

manipular as informações geográficas;

c) Instalação e configuração do servidor de mapas: Nesta etapa foi

realizada a instalação e configuração do servidor de mapas (GeoServer)

para atuar na comunicação entre o banco de dados e a interface cliente;

d) Prototipação: Nesta etapa são criados protótipos com finalidade de

oferecer um melhor entendimento do contexto da aplicação, validar os

requisitos e reduzir o esforço empregado na implementação do módulo;

e) Implementação da interface cliente: Durante esta etapa, o módulo foi

implementado tendo como ponto de partida o resultado obtido na fase de

prototipação;

f) Testes: Com finalidade de manter o sistema confiável através da redução

de riscos, o módulo foi submetido a testes de unidade.

1.5 ORGANIZAÇÃO DO ESTUDO

Os capítulos deste trabalho estão organizados da seguinte forma:

No Capítulo 2 apresenta os conceitos mais importantes que envolvem os

SIG’s com ênfase neste tipo de tecnologia voltada para o ambiente web.

No Capítulo 3 são descritos os principais conceitos da engenharia de software

utilizados na elaboração deste trabalho.

23

No Capítulo 4 são apresentados os recursos tecnológicos utilizados na

implementação do estudo de caso.

O Capítulo 5 demonstra o estudo de caso, apresentando de forma prática os

passos utilizados para a construção do módulo que visa a representação geográfica

de propriedades rurais e glebas.

No Capítulo 6 são apresentadas as considerações finais envolvendo os

resultados gerais obtidos do trabalho e as recomendações para trabalhos futuros.

E por fim, os apêndices produzidos e anexos utilizados durante o

desenvolvimento do trabalho que serviram como material de apoio a esta pesquisa.

2 SISTEMAS DE INFORMAÇÕES GEOGRÁFICAS

Num contexto geral os SIG’s abrangem uma diversidade de assuntos,

envolvendo desde seu surgimento, fatores que contribuíram para a sua constante

evolução até os dias atuais. Dessa forma, como fundamento para compreensão

deste trabalho e para o desenvolvimento do estudo de caso, neste capítulo é

descrito os principais conceitos, componentes e recursos computacionais que

formam um SIG voltado ao ambiente web.

2.1 BREVE HISTÓRICO

Câmara et al. (2003) descrevem que as primeiras tentativas de automatizar o

processamento geográfico (o que ainda não podia ser classificado como SIG)

aconteceram por volta dos anos 50 na Inglaterra e nos Estados Unidos, tendo como

objetivo reduzir os custos de produção e manutenção de mapas. Nos anos 60,

surgiram no Canadá os primeiros Sistemas de Informações Geográficas, fazendo

parte de um programa governamental para criar um inventário de recursos naturais

(CÂMARA et al., 2003). Porém, eram difíceis de usar, consumiam recursos

extremamente caros e eram dotados de pouca capacidade de armazenamento e

processamento. Assim, somente após os anos 70, com o aumento do potencial dos

25

recursos de hardware, obteve-se melhora na produção de documentos cartográficos,

sendo criada a expressão Geographic Information System.

Então, desde a década de 80 até os dias de hoje, a tecnologia de SIG’s vem

evoluindo constantemente, tendo como causa o barateamento dos recursos

computacionais, a evolução dos computadores pessoais, o estabelecimento de

centros de estudos sobre este assunto e o aprimoramento dos sistemas

gerenciadores de banco de dados relacionais, com a inclusão de funções

específicas para tratamento e análise de informações espaciais (CÂMARA et al.,

2003).

2.2 DEFINIÇÃO E ARQUITETURA

O termo SIG é aplicado a sistemas de informações que executam captura,

modelagem, manipulação, recuperação, análise e apresentação dos dados

referenciados geograficamente (CÂMARA et al., 2003). Assim, a diferença do SIG

para outros sistemas de informações convencionais é a capacidade de armazenar e

tratar além dos atributos convencionais também as informações com coordenadas

de posicionamento e delimitação geométrica de objetos espaciais como lotes, lagos,

rios, cidades, dentre outros (CASANOVA et al., 2011; DRUCK et al., 2004; CÂMARA

et al., 2003).

Segundo Druck et al. (2004), as tecnologias de SIG’s têm evoluído

substancialmente com o objetivo de atender as necessidades apresentadas por

diversas áreas de conhecimento seja em saúde, ambiente, geologia, agronomia,

dentre tantas outras, sendo capazes de apresentar um mapa permitindo a

visualização espacial do fenômeno que está ocorrendo e a tradução das

ocorrências, respondendo a questionamentos tais como:

a) Epidemiologistas coletam dados sobre a ocorrência de doenças. A

distribuição dos casos de uma doença forma um padrão no espaço? Existe

associação com alguma fonte de poluição? Evidência de contágio? Variou

no tempo?

26

b) Deseja-se investigar se existe alguma concentração na distribuição de

roubos. Roubos que ocorrem em determinadas áreas estão

correlacionados com característica sócio-econômicas dessas áreas?

c) Geólogos desejam estimar a extensão de um depósito mineral em uma

região a partir de amostras. Pode-se usar essas amostras para estimar a

distribuição do mineral na região?

d) Deseja-se analisar uma região para fins de zoneamento agrícola. Como

escolher as variáveis explicativas – solo, vegetação, geomorfologia, - e

determinar qual a contribuição de cada uma delas para definir em que local

o tipo de cultura é mais adequado?

De acordo com Aragão (2009) a arquitetura de um SIG pode ser dividida em

três partes principais: Apresentação, Ferramentas e Gerenciamento de Dados. E

cada parte dessa arquitetura é composta por componentes inter-relacionados,

conforme visualizado na Figura 1.

Figura 1 - Arquitetura de um SIG. Fonte: (ARAGÃO, 2009).

A parte de Apresentação abrange os elementos da interface com o usuário

(janelas, botões, gráficos, controles, mapas, etc) que são apresentados na tela do

computador em forma de ferramentas para visualização, consulta e manipulação de

dados geográficos (ARAGÃO, 2009; CÂMARA et al., 2003).

As Ferramentas de um SIG compreendem os elementos que atuam na

Entrada e Integração de Dados, nas Consultas e Análises Espaciais e nas diversas

27

técnicas de Visualização espacial (ARAGÃO, 2009). A Entrada e Integração de

Dados é caracterizada pelo uso de recursos computacionais de entrada e

processamento de dados geográficos. Dessa forma, um SIG deve estar apto a

receber, integrar e processar diferentes tipos de dados como geográficos,

convencionais, imagens de satélite, dentre outros. A Consulta e Análise Espacial é

composta pelos recursos que fornecem ao SIG a capacidade de executar as

consultas e análises geográficas. Estes recursos são algoritmos para álgebra de

mapas, estatística espacial, modelagem numérica de terreno e processamento de

imagens. A Visualização espacial permite que o resultado final do processamento

geográfico seja apresentado de diversas formas na tela do computador. Isto

geralmente é feito por meio de ferramentas que identificam padrões espaciais e

apresentam como resultado o mapa e a interpretação do fenômeno ocorrido

(ARAGÃO, 2009, CÂMARA et al., 2003).

A parte de Gerenciamento de Dados é composta por toda tecnologia

disponível em um SIG para armazenamento e gerência dos dados geográficos. Isto

pode ser feito através de arquivos específicos ou tabelas de um SGBD. Nos SIG’s

mais atuais o gerenciamento dos dados é feito por SGBDs (Sistemas de

Gerenciamento de Banco de Dados) que possuem suporte para manipulação e

armazenamento de dados geográficos (ARAGÃO, 2009, CÂMARA et al., 2003).

2.3 SIG WEB

Com a evolução e a popularização da internet, observou-se a migração de

diversos sistemas de informações para a web, tendo como principais motivos

fornecer acessibilidade a um número maior de usuários e solucionar problemas

como a adaptação de um software para funcionar em diferentes tipos de sistemas

operacionais, sendo tal característica conhecida também como portabilidade

(CABRAL, 2008).

Este mesmo comportamento foi observado no momento em que se iniciou a

disponibilidade dos SIG’s em ambiente web, trazendo grandes melhorias para os

desenvolvedores deste tipo de tecnologia ao permitir que desenvolvam soluções SIG

28

WEB sem necessitar do uso de recursos computacionais caros ou de uma equipe

especializada. Os usuários desta tecnologia foram mais beneficiados ainda,

podendo usufruir livremente dos recursos que ela oferece, sem a necessidade de

comprar e instalar um SIG por um preço elevado, precisando apenas estar

conectado à internet. (CABRAL, 2008; SCHIMIGUEL et al., 2006).

Segundo Cabral (2008), um SIG WEB é composto pelos seguintes elementos

conforme visualizado na Figura 2.

Figura 2 - Elementos de um SIG WEB. Fonte: (CABRAL, 2008).

Na Figura 2, o elemento Cliente (browser) se refere à parte de apresentação

do sistema, que é feita através de um navegador web, como Google Chrome,

internet Explorer, Mozilla Firefox, Safari, dentre outros. O elemento Servidor web se

refere aos mesmos servidores utilizados em aplicações web convencionais como

apache, internet Information Services e outros. O elemento Servidor de mapas se

refere ao software que por meio de requisições do cliente, faz a comunicação com o

banco de dados espacial e reproduz as informações obtidas em forma de mapas.

Atualmente os servidores mais utilizados são: MapServer (MAPSERVER, 2012) e

GeoServer (GEOSERVER, 2012) (seção 2.5.1). O Banco de dados espacial faz o

armazenamento dos dados geográficos. E por fim, a Linguagem de programação se

refere a qualquer linguagem para construção de sistemas de informação na web

como JavaScript (seção 4.3) e PHP (seção 4.4) (CABRAL, 2008).

29

2.4 ARMAZENAMENTO E MANIPULAÇÃO DE DADOS GEOGRÁFICOS

Os dados geográficos são a parte mais importante de um SIG, principalmente

quando este é disponível em ambiente web (SIG WEB). Dessa forma, para que o

sistema faça o uso destes dados, devem estar armazenados em um SGBD capaz de

realizar todo o tratamento necessário, serem transformados em um formato padrão a

fim de facilitar a manipulação do SGBD ou em um formato mais “legível” para ser

utilizado pela linguagem de programação no lado cliente da aplicação, além disso, é

importante que estes dados também estejam associados à um sistema de referência

espacial, sendo geograficamente posicionados conforme a superfície real da terra.

Portanto, os conhecimentos relacionados ao armazenamento e manipulação

de dados geográficos como: a extensão espacial PostGIS do SGBD PostgreSQL,

Formatos de Dados Geográficos (WKT e WKB) e Sistemas de Referência Espacial

são descritos com mais detalhes nas próximas seções.

2.4.1 POSTGRESQL E A EXTENSÃO POSTGIS

O PostgreSQL, sob a liderança de Michael Stonebraker, foi desenvolvido a

partir do projeto Postgres, que teve seu início em 1986 na Universidade da Califórnia

(CASANOVA et al., 2011). Desde então, este projeto vem se mantendo por um

grupo de desenvolvedores sob o nome de PostgreSQL. É considerado o melhor

SGBD open source, pois além de ter o código aberto, sendo uma alternativa aos

SGBDs Oracle ou Informix, possui recursos comuns aos tradicionais SGBDs

comerciais, com o suporte a consultas complexas, gatilhos, chaves estrangeiras,

visões, controle de concorrência e integridade relacional, e foi o primeiro SGBD a

possuir vários recursos que somente algum tempo depois foram incorporados aos

SGBDs comerciais (CASANOVA et al., 2011; MANZANO, 2008; MILANI, 2008;

GUTTOSKI, 2006).

30

Em sua versão oficial, o PostgreSQL apresenta tipos de dados geográficos

com operadores simples, possuindo uma grande limitação quanto a sua capacidade

de realizar operações espaciais. Diante desse contexto, é certo de que a integração

de um SIG através desses recursos oferecidos nativamente pela ferramenta

necessitaria de muito esforço em caso de implementações de novas operações

espaciais realizadas com ou entre objetos espaciais, como união, intersecção, testes

topológicos, dentre outras (CASANOVA et al., 2011).

De acordo com Casanova et al. (2011) o PostgreSQL é um SGDB bastante

flexível no que se diz respeito à extensibilidade, sendo dotado de um mecanismo

que permite a ampliação de sua capacidade, com o objetivo de fornecer um

gerenciamento de dados mais eficiente.

Diante dessa situação e aproveitando essa capacidade, o problema de

executar operações espaciais foi resolvido, sendo desenvolvido pela empresa

Refractions Research Inc (http://postgis.refractions.net/) uma extensão geográfica

completa, chamada de PostGIS (CASANOVA et al., 2011).

Segundo Postgis (2011), a extensão PostGIS permite que o PostgreSQL seja

utilizado como banco de dados espacial para SIG’s. É importante ressaltar que o

PostGIS é liberado sob a licença GNU GPL (General Public License) e segue as

especificações SFSSQL (Simple Features Specification for SQL) do OGC1. Existem

também outras soluções para utilização de SGBD espaciais semelhantes ao

PostGIS, destacando-se como principais a tecnologia ArcSDE (Spatial Data Server)

da ESRI (http://www.esri.com/) e a extensão espacial Oracle Spatial do SGDB

Oracle (POSTGIS, 2011; CASANOVA et al., 2011).

Para facilitar e permitir a representação de qualquer entidade geográfica, o

PostGIS trouxe consigo a capacidade de manipular as estruturas de dados vetoriais.

As estruturas de dados vetoriais são utilizadas para representar as coordenadas das

fronteiras de cada entidade geográfica, através de três tipos básicos: ponto (Point),

linha (LineString), polígono (Polygon) e seus respectivos agrupamentos, visualizado

em mais detalhes na Figura 3 (CÂMARA et al., 2003).

1OGC é um consórcio internacional, sem fins lucrativos, formado por várias entidades, que estabelece

padrões na área geoespacial e de serviços baseados na localização. Surgiu em 1994 com o objetivo de garantir interoperabilidade dos dados entre os diferentes softwares. Para isso, conseguiu o apoio de grandes empresas da área e atualmente conta com consorciados de peso na indústria, como é o caso do Google, ESRI, USGS, NASA, ERDAS, Autodesk, Microsoft e Oracle (COSTA, 2011).

http://www.esri.com/

31

Figura 3 - Tipos de dados geográficos do PostGIS. Fonte: (CASANOVA et al., 2011).

As entidades geográficas a serem representadas são objetos do mundo real

como uma casa, a localização de crimes e de espécies vegetais que podem ser

representados pelo tipo Point, um rio e uma estrada que podem ser representados

pelo tipo LineString e um lote, propriedade rural e municípios que podem ser

representados pelo tipo Polygon. Da mesma forma, para que se tenha maior

eficiência na manipulação e uso dos dados geográficos, os objetos podem ser

devidamente agrupados, e armazenados no SGBD nos tipos: GeometryCollection,

MultiPoint, MultiLineString e MultiPolygon (CÂMARA et al., 2003).

Segundo Uchoa & Ferreira (2004), o PostGIS pode oferecer mais de 130

funções e operadores para o manipulação das estruturas de dados geográficos

vetoriais. Algumas das principais funções são destacadas no Quadro 2 (RAMSEY,

2012):

Nome da função Parâmetros Funcionalidade

AddGeometryColumn() <table_name>,

<column_name>, <SRID2>, <type>, <dimension>

Adiciona uma coluna

geométrica em uma tabela

do SGBD.

Distance() <geometry>, <geometry> Retorna a distância entre

duas geometrias.

Intersects() <geometry>, <geometry>

Retorna verdadeiro se as

geometrias se cruzam

espacialmente.

2 SRID é o número identificador (chave primária) dos registros da tabela spatial_ref_sys explicado em

mais detalhes na seção 2.4.3.

32

Contains() <geometry>, <geometry>

Retorna verdadeiro se a

primeira geometria contém

espacialmente a segunda

geometria.

Intersection() <geometry>, <geometry>

Retorna uma geometria

que representa a

interseção entre as duas

definidas no parâmetro.

Area() <geometry>

Retorna a área da

geometria, sendo um

polígono ou multi-polígono.

Quadro 2 - Principais funções do PostGIS.

Segundo Ramsey (2012), o PostGIS também possui suporte à indexação

espacial denominada GIST (Generalized Search Tree), que tem como principal

finalidade acelerar as consultas que envolvem os dados espaciais. Para adicionar

um índice GIST é utilizada a seguinte sintaxe de código, como segue no Quadro 3.

CREATE INDEX <nome_do_índice> ON <nome_da_tabela> USING GIST

(<nome_do_campo_geométrico>);

Quadro 3 - Código para adicionar índice GIST em uma tabela. Fonte: (RAMSEY, 2012).

Além das funções destacadas aqui, existem muitas outras encontradas no

manual PostGIS (RAMSEY, 2012), na seção 6.1. Também são de grande

importância as funções utilizadas para converter os dados geográficos de um

formato utilizado no SGBD Well-Know Binary (WKB) para um formato mais acessível

à aplicação Well-Know Text (WKT) ou vice-versa. Estes formatos bem como as

funções utilizadas para realizar tais conversões são descritas em mais detalhes na

seção seguinte.

2.4.2 FORMATO DE DADOS GEOGRÁFICOS WKT E WKB

Segundo Ramsey (2012), a padronização especificada pelo OGC define dois

formatos para expressão de objetos espaciais, sendo o WKT e WKB. Estes dois

formatos incluem a informação sobre o tipo do objeto, as coordenadas geográficas

33

que formam o objeto e o sistema de referência espacial (seção 2.4.3) ao qual está

associado.

Na forma WKT esses dados são representados da seguinte forma

(CASANOVA et al., 2011):

a) Point: (0 0 0);

b) LineString: (0 0, 1 1, 2 2);

c) Polygon: ( (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0), ( 1 0 0, ...), ... );

d) MultiPoint: (0 0 0, 4 4 0);

e) MultiLineString: ( (0 0 0, 1 1 0, 2 2 0), (4 4 0, 5 5 0, 6 6 0) );

f) MultiPolygon: ( ( (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0), (...), ...), ...);

g) GeometryCollection: ( POINT(2 2 0), LINESTRING((4 4 0, 9 9 0)) ).

Na forma WKB os dados são representados por diversos caracteres

hexadecimais, que ficam armazenados no campo geométrico da tabela de forma

semelhante à demonstrada no Quadro 4.

"0103000020E61000000100000005000000FDFFFF6B8EE550C0802BDD45E

62B2440EDFFFFD362E550C096ED9DBE502B2440E6FFFFBB7AE550C0630F

5CFE2D2A2440EFFFFFB3A0E550C0BC1E93490E2B2440FDFFFF6B8EE550C0

802BDD45E62B2440"

Quadro 4 - Representação de dados no formato WKB.

Uma vez que estes dados estão armazenados numa tabela do SGBD, para

recuperá-los no formato WKT durante uma consulta, utiliza-se a função

asText(<geometry>). Para recuperá-los em sua forma original (WKB), utiliza-se a

função asBinary(<geometry>). Para fazer a inserção destes dados no banco utiliza-

se obrigatoriamente como segundo parâmetro o SRID. Assim, é utilizado a função

GeomFromWKB(<byte WKB>, <SRID>) para inserir os dados que estão no formato

WKB e a função GeometryFromText(text WKT, SRID) para inserir os dados que

estão no formato WKT (RAMSEY, 2012).

34

2.4.3 SISTEMA DE REFERÊNCIA ESPACIAL

Segundo IBGE (2012), os sistemas de referência espaciais são utilizados

para descrever as posições dos objetos, ou seja, sem eles não se pode identificar a

posição correta de determinada feição (objeto espacial) na superfície terrestre. Estes

sistemas também estão associados a uma superfície que mais se aproxima da forma

real da terra e sobre eles são desenvolvidos todos os cálculos relacionados às suas

coordenadas (IBGE, 2012).

Importante observar que em qualquer equipamento ou tecnologia relacionada

à informação geográfica, no momento em que é registrada tal informação, esta deve

estar relacionada a um sistema de referência espacial, estabelecendo assim um

padrão de visualização da informação geográfica. Da mesma forma, ao gravar num

banco de dados geográfico determinada informação espacial, esta deve ser

associada a um sistema de referência espacial. Para isso o próprio banco de dados

geográfico fornece uma estrutura com diversos sistemas de referência espaciais.

No PostgreSQL, quando é criado um novo esquema baseado na extensão

PostGIS, são geradas duas tabelas. Uma delas, denominada spatial_ref_sys (Figura

4), contém todos os sistemas de referência espaciais.

Figura 4 - Estrutura da tabela spatial_ref_sys da extensão PostGIS. Fonte: (CASANOVA et al., 2011).

A outra, denominada geometry_columns (Figura 5), é responsável por

estabelecer o relacionamento entre os sistemas de referência espaciais e todas as

colunas geométricas do banco de dados, e não apenas este relacionamento, mas

todos os dados geográficos do banco de dados estão associados a um determinado

35

SRID. E como pode ser observado, o SRID é o identificador (chave primária) da

tabela spatial_ref_sys.

Figura 5 - Estrutura da tabela geometry_columns da extensão PostGIS. Fonte: (CASANOVA et al., 2011).

2.5 TECNOLOGIAS E SERVIÇOS WEB PARA SISTEMAS GEOESPACIAIS

Nesta seção são descritas tecnologias e conceitos que envolvem o processo

de comunicação do lado cliente da aplicação com o banco de dados geográfico.

Dessa forma, são apresentadas as tecnologias OpenLayers e API (Application

Programming Interface) do Google Maps que compõem a interface de apresentação

ao usuário e o serviço WFS criado a partir do servidor de mapas GeoServer para

atualização, captura e distribuição da informação geográfica.

2.5.1 SERVIDOR DE MAPAS GEOSERVER

Segundo Barriguinha (2008), um servidor de mapas é o componente central

de um SIG, sendo utilizando para estabelecer a comunicação entre o lado cliente da

aplicação e o banco de dados geográfico.

Dentre os servidores de mapas mais conhecidos e utilizados na manipulação

de dados geográficos na web destacam se o MapServer e o GeoServer.

36

O GeoServer é um software open source baseado na linguagem Java, tendo

como objetivo principal a publicação de informações espaciais. Seu desenvolvimento

teve início em 2001 por uma empresa denominada “The Open Planning Project”. E

um fator importante a ser observado é que a capacidade deste software vem sendo

progressivamente ampliada com ajuda de colaboradores individuais, empresas

(destacando-se como principal a Refractions Research que também é responsável

pelo PostGIS) e fontes de financiamento externo, beneficiando a todos os usuários

(RAMOS, 2009).

Dentre os principais benefícios que fornece, destacam-se os padrões de

serviços WFS, WMS (Web Map Service) e WCS (Web Coverage Service) do OGC

(RAMOS, 2009). Segundo Geoserver (2011) este software é a implementação de

referência da norma WFS, motivo pelo qual foi utilizado para o desenvolvimento

deste trabalho.

2.5.2 SERVIÇO WFS

O padrão WFS, estabelecido pelo OGC é um dos principais serviços

fornecidos pelo GeoServer. Este padrão fornece aos usuários, a partir de requisições

feitas ao servidor de mapas, o acesso a objetos georreferenciados e seus atributos

em caso de consultas, permitindo também a execução de inserções, atualizações ou

a remoção de dados, tal procedimento é denominado transação WFS (WFS-T)

(COSTA, 2011).

Segundo Ramos (2009), o processo de comunicação entre cliente e servidor

ocorre da seguinte forma: veiculado pelo protocolo de transporte HTTP, é feito a

solicitação de requisições ao servidor de mapas (neste caso o GeoServer). Este

servidor é responsável por conduzir o serviço WFS, que atua na conversão dos

dados geográficos disponíveis no banco de dados, transformando-os em GML

(Geography Markup Language), e depois os transportando neste padrão como

resposta á solicitação cliente.

Sendo um dos primeiros padrões criados pela OGC, o GML, sendo uma

extensão do XML, possibilita a intercomunicação entre diferentes softwares que

37

utilizam a informação geográfica. O GML é útil tanto na codificação de objetos

geográficos como também seus atributos, pois ele armazena e transporta os dados

geográficos representados por ponto, linha ou polígono junto aos seus respectivos

atributos, representado por dados convencionais. Ao receber o GML, a aplicação é

responsável pela tradução e apresentação destes dados aos usuários em forma de

mapas (COSTA, 2011; RAMOS, 2009; KIMO, 2009).

A Figura 6 apresenta de forma mais simplificada o esquema de

funcionamento do serviço WFS.

Figura 6 - Esquema de funcionamento do serviço WFS. Fonte: (AZEVEDO et al., 2006).

2.5.3 BIBLIOTECA OPENLAYERS

O OpenLayers, que inicialmente foi desenvolvido pela empresa Metacarta,

trata-se do projeto de uma biblioteca livre e aberta desenvolvida na linguagem

JavaScript sendo mantido pela fundação Open Source Geospatial Foundation

(OSGEO, 2012; RAMOS, 2009). Dentre os pontos positivos encontrados nesta

38

biblioteca, destaca-se sua possibilidade de acessar diversas fontes de informações

geográficas além de suportar os formatos WMS, Ka-Map, TMS, WorldWind, WFS,

GeoRSS, Google, Yahoo, Microsoft e MultiMap (OSGEO, 2012; RAMOS, 2009).

Por ser baseado na tecnologia Ajax, permite maior usabilidade e

interatividade ao usuário, eliminando o tempo consumido durante as requisições

feitas ao servidor. É integrada com o servidor GeoServer, de onde é obtido os dados

solicitados por meio do serviço WFS (KUNIYOSHI et al., 2009).

O OpenLayers permite também a associação com diversos tipos de mapa

base, no qual representam a visualização da superfície terrestre, sendo

indispensáveis para uma aplicação SIG WEB. Dentre os mapas base suportados

pelo OpenLayers, destacam os que são fornecidos pela Microsoft

(http://www.bing.com/maps/), Yahoo (http://maps.yahoo.com/) e Google

(http://maps.google.com/).

Esta biblioteca também oferece uma diversidade de recursos, incluindo desde

funções básicas de um SIG como aumentar/reduzir nível de zoom, visão global,

controle de camadas, navegação, até a criação, alteração e seleção de objetos

geográficos, dentre tantos outros. A Figura 7 mostra um exemplo de aplicação

implementada com OpenLayers, utilizando como mapa base a API Google Maps,

que é descrita em detalhes na seção 2.5.4.

Figura 7 - Exemplo de aplicação implementada com OpenLayers. Fonte: (OPENLAYERS, 2011).

A Figura 7 mostra o exemplo de uma interface simples criada com

OpenLayers. No canto superior direito da figura podem ser observados os controles:

desenho de polígono, alterar objeto, remover e salvar. No centro da figura é

apresentado o objeto geográfico em forma de polígono, que pode ser criado

39

utilizando o controle de desenhar polígono ou recuperado de um banco de dados

geográfico por meio do serviço WFS fornecido pelo servidor de mapas. A camada

que representa a superfície terrestre foi extraída da API Google Maps, que é descrita

em mais detalhes na seção seguinte.

2.5.4 API GOOGLE MAPS

A empresa Google lançou em fevereiro de 2005 o Google Maps. Este é um

dos SIG WEB mais utilizados em todo o mundo, permitindo que qualquer usuário

marque locais importantes, adicione vídeos, fotos e compartilhe esse conteúdo com

outros usuários na internet. Assim, ainda na sua versão beta rapidamente se tornou

uma referência em serviços de mapas na internet (NETO, 2009).

Por volta de maio de 2007, foi disponibilizada no Brasil uma versão mais

ampla do Google Maps, com recursos para localização de restaurantes, hotéis,

traçar rotas, dentre outras funcionalidades (NETO, 2009).

Uma das grandes vantagens dessa ferramenta é a utilização do modelo Ajax,

que fornece dentre tantas vantagens, maior satisfação aos usuários devido a

velocidade na execução de transações. No entanto, fazendo uma comparação com

outros SIG WEB observa-se a desvantagem de não ser open source, não permitindo

por exemplo, a inserção e o tratamento de dados ambientais (NETO, 2009;

CABRAL, 2008).

Como forma de compensar essa desvantagem, a Google disponibiliza

gratuitamente a API do Google Maps, o que significa permitir que qualquer utilizador

de informações geográficas possa incluir em seu sistema web os mapas baseados

no próprio Google Maps.

Essa API foi construída com base na linguagem JavaScript, sendo

semelhante à biblioteca OpenLayers, e contém recursos utilizados para a exibição

de mapas, consultas por endereços, funções de aumento e redução de zoom,

registro de pontos importantes, dentre outras funcionalidades (NETO, 2009).

Para se utilizar os recursos providos pela API, é necessário solicitar ao

Google uma chave (disponível no endereço: http://code.google.com/intl/pt-

40

BR/apis/maps/signup.html) e informar o nome do diretório que se deseja incluir o

recurso, lembrando que uma única chave é válida em um único diretório do sistema

web (GOOGLE, 2012; NETO, 2009).

Neto (2009), utiliza a API do Google Maps para georreferenciar os principais

pontos de interesse na Universidade Federal de Viçosa. Dessa forma, essa

aplicação apresenta informações úteis a respeito da instituição, tais como a

localização e a descrição das principais edificações do campus. Conforme

observado na Figura 8, utilizando o controle de aumento de zoom, o usuário

identifica a Biblioteca Central e ao clicar sobre o marcador que está sobre a

edificação é apresentado mais detalhes sobre o local.

Figura 8 - Aplicação criada com a API do Google Maps para representar geograficamente os principais pontos da Universidade Federal de Viçosa. Fonte: (NETO, 2009).

Ao contrário do aplicativo produzido por (NETO, 2009), este trabalho não

utiliza a API Google Maps por completo, ou seja, é utilizado somente o mapa base

para visualização da superfície terrestre. Os outros controles fornecidos pela API

não são necessários na implementação deste sistema, uma vez que não se pode

definir uma base de dados para armazenar as transações que são executadas. Para

isso, é utilizado os recursos da biblioteca OpenLayers, e todos os controles são

adicionados sobre o mapa da API Google Maps para realizar um o tratamento mais

eficiente dos dados.

3 ENGENHARIA E MODELAGEM DE SOFTWARE

Durante a construção de um software, além da garantia da qualidade, deve-se

utilizar também outras diversas técnicas de Engenharia de Software, visando a

construção de produtos de software eficientes, confiáveis, robustos, dentre outros

pontos positivos, que transmitam maior satisfação à seus usuários.

Com base nesse contexto, o objetivo deste capítulo é demonstrar as

principais técnicas da Engenharia de Sofware que fizeram parte do desenvolvimento

do estudo de caso deste trabalho.

3.1 MODELOS DE PROCESSO DE SOFTWARE E PROTOTIPAÇÃO

Segundo Pressman (2006), os modelos de processo de software definem um

conjunto de atividades, ações, tarefas, marcos, e produtos de trabalho necessários

para construir produtos de software de alta qualidade. O autor admite que, apesar de

não serem perfeitos, estes modelos são de suma importância para a construção de

um software, ao fornecer os “caminhos” necessários para conduzir projetos de

software em conformidade com a Engenharia de Software.

Alguns desses modelos são apresentados em (SOMMERVILLE, 2007) e

(PRESSMAN, 2006) como: modelo de desenvolvimento baseado em componentes,

modelo em cascata, modelo espiral, modelo RAD (Desenvolvimento Rápido de

42

Aplicações), modelos prescritivos, prototipação, modelos ágeis de processo,

destacando como principais o Scrum, Crystal e Extreme Programming (XP), dentre

outros.

Este trabalho foi elaborado com o modelo de prototipação, com o intuito de

facilitar o processo de implementação do sistema, de forma que este atenda às

necessidades dos usuários.

Segundo Sommerville (2007), um protótipo é uma versão inicial do sistema de

software utilizado para facilitar o entendimento dos stakeholders3, oferecendo

demonstrações de conceitos, experimento de opções do projeto de interface, e

fornecendo um conhecimento maior sobre o problema e suas possíveis soluções.

Preece et al. (2002) justificam o uso de protótipos para diversos fins como:

testar a viabilidade técnica de uma idéia, esclarecer requisitos vagos, realizar testes

e avaliações com os usuários e verificar se o rumo que se estabeleceu ao design é

compatível com o restante do desenvolvimento do sistema.

Sommerville (2007) sugere a utilização da prototipação no processo de

desenvolvimento de software de várias formas, como:

a) Na fase de engenharia de requisitos, auxiliando na descoberta e validação

dos requisitos do sistema;

b) No processo de projeto do sistema, sendo utilizado para explorar soluções

específicas de software e apoiar o projeto de interface com o usuário;

c) No processo de teste, sendo utilizado para realizar testes completos com o

sistema que será entregue para o cliente.

Conforme visualizado na Figura 9, a prototipagem inicia com a comunicação,

onde o Engenheiro de Software (ou desenvolvedores) e o cliente encontram-se a fim

de definir os objetivos gerais do software, identificando as necessidades conhecidas

e delimitando as áreas que necessitam ser mais exploradas. Então é planejada

rapidamente uma iteração de prototipagem, onde ocorre a modelagem. O Protótipo é

construído através do projeto rápido, e após este procedimento é implantado e

avaliado pelo cliente ou usuário do sistema (PRESSMAN, 2006). Dessa forma, este

3Stakeholders são todos que estão envolvidos com um projeto de software, incluindo

desenvolvedores, gerentes, clientes e usuários.

43

feedback (avaliação) fornecido pelo usuário é utilizado para refinar os requisitos do

software.

Figura 9 - Modelo de prototipagem de sistema de software. Fonte: (PRESSMAN, 2006).

Naturalmente existem dois tipos de prototipação, sendo a de baixa-fidelidade

e a de alta-fidelidade. Ao contrário da prototipação de baixa-fidelidade, que utiliza

recursos mais simples para construir produtos descartáveis, a prototipagem de alta-

fidelidade utiliza materiais, esperando que estes estejam presentes também no

produto final (PREECE et al., 2002). Dessa maneira, pode-se construir um protótipo

de alta-fidelidade utilizando os mesmos recursos a serem utilizados na versão

verdadeira, por exemplo, o layout de uma página codificada apenas em HTML, pode

ser considerado como um protótipo de alta-fidelidade. Ao integrar nesta página, a

lógica de programação com a linguagem PHP e outras funcionalidades, por

exemplo, já torna o protótipo algo mais semelhante ao produto final que se deseja

construir (PREECE et al., 2002).

Entretanto, Preece et al. (2002) recomenda que atenciosamente seja feito um

estudo sobre o trabalho a ser desenvolvido e o tipo de protótipo a ser elaborado,

verificando principalmente se o tipo de protótipo é adequado. Para se ter uma base

ao fazer esta análise, o autor apresenta uma tabela demonstrando as principais

44

vantagens e desvantagens dos dois tipos de prototipação, que pode ser observado

no Quadro 5.

Tipo Vantagens Desvantagens

Protótipo de baixa-

fidelidade

Custo mais baixo de

desenvolvimento.

Avalia múltiplos

conceitos de design.

Instrumento de

comunicação útil.

Aborda questões de

leiaute de tela.

Útil para identificação de

requisitos de mercado.

Proof-of-concept

(demonstrações de que

o conceito funciona).

Verificação limitada de

erros.

Especificação pobre

em detalhe para

codificação.

“Uso” conduzido pelo

facilitador.

Utilidade limitada após

estabelecimento de

requisitos.

Utilidade limitada para

testes de usabilidade.

Limitações de fluxo e

navegação.

Protótipo de alta-

fidelidade

Funcionalidade

completa.

Totalmente interativo.

Uso conduzido pelo

usuário.

Define claramente o

esquema de navegação.

Uso para exploração e

teste.

Mesmo look and feel do

produto final.

Serve como uma

especificação viva.

Ferramenta de venda e

marketing.

Desenvolvimento mais

caro.

Sua criação demanda

tempo.

Ineficiente para

designs proof-of-

concept

(demonstrações de

que o conceito

funciona).

Não serve para coleta

de requisitos.

Quadro 5 - Principais vantagens e desvantagens da prototipação de baixa- e alta-fidelidade. Fonte: (PREECE et al., 2002).

45

3.2 MODELAGEM DE CASO DE USO

A Unified Modeling Language ou Linguagem de Modelagem Unificada (UML)

disponibiliza uma diversidade de recursos para elaboração de projetos de sistema de

software. Dentre estes recursos, destacam-se diversos tipos de diagramas, que

facilitam a visualização da arquitetura de um sistema. No contexto deste trabalho,

destaca-se o diagrama de caso de uso, que dentre as principais finalidades é

utilizado para fornecer aos stakeholders um entendimento geral sobre o sistema a

ser desenvolvido (BOOCH et al., 2006).

Todo sistema de software é criado para interagir com autores humanos ou

outros sistemas (BOOCH et al., 2006). Na interação entre estes autores e o sistema,

podem ser observados comportamentos, seqüência de ações e resultados

produzidos. Nesse contexto, é que entra o diagrama de caso de uso, que tem o

papel de capturar tais características e comportamentos (MELO, 2010; BOOCH et

al., 2006).

Dos componentes principais de um diagrama de caso de uso, conforme

observado na Figura 10, destacam-se os atores, os casos de uso e os

relacionamentos entre os atores e os casos de uso que podem ser inclusão ( include)

ou extensão (extend). Vale ressaltar que o relacionamento include é representado

como uma dependência, ou seja, é utilizado para especificar que um caso de uso

inclui o comportamento de outro. Já o relacionamento de extensão é utilizado

quando um caso de uso incorpora de forma implícita o comportamento de outro,

lembrando que, ao contrário do outro, este comportamento é opcional (MELO, 2010;

BOOCH et al., 2006).

Figura 10 - Representação de um diagrama de caso de uso. Fonte: (MELO, 2010).

46

Booch et al. (2006) recomendam que antes da elaboração de um caso de

uso, é importante descrever em forma de texto o fluxo de eventos que expressa de

forma detalhada o comportamento entre os autores e o sistema. Este fluxo é

geralmente capturado no projeto de levantamento e análise de requisitos, sendo

conhecido também como cenário de uso.

Segundo Preece et al. (2002) cenários de caso de uso são textos com uma

“descrição narrativa informal” de uso, ou seja, são descrições que exploram

atividades ou tarefas realizadas por usuários. Entretanto, vale ressaltar que não

existem regras que especificam o nível de detalhe que deve ser incluído em um

cenário.

Por meio de um exemplo, visualizado no Quadro 6, Preece et al. (2002)

mostram um cenário para um sistema de agenda compartilhada que, sendo extraído

de uma entrevista informal, tem como objetivo organizar uma reunião entre várias

pessoas.

O usuário digita o nome de todos os participantes da reunião,

juntamente com algumas restrições, tais como a duração da

reunião, quando (vagamente) ela irá acontecer e possivelmente

onde deverá ser realizada. O sistema procede então a uma

checagem, de acordo com os horários pessoais de cada um e com

os do departamento central, e apresenta ao usuário uma série

de datas que todos estão livres. Daí a reunião poderá ser

confirmada e marcada nas agendas pessoais. Algumas pessoas,

porém, irão querer ser consultadas antes de a reunião ser

marcada. Talvez o sistema pudesse enviar uma mensagem

automaticamente e perguntar se a data poderia ser confirmada

antes de marcada definitivamente.

Quadro 6 - Exemplo de cenário de uso. Fonte: (PREECE et al., 2002).

A construção de cenários de caso de uso é considerada uma atividade

primordial, sendo os primeiros passos para o estabelecimento das necessidades e

requisitos e dentre os principais auxílios obtidos de um cenário destaca-se a captura

de comportamentos existentes e a identificação de dados importantes para o

estabelecimento de novos requisitos (PREECE et al., 2002).

47

3.3 MANUTENÇÃO E EVOLUÇÃO DE SOFTWARE

Segundo Sommerville (2007), após a entrega de um software, seu

desenvolvimento não pára, pois as mudanças são inevitáveis para que ele continue

sendo útil, visto que os requisitos surgem e mudam constantemente.

Outro fator que argumenta a evolução do software é economia de recursos

investidos, por exemplo, em um sistema de software que cuida dos ativos de

negócio de uma organização. Ao observar isto, com certeza a melhor idéia é aplicar

melhorias neste sistema ao invés de fazer uma mudança drástica comprando e

adequando outro sistema para a organização (SOMMERVILLE, 2007).

Com base nos estudos de (Lehman, 1996; Lehman et al., 1998; Lehman et

al., 2001) apud Sommerville (2007), foram elaboradas um conjunto de leis com base

no comportamento da manutenção e evolução de sistemas de software, conforme

visualizado no Quadro 7.

Lei Descrição

Mudança Contínua Um programa usado em um ambiente real deve mudar necessariamente ou tornar-se progressivamente menos útil.

Complexidade crescente

À medida que um programa muda, sua estrutura tende a se tornar mais complexa. Recursos extras devem ser dedicados para preservar e simplificar a estrutura.

Evolução de progama de grande porte

A evolução de programa é um processo auto-regulável. Atributos de sistemas como tamanho, tempo entre versões e número de erros reportados é quase invariável em cada versão do sistema.

Estabilidade organizacional

Durante o ciclo de vida de um programa, sua taxa de desenvolvimento é quase constante e independente de recursos dedicados ao desenvolvimento do sistema.

Conservação de familiaridade

Durante o ciclo de vida de um sistema, mudanças incrementais em cada versão são quase constantes.

Crescimento contínuo A funcionalidade oferecida pelos sistemas deve aumentar continuamente para manter a satisfação do usuário.

Qualidade em declínio A qualidade dos sistemas entrará em declínio a menos que eles sejam adaptados a mudanças em seus ambientes operacionais.

Sistema de feedback

Os processo de evolução incorporam sistemas de feedback com vários agentes e loops e você deve tratá-los como sistemas de feedback para conseguir aprimoramentos significativos do produto.

Quadro 7 - Leis de Lehman. Fonte: (SOMMERVILLE, 2007).

48

Sommerville (2007), afirma que existem três tipos diferentes de manutenção

de software, sendo a manutenção para reparo de defeitos, para adaptar o software a

um ambiente operacional diferente e para adicionar funcionalidade ao sistema ou

modificá-la. Este último tipo de manutenção, o qual é adotado neste trabalho, tendo

em vista o desenvolvimento de um módulo para um sistema pré-existente, tem sua

utilização amparada com ocorrência de mudança de requisitos e organizacionais.

3.4 TESTE DE UNIDADE DE SOFTWARE

Nos últimos anos, observou-se que a qualidade tem sido um dos requisitos

mais importantes no desenvolvimento de software, ou seja, em épocas mais remotas

essa atividade era desenvolvida pelo próprio programador que conduzia o projeto da

forma mais cuidadosa possível, evitando (ou tentando evitar) qualquer tipo de erro

que venha a causar futuros prejuízos.

Nos dias de hoje, tem se desenvolvido técnicas modernas de projeto na

disciplina de Engenharia de Software, dedicadas à redução de erros ocorridos na

fase de desenvolvimento de software. Além disso, algumas dessas técnicas são

destinadas à resolução de problemas mais específicos dentro do desenvolvimento

de software, abrangendo desde as funções e objetos de um sistema até o sistema

como um todo (PRESSMAN, 2006).

Por se tratar do desenvolvimento de um módulo, é abordado sobre o teste de

unidade, que visa executar a verificação de erros nas partes mais específicas de um

software convencional (não orientado a objetos), sendo a forma mais adequada para

este tipo de projeto.

Pressman (2006) classifica o teste de unidade, juntamente com o teste de

integração como estratégias para testes de software convencional, ou seja, que não

adota o paradigma de orientação à objetos. O autor também apresenta testes

voltados para aplicações web como: teste de conteúdo, teste de interface com o

usuário, teste no nível de componente, teste de navegação, teste de configuração,

teste de segurança e teste de desempenho.

49

Um teste de unidade é focado nas menores unidades de projeto de software

que são os componentes ou módulos de software. Assim, os testes e os erros

descobertos são limitados à lógica interna de processamento e as estruturas de

dados que formam o escopo do módulo (SOMMERVILLE, 2007; PRESSMAN, 2006).

Os autores afirmam também que este mesmo procedimento pode ser executado de

forma paralela em diversos módulos do software (SOMMERVILLE, 2007;

PRESSMAN, 2006).

Durante a execução do teste de unidade, algumas considerações são de

suma importância, devendo ser adotadas para que este possa ser concluído de

forma satisfatória. Seguindo essa idéia, e como exemplo de fator importante a ser

considerado, tem-se que o teste de fluxo de dados através da interface deve ser

executado antes de qualquer outro teste, devido a importância dada ao fluxo de

entrada e saída de dados, bem como o funcionamento das estruturas de dados

locais e o impacto causado nos dados globais (PRESSMAN, 2006).

Ao continuar a atividade de testes, é verificada também a estrutura lógica de

dados local a fim de garantir a integridade dos dados armazenados temporariamente

em variáveis durante a execução de um algoritmo (PRESSMAN, 2006). Para garantir

a operação adequada do módulo, são testadas as condições-limite responsáveis por

limitar ou restringir o processamento (PRESSMAN, 2006). Todos os caminhos

independentes (conhecidos também como caminhos básicos na Engenharia de

Software) são verificados para garantir o bom funcionamento do módulo como um

todo. E por fim, todos os caminhos de manipulação de erros são testados,

garantindo mais confiabilidade ao módulo ou unidade do sistema, estando apto a ser

integrado às outras unidades do software e/ou ao software na sua versão completa

(PRESSMAN, 2006).

50

Este procedimento pode ser visualizado de forma mais “simplificada” na

Figura 11:

Figura 11. Esquema do teste de unidade. Fonte: (PRESSMAN, 2006).

4 TECNOLOGIAS PARA DESENVOLVIMENTO WEB

Após o surgimento da internet, em meados da década de 90, o acesso à rede

restringia-se apenas a um pequeno grupo de pessoas que tinham finalidades mais

específicas de uso, tais como pesquisas, distribuição do conhecimento e troca de

informações entre universidades, instituições de pesquisas e unidades militares.

No decorrer dos anos, milhares de pessoas passaram a ter maior

dependência do uso da rede, seja para o entretenimento, estudo ou trabalho. Essa

necessidade de informatização, conhecida também como inclusão digital tornou

possível que até comunidades mais carentes e isoladas tivessem o acesso à

internet. Na mesma proporção, este evento também desencadeou a necessidade de

serviços, produção de conteúdo e suporte para a web, de forma a atender

requisições e exigências de usuários espalhados por todo o mundo. Essa mudança

influenciou e, em muitos casos obrigou profissionais que antes trabalhavam e

conheciam os paradigmas, metodologias, conceitos, tecnologias e linguagens para

desenvolvimento de aplicativos desktop, a buscar e adotar estes conhecimentos

voltados para o desenvolvimento web.

Para o desenvolvimento deste trabalho, também foram adotadas algumas

dessas tecnologias, sendo descritas nas próximas seções como embasamento

fundamental para o estudo de caso.

52

4.1 LINGUAGEM HTML

Hypertext Markup Language ou Linguagem de Marcação de Hipertexto

(HTML) é a linguagem base para a composição de páginas na web sendo

naturalmente interpretada por navegadores. Possui um conjunto de tags e

propriedades definidas, que consiste em elementos, configuração ou formatação

para uma página. É utilizada em muitos casos, em conjunto com outras linguagens

de programação, com a finalidade de gerar conteúdo de forma dinâmica e

estabelecer maior nível de interatividade e comunicação com os usuários

(PFAFFENBERGER et al., 2004).

Segundo Costa (2007), os documentos de código-fonte com HTML são

implementados através do uso das tags que informam ao browser (navegador web)

a apresentação de textos, tabelas e outros itens. Essas tags são constituídas por um

comando que fica entre os símbolos de “<” e “>”, sempre começando por “<...>” e

fechadas por </...>. Dessa forma, um documento HTML básico é formado pelas tags

apresentadas na Figura 12:

Figura 12 - Estrutura básica de um documento HTML.

A aparência e as características dos componentes que compõem um

documento HTML podem ser definidas de duas formas: no próprio arquivo HTML,

incluindo nas propriedades das tags que se deseja formatar ou através da utilização

de Cascading Style Sheets ou Folhas de Estilo em Cascata (CSS) (SOMERA, 2006).

53

4.2 CASCADING STYLE SHEETS

A CSS trata-se de uma linguagem utilizada para definir a aparência das

páginas web, ou seja, ao ser incluída em um site, esta se torna responsável por

controlar as características de fonte, cores, margens, linhas, alturas, larguras,

imagens de fundo, posicionamentos, entre outras (SOMERA, 2006).

O layout de sites também pode ser definido pelo documento HTML, porém a

CSS fornece aos desenvolvedores mais opções e mais eficiência no

desenvolvimento de sites, uma vez que são utilizadas com o intuito de definir uma

formatação mais organizada das páginas, ou seja, sem misturar as tags de

formatação com as tags de conteúdo, o que torna uma página totalmente fora dos

padrões de organização. Com o uso do CSS, esse procedimento é feito de forma

prática, por exemplo, em um mesmo site sempre existem componentes com estilos

iguais (de cor, tamanho ou fonte) e que são distribuídos em páginas diferentes.

Dessa forma, em vez de ter que alterar essas propriedades em cada tag, dispersos

em várias páginas no site, isto pode ser definido em um único arquivo CSS externo

(GOMES, 2010; HIROMI, 2007; SOMERA, 2006).

A Figura 13 mostra a estrutura de uma regra em CSS. Segundo Meyer (2006)

cada regra possui duas partes fundamentais, sendo o seletor e o bloco de

declaração. Cada bloco de declaração é composto por uma ou mais declarações, e

cada declaração é constituída de uma propriedade e um valor. O seletor, conforme

observado no canto esquerdo da figura é responsável por definir a parte do

documento que será afetada. Neste exemplo, todos os elementos definidos pela tag

h1 são afetados conforme as características definidas no bloco de declaração.

Figura 13 – Estrutura de uma regra em CSS. Fonte: (MEYER, 2006).

54

4.3 LINGUAGEM JAVASCRIPT E BIBLIOTECA JQUERY

Criado pela empresa Netscape, JavaScript é uma linguagem de programação

interpretada, com recursos para orientação a objetos e incorporada em navegadores

web. Uma das principais características da linguagem é a capacidade de incluir

programas executáveis que interagem com o usuário, controlam o navegador e

criam o conteúdo HTML dinamicamente. O modelo de objeto de documento ou

(Document Object Model - DOM) é o recurso responsável pela dinamicidade das

páginas, especialmente por permitir a manipulação direta de qualquer componente

em uma página HTML por meio da execução de scripts (FLANAGAN, 2002).

A linguagem JavaScript pode ser utilizada para executar os seguintes tipos de

soluções (GOODMAN, 2001):

a) Fazer com que a página web responda ou reaja diretamente à interação do

usuário com elementos do formulário (campos de entrada, áreas de texto,

botões, botões de opção, caixas de seleção, listas de seleção) e links de

hipertexto;

b) Distribuir pequenas coleções de informações tipo banco de dados e

oferecer uma interface amigável para esses dados;

c) Controlar a navegação por vários frames, plug-ins ou applets Java com

base nas escolhas do usuário no documento HTML;

d) Pré-processar dados no cliente antes do envio a um servidor;

e) Alterar o conteúdo e os estilos nos browsers modernos dinamicamente e

instantaneamente em resposta à interação com o usuário.

Atualmente, o desenvolvimento utilizando o JavaScript “puro”, tem se tornado

uma atividade mais rara. Tal fato vem ocorrendo devido dificuldades encontradas

durante a execução de tarefas triviais e o surgimento de muitas bibliotecas criadas

por programadores que possuem um conhecimento mais profundo sobre a

linguagem, e que desejam facilitar e agilizar processo de desenvolvimento

(FLANAGAN, 2002).

A simplicidade é um fator primordial, que nos últimos anos tem sido adotada

por programadores de todo o mundo. Esta característica é também valorizada e

adotada por Jonh Resig, o criador da biblioteca JQuery, que teve como um dos

motivos para o desenvolvimento desta idéia, sua frustração com a complexidade de

55

se escrever JavaScript para obter simples resultados. Jonh Resig demonstrou este

sentimento no dia 22 de agosto de 2005 escrevendo um artigo em seu blog, onde

publicou também alguns exemplos propondo seletores CSS com o objetivo de

simplificar e dar maior eficiência no código. No dia 14 de janeiro de 2006, Jonh Resig

apresentou os resultados do seu estudo em uma palestra por nome de “JQuery, a

nova onda para JavaScript”, criando também neste mesmo ano o primeiro plugin

(SILVA, 2008).

Dentre diversas funcionalidades, JQuery pode ser utilizada para

(CASTLEDINE & SHARKIE, 2010; SILVA, 2008):

a) Adicionar efeitos visuais e animações;

b) Acessar e manipular o DOM;

c) Buscar informações no servidor sem necessidade de recarregar a página;

d) Prover interatividade;

e) Alterar conteúdos;

f) Modificar apresentação e estilização CSS;

g) Simplificar tarefas específicas de JavaScript.

4.4 LINGUAGEM DE PROGRAMAÇÃO PHP

Hypertext Preprocessor (PHP) é uma linguagem de programação muito

utilizada na criação de sites web dinâmicos, possibilitando uma interação com o

usuário mediante formulários, parâmetros de URL, links, etc (VIVAS, 2006;

WELLING & THOMSON et al., 2005). É executado no servidor, possibilitando a

interação com banco de dados e aplicações existentes nele, sem expor o código

fonte ao cliente (VIVAS, 2006; WELLING & THOMSON et al., 2005). Foi criado por

volta de 1994 por Rasmus Lerdof, que a princípio utilizava em seu próprio site. Dois

anos mais tarde o PHP deixou de ser um projeto pessoal de Rasmus e passou a ser

desenvolvido por uma equipe de colaboradores, evoluindo o projeto constantemente

(VIVAS, 2006; WELLING & THOMSON et al., 2005).

O desenvolvimento de web sites com PHP apresenta uma infinidade de

vantagens, podendo ser utilizado na maioria dos sistemas operacionais como Linux,

56

variantes da plataforma Unix (Solaris e OpenBSD), Microsoft Windows, entre outros;

é suportado pela maioria dos servidores web atuais, incluindo Apache, internet

Information Server (IIS), Personal Web Server e muitos outros. Outra vantagem

apresentada após a sua versão 4, é o suporte à programação orientada a objetos. A

linguagem PHP também permite a implementação de outras funcionalidades mais

específicas como a geração de imagens, geração de arquivos PDF, animações em

flash criadas dinamicamente, geração de padrões de texto como XHTML e XML, etc

(WELLING & THOMSON et al., 2005).

Em relação ao suporte a banco de dados, PHP está acessível a uma ampla

variedade, com suporte de driver nativo para mais ou menos 15 dos mais populares

banco de dados, destacando-se entre eles o MySQL, Oracle, Interbase e

PostgreSQL. Também possui suporte a um grande número de protocolos como

POP3, IMAP e LDAP, SNMP, NNTP e HTTP (MORAZ, 2005; CONVERSE & PARK,

2003).

Após evoluir para sua versão 5, o PHP sofreu algumas melhorias, sendo

destacada como principal o suporte à programação orientada a objetos. Assim,

recursos como herança, atributos, métodos, classes, construtores e dentre outros

encontrados nas linguagens como Java e C++ já estão disponíveis a partir desta

versão, que fornece ao programador as opções de programar da forma estruturada

ou orientada à objetos (WELLING & THOMSON et al., 2005).

O funcionamento do PHP é demonstrado na Figura 14 em mais detalhes,

onde mostra que após a requisição do navegador cliente, o servidor é responsável

por executar o processamento e então enviar ao navegador o resultado no formato

HTML.

Figura 14 – Esquema de funcionamento do PHP. Fonte: (BARRETO, 2002).

57

4.5 TECNOLOGIA AJAX

Ao contrário do que muitas pessoas pensam, Ajax não é uma linguagem de

programação, tratando-se de uma tecnologia que utiliza recursos das linguagens

JavaScript e XML para definir solicitações assíncronas feitas do lado cliente da

aplicação para o servidor, eliminando o tempo de espera que ocorre no momento em

que a página está recarregando seu conteúdo. O processo de realizar requisições

de informações em uma página sem a necessidade de recarregar por completo foi o

fator que mais marcou e fez com que a tecnologia Ajax fosse adotada e aceita por

toda a comunidade de programadores web, o que trouxe também substancial

melhora no modelo de interação, pois o processo de recarga de página, em alguns

casos, quando demorado, deixava o usuário frustrado a ponto de desistir de realizar

sua tarefa (NIEDERAUER, 2007; MCLAUGHLIN, 2006).

Em uma aplicação convencional, o processo de interação inicia quando o

navegador cliente faz uma solicitação através do protocolo HTTP ao servidor,

requisitando uma página. Esta página retorna, sendo reproduzida no navegador

web. Se logo após este procedimento, o usuário fizer a submissão de um formulário

ou clicar em um link, será necessário que a página seja completamente carregada

(NIEDERAUER, 2007). Na Figura 15, segue uma demonstração melhor de como

ocorre este processo.

Figura 15 - Modelo convencional de aplicação web. Fonte: (RAO, 2008).

58

Para uma aplicação baseada na tecnologia Ajax, este procedimento é

executado apenas na primeira vez que é carregada uma página web específica. Se

o usuário realizar outra requisição na mesma página, uma solicitação é feita através

do protocolo HTTP ao servidor, onde processa o pedido e retorna a resposta no

formato XML, alterando apenas o ponto dentro da página HTML que é necessário,

continuando todo o restante estático (MCLAUGHLIN, 2006). A forma como ocorre

este processo, é melhor visualizada na Figura 16.

Figura 16 - Modelo de aplicação web baseada em Ajax. Fonte: (RAO, 2008).

Outra vantagem da utilização desta tecnologia é a possibilidade de realizar

várias requisições ao mesmo tempo, ou seja, sua estrutura de funcionamento,

denominada também pelo autor de motor Ajax, permite realizar simultaneamente

diversas requisições (NIEDERAUER, 2007).

5. ESTUDO DE CASO

Este capítulo descreve a aplicação prática dos principais métodos,

tecnologias e ferramentas envolvidas na implementação de um módulo SIG WEB,

formando o estudo de caso proposto neste trabalho.

De maneira geral o módulo a ser implementado, consiste em uma parte

específica de software projetado e desenvolvido para ampliar a capacidade de

georreferenciamento do sistema DRIS, visto que este ainda não possui um

tratamento adequado para este tipo de informação.

Para satisfazer os requisitos que proporcionam o funcionamento correto do

módulo fez-se necessário o desenvolvimento das seguintes atividades (Figura 17):

Figura 17 – Esquema de fluxo das atividades desenvolvidas durante o estudo de caso.

a) Levantamento de requisitos e modelagem: teve como objetivo extrair os

principais requisitos do módulo e definir as principais funcionalidades a

serem implementadas;

b) Configuração do banco de dados geográfico: foram criados mecanismos

para que o banco de dados convencional do sistema DRIS ofereça suporte

para o gerenciamento de dados geográficos;

60

c) Instalação e configuração do servidor de mapas: para fornecer o serviço

WFS, atuando na comunicação entre o banco de dados e a aplicação

cliente;

d) Prototipação: para validar os requisitos e reduzir o esforço empregado

durante a implementação;

e) Implementação: codificação do módulo;

f) Testes: para proporcionar o funcionamento correto do módulo.

5.1 VISÃO GERAL

Este trabalho foi desenvolvido com o objetivo de ampliação o sistema DRIS,

disponível no endereço (http://www.dris.com.br), fornecendo recursos relacionados

ao processamento geográfico das informações, permitindo que os usuários possam

usufruir desta tecnologia para empregar maior eficiência no processo de avaliação

nutricional de culturas agrícolas.

Tendo como base o ANEXO A – UTILIZAÇÃO DO SISTEMA DRIS, do ponto

de vista do usuário os procedimentos para executar as avaliações nutricionais de

plantas ocorrem da seguinte maneira: após ter criado uma conta na área restrita e

logar no sistema, o usuário escolhe o tipo de cultura que deseja analisar, e então por

meio do menu à esquerda (Figura 18), ele aciona o cadastro de análise foliar.

61

Figura 18 – Interface do sistema DRIS visualizada após a escolha de uma cultura agrícola.

Entretanto, para cadastrar uma análise foliar é necessário antes, cadastrar de

forma hierárquica um estabelecimento (propriedade rural), a gleba de coleta

(pequenas áreas de terra dentro do estabelecimento) e em seguida a safra. A safra

representa determinada cultura que fica plantada por um período específico sobre a

gleba, dessa forma, em cada ano devem ser cadastradas novas safras em uma

mesma gleba. O módulo desenvolvido encaixa exatamente nesta parte do sistema,

sendo responsável por gerenciar geograficamente as áreas de estabelecimentos e

glebas.

62

Após ter cadastrado o estabelecimento a gleba e a safra, o usuário poderá

então fazer o cadastro de análise foliar, conforme observado na Figura 19.

Figura 19 – Interface do sistema DRIS para cadastro de análise foliar.

Ao finalizar o cadastro de análise foliar, o usuário poderá ativar o cálculo

utilizado para diagnosticar o estado nutricional das plantas. Tendo feito isso, é

disponibilizado no sistema uma página para geração do relatório resultante da

análise. O relatório apresenta ao usuário informações importantes como fórmulas,

normas, critério de interpretação dos índices DRIS, nutrientes permitidos na análise,

dentre outros (Figura 20).

63

Figura 20 – Relatório com diagnóstico nutricional de culturas agrícolas do sistema DRIS.

É importante ressaltar que este procedimento é utilizado por engenheiros

agrônomos ou pessoas capacitadas com o conhecimento que envolve o estudo

nutricional de plantas. Dessa forma este sistema é voltado para este tipo de

usuários, e tem como finalidade substituir os cálculos que antes eram realizados por

meio de planilhas eletrônicas dentre outros meios considerados “arcaicos” que

exigiam dos usuários mais habilidade além de consumir recursos que são

dispensados com a utilização do DRIS via interface web.

O módulo desenvolvido abrange o gerenciamento espacial das áreas de

estabelecimento e glebas por meio de uma interface de mapas interativos na web.

Dessa forma, constitui-se como uma ampliação da visão geográfica que os usuário

têm sobre o sistema DRIS, tendo em vista que essas áreas são representadas

geograficamente apenas por coordenadas geográficas. Dessa forma, os principais

procedimentos adotados neste trabalho para construir este módulo são

demonstrados nas próximas seções.

64

5.2 FERRAMENTAS UTILIZADAS

O desenvolvimento do módulo, que incluiu desde as atividades de

configuração do banco de dados até a execução de testes, foi conduzido com o

apoio de diversas ferramentas, as quais foram selecionadas, levando em conta o

nível de familiaridade com o autor e o nível de disponibilidade e confiabilidade,

sendo essas características observadas em projetos similares desenvolvidos por

outros autores (RAMOS, 2009; BARRIGUINHA, 2008; KUNIYOSHI et al., 2009;

CÂMARA et al., 2003; ARAGÃO, 2009). A seguir são descritas cada uma das

ferramentas, destacando o fator de contribuição com o trabalho:

a) PostgreSQL 8.3 com PostGIS 1.3.6: SGBD utilizado para a manutenção do

banco de dados geográfico;

b) PgAdmin 3: Interface gráfica para facilitar o gerenciamento do SGBD

PostgreSQL;

c) GeoServer 2.0.1: Servidor de mapas utilizado para estabelecer a

comunicação do banco de dados geográficos com a interface cliente.

d) ArgoUML: Ferramenta utilizada na elaboração do diagrama de caso de

uso;

e) Notepad++: Versão aprimorada do boco de notas, utilizado em todo o

processo de codificação, tanto na prototipação quanto na implementação

propriamente dita do módulo;

f) Xampp 1.7.7: Pacote com diversas ferramentas para execução de páginas

web, destacando Apache 2.2.21 e PHP 5.3.8 para uso neste trabalho;

g) Navegadores web – internet Explorer versão 8, Google Chrome versão 16

e Mozilla Firefox versão 3.6.26 utilizados na exibição das páginas e nos

casos de teste do módulo.

Através da utilização destas ferramentas, tornou-se possível o

desenvolvimento do estudo de caso, além de proporcionar um ambiente

computacional adequado para a realização das atividades relacionadas à construção

do módulo. Portanto, essas atividades são descritas em mais detalhes nas seguintes

seções.

65

5.3 LEVANTAMENTO DE REQUISITOS E MODELAGEM

O sistema web DRIS é resultante de um projeto de pesquisa do CNPq em

colaboração com a EMBRAPA-AC.

A idéia de desenvolvimento do módulo surgiu com o incentivo e o

investimento do CNPq na produção de novas tecnologias, e ao mesmo tempo foi

observada pelo co-orientador do trabalho a necessidade de “enriquecer

geograficamente” o sistema, visto que até o momento presente ele é voltado para o

processamento de informações que compõem o estado nutricional de plantas, não

dando a importância devida às informações de localização espacial. Portanto, esta

idéia inicial foi colocada em prática pelo orientador do projeto, que ficou responsável

por supervisionar e definir os principais requisitos para a implementação deste

módulo.

O processo de levantamento e análise de requisitos foi elaborado de forma

simplificada tendo em vista a familiaridade com o sistema DRIS. A princípio, foi

capturado um documento (ANEXO A – UTILIZAÇÃO DO SISTEMA DRIS), que

descreve sucintamente a utilização do mesmo. Este documento, mostra de forma

clara os procedimentos que relacionam as informações de estabelecimentos e

glebas com o restante do sistema, principalmente na descrição apresentada no

Quadro 8:

“As análises foliares somente são cadastradas seguindo uma

hierarquia pré-definida. Nesta hierarquia, para cadastrar uma

análise foliar será necessário informar a propriedade rural

onde a amostragem foi feita, o local ou gleba de coleta e,

finalmente, a safra. A safra representa um período de

produção específico em determinada gleba. Assim, a cada ano,

para uma mesma gleba, devem ser cadastradas novas safras.”

Quadro 8 - Trecho de texto capturado do ANEXO A – UTILIZAÇÃO DO SISTEMA DRIS.

Foi elaborado um cenário de uso (APÊNDICE A – CENÁRIO DE USO DO

MÓDULO) que descreve as principais características do módulo a ser implementado

e o cadastramento completo (dados convencionais e geográficos) de

estabelecimentos e glebas. Também foi elaborado um documento de requisitos

simplificado (APÊNDICE B – DOCUMENTO DE REQUISITOS DO MÓDULO),

visando demonstrar os principais aspectos funcionais e não-funcionais no projeto do

66

módulo, além de especificar os requisitos mínimos para configuração de hardware e

software. Os requisitos funcionais deste projeto são demonstrados no Quadro 9.

ID Requisito Descrição Caso de uso

[RF01] Manter dados

convencionais de estabelecimentos

Permitir listagem, inclusão, alteração e exclusão de

registros de estabelecimentos.

Manter estabelecimentos.

[RF02] Manter dados

convencionais de glebas


registros de glebas. Manter glebas.

[RF03] Gerenciar dados geográficos de

estabelecimentos

Permitir a inclusão e alteração de mapas (polígonos)

relacionados aos estabelecimentos cadastrados.

Gerenciar dados geográficos de

estabelecimentos.


glebas

Permitir a inclusão e alteração de mapas (polígonos)

relacionados às glebas cadastradas

Gerenciar dados geográficos de

glebas.

Quadro 9 - Lista de requisitos funcionais para implementação no módulo.

Conforme descrito na seção 3.2, através do cenário de uso e dos requisitos

funcionais (Quadro 9), foi elaborado um diagrama de caso de uso, utilizando a

ferramenta ArgoUML, com objetivo de esclarecer sobre o funcionamento do módulo

e sua interação com os usuários do DRIS. O resultado deste diagrama pode ser

observado na Figura 21.

Figura 21 - Diagrama de caso de uso do módulo.

Por meio de entrevistas com o orientador do projeto, foram adquiridos

requisitos mais específicos que requisitam a validação dos dados geográficos

inseridos pela interface bem como a ampliação das opções de entrada de dados

geográficos, ao permitir a inserção de coordenadas para a criação de geometrias

(polígonos).

67

Após reunir os requisitos extraídos da documentação, bem como os

adquiridos com o orientador do projeto, foram definidas as principais funcionalidades

a serem implementadas no módulo, conforme segue:

a) Interface para listagem de estabelecimentos, onde é possível visualizar

todos os dados convencionais e executar as ações de inclusão, alteração e

exclusão;

b) Interface para listagem de glebas, onde é possível visualizar todos os

dados convencionais e executar as ações de cadastro, alteração e

exclusão;

c) Interface com mapa para inclusão e alteração de informações geográficas

de estabelecimentos e glebas;

d) Mecanismo para organização da interface, de forma que os dados

convencionais se liguem à seus respectivos dados geográficos;

e) Permitir que os dados geográficos sejam removidos apenas com a

exclusão do registro como um todo.

f) Mais de 50% da área de uma gleba deve estar dentro da área do

estabelecimento;

g) No máximo 1/3 da extensão espacial de uma gleba deve ocupar a área de

outra;

h) Criação de geometrias através da entrada de dados por coordenadas

geográficas.

Com os requisitos definidos, foi dado início na atividade de configuração do

banco de dados geográfico, sendo esta tarefa de suma importância para o

funcionamento do módulo, visto que todos os dados geográficos adquiridos ou

apresentados pela interface cliente da aplicação são processados por um banco de

dados adequado a este tipo de aplicação. Dessa forma, tais informações são

apresentadas em mais detalhes na seção seguinte.

68

5.4 CONFIGURAÇÃO DO BANCO DE DADOS GEOGRÁFICO

Para executar o processo de configuração do banco de dados geográfico

foram utilizadas as ferramentas PostgreSQL 8.3, sua extensão geográfica PostGIS

1.3.6 e o esquema do banco de dados do sistema DRIS com todos os registros

armazenados e importado para o SGBD. A Figura 22 apresenta por meio do

Diagrama Entidade-Relacionamento (DER) que foi construído, a estrutura das

tabelas “estabelecimentos” e “glebas”, as quais foram utilizadas durante o processo

de configuração do banco de dados geográfico.

Figura 22 – Estrutura das tabelas “estabelecimentos” e “glebas”.

Utilizando a ferramenta PgAdmin 3, foi possível visualizar os registros

dessas tabelas antes de ser executado as alterações, conforme é observado

respectivamente nas Figuras (23 e 24):

Figura 23 - Registros da tabela “estabelecimentos”.

69

A marcação de cor vermelha na Figura 23 mostra os campos “coorlestesede”

e “coornortesede” que armazenam a localização dos estabelecimentos no formato

de coordenadas.

Figura 24 - Registros da tabela glebas.

A Figura 24, também mostra os campos que armazenam a localização das

glebas no formato de coordenadas. É importante salientar que estes campos por

não serem obrigatórios, raramente são inseridos pelos usuários.

Entretanto, com a configuração estes campos são removidos, sendo

substituído por campos geométricos, os quais são adicionados executando a função

AddGeometryColumn() do PostGIS (seção 2.4.1), demonstrada na Figura 25.

Figura 25 - Código para adicionar campos geométricos nas tabelas “estabelecimentos” e “glebas”.

Por fim, após adicionar os campos geométricos, também foram adicionados

índices espaciais nas tabelas “estabelecimentos” e “glebas” (Figura 26), tendo como

objetivo aumentar o desempenho do SGBD em consultas espaciais.

Figura 26 - Código para acrescentar índices nas tabelas “estabelecimentos” e “glebas”.

Adotando os procedimentos aqui descritos, o banco de dados se torna apto a

armazenar e manipular de forma eficiente as informações geográficas de

estabelecimentos e glebas. Entretanto, ao contrário de aplicações convencionais,

70

um SIG WEB necessita de um serviço para estabelecer a comunicação entre o lado

cliente da aplicação e o banco de dados. Para isto, foi utilizado o GeoServer para

prover este serviço, denominado WFS.

Visto a importância desta ferramenta, a próxima seção demonstra os passos

utilizados para a instalação e configuração da mesma, sendo executado este

procedimento para se ter seu funcionamento correto e em sincronia com o banco de

dados geográfico.

5.5 INSTALAÇÃO E CONFIGURAÇÃO DO SERVIDOR DE MAPAS

Esta seção descreve o processo de instalação e configuração do servidor de

mapas GeoServer na sua versão 2.0.1. Este procedimento foi executado em uma

máquina com o sistema operacional Windows 7 com 32 bits, e tem como requisitos

mínimos de hardware e software para seu funcionamento adequado, conforme

definido no documento de requisitos (APÊNDICE B – DOCUMENTO DE

REQUISITOS DO MÓDULO). De forma geral, a configuração desta ferramenta

consiste em sincronizá-la com o banco de dados geográfico a fim de prover o serviço

WFS, sendo este, responsável por codificar os dados geográficos no formato GML,

de forma que tanto o banco de dados geográfico como o lado cliente da aplicação

possam fazer o uso dos dados.

A Figura 27 mostra a etapa final deste processo de configuração, onde as

tabelas “estabelecimentos” e “glebas” são definidas como layers4 para a publicação

dos dados geográficos no formato WFS.

4 O Layer representa um componente para visualização de determinada camada de informação, onde

são definidos parâmetros como nome, tipo (ponto, linha ou polígono) e status (ativado ou desativado).

Além desses atributos, um layer permite a ligação com fontes de dados geográficos, podendo ser um

banco de dados ou arquivos que contém dados geográficos (ARAGÃO, 2009).

71

Figura 27 - Etapa final do processo de instalação e configuração do GeoServer.

Dessa forma, a versão completa do processo de instalação e configuração

pode ser visualizada em mais detalhes através do APÊNDICE C – INSTALAÇÃO E

CONFIGURAÇÃO DO GEOSERVER.

Portanto, executando o processo descrito nesta seção, faz-se suficiente para

dar início ao processo de implementação do módulo. Entretanto, com intuito de

validar os requisitos expostos durante a fase de levantamento de requisitos e

modelagem além de reduzir o esforço empregado durante a codificação do módulo,

foram elaborados protótipos de alta-fidelidade, sendo este procedimento descrito

detalhadamente na próxima seção.

5.6 PROTOTIPAÇÃO

Conforme descrito na seção 3.1, antes de dar início à implementação do

módulo, viu-se necessário a criação de protótipos de alta-fidelidade, tendo como

objetivo principal a validação dos requisitos, principalmente das questões de

organização da interface, visando proporcionar maior usabilidade, confiabilidade e

72

eficiência aos usuários do sistema. Além disso, esta atividade tem como finalidade

reduzir o esforço empregado na fase de implementação, onde utiliza como ponto de

partida todos os protótipos que foram construídos.

Os primeiros protótipos a serem construídos, com o intuito de facilitar a

interação com o usuário, apresentavam a idéia de integrar por meio de uma única

interface o gerenciamento das informações geográficas e das informações

convencionais do banco de dados, ou seja, todos os tipos de transações como

consultas, inclusão, alteração e exclusão de estabelecimentos e glebas devem ser

feitas em uma mesma tela. A Figura 28 apresenta um esquema da interface que foi

produzida com os protótipos.

Figura 28 - Prototipação para agrupar em uma tela o gerenciamento de dados convencionais e geográficos.

Antes de finalizar a implementação deste protótipo, foram constatados erros

provenientes da desorganização do código, visto que a maior parte das funções

deve ser codificada em um mesmo arquivo, o que dificultava a identificação de erros

e tornava a interface inconsistente.

Com base nesta experiência, decidiu-se alterar os requisitos funcionais para a

forma como está descrita no ANEXO B – DOCUMENTO DE REQUISITOS DO

MÓDULO (no quadro de requisitos funcionais), que visa a separação da interface

73

em: manutenção de dados convencionais de estabelecimentos, manutenção de

dados convencionais de glebas, gerenciamento de dados geográficos de

estabelecimentos e gerenciamento de dados geográficos de glebas. Por meio de um

esquema, a Figura 29 mostra o resultado da idéia de separação e organização das

informações convencionais e geográficas do módulo.

Figura 29 - Esquema de prototipação para separação de dados convencionais e geográficos do módulo.

Conforme observado na Figura 29, a organização da interface possibilita que,

da listagem de estabelecimentos (tela que permite todas as operações de transação

com os registros) o usuário seja redirecionado para um arquivo diferente que contém

a tela para cadastramento ou alteração dos dados geográficos. A listagem de

estabelecimentos também permite que o usuário, por meio da seleção de um

determinado estabelecimento, seja redirecionado para uma tela com a listagem de

glebas. Da mesma forma, a listagem de glebas permite que o usuário seja

redirecionado para as telas de inclusão ou alteração de dados geográficos.

Vale lembrar que toda a estrutura aqui apresentada foi codificada e, visto a

eficiência dos resultados após verificar seu funcionamento, decidiu-se iniciar a

implementação (descrita na próxima seção), tendo como base todos os protótipos de

alta-fidelidade que até então foram construídos.

74

5.7 IMPLEMENTAÇÃO DA INTERFACE CLIENTE

Tendo posse dos protótipos criados durante a fase de prototipação bem como

o documento de requisitos com as funcionalidades devidamente definidas, deu-se

início à implementação do módulo.

De forma hierárquica, primeiramente foram implementadas as funcionalidades

para gerenciamento dos dados convencionais de estabelecimentos, e depois de

glebas. Após a organização dos dados convencionais, foram implementadas as

funcionalidades para gerenciamento dos dados geográficos, sendo esta a parte mais

importante e complexa do módulo.

5.7.1 GERENCIAMENTO DE DADOS CONVENCIONAIS

O ponto de partida utilizado na fase de implementação foram os protótipos

das interfaces principais do módulo que consistiam em fazer as listagens de

estabelecimentos e glebas, conforme observado nas Figuras (30 e 31).

Figura 30 - Interface para listagem de estabelecimentos.

75

Na Figura 30, a listagem de estabelecimento é a interface principal do

módulo, visto que a partir dela o usuário é redirecionado para cadastrar novos

registros de estabelecimentos, alterar registros existentes, cadastrar/alterar dados

geográficos, ir para a listagem de glebas (Figura 31) relacionadas ao

estabelecimento e executar a exclusão do registro.

Figura 31 - Interface para listagem de glebas.

Assim como na listagem de estabelecimentos, a listagem de glebas permite

ao usuário executar o cadastramento, alteração, cadastramento/alteração de dados

geográficos e exclusão, conforme visualizado na Figura 31.

A listagem de estabelecimento foi criada para listar todos os estabelecimentos

de um usuário logado no sistema DRIS. A listagem de glebas permite visualizar

todas as glebas de um determinado estabelecimento, após selecioná-lo.

Nas interfaces para listagem foram adaptados por meio da biblioteca JQuery

mecanismos de paginação e ordenação alfabética, permitindo maior organização

dos registros. Estas interfaces também permitem a identificação de dados

geográficos nos registros, ou seja, caso já tenha sido cadastrado, o usuário é

redirecionado para a interface de alteração. Quanto à ação de remover os registros,

esta é acionada na própria interface de listagem, e ao ser confirmado, todo o registro

(incluindo os dados geográficos) é removido do banco de dados. A Figura 32

demonstra o resultado que foi produzido.

76

Figura 32 - Resultado da interface para listagem de estabelecimentos.

Todo o processamento lógico para executar as operações de cadastramento,

alteração e exclusão de dados convencionais foram baseados na biblioteca JQuery

(seção 4.3) com a utilização de requisições assíncronas da tecnologia Ajax (seção

4.5). Dessa forma, conforme observado na Figura 33, os dados e parâmetros eram

capturados por meio da interface (formulários e botões) e submetidos de forma

assíncrona para o arquivo “geo_sistema.php” através da função $_POST() (linha 29)

do JQuery.

Figura 33 - Trecho de código que envia dados de forma assíncrona para o arquivo “geo_sistema.php”.

77

O arquivo “geo_sistema.php” foi criado para organizar o processamento de

solicitações assíncronas do módulo, ou seja, é neste arquivo que ocorre grande

parte das operações com o banco de dados. Conforme observado na Figura 34, os

dados são obtidos da solicitação, e conforme o tipo de operação estes dados são

submetidos à execução SQL do PostgreSQL.

Figura 34 - Trecho de código do arquivo “geo_sistema.php”, responsável por executar uma consulta SQL vinda de uma solicitação assíncrona.

Após executar as instruções, é enviada uma resposta à interface, podendo

ser uma mensagem simples ou dados resultantes da consulta que foi executada.

Neste exemplo, conforme observado na Figura 34 (linhas 22 a 29), visto que se

refere a um cadastro de estabelecimento, a resposta mostra se o processamento

ocorreu de forma satisfatória ou não.

Por meio da função de retorno, observada na Figura 33 (entre as linhas 31 e

47) pode ser processada e/ou apresentada na interface (Figura 35).

78

Figura 35 - Exemplo de interface cliente para cadastro de informações convencionais.

De forma similar a esta que foi apresentada até aqui (cadastro de

estabelecimentos), ocorre também para a implementação das interfaces que atuam

no gerenciamento dos dados convencionais, sendo alteração de estabelecimentos,

exclusão de estabelecimentos, cadastro de glebas, alteração de glebas e exclusão

de glebas.

Portanto, tendo finalizado a codificação das interfaces que gerenciam os

dados convencionais, deu-se início na codificação da parte espacial, sendo esta

mais importante e complexa do módulo, descrita em mais detalhes na seção

seguinte.

5.7.2 GERENCIAMENTO DE DADOS GEOGRÁFICOS

Após construir as interfaces para manipular os dados convencionais, deu-se

início à implementação das interfaces para fazer o gerenciamento geográfico das

informações.

A parte destinada ao tratamento das informações geográficas é

substancialmente mais complexa que as outras, pois além do necessário para se ter

o funcionamento da parte convencional, esta necessita da utilização de outros

79

recursos como a biblioteca OpenLayers, serviço WFS do GeoServer e a camada da

API Google Maps.

Dessa forma foram obtidas, a biblioteca OpenLayers na sua versão 2.9 em

seu site (http://www.openlayers.org/) e a chave da API Google Maps pelo endereço

(http://code.google.com/intl/pt-BR/apis/maps/signup.html), os quais devem ser

incluídos na página a ser implementada, por meio de um recurso HTML utilizado

para importação, conforme observado no Quadro 10.

<script src="<caminho do diretório (OpenLayers) ou chave

fornecida pelo Google Maps>" type="text/javascript"></script>

Quadro 10 - Exemplificação de código para inclusão da biblioteca OpenLayers e da API Google Maps.

Para a implementação do mapa, foram utilizadas as instruções de código

apresentadas na Figura 36. Conforme pode ser observado neste trecho de código,

nas linhas entre 11 e 18 é criado o objeto Map, responsável por definir o mapa

propriamente dito na interface, e juntamente a ele são acoplados os principais

controles (entre as linhas 13 e 17). Na linha 20 é criada a camada base, sendo

extraída da API Google Maps. As linhas entre 23 e 35 compreendem a criação de

uma camada (com o nome “Estabelecimento”) para captura dos dados da tabela

“estabelecimentos”, sendo esta responsável por estabelecer a conexão com o

serviço WFS. Por fim, na linha 37 a camada do Google Maps é adicionada ao mapa

e consecutivamente é adicionada a camada “Estabelecimento” que sobrepõe a

primeira.

http://code.google.com/intl/pt-BR/apis/maps/signup.html

80

Figura 36 - Trecho de código para criação do mapa, camada base, principais controles e conexão com o serviço WFS.

Ao executar o código demonstrado na Figura 36, tem-se como resultado uma

interface semelhante à observada na Figura 37. Esta interface apresenta livremente

todos os dados geográficos, que foram registrados na tabela estabelecimentos, no

mapa em forma de polígonos. Além disso, os recursos do OpenLayers permite a

inclusão, alteração e exclusão de dados geográficos.

Figura 37 - Interface implementada com OpenLayers para manipular dados adquiridos da camada de informações do GeoServer.

81

Para complementar o processamento geográfico, e principalmente nas

questões de análises topológicas, tendo em vista que o OpenLayers não faz nenhum

tipo de verificação espacial dos dados obtidos do banco de dados através do serviço

WFS, foram implementadas validações geográficas, garantindo maior integridade

dos dados geográficos inseridos no banco de dados e garantindo os seguintes

requisitos geográficos, extraídos do levantamento de requisitos para a

implementação do módulo:

a) Mais de 50% da área de uma gleba deve estar dentro da área do

estabelecimento;

b) No máximo 1/3 da extensão espacial de uma gleba deve ocupar a área de

outra.

Para implementar esta funcionalidade são utilizados recursos de requisições

assíncronas (os mesmos utilizados na implementação dos formulários para

manutenção dos dados convencionais), onde os dados geográficos são enviados no

formato WKT para o arquivo “geo_sistema.php”.

Neste arquivo, foram utilizadas as seguintes funções do PostGIS para

executar de forma eficiente as validações topológicas:

a) st_area(<geometry>): Captura a área de uma geometria;

b) st_contains(<geometry>, <geometry>): Verifica se uma geometria está

contida em outra;

c) GeometryFromText(<geometry>, [<srid>]): Permite construir uma geometria

e adaptá-la ao SRID definido como parâmetro;

d) st_intersects(<geometry>, <geometry>): Verifica se uma geometria

intercepta espacialmente outra;

e) st_intersection(<geometry>, <geometry>): Retorna uma geometria

resultante do teste de duas geometrias que interceptam;

f) st_transform(<geometry>, <srid>): Transforma determinada geometria,

adaptando ao SRID definido como parâmetro.

82

As instruções lógicas responsáveis por executar esta validação em sua

versão completa, estão disponíveis no APÊNDICE D – VALIDAÇÃO TOPOLÓGICA

DE GLEBAS.

Visando fornecer maior flexibilidade e precisão na inserção de dados

geográficos, foi implementada uma funcionalidade que permite a entrada de dados

por meio de coordenadas geográficas. Além de permitir o desenho de polígonos por

dados de latitude e longitude, é possível selecionar 1 (um) dentre 3.162 (três mil

cento e sessenta e dois) sistemas de referência disponíveis no PostGIS. Ao ativar

esta função, o sistema apresenta uma janela conforme visualizada na Figura 38.

Figura 38 - Janela para criar geometria por meio de coordenadas geográficas.

Dessa forma, conforme observado na Figura 38, o usuário deve preencher os

campos e adicionar a coordenada. Ao fazer isso as coordenadas são convertidas,

apresentadas na região “Coordenadas registradas” na janela e armazenadas

internamente em um vetor.

O processamento principal desta funcionalidade consiste em transformar os

dados do formato “Graus-Minutos-Segundos” para o formato “Graus Decimais”.

Dessa forma, por exemplo, os dados “22° 54.361'S 47° 3.634'W” são transformados

para “lat -22.906014, lon -47.060571”, estando este último pronto para ser

processado na aplicação. A Figura 39 apresenta um trecho do código responsável

por capturar os dados e executar o cálculo de coordenadas.

83

Figura 39 - Trecho de código para captura e cálculo de coordenadas geográficas.

Para que a geometria seja desenhada sobre o mapa é necessário escolher o

sistema de referência ao qual a geometria será associada. Para isso o usuário deve

ativar o botão “Sistema de Referência...” (Figura 38) e então, o sistema apresenta

outra janela, conforme observado na Figura 40.

Figura 40 - Janela para seleção de um sistema de referência espacial.

84

A janela de sistemas de referência (Figura 40) permite que o usuário realize

dois tipos de busca. No primeiro caso, sendo por SRID, é geralmente utilizado

quando o usuário já possui uma noção de SIG WEB, já no segundo caso, tendo os

conhecimentos de geografia básica, por meio de palavras-chave o usuário poderá

executar buscas pelo sistema de referência mais adequado para si. Após executar

os procedimentos até então descritos e gerar a geometria (para representar um

estabelecimento ou gleba), o sistema é responsável por desenhar automaticamente,

focando o mapa sobre o resultado, conforme observado na Figura 41.

Figura 41 - Exemplo de geometria adicionado por coordenadas geográficas para representação geográfica de um estabelecimento.

Vale ressaltar que toda esta implementação para o gerenciamento de dados

geográficos, foi aplicada em todas as interfaces para cadastro e alteração de dados

relacionados à estabelecimentos e glebas. Também é importante lembrar que o

módulo foi desenvolvido, mas não integrado com o sistema DRIS, por isso, o escopo

deste trabalho envolve apenas a arquitetura do módulo SIG WEB.

Tendo finalizado o processo de implementação, o módulo foi submetido à

testes de software (próxima seção), com o objetivo de torná-lo mais confiável e

eficiente no processamento de dados.

85

5.8 TESTES

Conforme especificado pela Engenharia de Software, os testes são

executados com o objetivo de assegurar o bom funcionamento e desempenho de

um produto de software, além de garantir a execução correta de suas funções mais

específicas. Tendo esta idéia como principal fundamento, deu-se início às atividades

de teste do módulo, lembrando que os testes foram conduzidos com o intuito de

validar o módulo individualmente.

No início da fase de testes foi realizada uma revisão de código, sendo

observadas principalmente as funções específicas que desempenham os papéis

mais importantes no módulo.

Em seguida, obedecendo aos procedimentos descritos na seção 3.4, o

módulo foi submetido a testes de unidade, dando importância principalmente no

teste de fluxo através da interface, ao ser verificado atenciosamente o fluxo de

entrada e saída de dados. Também foram testadas as estruturas de condições e os

caminhos responsáveis pela manipulação de erros.

A estrutura lógica de dados locais, globais e funções específicas julgadas

como importantes para o funcionamento do módulo foram testadas utilizando a

impressão na tela do navegador, por meio da função alert() do JavaScript além de

serem utilizadas de forma constante as ferramentas Firebug 1.7.3, instalada junto ao

navegador Mozilla Firefox, e o gerenciador para desenvolvedores, integrado ao

navegador Google Chrome. Ambas as ferramentas possuem as mesmas

funcionalidades, permitindo a manipulação em tempo real do HTML e JavaScript.

Por meio de um exemplo, a Figura 42, mostra a forma que os testes foram

executados utilizando as ferramentas integradas com os navegadores web.

86

Figura 42 - Execução de testes utilizando a ferramenta para desenvolvedores integrada ao navegador Google Chrome.

Conforme observado na Figura 42, são fornecidos os dados de entrada pela

interface e depois é executada a ação responsável por armazenar os dados em um

vetor (dados_completos) criado na linguagem JavaScript. Em seguida, utilizando a

ferramenta do Google Chrome é executada a função alert(dados_completos.length)

para verificar se os dados realmente foram armazenados.

O módulo também foi testado nos diferentes navegadores web, sendo eles o

Mozilla Firefox versão 3.6.26, Google Chrome versão 16 e internet Explorer versão

8. Portanto, constatando normalidade no funcionamento, foi garantido a

compatibilidade com estes principais navegadores.

Tendo os procedimentos apresentados acima como argumento, afirma-se

com segurança que o módulo está apto a executar corretamente as funções a qual é

destinado.

5.9 RESULTADOS OBTIDOS

Após ter aplicado os procedimentos de testes, foram verificados os resultados

produzidos durante a fase de implementação, levando em conta principalmente os

objetivos deste trabalho.

Para a parte de gerenciamento de dados convencionais foram produzidas 6

(seis) interfaces, conforme listadas a seguir:

a) Listagem de estabelecimentos;

87

b) Listagem de glebas;

c) Cadastro de estabelecimentos;

d) Alteração de estabelecimentos;

e) Cadastro de glebas;

f) Alteração de glebas.

Quanto à parte de gerenciamento de dados geográficos, foram produzidas 4

(quatro) interfaces, conforme listadas a seguir:

a) Cadastro de dados geográficos para estabelecimentos;

b) Cadastro de dados geográficos para glebas;

c) Alteração de dados geográficos para estabelecimentos;

d) Alteração de dados geográficos para glebas.

Ao concluir a implementação do módulo, observou-se que o conjunto de

interfaces para gerenciamento dos dados convencionais mostrou-se sendo suficiente

para que os usuários do sistema DRIS possam executar de forma organizada e

eficiente a manutenção das informações relacionadas às áreas de estabelecimentos

e glebas. As 4 interfaces produzidas para o gerenciamento espacial das

informações, também mostrou-se eficiente em seu funcionamento, principalmente na

questão de interação com os usuários e organização das funcionalidades para o

tratamento geográfico das informações.

Ao total foram produzidos 24 arquivos de código-fonte subdividindo em 18

codificados nas linguagens PHP junto com HTML e JavaScript e 5 codificados em

CSS somando um total com mais de 5.000 (cinco mil) linhas de código-fonte.

Uma das características o módulo desenvolvido é sua flexibilidade, visto que

conforme a necessidade dos usuários do sistema DRIS, podem ser incluídas

diversas funcionalidades sobre ele. Exemplos importantes são apresentados na

seção 6.2 (Recomendações) como a implementação de funcionalidade que permita

a inclusão de informações nutricionais de culturas diretamente na interface espacial,

sobre a geometria que representa a gleba a qual a cultura está sendo cultivada,

fornecendo maior apoio no processo de avaliação nutricional das plantas.

Após a demonstração dos principais resultados obtidos com o

desenvolvimento deste trabalho, foi constatado o alcance de todos os objetivos

propostos, apresentando de forma satisfatória os resultados esperados.

6 CONSIDERAÇÕES FINAIS E RECOMENDAÇÕES

6.1 CONSIDERAÇÕES FINAIS

Para a produção deste trabalho, foram aplicados conhecimentos teóricos e

experiências práticas adquiridas durante a graduação no curso bacharelado em

Sistemas de Informação. Em seu decorrer, foram estudados os conhecimentos

relacionados à Engenharia de Software, que visa o desenvolvimento de produtos de

software confiáveis e eficientes; as tecnologias para desenvolvimento web, utilizadas

na implementação do estudo de caso e por fim e sendo mais importante, foram

estudados os principais conhecimentos relacionados aos SIG’s, tendo ênfase neste

tipo de tecnologia voltada para o ambiente web.

Dentro do ramo de SIG, destacam-se os conhecimentos gerais abrangendo

desde seu histórico, SIG’s voltado para o ambiente web, Banco de Dados

Geográficos, servidores de aplicações SIG WEB, e recursos disponibilizados pela

biblioteca OpenLayers para implementação deste tipo de software.

Quanto às atividades que foram realizadas, destacam-se o levantamento de

requisitos e modelagem, configuração do banco de dados geográfico, instalação e

configuração do servidor de mapas (GeoServer), prototipação, implementação e por

fim a execução de testes.

89

Durante o desenvolvimento do trabalho, foram encontradas diversas

dificuldades, destacando-se como principal a escassez de trabalhos científicos e

referências semelhantes, dificultando o processo de escrita. Na parte de codificação,

a maior dificuldade encontrada foi a utilização do OpenLayers, tendo em vista que é

um projeto novo que ainda está em processo de desenvolvimento, além da sua

documentação ser incompleta.

Como embasamento fundamental para a elaboração deste trabalho, foram

utilizadas diversas fontes de referências bibliográficas, destacando-se como

principais: (CÂMARA, 2003; CASANOVA et al., 2011; BARRIGUINHA, 2008;

RAMOS, 2009; RAMSEY, 2012; KUNIYOSHI et al., 2009; BOOCH et al., 2006;

PRESSMAN, 2006; SOMMERVILLE, 2007; CONVERSE & PARK, 2003).

Quanto às contribuições adquiridas com a produção deste trabalho,

destacam-se o apoio ao sistema DRIS, tendo em vista sua ampliação ao

providenciar o módulo para tratamento geográfico dos dados, repercutindo

diretamente na eficiência da avaliação nutricional de lavouras, manipulada por este

sistema. Este estudo também proporcionou a ampliação dos conhecimentos

técnicos, acadêmicos e científicos que envolvem o desenvolvimento de um SIG

WEB, destacando a importância deste tipo de tecnologia computacional para a

sociedade, ao permitir a solução de diversos problemas que envolvem o estudo de

fenômenos que ocorrem na superfície terrestre.

Por fim, levando em consideração os conhecimentos estudados, as

tecnologias, metodologias e técnicas aplicadas na prática, o cumprimento dos

objetivos bem como os benefícios adquiridos com o resultado, pode-se afirmar que

este trabalho foi concluído com êxito.

6.2 RECOMENDAÇÕES

Como forma de dar continuidade neste estudo e ampliar os principais

conhecimentos aqui explorados apresenta-se as seguintes sugestões para futuros

trabalhos científicos:

90

a) Integração do módulo com o sistema DRIS e implantação, de forma que

este possa funcionar corretamente em um ambiente de trabalho real;

b) Implementar outras formas de entrada de dados para a demarcação

geométrica de propriedades rurais e glebas, como exemplo, os dados

adquiridos por meio da conexão com um GPS, do acervo publicado no

serviço web geográfico do INCRA ou de outros WebServices;

c) Ampliar o módulo, para permitir a saída de dados em forma de relatórios

com informações geográficas;

d) Implementar funcionalidade para permitir que os dados nutricionais de

lavouras sejam inseridos diretamente pela interface espacial, ou seja,

sobre a geometria que representa a gleba a qual a cultura está sendo

cultivada, e através dela realizar diversas consultas e análises que

envolvem o posicionamento geográfico;

e) Implementar opção para utilização das camadas base de mapas providas

pela Microsoft (http://www.bing.com/maps/) e Yahoo

(http://maps.yahoo.com/), permitindo que os usuários tenham mais

opções para visualização do mapa base da aplicação;

f) Realizar avaliações do módulo SIG WEB por meio de usuários do sistema

DRIS.

REFERÊNCIAS

ARAGÃO, H. G. SIGWEB BUILDER: uma ferramenta para desenvolvimento de

sig web em ambientes livres e gratuitos. 2009. 133f. Dissertação (Mestrado

Profissional em Sistemas e Computação) - Universidade de Salvador, Salvador.

2009.

AZEVEDO, V. H. M. et. al. Interoperabilidade entre Objetos Geográficos

Heterogêneos. Geoinfo 2006, VIII Simpósio Brasileiro de Geoinformática, Campos

do Jordão, São Paulo, 2006.

BARRIGUINHA, A. F. Uma ferramenta WebGIS de apoio na consultadoria e

gestão agro-florestal. 2008. 88f. Dissertação (Mestrado em Ciência e Sistemas de

Informação Geográfica) - Instituto Superior de Estatística e Gestão de Informação da

Universidade Nova de Lisboa, Lisboa. 2008.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. 2

ed. Rio de Janeiro: Elsevier, 2006.

BRITO, C. Efeitos da fragmentação florestal sobre a estrutura e a dieta das

assembléias de peixes em igarapés de baixa ordem da amazônia sul-ocidental.

2009. 114f. Dissertação (Mestrado em Ecologia e Manejo de Recursos Naturais) -

Universidade Federal do Acre, Rio Branco. 2009.

CABRAL, I. P. de S. Novas Ferramentas para Monitoramento Ambiental Usando

SIG web. 2008. 115f. Tese (Doutorado em Engenharia Elétrica) – Centro de

Tecnologia, Universidade Federal do Rio Grande do Norte, Natal. 2008.

CÂMARA, G.; MONTEIRO, A. M.; DAVIS, C. Introdução à Ciência da

Geoinformação. São José dos Campos: INPE, 2003.

92

CASANOVA, M.; CÂMARA, G.; DAVIS, C.; VINHAS, L.; QUEIROZ, G. R. de.

Bancos de Dados Geográficos. MundoGeo, 2005. 506 p. Disponível em:

<http://www.dpi.inpe.br/livros/bdados/>. Acesso em: 30 dez. 2011.

CASTLEDINE, E.; SHARKIE, C. jQuery: Novice to Ninja. SitePoint Pty. Ltd., 2010.

CONVERSE, Tim; PARK, Joyce. PHP: a Bíblia. Rio de Janeiro: Elsevier, 2003.

COSTA, Carlos J. Desenvolvimento para web. Lisboa: Lusocrédito, 2007.

COSTA, Felipe dos S. Sopa de Letras Geográficas. FOSSGIS. ano 1, n. 1, p. 13-

18, março 2011.

DRUCK, S.; CARVALHO, M.S.; CÂMARA, G.; MONTEIRO, A.V.M. (eds). Análise

Espacial de Dados Geográficos. Brasília: EMBRAPA, 2004 (ISBN: 85-7383-260-6).

FLANAGAN, David. JavaScript o guia definitivo. 4 ed. São Paulo: BOOKMAN

COMPANHIA EDITORA (ARTMED EDITORA S. A.), 2002.

GEOSERVER. Disponível em: <http://geoserver.org/display/GEOS/Welcome>.

Acesso em: 03 jan. 2012.

GEOSERVER. Web Feature Service. Disponível em:

<http://docs.geoserver.org/stable/en/user/services/WFS/index.html>. Acesso em: 28

dez. 2011.

GOMES, Ana Laura. XHTML/CSS: Criação de páginas web. São Paulo: Senac,

2010.

GOODMAN, Danny. JavaScript: a Bíblia. Rio de Janeiro: Elsevier, 2001.

GOOGLE. Sign Up for the Google Maps API. Disponível em: <

http://code.google.com/intl/pt-BR/apis/maps/signup.html>. Acesso em: 08 jan. 2012.

GUTTOSKI, Pryscila Barvick. Otimização de consultas no PostgreSQL utilizando

o algoritmo kruskal. Curitiba: UFPR. Dissertação (Mestrado no Programa de Pós-

Graduação em Informática), 2006.

HIROMI, Renata; MIYAGUSKU, Minami. Crie Sites Arrasadores – flash, dhtml,

css, html, dreamweaver, javascript. São Paulo: Digerati Books, 2007.

IBGE. Sistemas de Referência. Disponível

em:<ftp://geoftp.ibge.gov.br/documentos/geodesia/sisref_2.pdf>. Acesso em: 05 jan.

2012.

93

KIMO, Y. J. Um Cliente WMS para Dispositivos Móveis. 2009. 70f. Dissertação

(Mestrado em Informática) – Pontifícia Universidade Católica de Minas Gerais, Belo

Horizonte. 2009.

KUNIYOSHI, M. A.; GRISI, B. U.; NOGUEIRA, M. Sistemas de Informação Para a Tomada de Decisão em Agricultura de Alta Precisão. São Paulo: Escola

Politécnica da Universidade de São Paulo. Trabalho de Conclusão de Curso (Engenharia da Computação). 2009.

MANZANO, J. A. N. G. PostgreSQL 8.3.0 Interativo: Guia de Orientação e

Desenvolvimento. São Paulo: Érica, 2008.

MAPSERVER. Open source web mapping. Disponível em: <http://mapserver.org/>.

Acesso em: 03 jan. 2012.

MCLAUGHLIN, Brett. Use a Cabeça! (Head Rush) Ajax. Alta Books, 2006. ISBN

8576081253.

MELO, A. C. Desenvolvendo aplicações com UML 2.2: Do conceitual à

implementação. 3 ed. Rio de Janeiro: Brasport, 2010.

MEYER, ERIC A. CSS: The Definitive Guide. 3 ed. O’reilly: Sebastopol. 2006.

MILANI, André. PostgreSQL: GUIA DO PROGRAMADOR. São Paulo: Novatec,

2008.

MORAZ, Eduardo. Treinamento prático em php. São Paulo: Digerati Books, 2005.

NETO, W. P. S. Usando API do Google Maps para criar um mapa interativo.

Estudo de Caso: Campus-Viçosa. 2009. 48f. Monografia apresentada como parte

das exigências da disciplina EAM 498, Curso de Graduação de Engenharia

Agrimensura, Universidade Federal de Viçosa. 2009.

NIEDERAUER, Juliano. Web interativa com Ajax e PHP. São Paulo: Novatec,

2007.

OPENLAYERS. Free Maps for the Web. Disponível em: <http://openlayers.org/>.

Acesso em: 28 dez. 2011.

OSGEO. The Open Source Geospatial Foundation… . Disponível em:

<http://www.osgeo.org/>. Acesso em: 20 jan. 2012.

PFAFFENBERGER, B.; SCHAFER, S. M.; WHITE, C.; KAROW, B. HTML, XHTML,

and CSS Bible. 3 ed. Indianapolis: Wiley, 2004.

POSTGIS. OSGeo Project. Disponível em: < http://postgis.refractions.net/ >. Acesso

em: 28 dez. 2011.

94

PREECE, J; Rogers, Y; Sharp, H. Design de interação: Além da interação

homem-computador. Porto Alegre: Bookman, 2002.

PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo: McGraw-Hill, 2006.

RAMOS, André M. M. da S. Diegues. Disponibilização da informação geográfica

na administração da região hidrográfica do Alentejo usando Webservices: WFS

sobre geoserver. Lisboa: Instituto Superior de Estatística e Gestão de Informação

da Universidade Nova de Lisboa. Dissertação (Mestrado em Ciência e Sistemas de

Informação Geográfica), 2009.

RAMSEY, Paul. Manual do PostGIS. Disponível em:

<http://www.Webgis.com.br/postgis/index.html>. Acesso em: 05 jan. 2012.

RAO, Rajnikant. AJAX: Conversations with an Ajaxian. New Delhi: Tata McGraw-

Hill, 2008.

SCHIMIGUEL, Juliano; BARANAUSKAS, M. Cecília C.; MEDEIROS, Cláudia

Bauzer. Usabilidade de aplicação SIG WEB na perspectiva do usuário: um

estudo de caso. IP Informática pública. Belo Horizonte, ano 8, n. 1, p. 07 – 22,

Março 2006.

SILVA, E. C. P.; JÚNIOR, O. R. C.; SANTOS, R. de C. M. dos; WADT, P. G. S.

Introdução ao desenvolvimento de um módulo WebGIS para monitoramento

nutricional de lavouras. In: ERIN 3, 2011, Rio Branco. Anais... . Rio Branco, 2011.

SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração de Dissertação. 3.ed. Florianópolis: Laboratório de ensino a Distância

da UFSC, 2001.

SILVA, Maurício Samy. jQuery A Biblioteca do Programador JavaScript. São Paulo: Novatec, 2008.

SOMERA, Guilherme. Treinamento básico em CSS. São Paulo: Digerati Books, 2006.

SOMMERVILLE, Ian. Engenharia de Software. 8 ed. Pearson: São Paulo, 2007.

UCHOA, H.N.; FERREIRA, P. R. Geoprocessamento com Software Livre. V 1.0.

Rio de Janeiro : www.geolivre.org.br, 2004.

VIVAS, Maurício. Iniciando no PHP: Introdução ao PHP. HTML Staff, 2006. disponível em: <http://www.htmlstaff.org/ver.php?id=1783>. Acesso em 09/07/2011.

APÊNDICES

APÊNDICE A – CENÁRIO DE USO DO MÓDULO

Para fazer um estudo sobre a nutrição das lavouras é necessário executar um

passo importante no sistema, que consiste em cadastrar análises foliares. Para o

cadastro de análise foliar é preciso antes ter os registros cadastrados de

estabelecimento, onde a amostragem foi feita, o local ou gleba de coleta e

finalmente a safra, sendo necessário seguir esta ordem.

O módulo abrange as informações de propriedades rurais (ou

estabelecimentos) e glebas. Com a integração do módulo ao sistema DRIS, este

deve disponibilizar um link para redirecionar o usuário à interface principal do

módulo.

A interface principal do módulo deve disponibilizar uma listagem de todas as

propriedades rurais cadastradas pelo usuário que está logado no sistema. Esta

listagem deve apresentar links para alteração dos dados convencionais, exclusão do

registro e a manipulação dos dados geográficos (mapas).

Da mesma forma que a listagem de propriedades rurais, a seleção de um dos

registros deve disponibilizar uma listagem com as glebas que estão associadas,

apresentando links para alteração dos dados convencionais, exclusão do registro e a

manipulação dos dados geográficos.

A simulação do cadastro de um estabelecimento com uma gleba e os

respectivos dados geográficos deve ocorrer da seguinte maneira:

“Na interface principal do sistema, o usuário deve ir em “Cadastrar estabelecimento”,

sendo redirecionado para o formulário de cadastro. Após cadastrar ele deve retornar

na interface principal (listagem de estabelecimentos) e ir em “Registrar Mapa”, sendo

redirecionado para uma interface que permite o desenho de um polígono sobre o

mapa físico do Google Maps para ser associado com o estabelecimento que foi

anteriormente cadastrado e depois selecionado. Depois, o usuário deve salvar e

retornar à interface principal, buscando as glebas do mesmo estabelecimento e

ativando o cadastro de uma nova gleba. Após fazer o cadastro no formulário, deve ir

em “Registrar Mapa”, sendo redirecionado para a interface de mapas, onde o

sistema estabelece o foco do mapa no polígono que representa o estabelecimento

ao qual pertence a gleba que foi selecionada. Após salvar este procedimento é

finalizado.”

APÊNDICE B – DOCUMENTO DE REQUISITOS DO MÓDULO

1 Introdução

O documento de requisitos é uma forma de definir oficialmente os requisitos

de um sistema para os clientes, usuários finais, desenvolvedores do software e

gerente de projeto.

Um dos objetivos principais deste documento é a definição formal das

características, restrições e funcionalidades que o sistema deve prover, servindo de

contrato entre o cliente e o gerente de projeto ou desenvolvedores, visto que outras

opções não-formais não são eficientes, além de poder causar um desentendimento

entre os envolvidos com o projeto.

Por ser um documento simplificado, este mostra apenas os principais fatores

que constituem um projeto de software sendo os requisitos funcionais, não-

funcionais e os requisitos mínimos de hardware e software para que se tenha um

bom funcionamento.

Os requisitos funcionais descrevem as funções que o sistema deve executar,

os requisitos não-funcionais definem restrições externas as quais o produto de

software deve atender, já os requisitos de hardware e software delimitam tais

características para se ter o funcionamento adequado do sistema ao ser implantado.

Dessa forma, estes tipos de requisitos para o módulo espacial para o sistema DRIS

são descritos a seguir.

2 Requisitos Funcionais

ID Requisito Descrição Caso de uso

[RF01] Manter dados

convencionais de estabelecimentos


registros de estabelecimentos.

Manter estabelecimentos.

[RF02] Manter dados

convencionais de glebas


registros de glebas. Manter glebas.


estabelecimentos

Permitir a inclusão e alteração de mapas

(polígonos) relacionados aos estabelecimentos

cadastrados.

Gerenciar geoinformação de estabelecimentos.


glebas

Permitir a inclusão e alteração de mapas

(polígonos) relacionados às glebas cadastradas

Gerenciar geoinformação de

glebas.

100

3 Requisitos Não-Funcionais

ID Descrição

[RNF01] Interface web: O sistema deve funcionar em ambiente web através dos navegadores Mozilla Firefox, Google Chrome e internet Explorer.

[RNF02]

Perfil dos usuários: Para que o sistema seja acessado e utilizado

de forma satisfatória, os usuários devem ter experiência no uso de aplicativos web, conhecimento básico em agricultura e noção intermediária em geografia.

4 Requisitos de hardware e software: Configurações mínimas

a) Sistema Operacional: Windows 7, 32 bits;

b) Processador: Pentium III 1GHz;

c) Memória: 1Gb;

d) Espaço Livre no Disco Rígido: 3Gb.

APÊNDICE C – INSTALAÇÃO E CONFIGURAÇÃO DO GEOSERVER

O processo de instalação é simples, por ser conduzido por meio de janelas do

assistente de configuração. Como pré-requisitos, é necessário apenas ter instalado

na máquina o pacote JDK (Java Development Kit) e o JRE (Java Runtime

Envoronment), observado na Figura 1.

Figura 1 - Solicitação do diretório onde o JDK está instalado.

Durante a instalação também se deve ter atenção na inserção de usuário e

senha, que são os dados necessários para acessar o sistema (Figura 2). O restante

dos passos percorridos até o final da instalação não necessitam de alterações.

Figura 2 - Solicitação de usuário e senha durante a instalação do GeoServer.

103

Para começar a utilizar esta ferramenta, que funciona através de uma

interface web deve ser inicializado seu serviço, que pode ser feito no mesmo

diretório em que foi instalado. A Figura 3 mostra a tela principal da ferramenta, que é

visualizada após fazer o login do usuário.

Figura 3 - Tela principal do servidor de mapas GeoServer.

Para dar início à configuração, na tela principal do sistema, o usuário deve

verificar no menu esquerdo a região “Data”, e clicar no link “Wokspaces”, onde o

sistema apresenta no corpo da página uma lista de workspaces que de forma

padrão vêm acompanhados com a instalação da ferramenta. Deve então ser criado,

clicando sobre o link “Add new workspace”, um novo workspace para agrupar e

identificar o serviço a ser disponibilizado pelo GeoServer. Conforme observado na

Figura 4, são preenchidos os campos “Name: dris” e “Namespace URI:

http://localhost:8080/dris”. Como forma de organização, o campo “Namespace URI”

é preenchido seguindo o padrão: http://<host> : <número da porta utilizada> / <nome

do workspace>, lembrando que o valor inserido neste campo é utilizado para

identificar os serviços disponibilizados pelo GeoServer a serem usufruídos por

outras aplicações geográficas.

104

Figura 4 - Cadastramento de um workspace para identificar os serviços disponibilizados pelo GeoServer a uma determinada aplicação.

Voltando ao menu esquerdo, o usuário deve clicar sobre o link “Store” que

fica logo abaixo do link “Workspace” e depois clicar sobre “Add new store”, onde

será apresentado uma tela conforme visualizado na Figura 5. Como este trabalho

está baseado no banco de dados PostgreSQL com a extensão espacial PostGIS, é

então selecionado o link “PostGIS” na área “Vector Data Resources”. Conforme pode

ser observado, o GeoServer oferece opções para trabalhar com diversos formatos

de dados, incluindo desde recursos baseados em banco de dados até arquivos do

tipo Shapefile e imagens GeoTIFF.

Figura 5 - Fontes de dados suportados pelo GeoServer.

105

Após seguir o procedimento descrito acima, por meio de um formulário o

sistema solicita informações para a conexão com o banco de dados, demonstrado

na Figura 6, destacando-se com principais: o nome do wokspace (mencionado no

parágrafo anterior), o tipo de banco de dados (PostGIS), host (máquina local), porta

utilizada pelo PostgreSQL, nome do banco de dados (dris) e por fim usuário e senha

que é utilizado para acessar o SGBD PostgreSQL.

Figura 6 - Informações do banco de dados para conexão com o GeoServer.

Depois de preenchidos corretamente os dados obrigatórios e salvo as

configurações, o sistema apresenta todas as tabelas do banco de dados que foi

informado. Cabe ao usuário escolher as que possuem campos geométricos e clicar

sobre o link “Publish”, sendo neste caso as tabelas “estabelecimentos” e “glebas”

conforme mostrado na Figura 7.

106

Figura 7 - Lista de tabelas recuperadas pelo GeoServer para que o usuário possa selecionar quais são fontes de dados geográficos.

Ao selecionar uma das tabelas, o sistema então apresenta a tela de

configuração das tabelas a serem disponibilizadas como layer (camada de dados

geográficos) pelo serviço WFS (seção 2.5.2). Nesta tela, as únicas ações a serem

feitas são a obtenção do Bounding Box (retângulo envolvente), que busca todos os

registros de dados geográficos no banco de dados e delimita uma área maior em

forma de retângulo, envolvendo todos os dados encontrados. Caso não tenha

nenhum registro com tais informações, o sistema estabelece o menor retângulo

possível, obtido do centro do mapa. Para isso o usuário deve clicar sobre os links

conforme marcados na Figura 8.

107

Figura 8 - Configuração de layer para publicação dos dados geográficos armazenados nas tabelas.

Depois de ter aplicado este procedimento para as tabelas “estabelecimentos”

e “glebas”, o servidor GeoServer estará apto a distribuir e receber os dados dessas

tabelas no padrão GML, por meio do serviço WFS (seção 2.5.2).

APÊNDICE D – VALIDAÇÃO TOPOLÓGICA DE GLEBAS

//Receber os dados da requisição $codEstabelecimento = $_POST["codEstabel"]; $codglebas = $_POST["idGleba"]; $feicaoGleba = $_POST["feicao"]; $validacao = 0; //Obter a área total da gleba $qryAreaGleba = pg_query("SELECT st_area(st_transform(GeometryFromText('".$feicaoGleba."',4326),3005))/10000 as area_gleba"); $areaGleba = pg_fetch_result($qryAreaGleba,0,"area_gleba"); //1º Verificar se a geometria da gleba a ser cadastrada esta sobre a geometria do estabelecimento (st_contains e st_intersects) $qryContains = pg_query("SELECT st_contains(estabelecimento_geom,GeometryFromText('".$feicaoGleba."',4326)) AS contem FROM estabelecimentos WHERE codestabelecimento=$codEstabelecimento"); $qryIntersects = pg_query("SELECT st_intersects(estabelecimento_geom,GeometryFromText('".$feicaoGleba."',4326)) AS intercept FROM estabelecimentos WHERE codestabelecimento=$codEstabelecimento"); $contemGleba = pg_fetch_result($qryContains,0,"contem"); $interceptGleba = pg_fetch_result($qryIntersects,0,"intercept"); if( ($contemGleba==false) && ($interceptGleba==false) ) { $validacao = 1; } //2º Verificar se a área de interseção sobre o estabelecimento é menor que 50% da área da gleba $qryAreaIntercept = pg_query("SELECT st_area(st_intersection(st_transform(estabelecimento_geom,3005),st_transform(GeometryFromText('".$feicaoGleba."',4326),3005)))/10000 AS area_intercept FROM estabelecimentos WHERE codestabelecimento=$codEstabelecimento"); //Área de interceção entre a gleba e o estabelecimento $areaIntercepta = pg_fetch_result($qryAreaIntercept,0,"area_intercept"); if($areaIntercepta <= $areaGleba/2) { $validacao = 2; } //3º Verificar quais glebas interceptam com a gleba selecionada e verificar se a área de interseção com cada uma é maior que 1/3 da área da gleba

110

//3.1 Selecionar os registros de todas as glebas que interceptam esta $qryGlebasIntercept = pg_query("SELECT * FROM glebas WHERE st_intersects(gleba_geom,GeometryFromText('".$feicaoGleba."',4326)) AND codglebas != $codglebas"); //Verificar se retorna algo if(pg_num_rows($qryGlebasIntercept) > 0) { //Se retornar, ele vai fazer comparações com as áreas de cada gleba que faz interseção com a que foi selecionada

while($dadosCodGlebas = pg_fetch_array($qryGlebasIntercept)) {

//Obter o código para fazer as seleções $codGlebasInter = $dadosCodGlebas["codglebas"];

$qryInterGleba = pg_query("SELECT st_area(st_intersection(st_transform(gleba_geom,3005),st_transform(GeometryFromText('".$feicaoGleba."',4326),3005)))/10000 AS area_interse FROM glebas WHERE codglebas=$codGlebasInter");

$areaInterse = pg_fetch_result($qryInterGleba,0,"area_interse");

//Se a área de interseção for maior que 1/3 (um terço) da área total da gleba

if($areaInterse > $areaGleba/3) { $validacao = 3; } } } //Na interface o código javascript verifica os números retornados. //Caso seja 1 ou 2, avisa que a gleba está sendo cadastrada fora do estabelecimento de origem //Caso seja 3, avisa que a gleba está sendo cadastrada sobre outras glebas echo $validacao;

ANEXOS

ANEXO A – UTILIZAÇÃO DO SISTEMA DRIS

Autor: PAULO G S WADT ([email protected])

O objetivo deste documento é apresentar alguns recursos básicos do sistema DRIS, em suas duas versões: VERSÃO estável – disponibilizada no sítio www.dris.com.br. VERSÃO treinamento/testes, disponibilizada no sítio www.dris.com.br/eti. Observações importantes:

O uso da versão estável está sujeita as restrições impostas pelo TERMO DE USO. A utilização inadequada poderá resultar em impedimento do acesso ao usuário ao sistema.

O banco de dados da versão de treinamento/testes não preserva os dados

utilizados. Somente o DRIS hospedado no sitio www.dris.com.br preserva os dados dos usuários.

- Neste documento não são apresentadas as bases teóricas ou implicações práticas sobre as metodologias disponíveis no software, apresentando apenas o passo-a-passo de parte dos recursos disponíveis. Como acessar:

Para acessar a versão de treinamento/testes, digite na barra de ferramentas de seu navegador o endereço www.dris.com.br/eti/ (é importante incluir a subpasta /eti - veja figura a seguir).

Para acessar a última versão estável, digite www.dris.com.br.

http://www.dris.com.br/eti

114

Após, escolher no menu lateral a opção DRIS Culturas (somente propriedades e glebas já cadastradas que serão acessadas). Caso não tenha ainda feito o cadastro, é necessário ir para a opção Cadastros, do mesmo menu lateral.

Na opção DRIS Culturas, escolha a cultura de seu interesse (por exemplo, Soja), clicando no respectivo nome da cultura no menu (figura abaixo)

115

Caso ainda não esteja logado, será direcionado para a área de login. Se já estiver logado, esta etapa não existirá. Faça seu login normalmente.

116

Se o acesso for feito com sucesso, aparecerá uma tela com a cultura que está acessando (no caso, DRIS Soja) e no menu lateral aparecerá novas opções. Se isto não ocorrer, é porque houve algum erro no sistema e solicitamos que nos informe para que possamos corrigir.

117

O próximo passo será cadastrar uma análise foliar, escolhendo no menu lateral a opção Análise Foliar / Cadastrar.

118

OBSERVAÇÃO IMPORTANTE: As configurações do DRIS para cada usuário e cada cultura,somente são habilitadas após o cadastro de uma nova análise foliar. Por isto, muitos recursos estarão desabilitados até que seja feito o primeiro cadastro de uma análise foliar.

As análises foliares somente são cadastradas seguindo uma hierarquia pré-definida. Nesta hierarquia, para cadastrar uma análise foliar será necessário informar a propriedade rural onde a amostragem foi feita, o local ou gleba de coleta e, finalmente, a safra. A safra, representa um período de produção específico em determinada gleba. Assim, a cada ano, para uma mesma gleba, devem ser cadastradas novas safras.

Somente as propriedades e glebas que foram cadastradas na opção Cadastros do menu lateral serão listadas (notar que neste cadastro, estas informações de propriedade e gleba não dependem da cultura que está sendo avaliada, pois, numa mesma gleba ou propriedade podem ser cultivadas diferentes lavouras, em safras simultâneas – consórcio, ou alternadas – rotação de culturas).

119

OBSERVAÇÃO IMPORTANTE: Esta hierarquia de propriedade rural/gleba/safra é fundamental para a organização dos dados e permitir, no futuro, que o usuário obtenha normas DRIS consistentes com sua realidade.

Se para uma determinada gleba, já existir alguma safra cadastrada, poderá ser informada quantas análises foliares para a mesma safra desejar, bastando que a safra seja selecionada na opção correspondente (embora, esta não seja uma prática recomendada, permite que o usuário possa fazer a avaliação em diferentes estádios fenológicos da cultura).

A informação de cada safra poderá ainda ser editada (alterada ou atualizada), ou ser cadastrada uma nova safra para a gleba escolhida.

120

Após o cadastro da safra, devem ser preenchidos os demais campos

marcados com asterisco. Qualquer número de nutrientes (desde que superior a três) podem ser cadastrados, e o ponto decimal poderá ser informado como vírgula (,) ou ponto (.). Não deve ser usado separador de milhar. Os nutrientes não informados devem ser mantidos em branco (deixando-se os campos nulos). Somente valores numéricos são válidos (valores alfabéticos e outros caracteres podem gerar erro).

Após digitar os dados dos elementos (g/kg para macronutrientes e mg/kg para micronutrientes), deve-se optar pelo botão Cadastrar ou Cadastrar e Calcular Dris. Ambos os botões gravam a análise foliar no banco de dados, porém, o primeiro botão retornar a esta tela para mais inserções, e o segundo botão, redireciona para a página de resultados do DRIS.

121

OBSERVAÇÃO IMPORTANTE: O sistema não faz, nesta etapa, nenhuma verificação da validade dos dados digitados. Ou seja, qualquer valor digitado, mesmo que absurdo, será aceito, gravado no banco de dados e utilizado para o cálculo dos índices DRIS ou normas DRIS. A validação será feita por meio de algoritmo ainda não disponível na versão estável ou de testes.

Caso tenha optado pelo botão Cadastrar e Calcular DRIS, a análise foliar será gravada e enviada para a página de resultados. O resultado dos cálculos, já gravados no banco de dados, poderão ser visualizados na opção Gerar Relatório.

122

OBSERVAÇÃO IMPORTANTE: O sistema limita o número de diagnósticos feitos em função do número de análises foliares cadastradas, de acordo com cada plano de licenciamento. Isto é para impedir que haja sobrecarga de informações no banco de dados, comprometendo o desempenho do sistema. Normalmente, para cada análise foliar são possíveis cadastrar cinco diagnósticos. Caso o limite tenha sido alcançado, é possível excluir os diagnósticos realizados, permitindo que novos sejam feitos. Para fins práticos, somente um diagnóstico é necessário para cada análise foliar, a menos que se deseje testar outros métodos disponíveis no sistema.

Ao clicar na opção Gerar Relatório, uma nova janela irá se abrir (o navegador deve estar habilitado para permitir a abertura de novas abas). O relatório consolida, as informações do método utilizado (fórmulas, normas, critério de interpretação dos índices DRIS, nutrientes permitidos na análise, etc). O resultado será apresentado conforme o método escolhido pelo usuário.

123

OBSERVAÇÃO IMPORTANTE: O sistema, por padrão, adota uma determinada configuração, que é a considerada mais apropriada. Esta configuração pode ser configurada para que se obtenha melhor desempenho do sistema, mas deve ser feita apenas por usuários que tenham algum conhecimento básico sobre o DRIS.

O sistema, após cadastrar a primeira análise foliar, adota um conjunto de normas padrões. O usuário pode produzir suas próprias normas, aplicando uma série de condições que são específicas para cada cultura. Estas condições podem ser aplicadas sobre seus dados ou sobre todos os dados da cultura que estejam armazenados no banco de dados. Porém, somente os dados próprios que podem ser editados ou selecionados individualmente.

Caso os testes estatísticos sejam validados, será gerado um novo conjunto de normas DRIS. Porém, se o número de informações for insuficiente, não serão geradas novas normas. Recomenda-se um mínimo de 200 análises foliares para o primeiro conjunto de normas DRIS.

124

Todas as normas geradas pelo usuário são gravadas e armazenadas em banco de dados, podendo serem visualizadas em arquivo PDF, ou apagadas.

O sistema também limita o número de normas DRIS que podem ser armazenadas, em função de cada plano de licenciamento.

125

O arquivo PDF com as normas DRIS são gerados em uma nova aba do navegador (e precisam estar habilitado no navegador a abertura de novas janelas ou abas).

126

O usuário também pode configurar o método de cálculo dos índices DRIS, usando as normas no sistema ou as normas que tenham sido geradas por ele próprio (nunca terá acesso a normas geradas por outros usuários).

Além das normas DRIS, poderá escolher métodos de cálculo das fórmulas DRIS, transformação ou não dos dados por função logarítmica, a exclusão de algum nutriente do cálculo (mesmo que seu valor não seja nulo na análise foliar) e o critério de interpretação dos índices DRIS.

127

OBSERVAÇÃO IMPORTANTE: Existem no sistema outros recursos, mais complexos, não apresentados neste PASSO A PASSO. Além disto, muitos dos recursos apresentados apresentam implicações que também não estão sendo consideradas neste momento.

TCC - EIDER - DESENVOLVIMENTO DE UM MÓDULO SIG WEB PARA REPRESENTAÇÃO ESPACIAL DE PROPRIEDADES...

Documents

Transcript of TCC - EIDER - DESENVOLVIMENTO DE UM MÓDULO SIG WEB PARA REPRESENTAÇÃO ESPACIAL DE PROPRIEDADES...