Sistema móvel para controle de rondas

UNIVERSIDADE

FEDERAL

DE

SANTA

CATARINA

SISTEMA

MÓVEL

PARA

CONTROLE

DE

RONDAS

Florianópolis, 21 de Fevereiro de 2013.

S

ISTEMA MÓVEL PARA CONTROLE DE RONDAS

Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de informação

Profª orientador:

Fernando Augusto Cruz da Silva Banca examinadora:

Prof. Mário Antônio Ribeiro Dantas Profa. Vânia Bogony

Agradeço principalmente a minha namorada Helena, meus avaliadores, minha família e meu orientador: Leonardo <Leonardo.vatos@gmail.com>.

“Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que aponta uma nova direção”.

Na mesma velocidade que a sociedade evolui, a criminalidade avança sobre to-dos os segmentos e camadas da população, com isso a busca por empresas priva-das de monitoramento e vigilância para fazer a segurança tanto de residências quanto de empresas também aumenta. Basicamente quando este serviço é contra-tado, são instalados pontos magnéticos nos locais que devem ser monitorados, em seguida um vigilante fica responsável por verificar periodicamente estes locais e uti-lizar um bastão eletrônico para registrar sua ronda. Para registrar a ronda é neces-sário o simples contato do bastão com o ponto magnético. Este serviço atualmente não é acessível à maioria da população devido a seu custo elevado. Levando-se em consideração a grande evolução da tecnologia e o custo cada vez mais reduzido dos dispositivos móveis surgiu a presente proposta que apresenta um ambiente cli-ente servidor, sugere um modo alternativo para realização deste monitoramento uti-lizando inicialmente apenas um dispositivo móvel que possua o sistema operacional Android, acesso a internet, GPS e câmera, onde será instalado um aplicativo que trocará informações com um servidor periodicamente, contendo todas as informa-ções necessárias sobre as rondas, incluindo fotos quando necessário.

At the same speed as society evolves, progresses on to crime-of segments and strata of the population, so the search for private companies from monitoring and surveillance to guard both residential as business increases. Basically when this ser-vice is counter-tion, magnetic points are installed in places that should be monitored, then a vigilante is responsible for periodically checking these sites and a stick-able to register their electronic round. To register it is necessary to round the simple touch of the stick with the magnetic point. This service is currently not available to the majority of the population due to its high cost. Taking into account the great evolution of technology and the ever-shrinking cost of mobile devices has emerged that this pro-posal presents a cli-ment server environment, suggests an alternative way to carry out this monitoring us-ing initially only a mobile device that has Android operating system, internet access, GPS and camera, where you install an application that ex-change information with a server periodically, containing all necessary information about the tours, including photos when necessary.

Figura 1 - Ponto de ronda ... 13

Figura 2 - Bastão de ronda ... 14

Figura 3 - Sistema operacional Android 4.0 ... 17

Figura 4 - Theme Roll para o JQuery mobile ... 29

Figura 5 - Estrutura da tag Header do JQuery e Phonegap. ... 29

Figura 6 - Estrutura do corpo da página com JQuery. ... 30

Figura 7 - Página JQuery com 2 páginas no mesmo documento. ... 31

Figura 8 - Estrutura de um script que utiliza jQuery. ... 32

Figura 9 - SmartPhone Sony Xperia U ... 32

Figura 10 - Código em JavaScript para obter imagem da câmera... 34

Figura 11 - Inicializando google maps ... 36

Figura 12 - Criando marcador ... 36

Figura 13 - criando circulo... 37

Figura 14 - Visão geral da solução ... 38

Figura 15 - Diagrama de Casos de uso. ... 40

Figura 16 - Diagrama de atividades - carregar dados do servidor ... 40

Figura 17 - Diagrama de atividades - enviar dados para o servidor ... 41

Figura 18 - Modelagem do banco de dados do lado cliente. ... 42

Figura 19 - Prévia da modelagem do banco de dados do lado servidor. ... 43

Figura 20 - Estrutura de pacotes Java ... 45

Figura 21 - Estrutura do WebContent do projeto ... 46

Figura 22 - Tela de login do ambiente servidor ... 47

Figura 23 - Tela de cadastro de clientes ... 47

Figura 24 - Tela de cadastro de vigilantes ... 48

Figura 25 - Tela de cadastro de ronda no mapa ... 49

Figura 26 - Tela de cadastro de periocidade de ronda ... 49

Figura 27 - Estrutura do cliente mobile ... 51

Figura 28 - Tela de login ... 52

Figura 29 - Tela de menu ... 53

Figura 30 - Tela do mapa ... 54

Sumário

2.1 Sistema atual de rondas ... 13

2.2 IDEs para desenvolvimento ... 14

2.2.1 Eclipse ... 14

2.2.2 MySQL WorkBench ... 15

2.3 Tecnologias para desenvolvimento ... 16

2.3.1 Sistema operacional Android ... 16

2.3.2 JQuery Mobile ... 17 2.3.3 Framework PhoneGap ... 18 2.3.4 WebService ... 18 2.3.5 Servidores ... 23 2.3.6 Bancos de dados ... 24 2.3.7 Google Maps ... 24

2.3.8 JSF - Java Server Faces ... 25

2.4 Considerações sobre o capítulo ... 26

3 Aspectos ambiente experimental ... 27

3.1 Materiais ... 27

3.2 Plugins para Eclipse ... 27

3.2.1 ADT Android... 27

3.2.2 MyFaces 2.1 ... 28

3.3 Phonegap ... 28

3.5 Aparelho SmartPhone com Android 2.3.7 ... 32

3.6 Métodos ... 34

3.6.1 PhoneGap ... 34

3.6.2 Google Maps ... 35

3.7 Considerações sobre o capítulo ... 37

4 Proposta ... 38

4.1 Visão geral ... 38

4.2 Diagramas ... 39

4.2.1 Diagramas de Casos de uso ... 39

4.2.2 Diagramas de atividades ... 40

4.3 Modelagem do banco de dados ... 41

4.3.1 Modelagem do lado cliente ... 42

4.3.2 Modelagem do lado servidor ... 43

4.4 Considerações sobre o capítulo ... 44

5 Resultado experimental ... 45

5.1 Servidor ... 45

5.1.1 Estrutura dos pacotes e pastas ... 45

5.1.2 Aplicação ... 46

5.1.3 API Rest ... 50

5.2 Cliente mobile ... 51

5.2.1 Estrutura ... 51

5.2.2 Aplicação ... 51

5.3 Considerações sobre o capítulo ... 55

6 Conclusões e trabalhos futuros... 56

6.1 Trabalhos futuros ... 56

7 Cronograma ... 57

1 Introdução

À medida que a sociedade evolui, a criminalidade também avança sobre todos os segmentos e camadas da população, com isso a busca por empresas privadas de monitoramento e vigilância para fazer a segurança tanto de residências quanto de empresas também aumenta, porém a segurança privada não é acessível a todos, pois possui um custo elevado. Boa parte deste custo deve-se as tecnologias utiliza-das.

