UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ...
82
UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA AGRÍCOLA PLATAFORMA PARA COLETA E VISUALIZAÇÃO DE DADOS AGRÍCOLAS GEORREFERENCIADOS EM AMBIENTE WEB E MOBILE ALEXANDRO PATRIK PERGHER CASCAVEL, PR JUNHO, 2015
Transcript of UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ...
UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA AGRÍCOLA
PLATAFORMA PARA COLETA E VISUALIZAÇÃO DE DADOS AGRÍCOLAS
GEORREFERENCIADOS EM AMBIENTE WEB E MOBILE
ALEXANDRO PATRIK PERGHER
CASCAVEL, PR
JUNHO, 2015
ALEXANDRO PATRIK PERGHER
PLATAFORMA PARA COLETA E VISUALIZAÇÃO DE DADOS AGRÍCOLAS
GEORREFERENCIADOS EM AMBIENTE WEB E MOBILE
Dissertação apresentada ao Programa de Pós-Graduação em Engenharia Agrícola, em cumprimento parcial aos requisitos para a obtenção do título de Mestre em Engenharia Agrícola, área de concentração em Sistemas Biológicos e Agroindustriais. Linha de pesquisa Geoprocessamento, Estatística Espacial e Agricultura de Precisão. Orientador: Prof. Dr. Erivelto Mercante Coorientador: Prof. Dr. Marcio Antonio Vilas Boas
CASCAVEL, PR
JUNHO, 2015
Dados Internacionais de Catalogação-na-Publicação (CIP)1
P517p Pergher, Alexandro Patrik
Plataforma para coleta e visualização de dados agrícolas georreferenciados em ambiente Web e Mobile./Alexandro Patrik Pergher, revisores de texto Ana Maria Martins Alves Vasconcelos – inglês e Maricélia Nunes dos Santos – português e normas. Cascavel, 2015.
82 p.
Orientador: Prof. Dr. Erivelto Mercante Coorientador: Dr. Marcio Antonio Vilas Boas
Dissertação (Mestrado) – Universidade Estadual do Oeste do Paraná. Programa de Pós-Graduação Stricto Sensu em Engenharia Agrícola 1. Banco de dados geográfico. 2. SIG. 3. Dispositivo móvel. I. Mercante,
Erivelto. II. Vilas Boas, Marcio Antonio. III. Universidade Estadual do Oeste do Paraná. IV. Título.
CDD 21.ed. 630.205
Ficha catalográfica elaborada por Helena Soterio Bejio – CRB 9ª/965
1 Revisão de Língua Portuguesa e das Normas de Edição conforme requisitos do PGEAGRI: Profa. Ma. Maricélia Nunes dos Santos, em 18 de agosto de 2015. Revisão de Língua Inglesa: Profa. Ana Maria Martins Alves Vasconcelos, em 17 de agosto de 2015.
ii
BIOGRAFIA
Alexandro Patrik Pergher nasceu em 1986 na cidade de Toledo, PR. Tornou-se
bacharel em Sistemas de Informação, pela Faculdade Sul Brasil, em 2008, exercendo
atividades na área de desenvolvimento de sistemas desde 2004. Em 2009 iniciou carreira
docente, ministrando disciplinas de bancos de dados e algoritmos em cursos de graduação
na área de Sistemas de Informação e Redes de Computadores.
Em 2010 concluiu cursos de pós-graduação lato sensu em Gestão de Inovação
Tecnológica, pela UTFPR, e Docência no Ensino Superior, também pela Faculdade Sul
Brasil.
Atuou de 2007 a 2010 na indústria de medicamentos, construindo sistemas para
apoiar operações nesse segmento. Em 2010 migrou para a indústria alimentícia, tornando-
se consultor em gestão da tecnologia da informação no agronegócio, especialmente em
indústria de laticínios.
Em 2013, com o intuito de contribuir e reafirmar seu interesse na área acadêmica,
ingressou no Programa de Pós-Graduação em Engenharia Agrícola da UNIOESTE.
iii
DEDICATÓRIA
Dedico este trabalho aos meus alunos. Formar
pessoas é uma responsabilidade muito grande.
iv
AGRADECIMENTOS
Algumas pessoas foram fundamentais para que este trabalho pudesse ser
realizado, portanto, deixo registrados meus sinceros agradecimentos.
Agradeço ao meu orientador Erivelto Mercante. Durante o período da pós-
graduação, aprendi muitas lições que foram além das disciplinas e orientações. Com
certeza, pude aprimorar minha prática docente simplesmente observando-o.
Agradeço ao meu coorientador, Marcio AntonioVilas Boas, que sugeriu abordagens
interessantes ao trabalho, além de auxiliar no processo de registro do software.
Agradeço aos meus pais, Fatima e Adair, pelo apoio na continuação dos meus
estudos.
Agradeço a minha namorada, Aline, e sua família, pelo incentivo para que eu
realizasse a pós-graduação. Também agradeço pela ajuda na revisão do texto.
Agradeço a Suzana Wrublack por, pacientemente, repassar valiosas informações
para elaboração do projeto.
Agradeço aos demais colegas do Laboratório de Topografia e Geoprocessamento,
que sempre demonstraram disposição para ajudar.
Agradeço aos professores Adair Santa Catarina, Jerry Johann e Claudio Bazzi, que,
gentilmente, aceitaram o convite para participar da banca de defesa.
Agradeço aos demais professores do Programa de Pós-Graduação em Engenharia
Agrícola, que contribuíram positivamente em minha formação.
Agradeço aos meus amigos e colegas de trabalho, que em algum momento
sentiram minha falta, pela compreensão, necessária para que esse objetivo fosse
alcançado.
v
PLATAFORMA PARA COLETA E VISUALIZAÇÃO DE DADOS AGRÍCOLAS
GEORREFERENCIADOS EM AMBIENTE WEB E MOBILE
RESUMO: Sistemas de informação podem auxiliar na melhoria do fluxo, velocidade e
segurança de processos. No meio acadêmico, embora buscam-se sempre novas descobertas, alguns processos são estabelecidos e não sofrem severas mudanças durante o tempo. A coleta de dados para pesquisas segue determinado padrão, onde são estabelecidos os pontos de coleta, as variáveis, e procede-se a coleta com a anotação dos valores das variáveis em cada uma das amostras. Ferramentas que automatizam tal processo não são populares. Ainda, quando se tratam de dados onde o local de ocorrência é informação determinante, os sistemas disponíveis são mais escassos. Esse tipo de informação caracteriza-se por ser georreferenciada, com coordenadas conhecidas, em um sistema de referência. Portanto, as tecnologias de informação e comunicação usadas nesse estudo resultaram em um software que permite o compartilhamento e a apresentação dos
dados das pesquisas de campo, com o intuito de auxiliar os pesquisadores do Laboratório de Geoprocessamento da Universidade Estadual do Oeste do Paraná, campus Cascavel no desempenho das atividades em coletas de dados agrícolas. As pesquisas do Laboratório de Topografia e Geoprocessamento auxiliam a evolução da agricultura na região Oeste do Paraná. Assim, com o intuito de contribuir com mais avanços relevantes para o PIB brasileiro e para essa área, foram realizadas entrevistas com os pesquisadores do laboratório, análise de documentos e planilhas utilizadas na coleta de dados, criação de um modelo de dados flexível que atenda ao armazenamento de dados numéricos, alfanuméricos, temporais, lógicos e espaciais. No desenvolvimento da aplicação, foram utilizados a linguagem de programação Java 8, o banco de dados relacional PostgreSQL 9.4 e sua extensão PostGIS 2.1 bem como alguns artefatos da UML para documentação. PALAVRAS-CHAVE: banco de dados geográfico; SIG; dispositivo móveis.
vi
GEOREFERENCED DATA COLLECT PLATFORM FOR AGRICULTURE ON WEB AND
MOBILE ENVIRONMENT
ABSTRACT: Information Systems can improve workflow, speed and security of processes.
In the academic area, although new discoveries are always researchers’ purposes, some processes are established and are not submitted to severe changes throughout time. The data collection follows a given standard, where the collection points and variables are defined then the procedure is executed, recording variable values on each sample. Tools which automate this process are not popular. In cases concerning data where the occurrence place is crucial, the available systems are scarcer. This information is characterized as georeferenced structures, with known coordinates, in some reference system. So, new technologies of information and communication applied in this study resulted in a software that share and present accordingly the field research data, in order to help the Topography and Geoprocessing Lab (GeoLab) researchers of Western Paraná State University, campus,
Cascavel, in their agricultural activities. The research of Topography and Geoprocessing Lab has improved the agriculture on Western Paraná. In order to contribute for new progresses in this field, that has Brazilian GDP relevance, some interviews with researchers of GeoLab was done. Thus, aiming at contributing with more relevant breakthroughs for Brazilian GDP and for this area, interviews were conducted with researchers at the lab, examining documents and spreadsheets used for data collection, and a flexible data model was created to meet the numerical data, alphanumeric, temporal, spatial and logical storage. Thus, during the solution development, Java 8 platform, PostgreSQL 9.4 relational database, PostGIS 2.1 extension, and some UML artifacts for documentation were used as well as some UML artifacts for documentation. KEY WORDS: Geographic database; GIS; Mobile devices.
SUMÁRIO
LISTA DE FIGURAS .............................................................................................................. 1
LISTA DE QUADROS ............................................................................................................ 2
LISTA DE ABREVIATURAS .................................................................................................. 4
1 INTRODUÇÃO .................................................................................................................... 5 2 OBJETIVOS ........................................................................................................................ 7 2.1 Objetivo Geral: ................................................................................................................. 7 2.2 Objetivos Específicos: ...................................................................................................... 7 3 REVISÃO BIBLIOGRÁFICA ................................................................................................ 8 3.1 Sistemas de Informação .................................................................................................. 8 3.2 Sistemas de Informações Geográficas (SIG) ................................................................. 10 3.3 Sistemas Gerenciadores De Bancos De Dados (SGBD) ................................................ 11 3.3.1 Definição e objetivos ................................................................................................... 11 3.3.2 Modelagem ................................................................................................................. 13 3.4 Orientação a objetos ...................................................................................................... 17 3.5 Unified Modeling Language (UML) ................................................................................. 19 3.6 Rational Unified Process (RUP) ..................................................................................... 20 3.7 Computação móvel ........................................................................................................ 22 3.8 Web e Web Services...................................................................................................... 23 4 MATERIAL E MÉTODOS .................................................................................................. 25 4.1 Caracterização dos requisitos ........................................................................................ 25 4.2 Casos de Uso ................................................................................................................ 27 4.3 Diagrama do banco de dados ........................................................................................ 28 4.4 Arquitetura do sistema ................................................................................................... 29 4.5 Tecnologias e ferramentas utilizadas ............................................................................. 31 4.5.1 Java ............................................................................................................................ 31 4.5.1.1 Java Server Faces ................................................................................................... 32 4.5.1.2 Java Persistence API e Hibernate ............................................................................ 32 4.5.2 Glassfish ..................................................................................................................... 33 4.5.3 Ambiente de Desenvolvimento .................................................................................... 33 4.5.3.1 NetBeans ................................................................................................................. 34 4.5.3.2 Eclipse ..................................................................................................................... 34 4.5.4 PostgreSQL ................................................................................................................ 34 4.5.5 Leaflet JS .................................................................................................................... 35 4.6 Fluxo das atividades ...................................................................................................... 35 4.7 Testes ............................................................................................................................ 36 5 RESULTADOS E DISCUSSÃO ........................................................................................ 38 5.1 Operação do sistema no ambiente Web ........................................................................ 38 5.2 Operação do sistema na plataforma móvel .................................................................... 52 6 CONCLUSÃO ................................................................................................................... 59 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 61 APÊNDICE I ........................................................................................................................ 65
APÊNDICE II ....................................................................................................................... 67
APÊNDICE III ...................................................................................................................... 69
APÊNDICE IV ...................................................................................................................... 71
LISTA DE FIGURAS
Figura 1 Atividades de um sistema ........................................................................................ 8
Figura 2 Visão geral sobre Sistema Gerenciador de Banco de Dados, composto pelos
subsistemas que dividem a responsabilidade de manter um eficiente controle dos dados
armazenados. ...................................................................................................................... 12
Figura 3 Exemplo de um modelo relacional para armazenar produtos e suas respectivas
categorias. ........................................................................................................................... 14
Figura 4 Exemplo de pontos em um sistema de coordenadas. ............................................ 16
Figura 5 Exemplo de polilinhas. ........................................................................................... 16
Figura 6 Exemplo de polígonos............................................................................................ 17
Figura 7 Classe professor com seus atributos e métodos. Os atributos definem as
características e os métodos definem as ações. .................................................................. 19
Figura 8 Fases do processo RUP ........................................................................................ 21
Figura 9 Localização do município de Salto do Lontra ......................................................... 25
Figura 10 Diagrama de casos e uso do sistema wGCGEO. ................................................. 28
Figura 11 Modelo Relacional do aplicativo Web proposto .................................................... 29
Figura 12 Arquitetura do sistema ......................................................................................... 30
Figura 13 Compilação e execução de um programa Java.................................................... 32
Figura 14 Fluxo das atividades em visão macro .................................................................. 35
Figura 15 Tela de acesso do login (a) e menu principal para acesso às rotinas do sistema (b)
............................................................................................................................................ 38
Figura 16 Lista de propriedades monitoradas no projeto...................................................... 39
Figura 17 Interface para inclusão de nova propriedade no sistema ..................................... 39
Figura 18 Upload de arquivo do polígono de uma área de interesse. .................................. 40
Figura 19 Definição dos pontos de coleta na propriedade. ................................................... 41
Figura 20 Uso e ocupação do solo da propriedade estudada. ............................................. 41
Figura 21 Lista de características disponíveis para coleta. .................................................. 42
Figura 22 Interface para edição de características. .............................................................. 42
Figura 23 Listagem de rotas que poderão ser estabelecidas. .............................................. 43
Figura 24 Propriedades de uma determinada rota simulada. A elipse vermelha destaca as
propriedades disponíveis. A elipse verde destaca as propriedades incluídas na rota. ......... 44
Figura 25 Lista de projetos monitorados pelos pesquisadores. ............................................ 44
Figura 26 Detalhes do projeto “GEOLAB – COLETA DE DADOS DO SOLO” ...................... 45
Figura 27 Atividades que serão executadas em um projeto. ................................................ 45
Figura 28 Características selecionadas para serem coletadas pelo projeto. ........................ 46
Figura 29 Propriedades que serão estudadas e foram incluídas no projeto. ........................ 47
Figura 30 Tela principal do sistema. Demonstra as propriedades estudadas em um mapa
que foi criado por meio dos polígonos importados. .............................................................. 48
Figura 31 Janela popup exibida no momento do clique em uma propriedade. ..................... 49
Figura 32 Análises executadas na propriedade. .................................................................. 49
Figura 33 Campos que são montados para serem preenchidos no momento do lançamento
dos dados da análise. .......................................................................................................... 50
Figura 34 Tela para emissão do relatório de análises do sistema wGCGEO. ...................... 51
Figura 35 Planilha de dados gerada pelo sistema wGCGEO. .............................................. 51
Figura 36 Consulta de propriedades. Filtro de características fora dos limites (a) e
propriedade destacada no mapa (b). ................................................................................... 52
Figura 37 Interface inicial do sistema mGCGEO. Autenticação do usuário (a) e menu
principal do sistema (b). ....................................................................................................... 53
Figura 38 Lista de projetos sincronizados pela Web. ........................................................... 54
Figura 39 Interface do sistema mGCGEO. Lista de Propriedades disponíveis (a) e detalhes
de uma propriedade selecionada (b). ................................................................................... 54
Figura 40 Interface do sistema mGCGEO. Lista de culturas (a) e incluir nova cultura (b). ... 55
Figura 41 – Interface o sistema mGCGEO. Menu de coleta (a), lista de rotas a serem
cumpridas (b) e propriedades a serem visitadas naquela rota (c). ....................................... 56
Figura 42 Interface do sistema mGCGEO. Definição dos dados da coleta (a), lista de
análises realizadas (b) e campos para inclusão dos dados da coleta (c). ............................ 57
Figura 43 Interface de comunicação do sistema mGCGEO. Menu de sincronização (a) e
progressão da transmissão no recebimento dos dados da Web (b). .................................... 58
LISTA DE QUADROS
Quadro 1 Dados da tabela Categoria ................................................................................... 14
Quadro 2 Dados da tabela Produto ...................................................................................... 14
Quadro 3 Detalhamento dos Requisitos do software ........................................................... 26
Quadro 4 Caso de Teste CT1 – Cadastrar Propriedade ...................................................... 36
Quadro 5 Procedimento de teste ......................................................................................... 37
Quadro 6 Limites dos Parâmetros para avaliação da qualidade da água ............................. 52
4
LISTA DE ABREVIATURAS
ADT - Android Development Tools
BD - Banco de Dados
ERP - Enterprise Resource Planning
FMIS - Farm Management Information System
GeoLab - Laboratório de Topografia e Geoprocessamento
HD - Hard Drive
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
IDE - Integrated Development Environment
JPA - Java Persistence API
JSF - Java Serve Faces
JSP - Java Server Pages
JSR - Java Specification Request
MVC - Model-View-Controller
ORM - Object/Relational Mapping
PK - Primary Key
POO - Programação Orientada a Objetos
RNF - Requisitos Não Funcionais
RUP - Rational Unified Process
SGBD - Sistemas Gerenciadores de Bancos de Dados
SIG - Sistema de Informações Geográficas
SQL - Structured Query Language
UML - Unified Modeling Language
URL - Uniform Resource Location
WWW - Worl Wide Web
5
1 INTRODUÇÃO
Avanços, proporcionados pela informática, têm permitido às mais diversas áreas se
beneficiar com ferramentas que contribuem para que os profissionais mantenham o foco em
suas atividades (LAUDON; LAUDON, 1999). Não é de interesse que pesquisadores e/ou
profissionais de outras áreas se tornem especialistas em tecnologia da informação para
armazenar e tratar os dados pertinentes ao seu trabalho. A evolução no uso de sistemas
específicos ocorre com as empresas, com uso dos sistemas Enterprise Resource Planning
(ERP), acontece na área da educação, com uso de softwares estatísticos, por exemplo, e
acontece também em institutos de pesquisa, com o uso de sistemas especializados, como é
o caso dos Sistemas de Informações Geográficas (SIGs).
É fato que toda essa evolução deixou algumas atividades mais convenientes,
diminuindo, por exemplo, o tempo de espera para processamento de resultados. Entretanto
a demanda por sistemas que atendam necessidades específicas ainda é grande (LAUDON;
LAUDON, 1999). Dentre muitas outras preocupações, engenheiros agrícolas estão
trabalhando para melhorar a produtividade das lavouras com menor impacto ambiental,
engenheiros civis estão procurando meios de reutilização dos materiais e engenheiros
químicos procuram formas alternativas de energia. O que todos eles têm em comum? Todos
necessitam do apoio de sistemas que supram suas necessidades informacionais, mas esses
profissionais não têm a informática como sua atividade fim. Os sistemas são ferramentas
para que eles possam desenvolver suas pesquisas com satisfação, integridade e
velocidade, não se preocupando com linhas de código de programação ou estruturas de
dados complexas.
No Laboratório de Topografia e Geoprocessamento (GeoLab) da Universidade
Estadual do Oeste do Paraná (UNIOESTE), campus de Cascavel, os problemas não são
diferentes. Diversas pesquisas estão sendo conduzidas por acadêmicos de iniciação
científica e por alunos de mestrado e doutorado do programa de pós-graduação, com o
intuito de melhorar processos, criar ferramentas e desenvolver tecnologias para melhoria
das atividades agrícolas da região. Contudo, a quantidade de dados gerados pelas
pesquisas é grande, e, na maioria das vezes, os pesquisadores ficam responsáveis por toda
a tarefa de mantê-los seguros e disponíveis.
Acidentes que resultam em perda de dados, modificação de dados sem permissão
ou até mesmo atraso na localização dos dados são problemas que podem comprometer
pesquisas, aumentar despesas e diminuir a produtividade dos pesquisadores.
Nesse contexto, o presente trabalho objetivou a informatização do processo de
coleta de dados do GeoLab da UNIOESTE, campus de Cascavel, provendo uma plataforma
que permita dar apoio nas etapas de coleta, armazenamento, integração e disponibilização
6
dos dados a todos os pesquisadores, de forma segura e rápida. Foram utilizados como base
os dados de pesquisas relacionadas ao projeto Aplicação Conjunta das Técnicas de
Geoprocessamento e SIG na Agricultura Familiar, e do Subprograma de Apoio à Agricultura
Familiar e Agroecologia, inseridos no âmbito do Programa de Extensão “Universidade Sem
Fronteiras” (USF), vinculado à SETI sob edital 01/2013, executados pelos pesquisadores do
GeoLab da UNIOESTE, campus de Cascavel.
No monitoramento realizado, os pesquisadores recolhem dados nas propriedades
dos produtores do programa, coletam amostras para avaliar a qualidade da água e do solo e
armazenam essas informações em planilhas eletrônicas. O uso das planilhas eletrônicas
dificulta o compartilhamento dos dados, não garante a integridade, tampouco a segurança
dessas informações.
A partir do momento da implantação do projeto, todas essas informações poderão
ser lançadas no sistema, que terá uma estrutura de dados robusta para armazenamento.
Destaca-se a inovação que a presente ferramenta trará, pois as novas coletas poderão ser
realizadas utilizando um aplicativo para dispositivos móveis, que fará a sincronização dos
dados com a plataforma, disponibilizando as informações aos pesquisadores. Esse
aplicativo receberá os dados inseridos no sistema Web e trabalhará off-line, pois na maior
parte das propriedades não há cobertura de rede de dados. Quando o pesquisador tiver
acesso à rede de dados, ele poderá enviar os dados coletados para o sistema.
A plataforma será desenvolvida para ser executada em ambiente Web, facilitando o
acesso aos usuários. Tecnologias como Java, PostgreSQL e PostGIS estarão presentes.
Conforme Rao, Geetha e Maíti (2014), o software executado em ambiente Web pode ser
acessado de qualquer computador conectado à internet. O único requisito para o cliente é
um web-browser. Outra característica interessante da plataforma é o armazenamento de
dados geoespaciais. Esses tipos de dados são estruturas complexas e necessitam de meios
de armazenamento especiais que são os Bancos de Dados Geográficos. Os pesquisadores
do GeoLab da UNIOESTE, campus de Cascavel, possuem o mapeamento das propriedades
rurais via GPS, que serão inseridos no sistema.
7
2 OBJETIVOS
2.1 Objetivo Geral
O objetivo do presente trabalho é desenvolver uma aplicação que possa ser
executada em ambiente Web e um aplicativo Mobile para informatização do processo de
coleta de dados das pesquisas GeoLab da UNIOESTE,campus de Cascavel.
2.2 Objetivos Específicos
Efetuar a análise dos requisitos e elaborar a documentação necessária para projetar
o software.
Estudar e definir a forma de armazenamento dos dados espaciais no banco de
dados relacional.
Inserir dados retroativos no software para permitir o acompanhamento histórico.
Disponibilizar um ambiente de testes para que os pesquisadores possam validar o
software antes de sua implantação.
8
3 REVISÃO BIBLIOGRÁFICA
3.1 Sistemas de Informação
Para entender as questões relacionadas aos sistemas de informação, é necessário,
primeiramente, o esclarecimento do termo “sistema”.
Ludwig Von Bertalanffy, nas décadas de 1950 e 1960, realizou estudos na área de
biologia, determinou o termo organismo como maior do que a soma de suas partes e,
consequentemente, estabeleceu como ciência a Teoria Geral de Sistemas. Assim, com essa
idealização, Bertalanffy quebrou o paradigma de que o mundo é dividido em áreas (biologia,
psicologia, física e química, por exemplo) e propôs uma unidade funcional mais abrangente,
onde são desenvolvidas qualidades que não são encontradas isoladamente nos seus
componentes (BERTALANFFY, 1968).
A partir dos estudos de Bertalanffy, diversos autores propuseram conceitos acerca
de Sistemas, como Mülber (2005), que caracterizou um sistema como um conjunto de
partes coordenadas, que concorrem para a realização de um objetivo. Mülber acrescentou,
ainda, que é possível definir um sistema como um conjunto de componentes e processos
capaz de transformar determinadas entradas em saídas.
Logo, uma forma simplória de exemplificar um sistema é ilustrar suas atividades,
conforme a Figura 1.
Figura 1Atividades de um sistema Fonte: Adaptado de MÜLBER (2005).
Observa-se na Figura 1 que o fluxo de informações de um sistema é caracterizado
como um conjunto de entradas que podem sofrer processamentos e têm um fim. O final do
processamento gera uma saída. Esta saída pode ou não ser um produto final, e existem
casos em que a saída gerada é responsável pela nova entrada, caracterizando o que foi
denominado de retroalimentação.
Fim
9
Para Laudon e Laudon (1999, p. 4), a entrada “envolve a captação ou coleta de
fontes de dados brutos”. O processamento, por sua vez, “envolve a conversão dessas
entradas brutas em uma forma mais útil e apropriada”. Por fim, a saída “envolve a
transferência da informação processada às pessoas ou atividades que a usarão”.
Com a evolução da informática e a necessidade crescente de gerir dados cada vez
maiores, surgiram os sistemas de informação. Estes, geralmente, são compostos por
subsistemas. Cada subsistema é responsável por realizar determinada atividade. A técnica
de se usar subsistemas permite a melhor gestão do sistema como um todo, pois cada
componente é especializado em executar uma tarefa e tem a capacidade de se relacionar
com outros subsistemas. Assim, pode-se diminuir a complexidade de um grande sistema,
com a construção de vários pequenos sistemas que o compõem (MÜLBER, 2005).
Um sistema de informação é um conjunto inter-relacionado de componentes, que
tem o intuito de coletar, processar, armazenar e distribuir informações, portanto, é a
combinação de recursos tecnológicos, humanos e organizacionais que permitem a gestão
de um processo ou atividade (CIDRAL; AUDY; ANDRADE, 2007).
Os recursos humanos que compõem um sistema de informação são as pessoas
que utilizam informações vindas dos sistemas e inserem informações para que possam ser
compartilhadas, validadas e armazenadas nos bancos de dados. Já os recursos
tecnológicos podem se apresentar de algumas formas, dentre elas: hardware, que são os
equipamentos físicos usados para imputar, processar e exibir os dados; software, que são
as instruções pré-programadas, com base nos requisitos do sistema, e organizam o trabalho
do hardware; armazenamento, que engloba o uso de hardware e software em estruturas
especiais criadas para garantir a vida dos dados; e, por fim, na forma de comunicação, que
permite a transferência de dados entre um ponto e outro por meio das redes. As redes
também são compostas por hardware e software, porém sua tarefa é permitir que dados se
desloquem e sejam acessíveis remotamente garantindo velocidade e segurança dentro do
processo. Ainda, afirma-se que um sistema de informação baseado em computador é
formulado para resolver problemas importantes que surgem nas organizações (LAUDON;
LAUDON, 1999).
Verifica-se que a teoria geral dos sistemas se mantém na definição de um Sistema
de Informação, mas o que ocorre é uma especialização para fins específicos. Contudo,
ainda existem subdivisões dentro do tema Sistema de Informação. Tal é o caso de sistemas
que compreendem e estruturam as informações com o intuito de resolver problemas
exclusivos de determinada área de atuação. Pertencem a esse grupo os Sistemas de
Informação Geográfica.
10
3.2 Sistemas de Informações Geográficas (SIG)
Para Longley et al. (2013), tudo o que acontece, acontece em algum lugar.
Portanto, saber onde determinado fato ocorreu é base importante para determinar seu
controle.
Uma série de aplicações de sistemas de informação foi se aprimorando com o
passar do tempo a fim de contemplar características que permitem a localização dos fatos.
Com essa evolução, surgiram os SIGs.
Para Dueker (1979), SIG é um caso especial de sistemas de informações, no qual o
banco de dados consiste em informações sobre características distribuídas espacialmente,
atividades ou eventos, os quais são definidos no espaço como pontos ou polígonos.
O conceito elaborado por Burrough (1986) caracteriza SIG como um poderoso
elenco de ferramentas para colecionar, armazenar, recuperar, transformar e exibir dados
espaciais referenciados ao mundo real.
Longley et al. (2013) conceitua SIG como sistemas computacionais feitos para
armazenar e processar informações geográficas. Sobretudo, eles são ferramentas que
melhoram a eficiência e efetividade do tratamento da informação de aspectos e eventos
geográficos.
Compreendendo esses conceitos fundamentais, percebe-se que a utilização de SIG
ocorre em diversas situações do cotidiano das empresas, instituições e pessoas, por
exemplo, para gestão de saúde pública, logística de materiais, criação de rodovias,
consultoria de vendas, gestão de parques nacionais, turismo e agricultura, entre outras.
No caso de SIG na agricultura, pode-se, por exemplo, orientar produtores acerca de
quando e onde aplicar pesticidas e fertilizantes, garantindo uso racional dos recursos, sem
prejudicar o meio ambiente (LONGLEY et al., 2013).
Frente ao termo SIG, é evidente que a tarefa de armazenamento de dados é uma
das atividades primordiais durante o processo de um SIG. Armazenar dados com segurança
não é tarefa fácil. A evolução dos sistemas gerenciadores de bancos de dados, como
ferramenta confiável para manter informações, permitiu o uso mais abrangente desses
sistemas.
Entretanto, os sistemas de bancos de dados relacionais não possuem
características que permitam a modelagem dos dados espaciais. Nesse contexto, para
auxiliar na resolução desse tipo de problema, foram desenvolvidos os bancos de dados
geográficos.
11
3.3 Sistemas Gerenciadores de Bancos de Dados (SGBD)
3.3.1 Definição e objetivos
Armazenar informações é uma tarefa que permeia toda a existência do homem.
Nossos antepassados usavam papéis para esse fim antes mesmo de qualquer tecnologia
contemporânea surgir. Os homens das cavernas utilizavam pinturas nas paredes para
ilustrar situações do cotidiano. Essa necessidade de registrar os fatos não é recente.
Contudo, a tecnologia atual nos permite gravar e compartilhar informações de forma
muito mais rápida e segura, por meio dos Sistemas Gerenciadores de Bancos de Dados.
É importante salientar que existem diferenças entre os termos Banco de Dados
(BD) e Sistemas Gerenciadores de Bancos de Dados (SGBD). Por si só, um BD é um
repositório (local de armazenamento) de dados. Para construir um banco de dados, não é
necessária nenhuma tecnologia de informação. Um fichário que contém arquivos de
pacientes é uma forma tradicional de se armazenar dados (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999).
O SGBD é um sistema que permite o armazenamento digital dos dados; logo, a
tecnologia de informação é necessária. Além de prover estruturas de armazenamento,
Silberschatz, Korth e Sudarshan (1999) afirmam que ele é constituído por um conjunto de
dados associados a um conjunto de programas para acesso a esses dados. Os dados são
informações do usuário que estão armazenadas. Os programas são ferramentas que
auxiliam no acesso, na segurança e na gestão do armazenamento.
Observa-se que em um SGBD as informações se integram, como mencionado por
Kroenke (1998), quando se refere ao SGBD como uma coleção autodescritiva de registros
integrados. Trata-se de uma coleção autodescritiva, pois além dos dados do usuário,
armazenados em uma estrutura chamada schema, o SGBD mantém informações sobre ele
próprio, em outra estrutura, denominada catálogo.
Por fim, o SGBD é “um sistema computadorizado cuja finalidade geral é armazenar
informações e permitir que os usuários busquem e atualizem essas informações quando as
solicitar” (DATE, 2003, p. 5).
A Figura 2 exemplifica o ambiente de um SGBD. A partir dela, pode-se observar a
complexidade envolvida no processo de armazenamento dos dados, bem como os
subsistemas que os compõem. Os subsistemas tratam de tarefas específicas. Um dos
subsistemas existentes é o Gerenciador de Processos (a), que é responsável pelo controle
de acesso, requisições e agendamento de tarefas que serão executadas. Para que um
cliente estabeleça uma conexão com o SGBD, é necessária a implementação de protocolos
12
de comunicação, em que o Gerenciador de Conexões Clientes (b) disponibiliza os
protocolos de acesso local e remoto.
Figura 2 Visão geral sobre Sistema Gerenciador de Banco de Dados, composto pelos subsistemas que dividem a responsabilidade de manter um eficiente controle dos dados armazenados. Fonte: Adaptado de MIT1 (2015).
Quando uma consulta é submetida ao Sistema Gerenciador de Banco de Dados, o
Processador de Consultas (c) é acionado. Esse processo é responsável por transformar e
validar a consulta, criando planos de execução que minimizem o custo computacional para
recuperar os dados solicitados e devolver o conjunto de dados ao usuário que solicitou.
Muitas das tarefas realizadas por um usuário refletem em várias modificações nos
dados armazenados no SGBD. Do ponto de vista do usuário, ele executou apenas uma
operação. O banco de dados tem que garantir que todas as modificações sejam refletidas
corretamente nos dados. Se algum erro que impeça a continuidade do processo ocorrer, é
sua função reverter as modificações realizadas, para que o banco de dados permaneça
consistente. Esse controle é realizado pelo Gerenciador de Armazenamento Transacional
(DATE, 2003).
Parte-se do pressuposto de que onde existem vários usuários acessando os
mesmos dados há a concorrência por recursos. Assim o Gerenciador Transacional (d)
também controla a concorrência, bloqueando as informações de forma exclusiva ou
compartilhada, dependendo da necessidade.
Um BD reside na memória não volátil do computador, isto é, no Hard Drive (HD).
Esse tipo de memória permite grande capacidade de armazenamento; entretanto, é mais
lento. Para ter desempenho satisfatório, o SGBD carrega os blocos de dados do disco para
a memória RAM, em um espaço chamado buffer. Os dados são modificados no buffer e
13
depois são recolocados no disco. Para evitar a leitura e escrita constante de todo o buffer no
disco, o que geraria uma sobrecarga de processamento, o SGBD registra apenas os
eventos relevantes das transações, esses eventos são chamados de log, o que permite que
o banco se recupere no caso de uma queda do sistema durante o processamento.
Um SGBD tem como principal objetivo proporcionar um ambiente tanto conveniente
quanto eficiente para a recuperação das informações lá armazenadas (SILBERSCHATZ;
KORTH; SUDARSHAN, 1999). O ambiente conveniente pode ser entendido como as
facilidades que o SGBD deve prover para o acesso aos dados. No que se refere à eficiência,
entende-se que o SGBD deve possuir um desempenho satisfatório, dispor de regras de
integridade e propiciar a segurança das informações.
As informações presentes na maioria dos sistemas são dados estruturados que
podem ser armazenados em estruturas tabulares. Essas estruturas tabulares deram origem
aos bancos de dados relacionais, que representam a forma mais utilizada hoje para
armazenamento (SILBERSCHATZ; KORTH; SUDARSHAN, 1999).
3.3.2 Modelagem
O modelo de dados relacional, surgiu em 1970 na IBM Research, quando Ted Codd
publicou o artigo “A relational model of data for large shared data banks”, que atraiu a
atenção em virtude de sua simplicidade. Com base na teoria matemática dos conjuntos e no
cálculo de predicados, Codd propôs um modelo de armazenamento de dados (ELMASRI;
NAVATHE, 2005).
Modelos de dados são criados para abstrair informações do mundo real e criar
meios de armazenamento digital que representam o fato modelado. Nesse contexto, o
modelo relacional representa o banco de dados como uma coleção de relações, e cada
relação é, informalmente, uma tabela de valores.
Quando se pensa em uma tabela para designar a relação, cada linha representa
uma coleção de valores de dados relacionados. Assim, cada linha representa um fato que
corresponde a uma entidade ou relacionamento do mundo real.
Em uma situação onde se pretende armazenar dados de produtos agrícolas e suas
respectivas categorias, dentro de uma instituição, deseja-se manter a informação de
identificação de cada uma das categorias, isto é, a descrição do que cada categoria
representa: a identificação de um determinado produto, o nome deste produto e a qual
categoria pertence.
Nesse caso, pode-se elaborar um modelo semelhante ao da Figura 3, e têm-se
todos os dados que foram requisitos de armazenamento, ou seja, os dados das categorias,
dos produtos e seu relacionamento.
14
Figura 3 Exemplo de um modelo relacional para armazenar produtos e suas respectivas categorias.
No modelo expresso na Figura 3, é necessário o esclarecimento de outros termos
inerentes à modelagem relacional. Cada retângulo representa uma tabela; logo, na Figura 3
têm-se as tabelas categoria e produto.
Cada item contido na tabela representa um atributo. O atributo é uma característica
específica da tabela. Essa característica a descreve em sua forma e conteúdo. Por exemplo,
a tabela categoria possui os atributos “codigo_categoria”, que representam um código para
uma determinada categoria, e o atributo “descricao", que é a descrição da categoria citada.
O Quadro 1 exemplifica as informações acerca da tabela Categoria.
Nota-se que não há o uso de acentos na definição dos atributos, visto que o modelo
será implementado em um banco de dados, e na maioria das vezes o banco de dados tem
como origem o idioma inglês. Nesse caso, evita-se ao máximo o uso de caracteres
específicos de qualquer outro idioma.
Quadro 1 Dados da tabela Categoria
codigo_categoria descricao
1 SEMENTE
2 FERTILIZANTE
3 DEFENSIVO
Analisando os atributos da tabela produto, tem-se: “codigo_produto”, “descricao” e
“codigo_categoria”, que são por sua vez as informações referentes ao código de
determinado produto, seu nome ou descrição, e o código da categoria a que ele pertence,
conforme os dados observados no Quadro 2.
Quadro 2 Dados da tabela Produto
codigo_produto Descrição codigo_categoria
S001 SEMENTE MILHO SC 1
S002 SEMENTE SOJA SC 1
F001 FERTILIZANTE FOLIAR 20 L 2
F002 FERTILIZANTE FOLIAR – ZINCO 1L 2
D001 GLIFOSATO GALAO 5L 3
15
Um conceito fundamental nos bancos de dados relacionais são os domínios.
Domínios são os tipos de dados que determinado atributo pode aceitar. Entende-se por tipos
de dados toda e qualquer informação categorizada em dados numéricos, alfanuméricos,
booleanos, datas, horas, etc. São os domínios que validam as entradas de dados na tabela
e garantem que a informação que se pretende adicionar lá é compatível com seu propósito
(ALVES, 2004).
O domínio INTEGER representa os dados numéricos inteiros. Já o domínio
VARCHAR representa os dados alfanuméricos. No caso de atributos do tipo VARCHAR, é
normal que se determine o tamanho, em número de caracteres, que podem ser
armazenados naquele atributo. Por exemplo, VARCHAR(60) permite armazenar sessenta
caracteres alfanuméricos no atributo (ELMASRI; NAVATHE, 2005).
Além dos atributos e domínios, um banco de dados relacional é conhecido por suas
chaves. Simplificadamente existem dois tipos de chaves: primárias e estrangeiras (DATE,
2003).
As chaves primárias são os atributos, elencados pelo criador do modelo,
identificadores da tabela. No caso da tabela produto (Quadro 2), o atributo identificador é o
“codigo_produto” (que está assinalado como PK, do inglês Primary Key). Ter o atributo
“codigo_produto” como chave primária faz com que o banco de dados não permita dois
produtos que tenham o mesmo valor para esse atributo. Ou seja, não são permitidos dois
produtos com o mesmo código. Assim, cada produto é distinguido de forma única dentre
todos os outros.
As chaves estrangeiras são atributos utilizados para relacionar as tabelas. No
Quadro 2, a chave estrangeira atua como um agente que garante a integridade das
informações existente entre as tabelas “categoria” e “produto”. Somente categorias
existentes na tabela “categoria” podem ser vinculadas aos produtos.
Quando se trata de dados espaciais, o modelo relacional enfrenta problemas, visto
que a estrutura de dados relacional, na maioria das vezes, não se permite representar na
forma de uma tabela. Para essa especialização surgiram os bancos de dados geográficos.
Esse novo modelo permite mesclar dados estruturados de forma relacional com informações
referentes aos locais onde os fatos ocorreram, tais como dados de coletas de GPS, imagens
de satélite, entre outros.
Banco de dados geográficos ou banco de dados espaciais são sistemas de banco
de dados que definem uma estrutura especial de tipos de dados para objetos geométricos e
permite que esses dados espaciais sejam armazenados em um banco de dados relacional
comum. Eles provêm funções especiais e técnicas de indexação para consulta e
manipulação de dados utilizando uma linguagem estruturada, isto é, uma Structured Query
16
Language (SQL). Frequentemente um banco de dados é usado apenas como repositório
dos dados, entretanto eles podem executar algoritmos que auxiliem os softwares que o
utilizam, além de permitir a criação de restrições que garantam a integridade dos dados
(OBE, 2011).
Esse tipo de banco de dados é utilizado quando a palavra “onde” é a pergunta
central sobre as informações que se deseja armazenar. Nikkilä, Seilonen e Koskinen (2010)
afirmam que sistemas que contribuem na gestão agrícola são exigidos no quesito de
manter, gerenciar e manipular informações geográficas, pois a localização é indispensável
para analisar a informação.
Para que isso seja possível, é necessário, inclusive, pensar de forma espacial. Esse
pensamento se refere particularmente aos tipos de dados que serão armazenados nesse
banco de dados. Os tipos básicos de estruturas de dados espaciais são: pontos (point),
polilinhas (linestring) e áreas ou polígonos (polygons). Cada um desses tipos de dados tem
características específicas (LONGLEY et al., 2013).
Os pontos são gravados como pares de coordenadas simples (Figura 4). Eles
podem ser utilizados para determinar a posição de uma universidade, de uma propriedade
rural etc.
Figura 4 Exemplo de pontos em um sistema de coordenadas. Fonte: Adaptado de Longley et al. (2013).
As polilinhas são representadas por uma série de pares de coordenadas (Figura 5).
Elas podem representar rodovias, córregos ou falhas geológicas.
Figura 5 Exemplo de polilinhas. Fonte: Adaptado de Longley et al. (2013).
17
Já os polígonos são um ou mais segmentos de linha que se fecham para formar
uma área, como apresentado na Figura 6. Esse tipo de dado pode representar, por exemplo,
um setor censitário, áreas de solo, propriedades rurais, áreas de petróleo etc.
Figura 6 Exemplo de polígonos. Fonte: Adaptado de Longley et al. (2013).
Considerando o cenário de dados geográficos, a OGC (Open Geospatial
Consortium), um consórcio formado por 518 empresas, governos e instituições de ensino,
esforça-se no sentido de padronizar o uso de dados espaciais. Essa padronização visa à
melhoria na interoperabilidade entre sistemas a fim de que todos possam se beneficiar dos
dados geográficos (OGC1, 2015).
Conforme Gil, Kozievitch e Torres (2011), a OGC define, além dos pontos, linhas e
polígonos, as coleções geométricas (Geometry Collection). Uma coleção geométrica pode
ser usada para representar uma coleção de objetos distintos, com, por exemplo, multipontos
(Multi Point), multilinhas (Multi Line Strings) e multipolígonos (Multi Polygon).
Para se armazenar os dados do sistema, sejam eles geográficos ou não, é
necessária a criação do modelo de dados. Entretanto, não é somente o modelo de dados
que permite ilustrar o software antes de seu desenvolvimento. Existem também os modelos
dos artefatos, que se enquadram no processo de desenvolvimento e garantem a aderência
entre o que foi solicitado e o que foi desenvolvido. Uma das formas de se construir modelos
de software é usar a Unified Modeling Language (UML), que será abordada adiante. Aliado
à UML, o paradigma de programação orientada a objetos é uma forma muito utilizada de se
desenvolver sistemas.
3.4 Orientação a objetos
Durante muito tempo, a maneira de se desenvolver sistemas foi por meio da
chamada programação estruturada. Esse meio remete-se a duas formas de tratar os
problemas: dividir a tarefa em subtarefas até que seja possível criar procedimentos para
programar ou criar procedimentos e agrupá-los em estruturas mais complexas até que o
problema seja resolvido. Diferentemente da abordagem estruturada, quando se pensa em
18
Programação Orientada a Objetos (POO), as tarefas não estão centradas na identificação
de procedimentos, mas sim na identificação de objetos (SANTOS, 2011).
O objeto pode ser considerado como uma entidade do mundo real que possui
características próprias e interagem com outros objetos. Já a entidade, mesmo sendo
abstrata, pode ser um objeto, do ponto de vista desse paradigma de programação. Pode-se
citar como exemplo de objetos um livro, um computador, um carro, uma máquina agrícola,
um defensivo, uma pessoa, uma conta bancária. A conta bancária não é um objeto concreto,
mas abstrato. O mundo está repleto de objetos, e não é difícil identificá-los.
Para se desenvolver um sistema orientado a objetos, deve-se ter em mente que
inicialmente são três as atividades principais envolvidas no projeto. a) Identificação dos
objetos; b) Identificação das características dos objetos; c) Identificação das ações que o
objeto executa e os serviços que ele presta (SANTOS, 2011).
Todo objeto possui características próprias que os descrevem e permitem distingui-
los entre objetos semelhantes. Também se pode denominar essas características como
atributos. Embora possam existir milhares de objetos semelhantes, nunca haverá dois
objetos exatamente iguais. Por exemplo, existem livros com o mesmo nome, autores e
ISBN, tratando-se da mesma obra, entretanto, cada um é um exemplar diferente. Assim, se
não existir uma característica específica que consiga distinguir um objeto do outro, há a
necessidade de se incluir essa característica no objeto.
Para se definir um objeto, usam-se substantivos para determinar seus atributos
(ligados a qualidades), e usam-se verbos para determinar seus métodos (relativos às ações)
(MAGELA, 2006).
As classes constituem um conceito fundamental da POO e são definidas como “[...]
um conjunto de objetos que respondem as mesmas ações com os mesmos resultados e
possuem os mesmos atributos” (MAGELA, 2006, p. 59). Quando se tem um objeto
Professor, por exemplo, assume-se que todos os professores possuem as mesmas
características e executam os mesmos serviços, entretanto, cada professor é único.
Portanto, o conjunto de Professores é a classe Professor, que pode ser concebida como
uma “categoria”. Desse modo, o professor Erivelto é único e é uma instância da classe
Professor.
Dentro de uma classe Professor, podem existir os atributos (características) nome,
endereço, e-mail, CPF e as ações (métodos) que essa classe poderia realizar são
“apontarFalta()”, “lançarNota()”, “emitirDiário()”. A Figura 7 ilustra a classe Professor.
19
Figura 7 Classe professor com seus atributos e métodos. Os atributos definem as características e os métodos definem as ações.
Para ilustrar uma classe, bem como outros artefatos utilizados para se desenvolver
um sistema, usa-se uma linguagem de modelagem. Uma das linguagens de modelagem
mais utilizadas é a UML.
3.5 Unified Modeling Language (UML)
A UML é uma linguagem que permite aos desenvolvedores de sistemas
especificarem, visualizarem e documentarem o modelo de software de uma maneira que
admita escalabilidade, segurança e execução robusta (PENDER, 2004).
Os modelos devem descrever o comportamento desejado do sistema e devem
permitir visualizar e controlar a arquitetura. Logo, “a modelagem é uma parte central de
todas as atividades que levam à implantação de um bom software” (BOOCH; RUMBAUGH;
JACOBSON, 2000, p. 3).
O modelo nada mais é do que a simplificação da realidade, construído para permitir
o melhor entendimento do sistema que está sendo desenvolvido. Contudo, nenhum modelo
único é suficiente, visto que “qualquer sistema será melhor investigado por meio de um
pequeno conjunto de modelos quase independentes” (BOOCH; RUMBAUGH; JACOBSON,
2000, p. 10).
Nesse contexto, a UML é adequada à modelagem de sistemas, pois abrange todas
as visões necessárias ao desenvolvimento e à implantação de sistemas, sendo constituída
por quatro tipos de itens: estruturais, comportamentais, agrupamento e anotacionais
(BOOCH; RUMBAUGH; JACOBSON, 2000).
Os itens estruturais são as partes estáticas do modelo e representam elementos
conceituais ou físicos. Um exemplo de um item estrutural é a classe. As classes são
conjunto de objetos que compartilham operações, relacionamentos, semânticas e os
20
mesmos atributos (conforme se pode observar na seção anterior), no que concerne à
orientação a objetos.
Itens comportamentais são as partes dinâmicas do modelo e representam o
comportamento no tempo e no espaço. Esses comportamentos podem ser de interação, que
possibilita a troca de mensagens entre os objetos, ou podem ser uma máquina de estado,
que especifica a sequência de estados pelos quais os objetos passam durante sua
existência.
Já os itens de agrupamento são estruturas criadas para organizar os modelos. O
pacote é o item que permite agrupar um conjunto de outros componentes.
Por fim, os itens anotacionais permitem explicar o modelo com comentários,
necessários para esclarecer pontos de difícil interpretação, ou fazer alguma observação
sobre qualquer elemento do modelo.
Assim, após a escolha de um padrão de comunicação para o modelo, pode-se
optar por um processo de desenvolvimento que, aliado aos artefatos do modelo, direcionará
a construção do software. Para o presente projeto, o processo de desenvolvimento utilizado
é o Rational Unified Process (RUP). A próxima seção explicará o funcionamento do RUP e
no capítulo acerca dos materiais e métodos será exposta a forma como o processo foi
conduzido.
3.6 Rational Unified Process (RUP)
O RUP, que pode ser traduzido informalmente para Processo Racional Unificado,
adequa-se à UML para prover um conjunto de passos ordenados com a intenção de
entregar de forma eficiente um produto de software aderente aos requisitos e que atenda a
demanda do solicitante.
Entende-se por requisito uma descrição dos desejos ou das necessidades para um
determinado produto. Nessa etapa, identifica-se e documenta-se tudo o que é necessário de
forma clara e não ambígua. Essa definição abrange várias áreas de conhecimento e
enquadra-se muito bem no processo de criação de um software (LARMAN, 2000).
Os Requisitos Não Funcionais (RNF) geralmente são requisitos que dizem respeito
ao ambiente. Tratam de questões externas ao software, por exemplo, se a aplicação exige
que haja um help online para auxiliar no uso do sistema. Já os Requisitos Funcionais atuam
diretamente em fornecer a informação do que deve ser construído (MAGELA, 2006).
A UML por ser independente do processo utilizado, adaptando-se a vários tipos de
processos, logo, o RUP se adequa bem à UML e consequentemente o “RUP captura
algumas das melhores práticas atuais de desenvolvimento de software” (BOOCH;
RUMBAUGH; JACOBSON, 2000, p. 442).
21
Booch, Rumbaugh e Jacobson (2000) definem RUP como um processo interativo,
considerando que a solução requer entendimento crescente da demanda utilizando-se de
sucessivos melhoramentos e desenvolvimento incremental em vários ciclos. Destaca-se
também que o RUP foca na criação de modelos, especialmente da UML, que proporcionam
representações ricas semanticamente. Outra característica importante é que as atividades
são orientadas por casos de uso. Isso garante que durante o desenvolvimento os esforços
se concentrem em como o sistema será utilizado.
Segmentado em quatro fases, em que cada fase determina um período de tempo
entre dois grandes marcos de progresso, o RUP prevê que ocorram várias interações em
cada uma dessas fases. Ao término de cada fase, artefatos são concluídos e decisões são
tomadas acerca da passagem para a fase seguinte. As fases existentes dentro desse
processo são apresentadas na Figura 8 e consistem em: concepção, elaboração,
construção e transição (BOOCH; RUMBAUGH; JACOBSON, 2000).
Figura 8 Fases do processo RUP Fonte: Adaptado de Booch, Rumbaugh e Jacobson, 2000.
Observa-se na Figura 8 que cada uma das fases compreende algumas importantes
atividades, chamadas de fluxos de trabalho. Na fase de concepção (Inicial) se estabelecem
os casos de negócio e delimita-se o escopo do projeto. Também são elencados os casos de
uso e é viável o uso de protótipos para aprovação pelo solicitante. Durante a elaboração,
cria-se uma arquitetura sólida, a fim de minimizar os riscos baseados em um entendimento
22
completo do problema. Há também nessa fase a complementação dos casos de uso. Já na
fase de construção, desenvolve-se de forma interativa e incremental um produto completo,
de modo a dar corpo ao projeto e efetuar os testes do software. Por fim, a fase de transição
prega a disponibilização do software ao usuário, a partir do que novas questões surgirão e
ocorrerá o ciclo novamente.
3.7 Computação móvel
A computação móvel surgiu como um paradigma a partir do qual os usuários
poderiam carregar seus computadores e manter certa conectividade com outras máquinas.
Com a miniaturização dos dispositivos e as redes sem fio, ela se ocupou da exploração de
instrumentos que se movimentam no mundo físico. Nesse contexto, um novo paradigma
surgiu, a chamada computação de mão (handheld computing), popularizando o uso de
aparelhos que cabem na mão, como os telefones móveis inteligentes (smartphones)
(COULOURIS et al., 2013).
Montiel Perez, Hernandez Rubio e Lopez Bonilla (2012) apontam que a
computação móvel é uma área emergente, que prevê o trabalho remoto usando dispositivos
móveis, sistemas computacionais e Internet. O uso da computação móvel aumenta ano a
ano. Por exemplo, o número de telefones móveis, na América Latina, cresceu 90% nos
últimos dez anos (MONTIEL PEREZ; HERNANDEZ RUBIO; LOPEZ BONILLA, 2012).
Plataformas móveis podem se referir a diversas questões e níveis, incluindo
protocolos de redes, sistemas operacionais móveis, dispositivos móveis, além de serviços e
aplicações (BALLON; BOUWMAN; YUAN, 2011). No que se refere ao hardware, uma
característica importante desse tipo de computação é a economia de energia (MONTIEL
PEREZ; HERNANDEZ RUBIO; LOPEZ BONILLA, 2012). A economia de energia deve ser
considerada ponto crítico, pois os aparelhos precisam prover autonomia suficiente para que
não haja necessidade de interrupção no meio do trabalho.
A utilização da computação móvel pode ser caracterizada como Om-Business e
visa a auxiliar em diversos setores da economia. Om-Business pode ser definido como o
“uso de tecnologias móveis para promover a troca de bens, serviços, informação e
conhecimento” (NETO et al., 2007, p. 111).
Assim,
[...] ao apostar na convergência da telefonia móvel, com as tecnologias da internet, tendo em vista suportar a utilização das novas tecnologias de informação e comunicação em qualquer lugar e qualquer momento, terá um elevado potencial de utilização para setores agrícolas e agroindustriais (NETO et al., 2007, p. 111).
23
Com vistas à arquitetura a ser desenvolvida, levando-se em consideração a
mobilidade, deve-se também construir uma forma em que haja uma efetiva comunicação
entre o sistema que será executado no dispositivo móvel e a plataforma base, onde ficarão
armazenados os dados imputados pelos usuários. Alguns meios de comunicação remota
poderiam ser elencados para resolução desse problema, como, por exemplo, o uso de
sockets, Java Remote Method Invocation (RMI), ou ainda Remote Procedure Call (RPC).
Entretanto, optou-se pelo uso de Web Services, pois esta é uma das formas mais utilizadas
atualmente para a integração de sistemas.
3.8 Web e Web Services
Para Comer (2001), a World Wide Web (www), ou como também é conhecida, a
Web, é um repositório distribuído de hipermídia em larga escala, que pode ser acessado por
meio de um software navegador. Trata-se de um sistema aberto em constante evolução que
pode ser ampliado e implementado de novas maneiras, sem perturbar as funcionalidades
existentes. Em sua forma mais simples, um recurso Web é uma página ou algum tipo de
conteúdo que possa ser apresentado ao usuário (COULOURIS et al., 2013).
Coulouris et al. (2013) afirma que a arquitetura Web é baseada em três
componentes tecnológicos principais:
Hyper Text Markup Language (HTML): uma linguagem de marcação que
especifica o layout das páginas;
Uniform Resource Location (URL): identifica os documentos e os recursos
armazenados como parte da Web;
Hyper Text Transfer Protocol (HTTP): responsável pelas regras de interação
entre cliente (navegador) e servidor (servidor de aplicação).
Quando um navegador interage com um servidor da Web, os dois programas
seguem o protocolo HTTP. Esse protocolo permite a um navegador solicitar um item
específico, que o servidor então retorna. Para assegurar que navegadores e servidores
possam interoperar de forma não ambígua, o HTTP define o formato exato das requisições
enviadas de um navegador a um servidor, como também o formato das respostas que o
servidor retorna.
Destaca-se a importância do uso de ambiente Web na implementação deste
projeto: embora não se tenha a intenção de compará-lo com um Farm Management
Information System (FMIS), reconhece-se que há um estreito relacionamento com o tema.
Nikkilä Seilonen e Koskinen (2010) afirmam que, enquanto as aplicações Web são
consideradas o futuro dos FMIS, essas aplicações ainda são muito raras comparadas aos
tradicionais FMIS implementados em ambientes on-site. Muitos dos FMIS serão baseados
24
em algum tipo de serviço Web. Assim, espera-se que o uso desse tipo de arquitetura
contribua de alguma forma com a evolução dos mais variados sistemas que auxiliam nos
processos agrícolas.
Um serviço Web, segundo Couloris et al. (2013), fornece uma interface de serviço
formatada em XML sobre o protocolo HTTP, onde os clientes podem executar operações
por meio de requisições e respostas. Assim, o cliente específico da aplicação interage pela
internet com um serviço que possui uma interface funcionalmente especializada.
De forma simplificada, Shi (2013) enquadra os Web Services como uma solução
tecnológica para a interoperabilidade de software que suporta a integração de diversos tipos
de aplicações sob uma rede de computadores.
Burke (2007) afirma que os Web Services são aplicativos de rede que fazem a troca
de dados baseando-se em documentos XML. Nesse caso, se tem um procedimento do lado
servidor, que é invocado pelo cliente (que pode ser um dispositivo móvel). Os
procedimentos (métodos) que podem ser acessados são publicados com uma estrutura
definida. Essa estrutura determina os argumentos necessários para sua execução e o
retorno do método.
Para Lacheta (2010), um Web Service é uma das tecnologias mais utilizadas
atualmente para efetuar a integração de sistemas. Kaivosoja et al. (2014) também sustenta
que Web Service permitem a troca de informações sob demanda entre sistemas
distribuídos. Coulouris et al. (2013) corrobora dizendo que os serviços Web estão cada vez
mais importantes nos sistemas distribuídos.
O presente projeto utiliza implementações de Web Services para transmissão de
dados entre o aplicativo móvel e o servidor de aplicações.
25
4 MATERIAL E MÉTODOS
4.1 Caracterização dos requisitos
Os requisitos utilizados para especificar os softwares denominados wGCGEO– para
a gestão Web – e mGCGEO – para a gestão Mobile – foram coletados por meio de
entrevistas informais com pesquisadores do GeoLab, da UNIOESTE, campus de Cascavel.
Inicialmente, foram demonstradas as dificuldades encontradas, por parte dos
pesquisadores, no gerenciamento dos dados das pesquisas, especificamente naquelas
relacionadas ao acompanhamento da Agricultura Familiar, desenvolvidas no município de
Salto do Lontra, Paraná, Brasil. A Figura 9 refere-se à localização geográfica do município
em que ocorreu o desenvolvimento das atividades dos pesquisadores do GeoLab.
Figura 9 Localização do município de Salto do Lontra Fonte: Wrublack et al.(2011).
Durante as entrevistas, foram vistoriados arquivos de planilhas eletrônicas,
disponíveis nos APÊNDICES I, II, III e IV, com o conteúdo das coletas de dados já
realizadas, os quais continham informações acerca das propriedades rurais amostradas. Do
conjunto de informações presente nos arquivos, cabe destacar:
Coordenadas geográficas das propriedades;
Tipo de solo presente;
Área total e área irrigada;
Uso e ocupação do solo;
Dados da qualidade da água;
Dados da qualidade do solo.
O conjunto de planilhas fornecidas contribuiu para a criação do modelo de dados
adequado às necessidades informacionais das pesquisas que estão sendo conduzidas.
26
Estruturadas, as informações permitem o compartilhamento e gerenciamento por meio da
plataforma construída.
Para guiar o desenvolvimento do projeto, utilizou-se como metodologia o RUP.
Essa metodologia permite atribuir tarefas e responsabilidades, de forma disciplinada, dentro
do contexto da engenharia de software.
A primeira etapa realizada, após coleta de informações, arquivos e entrevista, foi a
especificação dos requisitos, os quais podem ser classificados em funcionais (o que o
sistema deve fazer) e não funcionais (restrições de como deverá desempenhar suas
funções) (BOOCH; RUMBAUGH; JACOBSON, 2000). O Quadro 3 apresenta o
detalhamento, sendo que foram identificados os seguintes requisitos para o presente
projeto:
Manter propriedade rural (F1);
Manter produtor rural (F2);
Manter dados da qualidade da água (F3);
Manter dados da qualidade do solo (F4);
Manter dados do uso e ocupação do solo (F5);
Acesso Web (F6);
Ferramenta de coleta móvel (F7);
Interface com SIG (F8);
Relatório de análises.
Quadro 3 Detalhamento dos Requisitos do software
Requisitos funcionais
F1 – Manter propriedade rural ( ) Oculto
Descrição: Todas as ações das pesquisas têm como cerne o acompanhamento das
propriedades rurais do Programa de Agricultura Familiar. São informações pertinentes o proprietário, a localização e a área.
F2 – Manter produtor rural ( ) Oculto
Descrição: O produtor rural é o proprietário das terras onde os estudos estão sendo realizados. Portanto, é necessário dispor de informações tais como seu nome, sobrenome, telefone, entre outras, para relacionamento e contato.
F3 – Manter dados da qualidade da água ( ) Oculto
Descrição: O acompanhamento da qualidade da água nas propriedades é prioridade para
os pesquisadores. Informações físicas e químicas são analisadas e comparadas para identificação de melhora nos índices e, eventualmente, ações corretivas e preventivas na manutenção dos recursos hídricos.
F4 – Manter dados da qualidade do solo ( ) Oculto
Descrição: O acompanhamento da qualidade do solo permite aos pesquisadores orientar
os agricultores quanto ao manejo e adubação necessária para as culturas por eles produzidas.
27
4.2 Casos de Uso
Os casos de uso apresentam os aspectos dinâmicos do sistema e a interação que
existe entre seu comportamento perante os usuários ou outros sistemas (atores). O
diagrama de casos de uso para o projeto proposto é apresentado na Figura 10. Nele são
definidas as principais operações (caso de uso – elipses) e os atores responsáveis por
executá-las.
F5 – Manter dados do uso e ocupação do solo ( ) Oculto
Descrição: É importante para os pesquisadores saberem exatamente quais são as culturas produzidas em cada uma das propriedades e o quanto elas representam da área do produtor.
F6 – Acesso Web ( ) Oculto
Descrição: O acesso Web prevê que o sistema possa ser acessado por um navegador, dispensando assim a instalação do software no computador do usuário, o que facilita sua distribuição.
Requisitos não funcionais
Nome Restrição Categoria Desejável Permanente
NF6.1 Navegador
Deve ser compatível com navegadores atuais.
Compatibilidade ( ) ( X )
F7 – Ferramenta de coleta móvel ( ) Oculto
Descrição: A coleta dos dados que não dependem de análise laboratorial deve ser
realizada por aplicativo móvel e inserida no sistema por meio de uma plataforma de sincronização.
Nome Restrição Categoria Desejável Permanente
NF7.1
Plataforma
Deve ser compatível com dispositivos que executam o sistema operacional Android.
Compatibilidade ( ) ( X )
F8 – Interface com SIG ( ) Oculto
Descrição: A plataforma a ser desenvolvida deverá gerar dados que possam ser utilizados
por Sistemas de Informação Geográficas como QuantumGIS.
F9 – Relatório de análises ( ) Oculto
Descrição: O sistema deverá prover dados acerca dos resultados das amostras inseridas
no banco de dados.
28
Figura 10 Diagrama de casos e uso do sistema wGCGEO.
Observa-se, ainda na Figura 10, que existem basicamente três atores: o usuário,
responsável pelos cadastros necessários para o funcionamento do sistema; o pesquisador,
que executará a coleta dos dados; e o sistema de informação gerencial apropriado, com que
o pesquisador fará a interface. Esses atores relacionam-se com os casos de uso.
4.3 Diagrama do banco de dados
O modelo relacional do banco de dados (Figura 11) especifica todas as entidades,
os atributos e os relacionamentos. Por meio dele, é possível observar a demanda de
informações que o sistema exige e como é estruturado o armazenamento dos dados do
ponto de vista lógico.
As relações “projetopesquisa”, “propriedade” e “pessoa” são as principais tabelas
do modelo. Aliadas aos dados das análises, que são armazenados dependendo do tipo de
dado de que a característica necessita, fazem com que haja flexibilidade suficiente para
armazenar praticamente todos os diferentes tipos de informações que foram levantados nas
entrevistas.
29
Figura 11 Modelo Relacional do aplicativo Web proposto
30
4.4 Arquitetura do sistema
Aliado ao processo de desenvolvimento RUP, que prevê a especificação dos casos
de uso, definidos na UML, este projeto utilizará o padrão arquitetural Model-View-Controller
(MVC). Tal padrão é útil para representar vários tipos de aplicações de software (ZAPATA;
CHAVERRA, 2012).
O MVC apresenta como vantagens o gerenciamento da complexidade dos dados
armazenados e sua interação com o usuário. Os dados armazenados são qualificados como
Model. As operações que restam para iteração com os dados são a entrada (atribuída ao
controller) e a saída (atribuída à view). Assim, o MVC separa os dados contidos em outras
camadas do software, com o intuito de melhorar a organização e permitir maior
escalabilidade (MAGELA, 2006). Na sequência, a Figura 12 exemplifica a arquitetura do
sistema.
Figura 12 Arquitetura do sistema
Como o software executa em ambiente Web, têm-se dois locais de processamento
para cada aplicação: o lado cliente é o navegador do usuário; e o lado servidor é o servidor
de aplicação onde o sistema fica hospedado. Para o aplicativo móvel, o lado cliente é a
aplicação que irá executar no smartphone ou tablete; o lado servidor continua sendo o
servidor de aplicação, que dessa vez oferecerá um serviço (Web Service) para consumo.
No lado cliente da aplicação Web, não haverá necessidade de plug-ins ou outro
software específico além do navegador, que será responsável por exibir as telas do sistema,
como está definido na camada de visualização. O modelo mantém a estrutura de dados,
com as classes e os atributos. Por sua vez, o controlador faz a comunicação dos dados da
31
visualização com o modelo e, ao ser acionada alguma função para salvar os registros, o
controlador executa a persistência dos dados utilizando a Java Persistence API (JPA).
Por fim, utilizando-se de conexão de internet, o aplicativo móvel fará a requisição de
um serviço que estará disponível no servidor de aplicação. Esse serviço fornecerá as
informações necessárias para o trabalho remoto. Quando o trabalho remoto se encerrar,
ocorrerá o envio dos dados novamente para o servidor de aplicação, que será responsável
por alimentar o banco de dados com as informações coletadas.
4.5 Tecnologias e ferramentas utilizadas
Para desenvolver esse ambiente, necessita-se de ferramentas computacionais. A
plataforma Java foi elencada como padrão de desenvolvimento. No desenvolvimento da
camada de visualização, a ser operada pelo usuário, foi utilizada a tecnologia Java Serve
Faces (JSF). No lado servidor, todo o processamento e controle é realizado pelo servidor de
aplicação Glassfish 4, que hospeda um aplicativo Web desenvolvido na plataforma Java8. A
organização, o armazenamento e a consulta dos dados são realizados por meio do Sistema
Gerenciador de Banco de Dados PostgreSQL 9.4.
4.5.1 Java
Atualmente pertencente à empresa Oracle, a plataforma de programação
denominada Java é composta por uma linguagem de programação e um ambiente para
execução dos programas (máquina virtual). Diferentemente das tecnologias tradicionais,
como NET, que compila o programa para uma plataforma alvo, Java é considerada
multiplataforma (RAO, GEETHA, MAÍTI, 2014), pois o programa escrito pode ser executado
em mais de um sistema operacional, devido à máquina virtual Java (JVM).
Como pode ser observado na Figura 13, após ser escrito, o programa Java (Java
code) passa por um processo de compilação (JAVAC), gerando, assim, um código
intermediário chamado bytecode. Esse bytecode é interpretado pela máquina virtual Java,
que pode estar presente em qualquer sistema operacional, e então o código executável
(binário) para àquele sistema operacional é gerado (SANTOS, 2011).
32
Figura 13 Compilação e execução de um programa Java Fonte: Adaptado de Santos (2012).
Além da vantagem de ser multiplataforma, a tecnologia Java é gratuita, não
havendo necessidade de dispensar recursos no licenciamento para uso da plataforma.
Utilizou-se para o desenvolvimento desse projeto a versão 8 da plataforma Java.
4.5.1.1 Java Server Faces
JSF é uma tecnologia utilizada na criação de aplicativos Java para Web que se
baseia em Servlets (são classes Java que executam em um servidor de aplicação, chamado
Container Web) e também em Java Server Pages (JSP), sendo essa tecnologia introduzida
em 1996 pela Sun Microsystems, que permitia usar páginas HTML estáticas com conteúdo
dinâmico, concedendo ao programador o direito de utilizar lógica de programação dentro de
páginas HTML. O uso de JSF potencializa o desenvolvimento fornecendo componentes de
interface de usuário, regras de navegação entre as páginas, validadores de dados,
manipulação de eventos e dá suporte à internacionalização de sistemas (KURNIAWAN,
2004).
4.5.1.2 Java Persistence API e Hibernate
A tarefa de se armazenar em bancos de dados relacionais informações oriundas de
sistemas orientados a objetos possui grande repercussão no mundo Java. De forma
bastante trabalhosa, há a possibilidade de se escrever todas as instruções para criar, editar,
33
consultar e excluir dados do banco de dados, entretanto existe a solução de mapeamento
objeto-relacional (cuja sigla, ORM, advém do inglês Object/Relational Mapping), que é bem
aceita (HIBERNATE, 2015).
O mapeamento objeto-relacional determina a automatização da persistência dos
dados de objetos para um banco relacional. Para padronizar esse tipo de mapeamento, foi
criada uma especificação Java: Java Specification Request (JSR220) (JCP, 2015).
A Java Persistence API é a segunda parte de uma especificação JSR220, que trata
exclusivamente da persistência de objetos. Ela garante que todas as bibliotecas que tenham
a finalidade de armazenar objetos em bancos de dados sejam aderentes à especificação.
Assim, a especificação determina entidades, metadados do mapeamento objeto-relacional e
interfaces para gerenciamento.
Com o uso da especificação, qualquer instituição poderá construir sua biblioteca de
persistência. Neste projeto, foi utilizada a biblioteca Hibernate, que provê um serviço para
persistência e uma linguagem de consulta chamada HQL. O mapeamento das entidades
para as tabelas pode ser feito via arquivo XML ou por meio de Annotations – espécie de
tags que ficam no código fonte e são responsáveis por determinar o mapeamento (BAUER;
KING, 2007).
4.5.2 Glassfish
Um servidor de aplicação é um software especial que hospeda aplicativos e realiza
o gerenciamento das requisições aos aplicativos lá hospedados. O servidor também pode
implementar diversos protocolos de comunicação e consequentemente garante segurança,
disponibilidade e estabilidade aos programas hospedados.
Assim, no desenvolvimento deste projeto, utilizou-se o servidor de aplicação
Glassfish, versão 4.0, para hospedar o sistema. A vantagem desse servidor de aplicação é
devida a sua classificação como open-source e sua compatibilidade com a tecnologia Java
(ORACLE, 2013).
4.5.3 Ambiente de Desenvolvimento
Um Ambiente Integrado de Desenvolvimento (cuja sigla, IDE, advém do inglês
Integrated Development Environment) reúne em uma única ferramenta um conjunto de
componentes que facilitam o processo de desenvolvimento do software. Esses ambientes
proporcionam a escrita, a execução, os testes, o versionamento e a documentação, além de
outras atividades inerentes à construção de um software.
34
4.5.3.1 NetBeans
NetBeans é uma IDE para programação de aplicativos que permite
desenvolvimento rápido de aplicativos móveis, desktop e Web. Por tratar-se de uma
ferramenta de código aberto, possui uma extensa comunidade de usuários e
desenvolvedores ao redor do mundo, o que se deve também a seu suporte, com as várias
linguagens de programação, entre as quais se encontra a linguagem Java (NETBEANS,
2015).
Sendo assim, essa IDE foi utilizada para a criação do Sistema Web e uma
biblioteca de classes comum aos aplicativos Web e Mobile. A versão da ferramenta que foi
empregada é 8.0.1.
4.5.3.2 Eclipse
Eclipse também é uma IDE para programação de aplicativos e uma das mais
famosas para desenvolvimento na plataforma Java. Ela provê o uso de outras linguagens de
programação e até permite estender a ferramenta para outras funções (ECLIPSE, 2015).
A IDE Eclipse foi utilizada para o desenvolvimento do aplicativo móvel, visto que
favorece essa atividade ofertando o plugin Eclipse Android Development Tools (ADT), que
agrega um conjunto de componentes para programação para dispositivos Android. A versão
utilizada no desenvolvimento foi Eclipse Kepler.
4.5.4 PostgreSQL
O PostgreSQL, versão 9.4, foi utilizado neste projeto e refere-se a um banco de
dados objeto-relacional, desenvolvido sob a ideologia do software livre (MILANI, 2008). Ele
se originou a partir de um projeto de pesquisa da Universidade da Califórnia, mas
atualmente está a cargo do PostgreSQL Global Development Group (AGUILERA, GARCÍA,
2011).
Optou-se por esse sistema de banco de dados, por ser considerado o banco de
dados de código aberto mais avançado do mundo, pois suporta a grande maioria das
implementações SQL (Structured Query Language), controle de concorrência, consultas
complexas, gatilhos, visões, integridade transacional e permite agregar extensões, tipos de
dados, funções, operadores e linguagens procedurais (ARANDA; SOTOLONGO, 2013).
35
Uma das extensões que se destaca é a PostGIS, por ser responsável por fornecer
características espaciais ao banco de dados, permitindo o armazenamento eficaz desses
complexos objetos.
4.5.5 Leaflet JS
Para realizar a geração do mapa interativo, foi utilizada uma biblioteca de mapas
gratuita chamada Leaflet. Essa biblioteca é um componente de software para criação de
mapas interativos. Os dados armazenados no banco de dados espacial PostGIS são
convertidos em objetos javascript e enviados para a biblioteca. Segundo Leaflet (2015), essa
biblioteca apresenta vantagem no uso de recursos como HTML5 e CSS3 para prover
simplicidade, performance e usabilidade aos mapas interativos.
4.6 Fluxo das atividades
As atividades do sistema são execuções em andamento que resultam em alguma
ação (BOOCH; RUMBAUGH; JACOBSON, 2000). No fluxo macro das atividades do sistema
(Figura 14), observa-se que a primeira etapa para operacionalização do sistema é a
realização dos cadastros básicos. Esses cadastros envolvem: propriedades, pessoas
(proprietários, pesquisadores), municípios, estados e culturas. Assim, com essas
informações armazenadas no sistema, pode-se criar o projeto da pesquisa.
O projeto também permitirá análise de cronograma, avaliação de custos e definição
dos colaboradores e os vinculará às propriedades onde será executado. Não foram
discutidos detalhes de cada uma das atividades; porém, se espera que a Figura 14
esclareça ao leitor o fluxo de funcionamento do sistema, com as fases necessárias para que
se possa operar a plataforma. Maiores informações a respeito serão apresentadas no
capítulo Resultados e Discussão.
Figura 14 Fluxo das atividades em visão macro
36
Ainda na Figura 14, verifica-se a possibilidade de efetuar coleta de informações por
meio de ambiente móvel. Desse modo, inicia-se um novo processo, que é recebimento dos
dados do projeto no dispositivo, realização da coleta dos dados utilizando-se desse mesmo
dispositivo e, ao término, encaminhamento dos dados para a plataforma, por meio da
sincronização. Caso não seja utilizado dispositivo móvel, os pesquisadores poderão lançar
os dados diretamente pelo sistema Web, utilizando interfaces apropriadas para tal.
4.7 Testes
Os testes do software devem ser compreendidos como uma fase inerente ao
processo de desenvolvimento, uma vez que asseguram que o desenvolvimento do software
está de acordo com a especificação dos casos de uso.
Para realizar os testes, foram criados Planos de Testes que formalizam a atividade
para obter um resultado eficiente. Assim, essa essencial tarefa não é executada
aleatoriamente “sem critério”. Destaca-se que algumas etapas, tais como a rotina de
cadastro de propriedades, foram importantes para construir o plano de teste (ANDRADE;
VIANA, 2012).
Os testes ficaram sob responsabilidade de alunos do GEOLAB, que definiram se o
software desenvolvido atendia os requisitos especificados.
A primeira etapa para a realização dos testes é especificar o caso de teste. Nesse
momento, devem-se definir os dados de entrada e os resultados esperados após a
execução. O Quadro 4 demonstra o caso de teste para cadastrar uma propriedade.
Quadro 4 Caso de Teste CT1 – Cadastrar Propriedade
Código CT1
Objetivo Permitir o cadastramento de uma nova propriedade
Atores Usuário/Pesquisador
Condição de Entrada O ator aciona o menu para acesso às propriedades
Fluxo Principal 1. O sistema apresenta a lista de propriedades existente. 2. No rodapé da página será exibido o botão INSERIR. 3. Ao acionar o botão Inserir será exibido um formulário com os dados da nova
propriedade.
4. O ator informa os dados da propriedade, inclusive seu código de identificação, que já foi determinado.
5. O ator aciona o botão Salvar [A1].
Fluxo Alternativo [A1] O ator pressiona o botão Cancelar. O sistema fecha o formulário. Retorna para a lista de propriedades sem modificações.
Regras de Negócio 1. O Proprietário deve estar previamente cadastrado. 2. O Município deve estar previamente cadastrado.
Depois de estruturar o caso de teste, a etapa seguinte é o Procedimento de Teste.
Por exemplo, avaliou-se o preenchimento de campos obrigatórios no formulário de cadastro
37
de propriedades. No Quadro 5, é possível observar que a pessoa responsável pelo teste
terá em mãos as informações necessárias para proceder ao teste e poderá determinar se o
comportamento do software está condizente com o esperado pelo procedimento de teste.
Quadro 5 Procedimento de teste
Item Descrição
ID do caso de teste CT1.
Descrição Testar valores não preenchidos nos campos
Item a ser testado Manter Propriedade.
Características testadas Funcionalidade.
Entradas Código da propriedade vazio. Salvar propriedade.
Resultados e comportamentos esperados Aviso em tela de que é necessário informar o valor do campo.
Necessidades do ambiente de teste. Navegador Web recente.
Após realização de todos os procedimentos de teste, avalia-se em que proporção o
software está correto em relação aos requisitos e casos de uso. O objetivo dos testes não é
corrigir erros e sim encontrá-los, para que possam ser corrigidos.
38
5 RESULTADOS E DISCUSSÃO
O resultado deste trabalho é uma plataforma de software desenvolvida para gestão
das informações coletadas no projeto SIG na Agricultura Familiar, do GeoLab da
UNIOESTE, campus de Cascavel. Esse software recebe o nome de wGCGEO. Assim, este
capítulo apresentará o funcionamento da ferramenta.
5.1 Operação do sistema no ambiente Web
O primeiro passo para acessar o sistema é realizar o login, utilizando-se da tela de
acesso conforme demonstrado na Figura 15a. O login deve ser realizado por meio de
usuário previamente cadastrado, sendo que no momento da implantação o administrador do
sistema criará os usuários necessários para acesso.
Figura 15 Tela de acesso do login (a) e menu principal para acesso às rotinas do sistema (b)
Após o processo de validação do usuário, será exibida a tela principal do sistema,
com o menu para acesso às funções (Figura 15b). O menu “Cadastros” permite ao usuário
cadastrar as propriedades, características, culturas, pessoas, municípios, estados e
usuários. Já o acesso aos projetos e as rotas de coleta são realizadas pelo menu “Projeto”.
A relação de análises executadas é emitida pelo menu “Relatórios”.
Toda a coleta de dados está vinculada ao projeto de pesquisa. Entretanto, para que
um projeto possa ser criado, deve-se primeiramente ter as informações das propriedades e
características que serão avaliadas.
A propriedade diz respeito à área onde é realizada a coleta. No Projeto SIG para
Agricultura Familiar, 57 propriedades são monitoradas. Assim, foi realizado o cadastramento
de cada uma das propriedades por meio do menu “Cadastros” “Propriedades”.
A Figura 16 demonstra a lista de propriedades com as informações já existentes no
banco de dados e que se tornam disponíveis nos botões de ação para: incluir, visualizar,
editar e excluir a informação. Em alguns casos, botões adicionais são exibidos para funções
específicas, mas todos os cadastros do sistema seguem o mesmo padrão.
a)
b)
39
Figura 16 Lista de propriedades monitoradas no projeto.
Ao acionar o botão “Incluir” (Figura 16), um formulário com os dados da nova
propriedade é exibido (Figura 17). O usuário deverá preencher os campos requisitados e
pressionar o botão “Salvar’. Caso deseje cancelar o cadastramento, o usuário deverá
acionar o botão “Cancelar”.
Figura 17 Interface para inclusão de nova propriedade no sistema
O botão “Shape” (Figura 16) permite ao usuário incluir dados de GPS para a
propriedade. Todas as propriedades tiveram seus polígonos mapeados, e essa informação é
importante para localizá-las. Ao ser acionado o botão “Shape”, uma janela com a
possibilidade de upload de um arquivo é exibida (Figura 18) indicando que o sistema está
preparado para ler um arquivo empacotado (zip) contendo as extensão: .dbf, .shp e .shx. O
40
sistema irá desempacotar o arquivo e proceder à importação dos dados espaciais usando o
utilitário shp2pgsql, disponível na extensão PostGIS do banco de dados PostgreSQL.
Figura 18 Upload de arquivo do polígono de uma área de interesse.
No momento de incluir uma propriedade, são solicitados dados como localização,
proprietário, município, para permitir o cadastramento. Posteriormente, esse cadastro
poderá ser complementado selecionando-se a propriedade na lista e acionando-se o botão
“Editar”. Nesse momento, duas novas páginas (Figuras 19 e 20) aparecem para
complemento de informações.
Na Figura 19, observa-se em destaque a página “Pontos”, que permite aos
pesquisadores adicionar os pontos de coleta de informação dentro da propriedade. Os
pontos poderão ser definidos também pela ferramenta móvel, conforme será apresentado na
próxima seção.
41
Figura 19 Definição dos pontos de coleta na propriedade.
Outra informação pertinente diz respeito ao uso e à ocupação do solo. Com o
passar dos anos, haverá um histórico para analisar o comportamento do proprietário em
relação às culturas que foram cultivadas em sua propriedade, conforme se observa na
Figura 20.
Figura 20 Uso e ocupação do solo da propriedade estudada.
No sistema desenvolvido, o item “Características” consiste em elementos que
devem ter informações coletadas dentro de um projeto, conforme demonstra a Figura 21.
42
Figura 21 Lista de características disponíveis para coleta.
A Figura 22 exemplifica uma característica criada para os dados referente a
coliformes fecais presentes na água. Durante esse processo de criação, é necessário
determinar de que tipo de dado se trata (dado numérico, por exemplo), o tipo da
característica e também se consiste em uma variável qualitativa ou quantitativa.
Figura 22 Interface para edição de características.
Observa-se, ainda na Figura 22, a presença do atributo “Coleta Mobile”. Esse
atributo indica que a característica em questão poderá ser coletada via aplicativo móvel.
43
No entanto, antes de os pesquisadores procederem à coleta, deve-se previamente
determinar o itinerário para otimizar seu tempo em campo; logo, a ordem de visita das
propriedades é de suma importância. Esse itinerário é especificado por uma rota e dentro de
cada rota são atribuídas as propriedades que serão visitadas.
Para auxiliar também nesse processo, é possível realizar o cadastramento das
rotas no sistema (Figura 23). As rotas normalmente agrupam as propriedades de uma
mesma comunidade ou de comunidades vizinhas. Vale lembrar que as funções: “Incluir”,
“Editar”, “Visualizar” e “Excluir” estão disponíveis nesse item.
Figura 23 Listagem de rotas que poderão ser estabelecidas.
Ao se editar uma rota, é possível definir as propriedades que serão visitadas,
conforme demonstrado na Figura 24. A Figura 24a (destacada com elipse vermelha) contém
as propriedades disponíveis para serem incluídas na rota. Já a Figura 24b (destacada com a
elipse verde) contém as propriedades selecionadas para aquela rota. Para remover a
propriedade da rota, basta selecioná-la e pressionar o botão “Remover da Rota”.
Para determinar a ordem da coleta, a Figura 24b é implementada para que o
usuário possa utilizar a técnica de drag-and-drop, que permite a ordenação das linhas
apenas arrastando-as para cima ou para baixo. Após determinar a ordem da rota, o usuário
poderá clicar em “Salvar”, que está localizado na página “Dados da Rota”, destacado na
Figura 24.
44
Figura 24 Propriedades de uma determinada rota simulada. A elipse vermelha destaca as propriedades disponíveis. A elipse verde destaca as propriedades incluídas na rota.
Ressalta-se que cada projeto contém um grupo comum de informações que são
coletadas; sendo assim, para armazenar as informações, o projeto de pesquisa também
deve ser previamente cadastrado. A Figura 25 exemplifica o cadastro de dois projetos
distintos – um projeto gerenciará os dados de qualidade da água e outro projeto se voltará
aos dados do solo.
Figura 25 Lista de projetos monitorados pelos pesquisadores.
Na Figura 26, observam-se os atributos disponíveis no projeto, visto que cada
projeto de pesquisa possui suas características, é identificado por um código sequencial e
apresenta algumas informações para controle, como datas de início e término, orçamento e
escopo. Essas não são informações obrigatórias, mas poderão ser úteis para o
a b)
45
gerenciamento do projeto como um todo. Quando uma informação obrigatória não for
preenchida, o sistema irá destacar o campo para que o usuário proceda ao preenchimento.
Figura 26 Detalhes do projeto “GEOLAB – COLETA DE DADOS DO SOLO”
Um projeto de pesquisa é composto por atividades que permitem ao gestor do
projeto avaliar o andamento com o intuito de manter o orçamento e os prazos de início e
término, por exemplo. Se houver a necessidade de se definir as tarefas do projeto, a página
“Atividades” proverá esse recurso (Figura 27). É possível adicionar diversas atividades e em
cada uma delas inserir informações de controle, como datas de início e término, bem como
orçamento e custos.
Figura 27 Atividades que serão executadas em um projeto.
46
Cada projeto possui suas próprias características, que deverão ser coletadas.
Portanto, a guia “Características” possibilita ao pesquisador determinar as variáveis
importantes para a coleta naquele projeto (Figura 28). A utilização é simples, basta
selecionar a característica disponível (destacado pelo retângulo marrom) e pressionar o
botão adicionar. Para remover a característica do projeto, basta selecioná-la na lista de
características e pressionar o botão “Remover”.
Figura 28 Características selecionadas para serem coletadas pelo projeto.
As coletas de dados serão realizadas nas propriedades previamente cadastradas
sendo necessário relacionar ao projeto todas as propriedades que irão compor os dados.
Assim, a Figura 29 demonstra como o usuário poderá relacionar as propriedades ao projeto
e similar as características ao projeto descrito anteriormente. As propriedades disponíveis
são listadas em uma caixa de seleção, onde o usuário irá definir a propriedade que deseja
adicionar ao projeto e pressionará o botão “Adicionar”. Caso a intenção seja remover uma
propriedade, o usuário deverá localizá-la na lista de propriedades já incluídas e pressionar o
botão “Remover”.
47
Figura 29 Propriedades que serão estudadas e foram incluídas no projeto.
Com esse conjunto de informações determinado, é possível adicionar os dados das
coletas pelo próprio sistema Web por meio da tela inicial do sistema ou pelo mapa com as
propriedades que tiveram os polígonos salvos.
A Figura 30 ilustra o mapa geográfico interativo das propriedades rurais. Na Figura
30b, há uma seção de filtros, que permite ao usuário realizar uma busca conforme os
critérios que ele desejar. É possível especificar algumas propriedades, buscar propriedades
pelo tipo de captação, criar intervalos de área ou área irrigada para selecionar. Ainda, de
acordo com o uso e a ocupação do solo, é possível, por exemplo, selecionar as
propriedades que têm atividade de fruticultura. Na Figura 30a, as propriedades têm seus
polígonos destacados em azul. Como mencionado anteriormente, o mapa é interativo; isso
significa que o usuário terá opções de movimentá-lo, utilizar zoom e interagir com as
propriedades.
48
Figura 30 Tela principal do sistema. Demonstra as propriedades estudadas em um mapa que foi criado por meio dos polígonos importados. Fonte: Mapa criado sobre plataforma Leafletjs utilizando os dados do Laboratório de Topografia e Geoprocessamento da UNIOESTE, campus de Cascavel.
49
Quando uma propriedade é selecionada no mapa, uma janela popup (Figura 31) é
exibida, contendo os dados da propriedade (nome e localidade) e um botão para que o
usuário possa inserir os dados das análises realizadas.
Figura 31 Janela popup exibida no momento do clique em uma propriedade.
Quando o usuário pressiona o botão “Análises”, uma nova janela com as análises já
realizadas é ativada (Figura 32). O usuário poderá selecionar o projeto que deseja visualizar
ou incluir uma nova análise. Cada análise possui informações de todas as características do
projeto. Assim, basta incluir uma nova análise ou editar os dados de uma análise
selecionada na lista para ver quais são as características que devem ser informadas.
Figura 32 Análises executadas na propriedade.
Ao editar uma análise, todas as características do projeto selecionado são
dinamicamente adicionadas ao quadro de resultados. Essa possibilidade de edição e
alteração de características conforme necessidade de cada projeto fornece grande
flexibilidade ao sistema. Com isso, o pesquisador terá a capacidade de definir quais
50
informações são realmente importantes para armazenar, e consequentemente a interface
não ficará sobrecarregada com campos inutilizados. O retângulo em vermelho na Figura 33
destaca os campos que foram criados de forma dinâmica. Nele, são apresentadas as
características adicionadas ao Projeto 2 – Coleta de dados do Solo.
Figura 33 Campos que são montados para serem preenchidos no momento do lançamento dos dados da análise.
Os dados armazenados pelo sistema formam um banco de dados rico em
informações para os pesquisadores, o que possibilitar realizar análises estatísticas, verificar
comportamentos e orientar os produtores rurais participantes do projeto em relação às suas
práticas para preservação dos recursos hídricos de suas propriedades.
Além de se visualizar as informações inseridas no sistema, há a possibilidade de
extrair os dados do sistema e gerar planilhas eletrônicas para utilizar esses dados em outras
ferramentas.
O relatório de análises (Figura 34) apresenta diversos critérios de busca dos dados
para minimizar seu conjunto de informações, a fim de tornar a consulta realizada pelo
pesquisador mais assertiva.
51
Figura 34 Tela para emissão do relatório de análises do sistema wGCGEO.
O resultado do processamento desse relatório é uma planilha eletrônica (Figura 35),
que contém duas dimensões, fazendo com que as informações sejam acrescidas para
baixo, conforme a quantidade de análises e ao mesmo tempo sejam criadas novas colunas,
cada uma de acordo com as características do projeto.
Figura 35 Planilha de dados gerada pelo sistema wGCGEO.
Algumas dessas características possuem resoluções que determinam os limites
inferiores e superiores para considerar aquele parâmetro normal. Conforme Brasil (2005), a
Tabela 1 apresenta os limites para algumas das características que são controladas pelo
sistema.
52
Quadro 6 Limites dos Parâmetros para avaliação da qualidade da água
Característica Limites
pH 6,5-8,4
CE 0 – 3,0 dS / m
Bicarbonato 0 – 10 meq / L
Cloro 0 – 30 meq / L
Fosfato 0 – 2 mg / L
Nitrato 0 – 10 mg / L
Turbidez 100 UNT
Coliformes termotolerantes < 1.000 NMP / 100 mL
Fonte: Adaptado de WRUBLACK (2012).
Considerando que o sistema auxilia na agilidade pela busca das informações
armazenadas, também foi disponibilizada uma consulta para que o pesquisador tenha
destacadas no mapa apenas as propriedades que momentaneamente apresentaram uma
amostra fora dos limites da característica.
Figura 36 Consulta de propriedades. Filtro de características fora dos limites (a) e propriedade destacada no mapa (b).
Conforme se pode visualizar na Figura 36a, o pesquisador seleciona a
característica que o sistema deve avaliar e aplica seu filtro. Assim, o mapa exibirá apenas as
propriedades que se enquadram nessa avaliação, facilitando a busca por problemas. Nesse
caso, todas as propriedades exibidas (Figura 36b) estão com a característica “Coliformes
Fecais” fora dos padrões estabelecidos.
5.2 Operação do sistema na plataforma móvel
O sistema de coleta móvel mGCGEO é um sistema de apoio ao wGCGEO. Ele
recebe dados cadastrados na Web e permite a coleta de coordenadas geográficas, dados
de uso e ocupação do solo, além dos dados das características que não necessitam de
a)
b)
53
análise laboratorial. Após a primeira sincronização, o sistema trabalha off-line. Quando o
pesquisador obtiver acesso a uma rede wifi ou 3G, poderá enviar os dados coletados.
Para ter acesso aos dados, o usuário deverá realizar a primeira autenticação, que
verifica se o usuário e o aparelho podem acessar o sistema (Figura 37a).
O menu principal do sistema é bastante intuitivo e, por meio do uso de ícones
grandes, facilita o manuseio em campo. A Figura 37b demonstra o menu principal, em que o
usuário terá acesso aos dados de projetos, propriedades e pessoas cadastradas no sistema.
Também é possível coletar dados e efetuar a sincronização.
Figura 37 Interface inicial do sistema mGCGEO. Autenticação do usuário (a) e menu principal do sistema (b).
Ao acessar a opção “Projetos”, o usuário poderá visualizar a lista de projetos
existente (Figura 38). O projeto de pesquisa é o item que envolve um conjunto de
propriedades, características e permite realizar as análises, informando valores para cada
característica.
a) b)
54
Figura 38 Lista de projetos sincronizados pela Web.
Quando o usuário desejar exibir as propriedades, basta pressionar o botão
“Propriedades” no menu principal. Nesse momento, uma lista é formada, com a
possibilidade de busca e o detalhamento de cada propriedade rural, como é apresentado na
Figura 39a. No detalhamento da propriedade rural, existem opções para o usuário realizar
as coletas. As coordenadas geográficas da propriedade poderão ser atualizadas; basta o
usuário capturá-las e salvá-las. Assim, no momento de transmitir os dados, o sistema
enviará essas informações para o servidor.
Outra informação que auxilia no histórico de culturas existentes na propriedade é
acessada por meio do botão “Uso e ocupação”, apresentado na Figura 39b.
Figura 39 Interface do sistema mGCGEO. Lista de Propriedades disponíveis (a) e detalhes de uma propriedade selecionada (b).
b) a)
55
O acesso ao uso e ocupação demonstra uma lista que agrupa em um determinado
ano as culturas estabelecidas. A Figura 40a exemplifica as culturas da propriedade 1 e,
utilizando-se de dados fictícios, com o intuito de testar o aplicativo, observa-se que no ano
de 2014 havia pastagem e fumo, sem informações acerca da área plantada. Ainda, no ano
de 2015 a área era coberta por fruticultura. Já em 2016, olerícolas foram cultivadas. No ano
de 2017 novamente cultivou-se pasto, sendo 10 hectares não irrigados e 11 hectares
irrigados.
Como esse tipo de informação não depende de análise laboratorial, basta uma
entrevista com o proprietário ou observação da propriedade, sendo que os dados poderão
ser incluídos pelo aplicativo. Na Figura 40b, tem-se a interface de inclusão do uso e
ocupação. Após o preenchimento, as informações ficarão disponíveis para envio para o
servidor.
Figura 40 Interface do sistema mGCGEO. Lista de culturas (a) e incluir nova cultura (b).
A opção “Coletar” no menu principal (Figura 37) permite ao usuário duas novas
operações: visualizar as rotas que deverão ser seguidas para proceder à coleta e proceder à
coleta de características. Assim, na Figura 41a tem-se a lista de rotas disponíveis, na Figura
41b o detalhamento da rota e por fim a Figura 41c apresenta quais propriedades devem ser
visitadas.
a) b)
56
Figura 41 Interface o sistema mGCGEO. Menu de coleta (a), lista de rotas a serem cumpridas (b) e propriedades a serem visitadas naquela rota (c).
Ao acionar a opção “Coletar” (Figura 41a), o usuário poderá incluir dados das
características em uma propriedade para um determinado projeto. Quando um projeto é
selecionado, a lista de propriedades é apresentada e o usuário poderá selecionar a
propriedade onde a coleta está sendo realizada (Figura 42a). Após essa etapa, é
disponibilizada uma lista com as análises já realizadas (Figura 42b), mas o usuário também
poderá incluir uma nova análise acionado o botão “Incluir”. Por fim, é apresentada a tela
(Figura 42c) para “Adicionar” ou “Editar” a coleta.
Os campos na tela são criados dinamicamente, conforme as características
disponíveis no projeto. Assim, o sistema se adapta a diferentes tipos de coletas necessárias
durante as atividades de campo.
a) b) c)
57
Figura 42 Interface do sistema mGCGEO. Definição dos dados da coleta (a), lista de análises realizadas (b) e campos para inclusão dos dados da coleta (c).
Uma vez que os dados estejam armazenados no aparelho, é possível efetuar a
sincronização e enviar as informações para o servidor wGCGEO. O menu “Sincronizar”
realiza essa tarefa.
Percebe-se, na Figura 43a, que existem as opções para “Receber dados” e “Enviar
dados”. A opção de receber deve ser acionada toda vez que houver modificações no
projeto, nas propriedades ou características. Assim, os dados do servidor serão transmitidos
para o dispositivo móvel. Quando se envia os dados, os dados pendentes no dispositivo são
enviados ao servidor e ficarão disponíveis para os pesquisadores. Quando um processo de
sincronização é disparado, dependerá da rede de comunicação. Essa tarefa pode ser
demorada e o sistema ficará “bloqueado” para uso até que ela seja concluída, conforme se
visualiza na Figura 43b.
a)
b) c)
58
Figura 43 Interface de comunicação do sistema mGCGEO. Menu de sincronização (a) e progressão da transmissão no recebimento dos dados da Web (b).
a) b)
59
6 CONCLUSÃO
O auxílio de ferramentas de informática, para praticamente todas as áreas do
conhecimento, contribui para eficiência operacional e apoio à decisão. O presente projeto
permite um ambiente estruturado para armazenamento dos dados e possibilidade de extrair
informações sob demanda.
Ambos os aplicativos, Web e Mobile, foram desenvolvidos com vistas à demanda
específica do GeoLab da UNIOESTE, campus de Cascavel. Os requisitos que conduziram o
desenvolvimento foram levantados com os integrantes do Projeto SIG na Agricultura
Familiar.
Esses requisitos permitiram a criação de modelos que colaboraram no processo de
programação, tais como modelo do banco de dados e diagrama de casos de uso. Ainda, por
se tratar de uma ferramenta de código aberto, pequenas adaptações poderão torná-lo
utilizável por outros departamentos que possuem processos semelhantes.
A estrutura de banco de dados mostrou-se flexível para armazenar tipos diferentes
de variáveis, como valores inteiros, decimais, textos, lógicos, datas e tempos. Além disso, a
estrutura espacial permitiu o armazenamento dos contornos das propriedades de forma
satisfatória, conforme foi observado no mapa apresentado.
Os dados retroativos foram lançados no sistema em um ambiente disponibilizado
aos usuários e podem ser acessados diretamente pelo aplicativo, ou por qualquer outra
ferramenta que tenha comunicação com o banco de dados PostgreSQL. Inclusive,
ferramentas GIS, como Quantum GIS®, e ArcGIS®, podem fazer uso das informações
espaciais armazenadas, adicionando as propriedades como camadas em alguma
composição de mapas.
Considerando que inovação é a concepção de um novo produto/processo, que não
existia anteriormente ou era realizado de outra forma, e que proporciona benefícios aos
agentes envolvidos, esse trabalho traz inovações importantes na condução de pesquisas.
Para Reis (2008), as inovações podem envolver uma série de atividades científicas,
tecnológicas, organizacionais, financeiras e comerciais e, nesse mesmo sentido, a inovação
envolve não somente conhecimentos teóricos ou práticos num plano estritamente
tecnológico e científico, mas também organização e gestão.
Dessa forma, a propriedade intelectual está sendo protegida pelo registro do
software. Os dois softwares que resultaram desse trabalho estão em processo de registro e
já tiveram o aval positivo do NIT (Núcleo de Inovações Tecnológicas) da UNIOESTE, de
modo que contribuem com o catálogo de produtos tecnológicos da Instituição e elevam os
índices de inovação desta.
60
Indiretamente, o projeto contribuirá com o avanço da agricultura familiar na região
abrangida pelo programa. Incrementos nos índices de produção, bem como melhoria da
qualidade da água e solo, poderão beneficiar não apenas os pesquisadores, mas sim uma
grande e importante cadeia de produção.
Por fim, o projeto abrirá caminho às futuras implementações. O uso de tecnologias
emergentes aplicadas à análise dos dados armazenados, como pode-se citar, big data, são
soluções que poderão encontrar padrões e guiar as pesquisas para um novo patamar.
61
REFERÊNCIAS
AGUILERA, F. A. I.; GARCIA, M. L. D. RT-Postgresqt: Extensión de postgretol para manejo de datos con frecuencias temporales.UCT, Puerto Ordaz, v. 15, n. 60, Sept. 2011.
Disponível em: <http://www.scielo.org.ve/scielo.php?script=sci_arttext&pid=S1316-48212011000300003&lng=es&nrm=iso>. Acesso em: 29 abr. 2015. ALVES, W. P. Fundamentos de Bancos de Dados. São Paulo: Érica, 2004.
ANDRADE, A. P.; VIANA, P. Criação e geração de plano de testes de software. IBM
Developer Works. 2012. Disponível em: <http://www.ibm.com/developerworks/br/local/rational/criacao_geracao_planos_testes_software/>. Acesso em: 10 jun. 2015. ARANDA, Y. R.; SOTOLONGO, A. R. Integración de los algoritmos de minería de datos 1R, PRISM e ID3 a PostgreSQL. JISTEM J.Inf.Syst. Technol. Manag., São Paulo, v. 10, n. 2, p. 389-406, Ago. 2013. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1807-17752013000200389&lng=en&nrm=iso>. Acesso em: 29 abr. 2015. BALLON, P.; BOUWMAN, H.; YUAN, Y. Special Issue on Business Models for Mobile Platforms: Guest Editors’ Introduction. J. theor. appl. electron. commer. res., Talca, v. 6, n.
2, Ago. 2011. Disponível em: <http://www.scielo.cl/scielo.php?script=sci_arttext&pid=S0718-18762011000200004&lng=es&nrm=iso>. Acesso em: 29 abr. 2015. BAUER, C.; KING, G. Java Persistence com Hibernate. Rio de Janeiro. Ciência Moderna, 2007. BERTALANFFY, L. V. General System Theory. New York: George Brazziler, 1968.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.; UML, guia do usuário. Rio de Janeiro:
Campus, 2000. BRASIL. Ministério do Meio Ambiente. CONAMA – Conselho Nacional de Meio Ambiente. Dispõe sobre a classificação dos corpos de água e diretrizes ambientais para o seu enquadramento, bem como estabelece as condições e padrões de lançamento de efluentes, e dá outras providências. Resolução nº 357, de 17 de março de 2005. Disponível em:
<http://www.mma.gov.br/port/conama/legiabre.cfm?codlegi=459>. Acesso em: 15 abr. 2015. BURKE, B. Enterprise Java Beans 3.0. 5. ed. São Paulo: Pearson Prentice Hall, 2007. BURROUGH, P. A. Principles of Geographic Information Systems for Land Resource Assessment. Monographs on Soil and Resources Survey. N. 12. New York: Oxford Science Publications, 1986. CIDRAL, A.; AUDY, J. L. N; ANDRADE, G. K. Fundamentos de sistemas de informação.
Porto Alegre: Bookman, 2007. COMER, D. E. Redes de computadores e Internet. Porto Alegre: Bookman, 2001.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T.; BLAIR, G. Sistemas Distribuídos:
conceitos e projeto. Porto Alegre: Bookman, 2013. DATE, C. J. Introdução aos Sistemas de Bancos de Dados. Rio de Janeiro: Campus,
2003.
62
DUEKER, K. J. Land resources information systems: a review of fifteen years' experience. Technical Report nº 110, Institute of Urban and Regional Research, the
University of Iowa, Iowa, 1979. ECLIPSE. About the Eclipse Foundation. Disponível em: <http://eclipse.org/>. Acesso em:
10 mar. 2015. ELMASRI, R.; NAVATHE, S. B. Sistema de banco de dados. 4. ed. São Paulo: Pearson
Addison Wesley, 2005. GIL, F. B.; KOZIEVITCH, N. P.; TORRES, R. da S. GeoNote: a web service for geographic data annotation in biodiversity information systems. Journal of Information and Data Management, v. 2, n. 2, p. 195-210, jun. 2011. HIBERNATE. Hibernate ORM. Disponível em <http://hibernate.org/orm/>. Acesso em: 03
maio 2015. JCP. Java Specification Requests. JSR220: Enterprise Java Beans 3.0. Disponível em:
<https://jcp.org/en/jsr/detail?id=220>. Acesso em: 03 maio 2015. KAIVOSOJA, J.; JACKENKROLL, M.; LINKOLEHTO, R.; WEIS, M. GERHARDS, R. Automatic control of farming operations based on spatial web services. Computers and Electronics in Agriculture, v. 100, p. 110-115, 2014. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0168169913002731>. Acesso em: 10 jul. 2014. KROENKE, D. M. Bancos de dados: fundamentos, projeto e implementação. Rio de
Janeiro: LTC, 1998. KURNIAWAN, R. Programando em Java Server Faces. Rio de Janeiro: Ciência Moderna Ltda., 2004. LACHETA, R. R. Google Android: aprenda a criar aplicações para dispositivos móveis com o Android SDK. 2. ed. São Paulo: Novatec Editora, 2010. LARMAN, C. Utilizando UML e Padrões. Porto Alegre: Bookman, 2000. LAUDON, C. K.; LAUDON, P. J. Sistemas de Informação. 4. ed. Rio de Janeiro: LTC,
1999. LEAFLET. Overview. Disponível em: <http://leafletjs.com/>. Acesso em: 02 abr. 2015.
LONGLEY, P. A.; MAGUIRE, D. J.; GOODCHILD, M. F.; RHIND, D. W. Sistemas e ciência da informação Geográfica. 3. ed. Porto Alegre: Bookman, 2013.
MAGELA, R. Engenharia de software aplicada. Rio de Janeiro: Alta books, 2006.
MILANI, A. PostgreSQL: guia do programador. São Paulo: Novatec, 2008.
MIT1. MIT Open Course Ware. Disponível em: <http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-830-database-systems-fall-2010/>. Acesso em: 10 mar. 2015. MONTIEL PEREZ, J. Y.; HERNANDEZ RUBIO, E.; LOPEZ BONILLA, J. L. Computación móvil. Ingeniare. Rev. chil. ing., Arica, v. 20, n. 3, dic. 2012. Disponível em:
63
<http://www.scielo.cl/scielo.php?script=sci_arttext&pid=S0718-33052012000300001&lng=es&nrm=iso>. Acesso em: 10 jul. 2014. MÜLBER, A. L. Fundamentos para sistemas de informação. 2. ed. Palhoça: Unisul Virtual, 2005. NETBEANS. Netbeans IDE – The smarter and faster way to code. Disponível em: <https://netbeans.org/features/index.html>. Acesso em: 11 mar. 2015. NETO, M. C.; MAIA, J.; QUEIROZ E MELO, L.; FERNANDES, L. M. Computação móvel em agricultura. Rev. de Ciências Agrárias, Lisboa, v. 30, n. 1, jan. 2007. Disponível em:
<http://www.scielo.mec.pt/scielo.php?script=sci_arttext&pid=S0871-018X2007000100011&lng=pt&nrm=iso>. Acesso em: 10 jul. 2014. NIKKILÄ, R.; SEILONEN, I.; KOSKINEN, K. Software architecture for farm management information systems in precision agriculture. Computers and electronics in agriculture, v.
70, n. 2, p. 328-336, 2010. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0168169909001859>. Acesso em: 10 jul. 2014. OBE, R. O.; HSU, L. S. Postgis in action. Stamford: Manning Publications Co., 2011. OGC1. About OGC. Disponível em: http://www.opengeospatial.org/ogc. Acesso em: 03 ago.
2015. ORACLE. Glassfish Server – Roadmap. 2013. Disponível em:
<https://glassfish.java.net/roadmap.html>. Acesso em: 23 jan. 2015. PENDER, T. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.
RAO, N. S.; GEETHA, K. A.; MAITI, S. Web-based networking of herbal gardens for exchange of planting material. Computers and Electronics in Agriculture, v. 103, p. 26-32,
2014. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0168169914000349>. Acesso em: 10 jul. 2014. REIS, D. R. dos. Gestão da inovação tecnológica. 2. ed. Barueri: Manole, 2008. SANTOS, R. R. dos. Programação de computadores em Java. Rio de Janeiro: Nova
Terra, 2011. SHI, X. The Semantics of Web Services: an examination in giscience applications. ISPRS International Journal of Geo-Information, v. 2, n. 3, p. 888-907, 2013. Disponível em:
<http://www.mdpi.com/2220-9964/2/3/888>. Acesso em: 10 jul. 2014. SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. São
Paulo: Person Makron Books, 1999. WRUBLACK, S. C.; MERCANTE, E.; BOAS, M. A. V.; PRUDENTE, V. H. R.; REISDORFER, M.; REIS, C. F. Caracterização de áreas aptas a irrigação localizada, no município de Salto do Lontra – PR com utilização de técnicas de Geoprocessamento. In: CONGRESSO BRASILEIRO DE CARTOGRAFIA, XXV, 2011, Curitiba, Paraná. Anais... p. 323-328.
WRUBLACK, S. C. Caracterização do uso e ocupação do solo e qualidade da água com utilização das técnicas de geoprocessamento. 2012. 88 f. Dissertação (Mestrado em
64
Engenharia Agrícola). Programa de Pós-Graduação em Engenharia Agrícola. Universidade Estadual do Oeste do Paraná, Campus de Cascavel, Cascavel, Paraná.
ZAPATA, C. M.; CHAVERRA, J. J. An environment based on pre-conceptual schemas for automatically generating source code under the mvc pattern.Dyna, v. 176, p. 57, 2012.
Disponível em: <http://www.scielo.org.co/pdf/dyna/v79n176/v79n176a07.pdf>. Acesso em: 10 jul. 2014.
65
APÊNDICE I
66
67
APÊNDICE II
68
69
APÊNDICE III
70
71
APÊNDICE IV
72
