UNIVERSIDADE DO SUL DE SANTA CATARINA HALLAN MEDEIROS MRIO SRGIO DA SILVEIRA

CEOMAPS UMA SOLUO DE SISTEMAS DE INFORMAO GEOGRFICA

Palhoa 2010

HALLAN MEDEIROS MRIO SRGIO DA SILVEIRA

CEOMAPS UMA SOLUO DE SISTEMAS DE INFORMAO GEOGRFICA

Trabalho de Concluso de Curso apresentado ao Curso de Graduao em Sistemas de Informao da Universidade do Sul de Santa Catarina, como requisito parcial obteno do ttulo de Bacharel em Sistemas de Informao.

Orientador: Prof. Vera Rejane N. Schuhmacher, Msc.

Palhoa 2010

HALLAN MEDEIROS MRIO SRGIO DA SILVEIRA

CEOMAPS UMA SOLUO DE SISTEMAS DE INFORMAO GEOGRFICA

Este Trabalho de Concluso de Curso foi julgado adequado obteno do ttulo de Bacharel em Sistemas de Informao e aprovado em sua forma final pelo Curso de Sistemas de Informao, da Universidade do Sul de Santa Catarina.

Palhoa, 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. Snchez D'Alotto, Ph.D. Universidade do Sul de Santa Catarina - UNISUL

 minha me, Jane, a maior responsvel pela minha formao acadmica 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 so os maiores responsveis pela minha formao e foram de grande apoio nesta longa caminhada: meus pais, Cinzio e Albertina e minha irm Elaine. Mrio Srgio da Silveira

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 Informao da Universidade do Sul de Santa Catarina. Aos nossos pais, pelo apoio, incentivo e compreenso nos momentos difceis. 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 Mrio Srgio da Silveira

No 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 Informao Geogrfica (SIG), porm, a utilizao destas ferramentas feita somente por programadores que estudaram sua estrutura. Este fato distancia a possibilidade de usurios de diferentes reas lidarem com esta tecnologia, assim como as empresas que no possuem recurso humano-tecnolgico para tal. Neste sentido, a proposta do presente projeto a construo de um Sistema de Informao que permita a importao de dados geogrficos a partir de uma planilha eletrnica para posterior visualizao de seus dados distribudos em um mapa, como forma de simplificar o uso deste tipo de ferramenta. A utilizao de planilhas eletrnicas popularmente difundida e utilizada como sada de dados de quase todos os sistemas de informao 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 usurios 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 visualizao dos mapas utiliza a API do Google Maps. A validao foi realizada com dois usurios: um CEO de uma empresa de grande porte e uma gerente de um departamento pblico na rea da sade. O trabalho apresenta tambm a aplicao do ICONIX, um processo de desenvolvimento de software definido como intermedirio entre a complexidade e abrangncia do RUP e simplicidade e rapidez do XP, e que utiliza a notao UML. Palavras-chave: Sistema de Informao Geogrfica. Web Mapping. Geoinformao.

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. Keywords: Geographic Information System. Web Mapping. Geoinformation.

LISTA DE ILUSTRAES

FIGURA 1 INTERAO ENTRE UM SISTEMA SIG E O MUNDO REAL..............22 FIGURA 2 - INTERLIGANDO DADOS EXTERNOS COM SIG....................................30 FIGURA 3 - ESTRUTURA DE UM SISTEMA WEB SIG................................................33 FIGURA 4 - CENRIO DE UM PLANO DE VIAGEM....................................................34 FIGURA 5 - UTILIZANDO O SERVIO GOOGLE MAPS............................................35 FIGURA 6 - UTILIZANDO O STREET VIEW..................................................................36 FIGURA 7 - CAMADAS DO SERVIO GOOGLE MAPS...............................................37 FIGURA 8 - LATITUDE E LONGITUDE..........................................................................39 FIGURA 9 - ARQUITETURA DA SOLUO PROPOSTA............................................43 FIGURA 10 - O PROCESSO ICONIX.................................................................................46 FIGURA 11 - ICONIX REQUISITOS...............................................................................48 FIGURA 12 - ANLISE E PROJETO PRELIMINAR......................................................49 FIGURA 13 - PROJETO DETALHADO.............................................................................50 FIGURA 14 IMPLEMENTAO.....................................................................................51 FIGURA 15 - DIAGRAMA DE NECESSIDADES DOS STAKEHOLDERS..................52 FIGURA 16 - REQUISITOS FUNCIONAIS E REGRAS DE NEGCIO.......................53 FIGURA 17 - REQUISITOS NO FUNCIONAIS.............................................................59 FIGURA 18 - PROTTIPO DE TELA DE LOGIN...........................................................64 FIGURA 19 - PROTTIPO DE TELA DE ENTRADA.....................................................64 FIGURA 20 - PROTTIPO DE TELA DE IMPORTAO............................................65 FIGURA 21 - PROTTIPO DE TELA DE VISUALIZAO DE MAPA......................66 FIGURA 22 - DIAGRAMA DE DOMNIO.........................................................................67 FIGURA 23 - DIAGRAMA DE ATORES............................................................................68 FIGURA 24 - DIAGRAMA DE CASOS DE USO...............................................................69 FIGURA 25 - DIAGRAMA DE ROBUSTEZ CRIAR NOVA CONTA.........................78 FIGURA 26 - DIAGRAMA DE ROBUSTEZ IMPORTAR PLANILHA ELETRNICA........................................................................................................................79 FIGURA 27 - DIAGRAMA DE SEQNCIA - CRIAR NOVA CONTA........................80

FIGURA 28 - DIAGRAMA DE SEQNCIA - IMPORTAR PLANILHA ELETRNICA........................................................................................................................81 FIGURA 29 - DIAGRAMA DE CLASSES PERSISTENTES...........................................83 FIGURA 30 - DIAGRAMA ENTIDADE-RELACIONAMENTO.....................................85 FIGURA 31 - TECNOLOGIAS E FERRAMENTAS.........................................................86 FIGURA 32 - TELA DE LOGIN...........................................................................................94 FIGURA 33 - TELA DE CRIAO DE NOVA CONTA..................................................95 FIGURA 34 - TELA DE RECUPERAO DE SENHA....................................................96 FIGURA 35 - TELA DE ATIVAO DE CONTA............................................................97 FIGURA 36 - TELA PRINCIPAL........................................................................................98 FIGURA 37 - TELA DE IMPORTAO............................................................................99 FIGURA 38 - TELA DE VISUALIZAO DE DADOS DO MAPA.............................100 FIGURA 39 - TELA DE VISUALIZAO DE MAPA...................................................101 FIGURA 40 - TELA DE VISUALIZAO DE GRFICO............................................102 FIGURA 41 - TELA DE VISUALIZAO DE MEUS MAPAS.....................................103 FIGURA 42 - TELA DE CONFIGURAES..................................................................104

LISTA DE QUADROS

QUADRO 1 REQUISITOS FUNCIONAIS DE LOGIN..................................................55 QUADRO 2 REQUISITOS FUNCIONAIS DE USURIO.............................................57 QUADRO 3 REQUISITOS FUNCIONAIS DE ADMINISTRADOR............................57 QUADRO 4 REQUISITOS FUNCIONAIS DE GOOGLE MAPS.................................58 QUADRO 5 REQUISITOS FUNCIONAIS DE SISTEMA.............................................58 QUADRO 6 REQUISITOS NO FUNCIONAIS DE USABILIDADE.........................60 QUADRO 7 REQUISITOS NO FUNCIONAIS DE SEGURANA............................61 QUADRO 8 REQUISITOS NO FUNCIONAIS DE SUPORTABILIDADE..............61 QUADRO 9 REQUISITOS NO FUNCIONAIS DE DESEMPENHO.........................61 QUADRO 10 REGRAS DE NEGCIO............................................................................63 QUADRO 11 DOCUMENTAO DE CASO DE USO CRIAR NOVA CONTA.. . .70 QUADRO 12 DOCUMENTAO DE CASO DE USO IMPORTAR PLANILHA ELETRNICA........................................................................................................................71 QUADRO 13 DOCUMENTAO DE CASO DE USO LISTAR PLANILHA/MAPAS DE SUA CONTA...............................................................................71 QUADRO 14 DOCUMENTAO DE CASO DE USO VISUALIZAR PLANILHA/MAPA................................................................................................................72 QUADRO 15 DOCUMENTAO DE CASO DE USO VISUALIZAR GRFICO COM DADOS DO MAPA......................................................................................................72 QUADRO 16 DOCUMENTAO DE CASO DE USO EDITAR PLANILHA/MAPA................................................................................................................73 QUADRO 17 DOCUMENTAO DE CASO DE USO EXCLUIR PLANILHA/MAPA................................................................................................................73 QUADRO 18 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................74 QUADRO 19 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................74 QUADRO 20 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................75 QUADRO 21 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................75

QUADRO 22 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................76 QUADRO 23 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................76 QUADRO 24 DOCUMENTAO DE CASO DE USO LISTAR USURIOS CADASTRADOS....................................................................................................................77

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 Negcio RNF - Requisito No Funcional RUP - Rational Unified Process SaaS - Software-as-a-Service SAD - Sistemas de Apoio a Deciso SDSS - Spatial Decision Support Systems SGML - Standard Generalized Markup Language

SIG Sistema de Informao Geogrfica 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 eletrnica Microsoft Excel XML - Extensible Markup Language XP - Extreme Programming

SUMRIO

1 INTRODUO....................................................................................................................19 1.1 PROBLEMTICA.............................................................................................................20 1.2 OBJETIVOS.......................................................................................................................21 1.2.1 Objetivo Geral................................................................................................................21 1.2.2 Objetivos Especficos.....................................................................................................21 1.3 JUSTIFICATIVA...............................................................................................................22 1.4 ESTRUTURA DA MONOGRAFIA..................................................................................23 2 REVISO BIBLIOGRFICA...........................................................................................24 2.1 SISTEMAS DE INFORMAO.......................................................................................24 2.2 INTERNET.........................................................................................................................24 2.2.1 A Histria da Internet...................................................................................................25 2.2.2 World Wide Web...........................................................................................................26 2.3 WEB MAPPING.................................................................................................................27 2.4 SISTEMAS DE INFORMAO GEOGRFICA............................................................29 2.4.1 Web SIG..........................................................................................................................32 2.4.2 Google Maps...................................................................................................................35 2.4.3 A API do Google Maps..................................................................................................38 2.4.3.1 Geocoding.....................................................................................................................40 3 MTODO.............................................................................................................................41 3.1 CARACTERIZAO DO TIPO DE PESQUISA............................................................41 3.2 ETAPAS.............................................................................................................................42 3.3 ARQUITETURA DA SOLUO PROPOSTA................................................................42 3.4 RECURSOS........................................................................................................................43 3.5 DELIMITAES...............................................................................................................44 3.6 MODELAGEM DO SISTEMA..........................................................................................44 3.6.1 UML................................................................................................................................45 3.6.2 ICONIX...........................................................................................................................46 3.6.2.1 Requisitos......................................................................................................................48 3.6.2.2 Anlise e Projeto Preliminar.........................................................................................49 3.6.2.3 Projeto Detalhado..........................................................................................................49 3.6.2.4 Implementao .............................................................................................................50

3.6.3 Especificao de requisitos............................................................................................51 3.6.4 Necessidades dos Stakeholders.....................................................................................51 3.6.5 Requisitos Funcionais....................................................................................................52 3.6.5.1 Requisitos Funcionais de Login....................................................................................54 3.6.5.2 Requisitos Funcionais de Usurio.................................................................................55 3.6.5.3 Requisitos Funcionais de Administrador......................................................................57 3.6.5.4 Requisitos Funcionais de Google Maps........................................................................58 3.6.5.5 Requisitos Funcionais de Sistema.................................................................................58 3.6.6 Requisitos No Funcionais............................................................................................59 3.6.6.1 Requisitos No Funcionais de Usabilidade...................................................................60 3.6.6.2 Requisitos No Funcionais de Segurana.....................................................................61 3.6.6.3 Requisitos No Funcionais de Suportabilidade............................................................61 3.6.6.4 Requisitos No Funcionais de Desempenho.................................................................61 3.6.7 Regras de negcio...........................................................................................................62 3.6.8 Prototipao....................................................................................................................63 3.6.9 Modelo de domnio.........................................................................................................66 3.6.10 Identificao dos atores...............................................................................................68 3.6.11 Casos de Uso.................................................................................................................68 3.6.12 Documentao dos Casos de Uso................................................................................70 3.6.12.1 Diagrama de Robustez................................................................................................77 3.6.12.2 Diagrama de Seqncia...............................................................................................79 3.6.13 Diagrama de Classes....................................................................................................82 3.6.14 Diagrama Entidade-Relacionamento.........................................................................84 3.7 CONSIDERACES FINAIS..............................................................................................85 4 DESENVOLVIMENTO......................................................................................................86 4.1 TECNOLOGIAS E FERRAMENTAS...............................................................................86 4.1.1 Java..................................................................................................................................87 4.1.2 Adobe Flash....................................................................................................................87 4.1.3 Adobe Flex......................................................................................................................87 4.1.4 Adobe BlazeDS...............................................................................................................88 4.1.5 Apache Tomcat...............................................................................................................89 4.1.6 MySQL............................................................................................................................89 4.1.7 Eclipse.............................................................................................................................90 4.1.8 Adobe Flash Builder......................................................................................................90

4.1.9 Adobe Fireworks............................................................................................................91 4.1.10 Balsamiq Mockups.......................................................................................................91 4.1.11 Subversion ...................................................................................................................92 4.2 HISTRICO DE DESENVOLVIMENTO........................................................................92 4.3 APRESENTAO DO SISTEMA....................................................................................94 4.3.1 Tela de Login..................................................................................................................94 4.3.2 Tela de Criao de Nova Conta....................................................................................95 4.3.3 Tela de Recuperao de Senha.....................................................................................96 4.3.4 Tela de Ativao de Conta............................................................................................97 4.3.5 Tela Principal.................................................................................................................98 4.3.6 Tela de Importao........................................................................................................99 4.3.7 Tela de Visualizao de Dados do Mapa....................................................................100 4.3.8 Tela de Visualizao de Mapa....................................................................................101 4.3.9 Tela de Visualizao de Grfico.................................................................................102 4.3.10 Tela de Visualizao de Meus Mapas.......................................................................103 4.3.11 Tela de Configuraes...............................................................................................104 4.4 VALIDAO...................................................................................................................104 4.5 CONSIDERAES FINAIS............................................................................................106 5 CONCLUSES E TRABALHOS FUTUROS................................................................107 APNDICES........................................................................................................................115 APNDICE A MANUAL DO USURIO......................................................................116 116 117

19 1 INTRODUO

A Internet est cada vez mais presente em nossas vidas. De acordo com Internetworldstats (2009) a Internet atualmente utilizada por quase 25% da populao mundial, algo em torno de 1600 milhes de pessoas. As empresas tambm fazem parte da estatstica, e esto 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 Informao Geogrfica (GIS - Geographic Information System) como apoiador na tomada de deciso. A rea de Sistemas de Informao Geogrfica (SIG) teve um grande avano por contribuio da empresa Google quando foi lanado, em fevereiro de 2005, ainda em sua verso beta, o Google Maps, que um servio gratuito de visualizao de mapas por meio da Internet, no qual possibilita pesquisas por locais e traar rotas entre dois pontos (PETERSON, 2008). A partir disto se pode ento verificar a evidenciao de um conceito chamando de Web Mapping. De 2005 at hoje este conceito foi marcante em aplicaes focadas somente para web, onde poderiam ser observados em alguns sites, mapas com localizaes diversas, criados usando os recursos que a API (Application Programming Interface) do Google Maps fornece. Esta API possibilita personalizao de recurso e adaptao do mesmo sua aplicao. Sabe-se que na sua maioria, as empresas que geram dados histricos de faturamento e que tem um alto resultado financeiro, possuem uma rea de atuao geogrfica relativamente grande. E sabendo que os sistemas de informao de tais empresas so anteriores a exploso da Web 2.0, encontra-se ento um grande nicho de atuao para sistemas baseados em Web SIG. Este trabalho vai se concentrar na criao de uma ferramenta Web SIG, possibilitando anlises, gerando grficos e informaes de nvel gerencial, utilizando a API do Google Maps.

20 1.1 PROBLEMTICA