Atualmente a vigilância é feita através da utilização de pontos magnéticos nos locais a serem monitorados, onde um vigilante fica responsável por verificar periodi-camente estes locais e utilizar um bastão eletrônico para registrar sua ronda.

Este trabalho apresenta uma proposta alternativa e mais acessível para o sis-tema de rondas vigente através de um software para dispositivos móveis. No mode-lo previsto, o vigilante só precisará ter o dispositivo móvel conectado à internet e com GPS ativo para registrar a ronda de acordo com sua posição geográfica, tendo também opções de tirar fotografias e enviar para a central de monitoramento.

Para utilizar a solução, o dispositivo móvel deve possuir um dos sistemas operacionais suportados – Inicialmente o Android da Google, além de GPS e de al-gum tipo de conexão constante com a Internet, sem a necessidade de grande velo-cidade.

1.1 Objetivos

Criar uma solução alternativa ao sistema de rondas atual propondo um aplicati-vo para dispositiaplicati-vos móveis que utilizará a internet e o GPS do mesmo para indicar os locais que deverão ser realizadas às rondas. Inicialmente será utilizando o fra-mework Phonegap, funcionando em cima do sistema operacional Android (Google) e comunicando com um WebService utilizando a tecnologia Restful desenvolvida utilizando linguagem Java.

1.1.1 Objetivo geral

Desenvolver um sistema utilizando o framework Phonegap rodando na plata-forma Android juntamente com um WebService utilizando ambiente Restful para tro-ca de informações no modelo cliente-servidor. O sistema móvel será orientado pelo GPS1 e utilizará a rede 3G2, GPRS3 ou WIFI4 para conectar-se a internet e possibili-tar a troca de informações com o servidor sobre os pontos de localização no mapa a serem checados, como também os dados das rondas. Para visualizar os mapas, se-rá utilizada a API do Google maps, principalmente por ser robusta e livre. A cada ponto visitado, o dispositivo móvel deve registrar e tentar comunicar o sucesso ao servidor utilizando a internet. No caso de algum problema com o GPS, o vigilante deve reportar ao aplicativo que chegou ao ponto, caso exista algum problema para enviar os dados para servidor, o aplicativo tentará reenviar os dados periodicamen-te.

1.1.2 Objetivo específico

 Desenvolver uma solução mobile (aplicativo) em cima do framework

Pho-negap (APACHE), utilizando o sistema operacional Android (Google)

 Desenvolver um Web Service utilizando a linguagem JAVA Web, utilizan-do o serviutilizan-dor de aplicações TOMCAT (APACHE) e o framework Spring Restful.

1

Termo em inglês para Global Positioning System (sistema de posicionamento global)

2

Significa terceira geração de padrões e tecnologias de telefonia móvel

3

Significa serviço de rádio de pacote geral que aumenta a taxa de transferência de rede GSM

4

1.2 Justificativa

Considerando a constante evolução da tecnologia e dispositivos móveis cada vez mais acessíveis, além de conversas com pessoas que trabalham com sistemas de segurança privada, pode ser constatado que o sistema de rondas utilizado atu-almente por empresas de monitoramento é um sistema de alto custo, tornando ne-cessário um considerável investimento para garantir a segurança. Dessa forma, mui-tas pessoas ficam sem opção para garantir a segurança sob um tipo de vigilância constante. Analisando esse problema, surgiu à ideia de criar um sistema de rondas alternativo utilizando dispositivos móveis (smartphones), com o intuito de reduzir os custos e melhorar o controle sobre os vigilantes, possibilitando saber o local em que ele se encontra em determinado horário, quais rotas ele está fazendo, podendo aperfeiçoar o tempo das rondas, por exemplo, indicar a melhor rota para chegar ao seu destino.

1.3 Escopo do trabalho

Propor um modelo de segurança adequado para o segmento móvel utilizando

Web Services. Para que o desenvolvimento do trabalho seja viável considerando os

recursos de tempo e esforço disponíveis, as seguintes escolhas foram realizadas:

 A necessidade de uma alternativa para o sistema de rondas tornar-se um sis-tema completo necessita de uma interface web completa, sissis-tema para dis-positivos móveis para várias plataformas. O escopo se limitará a desenvolver um sistema móvel para dispositivos Android e um webservice sem interface completa. Somente o básico para o correto funcionamento da solução, ou se-ja, somente os cadastros realmente necessários, e a parte de troca de dados com o dispositivo móvel será implementado.

 O protótipo será desenvolvido para dispositivos baseados no sistema opera-cional Google Android, utilizando o framework PhoneGap desenvolvido pela ADOBE e de código livre, que juntos oferecem o ambiente ideal tanto no

as-pecto de desempenho quanto de produtividade no desenvolvimento de apli-cações.

 Dentre as abordagens existentes no desenvolvimento de Web Services, se-rão abordadas duas opções, o ambiente SOAP com o framework Axis2 e o padrão REST com o framework Spring Restful. Após a comparação será utili-zado o ambiente REST, pois torna o desenvolvimento mais simples e ágil.

1.4 Estrutura do trabalho

Este trabalho é composto por 6 capítulos, o capítulo 1 contém a introdução do trabalho, escopo e justificativas. O capítulo 2 é composto por toda a parte de ambi-ente e ferramentas. Terceiro capítulo informa o que foi necessário para o desenvol-vimento da solução proposta juntamente com os métodos utilizados. Capítulo 4 con-tém os diagramas utilizados. Quinto capítulo é sobre os resultados obtidos da solu-ção proposta. Por último sexto capítulo possuí conclusão e trabalhos futuros.

2 Ambiente e ferramentas

Considerando a natureza complexa de desenvolvimento envolvendo dispositivos móveis, este capítulo apresentará conceitos estritamente necessários para viabilizar o processo de desenvolvimento e análise experimental do problema apresentado. Em algumas seções será possível justificar algumas das escolhas associadas às tecnologias e arquiteturas utilizadas nas etapas de desenvolvimento.

2.1 Sistema atual de rondas

O sistema de rondas utilizado atualmente (pontos e bastões) consiste em traçar uma rota que o vigilante deve seguir, ou seja, são definidos locais a serem vistoria-dos periodicamente, então pontos eletrônicos (figura 1) são fixavistoria-dos nestes locais, e posteriormente o vigilante necessita aproximar seu bastão ao ponto fixo para regis-trar sua ronda, considerando o tempo para fixar um ponto na parede, torna inviável uma troca rápida de locais a serem vistoriados.

Os pontos eletrônicos de rondas devem ser previamente instalados nos locais escolhidos para os vigilantes realizarem a checagem. O vigilante por sua vez, possui um bastão, como mostra a figura 2:

Figura 2 - Bastão de ronda

Esse bastão, deve entrar em contato com o ponto de ronda para que seja regis-trado a hora, o local e a posição do GPS onde o vigilante está no momento. A maio-ria dos bastões necessita deste contato, outros somente a aproximação é suficiente, por possuírem um sistema de sinal via rádio para o reconhecimento do bastão pró-ximo ao ponto.

