HALLAN MEDEIROS MÁRIO SÉRGIO DA SILVEIRA
CEOMAPS
UMA SOLUÇÃO DE SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
Palhoça 2010
CEOMAPS
UMA SOLUÇÃO DE SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Profª. Vera Rejane N. Schuhmacher, Msc.
Palhoça 2010
HALLAN MEDEIROS MÁRIO SÉRGIO DA SILVEIRA
CEOMAPS
UMA SOLUÇÃO DE SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação, da Universidade do Sul de Santa Catarina.
Palhoça, 15 de junho de 2010.
_____________________________________ Profª. Vera Rejane Niedersberg Schuhmacher, Msc.
Universidade do Sul de Santa Catarina - UNISUL _____________________________________ Prof. Engº. Aran Bey Tcholakian Morales, Dr. Universidade do Sul de Santa Catarina – UNISUL
_____________________________________ Prof. Roque A. Sánchez D'Alotto, Ph.D. Universidade do Sul de Santa Catarina - UNISUL
À minha mãe, Jane, a maior responsável pela minha formação acadêmica e que sempre esteve presente nos momentos decisivos de minha vida.
À minha filha, Amanda, simplesmente por existir.
Hallan Medeiros Às pessoas que foram e que são os maiores responsáveis pela minha formação e foram de grande apoio nesta longa caminhada: meus pais, Cinézio e Albertina e minha irmã Elaine.
AGRADECIMENTOS
À nossa orientadora Vera Rejane Niedersberg Schuhmacher, Msc., que nos conduziu com maestria durante todas as etapas do projeto.
Aos professores do Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina.
Aos nossos pais, pelo apoio, incentivo e compreensão nos momentos difíceis. Aos amigos e colaboradores da Inkor, em especial ao Luiz Gonzaga Carvalho. Aos amigos da DIVE, em especial ao Patryck Ramos Martins.
À Google.
Hallan Medeiros Mário Sérgio da Silveira
“Não temos a oportunidade de fazer tantas coisas, por isso todas elas precisam ser realmente sensacionais.” (Steve Jobs).
RESUMO
O surgimento de ferramentas Web Mapping traz novas possibilidades para a área de Sistemas de Informação Geográfica (SIG), porém, a utilização destas ferramentas é feita somente por programadores que estudaram sua estrutura. Este fato distancia a possibilidade de usuários de diferentes áreas lidarem com esta tecnologia, assim como as empresas que não possuem recurso humano-tecnológico para tal. Neste sentido, a proposta do presente projeto é a construção de um Sistema de Informação que permita a importação de dados geográficos a partir de uma planilha eletrônica para posterior visualização de seus dados distribuídos em um mapa, como forma de simplificar o uso deste tipo de ferramenta. A utilização de planilhas eletrônicas é popularmente difundida e utilizada como saída de dados de quase todos os sistemas de informação existentes, fato que encorajou os autores a escolher este formato como entrada de dados. O projeto, chamado de Ceomaps, é acessado via Internet e permite que seus usuários possam importar, gerenciar e visualizar seus mapas. Como plataforma, foi escolhida a linguagem Java para o servidor, Adobe Flex para a camada visual e o Banco de Dados MySQL para armazenamento de dados. A visualização dos mapas utiliza a API do Google Maps. A validação foi realizada com dois usuários: um CEO de uma empresa de grande porte e uma gerente de um departamento público na área da saúde. O trabalho apresenta também a aplicação do ICONIX, um processo de desenvolvimento de software definido como intermediário entre a complexidade e abrangência do RUP e simplicidade e rapidez do XP, e que utiliza a notação UML.
ABSTRACT
The rise of Web Mapping tools brings new possibilities to the area of Geographic Information Systems (GIS), however, the use of these tools is done only by programmers who have studied its structure. This fact away the possibility of users from different fields dealing with this technology, as well as companies that have no human resource and technology to do so. In this sense, the purpose of this project is to build a Information System that allows import spatial data from a spreadsheet for later viewing their data distributed on a map, as a way to simplify the use of such tool. The use of spreadsheets is widespread and popularly used as data output of almost all existing information systems, a fact that encouraged the authors to choose this format as input. The project, called Ceomaps is accessed via Internet and allows users to import, manage and view its maps. As platform, the Java language was chosen for the server, Adobe Flex for the visual layer and MySQL Database for data storage. The visualization of the maps uses the Google Maps API. The validation was performed with two users: a CEO of a large company and a manager of a department in the area of public health. The paper also presents the application of ICONIX, a process of software development defined as an intermediary between the complexity and scope of the RUP and simplicity and speed of XP, which uses the UML notation.
Figura 1 – Interação entre um sistema SIG e o mundo real ...19
Figura 2 - Interligando dados externos com SIG...27
Figura 3 - Estrutura de um sistema Web SIG ...30
Figura 4 - Cenário de um plano de viagem ...31
Figura 5 - Utilizando o serviço Google Maps ...32
Figura 6 - Utilizando o Street View...33
Figura 7 - Camadas do serviço Google Maps...34
Figura 8 - Latitude e Longitude...36
Figura 9 - Arquitetura da Solução Proposta ...40
Figura 10 - O processo ICONIX ...43
Figura 11 - ICONIX – Requisitos ...45
Figura 12 - Análise e Projeto Preliminar...46
Figura 13 - Projeto Detalhado ...47
Figura 14 – Implementação ...48
Figura 15 - Diagrama de Necessidades dos Stakeholders ...49
Figura 16 - Requisitos Funcionais e Regras de Negócio...50
Figura 17 - Requisitos Não Funcionais ...56
Figura 18 - Protótipo de Tela de Login ...61
Figura 19 - Protótipo de Tela de Entrada ...61
Figura 20 - Protótipo de Tela de Importação...62
Figura 21 - Protótipo de Tela de Visualização de Mapa ...63
Figura 22 - Diagrama de Domínio...64
Figura 23 - Diagrama de Atores ...65
Figura 24 - Diagrama de Casos de Uso ...66
Figura 25 - Diagrama de Robustez – Criar Nova Conta...75
Figura 26 - Diagrama de Robustez – Importar Planilha Eletrônica ...75
Figura 27 - Diagrama de Seqüência - Criar Nova Conta...76
Figura 28 - Diagrama de Seqüência - Importar Planilha Eletrônica...77
Figura 29 - Diagrama de Classes Persistentes ...79
Figura 30 - Diagrama Entidade-Relacionamento ...80
Figura 32 - Tela de Login...90
Figura 33 - Tela de Criação de Nova Conta ...91
Figura 34 - Tela de Recuperação de Senha ...92
Figura 35 - Tela de Ativação de Conta...93
Figura 36 - Tela Principal...94
Figura 37 - Tela de Importação ...95
Figura 38 - Tela de Visualização de Dados do Mapa...96
Figura 39 - Tela de Visualização de Mapa ...97
Figura 40 - Tela de Visualização de Gráfico...98
Figura 41 - Tela de Visualização de Meus Mapas...99
LISTADEQUADROS
Quadro 1 – Requisitos Funcionais de Login. ...52
Quadro 2 – Requisitos Funcionais de Usuário. ...54
Quadro 3 – Requisitos Funcionais de Administrador...54
Quadro 4 – Requisitos Funcionais de Google Maps. ...55
Quadro 5 – Requisitos Funcionais de Sistema. ...55
Quadro 6 – Requisitos Não Funcionais de Usabilidade. ...57
Quadro 7 – Requisitos Não Funcionais de Segurança...58
Quadro 8 – Requisitos Não Funcionais de Suportabilidade...58
Quadro 9 – Requisitos Não Funcionais de Desempenho. ...58
Quadro 10 – Regras de Negócio...60
Quadro 11 – Documentação de Caso de Uso – Criar Nova Conta...67
Quadro 12 – Documentação de Caso de Uso – Importar Planilha Eletrônica...68
Quadro 13 – Documentação de Caso de Uso – Listar Planilha/Mapas de sua Conta. ...68
Quadro 14 – Documentação de Caso de Uso – Visualizar Planilha/Mapa. ...69
Quadro 15 – Documentação de Caso de Uso – Visualizar Gráfico com Dados do Mapa. ...69
Quadro 16 – Documentação de Caso de Uso – Editar Planilha/Mapa. ...70
Quadro 17 – Documentação de Caso de Uso – Excluir Planilha/Mapa. ...70
Quadro 18 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...71
Quadro 19 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...71
Quadro 20 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...72
Quadro 21 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...72
Quadro 22 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...73
Quadro 23 – Documentação de Caso de Uso – Listar Usuários Cadastrados. ...73
LISTA DE SIGLAS
AJAX - Asynchronous Javascript and XML AMF - Adobe Message Format
API – Application Programming Interface BI - Business Intelligence
CEO - Chief Executive Officer CSS - Cascading Style Sheet DAO - Data Access Object
DCP - Diagrama de Classes do Projeto EDI - Electronic Data Interchange ERP - Enterprise Resource Planning GPL - General Public License GPS - Global Positioning System HTML - Hyper Text Markup Language HTTP - Hyper Text Transfer Protocol IDE - Integrated Development Environment
JAAS - Java Authentication and Authorization Service Java EE - Java Enterprise Edition
JSP - Java Server Pages
NEC – Necessidade do Stakeholder OMT - Object Modeling Technique
OOSE - Object-Oriented Software Engineering PNG - Portable Network Graphics
POJO - Plain Old Java Object RF - Requisito Funcional RN - Regra de Negócio
RNF - Requisito Não Funcional RUP - Rational Unified Process SaaS - Software-as-a-Service
SAD - Sistemas de Apoio a Decisão SDSS - Spatial Decision Support Systems
SIG – Sistema de Informação Geográfica SOAP - Simple Object Access Protocol SQL - Structured Query Language SVN - Subversion
UC - Caso de Uso
UML - Unified Modeling Language URL - Uniform Resource Locator
XLS - Arquivo de planilha eletrônica Microsoft Excel XML - Extensible Markup Language
SUMÁRIO 1 INTRODUÇÃO...16 1.1 PROBLEMÁTICA ...17 1.2 OBJETIVOS ...18 1.2.1 Objetivo Geral ...18 1.2.2 Objetivos Específicos...18 1.3 JUSTIFICATIVA ...19 1.4 ESTRUTURA DA MONOGRAFIA ...20 2 REVISÃO BIBLIOGRÁFICA ...21 2.1 SISTEMAS DE INFORMAÇÃO ...21 2.2 INTERNET ...21 2.2.1 A História da Internet...22
2.2.2 World Wide Web ...23
2.3 WEB MAPPING ...24
2.4 SISTEMAS DE INFORMAÇÃO GEOGRÁFICA ...26
2.4.1 Web SIG...29
2.4.2 Google Maps ...32
2.4.3 A API do Google Maps ...35
2.4.3.1 Geocoding...37
3 MÉTODO ...38
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...38
3.2 ETAPAS ...39
3.3 ARQUITETURA DA SOLUÇÃO PROPOSTA ...39
3.4 RECURSOS...40 3.5 DELIMITAÇÕES ...41 3.6 MODELAGEM DO SISTEMA...41 3.6.1 UML...42 3.6.2 ICONIX...43 3.6.2.1 Requisitos ...45
3.6.2.2 Análise e Projeto Preliminar...46
3.6.2.3 Projeto Detalhado ...46
3.6.3 Especificação de requisitos ...48
3.6.4 Necessidades dos Stakeholders...48
3.6.5 Requisitos Funcionais ...49
3.6.5.1 Requisitos Funcionais de Login...51
3.6.5.2 Requisitos Funcionais de Usuário ...52
3.6.5.3 Requisitos Funcionais de Administrador...54
3.6.5.4 Requisitos Funcionais de Google Maps ...55
3.6.5.5 Requisitos Funcionais de Sistema ...55
3.6.6 Requisitos Não Funcionais ...56
3.6.6.1 Requisitos Não Funcionais de Usabilidade ...57
3.6.6.2 Requisitos Não Funcionais de Segurança...58
3.6.6.3 Requisitos Não Funcionais de Suportabilidade...58
3.6.6.4 Requisitos Não Funcionais de Desempenho ...58
3.6.7 Regras de negócio ...59
3.6.8 Prototipação...60
3.6.9 Modelo de domínio...63
3.6.10 Identificação dos atores ...65
3.6.11 Casos de Uso ...65
3.6.12 Documentação dos Casos de Uso ...67
3.6.12.1Diagrama de Robustez...74 3.6.12.2Diagrama de Seqüência ...76 3.6.13 Diagrama de Classes ...78 3.6.14 Diagrama Entidade-Relacionamento ...80 3.7 CONSIDERACÕES FINAIS...81 4 DESENVOLVIMENTO...82 4.1 TECNOLOGIAS E FERRAMENTAS...82 4.1.1 Java...83 4.1.2 Adobe Flash ...83 4.1.3 Adobe Flex ...83 4.1.4 Adobe BlazeDS ...84 4.1.5 Apache Tomcat...85 4.1.6 MySQL ...85 4.1.7 Eclipse...86
4.1.9 Adobe Fireworks ...87 4.1.10 Balsamiq Mockups ...87 4.1.11 Subversion...88 4.2 HISTÓRICO DE DESENVOLVIMENTO ...88 4.3 APRESENTAÇÃO DO SISTEMA ...90 4.3.1 Tela de Login ...90
4.3.2 Tela de Criação de Nova Conta ...91
4.3.3 Tela de Recuperação de Senha...92
4.3.4 Tela de Ativação de Conta...93
4.3.5 Tela Principal...94
4.3.6 Tela de Importação ...95
4.3.7 Tela de Visualização de Dados do Mapa...96
4.3.8 Tela de Visualização de Mapa...97
4.3.9 Tela de Visualização de Gráfico...98
4.3.10 Tela de Visualização de Meus Mapas...99
4.3.11 Tela de Configurações...100
4.4 VALIDAÇÃO...100
4.5 CONSIDERAÇÕES FINAIS...102
5 CONCLUSÕES E TRABALHOS FUTUROS...103
REFERÊNCIAS ...105
GLOSSÁRIO ...109
APÊNDICES ...111
APÊNDICE A – MANUAL DO USUÁRIO...112
1 INTRODUÇÃO
A Internet está cada vez mais presente em nossas vidas. De acordo com Internetworldstats (2009) a Internet atualmente é utilizada por quase 25% da população mundial, algo em torno de 1600 milhões de pessoas. As empresas também fazem parte da estatística, e estão muito mais dependentes deste recurso por estar sempre à procura de diferenciais competitivos. E um grande diferencial competitivo que possibilita um melhor gerenciamento de equipes de vendas e conhecer o mercado, é o uso de Sistemas de Informação Geográfica (GIS - Geographic Information System) como apoiador na tomada de decisão.
A área de Sistemas de Informação Geográfica (SIG) teve um grande avanço por contribuição da empresa Google quando foi lançado, em fevereiro de 2005, ainda em sua versão beta, o Google Maps, que é um serviço gratuito de visualização de mapas por meio da Internet, no qual possibilita pesquisas por locais e traçar rotas entre dois pontos (PETERSON, 2008). A partir disto se pode então verificar a evidenciação de um conceito chamando de Web Mapping.
De 2005 até hoje este conceito foi marcante em aplicações focadas somente para web, onde poderiam ser observados em alguns sites, mapas com localizações diversas, criados usando os recursos que a API (Application Programming Interface) do Google Maps fornece. Esta API possibilita personalização de recurso e adaptação do mesmo à sua aplicação.
Sabe-se que na sua maioria, as empresas que geram dados históricos de faturamento e que tem um alto resultado financeiro, possuem uma área de atuação geográfica relativamente grande. E sabendo que os sistemas de informação de tais empresas são anteriores a explosão da Web 2.0, encontra-se então um grande nicho de atuação para sistemas baseados em Web SIG.
Este trabalho vai se concentrar na criação de uma ferramenta Web SIG, possibilitando análises, gerando gráficos e informações de nível gerencial, utilizando a API do Google Maps.
1.1 PROBLEMÁTICA
Em se tratando de sistemas de informação geográficos, o aumento das fontes de informação, e das formas de se obter dados, aliado ao aumento considerável do número de sistemas e aplicações disponíveis, criou a necessidade de se fomentar a área de pesquisa em interoperabilidade de sistemas SIG. Esta área de aplicação focada na camada de dados suporta a entrada de dados externos que exponencialmente estão expandindo em número e volume somados aos conceitos de mídias locativas e territórios computacionais.
O desafio é encontrado dentro desta área de pesquisa. Uma análise dos três pilares que compõem a problemática da interoperabilidade de sistemas SIG, que são: dados, interface e processo. Observa-se um desafio ontologicamente ainda mais complexo dentro do tratamento realizado sobre os dados e sua reutilização. Sem uma interface de entrada de dados que suporte formatos genéricos, percebe-se total inoperância dos processos e manipulação de dados, impossibilitando maiores análises. O processo como sendo a maneira de intercambiar os dados entre sistemas, o que possibilitaria a obtenção dos dados de geo-referenciação, apresentaria então a maior problemática de um sistema SIG, e o fator que mais distanciaria os usuários dos resultados pretendidos.
Este entendimento tende a direcionar os desenvolvedores ao desenvolvimento de um sistema SIG focado no usuário e na facilidade em se adicionar dados externos ao sistema. Ainda dentro da camada de processo de uma aplicação SIG, deve-se observar que os objetos com sensibilidade locativa que possam proporcionar dados de entrada ultrapassam aparelhos celulares do tipo Smart Phone, Notebook ou Palm. Uma gama de objetos com esse tipo de funcionalidade está sendo desenvolvida, como por exemplo, aparelhos capazes de rastreamento, posicionamento, ou até mesmo geradores de informações de espaços geográficos em função de sua mobilidade.
No desafio de todas as problemáticas de um sistema SIG em sua interoperabilidade e extensão da abstração do mundo real, e as formas do sistema contemplar as novas mídias digitais, ainda tem-se como desafio a decomposição do paradigma da invasão de privacidade para gerar subsídios para então poder compor novos arranjos espaciais políticos e urbanos.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é desenvolver um Sistema de Informação que permita visualizar dados de qualquer natureza distribuídos em um mapa, sendo que nestes dados a componente geográfica deve estar definida. A importação dos dados será a partir de uma planilha eletrônica, como forma de simplificar o uso da ferramenta, fornecendo informações gerenciais para empresas e contribuindo nos aspectos de análise de dados estatísticos.
1.2.2 Objetivos Específicos
São objetivos específicos do projeto:
• Desenvolver uma aplicação Web, em Java, utilizando a API do Google Maps como interface de visualização de dados proveniente de uma fonte externa;
• Utilizar a framework Flex para criação das interfaces;
• Possibilitar uma forma genérica de integração de dados de sistemas externos e a aplicação a ser desenvolvida;
1.3 JUSTIFICATIVA
São muitas as possibilidades quando se utiliza um sistema SIG, para apoiar empresas. Mas as possibilidades de se obter tais recursos, que responderiam por crescimento de rentabilidade das empresas, ainda não são um acesso que se possa considerar como facilitado. Já é possível observar, porém, esforços em direção às mídias locativas, e a sistemas SIG, que contemplem flexibilidade e simplicidade, tendência a resultados significativos na tomada de decisão das empresas.
A localização de novos pontos de pujança de negócios, estimulado por esforços de vendas, e as genéricas transformações do comportamento da sociedade, alinhado até mesmo ao desenvolvimento caótico das cidades, são elementos conexos em um sistema, que interagem em duas vias, em que as mídias locativas impulsionam transformações no espaço urbano, e o espaço urbano responde com comportamentos consumistas que exige recursos computacionais de um sistema Web SIG.
Figura 1 – Interação entre um sistema SIG e o mundo real Fonte: BERNHARDSEN, ( 2002, p. 2)
Na Figura 1 a abstração ou simplificação do mundo real, é possibilitada por um banco de dados contendo informações geográficas, e a associação destas informações a ferramentas que tratem nesse momento, da qualidade das informações, temos uma via dinâmica, em que o mundo real influenciará a maneira de serem criadas e usadas essas
ferramentas. Em contrapartida os resultados gerados pelo sistema SIG trarão apoio para a tomada de decisão dentro do mundo real.
A API do Google Maps possibilita a geração de um arquivo com extensão “kml” e o mesmo terá que ser gerado com as informações pertinentes a análise da empresa em sua atuação. Em seguida este arquivo pode ser importado em qualquer serviço de Web Mapping do Google (Google Maps ou Google Earth). Porém a manipulação deste arquivo é possibilitada somente por desenvolvedores que estudaram sua estrutura, e já conhecem a API da ferramenta. Este fato distancia a possibilidade de usuários de diferentes áreas lidarem com esta tecnologia, assim como as empresas que não possuem recurso humano-tecnológico para tal. Isso impossibilita a análise das informações locativas desejadas.
O estreitamento na relação do uso de tecnologias se fundamenta na simplicidade da ferramenta e no que é de uso comum pela maioria. Desta forma pode-se perceber que as análises de dados estatísticos e informações, em sua grande parte, são realizadas com planilhas eletrônicas ou as chamadas “spreadsheet”, popularmente difundida e utilizada como saída de dados de quase todos os sistemas de informação já existentes. Outras formas de organização e saída de dados também são utilizadas, e compõem um cenário em que as mídias locativas compostas por sistemas SIG teriam que suportar este tipo de entrada de dados.
O sistema SIG proposto será desenvolvido neste cenário, e possibilitará entradas de dados nos formatos comuns, xls, csv, txt e kml, atuando dentro da necessidade de simplicidade e transparência, formatando uma maneira de análise focada nas competências dos gestores e executivos.
1.4 ESTRUTURA DA MONOGRAFIA
A estrutura deste trabalho é formada por 5 capítulos. O capítulo 1 descreve os objetivos e definições da monografia. No capítulo 2 tem-se revisão bibliográfica. Nele são abordados temas como a história e evolução da Internet, Sistemas de Informação, Web Mapping e SIG. O capítulo 3 é constituído pela arquitetura e modelagem do sistema proposto, sustentado pelo processo ICONIX. No capítulo 4 apresentam-se o desenvolvimento, apresentação e validação do sistema. Por fim, o capítulo 5 descreve as conclusões e trabalhos futuros.
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo apresentam-se os fundamentos teóricos que irão sustentar o presente trabalho. Os assuntos abordados servem como base para compreensão e fundamentação de conceitos como Web, do serviço de Web Mapping, Sistemas de Informação Geográficos e Web SIG.
2.1 SISTEMAS DE INFORMAÇÃO
Conforme Rezende (2003), Sistema de Informação significa um conjunto de partes que geram informação. Informação significa dados organizados: processados, limpos e em uma nova estrutura, sem redundância (MICHALEWICZ; MICHALEWICZ; SCHMIDT, 2006). Dados são coletados diariamente na forma de bits, números, símbolos ou objetos. De acordo com Rezende, "o dado tomado isoladamente não transmite conhecimento, ou seja, não contém um significado claro". Sendo assim, um Sistema de Informação pode ser definido como um conjunto de componentes que processam dados e por meio deste processamento geram informação. Um sistema é um conjunto de partes que interagem entre si para atingir objetivos (REZENDE, 2003), e o objetivo de um Sistema de Informação é gerar informação.
2.2 INTERNET
A Internet, poucos anos após a sua criação, causou um enorme impacto social em todo o planeta. Estima-se que, atualmente, 1/4 da população mundial acesse a Internet regularmente. Muitos Sistemas de Informação funcionam na Web, por meio de um Browser, permitindo que sejam acessados em locais diferentes sem a necessidade de instalar o mesmo, no sistema operacional. Os termos Internet e World Wide Web, erroneamente são usados como se tivessem o mesmo significado, mas não é a mesma coisa. Internet é um sistema
global de comunicação. É uma infra-estrutura de hardware e software que permite a comunicação entre computadores. World Wide Web é um serviço que funciona via Internet. É um enorme repositório de documentos e outros arquivos, ligados por Hiperlinks e Uniform Resource Locators (URL).
2.2.1 A História da Internet
A origem da Internet está atrelada a uma mensagem enviada em 29 de Outubro de 1969. Foi transmitida da Universidade de Califórnia para a Universidade de Stanford, por computadores conectados através de um protótipo chamado Interface Message Processors (IMP), que interligava computadores a ARPAnet, um projeto da Agência de Projetos de Pesquisa Avançada(ARPA) do Departamento de Defesa dos Estados Unidos (ZITTRAIN, 2008, p. 27). Até o final do ano de 1969, mais duas universidades foram conectadas na rede. A ARPANet foi a primeira rede a interligar computadores do mundo, e tempos depois se tornou a Internet (SUTTON, 2004). O motivo da criação da ARPANet foi militar. A intenção desta grande rede era manter os líderes militares dos Estados Unidos em contato no caso de uma guerra nuclear (BLANK, 2002).
O protocolo de envio e recebimento de mensagens da ARPAnet foi chamado de Network Control Protocol (NCP). Com o crescimento da rede, foi necessário criar um novo protocolo, pois o NCP não foi projetado para interligar uma grande rede. Vint Cerf, junto com outros membros da ARPAnet, desenvolveram o protocolo Transmission Control Protocol (TCP), e logo após foi criado o Transmission Control Protocol/Internet Protocol (TCP/IP). Com o TCP/IP, cada computador tem uma identificação numérica única dentro da rede, chamado de endereço IP.
Pela dificuldade em decorar números de identificação, foi criado uma tabela que mapeava o endereço de IP de cada computador da rede com um nome para o computador, pois seria mais fácil de lembrar. Cada computador da rede tinha esta tabela, mas o crescimento do número de computadores ligados a Internet tornou este método inviável. Paul Mockapetris, em 1982, criou o Domain Name System (DNS), um sistema de tradução de nomes hierárquico e distribuído (COSTA, 2007). A tarefa de fazer a ligação entre o nome do
computador e seu endereço IP passou a ser de servidores DNS, e não de cada computador da rede.
2.2.2 World Wide Web
A Internet no qual se conhece atualmente começou com Tim Berners-Lee. Ele criou, em 1990, um conjunto de regras baseadas na linguagem de marcação Standard Generalized Markup Language (SGML), surgindo assim o Hyper Text Markup Language (HTML). Os arquivos HTML então seriam gravados em discos rígidos de um computador de uma rede. Estes arquivos seriam acessados por meio de seu nome, precedidos pelo endereço IP do computador ou domínio, sempre únicos, e do diretório onde estava gravado. A este endereço foi dado o nome de URL. Para acessar os arquivos, foi criado o protocolo Hyper Text Transfer Protocol (HTTP). Tim Berners-Lee uniu a idéia do Hipertexto com TCP/IP e DNS, sendo esta união a World Wide Web, utilizada hoje por todos. Para Deitel (2003), foi a introdução da World Wide Web (ou simplesmente Web) na Internet que tornou a mesma um dos maiores e principais meios de comunicação mundial.
Para visualizar as páginas HTML, Tim Berners-Lee, em 1990, criou o primeiro navegador da Internet, chamado WorldWideWeb, que interpretava as tags HTML e montava a página visualmente na tela do computador. Tim trabalhou alguns meses no projeto, e montou o primeiro servidor Web e o primeiro cliente Web em seu próprio computador (MCPHERSON, 2009, p.51). Vários outros browsers foram sendo criados, mas um teve destaque: se chamava Mosaic, e foi criado Marc Andreessen e Eric Bina, dois estudantes da NCSA (National Center for Supercomputing Applications) em 1993. O Mosaic, além de ser o primeiro Browser com interface gráfica, tinha suporte a vários tipos de multimídia, formulários, histórico de navegação e favoritos, se tornando rapidamente o mais popular navegador não-comercial (STEWART, 2009). O Mosaic foi a base para os principais navegadores da Internet atualmente: O Internet Explorer e o Mozilla Firefox.
Com a criação da Web e do Browser, um novo e imenso território inexplorado surgiu, onde proliferavam páginas pessoais e surgiam celebridades instantâneas. As páginas eram estáticas em HTML e o comércio eletrônico não era cogitado de forma séria. Conforme foram surgindo novas tecnologias, como PHP, ASP, Java, Javascript e Flash, a interação com
os usuários se tornou mais dinâmica, possibilitando o comércio eletrônico, salas de bate-papo, entre outros. As empresas "ponto.com" começavam a surgir do dia para a noite, e as empresas da "velha economia" tiveram de se atualizar e utilizar a web para concorrer neste novo tipo de comércio (SAMPAIO, 2007, p.4).
O termo Web 2.0 foi utilizado por Tim O'Reilly, CEO da O'Reilly Media, em 2003, e não significa uma mudança de tecnologia, mas sim uma mudança de foco. A percepção foi que os websites deveriam se integrar, ao invés de cada um ser uma ilha isolada de informações (SAMPAIO, 2007). Surgem os grandes portais colaborativos, como os Wikis (Wikipedia), sites de relacionamento (Twitter, Orkut), blogs (Wordpress, Blogger), feeds RSS e serviços gratuitos para serem usados e compartilhar conteúdo, como Flickr, Youtube, Google Maps, entre outros (SOLOMON; SCHRUM, 2009). A Web passa a ser utilizada por uma massa imensa de pessoas (LYTRAS; DAMIANI; PABLO, 2009).
2.3 WEB MAPPING
Há poucos anos atrás, pessoas desenhavam e coloriam os mapas à mão. A análise dos dados e a criação dos mapas com os resultados eram lentas e trabalhosas (MITCHELL, 2005). O homem moderno começou a desenhar o espaço onde vive, porém os recursos para esses feitos sempre foram rudimentares, e eram usados métodos artísticos para conseguir chegar a uma maior aproximação do mundo real, em uma representação gráfica manuscrita. A experiência da psicogeografia, projeto do final dos anos 50 proposto por pensadores do movimento situacionista, buscava relacionar o slogan “todos tem o poder” - com objetivo de despertar a revolução a partir da atuação crítica e consciente do cotidiano - à criação de mapas subjetivos (LEÃO, 2004, p.9). Este projeto resgatava o “buscar afetivo” nos espaços públicos e contribuiu em muito na evolução das formas de se tratar mapas. Cunhado em 1984 por William Gibson o termo “Ciberespaço” três décadas depois, começou a se tornar co-relacionado com a idéia de computacionar e digitalizar mapas. “Camaleônico, elástico, ubíquo, e irreversível, o ciberespaço não se reduz a definições rápidas” (LEÃO, 2004). As representações em mapas eram perecíveis às transformações, e fugazes aos contornos do mundo, mas, indiscutivelmente indispensável para estabelecer as primeiras formas de se representar um ciberespaço.
Traduzir fenômenos do universo que estão além dos sentidos humanos em algo palpável e usual, faz lembrar que artistas românticos acreditam que alguns efeitos e fenômenos são irrepresentáveis. Em contrapartida os “artistas de mapeamento de dados” almejam o contrário, buscam representar graficamente o mundo, de uma maneira perceptível pelos sentidos cognitivos dos humanos. Isso aproxima em muito a arte de visualização de dados com a ciência moderna. No inicio do século XX a arte se distanciou de sua mais importante função: retratar o ser humano. E partiu para abstração de objetos, prédios, ruas, indústrias e recentemente dados, que conseqüentemente estaria ligado indiretamente com as atividades humanas dentro de uma rede (Internet).
Uma questão importante segundo Manovich (2004) é a escolha arbitrária versus escolhas motivadas no mapeamento. Uma vez que os computadores permitem facilmente mapear quaisquer conjuntos de dados em outro conjunto, muitas vezes é fácil indagar por que o cartógrafo escolheu esse ou aquele mapeamento, quando incontáveis outras escolhas seriam possíveis. Os meios computacionais fazem todo esse mapeamento parecer arbitrários, pois inúmeras possibilidades se desdobram quando se busca representar um ciberespaço, a menos que sejam usadas estratégias espaciais para motivar as escolhas.
Um exemplo sobre motivação é o da construção do Museu Judaico de Berlin (Jewish Museum Berlin), de Daniel Liberskind. Ele construiu um mapa que mostrava as casas dos judeus que residiam próximo ao futuro museu antes da II Grande Guerra. Ligando os pontos dos endereços ele montou uma grande rede que foi projetada ao topo do prédio, que teve como resultado um grande concentração de formas arbitrarias, que compunham janelas com ângulos que apontavam para várias referências visuais. “No Museu Judaico o passado literalmente penetra no presente. Em vez de algo efêmero, aqui o espaço de dados é materializado, tornando-se uma espécie de escultura monumental” (MANOVICH, 2004, p. 159). Sendo assim, uma questão então é formada: por que Liberskind compôs a rede com os endereços dessa forma? Dados coletados trabalhosamente são tramados quase que cientificamente, são jogados arbitrariamente sobre as formas do prédio. Esse exemplo mostra perfeitamente o paradigma do mapeamento de dados dentro de um ciberespaço. Uma metáfora usada pelos situacionistas na década de 60 era deixar fazer com que o habitante tivesse uma nova percepção de seu habitat, usando um método que eles chamavam de “ostranenie” ou estranhamento espacial. Navegar por Paris usando um mapa de Londres (MANOVICH, 2004, p. 160).
Poético, isso transcende aos dias atuais ao se deparar com um serviço de Web Mapping, e mergulha-se num ciberespaço, e caminha-se por lugares que parecem ser já
conhecidos, ou com a surpresa de novos lugares e a exatidão dos detalhes impressionaria um artista romântico, porém os dados coletados incansavelmente por “artistas” programadores arbitrariamente são chocados com a nossa percepção do mundo em que vivemos. "Os mapas para Web podem disponibilizar aos usuários o acesso às informações geográficas de modo interativo, dinâmico e constantemente atualizado" (MARISCO, 2004).
2.4 SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
A base de um SIG encontra-se em Sistemas de Informação e Geografia. De uma forma simplificada, um sistema SIG mescla informação - dados - com localizações geográficas, digitalmente (BERNHARDSEN, 2002). Um SIG auxilia nos negócios, possibilitando novas estratégias, determinar locais para abertura de novas lojas ou filiais, escolher melhores rotas para entrega de produtos, compra e venda de terrenos, entre outros (KORTE, 2001).
O avanço da Internet, e-commerce e sistemas web 2.0 foram alguns motivadores para o avanço de sistemas SIG. A Internet tem sido utilizada para negócio empresarial desde 1980, através de Eletronic Data Interchange (EDI), mas o controle das transações não era nada amigável. Com o advento da World Wide Web, e do Browser uma nova forma de negócio se tornou possível: o comércio eletrônico, ou commerce (PICK, 2007). O e-commerce cresceu rapidamente, e começou a se relacionar com o SIG, pois localizações espaciais passaram a estar diretamente envolvidas nos negócios.
O envolvimento físico de sistemas SIG com o comercio eletrônico ultrapassa a motivação de facilidade e agilidade, já se pode acreditar que a exploração de paisagens e seus dados, e a relação entre elas, que ainda não foram cruzadas, são intrinsecamente resultados de um sistema SIG atuando como suporte na criação de novas alternativas de comércio e de desenvolvimento. A informática altera a natureza do lugar, altera também a natureza de estar no lugar, de movimentar-se pelo lugar e de colaboração no lugar (LEÃO, 2004). Quando Lucia Leão comenta sobre a informática no aspecto de influencias e colaboração, remete ao conceito de “rede”, enquanto estrutura física de comunicação, entrelaçados com pacotes que
se movimentam sobre ela, comunicação/colaboração/comércio, animação/browser/servidor, que é todo o contexto da Internet, com a adição de corpo e lugar numa prática de SIG.
Projetos de pesquisa de mercado para empresas era um processo muito trabalhoso e demorado, onde os empresários teriam que ir até as bibliotecas de Censo e procurar os exemplares corretos e depois transferir manualmente os dados para seus sistemas. Já com um sistema SIG associado aos chamados “off-the-shelf” que são dados prontos para uso de empresas, como estatísticas de mercado e outras informações relevantes, todo esse trabalho pode ser feito em pouco tempo. Estes sistemas podem criar, em poucos minutos, numerosos mapas que sobrepõe informações sobre o inventário de dados do Censo a imagens fotográficas obtidas por satélite.
Figura 2 - Interligando dados externos com SIG Fonte: KORTE (2001, p. 53)
A Figura 2 mostra um exemplo de um SIG interligando informações internas da própria organização e externas “off-the-shelf”, fazendo com que estas deixem de ser uma ilha
de informações e passem a ter valor agregado. Os mapas gerados podem sobrepor as informações organizacionais com dados como taxas, vendas globais, localização de serviços públicos, valores de taxas, entre outros, mostrando ligações entre dados que sem um SIG seria difícil visualizar (KORTE, 2003).
Pode-se dizer ainda que a localização geográfica é um importante atributo de atividades, políticas, estratégias e planos. Sistemas de Informação Geográficos é uma classe especial de Sistemas de Informação que processa não apenas eventos, atividades e números, mas também onde estes eventos, atividades e números aconteceram ou existiram em um, determinado corte temporal (LONGLEY, 2005, p.4).
Como a localização é importante, muitos problemas sociais podem ser evidenciados ao analisar dados geográficos. Alguns destes problemas podem ser problemas diários, rotineiros, que quase passam despercebidos. Outros são eventos inesperados, que requerem uma ação imediata e rápida para poder contorná-los. De acordo com Longley (2005), problemas que envolvem um aspecto de localização, onde é usada a informação para poder resolvê-los, são chamados de problemas geográficos. Alguns exemplos de problemas geográficos são:
• Uma empresa no ramo da saúde resolve um problema geográfico (ou até mesmo cria um) ao decidir onde abrir uma clínica nova ou hospital;
• Uma empresa de transporte resolve problemas geográficos ao definir as rotas e agendamento de datas de entrega para seus veículos;
• Empresas de consultoria em vendas resolvem problemas geográficos quando recomendam os melhores locais para abrir uma nova loja de determinado ramo de produto.
Para analisar melhor cada um destes casos, se faz necessário analisar questões como o nível de detalhe geográfico, intenção ou propósito do negócio e escala (tanto espacial quanto temporal).
Informações geográficas são um dos tipos mais complicados de informação armazenados em sistemas computacionais. O conteúdo da informação geográfica varia em diferentes resoluções, escalas, tempos e domínios (PENG; TSOU, 2003). Conforme o tempo passa, a infra-estrutura e população de um local pode se alterar, gerando novas demandas de recursos sociais e potenciais nichos de mercado, como por exemplo, hotéis, postos de gasolina, parques e restaurantes.
Evidentemente, o mundo dos negócios depende de tomada de decisões. Presidentes guiam uma organização decidindo estratégias a longo prazo, enquanto os diretores decidem táticas e iniciativas para atingir os objetivos de médio e curto prazo. Analistas de Negócio tomam decisões para analisar problemas, conduzir desenvolvimento de produtos e gerar decisões criativas para manter a empresa no mercado. Os gerentes operacionais se focam na decisão tomadas em processos particulares. Para qualquer organização, a decisão é algo rotineiro e precisa ser tomada (MARAKAS, 2002).
Dentre os objetivos principais de uma empresa, podemos citar alcançar a modernidade com inteligência competitiva e gerar lucro e perenidade com inteligência empresarial. Dentro das empresas, o enfoque atual dos sistemas está principalmente no negócio empresarial e no objetivo de auxiliar os respectivos processos decisórios (REZENDE, 2003, p. 32). Sistemas de Informação Geográficos possuem um papel crucial no que diz respeito a ser suporte para tomada de decisões. A área de Sistemas de Informação possui sistemas conhecidos para auxiliar a tomada de decisão, como Sistemas de Apoio a Decisão (SAD) e Business Intelligence (BI). Na área de SIG existem conceitos relativamente novos como Sistemas de Apoio a Decisão Espacial (SDSS – Spatial Decision Support Systems) e Spatial Business Intelligence (PICK, 2007, p. 70). Um exemplo destes conceitos seria modelos e dados que auxiliariam instituições bancárias a identificarem locais para criar, manter ou fechar caixas eletrônicos. Estas decisões são baseadas em locais espaciais de seus clientes, concorrentes e filiais já existentes. Um SIG aumenta também a produtividade, pois permite uma melhor visualização global do negócio, espalhando os dados espaciais e permitindo que esta seja vista em variados temas e camadas, com cores diferentes e dependendo de como foi implantado, com valores sendo atualizados em tempo real (KORTE, 2002).
2.4.1 Web SIG
Um Sistema de Informação Geográfica pode ser criado de muitas formas diferentes. Como acontece em vários outros campos de atuação, não existe um termo específico para descrever os tipos e plataformas que um sistema SIG pode ser implantado. Muitos termos já foram citados, como “Internet GIS”, “GIS on-line”, “Sistema de Informação
Geográfica Distribuído”, e “Web GIS”. Todos estes termos são similares, mas podem ter significados distintos. Todos eles referenciam um Sistema de Informação Geográfica sendo executado através da Internet. Mas Internet e Web possuem significados diferentes. O termo “on-line” pode representar tanto Internet quanto Web. O termo “Internet GIS” pode ser usado para representar um SIG sendo executado através da Internet, mas não necessariamente utilizando o browser ou páginas de acesso. Já o termo “Web GIS” (ou Web SIG) significa um SIG utilizando a Web como plataforma de execução, tendo a troca de informações, processamento e visualização de seus resultados através do Browser (PENG; TSOU, 2003, p. 10).
Sistemas Web SIG possuem um cliente, um servidor de aplicação, um servidor de mapas e um servidor de dados.
Figura 3 - Estrutura de um sistema Web SIG Fonte: Elaborado pelos autores (2009)
Na Figura 3, pode-se visualizar a interação entre os componentes de um sistema Web SIG. A respeito de cada uma destas partes (PENG; TSOU, 2003, p. 20):
• Cliente: é o acesso do usuário ao SIG. Neste caso em específico, um Browser de acesso a Web no computador de cada usuário, como por exemplo, Internet Explorer, Firefox, Safari e Opera.
• Servidor de Aplicação: também chamado de servidor HTTP, sua função é responder as requisições dos Browsers via HTTP. Existem várias formas de um servidor responder as requisições de clientes: enviando uma página
HTML com imagens do mapa e dados para o cliente, enviando um Applet Java, um arquivo Flash (SWF), entre outros;
• Servidor de Mapas: o servidor de mapas é o responsável por receber requisições de dados espaciais e gerar os mapas baseados nesta requisição. O servidor de mapas possibilita algumas funções tradicionais de SIG, como filtros, extração de dados e serviços de localização por coordenadas geográficas.
• Servidor de Dados: o servidor de dados promove dados espaciais e não espaciais, em forma de estrutura de dados relacional ou não relacional. Por meio de comandos SQL os dados deste servidor são manipulados.
Em um exemplo de atuação de um sistema SIG, temos o seguinte cenário: Mike planeja fazer uma viagem para uma cidade desconhecida. Ele deseja traçar a rota de viajem para esta cidade e reservar um hotel para sua estadia.
Figura 4 - Cenário de um plano de viagem Fonte: PENG (2003, p. 37)
Na Figura 4, é possível visualizar os atores envolvidos no cenário do plano de viagem. Mike, um usuário do SIG, que não tem nenhum tipo de treinamento em sistemas SIG, quer planejar uma viagem. Tina é a representação de um designer de mapas. Kevin, o gerente de reservas do hotel, tem as informações de reserva e quem irá aceitar a reserva de Mike. Em uma solução Web SIG, Mike o cliente, por intermédio de um Browser, iria acessar o SIG, mais precisamente o serviço de rotas de viagem. Tina seria o servidor de mapas: irá mostrar o mapa no navegador para Mike definir seu ponto de saída e ponto de chegada (sua rota). Tina então retornaria um mapa contendo o caminho mais curto para Mike chegar ao seu destino, com os hotéis na sua cidade de destino. Toda interação de Mike e de Tina seria mediada pelo
servidor de aplicação, responsável por atender as requisições de Mike. Kevin então seria o servidor de dados, neste caso um serviço on-line de reservas do hotel escolhido, de acordo com suas definições de preço e data de estadia. Mike então efetua sua reserva e tem a opção de imprimir um mapa com a rota traçada de seu ponto de saída para o hotel de destino, com sua reserva já efetuada. Toda esta operação levaria poucos minutos para ser concluída (PENG; TSOU, 2003, p. 38).
2.4.2 Google Maps
O lançamento do Google Maps, em 2005, revolucionou o conceito de Web Mapping. Com a transmissão de dados entre cliente e servidor via Asynchronous Javascript And XML (AJAX), o Google Maps atingiu uma interação com os mapas inédita na web: apenas clicando e movendo o mouse para uma direção ou usando o scroll para aproximar ou afastar, a atualização do mapa ocorre quase de forma instantânea. Ao lançar este serviço, a Google deixou todos os outros serviços de Web Mapping parecer imediatamente obsoletos (PETERSON, 2008).
Figura 5 - Utilizando o serviço Google Maps Fonte: http://maps.google.com.br (2009)
No Google Maps, é possível armazenar suas localizações, apenas com um clique, com a premissa que você tenha uma conta no Google. As possibilidades que a ferramenta possibilita são inúmeras, e uma das mais impressionantes é a de projeção de rotas entre dois pontos, que é uma maneira de manipulação de dados muito complexa, que a ferramenta disponibiliza com muita precisão. Enviar localização por email, compartilhar as informações e se beneficiar de uma API aberta, são outras vantagens que o Google Maps possui.
Nos casos de sistemas SIG web, utilizar o Google Maps torna-se uma grande vantagem, pois além de ser relativamente barato, é possível personalizar e adicionar recursos facilmente (PETERSON, 2008). Os mapas também podem estar relacionados com fotos dos lugares, e as fotos são adicionadas por usuários comuns ou por empresas como National Geographic. Recentemente mais um recurso foi adicionado, o Street View, que nos proporciona uma experiência com imagens imersivas em 360°, com navegação intuitiva e uma representação do mundo real muito próxima, disponível apenas nas ruas das cidades que possuem este recurso adicionado, o objetivo é que o usuário tem a impressão de estar caminhando pelas ruas.
Figura 6 - Utilizando o Street View Fonte: http://maps.google.com.br (2009)
A Figura 6 mostra a visualização de uma rua por meio do recurso Street View. Com cliques e movimentos do mouse, é possível ter uma visão completa de como era a rua, aproximando ainda mais a representação abstrata do mundo real.
É possível cadastrar uma empresa e permitir que outras pessoas possam encontrá-la, já remetendo a um recurso comercial que atua significativamente no resultado das
empresas. Todos estes recursos colaborativos são utilizados de maneira que informações são adicionadas de modo automático por todos os usuários simultaneamente, e estas informações vão compondo uma espécie de mundo virtual, em que todos são afetados e tratados como peças de um grande mundo colaborativo que beneficia a todos.
Figura 7 - Camadas do serviço Google Maps Fonte: http://maps.google.com.br (2009)
Na Figura 7 é possível observar que o sistema de mapas do Google possui cinco camadas adicionais que podem ser selecionadas, e compõem uma maneira mais interativa de observação de mapas na Internet. A respeito das cinco camadas interativas do Google Maps:
• Fotografias: Fotos podem ser adicionadas por empresas ou qualquer usuários, e podem ser observadas por qualquer pessoa em qualquer parte do mundo. As fotos que são adicionadas terão que ter uma relação direta com a paisagem do lugar. Assim a experiência da utilização do Google Maps se torna muito mais próxima ao mundo real.
• Vídeos: Atrelado a outro serviço do Google, o Youtube, que é um repositório de vídeos na Internet, esta camada do Google Maps mostra
vídeos relacionados à paisagem do local e pode conter documentários que contem um pouco da história do lugar.
• Wikipédia: Informações sobre o local são relacionadas por meio de uma parceria com a Wikipédia, que é um grande repositório de artigos e fontes de informação, totalmente colaborativo.
• Webcams: Algumas câmeras podem ser observadas nos mapas, e os vídeos transmitidos são assistidos em tempo real, uma tecnologia muito interessante para projetos que buscam monitoramento de regiões.
• Transportes públicos: Apenas em alguns países esse recurso está disponível, e funciona como apoio a população, que utiliza o transporte público como meio de locomoção, contribuindo indiretamente com a preservação do meio ambiente.
2.4.3 A API do Google Maps
Uma das grandes características da Web 2.0 são as APIs para utilização e desenvolvimento de web sites. API, para Orenstein (2000) é um conjunto de requisições padronizadas, utilizadas quando um software requer que outro software faça algo. Segundo Roos (2009), API é um conjunto de instruções e padrões para acessar um software de plataforma Web, ou uma ferramenta Web. Uma empresa de software lança sua API publicamente, para que outros desenvolvedores possam criar produtos que possam se beneficiar deste serviço, tornando estes melhores. "Utilizando recursos e APIs existentes, é possível desenvolver sites poderosos e flexíveis, contando com recursos atrativos como blogs, agendas, notícias e mapas" (SAMPAIO, 2007, p.4). Esta é a maior diferença da Web 2.0 para a Web tradicional: criar novos serviços para as pessoas utilizando APIs e ferramentas já existentes, possibilitando o uso de inteligência coletiva.
A API do Google Maps é uma interface de desenvolvimento de aplicativos fornecida pela Google, permitindo a utilização e personalização de mapas na web. A API do Google Maps está totalmente integrada às APIs AJAX do Google. Portanto com apenas uma chave de utilização é possível utilizar todas as APIs AJAX do Google (inclusive o Google Maps). Para usar toda a estrutura da API AJAX do Google oferecida é relativamente simples, porém é necessário ter conhecimentos de programação orientada a objetos.
A API possui também um recurso para detectar se o aplicativo está usando um sensor (como um localizador GPS). Com isso é possível determinar a localização do usuário, que é especialmente importante para dispositivos móveis.
Através da latitude e longitude, é possível localizar um lugar na superfície terrestre, cada local possui um par único destes valores, chamados de coordenadas geográficas.
Figura 8 - Latitude e Longitude Fonte: UDELL (2009, p. 9)
Na Figura 8 é demonstrado de forma simples como funciona a latitude e a longitude terrestre. Latitude representa a distância de um ponto até a linha do Equador. A Latitude pode ir da linha do Equador (zero grau) ao Pólo Norte (90 graus norte) ou ao Pólo Sul (90 graus sul). Longitude representa distância de um ponto até o meridiano de Greenwich,
na Inglaterra. A Longitude pode ir de zero até 180 graus, para leste ou oeste (FREDERICKS, 2000).
2.4.3.1 Geocoding
Dificilmente um sistema de informação empresarial irá ter as coordenadas geográficas de uma localização, pois a mesma não teria utilidade fora de um SIG. Geocodificação (geocoding) é o processo de encontrar as coordenadas geográficas a partir de dados geográficos (como endereço, código postal e fronteira ou marco), sendo que o método mais preciso é buscar as coordenadas geográficas a partir do nome da rua (DRAMOWICZ, 2004). O processo de geocoding é essencial em qualquer SIG, por isso, a API do Google Maps contém este serviço, eliminando a necessidade de ter um serviço de geocoding externo (UDELL, 2009, p. 80).
3 MÉTODO
No ambiente acadêmico, para realizar pesquisas científicas, o arcabouço teórico e uma fundamentação para elaboração da mesma é imprescindível, dentro de todas as ações que são representadas pelas metodologias apropriadas.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
A pesquisa aplicada tem como objetivo principal gerar conhecimentos para resolver um problema específico, auxiliando na aplicação prática da resolução desse problema (SILVA; MENEZES, 2005, p. 20). Sendo assim, segundo a classificação da natureza da pesquisa, o presente trabalho é uma pesquisa aplicada, pois tem como objetivo angariar conhecimento que será exacerbado na aplicação de um problema em particular.
Caracterizando segundo as fontes de informação, este se enquadra na pesquisa bibliográfica, pois os dados a serem levantados serão buscados em materiais já publicados, escritos na forma de livros, periódicos e outros (SANTOS, 2001, p. 31).
Do ponto de vista de seus objetivos, a pesquisa exploratória é onde se encontra esta monografia. Pesquisa exploratória busca criar uma familiaridade em relação a um fato ou fenômeno. “Quase sempre busca-se esta familiaridade pela prospecção de materiais que possam informar ao pesquisador a real importância do problema” (SANTOS, 2001, p. 26). Esta busca pode informar também o estágio onde se encontram as informações já levantadas e também revelar novas fontes de informação. Normalmente, a pesquisa exploratória é feita com levantamento bibliográfico, buscas em web sites, entrevistas com profissionais da área, entre outros.
Quanto à abordagem do problema este trabalho se encaixa na pesquisa qualitativa, pois os dados colhidos não podem ser medidos, quantificados ou mensurados. “O pesquisador trabalha com a diversidade de dados do objeto de pesquisa” (CÁS, 2008, p. 35). Desta forma, “o processo e seu significado são os focos principais de abordagem” (SILVA; MENEZES, 2005, p. 20).
3.2 ETAPAS
As etapas do para elaboração da monografia são sintetizadas da seguinte forma: a) Levantamento teórico;
b) Levantamento de requisitos do sistema; c) Estudo da API do Google Maps;
d) Estudo da framework Flex; e) Modelagem do sistema; f) Implementação do sistema; g) Testes;
h) Validação.
3.3 ARQUITETURA DA SOLUÇÃO PROPOSTA
Respeitando algumas funcionalidades fundamentais da solução, e ainda carregando raízes culturais, e de posicionamento tecnológico, as exigências de interoperabilidade, e portabilidade, esbarram de maneira geral nas ofertas de Computação em Nuvem. ”Computação em Nuvem é um somatório da evolução de diversas tecnologias, como um grid computing, processamento paralelo, autonomic computing, virtualização, API’s assíncronos, browsers e outros.” (TAURION, 2009, p. 45). Como tendência ainda tem-se o modelo de Software-as-a-Service (SaaS). “O modelo SaaS é um modelo de entrega de software como um serviço de forma diferente do modelo tradicional, no qual a empresa adquire uma licença de uso e instala em seus próprios servidores.” (TAURION, 2009, p.101). No modelo SaaS a instalação não é necessária e as licenças são tratadas de maneira diferente, o usuário paga pelo que usou, a partir do momento que fechou o software, não esta mais pagando pelo serviço. Isso promove uma sensação de que realmente se paga pelo real uso do aplicativo. “Com o SaaS, também não são mais necessários os contratos de manutenção, pois essas atividades ficam a cargo do provedor e não mais da empresa.” (TAURION, 2009, p.101).
Mas com os inúmeros serviços de Computação em Nuvem, a solução proposta deve ser enquadrada em uma arquitetura que contemple SaaS dentro da Computação em Nuvem. Se em um primeiro momento existe a propensão da interpretação de que há apenas uma arquitetura para prover o conceito de Computação em Nuvem, essa propensão perde o sentido ao analisar as camadas que mostram como os serviços de TI são negociados nesse modelo.
A solução proposta se enquadra no nível três, que é a camada de aplicações, onde está o “Software-as-a-Service”. Na arquitetura de Computação em Nuvem, esse nível é o que visivelmente mostra resultados palpáveis aos usuários.
Figura 9 - Arquitetura da Solução Proposta Fonte: Elaborado pelos autores (2009).
3.4 RECURSOS
De recursos humanos, o presente trabalho será realizado por dois analistas de sistema – os mesmos serão responsáveis pela análise, desenvolvimento e testes do sistema proposto, sendo que estes analistas são os autores da monografia. Quanto aos recursos de software, para análise, documentação, linguagem de programação e banco de dados, serão utilizados preferencialmente ferramentas livres ou open-source. O desenvolvimento será com
o software Flex Builder, sendo que é possível obter uma licença completa de estudante sem custo. Os recursos de hardware serão dois computadores pessoais.
3.5 DELIMITAÇÕES
O sistema proposto irá importar, inicialmente, apenas arquivos no formato XLS. Não será desenvolvido neste momento a comparação de dados empresarias com dados “off-the-shelf”.
3.6 MODELAGEM DO SISTEMA
“A atividade de desenvolvimento de software, consiste de um processo de modelagem de sistemas do mundo real, intrinsecamente moldado a um processo de transmissão de mensagens entre grupos de pessoas.” (REZENDE, 2005, p. 7). A definição de modelagem é tão pouco ligada à informática, porém esse conceito evidencia-se quando é necessário descrever um modelo gráfico para auxiliar a criação de um software. É uma coletânea de estruturas fortemente ligados a recursos e padrões, globalmente imersos em lógicas, a fim de alcançar um ou mais objetivos.“A modelagem por objetos vê o mundo como uma coletânea de objetos que interagem entre si e apresentam entre características próprias que são apresentadas pelos seus atributos e operações.” (REZENDE, 2005, p. 201). Dessa forma, dependendo da área do conhecimento, têm-se vários sistemas reais que são abordados sobre algumas óticas para recuperar semântica através de uma modelagem. Uma das abordagens é a de melhoramento e implementação em sistemas, a fim de calibrar condições ideais de funcionamento, focado no objetivo a ser alcançado. Outra abordagem seria a de representação de sistemas reais, que podem ser desenvolvidas com protótipos ou com modelos matemáticos que funcionariam como suporte analítico para o tomador de decisão.
O que pode garantir que todas as diretrizes e a obediência dos objetivos definidos serão cumpridas é a modelagem descrita neste capitulo. Será descrito então toda a modelagem
do sistema proposto e serão abordados os conceitos usados para a representação gráfica de todas as regras e processos que envolvem o desenvolvimento. O uso da linguagem gráfica UML (Unified Modeling Language), é abordado dentro de um modelo de desenvolvimento chamado ICONIX.
3.6.1 UML
A UML é uma linguagem gráfica para visualizar, especificar, construir e documentar artefatos de um software. A UML fornece uma forma padronizada de escrita de um plano de projeto, cobrindo conceitos abstratos como processos de negócio, e funcionalidades do sistema, e também conceitos práticos como classes escritas em uma linguagem de programação específica, esquemas de banco de dados e componentes reutilizáveis de software (BOOCH; RUMBAUGH; JACOBSON, 1998).
As linguagens de programação orientadas a objeto surgiram em meados dos anos 70. As metodologias de programação, confrontando a orientação a objetos e o aumento da complexidade das aplicações, começaram a experimentar novas formas de análise e design. Entre 1989 e 1994, o número de técnicas orientadas a objeto aumentou de 10 para 50, e começou a ficar difícil de encontrar uma que sanasse todas as necessidades. Novas gerações destas técnicas começaram a aparecer, sendo que as mais notáveis eram a BOOCH criado por Grady Booch, a OOSE (Object-Oriented Software Engineering) criada por Ivar Jacobson e a OMT (Object Modeling Technique) de James Rumbaugh. Cada uma destas eram metodologias completas, com pontos fortes e fracos. Mais especificamente, a BOOCH era mais expressiva durante as fases de projeto e construção, a OOSE fornecia um excelente suporte para os casos de uso como um guia para a captura de requisitos, análise e modelagem de alto nível, enquanto a OMT foi mais útil para análise de dados e sistemas com uso intensivo de informação (BOOCH; RUMBAUGH; JACOBSON, 1998).
Várias idéias começaram a surgir na metade dos anos 90, quando Booch, Jacobson e Rumbaugh começaram a adotar idéias e métodos um dos outros, motivando a unificação destas metodologias, basicamente por três razões: eles já estavam se envolvendo um com os outros, a unificação das metodologias traria mais estabilidade e, por fim, a
colaboração dos três traria uma nova metodologia melhor que as três já existentes (BOOCH; RUMBAUGH; JACOBSON, 1998).
A criação da UML começou oficialmente em outubro de 1994, e sua versão 1.0 foi lançada em janeiro de 1997, com a contribuição de grandes corporações como IBM, Microsoft, Rational, Hewlett-Packard, entre outras (BOOCH; RUMBAUGH; JACOBSON, 1998).
3.6.2 ICONIX
ICONIX é um processo de análise e desenvolvimento de software que reserva a agilidade de metodologias como XP (Extreme Programming), e se caracteriza por um poderoso processo de desenvolvimento de software, por usar a linguagem de modelagem UML.
Figura 10 - O processo ICONIX
Na teoria, cada diagrama da UML é potencialmente útil, porém na prática nunca há tempo suficiente para a análise e modelagem dos mesmos. Sempre há uma pressão para que o desenvolvimento seja iniciado, pois o progresso da criação do software tende a ser medido pela quantidade de código existente. O ICONIX, como mostrado na Figura 10, é minimalista, com foco entre os casos de uso e o código, e dividido em dois workflows. O workflow dinâmico descreve o comportamento, enquanto o workflow estático descreve a estrutura (ROSEMBERG; STEPHENS, 2007, p. 1).
O ICONIX é dirigido por casos de uso como o RUP e minimalista como o XP, porém mais simples se comparado ao RUP e suficiente onde o XP não é. Desta forma, o ICONIX situa-se em algum ponto entre a complexidade e abrangência do RUP e a simplicidade e rapidez do XP, porém contemplando as etapas de análise e modelagem que são descartadas no XP (ROSENBERG; SCOTT, 2001).
Usando ferramentas mais simples, o resultado acaba sendo diferente de um modelo gerado com ferramentas mais complexas. Ao utilizar ferramentas simples, há maior possibilidade de os clientes investidores participarem ativamente do trabalho de modelagem, proporcionando uma compreensão melhor do que eles precisam (AMBLER, 2004, p. 120).
A criação de bons modelos com ICONIX é simples caso mantenha-se o foco em questões de importância fundamental sobre o sistema a ser construído e recusar-se em perder tempo com questões de modelagem supérfluas. Esta filosofia está no coração do processo ICONIX (ROSENBERG; SCOTT, 2001).
O processo ICONIX faz uso racionalizado da UML, mantendo um foco nítido sobre a rastreabilidade dos requisitos (ROSENBERG; SCOTT, 2001). Desta forma o ICONIX possui recursos atrelados as suas atividades que nos garante que os requisitos estão sendo atendidos. O ICONIX é composto pelos seguintes marcos ou estágios (ROSEMBERG; STEPHENS, 2007, p. 3-4):
• Requisitos;
• Análise e Projeto Preliminar; • Projeto Detalhado;
• Implementação.
3.6.2.1 Requisitos
Nesta etapa, segundo Rosemberg (2007), devem-se realizar as seguintes tarefas: a) Requisitos Funcionais: Definir aquilo que o sistema será capaz de fazer;
b) Modelo de Domínio: Identificar, no mundo real, os objetos e seus relacionamentos;
c) Casos de uso: Definir como o usuário e o sistema irão interagir, escrevendo os primeiros casos de uso. Recomenda-se começar com protótipos de tela para auxiliar a identificar todos os casos de uso a serem implementados;
d) Revisão dos requisitos: Para ter a certeza de que todos os casos de uso estão de acordo com as expectativas do cliente.
Figura 11 - ICONIX – Requisitos
3.6.2.2 Análise e Projeto Preliminar
Segundo Rosemberg (2007), esta etapa se repete para cada caso de uso identificado:
a) Análise de Robustez: Atualizar o diagrama de domínio e desenhar o diagrama de robustez, permitindo a visualização de classes antes não identificadas; b) Diagrama de classes: Neste momento, o diagrama de domínio vai ganhando
mais informações, se transformando no esboço do diagrama de classes; c) Atualizar o diagrama de casos de uso.
Figura 12 - Análise e Projeto Preliminar
Fonte: ROSEMBERG; SCOTT (2001, http://www.informit.com/articles/article.aspx?p=167902&seqNum=5)
3.6.2.3 Projeto Detalhado
