DESENVOLVIMENTO DE SISTEMA WEB PARA MONITORAMENTO
Propaganda
UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL – UNIJUÍ DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS – DCEEng CURSO DE CIÊNCIA DA COMPUTAÇÃO MARTIN ANDRÉ ARNOLD DILL DESENVOLVIMENTO DE SISTEMA WEB PARA MONITORAMENTO RESIDENCIAL E PREDIAL EM TEMPO REAL IJUÍ 2012 MARTIN ANDRÉ ARNOLD DILL DESENVOLVIMENTO DE SISTEMA WEB PARA MONITORAMENTO RESIDENCIAL E PREDIAL EM TEMPO REAL Trabalho de Conclusão de Curso apresentado ao Colegiado de Coordenação do Curso de Ciência da Computação a da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUÍ, como pré-requisito parcial para obtenção do título de Bacharel em Ciência da Computação. Orientador: Dr. Paulo Sérgio Sausen IJUÍ 2012 MARTIN ANDRÉ ARNOLD DILL DESENVOLVIMENTO DE SISTEMA WEB PARA MONITORAMENTO RESIDENCIAL E PREDIAL EM TEMPO REAL Trabalho de Conclusão de Curso apresentado ao Colegiado de Coordenação do Curso de Ciência da Computação a da Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUÍ, como pré-requisito parcial para obtenção do título de Bacharel em Ciência da Computação. ______________________________________ Orientador: Prof. Dr. Paulo Sérgio Sausen BANCA EXAMINADORA ______________________________________ Prof. Msc. Juliano Gomes Weber IJUÍ Dezembro de 2012 AGRADECIMENTOS Primeiramente, agradeço a Deus pela oportunidade de cursar uma ótima universidade, e agora, ao final do curso, poder finalizá-lo com ótimas experiências conhecimento adquirido ao longo da mesma. Agradeço também à minha família por todo o apoio e suporte, não deixando faltar nenhum recurso durante a realização do curso. Agradeço ao amigo Felipe Scherer, que cedeu seu trabalho para que eu pudesse fazer o meu, estendendo-o e melhorando-o. Agradeço ao meu orientador, Paulo Sérgio Sausen, que realizou muito bem seu trabalho, sempre conduzindo o trabalho para o caminho certo, auxiliando com importantes orientações que foram muito importantes para a coesão e implementação do trabalho. Por fim, agradeço ao amigo Regis Schuch, que muito me auxiliou durante a realização do meu trabalho, principalmente nos ajustes finais, agradeço a todos estes no geral, pois sem a ajuda dos mesmos, o trabalho certamente não seria entregue. RESUMO Este trabalho visa desenvolver uma aplicação web de monitoramento, em tempo real, utilizando as melhores opções em tecnologia possíveis, através de um estudo dividido em etapas que visa avaliar cada recurso individualmente, conforme seu propósito. Inicialmente, será apresentada uma contextualização do projeto, explicando sua razão e seus objetivos. Após esta contextualização, serão apresentados os resultados do estudo que conduziu para a escolha das seguintes tecnologias: arquitetura de sistema, linguagem de programação, banco de dados, criptografia e formas de comunicação entre diferentes sistemas. Após a escolha das tecnologias, será apresentada a aplicação de monitoramento desenvolvida, detalhando todas as suas funcionalidades e particularidades do desenvolvimento. Por fim, os resultados e a conclusão serão apresentados. Palavras Chave: Sistema Web, Monitoramento e Web Services. ABSTRACT This work intends to develop a web application real time-based monitoring using the best possible technology options, through a study divided into stages that aims to evaluate each feature individually, according to their purpose. Initially a contextualization of the project will be submitted, explaining its reason and objectives. After this context, will be present the results of the study that lead to the choice of the following technologies: system architecture, programming language, database, encryption and communication forms between different systems. After the choice of technologies, will be presented the developed monitoring application detailing all its features and peculiarities of development. Finally, results and conclusion will be presented. Keywords: System Web, Monitoring and Web Services. LISTA DE FÍGURAS Figura 1. Esquema simplificado do sistema atual. .................................................... 13 Figura 2. Software de automação e monitoramento - Status dos dispositivos. ......... 14 Figura 3. Software de automação e monitoramento - Histórico................................. 15 Figura 4. Esquema simples do sistema de monitoramento com a inclusão do módulo web. ........................................................................................................................... 16 Figura 5. Modelo 3 camadas. .................................................................................... 18 Figura 6. Sistema web representado no modelo de arquitetura em 3 camadas. ...... 19 Figura 7. Estatísticas de Uso do PHP. ...................................................................... 20 Figura 8. Estatística de utilização das linguagens web: Quantidade de Utilização X Quantidade de Tráfego. ............................................................................................ 22 Figura 9. Exemplo de sistema utilizando um Web Service. ....................................... 26 Figura 10. Modelo simples de criptografia. ................................................................ 28 Figura 11. Interface da Aplicação para telas maiores. .............................................. 41 Figura 12. Tela principal da aplicação para dispositivos móveis. .............................. 42 Figura 13. Tela de monitoramento – Lista de dispositivos. ....................................... 43 Figura 14. Tela de Histórico – Últimas dez ocorrências. ........................................... 44 Figura 15. Tela de Relatórios da aplicação Web ....................................................... 45 Figura 16. Tela de autenticação da aplicação de monitoramento web. ..................... 46 Figura 17. Tela inicial da aplicação: Mapa de Dispositivos. ...................................... 48 Figura 18. Histórico de eventos da aplicação de monitoramento. ............................. 49 Figura 19. Formulário para geração de relatórios. .................................................... 50 Figura 20. Exemplo de geração do relatório de ocorrências. .................................... 51 Figura 21. Listagem de Atividades Irregulares. ......................................................... 52 Figura 22. Cadastro de atividades irregulares. .......................................................... 52 Figura 23. Listagem dos dispositivos. ....................................................................... 53 Figura 24. Tela de inserção/edição de um dispositivo. .............................................. 54 Figura 25. Tela de listagem de Tipos de Dispositivos. .............................................. 55 Figura 26. Inserção/edição de um tipo de dispositivo. ............................................... 56 Figura 27. Tela de Dados do Cliente e Alteração de Senha. .................................... 56 LISTA DE TABELAS Tabela 1. Custo de licenças de alguns SGBD’s pagos. ............................................ 24 Tabela 2. Comparativo de Preços entre Entidades Certificadoras . .......................... 29 LISTA DE ABREVIATURAS CSS - Cascading Style Sheets HTML - HyperText Markup Language HTTP - HyperText Transfer Protocol HTTPS - Hypertext Transfer Protocol Secure WSDL - Web Services Description Language UDDI - Universal Description, Discovery and Integration SSL - Secure Sockets Layer SGBD - Sistema Gerenciador de Banco de Dados ASP - Active Server Pages JSP - Java Server Pages PHP - PHP: Hypertext Preprocessor AJAX - Asynchronous Javascript and XML SQL - Structured Query Language PIC - Programmable Interrupt Controller JVM - Java Virtual Machine ISS - Internet Information Services] PDF - Portable Document Format XML - eXtensible Markup Language LAMP - Linux + Apache + MySQL + PHP TCP -Transmission Control Protocol IP - Internet Protocol SOA - Service Oriented Arquiteture RMI - Remote Method Invocation DCOM - Distributed Component Object Model CORBA - Common Object Request Broker Architecture SUMÁRIO INTRODUÇÃO .......................................................................................................... 11 1. CONTEXTUALIZAÇÃO E ESTRUTURA EXISTENTE ....................................... 13 1.1. A PROPOSTA DO MÓDULO DE MONITORAMENTO WEB EM TEMPO REAL ......................................................................................................................15 2. REFERENCIAL TEÓRICO ................................................................................. 17 2.1. A ARQUITETURA DE SISTEMA ................................................................. 17 2.2. A LINGUAGEM DE PROGRAMAÇÃO ......................................................... 19 2.3. O BANCO DE DADOS ................................................................................. 23 2.4. A FORMA DE COMUNICAÇÃO ................................................................... 25 2.5. CRIPTOGRAFIA: A SEGURANÇA DO SISTEMA ....................................... 27 2.6. DEMAIS TECNOLOGIAS WEB ................................................................... 30 2.6.1. HTML ..................................................................................................... 30 2.6.2. CSS ....................................................................................................... 31 2.6.3. Javascript .............................................................................................. 32 3. SISTEMA DE MONITORAMENTO WEB ............................................................ 34 3.1. O MÓDULO DESKTOP................................................................................ 34 3.1.1. Web Service: Cliente ............................................................................. 34 3.2. O MÓDULO WEB......................................................................................... 35 3.2.1. Web Service: Servidor .............................................................................. 35 3.2.2. Modelagem do Banco de Dados ............................................................... 36 3.2.3. Interfaces com o Usuário .......................................................................... 40 3.3. APLICAÇÃO DE MONITORAMENTO.......................................................... 45 3.3.1. Mapa de Dispositivos............................................................................. 46 3.3.2. Histórico e Filtros ................................................................................... 48 3.3.3. Relatórios .............................................................................................. 49 3.3.4. Alertas para Atividades Incomuns ......................................................... 51 3.3.5. Painel de Controle: Cadastros ............................................................... 53 CONCLUSÃO............................................................................................................ 57 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 59 11 INTRODUÇÃO Este trabalho de conclusão de curso é uma extensão do trabalho intitulado ―DESENVOLVIMENTO DE UM SISTEMA DE AUTOMAÇÃO PREDIAL PARA PEQUENAS EDIFICAÇÕES‖. Apresentado em 2010 pelo acadêmico Luís Felipe Scherer e orientado pelo Professor MSc. Maurício de Campos. No trabalho em questão, o acadêmico desenvolveu um sistema de automação capaz de coletar sinais de dispositivos distribuídos por um ambiente e enviá-los para um software em um computador que realizava os processos e monitoramento a nível local. Nos últimos anos, a procura por softwares desktop convencionais veio diminuindo gradativamente. Este fato se deve à recente evolução dos sistemas e aplicativos web, juntamente com a consolidação das tecnologias presentes, que nos permitiram realizar praticamente as mesmas tarefas que vinham sendo utilizadas nos softwares desktop de outrora. Uma das vantagens da utilização destes sistemas e aplicativos é a possibilidade de acesso a partir de qualquer lugar onde haja uma conexão com a Internet, garantindo também ao usuário o acesso a seus dados, permitindo maior grau de mobilidade e facilidade de acesso. Este trabalho estende o projeto inicial a partir do desenvolvimento de um módulo web, em tempo real, deste sistema de automação e monitoramento. Este módulo web resgatará as informações coletadas pelo hardware e software já existentes e tornará possível o monitoramento remoto em qualquer lugar do mundo através de uma conexão com a internet, tanto por um computador quanto por dispositivos móveis (ex.: smartphones e tablets). O restante deste trabalho está organizado da seguinte forma: Na seção 1, será apresentada uma contextualização da estrutura de software e hardware já existente, juntamente com um exemplo que explana a utilização do sistema de automação e monitoramento com a adição do módulo web. A contextualização deste cenário será importante didaticamente e também permitirá melhor entendimento do objetivo do sistema existente e o módulo web. Na seção 2 será apresentado o referencial teórico. Em que será explanada a preparação para o estudo, a análise de tecnologias web para o desenvolvimento deste sistema de monitoramento online, tais como: arquitetura de sistema, 12 linguagem de programação, banco de dados, criptografia e formas de comunicação entre diferentes sistemas. Na seção 3 o módulo de monitoramento online é apresentado, este módulo é subdividido em 2 partes: o módulo desktop, contendo uma aplicação que coleta os dados do software local existente e enviando-os para o segundo módulo. O segundo módulo é a aplicação web que recebe estes dados e os exibe de forma dinâmica na tela através de uma aplicação de monitoramento web. Juntamente com esta aplicação há um painel de controle onde são parametrizados os dados coletados. Por fim serão apresentados a conclusão e os resultados do trabalho. Este trabalho se refere exclusivamente a um projeto de software, para mais detalhes sobre hardware e o projeto físico, consultar em (Scherer, 2010). 13 CONTEXTUALIZAÇÃO E ESTRUTURA EXISTENTE Nesta seção será realizada uma contextualização da estrutura de software e hardware desenvolvidos no trabalho de conclusão do acadêmico Luis Felipe Scherer. Serão apresentados os objetivos e resultados obtidos no trabalho do acadêmico, justificando também o propósito e significado da extensão deste trabalho. A proposta do acadêmico foi o desenvolvimento de um hardware capaz de monitorar diversos dispositivos tais como: sensores, lâmpadas, alarme, controles para acesso, entre outros. Estes dispositivos podem estar distribuídos por um condomínio, prédio ou residência. A leitura da situação destes dispositivos seria realizada em tempo real e centralizada em uma placa de hardware contendo um microprocessador PIC que envia estes dados a um computador através de uma conexão serial. A situação do dispositivo representa seu estado no momento da leitura, neste caso há duas possibilidades: ligado e desligado. Na Figura 1 é apresentado um esquema contendo as partes integrantes do sistema inicial. Figura 1. Esquema simplificado do sistema atual. 14 No momento em que os dados são transferidos para o computador, um software desenvolvido na linguagem de programação C++ realiza a leitura dos mesmos e exibe em uma interface gráfica a situação de cada dispositivo, desde que estes estejam devidamente mapeados no software. Na Figura 2 é possível visualizar a tela de situação de dispositivos. Figura 2. Software de automação e monitoramento - Status dos dispositivos. Neste mesmo software há um histórico da mudança de situação dos dispositivos, em que é possível verificar as mudanças de estado de todos os dispositivos monitorados. Um exemplo de utilização deste recurso é saber exatamente o dia e horário de todas as ocorrências durante um determinado período em que o alarme disparou ou por quanto tempo em determinada noite o alarme esteve desligado. Estas análises são utilizadas para resolver questões de segurança, porém o monitoramento pode servir para outros propósitos. A tela de histórico da mudança dos dispositivos pode ser visualizada na Figura 3. 15 Figura 3. Software de automação e monitoramento - Histórico. 1.1. A PROPOSTA DO MÓDULO DE MONITORAMENTO WEB EM TEMPO REAL Após a explanação do sistema inicial, nesta subseção será apresentada a proposta do desenvolvimento do sistema web. Aqui serão descritos os objetivos do trabalho e serão propostas melhorias que posteriormente serão implantadas no sistema e que conduzirão para a criação do módulo de monitoramento web. O primeiro objetivo que levou à ideia da criação do sistema web foi permitir que os clientes que estão residindo nos locais monitorados possam ter a visão geral do comportamento da sua residência ou prédio, mesmo estando fora de casa. Desde que haja acesso à Internet, será possível verificar a situação de sua moradia. Este aspecto por si só já revela um grande avanço em relação à proposta inicial, pois nela só é possível o monitoramento local. Este objetivo em particular é o mais complexo, pois implica no estudo e seleção de diversas tecnologias para tornar possível a integração entre o módulo local e o módulo web do sistema. Entre elas: a escolha de uma linguagem de 16 programação para a web em que o programa será desenvolvido, um banco de dados para armazenar as informações coletadas, uma forma de comunicação entre estes diferentes locais, uma forma de comunicação segura entre as partes (criptografia) e também aspectos organizacionais, tais como escolha de uma arquitetura de sistema. Na Figura 4 pode ser visualizado um esquema de como o sistema deverá se adaptar para receber o módulo web. Figura 4. Esquema simples do sistema de monitoramento com a inclusão do módulo web. O sistema Web também terá como objetivo, através da análise dos dados capturados, analisar e detectar comportamentos irregulares, pois estará armazenando um histórico das atividades. Um exemplo de atividade irregular seria o desligamento do alarme no período entre 23h da noite e 06h da manhã do dia seguinte. O terceiro objetivo do sistema web será criar diferentes interfaces de usuário, tais como interfaces para smartphones e tablets, e não apenas computadores pessoais. Isto possibilitará melhor usabilidade em diferentes plataformas, visto que em telas menores muita informação dificulta a visão e interação do usuário. Isto é incomum em computadores convencionais com telas maiores, em que mais informações e opções gráficas mais avançadas podem ser agregadas ao sistema para melhorar o entendimento. 17 2. REFERENCIAL TEÓRICO Nesta seção serão apresentadas as tecnologias e ferramentas utilizadas para o desenvolvimento e validação do módulo de monitoramento web. Atualmente há inúmeras opções de tecnologias para se desenvolver um sistema web. Há diversas formas de organização (arquitetura de sistema), linguagens de programação, bancos de dados e comunicação entre sistemas. É necessário então um estudo mais aprofundado das tecnologias, para que o software seja desenvolvido com as ferramentas que mais se adequam ao estilo e propósito do sistema, que podem ser os mais diversos. 2.1. A ARQUITETURA DE SISTEMA Segundo (BOOCH et. al., 1999), arquitetura de sistema é ―O conjunto de decisões significativas sobre a organização de um sistema de software, a seleção dos elementos estruturais e as suas interfaces em que o sistema é composto, em conjunto com o seu comportamento, tal como especificado nas colaborações entre esses elementos, a composição destes elementos estruturais e comportamentais em subsistemas progressivamente maiores, e o estilo arquitetônico que guia esta organização - esses elementos e suas interfaces, suas colaborações e sua composição‖. Escolher uma arquitetura de sistema é importante, pois quando é utilizada, está se fazendo a organização fundamental de um sistema, incorporada em seus componentes, suas relações com os outros sistemas e os princípios que regem a sua concepção e evolução (HILLARD, 2000). Existem diversas arquiteturas de sistemas que podem ser utilizadas para se conceber um software, cada uma delas apresenta vantagens e desvantagens para cada caso. Para este sistema web, a arquitetura a ser utilizada é o ―modelo 3 camadas‖ (MICROSOFT GUIDE, 2010). Nesta arquitetura, o software é dividido em três camadas distintas que comunicam-se entre si. A primeira camada é Aplicação, esta é responsável pela 18 interação do usuário com o sistema, pode-se dizer que esta é a parte visual do sistema, as telas. Na segunda camada, estão as regras de negócio, nesta parte há todas as regras que regem o funcionamento do software, ou seja, todas os serviços que fazem o sistema funcionar. A terceira camada é chamada de ―Camada de persistência‖, a persistência se refere à persistência de dados, esta camada é responsável por armazenar e buscar os dados coletados pelo sistema ou necessários para o funcionamento do mesmo, pode ser chamada também de camada de dados. Na Figura 5 é ilustrado o modelo 3 camadas e suas partes integrantes (MICROSOFT GUIDE, 2010). Figura 5. Modelo 3 camadas (Microsoft Dynamics Nav). A vantagem da utilização de um modelo 3 camadas neste sistema é que se for necessário realizar ajustes ou até mesmo substituir uma camada inteira, as outras camadas permanecerão intactas e o sistema funcionará normalmente, pois estas serão independentes entre si. Um exemplo de troca de camada seria a substituição de um sistema gerenciador de banco de dados por outro, com mais recursos. É possível também reaproveitar o código das demais camadas para se desenvolver um sistema multi-canal (acessado por vários meios ou plataformas). 19 Neste trabalho serão desenvolvidas duas camadas de apresentação para o sistema web: A principal para telas grandes (computadores e tablets) e a segunda para se adaptar a telas menores, por exemplo: smartphones. Utilizando o modelo de 3 camadas será necessário desenvolver apenas uma nova camada de apresentação, as regras de negócio e camada de persistência continuam intactas e são totalmente reaproveitadas sem qualquer modificação. Outra vantagem é a possibilidade de integração com outras aplicações, pela comunicação mais acessível à camada de regras de negócio e banco de dados. Na Figura 6 pode ser visualizada arquitetura do sistema de monitoramento web utilizando o modelo 3 camadas. Figura 6. Sistema web representado no modelo de arquitetura em 3 camadas. 2.2. A LINGUAGEM DE PROGRAMAÇÃO Várias propriedades das linguagens de programação devem ser analisadas ao escolher a que melhor se adapta ao propósito do sistema a ser desenvolvido. Alguns destes aspectos são: ● Simplicidade: O quão simples é escrever os comandos na sintaxe da linguagem para se fazer um programa; 20 ● Portabilidade: Propriedade que permite utilizar o mesmo software para ser executado em diferentes plataformas (sistemas operacionais); ● Compatibilidade: Possibilidade de integração da linguagem com diversas tecnologias, como por exemplo, bancos de dados ou Web Services; ● Segurança: O quão a linguagem está vulnerável a ataques e invasões; ● Documentação: Suporte que a linguagem oferece para consulta sobre seus métodos e recursos. Neste trabalho, um estudo com as linguagens de programação para a web mais populares foi realizado, entre elas ASP, JSP e PHP. A linguagem que se destacou e foi escolhida para o desenvolvimento do módulo web foi a linguagem PHP. A seguir serão explicados os motivos da escolha. O PHP: Hypertext Preprocessor é uma das linguagens para web mais utilizadas no mundo (PHP, 2008). Sua popularidade se deve à facilidade em criar aplicações dinâmicas com suporte à maioria dos bancos de dados existentes e ao conjunto de funções que, por meio de uma estrutura flexível de programação, permitem desde a criação de simples portais até complexas aplicações de negócio. (DALL'OGLIO, 2007) Na Figura 7 pode ser visualizado um gráfico com a evolução da utilização do PHP nos servidores web, na figura em questão mostra que desde 2000 o número de domínios que está utilizando PHP aumentou consideravelmente e este se mantém estável. Figura 7. Estatísticas de Uso do PHP (php.net). 21 Sob o aspecto da simplicidade, PHP é uma linguagem com um modelo de desenvolvimento muito simples. O propósito original do PHP era desenvolver rapidamente aplicações para a Web sem qualquer treinamento preliminar. Isto foi tão bem sucedido que todas as principais empresas de hospedagem oferecem pacotes de hospedagem para aplicações PHP. Além disso, o PHP possui duas sintaxes, a estruturada e a orientada a objeto, que permite ao desenvolvedor a liberdade de escolher o estilo de programação que mais lhe é vantajosa. Em relação à portabilidade, a linguagem está disponível para quase todos os sistemas operacionais. A abordagem técnica do PHP é idêntica a uma Máquina Virtual Java (JVM). É necessário apenas instalar o PHP na máquina servidor e o aplicativo irá funcionar imediatamente, sem reescrever código, não importa qual sistema operacional está sendo utilizado. A linguagem PHP está disponível para utilização nos dois servidores de páginas mais utilizados atualmente: Apache e Microsoft ISS. O PHP possui bibliotecas nativas para acesso aos principais SGBDs do mercado, entre eles: MySQL, PostgreSQL, Oracle e SQL Server. Possui bibliotecas nativas para desenvolvimento de Web Services SOAP, permite criar documentos das mais diversas extensões, tais como documentos de texto, PDFs, Planilhas eletrônicas, XML entre outros. A plataforma PHP não teve nenhum alerta de segurança em vários anos, atualmente é a plataforma mais confiável para desenvolvimento de aplicações e web sites. A documentação é muito ampla, todas as funções e bibliotecas suportadas pela linguagem estão disponíveis no site oficial (http://php.net), a linguagem é aperfeiçoada e mantida por cerca de mil engenheiros e a comunidade de desenvolvedores que utilizam PHP é de aproximadamente 4,5 milhões de usuários. Na Figura 8 podem ser vistos mais alguns detalhes sobre a natureza da utilização do PHP, pode-se observar que o mesmo está liderando sob o aspecto da quantidade de utilização. 22 Figura 8. Estatística de utilização das linguagens web: Quantidade de Utilização X Quantidade de Tráfego. Ao analisar as propriedades da linguagem de programação PHP, concluiu-se que esta é a mais adequada para o desenvolvimento do módulo web, pois neste sistema deverão ser utilizados diversas tecnologias para que o desenvolvimento do mesmo seja possível, entre elas um SGBD e um Web Service a serem escolhidos posteriormente, como o PHP já suporta nativamente estes recursos, o uso desta linguagem é apropriado. Em relação às questões de segurança, o sistema web a ser desenvolvido deve ter um cuidado especial, pois estará trabalhando com dados sigilosos, como a linguagem está estável a muitos anos e possui uma equipe de desenvolvimento grande, a linguagem garante a segurança necessária para o sistema. A questão da portabilidade também é importante, pois um dos objetivos da criação deste sistema web é o acesso em diversos dispositivos em diferentes plataformas, por ser uma linguagem de execução no lado do servidor, não importa qual plataforma está sendo utilizada. Desde que haja uma aplicação que permita a navegação na internet, o sistema poderá ser acessado. O PHP oferece vantagens também para o desenvolvedor, que contará com uma sintaxe simples e uma extensa documentação e comunidade de desenvolvedores. Com estes recursos a disposição, o desenvolvimento se torna 23 facilitado, além de possuir nativamente diversos recursos que mais tarde serão necessários para o desenvolvimento do sistema. 2.3. O BANCO DE DADOS Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a estes dados. O conjunto de dados, comumente chamado de banco de dados, contém, por exemplo, informações sobre uma empresa em particular. O principal objetivo de um SGBD é proporcionar um ambiente conveniente e suficiente para a recuperação e armazenamento das informações do banco de dados (KORTH, 1999). Um SGBD faz mais do que simplesmente gravar e acessar dados, se fosse apenas isso, uma aplicação poderia fazê-lo através de um gerenciamento de arquivos simples. Um SGBD possui diversos recursos transparentes ao utilizador que garantem que não haja inconsistências e redundâncias nos dados, dificuldade no acesso, problemas de integridade, também implementam questões de segurança relacionados ao acesso aos dados e gerenciam acessos concorrentes (KORTH, 1999). Nesta seção será explanada a escolha do SGDB que tem como objetivo a gravação dos dados coletados pelo sistema de monitoramento local e que serão utilizados para consulta e análise no módulo web. Existem diversos produtos de SGBDs disponíveis no mercado atualmente, cada qual com suas características que os tornam melhores em alguns casos e piores em outras ocasiões sob a ótica do desempenho e recuperação de dados. Entre os mais utilizados estão: PostgreSQL, Oracle, Microsoft SQL Server e MySQL. O foco deste trabalho está mais relacionado à aplicação em si e não a forma de armazenamento e recuperação das informações. Tendo isso como base, não seria necessário um banco de dados demasiadamente robusto, pois a aplicação, não estará trabalhando com um grande volume de dados. Neste caso, a melhor opção de SGBD para o módulo web de monitoramento é o SGBD MySQL. 24 O MySQL é um SGBD livre de custo e de código aberto. No início da sua história, o MySQL enfrentou muitas críticas devido a sua falta de suporte a recursos básicos dos SGBDs, tais como chaves estrangeiras e sub-consultas. Porém, nos últimos anos, o MySQL tornou-se banco de dados mais popular do mundo pelo seu alto desempenho, alta confiabilidade e facilidade de uso. (CONVERSE, 2004) É também o SGBD de escolha para uma nova geração de aplicativos que utilizam o LAMP (Sigla da combinação: Linux + Apache + MySQL + PHP / Perl / Python). Muitas das maiores organizações e de mais rápido crescimento do mundo, incluindo Facebook, Google, Adobe, Alcatel Lucent e Zappos encontraram no MySQL uma forma de economizar tempo e dinheiro ligando seus web sites, sistemas críticos de negócio e pacotes de software (MySQL, 2012). Uma das vantagens para a escolha deste SGBD foi a sua ampla disponibilidade nos servidores de hospedagem web, praticamente todos os servidores trabalham com o MySQL em conjunto com a Linguagem PHP. Outra vantagem de utilização é o custo zero, ou seja, o MySQL é livre de custo, ao contrário de outros SGBDs como Oracle, SQL Server e DB2. Na Tabela 1 pode-se verificar o custo de manutenção de alguns SGBDs pagos do mercado. Tabela 1. Custo de licenças de alguns SGBD’s pagos. SGBDs Custo pela licença (em Reais) Oracle Standard (para 1 processador) R$ 35.000,00 Microsoft SQL Server (para 1 processador) R$ 3.500,00 O SGBD é nativo para as 3 plataformas mais utilizadas em servidores: Unix, Linux e Windows. Também não é necessária compatibilidade específica com algum servidor web específico, o PHP se encarrega de integrar ambas as partes. MySQL é o padrão de fato para sites de alto tráfego web pelo seu mecanismo de consulta de alto desempenho, capacidade de inserção de dados otimizado, e um forte apoio para as funções especializadas da web como pesquisas rápidas em textos longos (MySQL, 2012). Por fim, a vantagem da utilização do MySQL para este trabalho advém da escolha da linguagem de programação anterior, o PHP. A linguagem PHP e o MySQL foram praticamente desenvolvidos para trabalharem juntos, a união destas duas ferramentas faz com que os softwares obtenham maior desempenho e 25 agilidade. Por fim, a estabilidade deste SGBD é comprovada, não há grandes mudanças de versão para versão, fazendo com que este seja fácil de se trabalhar. (CONVERSE, 2004). 2.4. A FORMA DE COMUNICAÇÃO Nesta seção serão apresentados os conceitos envolvendo formas de comunicação entre diferentes plataformas e justificada a escolha por uma tecnologia específica. O sistema de monitoramento local e o módulo web estarão sendo executados em locais distantes fisicamente, ou seja, fora do alcance de uma rede local. O primeiro estará instalado em um computador no local monitorado e o outro estará em um servidor na web que poderá ser acessado em qualquer local. As plataformas em que foram desenvolvidas estes dois módulos são distintas, o sistema local foi desenvolvido na linguagem C++ para o sistema operacional Windows e o sistema web local será desenvolvido em PHP que é uma linguagem exclusiva para web. Para realizar uma conexão bem sucedida entre os dois módulos é necessária uma tecnologia que utilize um padrão de comunicação. Este padrão deve ser suportado em ambas as linguagens e que possa ser facilmente configurado. Sabendo disso, uma pesquisa foi feita para verificar quais meios de comunicação poderiam ser utilizados para interligar estes dois módulos. Uma opção seria realizar uma conexão TCP/IP padrão, que está disponível nativamente em praticamente todas as linguagens de programação de alto nível, porém esta opção é de difícil implementação. Para que esta opção seja bem sucedida o sistema deveria reconhecer as mensagens enviadas e tratá-las para que o programa entenda o que deve fazer e então chamar os métodos responsáveis. Além disso, a comunicação entre estas duas tecnologias que teria que ser configurada manualmente. Na pesquisa concluiu-se que a melhor opção para comunicação entre os módulos seria a utilização de um Web Service. Um Web Service é um conjunto de funções empacotas, entidades independentes que estão publicadas na web para outros programas utilizarem. 26 A tecnologia de Web Services oferece um modelo de programação para a criação de aplicações distribuídas que utilizam padrões abertos. A arquitetura utiliza padrões da Internet como HTTP, XML e SOAP (Simple Object Acess Protocol) e introduz novos conceitos e tecnologias, tais como Arquitetura Orientada a Serviços (SOA), Universal Description, Discovery and Integration (UDDI), e Web Services Description Language (WSDL) (SONERA PLAZA, 2002). A tecnologia de Web Services foi escolhida porque a linguagem de programação PHP, que será utilizada para o desenvolvimento do módulo web e a Linguagem de programação C++ utilizada no desenvolvimento do sistema local possuem suporte nativo para desenvolvimento de Web Services com o protocolo SOAP, que será o padrão utilizado para a comunicação entre os módulos. SOAP é um protocolo leve para troca de informações em um ambiente distribuído. É um protocolo de comunicação, diferente de um sistema de computação distribuída como RMI, DCOM ou CORBA, que são protocolos específicos para uma linguagem. SOAP é independente do modelo de programação, plataforma ou de transporte usado para trocar as mensagens SOAP, e sua sintaxe é baseada em XML. Na Figura 9 pode ser visualizado um exemplo de funcionamento de um Web Service SOAP. Figura 9. Exemplo de sistema utilizando um Web Service. (http://www.oficinadanet.com.br/) Neste exemplo, a aplicação local da esquerda está invocando um método de um web service em um sistema remoto, esta comunicação acontece web utilizando HTTP através do protocolo SOAP. Depois que o método é processado, uma resposta é enviada para a aplicação com o resultado da solicitação. Também é 27 possível perceber que o web service se divide em duas partes: servidor e cliente, sendo o servidor responsável por abrigar e disponibilizar os métodos e o cliente que irá utilizar estes métodos. O funcionamento do Web Service no sistema de monitoramento web será realizado da mesma forma: No módulo web (servidor do Web Service) serão criadas e abrigadas as funções que irão receber os dados vindos da aplicação local e que irão fazer a análise e armazenamento destes dados. Este conjunto de funções serão métodos, que estarão disponíveis para execução pela aplicação local (cliente). O web service, ao receber uma requisição, irá processar os dados e enviará uma resposta para o sistema local informando que mais dados podem ser enviados ou, em caso de erro, o que está acontecendo de errado. Outro motivo que conduziu à escolha desta tecnologia foi a facilidade na implementação e disponibilização de novos métodos para a aplicação local. A publicação de um novo método é transparente, basta desenvolver o método no servidor e automaticamente o método estará disponível para acesso na aplicação cliente, não sendo necessária modificação no código da aplicação local. Além da facilidade de utilização, uma questão importante é a segurança. A tecnologia de web services está apta a implementar um sistema de proteção aos dados que estão trafegando sobre o protocolo SOAP. Isso é necessário devido à questão que envolve o sigilo dos dados captados. Na próxima seção o assunto de criptografia aos dados será explanada. 2.5. CRIPTOGRAFIA: A SEGURANÇA DO SISTEMA Criptografia é um meio de aprimorar a segurança de uma mensagem ou arquivo embaralhando o conteúdo de modo que ele só possa ser lido por quem tenha a chave de criptografia correta para desembaralhá-lo. Por exemplo, ao comprar algo em um site, as informações da transação (como endereço, número de telefone e número do cartão de crédito) normalmente serão criptografadas para ajudar a mantê-la segura (MICROSOFT BRASIL, 2012). 28 Na Figura 10 pode-se observar um fluxo de informação utilizando criptografia, onde a mensagem é criptografada antes de ser enviada, e descriptografada na chegada ao seu destindo, impedindo que seja lida durante seu percurso. Figura 10. Modelo simples de criptografia. Neste sistema serão aplicadas duas formas de criptografia, essas criptografias possuem o mesmo objetivo: proteger os dados que trafegarem pela Internet. A primeira será responsável pela proteção da aplicação web em si, que fará a comunicação com o utilizador do sistema, protegendo os dados enviados pela aplicação ao navegador do cliente, a tecnologia utilizada será a SSL (Secure Socket Layer). Já a segunda criptografia tratará de proteger os dados enviados através do web service, no sentido da aplicação web service local (cliente) para a aplicação web (servidor), a resposta do servidor para a aplicação não será necessária, pois este estará enviando apenas uma confirmação de recebimento dos dados, neste caso será utilizada um algoritmo criptográfico secreto. O SSL é uma tecnologia de proteção ao trafego de dados mais utilizada na Web. Praticamente todos os sistemas web ou web sites que necessitam ter uma proteção aos dados que enviam aos clientes utilizam este tipo de criptografia. Isto permite que os dados enviados não sejam entendidos por outras máquinas na rede, senão a real utilizadora do serviço. O SSL utilizado neste sistema web será o Módulo do servidor de páginas Apache denominado OpenSSL, uma solução que implementa o algoritmo de forma gratuíta e já é nativa do servidor. Utilizando o OpenSSL e fazendo com que o cliente 29 sempre utilize uma conexão segura através do protocolo HTTPS, é possivel implementar a comunicação de forma segura, porém apenas isso não basta. Para a aplicação que recebe os dados se certificar que a aplicação que está os enviando os dados é a verdadeira, ou seja, que não há nenhuma máquina estranha enviando dados falsos para o receptor é necessário que, a aplicação no servidor (neste caso o sistema web) utilize um certificado digital válido. Um certificado digital é um documento eletrônico que visa atestar a identidade do seu titular (usuário ou instituição, como bancos e lojas de comércio eletrônico), em documentos ou e-mails digitalmente assinados, em navegação na internet ou em operações online, inclusive sigilosas. Ao ser instalado no computador e usado em uma dessas ações pelo titular, por meio de software capaz de operá-lo, o certificado dá garantias dessa identidade, ou de privacidade, para as partes envolvidas (REZENDE, 2005). Após a certificação, que, em tese, prova que a aplicação do servidor é a original, os dados podem ser transmitidos, mas caso a identidade não seja comprovada, o navegador de internet bloqueará o tráfego dos dados a não ser que o cliente utilizador deseje conectar no serviço mesmo assim, adicionando uma exceção de segurança. Para obter o certificado digital válido, é necessário que a aplicação do servidor compre-o de uma entidade certificadora. Esta entidade vai gerar um certificado válido e garantirá que este não está sendo usado por aplicações mal intencionadas, assegurando trafego seguro à aplicação web e também aos utilizadores. Neste trabalho não serão utilizados certificados digitais, devido ao seu alto valor e estar em fase inicial, porém caso a aplicação seja utilizada por clientes reais em um futuro próximo, a aplicação deverá fazer uso de um. Na Tabela 2 podem-se observar alguns valores em dólares de certificados digitais oferecidos pelas mais populares entidades certificadoras da internet (WhichSSL, 2012). Tabela 2. Comparativo de Preços entre Entidades Certificadoras (WhichSSL ,2012). Entidade Certificadora Verisign GeoTrust COMODO Valor do Certificado $ 234,00 $ 118,00 $ 64,95 Validade do Certificado 1 Ano 1 Ano 1 Ano 30 Para a comunicação entre o web service do módulo local com o módulo web será utilizado um algoritmo criptográfico secreto. A tecnologia SSL também poderia ser utilizada para esta conexão, porém a utilização desta faz com que a aplicação perca desempenho no envio dos dados, pois leva um tempo considerável para criptografar e descriptografar as mensagens. Além da conexão SSL será utilizada autenticação por meio de sessões, uma forma fundamental e simples de implementar a segurança, através de um controle de acesso utilizando usuario e senha. Para que a conexão seja mais rápida entre as partes, um algoritmo criptográfico menos complexo pode ser utilizado, visto que os dados, mesmo que interpretados, não podem ser compreendidos em sua totalidade, pois estes não estão associados aos dispositivos no momento do envio. A aplicação cliente do web service apenas envia um vetor de elementos numéricos que só faz sentido unindo estes valores com as informações que estão contidas no servidor, que possui a segurança SSL. 2.6. DEMAIS TECNOLOGIAS WEB Ao criar um sistema web são utilizadas algumas tecnologias que são essenciais para que o desenvolvimento se inicie. Estas tecnologias já estão consolidadas e são utilizadas praticamente em todos os sistemas desenvolvidos especialmente para a web. Estas tecnologias são o HTML, CSS e Javascript. 2.6.1. HTML Para publicar informação de distribuição global, é preciso uma linguagem de compreensão universal, um tipo de publicação de língua materna que todos os computadores podem potencialmente entender. A linguagem de publicação utilizada na Internet é HTML (HyperText Markup Language) (W3C, 2012). HTML dá aos autores a possibilidade de: Publicar documentos on-line com títulos, textos, tabelas, listas, fotos, etc; 31 Recuperar informações on-line através de links de hipertexto, com o clique de um botão; Projetar formas para a realização de transações com serviços remotos, para uso na busca de informações, reservas ou encomenda de produtos; Incluir videoclipes, músicas e outras aplicações diretamente em seus documentos. O HTML é uma linguagem de marcação, baseada em XML, é o padrão utilizado por todas as páginas de internet que existem, para se publicar algo na web, é necessário que seja feito através de um documento/página HTML. Isto significa que apenas escolher uma linguagem de programação e utilizá-la para desenvolver um sistema web não basta. É necessário utilizar o HTML para padronizar as informações que serão exibidas na tela e também dar forma ao sistema. A linguagem de programação PHP está diretamente ligada ao HTML, pois a linguagem, ao ser executada, gera documentos HTML que serão as telas do sistema. Atualmente a versão 5 do HTML ainda está em desenvolvimento, portanto será utilizada a última versão já estável e suportada pelos principais navegadores de Internet. Esta versão é o HTML 4.1. 2.6.2. CSS O CSS (Cascading Style Sheets) é um mecanismo simples para adicionar estilo (por exemplo, fontes, cores, espaçamentos) aos documentos web. É possível desenvolver um sistema sem usar estilos, porém sistemas muito básicos, sem cores nem formas personalizadas. O CSS é utilizado para personalizar e destacar as informações presentes em um documento HTML, ou seja, dá forma e desenvolve a interface com o usuário do sistema (W3C, 2012). No caso deste trabalho serão desenvolvidos dois estilos, o primeiro para computadores desktop, com telas maiores, o segundo para dispositivos móveis com acesso à internet, que por consequência possuem telas menores. É dada extrema importância à interface de utilização do sistema porque esta cumpre a tarefa essencial de acertar a devida importância para cada informação 32 presente na tela, como a forma de acesso ao sistema será destas duas formas distintas, é necessário que se destaque de forma diferenciada as informações para cada tipo de dispositivo, melhorando o aproveitamento do sistema objetivando a fácil utilização do mesmo. 2.6.3. Javascript Javascript é a linguagem de programação do tipo script mais popular do mundo. É a linguagem padrão utilizada para interação em páginas Web, mas também é amplamente usado por aplicativos de desktop, aplicativos de telefonia móvel, e servidores de internet. O Javascript, diferentemente do PHP, é executado na máquina do cliente (utilizador de sistema) e não no servidor (disponibilizador do sistema), o que lhe permite realizar funções que não são possiveis pelo PHP, como, por exemplo, detectar a resolução da tela do computador em que está sendo utilizado um sistema web, esta informação o PHP não consegue capturar, pois não está sendo executado na máquina do utilizador, mas sim em um servidor (W3C, 2012). O javascript será utilizado neste sistema para requisitar novas informações sobre o monitoramento em intervalos de tempo determinado. Como o sistema de monitoramento é em tempo real, as informações precisam ser atualizadas constantemente. É possivel atualizar estas informaçoes sem a utilização desta linguagem de script, porém há uma diferença. Sem usar o Javascript é necessário atualizar toda a página para requerer novas informações, isso significa ter de carregar novamente, além das novas informações, todas as imagens, estilos e demais componentes do documento HTML. Isto gera uma lentidão no sistema e não constitui uma interface fluída de navegação, o que prejudicaria muito a utilização do sistema. Com javascript, apenas as novas informações podem ser recuperadas através de requisições assíncronas (AJAX) e o fluxo de dados se torna muito menor e a atualização dos dados do sistema se dá de forma transparente, como uma aplicação desktop tradicional. 33 O Javascript também será utilizado para detectar informações sobre o cliente utilizador, como, por exemplo, em que tipo de máquina o sistema está sendo executado (computador ou dispositivo móvel) e assim aplicar o estilo adequado para cada cliente. Além disso o Javascript é utilizado para dar mais dinamismo ao sistema, projetando animações com imagens ou componentes do sistema. 34 3. SISTEMA DE MONITORAMENTO WEB Nesta seção será apresentado o sistema de monitoramento web, descrevendo todos os seus detalhes de desenvolvimento. O sistema será descrito em duas subseções, a primeira apresentará detalhes sobre o módulo do sistema desenvolvido para a parte local do sistema, responsável pelo controle e envio dos dados para a aplicação web, que será descrita na segunda subseção e que será responsável pela análise e exibição dos dados coletados. 3.1. O MÓDULO DESKTOP O módulo desktop do sistema possui uma função simples, porém essencial para o funcionamento da aplicação. Os dados que estão sendo capturados pelo sistema local de monitoramento necessitam ser enviados para o servidor web, onde estará rodando a aplicação que será responsável pela análise e exibição destes dados. A função deste módulo desktop é enviar, através de um web service, os dados que foram coletados pelo hardware presente no local monitorado. Para isso, foi necessário adaptar e reescrever parte da aplicação cliente já existente, adicionando uma chamada para o web service do módulo web. 3.1.1. Web Service: Cliente Para desenvolver o Web Service na aplicação local é necessário utilizar uma biblioteca em C, que realiza conexões e interage com web services remotos. A biblioteca utilizada para desenvolvimento se chama GSoap, esta não é nativa na linguagem C, mas basta importá-la para o arquivo principal da aplicação local para fazer uso da mesma. 35 A partir do momento em que o código da aplicação reúne todos os sinais dos dispositivos em um vetor, a chamada de web service é adicionada, enviando os sinais de todos os dispositivos coletados, juntamente com a identificação do cliente o qual está os enviando e também a data e a hora do envio. O Web Service se encarrega de enviar os dados e receber uma resposta de confirmação que garante que os dados chegaram com sucesso. Inicialmente o código foi escrito sem uma Thread, porém ao perceber que, se a conexão com o servidor falhasse por um momento, a aplicação travaria, pois estaria esperando a resposta do Web Service. Constatando esta falha, foi criada uma Thread para enviar os dados, assim caso a conexão falhasse, a aplicação continuaria funcionando normalmente, um marcador foi adicionado à interface da aplicação para exibir se o web service estava conectado ao servidor, baseado na resposta obtida. Este marcador pode ser observado na Figura 3, localizado à direita da aplicação, se chamando Net Conectado. Quando conectado exibe uma cor vermelha, ao desconectar exibe uma cor cinza. No caso da figura a aplicação encontra-se desconectada do Web Service. 3.2. O MÓDULO WEB Nesta seção são descritos todos os detalhes de implementação do módulo web, contendo o Web Service servidor, o banco de dados e a aplicação de monitoramento web. 3.2.1. Web Service: Servidor O Web Service do servidor é responsável pela captura dos dados enviados pelo Web Service cliente e a interpretação dos mesmos, tendo como responsabilidade a análise dos dados e a geração do histórico, juntamente com a gravação da situação atual no banco de dados. Ao receber novos dados através da função ―RecebeDados‖ do Web Service, a primeira tarefa do servidor é identificar qual cliente está os enviando, já que o 36 sistema comporta múltiplos clientes. Esta verificação é realizada através da consulta à primeira posição do vetor de dados recebido, que carrega o identificador único do cliente. Ao identificar o cliente, a função verifica quais dados foram alterados desde o último envio. Esta verificação é realizada para saber quais dispositívos alteraram a sua situação. Após identificar alterações, as posições alteradas são consultadas na tabela de dispositivos para verificar quais dispositivos estão ativos e se os dispositivos cadastrados ativos possuem a opção ―Gerar Histórico‖, esta opção é utilizada para definir quais deles, ao alterarem seus Status, gerarão ou não uma nova atividade no histórico. Isto é interessante para destacar alguns dispositivos mais importantes, tais como o alarme ou a sirene, e desconsiderar alterações em lâmpadas, por exemplo. Se um dispositivo possui a opção ―Gerar Histórico‖, uma nova entrada no histórico é criada, contendo a data de envio dos dados, qual dispositivo teve seu status alterado e qual foi a alteração realizada. Neste caso só há dois tipos de alteração: de Ligado para Desligado, ou de Desligado Para Ligado. Ao analisar a situação de todos os dispositivos, a situação atual é gravada no banco de dados como última situação válida, que será utilizada para comparar com novos dados que o Web Service estará recebendo. Este processo se repete a cada novo envio, caracterizando um loop infinito, em que os dados são recebidos, processados, e uma confirmação é enviada ao cliente para que este possa enviar novos dados. O envio de dados pela aplicação cliente é realizado em um intervalo menor que 2 segundos, então a situação atual pode ser considerada como tempo real. E a atualização dos dados na aplicação é instantânea, exibindo ao cliente o status dos dispositivos de seu local monitorado há apenas alguns segundos atrás. 3.2.2. Modelagem do Banco de Dados Nesta subseção é apresentada a modelagem lógica de banco de dados da aplicação de monitoramento web. O projeto é composto por 6 tabelas: Sinais, 37 Descrição dos Sinais, Clientes, Histórico, Tipos de Dispositivos e Atividades Irregulares. Tabela Sinais Nesta tabela é armazenada a situação atual de cada cliente em um registro único, que é constantemente atualizada pelo Web Service. SINAIS Chave Atributo Tipo de Dado Tamanho Observações DATAHORA timestamp @ - Chave primária CLIENTE # caractere 50 Chave estrangeira da tabela Clientes VALORES caractere 1000 A modelagem foi realizada desta forma porque se fossem utilizadas chaves estrangeiras para todos os dispositivos, em múltiplos registros, a cada segundo centenas de atualizações de registros deveriam ser feitas, fazendo com que o sistema se tornasse lento, ao obter todos os dados em um só registro, seu uso se torna muito mais eficiente. Tabela Descrição de Sinais Nesta tabela é realizada a associação de um dispositivo cadastrado no sistema com a posição no vetor recebido de um cliente, ou seja, apenas a partir deste momento é possível identificar qual sinal pertence a qual dispositivo. DESC_SINAIS Chave Atributo @ CLIENTE @ NUM_SINAL DESC_SINAL # Tipo de Dado Tamanho Observações Inteiro 10 Chave primária Inteiro 10 Chave primária caractere 100 Chave Estrangeira de Tipo TIPO_DISP inteiro 10 de Dispositivo GERA_HISTORICO caractere 1 sim ou não (0 ou 1) ATIVO caractere 1 Ativo ou inativo Posição na planta da POS_PLANTA caractere 20 aplicação web. Nesta tabela estão todas as informações de cada dispositivo, a qual cliente ele pertence, qual sua posição no vetor de dados do cliente, seu nome, tipo de 38 dispositivo, se suas mudanças de estado geram histórico ou não, se o dispositivo está sendo utilizado ou está desativado e também qual sua posição na planta do cliente utilizada na aplicação web na tela de monitoramento do sistema. Tabela Clientes Nesta tabela são armazenadas as informações sobre os clientes do sistema, informações tais como número de identificação, nome completo, login de utilização, senha de acesso e nível de acesso. CLIENTES Chave Atributo @ ID_CLI @ NOME_CLI USERNAME PASSWORD NIVEL_ACESSO Tipo de Dado Tamanho Observações Inteiro 10 Chave primária caractere 10 Chave primária caractere 100 caractere 10 Senha Criptografada caractere 1 Total ou parcial (1 ou 0) Nesta tabela são armazenadas apenas as informações utilizadas pelo sistema a respeito dos seus clientes, informações completas estarão sendo armazenadas em outros sistemas. O nível de acesso define se o usuário pode ou não controlar seus dispositivos, cadastrálos ou alterá-los, normalmente os usuários padrão vêm com acesso apenas parcial, pois não há necessidade de alteração dos dados e esta será feita pela administração do sistema. Tabela de Histórico Nesta tabela ficam armazenadas todas as ocorrências de mudança de estado dos dispositivos, nela são registradas a data e a hora da mudança, qual dispositivo sofreu a alteração, a qual cliente pertence o dispositivo e qual foi o tipo de evento registrado. 39 HISTORICO Chave Atributo @ ID DATAHORA # CLIENTE # Tipo de Dado Tamanho Observações Inteiro 10 Chave primária timestamp Inteiro 10 Chave estrangeira de Clientes Chave estrangeira de Descrição de DISPOSITIVO Inteiro 10 Dispositivos EVENTO caractere 1 0 ou 1 O tipo de evento registrado representa se o dispositivo alterou seu status de Desligado para Ligado (1), ou de Ligado para Desligado (0). Tabela Tipos de Dispositivos Nesta Tabela é cadastrado apenas um descritivo dos tipos de dispositivos existentes no sistema, para que, quando forem necessários novos tipos, estes possam ser cadastrados e utilizados sem que haja necessidade de alteração no sistema. TIPO_DISPOSITIVO Chave Atributo Tipo de Dado Tamanho Observações @ ID Inteiro 10 Chave primária DESCRICAO Caractere 50 Atualmente no sistema há quatro tipos de dispositivos cadastrados e utilizáveis: Lâmpadas, Sensores, Alarmes e Sirenes. Tabela Atividades Irregulares Nesta tabela são armazenadas informações a respeito de dispositivos que, se determinadas regras cadastradas acontecerem, por exemplo, acendimento de uma lãmpada de madrugada, o sistema gerará um alerta de atividade irregular. Na tabela são armazenadas o cliente e dispositivo ou tipo de dispositivo que gerará o alarme, a hora inicial e final do acontecimento, a mensagem que será exibida na tela e para qual mudança de estado a atividade se configure como irregular (ex: ligar, desligar ou os dois). 40 ATIVIDADES_IRREGULARES Chave @ # # # Atributo ID ID_CLI ID_DISP ID_TIPO_DISP HORA_INICIO HORA_FIM MENSAGEM ESTADO Tipo de Dado Tamanho Observações Inteiro 10 Chave primária Inteiro 10 Chave Estrangeira Cliente Inteiro 10 Chave Estrangeira Descrição Dispositivos Inteiro 10 Chave Estrangeira Tipo Dispositivos Tempo Tempo Caractere 255 Caractere 1 Apenas (0,1,2) 3.2.3. Interfaces com o Usuário Nesta subseção são apresentadas as duas interfaces com o usuário desenvolvidas para a aplicação. Será dada maior ênfase para a interface para dispositivos móveis, pois na próxima seção que apresentará a aplicação em seu funcionamento, serão exibidas as telas da interface com o usuário para a aplicação para computadores e notebooks. A aplicação para dispositivos móveis tem o intuito de trazer uma visão mais agradável da aplicação web para telas menores, partindo deste princípio, alguns recursos da aplicação para telas maiores foram removidos para que a informação melhor se adequasse na tela e não deixasse a visualização da aplicação poluída, exibindo apenas as informações mais importantes. Isto não significa que a interface para telas grandes não possa ser carregada pelos dispositivos móveis, pelo contrário, se o cliente optar por utilizar a interface padrão para computadores, basta trocar de interface através de um link disponível na aplicação. A maioria dos dispositivos modernos com sistemas operacionais já suportam os recursos mais avançados dos navegadores, então é possível visualizar a interface normal, porém com limitação de tamanho de tela que pode trazer eventuais encômodos. Na Figura 11 pode-se observar a interface para telas maiores. 41 Figura 11. Interface da Aplicação para telas maiores. Na tela da Figura 11, que é a tela inicial da aplicação, percebe-se que são utilizados diversos recursos gráficos com imagens para representar os dispositivos monitorados, por isso a necessidade da criação de uma interface especial para os dispositivos menores, pois com uma tela pequena, os dispositivos ficam dificeis de se observar, e o histórico de eventos e os filtros do histórico ficam de difícil visualização, por estarem com uma letra muito pequena. Levando estes fatos em consideração, decidiu-se recriar a interface para se adequar às telas menores, esta nova interface foi desenvolvida e pode ser visualizada na Figura 12. 42 Figura 12. Tela principal da aplicação para dispositivos móveis. Na Figura 12 percebemos que a interface é diferente de uma aplicação web convencional, se parece e se comporta tal qual uma aplicação para disposivos móveis, com menos informações, botões maiores e simples navegação, nesta versão para dispositivos móvies o usuário tem acesso ao monitoramento dos dispositivos, o histórico e também à alguns relatórios. Na tela de monitoramento, o usuário pode visualizar uma lista de todos os dispositivos monitorados ativos e, ao lado de cada dispositivo, uma miniatura representando o tipo de dispositivo e também seu estado, nesta lista é possível filtrar por nome de dispositivo para ser de mais simples localização. Os dados são atualizados em tempo real sem necessidade de atualização da página. Na Figura 13 é possível visualizar a tela de monitoramento. 43 Figura 13. Tela de monitoramento – Lista de dispositivos. Na tela do histórico, o usuário pode visualizar as últimas 10 ocorrências de mudanças de estado dos dispositivos, trazendo uma lista com o nome do dispositivo, o tipo de evento (ativou ou desativou) e o horário da ocorrência, esta lista também é atualizada em tempo real sem a necessidade de atualização. Na Figura 14 é possível visualizar a tela de histórico da aplicação para dispositivos móveis. 44 Figura 14. Tela de Histórico – Últimas dez ocorrências. Como a tela de histórico mostra apenas os últimos registros da aplicação, é necessária uma funcionalidade para recuperar informações do passado, sobre determinados dispositivos, em determinados horários. Para isso a funcionalidade de histórico foi criada, objetivando recuperar estas informações e trazer relatórios sobre o comportamento dos dispositivos em um determinado intervalo de tempo, a tela de relatórios pode ser visualizada na Figura 15. 45 Figura 15. Tela de Relatórios da aplicação Web 3.3. APLICAÇÃO DE MONITORAMENTO Nesta seção será apresentada a aplicação de monitoramento, desenvolvida na linguagem PHP, instalada em um servidor remoto, que obtêm os dados do banco de dados MYSQL, alimentado pelo Web Service instalado no mesmo servidor. Por se tratar de um sistema que exige autenticação do usuário, ao abrir a aplicação de monitoramento em um navegador de internet, a tela de autenticação é apresentada. A aplicação como um todo utiliza navegação segura (HTTPS), então a partir deste ponto, desde o envio das credenciais do usuário até quando este abandonar o sistema, os dados que transitarão entre o utilizador da aplicação e o servidor estão protegidos por criptografia de alto nível. Na Figura 16 pode ser visualizada a tela de autenticação. 46 Figura 16. Tela de autenticação da aplicação de monitoramento web. Cabe salientar que o sistema de monitoramento é multi-cliente, então diversos clientes podem se conectar, ilimitadamente, à aplicação de monitoramento e receber dados, estando limitados apenas à velocidade de conexão de sua Internet e também à capacidade de processamento do servidor da aplicação. As credenciais são informadas para o cliente pelo e-mail oficial da aplicação no momento do cadastro, e caso a senha seja perdida, por segurança, deve-se solicitar nova senha por e-mail ou entrar em contato diretamente com o administrador de sistema, para garantir a identidade do cliente que está solicitando a nova senha e não se trate de um usuário mal intencionado. 3.3.1. Mapa de Dispositivos Ao se conectar a aplicação, a tela principal é apresentada, nela, as informações de mais destaque estão no mapa de dispositivos. Nesta tela, é 47 apresentada uma planta baixa do local monitorado, cada cliente possui uma planta que é carregada no momento da autenticação. Nesta planta são carregados os dispositivos que estão sendo monitorados pela aplicação web, estes ficam posicionados na planta simulando a sua localização de fato do local monitorado. Há diferentes e intuitivas formas de exibição dos dispositivos conforme o seu tipo (por exemplo, uma lâmpada), bem como seu estado atual, que pode ser ligado ou desligado. Estas informaçoes são carregadas a partir da tabela de descrição dos dispositivos. Quando um dispositivo muda seu estado, o mesmo ocorre com o indicativo na planta baixa no mesmo momento. Isto faz com que o cliente perceba exatamente quando ocorreu a mudança e qual o local aproximado onde tal evento ocorreu, esta forma de visualização permite que o usuário tenha uma visão geral do local monitorado, percebendo facilmente o que está ocorrendo com cada dispositivo e qual o local em que o mesmo se encontra. Estes dados são atualizados de segundo em segundo, conforme dados enviados pelo web service da aplicação local, que fica encarregado pelo envio dos mesmos, um indicativo à direita da tela informa qual a data e a hora da última atualização, para que, caso o web service local perca temporariamente a sua conexão, o cliente perceba que a situação que está vendo no mapa dos dispositivos não é a mais atual, mas sim a do último dado recebido no passado. Porém, ao possuir uma conexão estável a aplicação flui as informações normalmente podendo ser considerada uma aplicação de monitoramento em tempo real. Na Figura 17 pode-se observar um exemplo de mapa de dispositivos com alguns dispositivos pré-cadastrados. 48 Figura 17. Tela inicial da aplicação: Mapa de Dispositivos. 3.3.2. Histórico e Filtros O histórico é outra importante ferramenta presente na tela inicial da aplicação de monitoramento. Em tempo real são atualizadas, segundo a segundo, as últimas atividades envolvendo dispositivos que possuem a opção de gerar histórico marcada em seu registro. No mesmo momento em que chegam os dados do estado atual dos dispositivos no mapa, o histórico também é atualizado, exibindo e registrando os fatos ocorridos para que estes não se percam quando a aplicação for fechada. A lista de histórico exibe os últimos 10 eventos registrados pela aplicação, os dados apresentados são o dispositivo que teve seu estado alterado, qual foi a mudança e também a data e a hora desta mudança. Este recurso conta ainda com opções de filtragem dos dados, para que o cliente possa observar mudanças específicas nos dispositivos, os filtros disponíveis atualmente são: 49 Filtro por Dispositivo; Filtro por Estado. No primeiro é possivel filtrar o histórico para exibir apenas as entradas de um determinado tipo de dispositivo, como por exemplo apenas Lâmpadas, por padrão a opção Todos os Dispositivos vem selecionada. No segundo filtro é possivel filtrar eventos do histórico por estado, por exemplo, apenas quando dispositivos foram ligados ou ativados, por padrão, a opção ―Todos os Estados‖ vem selecionada. Com estes dois filtros é possivel fazer combinações de eventos específicos para selecionar melhor o que o cliente deseja ver. Na Figura 18 é possivel observar o Histórico na aplicação de monitoramento com dados de exemplo. Figura 18. Histórico de eventos da aplicação de monitoramento. 3.3.3. Relatórios A tela de monitoramento mostra um pequeno histórico contendo apenas os últimos acontecimentos do local monitorado. Então é necessário que exista uma funcionalidade que possa recuperar mais informações do passado em qualquer 50 tempo sobre o monitoramento e também que possa filtrar essas ocorrências por dispositivo ou estado para que os dados possam ser mais bem selecionados. Para suprir essa necessidade a funcionalidade de relatórios foi desenvolvida. Na tela de relatórios é escolhido o intervalo de datas e horário inicial e final em que as ocorrências aconteceram, podendo também optar pela data inicial ―desde sempre‖, que representa a data da primeira ocorrência, ou também a data final ―até agora‖ que representa a data da última ocorrência registrada. Ao escolher o intervalo de tempo, é possivel escolher também o histórico de ocorrências de um dispositivo específico, ou pode-se deixar selecionada a opção ―todos‖, que recuperará ocorrências de todos os dispositivos. Por fim, pode ser escolhido o estado das ocorrências, ou seja, se os dispositivos foram ativados ou desativados, por padrão, o relatório recuperará os dois casos. Na Figura 19 é possível observar a tela de formulário do relatório. Figura 19. Formulário para geração de relatórios. Após gerar o relatório enviando o formulário, as ocorrências são exibidas em uma nova tela, como forma de tabela. Uma tabela exemplo de resultados pode ser visualizada na Figura 20. 51 Figura 20. Exemplo de geração do relatório de ocorrências. 3.3.4. Alertas para Atividades Incomuns A identificação de atividades irregulares é uma importante funcionalidade do aplicativo web de monitoramento. O objetivo desta funcionalidade é destacar e identificar possíveis atividades estranhas acontecendo nos locais monitorados, através da analise individual do histórico de ocorrências. Uma situação que pode ser usada para explanar essa funcionalidade seria definir que uma atividade irregular é o alarme de um local monitorado que dispara num horário determinado da madrugada, porém em nem todos os locais isso pode ser considerado irregular, portanto para cada local pode-se definir, através de um cadastro, o que pode ser considerada uma atividade irregular. Para cadastrar uma atividade irregular deve-se acessar o link "Configurações" presente no topo da aplicação web. Acessando o link "Atividades Irregulares" o usuário poderá observar as atividades cadastradas sendo listadas, para serem editadas ou excluídas e tendo também a opção de adicionar novas atividades. Na Figura 21 é possível observar a tela de listagem das atividades irregulares. 52 Figura 21. Listagem de Atividades Irregulares. Para Cadastrar uma nova atividade, deve-se definir qual o dispositivo ou tipo de dispositivo que será alvo de análise das atividades irregulares, qual o horário em que o evento ocorre que fará este ser considerado uma atividade irregular, qual o tipo de evento (Ativar, Desativar ou Ambos), e também uma mensagem personalizada, que será exibida quando a atividade do histórico for validada como irregular. Na Figura 22 pode-se visualizar a tela de cadastro das Atividades Irregulares. Figura 22. Cadastro de atividades irregulares. 53 3.3.5. Painel de Controle: Cadastros O painel de controle da aplicação web, que é última subseção desta seção sobre a aplicação Web e também do Projeto, apresenta as telas administrativas do sistema. Estas telas são utilizadas pelo administrador da aplicação para gerenciar os dispositivos de cada cliente, são basicamente os cadastros de dispositivos e alertas. Para acessar a parte administrativa do sistema, deve-se clicar no link ―Configurações‖ no topo direito da tela, próximo ao link de saída do sistema. Como os dispositivos dos locais monitorados podem ser instalados após a implantação do sistema, ou até mesmo alguns dispositivos fiquem com defeito e não possam mais ser utilizados, é necessário um cadastro dos mesmos para mantê-los sempre atualizados. Na Figura 23 podemos visualizar a tela de listagem dos dispositivos. Figura 23. Listagem dos dispositivos. Na Figura 23, podemos visualizar a lista com todos os dispositivos cadastrados no sistema e algumas informaçoes sobre eles, tais como seu identificador, que é a posição do vetor de dados recebida pelo web service cliente, a descrição do dispositivo, seu tipo e se este gera eventos de histórico ou não. Os dispositivos podem ser basicamente incluídos, editados e excluídos nesta listagem. Para inserir um novo dispositivo, deve-se clicar em ―novo dispositivo‖, que será exibido um formulário em branco para a inserção dos dados do novo 54 dispositivo. Para editar um dispositivo existente, deve-se clicar na descrição do dispositivo, e um formulário contendo os dados atuais do dispositivo será exibido para que as informações sobre ele possam ser modificadas. Por último, se um dispositivo não existe mais, ele pode ser excluído, clicando no botão excluir respectivo ao dispositivo desejado. Na Figura 24 pode-se visualizar a tela de cadastro/edição de um dispositivo. Figura 24. Tela de inserção/edição de um dispositivo. Na Figura 24, pode-se observar a tela de edição do primeiro dispositivo cadastrado, nela são informadas: a identificação do dispositivo (posição do vetor), a descrição do mesmo, qual o tipo de dispositivo, que é uma caixa de seleção dinâmica que carrega as opções cadastradas de tipos de dispositivos, a opção de gerar histórico (sim ou não), se o dispositivo está ativado, ou seja, está aparecendo na tela de monitoramento e a posição do dispositivo na planta. A posição do dispositivo na planta representa o local em que o dispositivo será carregado na planta na aplicação para computadores, esta posição é capturada através de um clique na imagem da planta, ao clicar na posição, um script recupera as coordenadas do clique e adiciona na caixa de texto para que a posição seja gravada no banco de dados, e posteriormente, o dispositivo possa ser carregado na tela de monitoramento. A tela de inserção de um dispositivo é exibida da mesma forma, porém com as informações em branco, para a criação de um novo dispositivo. No painel de 55 controle também há a opção de um cadastro dos tipos de dispositivos, para que, caso um novo tipo seja instalado no local monitorado, este possa ser adicionado à aplicação sem necessidade de manutenção no código. A tela de cadastro de Tipos de Dispositivos é semelhante à tela de Dispositivos, e pode ser visualizada na Figura 25. Figura 25. Tela de listagem de Tipos de Dispositivos. A sistemática para o gerenciamento dos tipos de dispositivos é a mesma da tela de dispositivos, para inserir basta clicar em ―Novo Tipo de Dispositivo‖, para editar deve-se clicar na descrição do dispositivo desejado, e por último, se o objetivo é excluir um tipo de dispositivo não mais usado, basta clicar no botão excluir respectivo. A tela de inserção/edição de um tipo de dispositivo é realmente simples, como o identificador do tipo de dispositivo é gerado automaticamente pelo SGBD, a única informação a ser inserida/editada é a descrição do tipo de dispositivo. Esta tela pode ser visualizada na Figura 26. 56 Figura 26. Inserção/edição de um tipo de dispositivo. Por fim, para completar a parte administrativa dos cadastros, há a tela dos dados do cliente. Esta tela apenas é utilizada para visualizar alguns dados e alterar a senha do cliente, caso seja necessário por alguma questão de segurança. Para utilizá-la basta clicar no link ―Dados do Cliente‖ no menu dos cadastros, digitar a nova senha duas vezes e enviar o formulário, se a senha foi validada corretamente, a senha será substituída. A tela de Dados do Cliente pode ser visualizada na Figura 27. Figura 27. Tela de Dados do Cliente e Alteração de Senha. 57 CONCLUSÃO Com este trabalho pôde-se compreender e aprender com profundidade as tecnologias web existentes e mais utilizadas atualmente, para que o desenvolvimento de um software de monitoramento fosse realizado com as melhores opções possíveis, através de um estudo detalhado. Entre essas tecnologias destacam-se: linguagens de programação, sistemas gerenciadores de banco de dados, servidores de aplicações web, as linguagens utilizadas para se trabalhar com as páginas web (HTML, CSS e Javascript). A oportunidade de trabalhar e estudar com formas de comunicação entre diferentes plataformas, utilizando web services, no aplicativo proposto e desenvolvido propiciou conhecimento de diversas linguagens de programação, e uma forma padronizada e amplamente utilizada para comunicação entre estas plataformas. Utilizando diversas técnicas de segurança, tais como criptografia e certificados digitais, pode-se entender como trabalhar com segurança de dados e aplicações, garantindo que os dados que trafegam entre servidor e cliente não sejam capturados e compreendidos, aumentando significativamente a segurança do sistema. Conhecendo as arquiteturas de sistemas amplamente utilizadas para se desenvolver softwares e escolhendo uma para ser a base de desenvolvimento de um aplicativo web, conclui-se que é necessária a utilização da mesma, para que as funções do aplicativo estejam bem separadas e organizadas em módulos, o que facilita a manutenção e expansão. Com relação aos sistemas gerenciadores de bancos de dados, pode-se perceber a importância de analisar diversos produtos, a fim de escolher não o sistema mais robusto, mas sim o que trará o melhor custo benefício para o sistema, levando em consideração os fatores custo de licença e utilização, robustez e grau de complexidade de utilização. Ao desenvolver o sistema, pode-se testar e validar o funcionamento de cada função e tela, fazendo com que a utilização do mesmo pelos usuários finais se torne mais facilitada e menos suscetível a falhas. Aproveitando os conhecimentos adquiridos ao em tecnologias web, pode-se desenvolver mais de uma interface com o usuário, que visa facilitar o uso dependendo da plataforma em que o mesmo é 58 acessado, visto que um sistema web pode ser acessado também por smartphones e tablets atualmente, visto que os navegadores destes dispositivos evoluíram consideravelmente. Por fim, ao término do desenvolvimento e da validação dos serviços e aplicativos, o sistema se comportou bem e não teve falhas graves, cumprindo o que lhe foi proposto. O monitoramento online via internet facilita e auxilia muito os utilizadores da tecnologia, pois não necessitam mais estar no local monitorado para consultar os eventos ocorridos ou a situação atual do local, isto pode ser realizado através de um equipamento com navegador instalado. A interface que foi melhorada consideravelmente, juntamente com as funções agregadas ao sistema, que antes não existiam, tais como o mapa de dispositivos e os relatórios, abriram um leque de possibilidades para visualização e consulta de eventos com relação ao monitoramento e ao histórico de eventos. 59 REFERÊNCIAS BIBLIOGRÁFICAS BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The UML Modeling Language User Guide. 2nd Edition. [S.l]. Addison-Wesley. 1999. CONVERSE, T.; PARK J.; MORGAN C. PHP 5 e MySQL A Bíblia. [S.l.:S.n]. 4 p. 2004. DALL'OGLIO, P. PHP Programando com Orientação a Objetos: Inclui Design Patterns. 1 ed. São Paulo: Novatec, 576 p. 2007. HILLARD, R. IEEE-std-1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems. [S.l]. IEEE, http://standards.ieee.org/. 2000. KORTH, H.F.; SILBERCHATZ, A.; S. SUDARSHAN. Sistema de bancos de dados. São Paulo — SP, Brasil: Makron Books. 1999. MICROSOFT BRASIL. O que é Criptografia? Disponível em: <http://windows.microsoft.com/pt-BR/windows7/What-is-encryption>. Acesso em 16 de setembro 2012. MICROSOFT GUIDE. Microsoft Application Architecture Guide. 2nd Edition. 2010. Disponível em: <http://www.microsoft.com/architectureguide>. Acessado em: 26 agosto de 2012. MySQL. Why MySQL. Disponível Acessado em 03 de setembro 2012. em: <http://www.mysql.com/why-mysql/>. PHP. PHP White Paper. The Irish PHP User Group (2008). Disponível em: <http://www.php.ie/f/PHPWhitePaper.pdf>. Acessado em 26 de agosto 2012. 60 REZENDE, P. O que é um Certificado Digital? (2005). Disponível on-line em: <http://www.cic.unb.br/~pedro/trabs/certdigital.html>. Acesso em 17 de setembro 2012. SONERA PLAZA. Web Services White Paper (2002). Disponível em: <http://www.medialab.sonera.fi/workspace/WebServicesWhitePaper.pdf>. Acessado em 05 de setembro 2012. SCHERER, F. L. Desenvolvimento de um Sistema de Automação Predial para Pequenas Edificações (2010). IJUÍ – RS. 2010. W3C. W3C Consortium. Cascading Style Sheets (CSS). Recommendation 7 June 2011. Disponível em: <http://www.w3.org/TR/CSS21/>. Acessado em 10 de setembro 2012. W3C. W3C Consortium. HTML 4.01 Specification. Recommendation 24 December 1999. Disponível em: < http://www.w3.org/TR/REC-html40/>. Acessado em: 10 de setembro 2012. W3SCHOOLS. W3C Consortium. Javascript Tutorial. Disponível em: <http://www.w3schools.com/js/js_intro.asp>. Acessado em 10 de setembro 2012. WhichSSL. SSL Cert Comparison, SSL Certification Price Comparison. Disponível em: <http://www.whichssl.com/comparisons/price.html>. Acesso em 17 de setembro 2012.