A função deste bastão é registrar o nome do ponto de ronda lido, a data e hora da leitura juntamente com a posição geográfica utilizando o GPS, sendo que cada bastão está associado a um vigilante no sistema geral. Posteriormente as informa-ções armazenadas podem ser descarregadas em um computador através do qual é possível gerar relatórios e informações em geral.

Estes bastões possuem um custo elevado, que se justifica pela tecnologia neles aplicada, como o GPS.

2.2 IDEs para desenvolvimento

2.2.1 Eclipse

Eclipse é um IDE desenvolvido em Java, seguindo o modelo open

sour-ce de desenvolvimento de software. O projeto Eclipse foi iniciado na IBM que

de-senvolveu a primeira versão do produto e doou-o como software livre para a comu-nidade. O gasto inicial da IBM no produto foi de mais de 40 milhões de dólares. Ho-je, o Eclipse é o IDE Java mais utilizado no mundo. Possui como características marcantes o uso da SWT e não do Swing como biblioteca gráfica, a forte orientação ao desenvolvimento baseado em plug-ins e o amplo suporte ao desenvolvedor com

centenas de plug-ins que procuram atender as diferentes necessidades de diferen-tes programadores.

O uso de plugins, pode ser usado não só para desenvolver em Java, mas também em C/C++, PHP, ColdFusion, Python, HTML5, JavaScript.

2.2.1.1 Android Development Tools (ADT)

Android Development Tools (ADT) é um plugin para o Eclipse IDE que é

proje-tado para fornecer um ambiente poderoso, integrado, para criação de aplicativos Android.

O ADT amplia os recursos do Eclipse para possibilitar a criação de projetos An-droid, criar interface de aplicativo, adicionar pacotes baseados no Android Fra-mework API, depurar seus aplicativos usando as ferramentas do Android SDK, e até mesmo exportar arquivos .Apk (formato de pacote de arquivos Android para distri-buição) assinados (ou não assinado) a fim de distribuir a sua aplicação.

Desenvolver no Eclipse com ADT é altamente recomendado, é o caminho mais rápido para começar. Com a configuração do projeto guiada proporciona, além de ferramentas de integração, os editores XML personalizados, e painel de saída de depuração.

2.2.2 MySQL WorkBench

MySQL Workbench simplifica o projeto de banco de dados e manutenção, au-tomatiza as tarefas demoradas e propensas a erros e melhora a comunicação entre DBA e equipes de desenvolvedores. Ele permite que os arquitetos de dados possam visualizar os requisitos, comunicar-se com as partes interessadas, e resolver ques-tões de design antes de um grande investimento de tempo e recursos a ser feita. Ele permite fazer a modelagem do banco, que é a metodologia mais eficiente para a criação de bases de dados válidos e com bom desempenho, oferecendo a flexibili-dade para responder à evolução das exigências do negócio. Utilitários para valida-ção de modelagens e cumprir as melhores práticas para a modelagem de dados,

também para MySQL e impor normas específicas de design físico por isso não se-jam cometidos erros ao construir novos diagramas ER ou gerar bases de dados MySQL físicas.

MySQL Workbench fornece capacidades de engenharia para a frente de proje-tos de banco de dados físicos. Um modelo de dados visual pode ser facilmente transformado em um banco de dados físico em um servidor alvo MySQL com ape-nas alguns cliques do mouse. Todo o código SQL é gerado automaticamente; o que elimina o processo sujeito a erros normais ao manualmente escrever código SQL complexa. MySQL Workbench também permite a engenharia reversa de um banco de dados existente ou aplicativo de pacote para obter uma melhor visão sobre o pro-jeto de banco de dados. Não só pode fazer engenharia reversa de bancos de dados existentes, mas também pode importar scripts SQL para construir modelos e expor-tar modelos para scripts DDL que podem ser executados em um momento posterior.

2.3 Tecnologias para desenvolvimento

2.3.1 Sistema operacional Android

Liderado pela Google, o Android inclui um sistema operacional baseado em núcleo Linux, além de ferramentas e aplicações voltadas para funções usualmente embarcadas em dispositivos móveis. Através da máquina virtual Dalvik, o sistema executa aplicações escritas em Java. No entanto, esse ambiente apenas usa a sin-taxe Java, não sendo propriamente uma máquina virtual Java. Dessa forma, não se pode dizer que a plataforma é compatível com qualquer padrão Java estabelecido pela Sun Microsystems, como Java ME ou SE. Também é possível escrever biblio-tecas em C e outras linguagens que possam ser compiladas para código nativo ARM e instaladas utilizando o kit de desenvolvimento para Android. Na Figura 3 po-de ser observada a interface do sistema na versão atual 4.0 Ice Cream Sandwich.

Figura 3 - Sistema operacional Android 4.0

2.3.2 JQuery Mobile

JQuery é uma biblioteca JavaScript cross-browser desenvolvida para simplifi-car os scripts do lado cliente que interagem com o HTML. Ela foi lançada em janeiro de 2006 no BarCamp de Nova York por John Resig. Usada por cerca de 55% dos 10 mil sites mais visitados do mundo, jQuery é a mais popular das bibliotecas Ja-vaScript.

jQuery é uma biblioteca de código aberto e possui licença dual, fazendo uso da Licença MIT ou da GNU General Public License versão 2. A sintaxe do jQuery foi desenvolvida para tornar mais simples a navegação do documento HTML, a seleção de elementos DOM, criar animações, manipular eventos e desenvolver aplicações AJAX. A biblioteca também oferece a possibilidade de criação de plugins sobre ela. Fazendo uso de tais facilidades, os desenvolvedores podem criar camadas

de abstração para interações de mais baixo nível, simplificando o desenvolvimento de aplicações web dinâmicas de grande complexidade.

A Microsoft e a Nokia anunciaram planos de incluir o jQuery em suas plata-formas, a Microsoft adotando-a inicialmente no Visual Studio para uso com o fra-mework AJAX do ASP.NET, e a Nokia na sua plataforma Web Run-Time de wid-gets. A biblioteca jQuery também tem sido usada no MediaWiki desde a versão 1.16.

JQuery mobile é um sistema de interface unificada, baseada em HTML5, Uti-lizada para todas as plataformas populares dispositivos móveis, construída sobre a rocha sólida jQuery e jQuery UI fundação. Seu código é construído com leve valori-zação progressiva, e tem um design flexível e facilmente personalizável.

2.3.3 Framework PhoneGap

O Phonegap é um framework que provê que um código HTML5 acesse as api’s nativas do dispositivo móvel, possibilitando gerar aplicações para serem dispo-nibilizadas em suas respectivas lojas, como Apple Store e Android Market.

Recentemente, a Adobe comprou a empresa chamada Nitobi, responsável pelo Phonegap. Ainda, apontou o HTML5 como sendo a melhor tecnologia para o futuro e deixou o Flex um pouco de lado.

O Phonegap está disponível para 7 plataformas, entre elas Android e IOS. Com ele, temos acesso a itens como câmera, GPS, contatos, SQLite (banco de da-dos), entre outros.

Ele ainda é baseado em plugins. Logo, se o desenvolvedor precisar de algo que ele não implementa, é possível desenvolver a parte e integrar com o Phonegap. Um desses plug-ins é o jQuery mobile e será descrito.