Em se tratando de sistemas de informao geogrficos, o aumento das fontes de informao, e das formas de se obter dados, aliado ao aumento considervel do nmero de sistemas e aplicaes disponveis, criou a necessidade de se fomentar a rea de pesquisa em interoperabilidade de sistemas SIG. Esta rea de aplicao focada na camada de dados suporta a entrada de dados externos que exponencialmente esto expandindo em nmero e volume somados aos conceitos de mdias locativas e territrios computacionais. O desafio encontrado dentro desta rea de pesquisa. Uma anlise dos trs pilares que compem a problemtica da interoperabilidade de sistemas SIG, que so: dados, interface e processo. Observa-se um desafio ontologicamente ainda mais complexo dentro do tratamento realizado sobre os dados e sua reutilizao. Sem uma interface de entrada de dados que suporte formatos genricos, percebe-se total inoperncia dos processos e manipulao de dados, impossibilitando maiores anlises. O processo como sendo a maneira de intercambiar os dados entre sistemas, o que possibilitaria a obteno dos dados de geo-referenciao, apresentaria ento a maior problemtica de um sistema SIG, e o fator que mais distanciaria os usurios dos resultados pretendidos. Este entendimento tende a direcionar os desenvolvedores ao desenvolvimento de um sistema SIG focado no usurio e na facilidade em se adicionar dados externos ao sistema. Ainda dentro da camada de processo de uma aplicao 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 informaes de espaos geogrficos em funo de sua mobilidade. No desafio de todas as problemticas de um sistema SIG em sua interoperabilidade e extenso da abstrao do mundo real, e as formas do sistema contemplar as novas mdias digitais, ainda tem-se como desafio a decomposio do paradigma da invaso de privacidade para gerar subsdios para ento poder compor novos arranjos espaciais polticos e urbanos.

21 1.2 OBJETIVOS

1.2.1

Objetivo Geral

O objetivo geral deste trabalho desenvolver um Sistema de Informao que permita visualizar dados de qualquer natureza distribudos em um mapa, sendo que nestes dados a componente geogrfica deve estar definida. A importao dos dados ser a partir de uma planilha eletrnica, como forma de simplificar o uso da ferramenta, fornecendo informaes gerenciais para empresas e contribuindo nos aspectos de anlise de dados estatsticos.

1.2.2

Objetivos Especficos

So objetivos especficos do projeto: Desenvolver uma aplicao Web, em Java, utilizando a API do Google Maps como interface de visualizao de dados proveniente de uma fonte externa; Utilizar a framework Flex para criao das interfaces; Possibilitar uma forma genrica de integrao de dados de sistemas externos e a aplicao a ser desenvolvida;

22

1.3

JUSTIFICATIVA

So 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 no so um acesso que se possa considerar como facilitado. J possvel observar, porm, esforos em direo s mdias locativas, e a sistemas SIG, que contemplem flexibilidade e simplicidade, tendncia a resultados significativos na tomada de deciso das empresas. A localizao de novos pontos de pujana de negcios, estimulado por esforos de vendas, e as genricas transformaes do comportamento da sociedade, alinhado at mesmo ao desenvolvimento catico das cidades, so elementos conexos em um sistema, que interagem em duas vias, em que as mdias locativas impulsionam transformaes no espao urbano, e o espao urbano responde com comportamentos consumistas que exige recursos computacionais de um sistema Web SIG.

Figura 1 Interao entre um sistema SIG e o mundo real Fonte: BERNHARDSEN, ( 2002, p. 2)

Na Figura 1 a abstrao ou simplificao do mundo real, possibilitada por um banco de dados contendo informaes geogrficas, e a associao destas informaes a ferramentas que tratem nesse momento, da qualidade das informaes, temos uma via dinmica, em que o mundo real influenciar a maneira de serem criadas e usadas essas

23 ferramentas. Em contrapartida os resultados gerados pelo sistema SIG traro apoio para a tomada de deciso dentro do mundo real. A API do Google Maps possibilita a gerao de um arquivo com extenso kml e o mesmo ter que ser gerado com as informaes pertinentes a anlise da empresa em sua atuao. Em seguida este arquivo pode ser importado em qualquer servio de Web Mapping do Google (Google Maps ou Google Earth). Porm a manipulao deste arquivo possibilitada somente por desenvolvedores que estudaram sua estrutura, e j conhecem a API da ferramenta. Este fato distancia a possibilidade de usurios de diferentes reas lidarem com esta tecnologia, assim como as empresas que no possuem recurso humano-tecnolgico para tal. Isso impossibilita a anlise das informaes locativas desejadas. O estreitamento na relao 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 anlises de dados estatsticos e informaes, em sua grande parte, so realizadas com planilhas eletrnicas ou as chamadas spreadsheet, popularmente difundida e utilizada como sada de dados de quase todos os sistemas de informao j existentes. Outras formas de organizao e sada de dados tambm so utilizadas, e compem um cenrio em que as mdias locativas compostas por sistemas SIG teriam que suportar este tipo de entrada de dados. O sistema SIG proposto ser desenvolvido neste cenrio, e possibilitar entradas de dados nos formatos comuns, xls, csv, txt e kml, atuando dentro da necessidade de simplicidade e transparncia, formatando uma maneira de anlise focada nas competncias dos gestores e executivos.

1.4

ESTRUTURA DA MONOGRAFIA

A estrutura deste trabalho formada por 5 captulos. O captulo 1 descreve os objetivos e definies da monografia. No captulo 2 tem-se reviso bibliogrfica. Nele so abordados temas como a histria e evoluo da Internet, Sistemas de Informao, Web Mapping e SIG. O captulo 3 constitudo pela arquitetura e modelagem do sistema proposto, sustentado pelo processo ICONIX. No captulo 4 apresentam-se o desenvolvimento, apresentao e validao do sistema. Por fim, o captulo 5 descreve as concluses e trabalhos futuros.

24 2 REVISO BIBLIOGRFICA

Neste captulo apresentam-se os fundamentos tericos que iro sustentar o presente trabalho. Os assuntos abordados servem como base para compreenso e fundamentao de conceitos como Web, do servio de Web Mapping, Sistemas de Informao Geogrficos e Web SIG.

2.1

SISTEMAS DE INFORMAO

Conforme Rezende (2003), Sistema de Informao significa um conjunto de partes que geram informao. Informao significa dados organizados: processados, limpos e em uma nova estrutura, sem redundncia (MICHALEWICZ; MICHALEWICZ; SCHMIDT, 2006). Dados so coletados diariamente na forma de bits, nmeros, smbolos ou objetos. De acordo com Rezende, "o dado tomado isoladamente no transmite conhecimento, ou seja, no contm um significado claro". Sendo assim, um Sistema de Informao pode ser definido como um conjunto de componentes que processam dados e por meio deste processamento geram informao. Um sistema um conjunto de partes que interagem entre si para atingir objetivos (REZENDE, 2003), e o objetivo de um Sistema de Informao gerar informao.

2.2

INTERNET

A Internet, poucos anos aps a sua criao, causou um enorme impacto social em todo o planeta. Estima-se que, atualmente, 1/4 da populao mundial acesse a Internet regularmente. Muitos Sistemas de Informao 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 so usados como se tivessem o mesmo significado, mas no a mesma coisa. Internet um sistema

25 global de comunicao. uma infra-estrutura de hardware e software que permite a comunicao entre computadores. World Wide Web um servio que funciona via Internet. um enorme repositrio de documentos e outros arquivos, ligados por Hiperlinks e Uniform Resource Locators (URL).

2.2.1

A Histria da Internet

A origem da Internet est atrelada a uma mensagem enviada em 29 de Outubro de 1969. Foi transmitida da Universidade de Califrnia para a Universidade de Stanford, por computadores conectados atravs de um prottipo chamado Interface Message Processors (IMP), que interligava computadores a ARPAnet, um projeto da Agncia de Projetos de Pesquisa Avanada(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 criao da ARPANet foi militar. A inteno desta grande rede era manter os lderes 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 necessrio criar um novo protocolo, pois o NCP no foi projetado para interligar uma grande rede. Vint Cerf, junto com outros membros da ARPAnet, desenvolveram o protocolo Transmission Control Protocol (TCP), e logo aps foi criado o Transmission Control Protocol/Internet Protocol (TCP/IP). Com o TCP/IP, cada computador tem uma identificao numrica nica dentro da rede, chamado de endereo IP. Pela dificuldade em decorar nmeros de identificao, foi criado uma tabela que mapeava o endereo de IP de cada computador da rede com um nome para o computador, pois seria mais fcil de lembrar. Cada computador da rede tinha esta tabela, mas o crescimento do nmero de computadores ligados a Internet tornou este mtodo invivel. Paul Mockapetris, em 1982, criou o Domain Name System (DNS), um sistema de traduo de nomes hierrquico e distribudo (COSTA, 2007). A tarefa de fazer a ligao entre o nome do

26 computador e seu endereo IP passou a ser de servidores DNS, e no de cada computador da rede.

2.2.2

World Wide Web

A Internet no qual se conhece atualmente comeou com Tim Berners-Lee. Ele criou, em 1990, um conjunto de regras baseadas na linguagem de marcao Standard Generalized Markup Language (SGML), surgindo assim o Hyper Text Markup Language (HTML). Os arquivos HTML ento seriam gravados em discos rgidos de um computador de uma rede. Estes arquivos seriam acessados por meio de seu nome, precedidos pelo endereo IP do computador ou domnio, sempre nicos, e do diretrio onde estava gravado. A este endereo foi dado o nome de URL. Para acessar os arquivos, foi criado o protocolo Hyper Text Transfer Protocol (HTTP). Tim Berners-Lee uniu a idia do Hipertexto com TCP/IP e DNS, sendo esta unio a World Wide Web, utilizada hoje por todos. Para Deitel (2003), foi a introduo da World Wide Web (ou simplesmente Web) na Internet que tornou a mesma um dos maiores e principais meios de comunicao mundial. Para visualizar as pginas HTML, Tim Berners-Lee, em 1990, criou o primeiro navegador da Internet, chamado WorldWideWeb, que interpretava as tags HTML e montava a pgina visualmente na tela do computador. Tim trabalhou alguns meses no projeto, e montou o primeiro servidor Web e o primeiro cliente Web em seu prprio computador (MCPHERSON, 2009, p.51). Vrios 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, alm de ser o primeiro Browser com interface grfica, tinha suporte a vrios tipos de multimdia, formulrios, histrico de navegao e favoritos, se tornando rapidamente o mais popular navegador no-comercial (STEWART, 2009). O Mosaic foi a base para os principais navegadores da Internet atualmente: O Internet Explorer e o Mozilla Firefox. Com a criao da Web e do Browser, um novo e imenso territrio inexplorado surgiu, onde proliferavam pginas pessoais e surgiam celebridades instantneas. As pginas eram estticas em HTML e o comrcio eletrnico no era cogitado de forma sria. Conforme foram surgindo novas tecnologias, como PHP, ASP, Java, Javascript e Flash, a interao com

27 os usurios se tornou mais dinmica, possibilitando o comrcio eletrnico, salas de bate-papo, entre outros. As empresas "ponto.com" comeavam 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 comrcio (SAMPAIO, 2007, p.4). O termo Web 2.0 foi utilizado por Tim O'Reilly, CEO da O'Reilly Media, em 2003, e no significa uma mudana de tecnologia, mas sim uma mudana de foco. A percepo foi que os websites deveriam se integrar, ao invs de cada um ser uma ilha isolada de informaes (SAMPAIO, 2007). Surgem os grandes portais colaborativos, como os Wikis (Wikipedia), sites de relacionamento (Twitter, Orkut), blogs (Wordpress, Blogger), feeds RSS e servios gratuitos para serem usados e compartilhar contedo, 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 atrs, pessoas desenhavam e coloriam os mapas mo. A anlise dos dados e a criao dos mapas com os resultados eram lentas e trabalhosas (MITCHELL, 2005). O homem moderno comeou a desenhar o espao onde vive, porm os recursos para esses feitos sempre foram rudimentares, e eram usados mtodos artsticos para conseguir chegar a uma maior aproximao do mundo real, em uma representao grfica manuscrita. A experincia 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 revoluo a partir da atuao crtica e consciente do cotidiano - criao de mapas subjetivos (LEO, 2004, p.9). Este projeto resgatava o buscar afetivo nos espaos pblicos e contribuiu em muito na evoluo das formas de se tratar mapas. Cunhado em 1984 por William Gibson o termo Ciberespao trs dcadas depois, comeou a se tornar corelacionado com a idia de computacionar e digitalizar mapas. Camalenico, elstico, ubquo, e irreversvel, o ciberespao no se reduz a definies rpidas (LEO, 2004). As representaes em mapas eram perecveis s transformaes, e fugazes aos contornos do mundo, mas, indiscutivelmente indispensvel para estabelecer as primeiras formas de se representar um ciberespao.

28 Traduzir fenmenos do universo que esto alm dos sentidos humanos em algo palpvel e usual, faz lembrar que artistas romnticos acreditam que alguns efeitos e fenmenos so irrepresentveis. Em contrapartida os artistas de mapeamento de dados almejam o contrrio, buscam representar graficamente o mundo, de uma maneira perceptvel pelos sentidos cognitivos dos humanos. Isso aproxima em muito a arte de visualizao de dados com a cincia moderna. No inicio do sculo XX a arte se distanciou de sua mais importante funo: retratar o ser humano. E partiu para abstrao de objetos, prdios, ruas, indstrias e recentemente dados, que conseqentemente estaria ligado indiretamente com as atividades humanas dentro de uma rede (Internet). Uma questo importante segundo Manovich (2004) a escolha arbitrria versus escolhas motivadas no mapeamento. Uma vez que os computadores permitem facilmente mapear quaisquer conjuntos de dados em outro conjunto, muitas vezes fcil indagar por que o cartgrafo escolheu esse ou aquele mapeamento, quando incontveis outras escolhas seriam possveis. Os meios computacionais fazem todo esse mapeamento parecer arbitrrios, pois inmeras possibilidades se desdobram quando se busca representar um ciberespao, a menos que sejam usadas estratgias espaciais para motivar as escolhas. Um exemplo sobre motivao o da construo do Museu Judaico de Berlin (Jewish Museum Berlin), de Daniel Liberskind. Ele construiu um mapa que mostrava as casas dos judeus que residiam prximo ao futuro museu antes da II Grande Guerra. Ligando os pontos dos endereos ele montou uma grande rede que foi projetada ao topo do prdio, que teve como resultado um grande concentrao de formas arbitrarias, que compunham janelas com ngulos que apontavam para vrias referncias visuais. No Museu Judaico o passado literalmente penetra no presente. Em vez de algo efmero, aqui o espao de dados materializado, tornando-se uma espcie de escultura monumental (MANOVICH, 2004, p. 159). Sendo assim, uma questo ento formada: por que Liberskind comps a rede com os endereos dessa forma? Dados coletados trabalhosamente so tramados quase que cientificamente, so jogados arbitrariamente sobre as formas do prdio. Esse exemplo mostra perfeitamente o paradigma do mapeamento de dados dentro de um ciberespao. Uma metfora usada pelos situacionistas na dcada de 60 era deixar fazer com que o habitante tivesse uma nova percepo de seu habitat, usando um mtodo que eles chamavam de ostranenie ou estranhamento espacial. Navegar por Paris usando um mapa de Londres (MANOVICH, 2004, p. 160). Potico, isso transcende aos dias atuais ao se deparar com um servio de Web Mapping, e mergulha-se num ciberespao, e caminha-se por lugares que parecem ser j

29 conhecidos, ou com a surpresa de novos lugares e a exatido dos detalhes impressionaria um artista romntico, porm os dados coletados incansavelmente por artistas programadores arbitrariamente so chocados com a nossa percepo do mundo em que vivemos. "Os mapas para Web podem disponibilizar aos usurios o acesso s informaes geogrficas de modo interativo, dinmico e constantemente atualizado" (MARISCO, 2004).

2.4

SISTEMAS DE INFORMAO GEOGRFICA

A base de um SIG encontra-se em Sistemas de Informao e Geografia. De uma forma simplificada, um sistema SIG mescla informao - dados - com localizaes geogrficas, digitalmente (BERNHARDSEN, 2002). Um SIG auxilia nos negcios, possibilitando novas estratgias, 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 avano da Internet, e-commerce e sistemas web 2.0 foram alguns motivadores para o avano de sistemas SIG. A Internet tem sido utilizada para negcio empresarial desde 1980, atravs de Eletronic Data Interchange (EDI), mas o controle das transaes no era nada amigvel. Com o advento da World Wide Web, e do Browser uma nova forma de negcio se tornou possvel: o comrcio eletrnico, ou e-commerce (PICK, 2007). O ecommerce cresceu rapidamente, e comeou a se relacionar com o SIG, pois localizaes espaciais passaram a estar diretamente envolvidas nos negcios. O envolvimento fsico de sistemas SIG com o comercio eletrnico ultrapassa a motivao de facilidade e agilidade, j se pode acreditar que a explorao de paisagens e seus dados, e a relao entre elas, que ainda no foram cruzadas, so intrinsecamente resultados de um sistema SIG atuando como suporte na criao de novas alternativas de comrcio e de desenvolvimento. A informtica altera a natureza do lugar, altera tambm a natureza de estar no lugar, de movimentar-se pelo lugar e de colaborao no lugar (LEO, 2004). Quando Lucia Leo comenta sobre a informtica no aspecto de influencias e colaborao, remete ao conceito de rede, enquanto estrutura fsica de comunicao, entrelaados com pacotes que

30 se movimentam sobre ela, comunicao/colaborao/comrcio, animao/browser/servidor, que todo o contexto da Internet, com a adio de corpo e lugar numa prtica de SIG. Projetos de pesquisa de mercado para empresas era um processo muito trabalhoso e demorado, onde os empresrios 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 so dados prontos para uso de empresas, como estatsticas de mercado e outras informaes relevantes, todo esse trabalho pode ser feito em pouco tempo. Estes sistemas podem criar, em poucos minutos, numerosos mapas que sobrepe informaes sobre o inventrio de dados do Censo a imagens fotogrficas obtidas por satlite.

Figura 2 - Interligando dados externos com SIG Fonte: KORTE (2001, p. 53)

A Figura 2 mostra um exemplo de um SIG interligando informaes internas da prpria organizao e externas off-the-shelf, fazendo com que estas deixem de ser uma ilha

31 de informaes e passem a ter valor agregado. Os mapas gerados podem sobrepor as informaes organizacionais com dados como taxas, vendas globais, localizao de servios pblicos, valores de taxas, entre outros, mostrando ligaes entre dados que sem um SIG seria difcil visualizar (KORTE, 2003). Pode-se dizer ainda que a localizao geogrfica um importante atributo de atividades, polticas, estratgias e planos. Sistemas de Informao Geogrficos uma classe especial de Sistemas de Informao que processa no apenas eventos, atividades e nmeros, mas tambm onde estes eventos, atividades e nmeros aconteceram ou existiram em um, determinado corte temporal (LONGLEY, 2005, p.4). Como a localizao importante, muitos problemas sociais podem ser evidenciados ao analisar dados geogrficos. Alguns destes problemas podem ser problemas dirios, rotineiros, que quase passam despercebidos. Outros so eventos inesperados, que requerem uma ao imediata e rpida para poder contorn-los. De acordo com Longley (2005), problemas que envolvem um aspecto de localizao, onde usada a informao para poder resolv-los, so chamados de problemas geogrficos. Alguns exemplos de problemas geogrficos so: Uma empresa no ramo da sade resolve um problema geogrfico (ou at mesmo cria um) ao decidir onde abrir uma clnica nova ou hospital; Uma empresa de transporte resolve problemas geogrficos ao definir as rotas e agendamento de datas de entrega para seus veculos; Empresas de consultoria em vendas resolvem problemas geogrficos quando recomendam os melhores locais para abrir uma nova loja de determinado ramo de produto. Para analisar melhor cada um destes casos, se faz necessrio analisar questes como o nvel de detalhe geogrfico, inteno ou propsito do negcio e escala (tanto espacial quanto temporal). Informaes geogrficas so um dos tipos mais complicados de informao armazenados em sistemas computacionais. O contedo da informao geogrfica varia em diferentes resolues, escalas, tempos e domnios (PENG; TSOU, 2003). Conforme o tempo passa, a infra-estrutura e populao de um local pode se alterar, gerando novas demandas de recursos sociais e potenciais nichos de mercado, como por exemplo, hotis, postos de gasolina, parques e restaurantes.

32 Evidentemente, o mundo dos negcios depende de tomada de decises. Presidentes guiam uma organizao decidindo estratgias a longo prazo, enquanto os diretores decidem tticas e iniciativas para atingir os objetivos de mdio e curto prazo. Analistas de Negcio tomam decises para analisar problemas, conduzir desenvolvimento de produtos e gerar decises criativas para manter a empresa no mercado. Os gerentes operacionais se focam na deciso tomadas em processos particulares. Para qualquer organizao, a deciso algo rotineiro e precisa ser tomada (MARAKAS, 2002). Dentre os objetivos principais de uma empresa, podemos citar alcanar a modernidade com inteligncia competitiva e gerar lucro e perenidade com inteligncia empresarial. Dentro das empresas, o enfoque atual dos sistemas est principalmente no negcio empresarial e no objetivo de auxiliar os respectivos processos decisrios (REZENDE, 2003, p. 32). Sistemas de Informao Geogrficos possuem um papel crucial no que diz respeito a ser suporte para tomada de decises. A rea de Sistemas de Informao possui sistemas conhecidos para auxiliar a tomada de deciso, como Sistemas de Apoio a Deciso (SAD) e Business Intelligence (BI). Na rea de SIG existem conceitos relativamente novos como Sistemas de Apoio a Deciso Espacial (SDSS Spatial Decision Support Systems) e Spatial Business Intelligence (PICK, 2007, p. 70). Um exemplo destes conceitos seria modelos e dados que auxiliariam instituies bancrias a identificarem locais para criar, manter ou fechar caixas eletrnicos. Estas decises so baseadas em locais espaciais de seus clientes, concorrentes e filiais j existentes. Um SIG aumenta tambm a produtividade, pois permite uma melhor visualizao global do negcio, 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 Informao Geogrfica pode ser criado de muitas formas diferentes. Como acontece em vrios outros campos de atuao, no existe um termo especfico 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 Informao

33 Geogrfica Distribudo, e Web GIS. Todos estes termos so similares, mas podem ter significados distintos. Todos eles referenciam um Sistema de Informao Geogrfica sendo executado atravs 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 atravs da Internet, mas no necessariamente utilizando o browser ou pginas de acesso. J o termo Web GIS (ou Web SIG) significa um SIG utilizando a Web como plataforma de execuo, tendo a troca de informaes, processamento e visualizao de seus resultados atravs do Browser (PENG; TSOU, 2003, p. 10). Sistemas Web SIG possuem um cliente, um servidor de aplicao, 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 interao entre os componentes de um sistema Web SIG. A respeito de cada uma destas partes (PENG; TSOU, 2003, p. 20): Cliente: o acesso do usurio ao SIG. Neste caso em especfico, um Browser de acesso a Web no computador de cada usurio, como por exemplo, Internet Explorer, Firefox, Safari e Opera. Servidor de Aplicao: tambm chamado de servidor HTTP, sua funo responder as requisies dos Browsers via HTTP. Existem vrias formas de um servidor responder as requisies de clientes: enviando uma pgina

34 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 responsvel por receber requisies de dados espaciais e gerar os mapas baseados nesta requisio. O servidor de mapas possibilita algumas funes tradicionais de SIG, como filtros, extrao de dados e servios de localizao por coordenadas geogrficas. Servidor de Dados: o servidor de dados promove dados espaciais e no espaciais, em forma de estrutura de dados relacional ou no relacional. Por meio de comandos SQL os dados deste servidor so manipulados. Em um exemplo de atuao de um sistema SIG, temos o seguinte cenrio: Mike planeja fazer uma viagem para uma cidade desconhecida. Ele deseja traar a rota de viajem para esta cidade e reservar um hotel para sua estadia.

Figura 4 - Cenrio de um plano de viagem Fonte: PENG (2003, p. 37)

Na Figura 4, possvel visualizar os atores envolvidos no cenrio do plano de viagem. Mike, um usurio do SIG, que no tem nenhum tipo de treinamento em sistemas SIG, quer planejar uma viagem. Tina a representao de um designer de mapas. Kevin, o gerente de reservas do hotel, tem as informaes de reserva e quem ir aceitar a reserva de Mike. Em uma soluo Web SIG, Mike o cliente, por intermdio de um Browser, iria acessar o SIG, mais precisamente o servio de rotas de viagem. Tina seria o servidor de mapas: ir mostrar o mapa no navegador para Mike definir seu ponto de sada e ponto de chegada (sua rota). Tina ento retornaria um mapa contendo o caminho mais curto para Mike chegar ao seu destino, com os hotis na sua cidade de destino. Toda interao de Mike e de Tina seria mediada pelo

35 servidor de aplicao, responsvel por atender as requisies de Mike. Kevin ento seria o servidor de dados, neste caso um servio on-line de reservas do hotel escolhido, de acordo com suas definies de preo e data de estadia. Mike ento efetua sua reserva e tem a opo de imprimir um mapa com a rota traada de seu ponto de sada para o hotel de destino, com sua reserva j efetuada. Toda esta operao levaria poucos minutos para ser concluda (PENG; TSOU, 2003, p. 38).

2.4.2

Google Maps

O lanamento do Google Maps, em 2005, revolucionou o conceito de Web Mapping. Com a transmisso de dados entre cliente e servidor via Asynchronous Javascript And XML (AJAX), o Google Maps atingiu uma interao com os mapas indita na web: apenas clicando e movendo o mouse para uma direo ou usando o scroll para aproximar ou afastar, a atualizao do mapa ocorre quase de forma instantnea. Ao lanar este servio, a Google deixou todos os outros servios de Web Mapping parecer imediatamente obsoletos (PETERSON, 2008).

Figura 5 - Utilizando o servio Google Maps Fonte: http://maps.google.com.br (2009)

36 No Google Maps, possvel armazenar suas localizaes, apenas com um clique, com a premissa que voc tenha uma conta no Google. As possibilidades que a ferramenta possibilita so inmeras, e uma das mais impressionantes a de projeo de rotas entre dois pontos, que uma maneira de manipulao de dados muito complexa, que a ferramenta disponibiliza com muita preciso. Enviar localizao por email, compartilhar as informaes e se beneficiar de uma API aberta, so outras vantagens que o Google Maps possui. Nos casos de sistemas SIG web, utilizar o Google Maps torna-se uma grande vantagem, pois alm de ser relativamente barato, possvel personalizar e adicionar recursos facilmente (PETERSON, 2008). Os mapas tambm podem estar relacionados com fotos dos lugares, e as fotos so adicionadas por usurios comuns ou por empresas como National Geographic. Recentemente mais um recurso foi adicionado, o Street View, que nos proporciona uma experincia com imagens imersivas em 360, com navegao intuitiva e uma representao do mundo real muito prxima, disponvel apenas nas ruas das cidades que possuem este recurso adicionado, o objetivo que o usurio tem a impresso de estar caminhando pelas ruas.

Figura 6 - Utilizando o Street View Fonte: http://maps.google.com.br (2009)

A Figura 6 mostra a visualizao de uma rua por meio do recurso Street View. Com cliques e movimentos do mouse, possvel ter uma viso completa de como era a rua, aproximando ainda mais a representao abstrata do mundo real. possvel cadastrar uma empresa e permitir que outras pessoas possam encontrla, j remetendo a um recurso comercial que atua significativamente no resultado das

37 empresas. Todos estes recursos colaborativos so utilizados de maneira que informaes so adicionadas de modo automtico por todos os usurios simultaneamente, e estas informaes vo compondo uma espcie de mundo virtual, em que todos so afetados e tratados como peas de um grande mundo colaborativo que beneficia a todos.

Figura 7 - Camadas do servio Google Maps Fonte: http://maps.google.com.br (2009)

Na Figura 7 possvel observar que o sistema de mapas do Google possui cinco camadas adicionais que podem ser selecionadas, e compem uma maneira mais interativa de observao de mapas na Internet. A respeito das cinco camadas interativas do Google Maps: Fotografias: Fotos podem ser adicionadas por empresas ou qualquer usurios, e podem ser observadas por qualquer pessoa em qualquer parte do mundo. As fotos que so adicionadas tero que ter uma relao direta com a paisagem do lugar. Assim a experincia da utilizao do Google Maps se torna muito mais prxima ao mundo real. Vdeos: Atrelado a outro servio do Google, o Youtube, que um repositrio de vdeos na Internet, esta camada do Google Maps mostra

38 vdeos relacionados paisagem do local e pode conter documentrios que contem um pouco da histria do lugar. Wikipdia: Informaes sobre o local so relacionadas por meio de uma parceria com a Wikipdia, que um grande repositrio de artigos e fontes de informao, totalmente colaborativo. Webcams: Algumas cmeras podem ser observadas nos mapas, e os vdeos transmitidos so assistidos em tempo real, uma tecnologia muito interessante para projetos que buscam monitoramento de regies. Transportes pblicos: Apenas em alguns pases esse recurso est disponvel, e funciona como apoio a populao, que utiliza o transporte pblico como meio de locomoo, contribuindo indiretamente com a preservao do meio ambiente.

2.4.3

A API do Google Maps

Uma das grandes caractersticas da Web 2.0 so as APIs para utilizao e desenvolvimento de web sites. API, para Orenstein (2000) um conjunto de requisies padronizadas, utilizadas quando um software requer que outro software faa algo. Segundo Roos (2009), API um conjunto de instrues e padres para acessar um software de plataforma Web, ou uma ferramenta Web. Uma empresa de software lana sua API publicamente, para que outros desenvolvedores possam criar produtos que possam se beneficiar deste servio, tornando estes melhores. "Utilizando recursos e APIs existentes, possvel desenvolver sites poderosos e flexveis, contando com recursos atrativos como blogs, agendas, notcias e mapas" (SAMPAIO, 2007, p.4). Esta a maior diferena da Web 2.0 para a Web tradicional: criar novos servios para as pessoas utilizando APIs e ferramentas j existentes, possibilitando o uso de inteligncia coletiva.

39 A API do Google Maps uma interface de desenvolvimento de aplicativos fornecida pela Google, permitindo a utilizao e personalizao de mapas na web. A API do Google Maps est totalmente integrada s APIs AJAX do Google. Portanto com apenas uma chave de utilizao possvel utilizar todas as APIs AJAX do Google (inclusive o Google Maps). Para usar toda a estrutura da API AJAX do Google oferecida relativamente simples, porm necessrio ter conhecimentos de programao orientada a objetos. A API possui tambm um recurso para detectar se o aplicativo est usando um sensor (como um localizador GPS). Com isso possvel determinar a localizao do usurio, que especialmente importante para dispositivos mveis. Atravs da latitude e longitude, possvel localizar um lugar na superfcie terrestre, cada local possui um par nico destes valores, chamados de coordenadas geogrficas.

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 distncia de um ponto at a linha do Equador. A Latitude pode ir da linha do Equador (zero grau) ao Plo Norte (90 graus norte) ou ao Plo Sul (90 graus sul). Longitude representa distncia de um ponto at o meridiano de Greenwich,

40 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 informao empresarial ir ter as coordenadas geogrficas de uma localizao, pois a mesma no teria utilidade fora de um SIG. Geocodificao (geocoding) o processo de encontrar as coordenadas geogrficas a partir de dados geogrficos (como endereo, cdigo postal e fronteira ou marco), sendo que o mtodo mais preciso buscar as coordenadas geogrficas a partir do nome da rua (DRAMOWICZ, 2004). O processo de geocoding essencial em qualquer SIG, por isso, a API do Google Maps contm este servio, eliminando a necessidade de ter um servio de geocoding externo (UDELL, 2009, p. 80).

41 3 MTODO

No ambiente acadmico, para realizar pesquisas cientficas, o arcabouo terico e uma fundamentao para elaborao da mesma imprescindvel, dentro de todas as aes que so representadas pelas metodologias apropriadas.

3.1

CARACTERIZAO DO TIPO DE PESQUISA

A pesquisa aplicada tem como objetivo principal gerar conhecimentos para resolver um problema especfico, auxiliando na aplicao prtica da resoluo desse problema (SILVA; MENEZES, 2005, p. 20). Sendo assim, segundo a classificao da natureza da pesquisa, o presente trabalho uma pesquisa aplicada, pois tem como objetivo angariar conhecimento que ser exacerbado na aplicao de um problema em particular. Caracterizando segundo as fontes de informao, este se enquadra na pesquisa bibliogrfica, pois os dados a serem levantados sero buscados em materiais j publicados, escritos na forma de livros, peridicos e outros (SANTOS, 2001, p. 31). Do ponto de vista de seus objetivos, a pesquisa exploratria onde se encontra esta monografia. Pesquisa exploratria busca criar uma familiaridade em relao a um fato ou fenmeno. Quase sempre busca-se esta familiaridade pela prospeco de materiais que possam informar ao pesquisador a real importncia do problema (SANTOS, 2001, p. 26). Esta busca pode informar tambm o estgio onde se encontram as informaes j levantadas e tambm revelar novas fontes de informao. Normalmente, a pesquisa exploratria feita com levantamento bibliogrfico, 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 no podem ser medidos, quantificados ou mensurados. O pesquisador trabalha com a diversidade de dados do objeto de pesquisa (CS, 2008, p. 35). Desta forma, o processo e seu significado so os focos principais de abordagem (SILVA; MENEZES, 2005, p. 20).

42 3.2 ETAPAS

As etapas do para elaborao da monografia so sintetizadas da seguinte forma: a) Levantamento terico; b) Levantamento de requisitos do sistema; c) Estudo da API do Google Maps; d) Estudo da framework Flex; e) Modelagem do sistema; f) Implementao do sistema; g) Testes; h) Validao.