2.3.4 WebService

Webservice é uma solução utilizada na integração de sistemas e na comuni-cação entre aplicações diferentes. Com esta tecnologia é possível que novas

aplica-ções possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em vários formatos como XML e JSON.

Para as empresas, Webservice podem trazer agilidade para os processos e eficiência na comunicação entre cadeias de produção ou de logística. Toda e qual-quer comunicação entre sistemas passa a ser dinâmica e principalmente segura, pois não há intervenção humana.

Essencialmente, Web Service faz com que os recursos da aplicação do sof-tware estejam disponíveis sobre a rede de uma forma normalizada. Outras tecnolo-gias fazem a mesma coisa, como por exemplo, os browsers da Internet acedem às páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estas tecnologias não são bem sucedidas na comunicação e in-tegração de aplicações. Existe uma grande motivação sobre a tecnologia Web Ser-vice pois possibilita que diferentes aplicações comuniquem entre si e utilizem recur-sos diferentes.

Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qual-quer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Servi-ce.

Os Web Services podem ser identificados por um URI (Uniform Resource Identifier), descritos e definidos usando XML (Extensible Markup Language). Um dos motivos que tornam os Web Services atrativos é o facto deste modelo ser baseado em tecnologias standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services são utilizados para disponibilizar serviços interativos na Web, po-dendo ser acessados por outras aplicações usando, por exemplo, o protoco-lo SOAP (Simple Object Access Protocol).

O objetivo dos Web Services é a comunicação de aplicações através da In-ternet. Esta comunicação é realizada com intuito de facilitar a EAI (Enterprise

Appli-cation Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a informação que circula numa organização nas dife-rentes aplicações como, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui o sistema de informação de uma empre-sa. E para além da interoperabilidade entre as aplicações, a EAI permite definir um workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com um workflow é possível otimizar e controlar processos e tarefas de uma determinada organização.

2.3.4.1 SOAP

O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse com-ponente. Não define ou impõe qualquer semântica, quer seja o modelo de progra-mação, quer seja a semântica específica da implementação. Este aspecto é extre-mamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programa-ção. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP. Desta forma, pre-tende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou ou-tro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.

Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de seguran-ça/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, atra-vés da resposta do HTTP. Para assegurar correctamente a transmissão da

mensa-gem de XML, o servidor de HTTP, tais como Apache ou IIS (Microsoft Internet In-formation Server), recebe mensagens SOAP e deve validar e compreender o forma-to do documenforma-to XML definido na especificação SOAP v1.1.

2.3.4.2 Axis2

O Apache Axis é um framework de código aberto, baseado na linguagem Ja-va e no padrão XML, utilizado para construção de web services no padrão SOAP. Através do Axis os desenvolvedores podem criar aplicações distribuídas. Além da versão para Java, existe uma implementação baseada na linguagem C++. O projeto Apache Axis é suportado pela Apache Software Foundation.

O Axis disponibiliza dois modos para "expor" os métodos de uma classe através de web services. O modo mais simples utiliza os arquivos JWS (Java Web Service) do Axis. O outro método utiliza um arquivo WSDD (Web Service Deployment Descriptor), que descreve com detalhes como serão criados os web

services a partir dos recursos (classes Java) existentes.

Também é possível, através do Axis, gerar automaticamente o arqui-vo WSDL (Web Service Description Language). O WSDL contém a definição da interface dos web services.

2.3.4.3 Ambiente Restful

“A REST (Transferência do Estado Representacional) é pretendida como uma imagem do design da aplicação se comportará: uma rede de websites (um estado virtual), onde o usuário progride com uma aplicação selecionando as ligações (tran-sições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao usuário e apresentada para seu uso.” (Fielding)

O termo REST se referia, originalmente, a um conjunto de princípios de arquite-tura, na atualidade se usa no sentido mais amplo para descrever qualquer interface web simples que utiliza XML e HTTP (JSON, ou texto puro), sem as abstrações adi-cionais dos protocolos baseados em padrões de trocas de mensagem como o pro-tocolo de serviços web SOAP. É possível desenhar sistemas de serviços web de acordo com o estilo arquitetural REST descrito por Fielding, e também é possível

desenhar interfaces XMLHTTP de acordo com o estilo de RPC, mas sem utilizar SOAP.

Os sistemas que seguem os princípios REST são frequentemente chamados de RESTful.

REST afirma que a web já desfrutou de escalabilidade como resultado de uma série de desenhos fundamentais:

Um protocolo cliente/servidor sem estado: cada mensagem HTTP contém toda a informação necessária para compreender o pedido. Como resultado, nem o cliente e nem o servidor necessitam gravar nenhum estado das comunicações entre mensa-gens. Na prática, muitas aplicações baseadas em HTTP utilizam cookies e outros mecanismos para manter o estado da sessão (algumas destas práticas, como a re-escrita de URLs, não são permitidas pela regra do REST).

Um conjunto de operações bem definidas que se aplicam a todos os recursos de informação: HTTP em si define um pequeno conjunto de operações, as mais impor-tantes são POST, GET, PUT e DELETE. Com frequência estas operações são combinadas com operações CRUD para a persistência de dados, onde POST não se encaixa exatamente neste esquema.

Uma sintaxe universal para identificar os recursos. No sistema REST, cada re-curso é unicamente direcionado através da sua URI.

O uso de hipermídia, tanto para a informação da aplicação como para as transi-ções de estado da aplicação: a representação deste estado em um sistema REST são tipicamente HTML ou XML. Como resultado disto, é possível navegar com um recurso REST a muitos outros, simplesmente seguindo ligações sem requerer o uso de registros ou outra infraestrutura adicional.

Cada recurso teria seu próprio identificador, como

http://www.example.org/locations/us/ny/new_york_city. Os clientes trabalhariam com estes recursos através das operações padrão de HTTP, como o GET para chamar uma cópia do recurso. Observa-se como cada objeto tem sua própria URL e pode ser facilmente cacheado, copiado e guardado como marcador. POST se utiliza ge-ralmente para ações com efeitos laterais, como enviar uma ordem de compra.

2.3.5 Servidores

2.3.5.1 Servidor de aplicações TOMCAT

O Tomcat é um servidor web Java, mais especificamente, um container de

servlets. Também é um servidor de aplicações JEE, porém não é um servidor de

EJBs. Desenvolvido pela Apache Software Foundation, é distribuído como software livre dentro do conceituado projeto Apache Jakarta, sendo oficialmente endossado pela Sun como a implementação de referência para as tecnologias Java Ser-vlet e JavaServer Pages (JSP). Ele cobre parte da especificação J2EE com tecnolo-gias como servlet e JSP, e tecnolotecnolo-gias de apoio relacionadas como Realms e segu-rança, JNDIResources e JDBC DataSources.

Ele tem a capacidade de atuar também como servidor web, ou pode funcionar integrado a um servidor web dedicado como o Apache ou o IIS. Como servidor web, ele provê um servidor web HTTP puramente em Java.

O servidor inclui ferramentas para configuração e gerenciamento, o que também pode ser feito editando-se manualmente arquivos de configuração formatados em XML.

2.3.6 Bancos de dados

2.3.6.1 MySQL

O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured

Query Language) como interface. É atualmente um dos bancos de dados mais

po-pulares, com mais de 10 milhões de instalações pelo mundo.

Entre os usuários do banco de dados MySQL estão: NASA, Friendster, Banco Bra-desco, Dataprev, HP, Nokia, Sony, Lufthansa, U.S. Army, U.S. Federal Reserve Bank, Associated Press, Alcatel, Slashdot, Cisco Systems, Google e outros.

2.3.6.2 SQLite

SQLite é uma biblioteca em linguagem C que implementa um banco de da-dos SQL embutido. Programas que usam a biblioteca SQLite podem ter acesso a bancos de dados SQL sem executar um processo SGBD separado.

SQLite não é uma biblioteca cliente usada para conectar com um grande ser-vidor de banco de dados, mas sim o próprio serser-vidor. A biblioteca SQLite lê e escre-ve diretamente para e do arquivo do banco de dados no disco.

2.3.7 Google Maps

Google Maps é um serviço de pesquisa e visualização de mapas e imagens de satélite da Terra gratuito na web, fornecido e desenvolvido pela empre-sa estadunidense Google.

Atualmente, o serviço disponibiliza mapas e rotas para qualquer ponto nos Estados Unidos, Canadá, na União Europeia, Austrália e Brasil, entre outros. Disponibilizar também imagens de satélite do mundo todo, com possibilidade de

zo-om nas grandes cidades, czo-omo Nova Iorque, Paris, São Paulo, Rio de

Janei-ro, Brasília, entre outras.

Juntamente com o lançamento da versão brasileira do Google Maps, a em-presa introduziu o Local Business Center, ferramenta que permite com que qualquer

empresa faça seu cadastro e seja então encontrada no Google Maps por qualquer usuário. No cadastro, as empresas podem preencher seus dados cadastrais, horário de atendimento, formas de pagamento, logotipo e fotos, sendo necessária confirma-ção do cadastro através de uma ligaconfirma-ção telefônica, SMS ou carta.

Com uma conta Google, já é possível destacar as suas próprias rotas, pontos e áreas, gerar comentários e compartilhar os respectivos links de acesso ao mapa criado. Também é possível gerar um arquivo KML para integração com o Google Earth.

2.3.8 JSF - Java Server Faces

JavaServer Faces (JSF) é um framework MVC de aplicações Web baseado em Java destinado a simplificar o desenvolvimento de interfaces de usuário baseadas em web.

O Java Server Faces ganhou expressão na versão 1.1 quando implementado pela comunidade utilizando a especificação 127 do Java Community Process, evi-denciando maturidade e segurança.

Hoje ele está na versão 2.1 da especificação 252 do JCP. A funda-ção Apache vem realizando esforços na implementafunda-ção da especificafunda-ção através do projeto MyFaces. O reconhecimento do trabalho é visto por diversas empresas, tan-to é que a Oracle doou os fontes do ADF Faces, conjuntan-to de mais de 100 compo-nentes JSF, para o projeto MyFaces que o denominará de Trinidad.

O JSF é atualmente considerado pela comunidade Java como a última palavra em termos de desenvolvimento de aplicações Web utilizando Java, resultado da ex-periência e maturidade adquiridas com o JSP/Servlet, Model2 e Struts.

2.3.8.1 Primefaces

PrimeFaces é uma suite de componentes JSF customizados, a maioria com su-porte a ajax, conta com um Kit para desenvolvimento mobile, é open source, a do-cumentação é razoável, fácil de instalar e usar.

Conta com mais de 100 compontentes completos e de fácil implementação. Uma grande vantagem do Primefaces é que seus componentes utilizam Ajax nativo do JSF. Serve para criar páginas WEB para ambiente Java SE.

2.4 Considerações sobre o capítulo

Neste capítulo foi apresentado o embasamento teórico das ferramentas e tecno-logias utilizadas para possibilitar o desenvolvimento deste trabalho.

3 Aspectos ambiente experimental

Conforme os objetivos e o escopo estabelecidos para este trabalho, se faz necessário a construção de um cenário que ofereça requisitos para desenvolvimento de um protótipo. Sendo que neste capítulo o objetivo é demonstrar os métodos, tec-nologias e ferramentas utilizadas nas etapas de desenvolvimento e comprovação de resultados.

3.1 Materiais

Este capítulo trata das ferramentas que serão utilizadas como suporte para o desenvolvimento da solução proposta após ter sido feito um estudo abrangente das tecnologias existentes possíveis de serem utilizadas, sendo a escolha feita por te-rem sido eleitas as ferramentas mencionadas como as mais adequadas para este projeto.

3.2 Plugins para Eclipse

Será utilizado a IDE de desenvolvimento Eclipse devido principalmente as suas vantagens, entre elas ser uma ferramenta livre e de código aberto, consequente-mente a grande comunidade de programadores ajuda constanteconsequente-mente a melhorar essa ferramenta, além de desenvolver novos plug-ins.

3.2.1 ADT Android

Para programar para android e fundamental ter o auxilio de uma IDE, para isso é necessária a instalação do plugin ADT Android da Google, que possibilita a cria-ção, validacria-ção, testes e edição das diversas classes e arquivos XML, tanto de confi-guração quanto para interface. Esse plugin será usado basicamente para configurar os arquivos necessários para aplicações android e para usar o emulador que ele fornece.

3.2.2 MyFaces 2.1

O projeto Apache MyFaces, ou simplesmente MyFaces, é um framework para o desenvolvimento de aplicações para Web. Ele é baseado no paradigma MVC e foi criado para suportar o padrão Java Server Faces (JSR 127).

Java Server Faces (JSF) é um framework para desenvolvimento web seguindo as especificações JSR252 e JSR171 baseado no padrão de projeto MVC.

O projeto MyFaces da Apache Software Foundation inclui uma implementação do JSF ("MyFaces Core") e um conjunto de bibliotecas para trabalharem juntos com esse framework.

A família do MyFaces inclui as seguintes bibliotecas para complementar com ca-racterísticas extras e flexibilidade.

 Tomahawk  Trinindad  Tobago  Orchestra  Portlet Bridge

3.3 Phonegap

Como dito anteriormente o phonegap é um framework permite que por meio de Javascript, seja possível acessar apis nativas do dispositivo, ou seja, escreve-se somente um código fonte e pode-se compilar para diversas plataformas o mesmo código acessando as mesmas apis, entre elas Android e IOS. O phonegap prove acesso aos principais recursos do aparelho. Entre os diversos métodos, será utiliza-do:

Câmera – Para possibilitar a captura de imagens.

GPS – Para obter a localização do vigilante principalmente para calcular a rota. Conexão com a internet(WIFI, GPRS, 3G) – Para atualizar e mostrar os mapas e as rotas.

3.4 Utilização JQuery

JQuery mobile facilita a construção de interfaces por possuir muitos componen-tes prontos e ainda fornece uma interface para construção do seu próprio tema co-mo co-mostra a figura 4.

Figura 4 - Theme Roll para o JQuery mobile

Como o Phonegap provê que a aplicação para android seja desenvolvido em cima de HTML5 e JavaScript, isso possibilita o uso do JQuery e JQuery mobile, por tratar-se de um framework baseado em JavaScript. Logo devemos criar uma página HTML e na tag <HEADER>, devemos importar os scripts necessários, como mostra a figura 5.

Figura 5 - Estrutura da tag Header do JQuery e Phonegap.

Para a estrutura do corpo da página deve-se seguir algumas regras, como mos-tra a figura 6.

Figura 6 - Estrutura do corpo da página com JQuery.

Como visto na figura 6, cada página corresponde a tag <div data-role=”page”>, que podemos utilizar a propriedade id do html para dar um nome único a ela, dessa forma ficaria <div data-role=”page” id=”pagina1”></div>, utilizar esta propriedade id se vê necessária, pois podemos ter várias páginas do JQuery em um mesmo docu-mento, como mostra a figura 7.

Figura 7 - Página JQuery com 2 páginas no mesmo documento.

Como observado na figura 7, existem 2 páginas diferentes no mesmo documen-to, para reconhecer a página utilizamos a propriedade id, como dito anteriormente, na figura 7 é possível observar outro detalhe, que é como trocamos de páginas que estão em um mesmo documento, no div contente da página 1 temos um link que no seu href (propriedade que indica a página que deve abrir ao ser clicado no link), te-mos “#pagina2”, que é a forma de dizer que querete-mos trocar para a página 2 do mesmo documento. Neste caso após o “#” colocamos o id da página que será aber-ta.

JQuery age no documento HTML também, mas seus principais recursos de-vem ser utilizados na parte de scripts da página. Normalmente criamos um arquivo separado para tal. A estrutura de um script que utiliza jQuery tem a identidade iden-tidade mostrada na figura 8.

Figura 8 - Estrutura de um script que utiliza jQuery.

Na figura 8, observa-se como iniciar o jquery e dois exemplos de eventos dispa-rados quando a página de id=pagina1 carregar e quando o componente com id=logar for clicado. Logo no corpo da função escreve-se os métodos.

3.5 Aparelho SmartPhone com Android 2.3.7

Para efeito de testes, será necessário um aparelho Smartphone com sistema Android, inicialmente será utilizado o modelo Sony Xperia U, como mostra a figura 9.

Este aparelho possui todos os recursos necessários para este trabalho. Sendo estes:  Câmera de 5.0 MP  WIFI  2G, 3G  GPRS  GPS  Acelerômetro

3.6 Métodos

Capítulo que mostra como utilizar algumas das tecnologias utilizadas na aplica-ção que podem ser de utilidade.

3.6.1 PhoneGap

Figura 10 é um exemplo de código para utilizar a API do dispositivo móvel.

Figura 10 - Código em JavaScript para obter imagem da câmera.

Como é mostrado na figura 10, o código para se obter uma imagem retirado pela câmera, consiste em uma função javaScript, é chamado a função naviga-tor.camera.getPicture, essa função é nativa do Phonegap, ela recebe como parâme-tro o onSucess e o onFail, essas duas são funções de call-back, no caso de suces-so ele executa o onSucess e no casuces-so de algum erro ele retorna no onFail.

Todas as funções para acessar a api nativa do dispositivo móvel, segue essa mesma idéia. Utiliza-se o navigator em seguida o tipo de api que deseja ser utiliza-da, temos as seguintes apis:

 navigator.Accelerometer

o Captura os movimentos do dispositivo nas direções x,y e z.  navigator.camera

o Captura imagens pela câmera do aparelho.  Device.capture

o Fornece acesso para captura e áudio, imagens e vídeos.  navigator.compass

o Obtém a direção para qual o dispositivo está apontando.  navigator.Network.connection_type

o Retorna o tipo de conexão com a internet que o dispositivo esta uti-lizando.

 navigator.contacts

o Acessa a base de dados de contatos do aparelho.  Device

o Fornece informações sobre o hardware e software do dispositivo.  navigator.geolocation

o Prove acesso as informações fornecidas pelo GPS do dispositivo.  media

o Permite gravar e reproduzir arquivos de áudio do dispositivo.  navigator.notification

o Permite criar notificações visuais, tátil e audível no aparelho.  window.openDatabase

o Prove acesso à base de dados do software.

3.6.2 Google Maps

Google maps é uma api completa quando se tratando de mapas, localização geográfica, rotas entre outros assuntos relacionados.

Figura 11 - Inicializando google maps

Na figura 11, é possível simplificadamente, analisar como se inicializa o objeto map do google maps. Basicamente deve-se realizar os seguintes passos:

 Importar o script do google maps.

 Definir as propriedades e opções que o mapa conterá.  Definir uma tag (div) que será o mapa

 Inicializar o objeto do mapa como mostrado na figura 11.

Para criar um marcador utilizando a api do google maps, deve-se utilizando o método ilustrado na figura 12, onde é criado um objeto marker que deve receber o objeto mapa já instanciado, juntamente com a posição geográfica que deve conter o marcador.

A figura 13, ilustra a função para criar um circulo em torno de um ponto geográ-fico, este chamado de “center” e deve ser informado juntamente com o objeto mapa da aplicação no momento da criação do círculo. Outra informação essencial é o “ra-dius”, que indica quantos metros deve ter o raio do circulo.

Figura 13 - criando circulo

3.7 Considerações sobre o capítulo

Este capítulo apresentou os frameworks utilizados e como foram utilizados nesta tese, além de alguns exemplos para melhorar o entendimento.

4 Proposta

Este capítulo apresenta uma visão geral da soluçao além de diagramas seguin-do a especificação UML5 e modelagens relacionais de bancos de dados para a so-lução proposta.

4.1 Visão geral

Figura 14 - Visão geral da solução

A imagem 14 ilustra bem de modo geral como deve funcionar o sistema, a nu-vem representa o WebServer responsável para receber as requisições dos App cli-entes reprensetados pelas pessoas na imagem. O app deve estar em constante in-teração com o Webserver para que remotamente seja possível manter o controle e melhorar o planejamento das rotas para as rondas.

5

4.2 Diagramas

Esta seção apresenta diagramas utilizando a notação padrão de UML para facili-tar o entendimento da solução.

4.2.1 Diagramas de Casos de uso

A figura 15 representa o diagrama de casos de uso da aplicação, tendo 3 atores:  atorClienteMobile – Representa o cliente da aplicação, neste caso, um

dispositivo mobile com o sistema de rondas instalado.

 atorServidor – Representa o servidor de aplicações para trocar informa-ções com o atorCliente (aplicação cliente).

 atorGoogle – Representa basicamente a api do google maps disponibili-zada pela google e usada no cliente mobile em todas as partes que en-volvem mapas.

Em seguida existem 3 casos de uso:

 CarregarMapa – Este item está entre o atorClienteMobile e o atorGoogle, é o ato do cliente requisitar todas as informações necessárias relaciona-das com mapas, como também a manipulação do mesmo.

 ReceberDadosServidor – atorServidor envia vários tipos de dados para o cliente, dados estes como dados da ronda diária.

 EnviarDadosServidor – atorCliente envia para o servidor alguns dados chave, tal como informar que um ponto foi vistoriado com sucesso.

Figura 15 - Diagrama de Casos de uso.

4.2.2 Diagramas de atividades

Figura 16 - Diagrama de atividades - carregar dados do servidor

Na figura 16 temos o diagrama de atividades que representa o caso de uso Re-ceberDados representado na figura 15. Este diagrama inicia no círculo preto que re-presenta o atorClienteMobile fazendo a requisição para obter um conjunto de dados

do servidor onde este conjunto poderia ser os pontos que deverão ser checados no dia. O segundo passo é identificar o usuário de acordo com email e senha. Caso não reconheça, retorna erro, caso reconheça processa a requisição e retorna o con-junto de dados para o cliente.

Figura 17 mostra como funciona o envio de dados do atorClienteMobile para o servidor. O processo inicia no círculo preto que representa o cliente tentando cone-xão com o servidor para envio dos dados. Quando o servidor recebe a requisição ele tenta identificar o usuário e caso não reconheça, retorna erro informando o tipo de erro ocorrido. Caso contrario tenta ler os dados e gravar na base de dados, qualquer erro neste processo é retornado um erro para o cliente.

Figura 17 - Diagrama de atividades - enviar dados para o servidor

4.3 Modelagem do banco de dados

Este capítulo contem as modelagens realizadas para implementar a parte de banco de dados no cliente e no WebService. Para isso foi utilizada a ferramenta Mysql WorkBench citada anteriormente no capítulo 2.

4.3.1 Modelagem do lado cliente

A figura 18 representa a modelagem do banco de dados que foi utilizada na par-te clienpar-te da solução. Exispar-tem as seguinpar-tes tabelas:

 Vigilante - conterá as informações dos vigilantes que estão usando o aplicativo apenas, só existirão os vigilantes que utilizaram pelo menos uma vez o sistema pelo cliente.

 Cliente - contem somente o id do cliente (mesmo utilizado no servidor) e o nome do cliente qual será efetuado a ronda.

 Evento – Representa uma tabela simplesmente para log de eventos que ocorrem na aplicação.

 Ponto_ronda – Principal tabela da aplicação cliente contém todos os da-dos referentes às rondas que o vigilante já executou e ainda tem por exe-cutar no presente dia. Sempre é mantido histórico das rondas já efetua-das até o envio com sucesso para o servidor, logo após o ponto enviado é apagado.

4.3.2 Modelagem do lado servidor

Figura 19 - Prévia da modelagem do banco de dados do lado servidor.

Figura 19 representa a modela de bancos de dados da parte servidor da aplica-ção e existem as seguintes tabelas:

 Cliente – Contem os dados dos clientes (somente dados básicos) que deverão ser vistoriados pelos vigilantes.

 Endereço – Tabela simples para guardar os endereços dos clientes e vi-gilantes.

 Vigilante – Tabela contendo informações básicas dos vigilantes que irão usar a solução cliente da aplicação.

 Usuário – Contém o email e senha de todos que poderão ter acesso ao sistema, vigilantes devem conter um id_usuario para usar o sistema.

 Ponto_ronda – Representa o local geográfico, latitude e longitude, e o cliente correspondente juntamente com o vigilante responsável para visto-riar aquele local.

 Rota_execucao – Representa os dias e horários que um ponto_ronda deve ser vistoriado, caso seja dois horários diferentes para o mesmo pon-to, deve haver dois registros nesta tabela referenciando o mesmo ponto.  Histórico_pontos_executados – Contem todos os dados do ponto

exe-cutado na aplicação cliente e enviado com sucesso ao servidor. Serve pa-ra ter o histórico e gepa-rar relatórios.

4.4 Considerações sobre o capítulo

Foram apresentados os diagramas e modelagens necessários para um melhor entendimento da solução proposta.

5 Resultado experimental

Neste capítulo será apresentado como se deu o desenvolvimento, tanto do ser-vidor quanto do cliente.

5.1 Servidor

Para o desenvolvimento no servidor fora utilizado um conjunto de tecnologias. Para o desenvolvimento da interface foi utilizado o JSF com o paco MyFaces 2.1, juntamente com o framework PrimeFaces para Web.

5.1.1 Estrutura dos pacotes e pastas

Como mostra a figura 20, as classes desenvolvidas utilizando Java estão dividi-das em pacotes semelhantes ao modelo MVC. No pacote controller ficam as classes controladoras, tanto da API Rest, quanto dos controladores do modelo JSF das pá-ginas do servidor. O pacote model representa as classes modelo, entre elas estão as classes de persistência do banco de dados. O pacote utils contem somente clas-ses com funções genéricas utilizadas em todo o sistema. Já o arquivo hiberna-te.xfg.xml serve para configurar o hibernate com o banco de dados.

A árvore de diretórios representa na figura 21, o diretório WebContent da aplica-ção. Neste diretório fica toda a parte do View (páginas xhtml) e algumas configura-ções e templates 6referentes ao JSF.

Figura 21 - Estrutura do WebContent do projeto

5.1.2 Aplicação

No corrente capitulo serão apresentados mais informações da aplicação servi-dor proposta para a solução.

5.1.2.1 Interface

Na figura 22, pode ser visualizada a tela de login do sistema, sem efetuar o login não é possível realizar nenhuma operação.

6

Figura 22 - Tela de login do ambiente servidor

A Imagem 23 representa a tela de cadastro de clientes, anteriormente menci-onado no escopo do projeto, somente dados representativos são requeridos, utiliza-dos dautiliza-dos primários somente.

A figura 24 representa a tela de cadastro de vigilantes, é semelhante ao ca-dastro de clientes e exige somente dados representativos.

Figura 24 - Tela de cadastro de vigilantes

A figura 25 representa a tela de cadastro de pontos de ronda. Nesse passo devem ser cadastrados os pontos no mapa a serem vistoriados pelo vigilante res-ponsável, já na figura 26 são cadastrados os horários que o vigilante deve vistoriar o local.

Figura 25 - Tela de cadastro de ronda no mapa

Figura 25 representa a tela onde deverão ser selecionados no mapa os pontos a serem vistoriados pelo vigilante, neste passo deve-se selecionar os pontos somente uma vez.

Figura 26 - Tela de cadastro de periocidade de ronda

Figura 26 é a tela onde serão cadastrados os horários e dias que os pontos se-lecionados na tela anterior (figura 25) serão efetuados. No caso deve-se selecionar

um ponto já previamente cadastrado e preencher as informações pedidas na parte inferior da tela como datas, horários e dias que será executado.

5.1.3 API Rest

A aplicação servidora possui uma api em Rest para enviar e receber dados com a aplicação cliente. Essa API fornece alguns serviços, entre eles os principais são:

 Validar usuário e senha

 Retornar as informações para efetuar a ronda diária  Receber os pontos executados pelo cliente

 Receber outras informações do cliente

Como documentado no capítulo 2, o ambiente Rest é basicamente um serviço orientado a links, ou seja, para validar o usuário, por exemplo, é utilizado um link tal como www.enderecoservidor.com.br/rest/usuario/validar. No caso do exemplo de validar um usuário, não é necessário, porém para retornar as informações deseja-das, é preciso enviar no cabeçalho da requisição HTTP o e-mail e senha do vigilan-te, como exemplo, requisitar as rondas do dia.

5.2 Cliente mobile

Nesta seção é apresentada, a estrutura e os recursos que foram utilizados para o desenvolvimento da aplicação.

5.2.1 Estrutura

A figura 27 representa a estrutura de pastas e arquivos do projeto do cliente mobile para android, utilizando aa linguagem JAVA, HTML e JavaScript (JQuery).

A pasta src contém apenas uma classe, que é necessário para iniciar a aplica-ção e é escrita na linguagem JAVA. Todo o funcionamento e telas da aplicaaplica-ção, fo-ram desenvolvidos em HTML e JavaScript. O arquivo html responde pelo nome de index.html, os scripts fica na pasta js e na pasta jquery.mobile. Na pasta css ficam as folhas de estilo da aplicação.

Figura 27 - Estrutura do cliente mobile

5.2.2 Aplicação

Nesta seção será apresentada todas as telas da aplicação cliente juntamente com o funcionamento das principais.

5.2.2.1 Interface da tela de login

Na figura 28, é apresentada a tela de login do sistema, é necessário entrar com e-mail e senha, previamente cadastrados no servidor, da pessoa que irá utilizar o sistema.

O funcionamento é simples, o cliente requisita validação do email e senha junto com o servidor enviando usuário e senha no cabeçalho da mensagem HTTP, o ser-vidor retorna sucesso ou o erro, que é apresentado em forma de mensagem na tela para o usuário.

Figura 28 - Tela de login

5.2.2.2 Interface da tela do menu

Na tela do menu principal do sistema (Figura 29), os botões com as descrições de Mapa, Pontos salvos e Testar câmera, abrem novas telas. Já os botões Enviar pontos e Testar GPS, executam funções, porém não mudam de tela.

O botão com a descrição Enviar Pontos, existe para enviar para o servidor os pontos que já foram executados e que ainda não foram enviados.

Figura 29 - Tela de menu

5.2.2.3 Interface da tela do mapa

A figura 30 representa a tela do mapa, a principal tela da aplicação. Esta tela deve conter sempre visível para o usuário do sistema dois pontos que serão chaves no mapa, seriam eles um azul (de baixo) e um vermelho (de cima).

O ponto azul representa a posição local do usuário, obtida utilizando o GPS do dispositivo, esta é atualizada de tempos em tempos, o default é 3 segundos.

O ponto vermelho no mapa representa o local onde o usuário deve vistoriar, olhando a figura é possível verificar um circulo semitransparente ao redor do ponto. Essa área circular significa que o usuário precisa somente entrar nela para que o ponto seja dado como executado, em seguida indicando o próximo ponto a ser visto-riado.

Para traçar está área circular, foi utilizada a api do google maps para Java Script. No caso desta aplicação o diâmetro do circulo inicialmente para teste está fixo em 15 metros, porém pode ser facilmente alterado.

Quando o usuário entra na área do circulo, automaticamente será apontado o próximo local a ser visitado pelo usuário, e assim sucessivamente até terminarem os pontos.

Figura 30 - Tela do mapa

5.2.2.4 Interface da tela de consulta de pontos

A tela de consulta de pontos é representada pela figura 31. Nela é possível con-sultar todos os pontos que já foram ou não, executados pelo usuário, se já foram enviados para o servidor, se possui foto do ponto, entre outras informações como data, hora e id do ponto.

Figura 31 - Tela de consulta de pontos

5.3 Considerações sobre o capítulo

Este capítulo apresentou a parte de interface dos protótipos mobile e WebServi-ce, ilustrando com imagens das telas criadas.

6 Conclusões e trabalhos futuros

Segundo os objetivos estabelecidos neste trabalho, foi possível desenvolver uma solução mobile alternativa ao sistema de rondas utilizando atualmente, junta-mente com a parte do WebService, foi desenvolvida apenas a parte fundamental para o correto funcionamento do aplicativo mobile, que sempre foi o foco deste tra-balho.

Outro objetivo era conseguir reduzir os custos para possibilitar uma segurança adequada e com valores mais acessíveis. Tendo em vista esse objetivo, é possível afirmar que um dispositivo simples com sistema operacional Android e todas as in-formações necessárias, possui um custo bem abaixo de um bastão de rondas, sem considerar a criação de planos com operadoras para ter internet ilimitada para a comunicação do cliente com o servidor e aparelhos mais baratos quando comprados em grandes quantidades.

6.1 Trabalhos futuros

Falta de tempo e outros fatores, foram relevantes para a não implementação de toda a solução, principalmente na parte do servidor e alguns pontos na parte do cli-ente, estes pontos podendo ser explorados em possíveis trabalhos futuros, tais co-mo:

 Desenvolver uma interface mais amigável na parte do servidor  Adicionar mais informações na parte de cadastros e consulta  Telas para geração de relatórios

 Melhorar a modelagem do banco de dados

 Aperfeiçoar o consumo de bateria na parte cliente

 Cliente receber mensagens do servidor quando necessário

 Fazer análise do movimento do vigia, caso ele se afaste muito da sua ro-ta original, deve ser penalizado.

7 Cronograma

E1: Desenvolvimento de um protótipo E2: Testes do protótipo

E3: Desenvolvimento do relatório de Projeto II. E4: Entrega do relatório de Projeto II.

E5: Ajustes

Referências bibliográficas

SILVA, Ricardo P. e. Como modelar com UML 2. Florianópolis, SC: Visual Books, 2009. 320p.

SILVA, Ricardo P. e. UML 2 em modelagem orientada a objetos. Florianópolis, SC: Visual Books, 2007. 232p.

Heuser, C.A. Projeto de Banco de Dados. 6a edição. Série Livros Didáticos – Instituto de In-formática da

UFRGS, número 4. Editora Bookman, 2009.

Chaffer, Jonathan and wedberg, Karl (2007). Learning jQuery: Better Interaction Design and Web Development with Simple JavaScript Techniques.

BORATTI, Isaias C. Programação Orientada a Objetos em Java. Florianópolis: VisualBooks. 2007.

BORATTI, Isaias C. e OLIVEIRA, A. B. Introdução a Programação – Algoritmos. Visu-al Books, 3 Ed. 2007.

DEITEL, Harvey M.; DEITEL, Paul J. Java: como programar. 3. ed. Porto Alegre: Bookman, 2001. http://www.oficinadanet.com.br/artigo/1571/trabalhando_com_a_ide_eclipse https://developers.google.com/maps/documentation/javascript/reference?hl=pt-br http://eclipse.org http://www.mysql.com/products/workbench/ http://phonegap.com/ http://www.w3schools.com/webservices/ http://jquerymobile.com/ http://jquery.com/ http://axis.apache.org/axis2/java/core/ http://tomcat.apache.org/