3.3

ARQUITETURA DA SOLUO PROPOSTA

Respeitando algumas funcionalidades fundamentais da soluo, e ainda carregando razes culturais, e de posicionamento tecnolgico, as exigncias de interoperabilidade, e portabilidade, esbarram de maneira geral nas ofertas de Computao em Nuvem. Computao em Nuvem um somatrio da evoluo de diversas tecnologias, como um grid computing, processamento paralelo, autonomic computing, virtualizao, APIs assncronos, browsers e outros. (TAURION, 2009, p. 45). Como tendncia ainda tem-se o modelo de Software-as-a-Service (SaaS). O modelo SaaS um modelo de entrega de software como um servio de forma diferente do modelo tradicional, no qual a empresa adquire uma licena de uso e instala em seus prprios servidores. (TAURION, 2009, p.101). No modelo SaaS a instalao no necessria e as licenas so tratadas de maneira diferente, o usurio paga pelo que usou, a partir do momento que fechou o software, no esta mais pagando pelo servio. Isso promove uma sensao de que realmente se paga pelo real uso do aplicativo. Com o SaaS, tambm no so mais necessrios os contratos de manuteno, pois essas atividades ficam a cargo do provedor e no mais da empresa. (TAURION, 2009, p.101).

43 Mas com os inmeros servios de Computao em Nuvem, a soluo proposta deve ser enquadrada em uma arquitetura que contemple SaaS dentro da Computao em Nuvem. Se em um primeiro momento existe a propenso da interpretao de que h apenas uma arquitetura para prover o conceito de Computao em Nuvem, essa propenso perde o sentido ao analisar as camadas que mostram como os servios de TI so negociados nesse modelo. A soluo proposta se enquadra no nvel trs, que a camada de aplicaes, onde est o Software-as-a-Service. Na arquitetura de Computao em Nuvem, esse nvel o que visivelmente mostra resultados palpveis aos usurios.

Figura 9 - Arquitetura da Soluo Proposta Fonte: Elaborado pelos autores (2009).

3.4

RECURSOS

De recursos humanos, o presente trabalho ser realizado por dois analistas de sistema os mesmos sero responsveis pela anlise, desenvolvimento e testes do sistema proposto, sendo que estes analistas so os autores da monografia. Quanto aos recursos de software, para anlise, documentao, linguagem de programao e banco de dados, sero utilizados preferencialmente ferramentas livres ou open-source. O desenvolvimento ser com

44 o software Flex Builder, sendo que possvel obter uma licena completa de estudante sem custo. Os recursos de hardware sero dois computadores pessoais.

3.5

DELIMITAES

O sistema proposto ir importar, inicialmente, apenas arquivos no formato XLS. No ser desenvolvido neste momento a comparao de dados empresarias com dados offthe-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 transmisso de mensagens entre grupos de pessoas. (REZENDE, 2005, p. 7). A definio de modelagem to pouco ligada informtica, porm esse conceito evidencia-se quando necessrio descrever um modelo grfico para auxiliar a criao de um software. uma coletnea de estruturas fortemente ligados a recursos e padres, globalmente imersos em lgicas, a fim de alcanar um ou mais objetivos. A modelagem por objetos v o mundo como uma coletnea de objetos que interagem entre si e apresentam entre caractersticas prprias que so apresentadas pelos seus atributos e operaes. (REZENDE, 2005, p. 201). Dessa forma, dependendo da rea do conhecimento, tm-se vrios sistemas reais que so abordados sobre algumas ticas para recuperar semntica atravs de uma modelagem. Uma das abordagens a de melhoramento e implementao em sistemas, a fim de calibrar condies ideais de funcionamento, focado no objetivo a ser alcanado. Outra abordagem seria a de representao de sistemas reais, que podem ser desenvolvidas com prottipos ou com modelos matemticos que funcionariam como suporte analtico para o tomador de deciso. O que pode garantir que todas as diretrizes e a obedincia dos objetivos definidos sero cumpridas a modelagem descrita neste capitulo. Ser descrito ento toda a modelagem

45 do sistema proposto e sero abordados os conceitos usados para a representao grfica de todas as regras e processos que envolvem o desenvolvimento. O uso da linguagem grfica UML (Unified Modeling Language), abordado dentro de um modelo de desenvolvimento chamado ICONIX.

3.6.1

UML

A UML uma linguagem grfica 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 negcio, e funcionalidades do sistema, e tambm conceitos prticos como classes escritas em uma linguagem de programao especfica, esquemas de banco de dados e componentes reutilizveis de software (BOOCH; RUMBAUGH; JACOBSON, 1998). As linguagens de programao orientadas a objeto surgiram em meados dos anos 70. As metodologias de programao, confrontando a orientao a objetos e o aumento da complexidade das aplicaes, comearam a experimentar novas formas de anlise e design. Entre 1989 e 1994, o nmero de tcnicas orientadas a objeto aumentou de 10 para 50, e comeou a ficar difcil de encontrar uma que sanasse todas as necessidades. Novas geraes destas tcnicas comearam a aparecer, sendo que as mais notveis 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 construo, a OOSE fornecia um excelente suporte para os casos de uso como um guia para a captura de requisitos, anlise e modelagem de alto nvel, enquanto a OMT foi mais til para anlise de dados e sistemas com uso intensivo de informao (BOOCH; RUMBAUGH; JACOBSON, 1998). Vrias idias comearam a surgir na metade dos anos 90, quando Booch, Jacobson e Rumbaugh comearam a adotar idias e mtodos um dos outros, motivando a unificao destas metodologias, basicamente por trs razes: eles j estavam se envolvendo um com os outros, a unificao das metodologias traria mais estabilidade e, por fim, a

46 colaborao dos trs traria uma nova metodologia melhor que as trs j existentes (BOOCH; RUMBAUGH; JACOBSON, 1998). A criao da UML comeou oficialmente em outubro de 1994, e sua verso 1.0 foi lanada em janeiro de 1997, com a contribuio de grandes corporaes como IBM, Microsoft, Rational, Hewlett-Packard, entre outras (BOOCH; RUMBAUGH; JACOBSON, 1998).

3.6.2

ICONIX

ICONIX um processo de anlise 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 Fonte: ROSEMBERG; STEPHENS (2007, p. 1)

47 Na teoria, cada diagrama da UML potencialmente til, porm na prtica nunca h tempo suficiente para a anlise e modelagem dos mesmos. Sempre h uma presso para que o desenvolvimento seja iniciado, pois o progresso da criao do software tende a ser medido pela quantidade de cdigo existente. O ICONIX, como mostrado na Figura 10, minimalista, com foco entre os casos de uso e o cdigo, e dividido em dois workflows. O workflow dinmico descreve o comportamento, enquanto o workflow esttico descreve a estrutura (ROSEMBERG; STEPHENS, 2007, p. 1). O ICONIX dirigido por casos de uso como o RUP e minimalista como o XP, porm mais simples se comparado ao RUP e suficiente onde o XP no . Desta forma, o ICONIX situa-se em algum ponto entre a complexidade e abrangncia do RUP e a simplicidade e rapidez do XP, porm contemplando as etapas de anlise e modelagem que so 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 compreenso melhor do que eles precisam (AMBLER, 2004, p. 120). A criao de bons modelos com ICONIX simples caso mantenha-se o foco em questes de importncia fundamental sobre o sistema a ser construdo e recusar-se em perder tempo com questes de modelagem suprfluas. Esta filosofia est no corao do processo ICONIX (ROSENBERG; SCOTT, 2001). O processo ICONIX faz uso racionalizado da UML, mantendo um foco ntido sobre a rastreabilidade dos requisitos (ROSENBERG; SCOTT, 2001). Desta forma o ICONIX possui recursos atrelados as suas atividades que nos garante que os requisitos esto sendo atendidos. O ICONIX composto pelos seguintes marcos ou estgios (ROSEMBERG; STEPHENS, 2007, p. 3-4): Requisitos; Anlise e Projeto Preliminar; Projeto Detalhado; Implementao.

Estes estgios esto detalhados nas sees a seguir.

48 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 Domnio: Identificar, no mundo real, os objetos e seus relacionamentos; c) Casos de uso: Definir como o usurio e o sistema iro interagir, escrevendo os primeiros casos de uso. Recomenda-se comear com prottipos de tela para auxiliar a identificar todos os casos de uso a serem implementados; d) Reviso dos requisitos: Para ter a certeza de que todos os casos de uso esto de acordo com as expectativas do cliente.

Figura 11 - ICONIX Requisitos Fonte: ROSEMBERG; SCOTT (2001, http://www.informit.com/articles/article.aspx?p=167902&seqNum=5)

49 3.6.2.2 Anlise e Projeto Preliminar

Segundo Rosemberg (2007), esta etapa se repete para cada caso de uso identificado: a) Anlise de Robustez: Atualizar o diagrama de domnio e desenhar o diagrama de robustez, permitindo a visualizao de classes antes no identificadas; b) Diagrama de classes: Neste momento, o diagrama de domnio vai ganhando mais informaes, se transformando no esboo do diagrama de classes; c) Atualizar o diagrama de casos de uso.

Figura 12 - Anlise e Projeto Preliminar Fonte: ROSEMBERG; SCOTT (2001, http://www.informit.com/articles/article.aspx?p=167902&seqNum=5)

3.6.2.3 Projeto Detalhado

Segundo Rosemberg (2007), para cada caso de uso:

50 a) Diagrama de seqncia: Modelar o diagrama de seqncia, mostrando em detalhes como o caso de uso ser implementado. A funo principal do diagrama de seqncia dar comportamento as classes do sistema.

Figura 13 - Projeto Detalhado Fonte: ROSEMBERG; SCOTT (2001, http://www.informit.com/articles/article.aspx?p=167902&seqNum=5)

3.6.2.4 Implementao

Segundo Rosemberg (2007), na etapa de implementao deve-se seguir os seguintes passos: a) Nesta etapa, caso seja necessrio, podem ser criados diagramas de componentes e/ou de deploy, servindo de apoio para a implementao; b) Escrever o cdigo; c) Realizar testes unitrios e testes de integrao; d) Realizar testes de sistema e testes com o usurio, de acordo com os casos de uso.

51

Figura 14 Implementao Fonte: ROSEMBERG; SCOTT (2001, http://www.informit.com/articles/article.aspx?p=167902&seqNum=5)

3.6.3

Especificao de requisitos

As definies de requisitos do sistema, segundo Sommerville (2007, p. 18), especificam o que o sistema deve fazer e tambm (suas funes) e suas propriedades essenciais de desejveis, e tambm especificam restries quanto operao do sistema. As definies de requisitos de sistema implicam diretamente na consulta a parte interessada no mesmo (stakeholders) e tambm aos usurios que iro utiliz-lo.

3.6.4

Necessidades dos Stakeholders

A maioria dos processos de engenharia de requisitos envolve entrevistas formais ou informais com os Stakeholders. Os requisitos so derivados das respostas que os Stakeholders fornecem ao analista de requisitos em frente a questes sobre o sistema que eles usam e o sistema a ser desenvolvido (SOMMERVILLE, 2007, p. 101).

52

Figura 15 - Diagrama de Necessidades dos Stakeholders Fonte: Elaborado pelos autores (2010)

No sistema proposto, apenas um stakeholder foi identificado, sendo que suas necessidades so, basicamente, visualizar dados geogrficos de seu negcio distribudos em um mapa sem impactar na operao de seu sistema legado.

3.6.5

Requisitos Funcionais

Requisitos funcionais so declaraes de funes ou servios que o sistema dever fornecer, como o sistema dever se comportar ou reagir em determinadas situaes e tambm como dever tratar entradas especficas. A especificao de requisitos funcionais deve ser completa e consistente (SOMMERVILLE, 2007, p. 81).

53

Figura 16 - Requisitos Funcionais e Regras de Negcio Fonte: Elaborado pelos autores (2010)

A Figura 16 mostra os requisitos funcionais do sistema proposto. Os mesmos foram divididos em requisitos funcionais de Login, Administrador, Usurio, Sistema e Google Maps. Foram elencados 22 requisitos funcionais. A seguir, a descrio dos mesmos:

54 3.6.5.1 Requisitos Funcionais de Login

Nome RF001 - Login no Sistema

Descrio A Pgina inicial da aplicao deve conter uma rea para entrar com os dados de acesso ao sistema. Os dados que devem constar no acesso so: - Usurio - Senha Na pgina de acesso deve conter o campo Esqueceu sua Senha e dar oportunidade aos usurios gerarem uma nova senha, atravs da insero dos dados de email e usurio. A pgina dever tambm ter um boto chamado "Criar uma conta", onde o usurio ser redirecionado para uma pgina de cadastro (RF004).

Ao efetuar o login, o sistema dever registrar este acesso (RF012). RF002 - Gerao de nova senha Caso o usurio tenha esquecido sua senha, deve ser gerada uma nova senha esta ser enviada ao e-mail do usurio, e o sistema ir marcar este usurio como expirado. Quando este acessar o sistema com a nova senha, ser obrigatrio que ele altere esta senha. Ao alterar, o usurio deixa de ser expirado. Para solicitar uma nova senha, o usurio dever: 1 - Clicar no campo "Esqueceu sua senha" na tela de login; 2 - Na tela de recuperao de senha, fornecer o e-mail cadastrado no sistema; Caso o e-mail esteja correto, o sistema ir gerar uma nova senha para este usurio e enviar por e-mail; Caso esteja errado, o sistema dever mostrar uma mensagem de "E-mail no cadastrado no sistema". Os usurios que estiverem marcados como bloqueados no podero ter acesso ao sistema.

RF003 - Usurios bloqueados

55 RF004 - Criao de Nova Conta Para criar uma nova conta, o usurio dever entrar com os seguintes dados: - Nome Completo; - Nome de Usurio desejado (Login); - Senha; - Email. O nome de usurio desejado ser de acordo com a disponibilidade: no poder haver dois usurios com o mesmo login. O campo senha dever ter um campo adicional, onde o cadastrante dever confirmar a senha. O campo e-mail ser utilizado para enviar um link para ativao da conta (isso dever ser informado). Para finalizar a criao da conta, o usurio dever ler os Termos de Servio, e o boto para criao da conta dever se chamar "Aceito. Criar minha conta", logo abaixo dos Termos de Servio. Toda conta criada desta forma ser do tipo "Free" (RF019).
Quadro 1 Requisitos Funcionais de Login. Fonte: Elaborado pelos autores (2010).

3.6.5.2 Requisitos Funcionais de Usurio

Nome Descrio RF005 - Importar dados de uma O sistema dever permitir que o usurio importe dados planilha eletrnica diretamente de uma planilha eletrnica para o sistema. Os formatos permitidos para a importao so: XLS, XLSX e CSV (campos separados por ponto e vrgula). A planilha deve obedecer ao padro correto para importao (RN01). A quantidade de planilhas importadas deve obedecer aos limites de conta (RN03). Caso a planilha seja importada com sucesso, os dados da planilha sero mostrados na tela(RF009).

56 RF007 - Listagem dos Mapas O sistema dever ter um menu chamado "meus mapas", onde o usurio poder visualizar todos os seus mapas de sua autoria. Ao clicar duas vezes em um mapa, o mesmo ser mostrado na tela (RF008). Em nenhum momento um usurio poder listar os mapas de outro usurio (RN02). A visualizao do mapa dever cobrir praticamente toda a tela do sistema, sobrando um menu esquerdo para edies e um menu superior direito para navegao no sistema. Dever tambm ter um link para visualizao dos dados em uma tabela (RF009) em uma tela poupup.

RF008 - Visualizao do Mapa

Em nenhum momento o usurio poder visualizar mapas de outros usurios (RN02). RF009 - Visualizao da tabela O sistema dever permitir que o usurio possa de dados do mapa visualizar os dados do mapa em uma tabela, simulando uma planilha eletrnica. Em nenhum momento um usurio poder visualizar dados de um mapa de outro usurio (RN02). RF010 - Alterao de dados do O sistema deve permitir que o usurio possa alterar os mapa dados de um mapa j importado. A alterao poder ser apenas a localizao do ponto no mapa, caso a geocodificao tenha sido equivocada. Para alterar, ser necessrio clicar no ponto e arrastlo pelo mapa at o local correto. Aps a alterao, o usurio dever confirmar se quer salvar os dados alterados. Caso sim, o mapa referente a estes dados ser atualizado. Em nenhum momento o usurio poder alterar mapas de outros usurios (RN02). O sistema deve permitir que o usurio possa excluir um mapa que seja de sua autoria. A opo de excluso dever estar na tela de listagem de mapas. Uma tela de confirmao dever ser mostrada caso o usurio decida excluir um de seus mapas. Em nenhum momento o usurio poder excluir mapas de outros usurios (RN02).

RF011 - Excluso de um mapa

57 RF019 - Visualizao Grfico Pizza em O sistema deve permitir que o usurio possa visualizar os dados de um mapa em um grfico de pizza. O nome de cada coluna com dados numricos dever ser colocado em uma combobox, sendo que ao selecionar a mesma, o grfico se atualizar com os dados daquela coluna. Em nenhum momento o usurio poder visualizar dados de mapas de outros usurios (RN02).
Quadro 2 Requisitos Funcionais de Usurio. Fonte: Elaborado pelos autores (2010).

3.6.5.3 Requisitos Funcionais de Administrador

Nome RF014 - Listagem de usurios

Descrio O sistema dever permitir que o administrador possa listar todos os usurios cadastrados no sistema. Ao clicar em um usurio o sistema dever exibir os dados do mesmo (RF015). RF015 - Visualizar dados do O sistema dever ter uma tela visualizao de dados usurio do usurio. Os dados sero: - Nome de Usurio; - Login; - E-mail; - Tipo de conta; - Total de mapas de sua autoria; - Total de vezes que o mesmo entrou no sistema; - Tempo total de utilizao do sistema. Nesta tela, o sistema dever permitir que o usurio seja bloqueado ou desbloqueado (RF016). RF016 Bloquear ou O sistema dever permitir que o administrador possa Desbloquear usurio bloquear ou desbloquear usurios. Um usurio bloqueado no poder acessar o sistema. Ao tentar efetuar o login, o sistema emitir uma mensagem dizendo que o mesmo est bloqueado, e para efetuar o desbloqueio dever entrar em contato com os administradores. O sistema dever permitir que o administrador possa alterar o tipo do usurio (RF022). O sistema dever permitir que o administrador possa excluir uma conta de usurio.

RF017 - Alterar usurio RF018 - Excluir um usurio

Quadro 3 Requisitos Funcionais de Administrador. Fonte: Elaborado pelos autores (2010).

58 3.6.5.4 Requisitos Funcionais de Google Maps

Nome RF006 - Geocodificao

Descrio O sistema dever, para cada registro na planilha a ser importado, fazer a geocodificao dos dados para buscar a latitude e a longitude do local. Esta geocodificao ser feita atravs de um Web Service da Google. Os tipos de visualizao dos mapas devero ser todos os suportados pela API do Google Maps: - mapa; - terreno; - hbrido. O tipo padro dever ser o "terreno". O controle de zoom do mapa dever ser tanto com o scroll do mouse quanto com uma barra lateral esquerda, indicando com o ponteiro do mouse o nvel desejado.

RF020 - Tipos de Visualizao

RF021 - Controle de Zoom

Quadro 4 Requisitos Funcionais de Google Maps. Fonte: Elaborado pelos autores (2010).

3.6.5.5 Requisitos Funcionais de Sistema

Nome Descrio RF012 - Registrar Momento O sistema dever registrar cada vez que um usurio Inicial do Login entra no sistema. Os dados a serem gravados sero: - Usurio; - Data e hora de Login no sistema; RF013 - Registrar Momento de O sistema dever registrar cada vez que um usurio sai Termino Login do sistema. Os dados a serem gravados sero: - Usurio; - Data e hora de sada no sistema; RF022 - Tipos de Usurio O sistema dever ter dois tipos de usurio: - "Free"; - "Premium"; - "Administrador"; A alterao de uma somente poder ser efetuada por um administrador do sistema (RF017).
Quadro 5 Requisitos Funcionais de Sistema. Fonte: Elaborado pelos autores (2010).

59

3.6.6

Requisitos No Funcionais

Requisitos no funcionais so aqueles que no esto ligados diretamente com as funes especficas do sistema. Normalmente os requisitos no funcionais especificam ou restringem as propriedades emergentes do sistema, como confiabilidade, disponibilidade, desempenho, usabilidade, segurana e proteo. Isto significa que geralmente eles so mais importante que do que requisitos funcionais individuais, pois uma falha de um requisito no funcional de confiabilidade, por exemplo, pode tornar todo o sistema intil (SOMMERVILLE, 2007, p. 82).

Figura 17 - Requisitos No Funcionais Fonte: Elaborado pelos autores (2010)

60

No sistema proposto, existem 10 requisitos no funcionais: cinco de usabilidade, um de desempenho, dois referentes a suportabilidade e dois sobre segurana. A seguir, a descrio dos mesmos:

3.6.6.1 Requisitos No Funcionais de Usabilidade

Nome RNF01 - Link para os mapas

Descrio Para visualizar quaisquer mapas j importados, o usurio no pode dar mais de 3 cliques (links). RNF02 - Botes de ajuda Todas as telas do sistema devero ter um boto de ajuda (ponto de interrogao) ao lado de uma funcionalidade, explicando para que serve aquela ao. RNF03 - Espera na importao A importao de um arquivo um momento de arquivos demorado, pois consiste em upload e converso de um arquivo XLS para dados. Durante esta ao, uma barra de progresso dever ser mostrada ao usurio no momento da importao. RNF04 - Esttica O sistema dever ter cores claras: o padro so letras pretas e fundo branco para textos. O sistema dever tambm permitir ser personalizado com temas, para que cada usurio possa ter suas determinadas preferncias. RNF05 - Ajuda e manuais on- Dever estar disponvel a qualquer momento um menu line de ajuda on-line, explicando todos os passos para a importao de um mapa e tambm a criao de um mapa a partir do sistema. Dever conter tambm um vdeo mostrando estes passos. Alm disso, o manual de usurio dever estar disponvel para download ( em formato pdf) e consulta.
Quadro 6 Requisitos No Funcionais de Usabilidade. Fonte: Elaborado pelos autores (2010).

61 3.6.6.2 Requisitos No Funcionais de Segurana

Nome RNF06 - Link seguro

Descrio Aps efetuar o login no sistema, toda a troca de informao com o servidor dever ocorrer pelo protocolo HTTPS. RNF07 - Recuperao de senha Caso o usurio precise recuperar sua senha, o sistema dever mostrar uma opo onde o usurio entre com seu login ou e-mail. Ao entrar com os dados, o sistema ir ocultar o campo de entrada de login/e-mail, dificultando mecanismos de fora bruta descobrir dados de usurios como login ou e-mail.
Quadro 7 Requisitos No Funcionais de Segurana. Fonte: Elaborado pelos autores (2010).

3.6.6.3 Requisitos No Funcionais de Suportabilidade

Nome RNF08 - Internacionalizao

RNF09 Sistema

Arquitetura

Descrio O sistema dever ter suas mensagens e textos em arquivos externos, permitindo que, caso seja necessrio, a aplicao possa suportar localizao (internacionalizao). do A arquitetura do sistema dever permitir que, caso precise, suportar mais usurios simultneos, seja aumentando o desempenho do servidor ou distribuindo as camadas da aplicao em mais servidores.

Quadro 8 Requisitos No Funcionais de Suportabilidade. Fonte: Elaborado pelos autores (2010).

3.6.6.4 Requisitos No Funcionais de Desempenho

Nome RNF10 - Carga de usurios

Descrio O sistema deve suportar pelo menos 50 usurios simultneos, sem afetar o desempenho.

Quadro 9 Requisitos No Funcionais de Desempenho. Fonte: Elaborado pelos autores (2010).

62

3.6.7

Regras de negcio

Uma regra de negcio uma afirmao compacta a respeito do negcio. Ela pode ser expressa de uma forma que podem ser diretamente relacionada ao negcio, usando uma linguagem simples que acessvel a todas as partes interessadas: proprietrio do negcio, analista de negcio, arquiteto do sistema, entre outros. uma restrio, no sentido de que uma regra de negcio estabelece o que pode e o que no pode ser feito (MORGAN, 2002, p.5). Para Martim Fowler (2003, p.26) o software de negcios se torna complexo, pois existem poucas coisas que so menos lgicas do que a lgica de negcio. Apesar de sempre existir um esforo para manter toda a aplicao lgica, as regras de negcio so simplesmente impostas e no h nada que se possa fazer para alter-las. Isso faz com que o analista ou desenvolvedor tenham que lidar com um conjunto aleatrio de condies estranhas que muitas vezes se interagem umas com as outras de uma forma surpreendente (FOWLER, 2003). A seguir, a descrio das regras de negcio do sistema proposto: Nome Descrio RN01 - Padro do arquivo para A planilha a ser importada dever seguir o seguinte importao padro: - A primeira linha dever conter o nome das colunas; - Dever haver uma coluna ou mais colunas com os seguintes nomes: - Cidade; - Municpio; - Estado; - UF; Nesta(s) coluna(s) dever(o) conter os dados referentes a localizao. Cada linha dever conter os dados referentes aos dados de cada coluna. Caso a planilha no obedea este padro, uma mensagem de erro deve ser mostrada. A mensagem ser "Planilha em Formato Invlido", juntamente com um link para o padro que a planilha deve obedecer.

63 RN02 - Autoria de mapas Cada mapa criado ou importado dever estar vinculado ao usurio que importou/criou o mesmo. Cada usurio ser responsvel por seus mapas, e em nenhum momento o mapa de um usurio poder ser visualizado/editado/excludo por outro usurio que nao seja o autor do mapa. de Sempre que houver uma duplicidade de localizao (a API do Google encontrar mais de um local com os dados passados), o sistema ir utilizar a primeira localizao encontrada. Toda conta "Free" ter um limite de dois mapas no sistema. Caso a conta j possua dois mapas, as opes de importar planilha (RF005) e criar mapa (RF006) mostraro a seguinte mensagem: "Sua conta j atingiu o limite de mapas permitido (2 mapas). Para possibilitar a importao de mais mapas, necessrio uma conta premium". Caso o usurio exclua um mapa (ficando com menos de dois mapas em sua conta) as opes de criao e importao voltam a funcionar. A conta Premium no tem limite de mapas a serem importados ou criados.
Quadro 10 Regras de Negcio. Fonte: Elaborado pelos autores (2010).

RN03 - Duplicidade Localizao RN04 - Limites de Conta

3.6.8

Prototipao

As interfaces com o usurio possuem uma natureza dinmica, fazendo com que as descries textuais e os diagramas no sejam bons suficientes para especificar requisitos de interface com o usurio. A prototipao, com o envolvimento dos usurios finais, a nica forma prtica de projetar interfaces grficas com o usurio. O objetivo da prototipao permitir que os usurios ganhem experincia direta com a interface (SOMMERVILLE, 2007, p. 253). A seguir, os prottipos de tela do sistema proposto:

64

Figura 18 - Prottipo de Tela de Login Fonte: Elaborado pelos autores (2010)

A Figura 18 representa o prottipo de tela de login do sistema. Nesta tela, alm de um campo para acessar o sistema, h tambm dados gerais sobre o sistema e um boto para criao de nova conta.

Figura 19 - Prottipo de Tela de Entrada Fonte: Elaborado pelos autores (2010)

65 A Figura 19 representa o prottipo de tela de entrada do sistema. Nesta tela, haver apenas um menu superior contendo os botes para navegao: o restante ser reservado para a visualizao do mapa.

Figura 20 - Prottipo de Tela de Importao Fonte: Elaborado pelos autores (2010)

A Figura 20 representa o prottipo de tela de importao. Nesta tela, haver um boto para buscar a planilha eletrnica no computador e uma mensagem contendo os tipos de arquivos suportados pelo sistema.

66

Figura 21 - Prottipo de Tela de Visualizao de Mapa Fonte: Elaborado pelos autores (2010)

A Figura 21 representa o prottipo de tela de visualizao de mapa. O mapa ir ocupar praticamente toda a tela. Nos pontos do mapa, ao clicar, aparecer um balo contendo os dados referentes quela localizao. Haver um menu, na esquerda, que pode ser expandido, contendo opes de visualizao do mapa em questo.

3.6.9

Modelo de domnio

O termo Modelo de Domnio significa uma representao de classes conceituais do mundo real, no de objetos de software. O termo no significa um conjunto de diagramas que descreve classes de software, a camada de domnio de uma arquitetura de software. (LARMAN, 2005, p. 160). O modelo de domnio cria um entrelaado de objetos interligados, e cada objeto representa um significado individual. Fato que traz uma viso resumida em detalhes de software, mas global em relao ao funcionamento do software. O diagrama de classes de UML o veculo mais comum para capturar o contedo de um modelo de domnio. (SCOTT, 2002, p. 36). O modelo de domnio captura as entidades e os conceitos importantes do mundo real, que pertencem ao espao do problema, o qual define o

67 problema que o novo sistema em construo deve solucionar. (SCOTT, 2002, p. 36). A abstrao das classes e a captura da essncia do funcionamento do sistema sempre ser fundamento primordial para construir um sistema que atenda a resoluo dos problemas propostos. Dentro de qualquer metodologia ou representao grfica de sistemas reais o escopo do domnio ou negcio se faz apoiador ao desempenho do projeto e nveis de complexidade maiores.

Figura 22 - Diagrama de Domnio Fonte: Elaborado pelos autores (2010)

A Figura 22 representa o diagrama de domnio para o sistema proposto. Os objetos de negcio do sistema so: o usurio, seu tipo, o tempo de acesso e seus mapas.

68 3.6.10 Identificao dos atores

Atores so utilizados para modelar e representar os papis dos usurios de um sistema, sendo eles usurios humanos ou outros sistemas. Os atores so externos ao sistema, e interagem com o mesmo (ALHIR, 2000). Um ator pode ser descrito como qualquer coisa que possua um comportamento, inclusive o prprio sistema quando invoca servios de outro sistema (LARMAN, 2005, p. 92).

Figura 23 - Diagrama de Atores Fonte: Elaborado pelos autores (2010)

Na Figura 23, foram identificados trs atores para o sistema proposto: o visitante, que a pessoa que no possui uma conta no sistema, o usurio, que a pessoa que utiliza o sistema para criar e visualizar mapas, e o administrador, que a pessoa que gerencia os usurios do sistema.

3.6.11 Casos de Uso

Os casos de uso so utilizados para modelar e representar unidades de funcionalidades ou servios de um sistema (ou partes de um sistema) aos usurios. So interaes ou dilogos entre o sistema e atores, incluindo troca de mensagens e aes tomadas pelo sistema (ALHIR, 2000). A modelagem de casos de uso fornece uma forma estruturada de capturar os requisitos comportamentais do sistema. Ela tambm ajuda a responder questes

69 fundamentais como o que os usurios do sistema esto tentando fazer ou qual a experincia que estes tm em relao ao domnio do problema (ROSEMBERG; STEPHENS, 2007, p. 49). Os casos de uso oferecem um meio excelente para descobrir requisitos de clientes, pois textos bem escritos sobre casos de uso so muito semelhantes a textos que se encontram em um bom manual de usurio (SCOTT, 2002, p.35).

Figura 24 - Diagrama de Casos de Uso Fonte: Elaborado pelos autores (2010)

A Figura 24 representa o diagrama de casos de uso do sistema proposto.

70 3.6.12 Documentao dos Casos de Uso

A modelagem de casos de uso tambm descreve a forma que o usurio ir interagir com o sistema e como o sistema ir responder a esta interao. Ao descrever os cenrios, deve-se manter o foco em capturar as aes do usurio e associ-las a resposta do sistema (ROSEMBERG; STEPHENS, 2007, p. 50). A documentao dos casos de uso do sistema proposto apresentada a seguir:

Caso de Uso:

UC01 - Criar nova conta

Este caso de uso inicia-se quando um visitante necessita criar uma nova conta para acessar o sistema Visitante 1 - O visitante clica no boto "Criar nova conta" 2 - O visitante preenche os dados pessoais 3 - O visitante l e aceita os termos de compromisso 4 - O visitante clica no boto "Aceito, criar minha conta" 5 - O sistema cria a conta e envia um e-mail de ativao 6 - O usurio clica no link para ativao 7 - O sistema ativa a conta Pr-condio: O usurio no estar logado no sistema

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Ps-condio: Ativar a conta atravs de um link enviado por e-mail

Quadro 11 Documentao de Caso de Uso Criar Nova Conta. Fonte: Elaborado pelos autores (2010).

71

Caso de Uso:

UC02 - Importar planilha eletrnica

Este caso de uso inicia-se quando o usurio necessita importar uma planilha eletrnica no sistema Usurio 1 - O usurio seleciona o arquivo de planilha eletrnica no seu computador local; 2 - O usurio clica no boto "importar"; 3 - O sistema mostra os dados da planilha na tela.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio deve estar logado no sistema

Quadro 12 Documentao de Caso de Uso Importar Planilha Eletrnica. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC03 - Listar planilha/mapas de sua conta

Este caso de uso inicia-se quando o usurio visualizar os mapas/planilhas de sua conta. Usurio 1 - O usurio clica em "Meus Mapas"; 2 - O sistema mostra os mapas da conta do usurio

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 13 Documentao de Caso de Uso Listar Planilha/Mapas de sua Conta. Fonte: Elaborado pelos autores (2010).

72

Caso de Uso:

UC04 - Visualizar planilha/mapa

Este caso de uso inicia-se quando o usurio necessita visualizar um mapa/planilha no sistema Usurio 1 - O usurio lista os mapas de sua conta (UC03); 2 - O usurio clica duas vezes no mapa a ser visualizado; 3 - O sistema mostra os dados distribudos no mapa

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 14 Documentao de Caso de Uso Visualizar Planilha/Mapa. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC05 - Visualizar grfico com dados do mapa

Este caso de uso inicia-se quando necessrio visualizar os dados do mapa em um grfico Usurio 1 - O usurio lista os mapas de sua conta (UC03); 2 - O usurio visualiza o mapa (UC04); 3 - O usurio clica em "Grfico Pizza"; 4 - O sistema mostra os dados no grfico

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 15 Documentao de Caso de Uso Visualizar Grfico com Dados do Mapa. Fonte: Elaborado pelos autores (2010).

73

Caso de Uso:

UC06 - Editar planilha/mapa

Este caso de uso inicia-se quando necessrio alterar a localizao dos pontos distribudos no mapa Usurio 1 - O usurio lista os mapas de sua conta (UC03); 2 - O usurio visualiza o mapa (UC04); 3 - O usurio clica e arrasta os pontos pelo mapa; 4 - O usurio clica em "Salvar" 5 - O sistema mostra um aviso de salvo com sucesso

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 16 Documentao de Caso de Uso Editar Planilha/Mapa. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC07 - Excluir planilha/mapa

Este caso de uso inicia-se quando necessrio excluir um mapa. Usurio 1 - O usurio lista os mapas de sua conta (UC03); 2 - O usurio seleciona mapa a ser excludo; 3 - O usurio clica em "Excluir"; 4 - O sistema mostra uma janela de confirmao; 5 - O usurio clica em "Sim"; 6 - O sistema mostra uma mensagem de excludo com sucesso

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 17 Documentao de Caso de Uso Excluir Planilha/Mapa. Fonte: Elaborado pelos autores (2010).

74

Caso de Uso:

UC08 - Listar usurios cadastrados

Este caso de uso inicia-se quando necessrio visualizar os usurios cadastrados no sistema. Administrador 1 - O administrador clica em "Gerenciar usurios"; 2 - O sistema mostra uma janela para listagem de usurios

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema com uma conta de

administrador

Quadro 18 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC09 - Visualizar dados do Usurio

Este caso de uso inicia-se quando necessrio visualizar os dados de um usurio. Administrador 1 - O administrador lista os usurios do sistema (UC08); 2 - O administrador clica duas vezes no usurio a ser visualizado; 3 - O sistema mostra os dados do usurio.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema com uma conta de

administrador

Quadro 19 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

75

Caso de Uso:

UC10 - Alterar tipo de conta de usurio

Este caso de uso inicia-se quando o administrador precisa alterar o tipo de conta de um usurio Administrador 1 - O administrador lista os usurios do sistema (UC08); 2 - O administrador visualiza os dados do usurio (UC09); 3 - O administrador altera o tipo de conta do usurio; 4 - A administrador clica em salvar; 5 - O sistema mostra uma mensagem de salvo com sucesso.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema com uma conta de

administrador

Quadro 20 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC11 - Excluir usurio

Este caso de uso inicia-se quando necessrio excluir um usurio do sistema. Administrador 1 - O administrador lista os usurios do sistema (UC08); 2 - O administrador seleciona o usurio; 3 - O sistema mostra a opo "Excluir"; 4 - O administrador clica em "Excluir"; 5 - O sistema mostra uma janela de confirmao; 6 - O administrador clica em "Sim"; 5 - O sistema mostra um aviso de excluso efetuada.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema com uma conta de

administrador

Quadro 21 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

76

Caso de Uso:

UC12 - Bloquear ou desbloquear usurio

Este caso de uso inicia-se quando necessrio bloquear ou desbloquear o acesso de um usurio no sistema. Administrador 1 - O administrador lista os usurios do sistema (UC08); 2 - O administrador seleciona o usurio; 3 - O sistema mostra a opo bloquear/desbloquear; 4 - O administrador clica em bloquear/desbloquear; 5 - O sistema mostra um aviso de bloqueio/desbloqueio efetuado.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema com uma conta de

administrador

Quadro 22 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

Caso de Uso:

UC13 - Alterar preferncias e dados de usurio

Este caso de uso inicia-se quando necessrio alterar preferncias de usurio e senha de acesso. Administrador 1 - O usurio clica em "Opes" 2 - O usurio altera suas preferncias e/ou senha de acesso; 3 - O usurio clica em "Salvar"; 4 - O sistema mostra uma mensagem de salvo com sucesso.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar logado no sistema

Quadro 23 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

77

Caso de Uso:

UC14 - Recuperao de senha

Este caso de uso inicia-se quando necessrio recuperar a senha de acesso ao sistema. Administrador 1 - O usurio clica em "Esqueceu sua senha"; 2 - O usurio digita seu e-mail e clica em "Recuperar Senha"; 3 - O sistema gera uma nova senha e envia por e-mail.

Descrio: Atores:

Fluxo de Tarefas:

Condies:

Pr-condio: O usurio precisa estar cadastrado no sistema.

Quadro 24 Documentao de Caso de Uso Listar Usurios Cadastrados. Fonte: Elaborado pelos autores (2010).

3.6.12.1 Diagrama de Robustez

O diagrama de robustez uma forma especial de diagrama de colaborao da UML que contm uma realizao de anlise de caso de uso. (SCOTT, 2002, p. 50). Uma verificao de que aquilo que foi levantado nos casos de uso vivel ou no pode ser respondido com o diagrama de robustez, e em processos como ICONIX isso transcreve a metfora de anlise (o que), para o diagrama (como). Um modelo que mostra os objetos mais importantes - classificados em perifricos/interface, de entidade e de controle/processo - que participam da realizao e da interao de um ator com um sistema, conforme definido por um cenrio de uso. (AMBLER, 2002, p. 331). A seguir, mostram-se os principais diagramas de robustez do sistema proposto:

78

Figura 25 - Diagrama de Robustez Criar Nova Conta Fonte: Elaborado pelos autores (2010)

79

Figura 26 - Diagrama de Robustez Importar Planilha Eletrnica Fonte: Elaborado pelos autores (2010)

3.6.12.2 Diagrama de Seqncia

Um diagrama de seqncia ilustra, para cada caso de uso, os eventos gerados pelos atores, sua ordem e os eventos entre os sistemas. a explicao detalhada de como o software vai funcionar (LARMAN, 2005, p.198). Nas anlises preliminares, so feitas algumas suposies de como as classes iro interagir. Ao modelar diagramas de seqncia, as interaes entre as classes so detalhadas e se tornam muito mais precisas. Existe uma ligao direta entre os casos de uso, diagramas de robustez e diagramas de seqncia. Para cada caso de uso identificado, cria-se um diagrama de robustez e um diagrama de seqncia (ROSEMBERG; STEPHENS, 2007, p. 186). Os principais diagramas de seqncia do sistema proposto se seguem:

80

Figura 27 - Diagrama de Seqncia - Criar Nova Conta Fonte: Elaborado pelos autores (2010)

81

Figura 28 - Diagrama de Seqncia - Importar Planilha Eletrnica Fonte: Elaborado pelos autores (2010)

82 3.6.13 Diagrama de Classes

Um diagrama de classes serve para ilustrar as classes, interfaces e suas associaes (LARMAN, 2005, p.266). Esse diagrama UML tambm utilizado para fazer a modelagem de domnio, porm transcrito de uma maneira conceitual, resumidamente, onde as classes no apresentam os mtodos e funes, apenas os nomes das classes e suas relaes. Um termo de modelagem comum para a finalidade de demonstrar as classes do sistema diagrama de classes do projeto (DCP). (LARMAN, 2005, p.266). Esse termo usado para no confundir com o modelo conceitual da modelagem de domnio, por utilizarem a mesma notao grfica da UML. A seguir, o diagrama de classes persistentes do sistema proposto:

83

Figura 29 - Diagrama de Classes Persistentes Fonte: Elaborado pelos autores (2010)

84 3.6.14 Diagrama Entidade-Relacionamento

O Modelo Entidade-Relacionamento a forma mais comum de expressar o resultado analtico de um estgio inicial de um novo Banco de Dados. Neste primeiro estgio, normalmente no prioridade tpicos como desempenho. O objetivo principal definir quais informaes a camada de negcio precisar para efetuar determinadas operaes, como a informao poder ser armazenada da melhor forma possvel e quais relaes existem entre diferentes conjuntos de informaes (PEDERSEN, 2004). Segundo Pedersen (2004), o modelo entidade-relacionamento consiste em mapear: Entidades: um objeto especfico de interesse do negcio. Cada unidade de informao chamada de entidade, com nome e atributos; Atributos: cada entidade normalmente possui um ou mais atributos. coerente afirmar que os atributos so pequenos pedaos de informao da entidade; Relacionamentos: em um banco de dados relacional, todas as entidades possuem ligaes entre elas expressadas como relacionamentos. Um relacionamento uma ligao entre entidades. Para Peter Chen (2010), o modelo entidade-relacionamento baseado fortemente em fundamentos matemticos, pois a cardinalidade de seus relacionamentos so explcitos no modelo.

85

Figura 30 - Diagrama Entidade-Relacionamento Fonte: Elaborado pelos autores (2010)

3.7

CONSIDERACES FINAIS

Nesta etapa, aps a modelagem, foi possvel ter uma visualizao mais ampla do sistema. Ficou claro o rumo a ser tomado quanto ao desenvolvimento. Observou-se o quo imprescindvel , para um sistema, um processo de desenvolvimento de software que seja adequado ao seu tamanho e propsito. O ICONIX, processo de modelagem e desenvolvimento selecionado pelos autores, cumpriu o seu papel: a modelagem ocorreu de forma rpida e os diagramas criados sero de suma importncia ao desenvolvimento o prximo passo deste processo.

86 4 DESENVOLVIMENTO

Neste captulo, sero apresentadas as tecnologias que foram empregadas na criao do sistema e as ferramentas utilizadas para o manuseio destas tecnologias. Sero apresentadas tambm as telas do sistema e a forma utilizada para validao de suas funcionalidades.

4.1

TECNOLOGIAS E FERRAMENTAS

A escolha das tecnologias e ferramentas utilizadas partiu de algumas premissas, como confiabilidade, desempenho, funcionalidades e conhecimento dos autores sobre as mesmas. Foi dada preferncia tambm a ferramentas livres e/ou open source, apesar de algumas ferramentas utilizadas, por conta do grande benefcio que as mesmas trouxeram ao desenvolvimento, so proprietrias.

Figura 31 - Tecnologias e Ferramentas Fonte: Elaborado pelos autores (2010).

87 4.1.1 Java

Java uma linguagem de programao, e com ela possvel desenvolver sistemas que so independentes de plataforma ou sistema operacional, e que so executados em uma grande variedade de ambientes de hardware e software (O NEIL, 1999). A linguagem Java possui funcionalidades significativas, orientada a objetos e, por isso, permite a reutilizao de cdigo. Possui tratamento de excees, possibilitando a manipulao de erros de execuo de forma organizada. O Garbage Collection executado automaticamente, recuperando recursos de memria de objetos que no esto mais sendo utilizados. Estas e outras funcionalidades facilitam o desenvolvimento de sistemas robustos com Java (O NEIL, 1999).

4.1.2

Adobe Flash

O Adobe Flash um software de criao de multimdia que se tornou praticamente um padro na Web. O Flash surgiu na metade dos anos 90, quando profissionais em animao, como a Disney Online e o MSN da Microsoft comearam a utilizar sua primeira verso, chamada na poca de FutureSplash. Com o passar dos anos, o Flash acabou se tornando uma alternativa ao Java para criao de animaes vetoriais (VEER, 2007, p. 1). Por meio do Flash Player, um complemento disponvel para praticamente todos os browsers existentes, os usurios podem executar aplicativos feitos em Flash. O percentual de instalao do Flash Player nos web browsers atualmente de 99% (ADOBE, 2010).

4.1.3

Adobe Flex

Adobe Flex um framework de desenvolvimento que fornece componentes de nvel corporativo para o Flash Player, por intermdio de uma linguagem de marcao

88 reconhecida e de fcil aprendizado para quem tenha experincia com HTML ou XML. O framework Flex fornece componentes visuais como janelas, efeitos, tabelas, grficos, comunicao com servidor, e outros (NOBLE; ANDERSON, 2008). De acordo com a Adobe (2010), Flex um framework de desenvolvimento, de alta produtividade, open source, livre, permitindo a produo de aplicaes Web que podem ser acessadas consistentemente a partir de quaisquer browsers, desktops e sistemas operacionais, por meio do Adobe Flash Player e do Adobe AIR. A maioria das linguagens teve o suporte para criao de interfaces depois de sua criao. Um exemplo seria o Java, que teve o Swing criado especificamente para dar suporte criao de interfaces. Como resultado, muitas vezes, criar algo simples exige muito trabalho, e para ser produtivo, deve-se ter um conhecimento profundo da API. Com Flex ocorre exatamente o oposto: seu objetivo, desde o princpio, a criao de interfaces. Sendo assim, muito mais fcil criar interfaces grficas e tratar seus eventos em Flex ao comparar com JSF/Faces ou JSP/HTML/CSS/Javascript. Com Flex, possvel ser produtivo mesmo conhecendo pouco sobre a linguagem (KNIGHT, 2009).

4.1.4

Adobe BlazeDS

BlazeDS uma tecnologia de troca de mensagens com base em um servidor web Java, que permite de uma forma simples conectar este a aplicaes desenvolvidas em Flex. Desta forma, atravs de um browser, utilizando o Adobe Flash Player, uma aplicao em Flex pode fazer chamadas remotas a mtodos de classes Java no servidor de forma transparente. Alm disso, o BlazeDS utiliza o Adobe Message Format (AMF), um formato binrio de transferncia de dados atravs do protocolo HTTP, fato que aumenta consideravelmente a performance, fazendo com que os dados sejam carregados em at 10 vezes mais rpido do que formatos baseados em texto como XML ou SOAP (ADOBE, 2010). De acordo com a Adobe (2010), as maiores razes para utilizar o BlazeDS so: Facilidade de conectar aplicaes em Flex com a lgica de servidor Java j existente; Alto desempenho de transferncia de dados; Acesso em tempo real ao servidor via protocolo HTTP;

89 Livre e open source.

4.1.5

Apache Tomcat

Apache Tomcat um servidor web de Servlets Java e Java Server Pages, desenvolvido pela Apache Software Foundation. Um servidor web um software que devolve pginas web em resposta as requisies de, por exemplo, um usurio utilizando um browser web (BRITTAIN; DARWIN, 2008). O Apache Tomcat uma implementao open source das tecnologias Servlets Java e Java Server Pages, sendo que sua especificao definida pela Java Comunity Process (APACHE, 2010).

4.1.6

MySQL

MySQL um sistema de Banco de Dados relacional. O MySQL o Sistema Gerenciador de Banco de Dados open source mais utilizado atualmente. Dentre as suas caractersticas que justificam sua utilizao, pode-se citar (KOFLER, 2005): Rapidez; Estabilidade; Fcil aprendizado; executado nos Sistemas Operacionais mais populares (Windows, Linux, Mac OS X e vrias verses de UNIX); acessado por uma grande variedade de linguagens de programao (C, C#, C++, Java, Perl, PHP, Python, VB, VB.NET, entre outras); Possui uma grande extenso de documentos e tutoriais sobre o mesmo disponveis na Internet, e tambm vrios livros sobre o assunto foram lanados; Est disponvel de forma livre, sobre a licena GPL.

90 4.1.7 Eclipse

O Eclipse uma Plataforma de Desenvolvimento de Software distribudo na forma de software livre pela Eclipse Foundation. Em uma comparao direta a algumas IDEs Java, o Eclipse tem uma grande vantagem: a IBM e a Rational Software foram um dos fundadores do consrcio Eclipse.org em 2001, e atualmente a IBM Rational um membro estratgico da Eclipse Foundation (IBM, 2010). Com seus plug-ins, o Eclipse tornou-se uma plataforma de desenvolvimento universal, pois possui suporte a ferramentas que vo alm da linguagem Java para desenvolver em outras linguagens, basta instalar os plug-ins relativos a cada linguagem (HOLZNER, 2004, p. 6).

4.1.8

Adobe Flash Builder

O Adobe Flash Builder (antigo Flex Builder) um software proprietrio criado pela Adobe para desenvolver aplicaes utilizando a framework Flex de uma forma rpida e produtiva. Inclui suporte a codificao inteligente, debug, editor visual e funcionalidades de teste que aceleram o processo de desenvolvimento de software. O Flash Builder disponibilizado de forma autnoma ou como um plug-in para o Eclipse (ADOBE, 2010). A Adobe fornece licenas do Flash Builder de forma gratuita para: Estudantes, professores e funcionrios de instituies de ensino; Desenvolvedores afetados pela crise econmica que esto desempregados; Participantes de eventos que receberam cdigos promocionais.

91 4.1.9 Adobe Fireworks

Adobe Fireworks um software proprietrio de autoria da Adobe de criao e edio de imagens que combina tecnologias de tratamento de imagens vetoriais e bitmap. O Fireworks tem o seu foco na criao e manipulao de imagens para a Web, dispositivos como smartphones e outras formas de visualizao de imagens em telas eletrnicas. O Fireworks possui integrao com outras aplicaes da sute Adobe como Photoshop, Dreamweaver e Flash Professional, e tambm exporta seus projetos para vrios formatos como PDF e pginas padres web em HTML e CSS (ADOBE CREATIVE TEAM, 2009).

4.1.10 Balsamiq Mockups

Balsamiq Mopckups um software proprietrio de prototipao de tela criado pela Balsamiq Studios. uma aplicao robusta que contm vrios elementos de interface de usurio desenhados a mo, tanto para modelagem de interfaces de aplicativos Desktop, Web ou IPhone. Isso permite que prottipos de tela sejam produzidos de forma limpa e profissional, mantendo a aparncia de como se tivessem sidas desenhadas a mo (WOOLDRIDGE, 2010). O Balsamiq Mockups possui 75 componentes de tela prontos para desenhar os mais variados tipos de tela, sendo que os mesmos tm a aparncia de terem sido desenhados mo de forma proposital, para que o usurio no fique preso a algum tipo de tema ou cor em especfico, e tambm para evitar que este pense que existe cdigo desenvolvido por trs da tela e que o sistema est praticamente pronto (BALSAMQ STUDIOS, 2010). Alm da licena que desktop com todas as funcionalidades, o Balsamiq Mockups pode ser utilizado na forma de demonstrao diretamente no site do produto, sendo que as interfaces projetadas podem ser exportadas em formato PNG ou XML para futuras alteraes.

92 4.1.11 Subversion

O Subversion (SVN) um sistema para controle de verso livre e open source. O Subversion controla arquivos e diretrios, e as mudanas feitas a estes no decorrer do tempo, permitindo recuperar verses antigas de cdigo fonte ou examinar o histrico de como o cdigo foi modificado. O Subversion pode funcionar atravs de redes, permitindo a utilizao entre usurios em diferentes computadores. Este fato permite que vrias pessoas possam trabalhar em um mesmo projeto, de forma colaborativa. Como todo o trabalho possui o histrico de alteraes, caso alguma modificao errada for salva, basta desfazer a modificao (PILATO;SUSSMAN;FITZPATRICK, 2008).

4.2

HISTRICO DE DESENVOLVIMENTO

Com relao ao processo de desenvolvimento, o primeiro passo foi aperfeioar o conhecimento sobre as tecnologias e ferramentas utilizadas. Apesar dos autores j terem conhecimento e experincia em desenvolvimento web, se fez necessrio um aprofundamento no conhecimento de algumas funcionalidades, em especfico o upload de arquivos com Flex, a leitura de arquivos XLS com Java e a utilizao da API do Google Maps. Em algumas funcionalidades, como por exemplo, o sistema de login, foi utilizado o padro JAAS, uma API de segurana presente em todos os servidores web Java. Apesar de todo o sistema ser desenvolvido em Flex, por conta de o acesso ser por meio da Internet, todas as pginas referentes ao login, criao de nova conta, ativao e recuperao de senha foi desenvolvido por completo em JSP. A justificativa que o visitante no precisa baixar toda a aplicao em Flash para descobrir que no tem acesso e que necessrio se registrar para acessar o sistema. Uma das grandes dificuldades encontradas no decorrer do desenvolvimento foi o upload de arquivos em Flex. Em um primeiro momento, funcionava apenas no navegador Internet Explorer: em outros navegadores o Flash Player lanava um erro de entrada/sada (IO Error). O fato que o erro era genrico: no mostrava detalhes do problema. Este fato

93 atrasou um pouco o desenvolvimento, pois foi complexa sua resoluo. Aps uma exaustiva busca pela Internet, trs dias depois, em um frum internacional, outro desenvolvedor com o mesmo erro conseguiu resolv-lo. O estado de sesso atravs de um navegador controlado atravs de cookies, sendo que este cookie enviado em toda requisio: assim o servidor reconhece quem cada usurio que est utilizando o sistema. Desta forma, o Flash Player dos navegadores Mozilla Firefox e Google Chrome, no momento de fazer o upload, no enviam o cookie contendo os dados de autenticao do usurio, gerando o problema em questo. Sendo assim, os dados de autenticao de usurio passaram a ser enviados manualmente no momento do upload, resolvendo o problema por completo. Com a funcionalidade de upload completa, o prximo desafio foi armazenar a planilha de uma forma que fosse simples e funcional, para que estes dados pudessem ser rapidamente recuperados e lanados na API de mapas do Google. Vrias alternativas foram levantadas, e dentre todas elas, a que melhor se encaixa com o propsito do sistema foi guardar os dados da planilha em formato XML. A justificativa para esta escolha reside em que o XML, alm de tambm ser uma forma de armazenar dados, extensvel, sendo que novos dados podero ser acrescentados sem impactar na estrutura do Banco de Dados. Outro fato que levou a escolha do XML foi que tanto a linguagem Java quanto o ActionScript (linguagem de programao do Flex) possuem classes prontas de leitura e escrita de XML: no foi necessrio criar uma API de manipulao de XML a partir do zero. Neste ponto do desenvolvimento, dois padres tiveram de ser criados: o padro de como a planilha deve ser para poder ser importada no sistema e tambm o padro do XML que seria armazenado. Aps algumas discusses, com os dois formatos definidos, foram desenvolvidas ento as classes responsveis pela converso entre a planilha eletrnica e o padro XML que foi criado. A API do Google Maps para Flex de fcil utilizao e em nenhum momento houve limitaes para desenvolver as funcionalidades previstas. O sistema busca o XML armazenado no Banco de Dados, faz a leitura do mesmo e preenche o mapa com os valores importados.

94 4.3 APRESENTAO DO SISTEMA

O sistema proposto foi desenvolvido com base na modelagem presente no Captulo 3 e pode ser apresentado conforme a seguir:

4.3.1

Tela de Login

Figura 32 - Tela de Login Fonte: Elaborado pelos autores (2010).

A tela de login a tela de acesso ao sistema. Esta tela, alm do formulrio de login, possui um link para cadastro caso seja um visitante sem conta no sistema, um link para recuperar a senha de acesso e tambm dados gerais de apresentao do sistema.

95 4.3.2 Tela de Criao de Nova Conta

Figura 33 - Tela de Criao de Nova Conta Fonte: Elaborado pelos autores (2010).

A tela de criao de nova conta contm um formulrio de cadastro para visitantes que tem interesse em criar uma conta no sistema. Neste momento, verificado se o nome de usurio (login) j existe, a fora da senha criada e tambm os termos de compromisso de usurio. Ao finalizar o preenchimento do formulrio, caso o mesmo seja preenchido corretamente, o sistema ir criar uma nova conta com os dados deste formulrio e enviar uma confirmao ao e-mail da pessoa. Para finalizar o cadastro, se faz necessrio clicar no link que foi enviado por e-mail.

96 4.3.3 Tela de Recuperao de Senha

Figura 34 - Tela de Recuperao de Senha Fonte: Elaborado pelos autores (2010).

A tela de recuperao de senha serve para quem j possui conta no sistema e esqueceu o usurio ou a senha de acesso. Nesta tela, basta que o usurio entre com o seu email, e o sistema ir procurar o usurio deste e-mail e enviar uma nova senha.

97 4.3.4 Tela de Ativao de Conta

Figura 35 - Tela de Ativao de Conta Fonte: Elaborado pelos autores (2010).

A tela de ativao de conta possui apenas uma mensagem informando ao usurio que sua conta foi criada e ativada, e a partir deste momento o mesmo tem acesso ao sistema. Esta tela visualizada quando o usurio clica no link que foi enviado ao seu e-mail.

98 4.3.5 Tela Principal

Figura 36 - Tela Principal Fonte: Elaborado pelos autores (2010).

A tela principal do sistema a tela de incio, que visualizada quando o usurio digita seus dados de login e senha corretamente na tela de login. Nesta tela, existe uma barra superior que contm na parte esquerda os dados do usurio que est autenticado e na parte direita um menu para navegao. Neste menu, possvel importar um novo mapa, visualizar os mapas j importados, alterar as preferncias de usurio e sair do sistema.

99 4.3.6 Tela de Importao

Figura 37 - Tela de Importao Fonte: Elaborado pelos autores (2010).

A tela de importao onde o usurio seleciona a planilha eletrnica a ser importada no sistema. A planilha deve seguir o padro estabelecido pelo sistema. Ao selecionar a planilha, o usurio ir fazer o upload da mesma para o servidor do sistema, onde ocorrer efetivamente a importao dos dados. No final da importao, o sistema ir mostrar os dados da planilha em caso de sucesso ou mostrar uma mensagem de erro em caso de problemas na importao.

100 4.3.7 Tela de Visualizao de Dados do Mapa

Figura 38 - Tela de Visualizao de Dados do Mapa Fonte: Elaborado pelos autores (2010).

Nesta tela possvel visualizar os dados que sero visualizados no mapa. Semelhante ao Microsoft Excel, a visualizao feita a partir de uma tabela, onde na primeira coluna haver os dados referentes localizao geogrfica. Nesta tela tambm possvel alterar o nome do mapa. O nome padro ser sempre o nome da planilha que foi importada.

101 4.3.8 Tela de Visualizao de Mapa

Figura 39 - Tela de Visualizao de Mapa Fonte: Elaborado pelos autores (2010).

Nesta tela possvel visualizar os dados importados distribudos no mapa. Cada ponto marcado no mapa contm os dados referentes a sua localizao. possvel visualizar os dados clicando no ponto, e tambm arrastar o ponto caso o mesmo no esteja no local correto. Na esquerda, h um menu para salvar as alteraes e tambm visualizao de grfico.

102 4.3.9 Tela de Visualizao de Grfico

Figura 40 - Tela de Visualizao de Grfico Fonte: Elaborado pelos autores (2010).

Na tela de visualizao de grfico, os dados so mostrados em um grfico tipo pizza de acordo com as localizaes. Caso exista mais de um dado para cada localizao, possvel alterar o dado em uma lista de seleo.

103 4.3.10 Tela de Visualizao de Meus Mapas

Figura 41 - Tela de Visualizao de Meus Mapas Fonte: Elaborado pelos autores (2010).

Nesta tela, possvel ver a lista de todos os mapas que j foram importados, ordenados por dada em ordem decrescente. possvel tambm tomar algumas aes, como por exemplo, excluir ou visualizar um mapa.

104 4.3.11 Tela de Configuraes

Figura 42 - Tela de Configuraes Fonte: Elaborado pelos autores (2010).

Na tela de configuraes possvel alterar as preferncias de usurio como tema e senha de acesso.

4.4

VALIDAO

Uma das validaes contou com um CEO de uma empresa de grande porte, que mantm suas atividades comerciais dentro de uma extenso territorial compreendida em trs Estados brasileiros: Rio Grande do Sul, Santa Catarina e Paran. A empresa possui um sistema ERP que possui em suas funcionalidades a exportao de seus relatrios estatsticos e gerenciais. Essa exportao feita para um arquivo com extenso XLS. Aps o CEO obter um relatrio gerencial de vendas, gerado num perodo, tomou-se o cuidado de no manipular

105 os dados contidos dentro da planilha eletrnica, mantendo as informaes geradas pelo sistema com integridade. Esse cuidado foi tomado para garantir um dos objetivos do projeto, que a facilidade em importar dados no sistema proposto, sem a necessidade de intervir com parmetros ou qualquer outro recurso, garantindo assim a eficincia da validao, e a confiabilidade do projeto. A planilha eletrnica foi importada dentro do tempo esperado e o usurio no teve dificuldade em visualizar as informaes no mapa. A planilha continha informaes de venda do perodo de um determinado ms, e uma das colunas da planilha mostrava as cidades onde ocorreram vendas. O mapa revelou um profcuo espelho, que reflete o resultado das atividades comerciais dentro do dado mercado que a empresa atua. Os processos computacionais e a dificuldade da interoperabilidade entre sistemas SIG foram superados. Todavia, uma necessidade de obteno de referencia geogrfica das vendas realizadas em tempo real surgiu com uma anlise feita pelo CEO, quando o mesmo questionava sobre uma integrao maior do sistema proposto com o ERP de sua empresa. O processo de gerao de conhecimento foi alcanado. Inmeras anlises puderam ser feitas pelo CEO. Como exemplo, reas no atendidas por seus vendedores foram reveladas, e decises tomadas posteriormente ganharam eficincia. A aproximao com conceitos de BI e mtodos estatsticos podero ter embasamento de informao a partir do conhecimento gerado pelo sistema. Outra validao, no menos importante, foi realizada com uma gerente de um departamento pblico na rea da sade. Observou-se nesse momento a comprovao de um fato descrito no trabalho, onde a maioria os sistemas de informao tem como sada de dados planilhas eletrnicas. A gerente tem em sua rotina o uso do Sistema de Informao de Agravos de Notificao (SINAN) que atende seu setor no rgo pblico, e habitualmente necessita de auxilio de mapas eletrnicos para obter informaes. A gerente exportou do sistema SINAN um relatrio contendo os casos de AIDS de Santa Catarina, e de mesma forma da validao anterior, no teve problemas na importao e os dados foram importados no tempo esperado. Confrontados no mapa os dados importados, revelaram o escopo de atuao da rea da sade e a localizao por cidade do somatrio de casos de contaminao no Estado. Um comparativo entre relatrios gerados no perodo de um ano com o ano anterior foi sugerido pela gerente, pois o sistema apenas mostra relatrios isoladamente. Um recurso tambm almejado pela gerente foi o de exportar os dados para formatos de apresentaes eletrnicas e a possibilidade de imprimir os mapas, sendo que em sua funo e setor so realizados reunies e palestras para expor as informaes de resultado e

106 desempenho. Mais uma vez os recursos computacionais foram validados e a gerao de conhecimento se fez presente sem qualquer obstculo maior.

4.5

CONSIDERAES FINAIS

Nesta etapa, aps a concluso do desenvolvimento do sistema, foi possvel observar todas as suas funcionalidades e como o mesmo se comporta diante ao usurio final. Com estas observaes, foi possvel obter as concluses referentes proposta inicial dos autores.

107 5 CONCLUSES E TRABALHOS FUTUROS

Na finalizao do presente trabalho, por parte dos autores, percebe-se uma tendncia, e acompanhando a cadncia dos fatos do mundo da Internet possvel compreender que tudo que agrega valor e conhecimento s operaes comerciais, ganha subsdio e fora tecnolgica para sustentar grandes projetos. Implicitamente, existente na maioria dos projetos da Google, a metfora do gratuito esconde tendncias comerciais. A API do Google Maps utilizada no trabalho um indcio que as coordenadas desse contexto apontam para um e-commerce geo-referenciado, com informaes pontuais, onde os valores praticados sistematicamente possuiro novos indicadores e grandezas advindas do conceito de mdias locativas. A convergncia das tecnologias tratadas aqui encoraja os autores a afirmar que os hbitos de navegao na Internet esto mudando, onde tudo imerge para dentro de web mapas, onde as escolhas dos usurios possuiro sempre uma coordenada geogrfica. Um pequeno caminho foi trilhado, num percurso de substancial importncia para apoiar pequenas e grandes empresas, em decises que necessitem de uma visualizao clara em um sistema de informao geogrfica. A problemtica de administrar, transmitir e gerir informao a partir de dados entre dois sistemas nesse trabalho foram atingidos: o sistema, pronto, conteve todas as funcionalidades previstas pelos autores. Arquivos contendo dados provenientes de outros sistemas puderam ser importados e visualizados no mapa, rompendo a barreira da inacessibilidade desse tipo de recurso aos usurios que possuem em seus sistemas uma grande gama de dados por conta da complexidade de integrao com um sistema SIG. Dentro da metodologia ICONIX, at ento desconhecida pelos autores, o desenvolvimento metdico dos processos de desenvolvimento refletiu um ambiente rpido. A mesma mostrou-se muito eficaz no decorrer da modelagem, sendo uma metodologia rpida, mas que mantm diagramas essenciais para o desenvolvimento. Ter uma viso clara e ampla do projeto s foi possvel graas metodologia usada. Quanto ao desenvolvimento, as tecnologias Java EE e Flex se mostraram altamente eficientes. A integrao entre as mesmas ocorre de uma forma muito transparente, mantendo a robustez da linguagem Java com a agilidade de desenvolvimento do Flex. Sobre o Flex, apesar de estar no mercado h poucos anos, possvel obter muito material sobre o mesmo na Internet. A Adobe disponibiliza no seu site oficial treinamentos

108 completos em vdeo e uma pgina de ajuda contendo todos os componentes do Flex com exemplos. No Brasil, muitos blogs contm tutoriais em portugus sobre vrias funcionalidades da linguagem, porm os melhores contedos sobre Flex esto em lngua inglesa. Desta forma, imprescindvel a leitura nessa lngua para que a premissa do Flex seja atendida: desenvolver interfaces de forma rpida e eficiente. Mesmo assim, observou-se que o Flex, hoje, possui seu espao no mercado brasileiro, inclusive na grande Florianpolis. Sobre as perspectivas futuras, podem-se citar algumas funcionalidades como a separao e preenchimento dos municpios e estados em cores, e tambm colorir o mapa de acordo com os valores da planilha funcionalidade conhecida como mapa trmico (heat map). Dentre as funcionalidades futuras que podem fazer com que o sistema desenvolvido tenha chance de sucesso, duas se destacam: relacionar os dados de cada mapa com dados estatsticos de mercado e a possibilidade de integrao direta com outras bases de dados, sem a necessidade de importao via planilha eletrnica. Caso essas funcionalidades sejam atendidas, o sistema ir funcionar de forma semelhante aos sistemas de BI: um sistema de gesto empresarial contendo todas as movimentaes dirias e outro sistema (no caso, o Ceomaps) atuando sobre estes dados e gerando informao, agindo como um sistema de apoio a decises de negcio.

109 REFERNCIAS

ADOBE CREATIVE TEAM. Adobe Fireworks CS4 Classroom in a Book. USA: Adobe Press, 2009. ADOBE. Adobe Flash Builder 4. Disponvel em: <http://www.adobe.com/products/flashbuilder/>. Acesso em: 4 mai. 2010. ______. Adobe Flash Player. Disponvel em: <http://www.adobe.com/products/flashplayer/>. Acesso em: 3 mai. 2010. ______. Adobe Flex: Open Source Framework. Disponvel em: <http://www.adobe.com/products/flex/>. Acesso em: 16 abr. 2010. ______. BlazeDS Overview. Disponvel em: <http://opensource.adobe.com/wiki/display/blazeds/Overview>. Acesso em: 30 abr. 2010. ALHIR, Sinan Si. Understanding Use Case Modelling. Disponvel em: <http://www.methodsandtools.com/archive/archive.php?id=24>. Acesso em: 08 abr. 2010. AMBLER, Scott W. Modelagem gil: Prticas eficazes para Programao Extrema e o Processo Unificado. So Paulo: Bookman, 2002. APACHE. Apache Tomcat. Disponvel em: <http://tomcat.apache.org/>. Acesso em: 29 abr. 2010. BALSAMIQ STUDIOS. Balsamiq Mockups. Disponvel em: <http://www.balsamiq.com/products/mockups>. Acesso em: 6 mai. 2010. BERNHARDSEN, Tor. Geographic Information Systems: An Introduction. USA: John, Wiley & Sons, 2002. BLANK, Andrew G. TCP/IP Foundations. USA: Sybex, 2002. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modelling Language User Guide. USA: Addison-Wesley, 1998. BRITTAIN, Jason; DARWIN, Ian F. Tomcat: The Definitive Guide. USA: OReilly, 2008. CS, Danilo Da. Manual Terico-prtico para Elaborao Metodolgica de Trabalhos Acadmios. So Paulo: Jubela Livros, 2008. CHEN, Peter P. Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned. Disponvel em: <http://bit.csc.lsu.edu/~chen/pdf/Chen_Pioneers.pdf>. Acesso em: 6 mai. 2010. COSTA, Daniel Gouveia. DNS - Um Guia Para Administradores de Redes. Rio de Janeiro: Brasport, 2007. DEITEL, H. M. Java, como programar. 4. Ed. Porto Alegre: Bookman, 2003.

110 DRAMOWICZ, Ela. Three Standard Geocoding Methods. Disponvel em: <http://www.directionsmag.com/article.php?article_id=670>. Acesso em: 18 set. 2009. FOWLER, Martim. Padres de Arquitetura de Aplicaes Corporativas. Porto Alegre: Bookman, 2003. FREDERICKS, Anthony D. Social Studies Discoveries on the Net. USA: Libraries Unlimited, 2000. HOLZNER, Steve. Eclipse. USA: OReilly, 2004. IBM. Rational And Eclipse. Disponvel em: <http://www01.ibm.com/software/rational/eclipse/>. Acesso em: 4 mai. 2010. KNIGHT, Ryan. 13 Reasons for Java Programmers to Learn Flex and BlazeDS. Disponvel em <http://www.infoq.com/articles/java-flex-blazeds> Acesso em: 15 abr. 2010. KOFLER, Michael. The definitive guide to MySQL 5. USA: Apress, 2005. KORTE, George. The GIS book. USA: Thompson Learning, 2001. LARMAN, CRAIG. UML e Padres. Porto Alegre: Bookman, 2005. LEO, Lucia. Derivas: cartografias do Ciberespao. So Paulo: Annablume, 2004. LYTRAS, Miltiadis D.; DAMIANI, Ernesto; PABLOS, Patricia Ordez de. Web 2.0: The Business Model. USA: Spring, 2009. MANOVICH, Lev. Visualizao de Dados como uma nova abstrao e anti-sublime. In: LEO, Lucia. Derivas: cartografias do Ciberespao. So Paulo: Annablume, 2004. p. 149162. MARAKAS, George M. Decision support systems in the 21st century. USA: Prendice Hall, 2002. MARISCO, N.; PHILIPS, J.; PEREIRA, H. R. Prottipo de Mapa para Web Interativo: Uma Abordagem Utilizando Cdigo Aberto. Revista Brasileira de Cartografia, Rio de Janeiro, v. 56 n. 01, jul. 2004. Disponvel em: <http://www.rbc.ufrj.br/_pdf_56_2004/56_1_08.pdf>. Acesso em: 27 set. 2009. MARTINS, Jos Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e EML. 4. Ed. So Paulo: Brasport, 2007. MCPHERSON, Stephanie Sammartino.Tim Berners-lee: Inventor of the World Wide Web. USA: Twenty First Century Books, 2009. MINIWATTS MARKETING GROUP. World Internet Usage Statistics News and World Population Stats. Disponvel em: <http://www.internetworldstats.com/stats.htm>. Acesso em: 29 ago. 2009. MITCHELL, Tyler. Web Mapping Illustrated. USA: OReilly, 2005.

111 MORGAN, Tony. Business Rules and Information Systems: Aligning IT whith Business Goals. USA: Addison-Wesley, 2002. NOBLE, Joshua; ANDERSON, Todd. Flex 3 Cookbook. USA: OReilly, 2008. ORENSTEIN, David. QuickStudy: Application Programming Interface (API). Disponvel em: <http://www.computerworld.com/s/article/43487/Application_Programming_Interface>. Acesso em: 18 out. 2009. O NEIL, Joseph. Teach Yourself Java. USA: McGraw-Hill, 1999. PENG, Zhong-Ren; TSOU, Ming-hsiang. Internet GIS: distributed geographic information services for the Internet and wireless networks. USA: John, Wiley e Sons, 2003. PEDERSEN, Alf A. Entity Relationship Modelling. Disponvel em: <http://www.devarticles.com/c/a/Development-Cycles/Entity-Relationship-Modeling/>. Acesso em: 6 mai. 2010. PETERSON, Michael P. A Critical Assessment of Maps and the Internet. Revista Brasileira de Cartografia, Rio de Janeiro, v. 60 n. 03, out. 2008. Disponvel em: <http://www.rbc.ufrj.br/_pdf_60_2008/60_03_7.pdf >. Acesso em: 27 set. 2009. PICK, James B. Geo-business GIS in the Digital Organization. USA: Wiley, 2007. PILATO, C. Michael; SUSSMAN, Ben Collins; FITZPATRICK, Brian W. Version Control With Subversion. USA: OReilly, 2008. REZENDE, Denis Alcides. Engenharia de Sotware e Sistemas de Informao. Rio de Janeiro: Brasport, 2005. ROOS, Dave. How to Leverage an API for Conferencing. Disponvel em: <http://communication.howstuffworks.com/how-to-leverage-an-api-for-conferencing.htm>. Acesso em: 18 out. 2009. ROSEMBERG, Doug; STEPHENS, Matt. Use Case Driven Object Modeling With UML. USA: Apress, 2007. ROSEMBERG, Doug; SCOTT, Kendal. Introduction to ICONIX Process of Sotware Modelling. Disponvel em: < http://www.informit.com/articles/article.aspx?p=167902>. Acesso em: 31 mar. 2010. SAMPAIO, Cleuton. Web 2.0 e Mashups - Reinventando a Internet. Rio de Janeiro: Brasport, 2007. SANTOS, Antonio Raimundo. Metodologia Cientfica a Construo do Conhecimento. Rio de Janeiro: De Paulo, 2001. SCOTT, Kendal. Processo Unificado Explicado. So Paulo: Bookman, 2002. SOMMERVILLE, Ian. Engenharia de Software. 8. Ed. So Paulo: Pearson AddisonWesley, 2007.

112 SOLOMON, Gwen; SCHRUM, Lynne. Web 2.0: New Tools, New Schools. USA: International Society for Technology in Education, 2007. STEWART, William. Web Browser History. Disponvel em: <http://www.livinginternet.com/w/wi_browse.htm>. Acesso em: 27 set. 2009. SUTTON, Chris. Internet Began 35 Years Ago at UCLA with First Message Ever Sent Between Two Computers. Disponvel em: <http://www.engineer.ucla.edu/stories/2004/Internet35.htm>. Acesso em 27 de Setembro de 2009. TAURION, Cezar. Cloud Computing Computao em Nuvem: Transformando o mundo da Tecnologia da Informao. Rio de Janeiro: Brasport, 2009. VEER, Emyly A. Vander; GROVER, Chris. Flash CS3: The Missing Manual. USA: OReilly, 2007. WOOLDRIDGE, Dave. The Business of IPhone App Development: Making and Marketing Apps that Succeed. USA: Apress, 2010. ZITTRAIN, Jonathan. The Future of the Internet--And How to Stop It. USA: Creative Commons, 2008.

113 GLOSSRIO

Applet Java: Aplicativo Java executado a partir de um navegador de Internet. Bitmap: Imagem que contm a descrio de cada pixel sendo este o menor elemento em um dispositivo de exibio de imagem. Blog: um web site cuja estrutura permite a sua atualizao rpida atravs de artigos ou posts. Browser: Navegador de Internet. Cliente Web: idem Browser. Cookies: um conjunto de dados trocados entre o navegador de Internet e o servidor de pginas. Deploy: Ato de mover o sistema de seu estado de desenvolvimento ou testes para produo. E-Commerce: Comrcio eletrnico. Feeds RSS: Formato de dados usado por web sites que so atualizados constantemente, como notcias e blogs, onde seus assinantes so notificados de sua atualizao. Framework: um conjunto de cdigos comuns entre vrios projetos de software, que provm uma funcionalidade genrica. Garbage Collection: Em Java, uma coleo de funcionalidades da linguagem, utilizada para automatizar o gerenciamento de memria, evitando que o programador tenha de lidar manualmente com espao de memria que no est mais sendo utilizado. Hiperlink: Uma referncia entre um documento ou pgina da Internet a outras partes deste documento ou a outro. Interface: 1. Forma de interao entre o computador e o usurio; 2. Uma tela de um sistema. Link: idem Hiperlink. Login: 1. a ao necessria para acessar um sistema computacional restrito inserindo uma identificao; 2. Registrar-se; 3. Conjunto de caracteres solicitados por sistemas computacionais para que os usurios possam acess-lo. 4. Nome de usurio. Mdias Locativas: Dispositivos ou sensores capazes de mapear, rastrear ou gerar informaes sobre o espao e a geografia atravs de sua mobilidade. Off-The-Shelf: Termo que define uma tecnologia que est pronta para ser utilizada, comercializada ou liberada. Open Source: Software de cdigo aberto. Plug-In: Programa de computador usado para adicionar funes a outros programas maiores.

114 Scroll: Boto do mouse em formato de roda, situado entre os botes esquerdo e direito. Servidor Web: 1. Programa de computador responsvel por aceitar pedidos HTTP, normalmente de navegadores, e conseqentemente devolver respostas HTTP, sendo estas normalmente pginas HTML; 2. Computador que executa tal programa. Servlet Java: Classe Java responsvel por atender a requisies, em sua grande maioria requisies HTTP. Stakeholder: a pessoa, organizao ou parte de interesse no sistema. Normalmente, a pessoa que contm o conhecimento do negcio onde o sistema ir atuar. Tags: Estrutura de linguagens de marcao que contm instrues, um incio e um fim. Em HTML e XML, as tags so identificadas por iniciar com < e fechar com >. Upload: a transferncia de um arquivo do computador local para um servidor. Verso Beta: a verso de um software que ainda est em fase de desenvolvimento e testes. Web: Abreviao de World Wide Web. Websites: 1. Site da Internet; 2. Conjunto de pginas HTTP. Wiki: Website que permite a sua edio de forma colaborativa, permitindo que o seu contedo seja publicado sem necessidade de reviso. Workflow: 1. Fluxo de Trabalho; 2. Sequncia de passos ou conjunto de regras definidas.

115

APNDICES

116 APNDICE A MANUAL DO USURIO

117

118

119

120

121

122

123

124

125

126

127

128 APNDICE B DOCUMENTO DE REQUISITOS

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152