Modelo de TCC para o Curso de Ciência da Computação da …siaibib01.univali.br/pdf/Matheus Weber...

UNIVERSIDADE DO VALE DO ITAJAÍCENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

OCTOPUS: FERRAMENTA DE CÓDIGO ABERTO PARA GERAÇÃO DE RELATÓRIOS PARA O SERVIDOR PROXY SQUID

por

Matheus Weber da Conceição

Itajaí (SC), novembro de 2012

UNIVERSIDADE DO VALE DO ITAJAÍCENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

OCTOPUS: FERRAMENTA DE CÓDIGO ABERTO PARA GERAÇÃO DE RELATÓRIOS PARA O SERVIDOR PROXY SQUID

Área de Ciência da Computação

por

Matheus Weber da Conceição

Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação.Orientador: Fabrício Bortoluzzi, M.Sc.

Itajaí (SC), novembro de 2012

Aos meus pais.

AGRADECIMENTOS

Agradeço primeiramente aos meus pais pelo grande apoio e suporte nessa etapa da

minha vida.

Agradeço também aos amigos que foram feitos durante o curso possibilitando uma

grande troca de conhecimento e apoio necessário, em especial aos amigos Alexandre Corsi,

Elcio Arthur Cardoso, Paulo Eduardo Krieger e Marcus Simas.

Agradeço também a todos os docentes que participaram da minha evolução de

conhecimento, em especial ao Fabricio Bortoluzzi pelo apoio e orientação necessária no

desenvolvimento deste trabalho.

Obrigado.

“No pain, no gain.”

RESUMO

CONCEIÇÃO, Matheus W. Octopus: ferramenta de código aberto para geração de relatórios para o servidor proxy Squid. Itajaí, 2012. 84. Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2012.

A partir do momento em que o acesso à Internet em uma organização se torna um recurso crítico, de alta dependência, faz-se necessário o uso de ferramentas de monitoramento por parte dos gestores para auxiliá-los nas tomadas de decisões no que tange a definição de políticas de uso da Internet a fim de evitar abusos. A otimização do uso deste recurso de comunicação e a identificação do perfil de uso do protocolo de navegação web, gera uma boa fundamentação para as decisões futuras. Para isso, é importante que a ferramenta de monitoramento seja de fácil e ágil utilização, sendo flexível na busca e na visualização das informações desejadas. Este trabalho projetou e implementou o Octopus: ferramenta de código aberto para a geração de relatórios para o servidor proxy Squid. Com este fim, foi realizado um trabalho de pesquisa para fundamentar a teoria necessária e definir as tecnologias a serem utilizadas. Em seguida, foi elaborado o projeto de engenharia de software da ferramenta, levantando requisitos necessários, diagramas de modelo de classes, diagramas de casos de uso e a estrutura do banco de dados. Em seguida, realizou-se a etapa de implementação da ferramenta com base no projeto realizado. No fim do processo de desenvolvimento, realizou-se uma validação da ferramenta com alguns arquivos de registro de acessos do Squid coletados anteriormente, atestando-se então a conformidade da ferramenta com o projeto.

Palavras-chave: Gerência de Redes. Proxy. Squid.

ABSTRACT

When the Internet access of a company became critical, it is necessary that the company leaders consider the use of monitoring tools to help them to take the best decision in terms of Internet use policy to avoid abuse from users. Optimizing the use of that valuable communication resource and identifying the web use profile, should result in a wide background knowledge for future decisions. Then, is important to use a monitoring tool that is easy, fast and flexible in data searching and in the visualization of the information. This work have designed and developed the Octopus, an open source reports generator tool for Squid proxy server. With this aim, a literature search was first done to get all the necessary theory background, which was followed by the definition of the technology that was used in the tool specification step. Then, the software engineering project of the tool was elaborated and all the requirements, class diagrams, use case diagrams and database models were obtained. In the next stage of the work, the tool was implemented in the bases of the engineering project, followed by the validation stage, which allowed the validation of the tool with some previously collected Squid access data files, which attested the conformity of the tool with the project specifications.

Keywords: Network Management. Proxy. Squid.

LISTA DE FIGURAS

Figura 1. Hierarquia das camadas da Gerência de Rede...........................................................18Figura 2. Funcionamento de um servidor proxy.......................................................................19Figura 3. Funcionamento do servidor proxy Squid em uma rede.............................................21Figura 4. Metáfora visual para visualização dos dados de acessos do Squid...........................26Figura 5. Captura de tela da ferramenta SARG na página inicial de relatórios........................30Figura 6. Captura de tela da ferramenta SARG no relatório de um usuário.............................31Figura 7. Captura de tela da ferramenta Calamaris no início do relatório................................33Figura 8. Captura de tela da ferramenta Free-SA na tela de escolha dos períodos de tempo disponíveis ..............................................................................................................................35Figura 9. Captura de tela da ferramenta Free-SA com os tipos de relatórios gerados..............35Figura 10. Captura de tela da ferramenta Free-SA na página de relatório de domínios acessados de um usuário...........................................................................................................36Figura 11. Captura de tela da ferramenta Redline Internet Access Monitor.............................38Figura 12. Captura de tela da ferramenta Redline Internet Access Monitor com o relatório de uso diário exportado em HTML................................................................................................39Figura 13. Captura de tela da ferramenta Firewall Analyzer na página inicial do relatório.....40Figura 14. Captura de tela da ferramenta Firewall Analyzer na página de relatório de um usuário ..............................................................................................................................41Figura 15. Captura de tela da ferramenta Sawmill na página inicial........................................43Figura 16. Captura de tela da ferramenta Sawmill na tela de relatório de acessos...................44Figura 17. Diagrama do modelo de casos de uso......................................................................49Figura 18. Diagrama do modelo de classes do módulo coletor................................................51Figura 19. Diagrama de modelo de classes do módulo interface de visualização....................52Figura 20. Diagrama modelo entidade relacionamento (modelo ER).......................................53Figura 21. Protótipo de tela do relatório bidimensional............................................................54Figura 22. Protótipo de tela do relatório tridimensional...........................................................55Figura 23. Classe “SquidAccessLogRequest” do módulo coletor............................................56Figura 24. Classe "SquidLogFile" do módulo coletor (método "parse" recolhido)..................56Figura 25. Captura de tela do formulário de autenticação do sistema......................................59Figura 26. Captura de tela do relatório bidimensional com destaque para os parâmetros........60Figura 27. Captura de tela do relatório bidimensional com destaque ao relatório....................61Figura 28. Captura de tela do relatório tridimensional com destaque para os parâmetros.......62Figura 29. Captura de tela do relatório tridimensional com destaque para o relatório tridimensional............................................................................................................................63Figura 30. Captura de tela da listagem de usuários...................................................................64Figura 31. Captura da tela inicial da ferramenta juntamente com a listagem de consultas salvas

65Figura 32. Captura de tela no número total de resultados no banco de dados..........................67Figura 33. Teste 2 - Parâmetros do relatório bidimensional.....................................................68Figura 34. Teste 2 - Relatório bidimensional de acessos de um usuário específico.................69Figura 35. Teste 3 - Parâmetros do relatório tridimensional.....................................................70Figura 36. Teste 3 - Relatório dos maiores arquivos baixados.................................................71

LISTA DE QUADROS

Quadro 1. Exemplo de arquivo com um registro de acesso do Squid......................................22Quadro 2. Comparativo de ferramentas similares.....................................................................29Quadro 3. Resultado da execução do módulo coletor...............................................................66

LISTA DE ABREVIATURAS E SIGLAS

ACL Access Control ListDDL Data Definition LanguageDML Data Manipulation LanguageDRL Data Representation LanguageER Entity-relationshipHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIP Internet ProtocolLDAP Lightweight Directory Access ProtocolOLAP Online Analytical ProcessingOSI Open Systems InterconnectionPHP PHP: Hypertext PreprocessorSARG Squid Analysis Report GeneratorSGBD Sistema de Gerenciamento de Banco de DadosSQL Structured Query LanguageTCP Transmission Control ProtocolTTC Trabalho Técnico-científico de Conclusão de CursoUML Unified Modeling LanguageUNIVALI Universidade do Vale do ItajaíURI Uniform Resource IdentifierURL Uniform Resource LocatorW3C World Wide Web Consortium

SUMÁRIO

1 INTRODUÇÃO.............................................................................xii1.1 PROBLEMATIZAÇÃO..........................................................................XIV1.1.1 Formulação do Problema......................................................................xiv1.1.2 Solução Proposta....................................................................................xiv1.2 OBJETIVOS.............................................................................................XIV1.2.1 Objetivo Geral........................................................................................xiv1.2.2 Objetivos Específicos...............................................................................xv1.3 METODOLOGIA......................................................................................XV1.4 ESTRUTURA DO TRABALHO............................................................XVI2 FUNDAMENTAÇÃO TEÓRICA...............................................172.1 GERÊNCIA DE REDES.............................................................................172.2 PROXY.........................................................................................................192.3 SQUID..........................................................................................................202.3.1 Registro das informações de acessos......................................................212.3.2 Fonte do registro de informações de acesso..........................................242.4 OLAP (ONLINE ANALYTICAL PROCESSING)..................................252.5 POSTGRESQL............................................................................................272.6 FERRAMENTAS SIMILARES.................................................................282.6.1 SARG........................................................................................................302.6.2 Calamaris.................................................................................................322.6.3 Free-SA.....................................................................................................342.6.4 Redline Internet Access Monitor...........................................................372.6.5 Firewall Analyzer....................................................................................402.6.6 Sawmill.....................................................................................................423 DESENVOLVIMENTO...............................................................463.1 MODELAGEM DO SOFTWARE.............................................................463.1.1 Levantamento de requisitos....................................................................473.1.2 Modelo de casos de uso............................................................................483.1.3 Modelo de classes.....................................................................................503.1.4 Diagrama entidade relacionamento (modelo ER)................................523.1.5 Protótipo de tela.......................................................................................533.2 IMPLEMENTAÇÃO DA FERRAMENTA..............................................553.2.1 Implementação do módulo coletor.........................................................563.2.2 Implementação do módulo de interface de visualização......................573.3 TESTES FINAIS DA FERRAMENTA.....................................................653.3.1 Teste 1: Número requisições coletadas..................................................653.3.2 Teste 2: Verificar os sites acessados por um endereço IP (usuário) durante um período de tempo..........................................................................673.3.3 Teste 3: Verificar os maiores arquivos baixados..................................69

4 CONCLUSÕES.............................................................................724.1 TRABALHOS FUTUROS..........................................................................73

1 INTRODUÇÃO

Segundo Ricci e Mendonça (2006), cada vez mais o acesso à Internet em uma

organização se torna um recurso crítico, mais acessado e evidente. Com isso, adquire-se

inúmeros benefícios, como por exemplo a informação em tempo real, comunicação mundial a

baixo custo, possibilidade de contatos comerciais com o mundo todo. Porém, juntamente aos

benefícios, traz-se também os riscos às organizações. Riscos estes que podem variar da

segurança da informação, à produtividade dos funcionários.

Em uma das frentes de risco mencionadas anteriormente, o autor sugere a aplicação de

uma ferramenta de auditoria de tráfego web, sendo no caso, um servidor proxy web, mais

especificamente, o Squid. Podendo com isto, aplicar políticas de rede, como o bloqueio de

algumas páginas, além é claro de realizar o monitoramento dos acessos. Dessa maneira pode-

se diminuir os abusos e otimizar este recurso de comunicação.

“O conceito de Proxy refere-se a um software que atua como gateway de aplicação

entre o cliente e o serviço a ser acessado, interpretando as requisições e repassando-as ao

servidor de destino.” (RICCI; MENDONÇA, 2006, p. 1).

Wessels (2004) comenta que o Squid é um servidor proxy do tipo web de código

aberto bastante popular, que também oferece funcionalidade de cache de conteúdo. Wessels

(2004) ressalta alguns usos do Squid:

• Economizar banda do provedor de Internet enquanto se navega na web;

• Diminuir o tempo que uma página leva para carregar;

• Coletar estatísticas sobre o tráfego web da rede;

• Bloquear o acesso de usuários à sites inapropriados conforme a política de uso da

empresa;

• Garantir que apenas usuários autorizados possam navegar na Internet.

Na tentativa de melhorar a visualização das informações, pode-se utilizar o conceito

de OLAP (Online Analytical Processing). Segundo Thomsen (2002), OLAP define-se como

sendo um sistema de informação multidimensional. O conceito é associado à noção de

múltiplas dimensões hierárquicas que podem ser utilizados por todos para a obtenção de

informações, como o próprio autor relata, desde em uma escala atômica (informação mais

detalhada), como também em uma escala galáctica (informação menos detalhada). Ou seja, a

visão das informações se dá em um mundo multidimensional e com diversos níveis.

Com isso, este trabalho tem a pretensão de formalizar o desenvolvimento do Octopus:

ferramenta de código aberto para a geração de relatório do servidor proxy Squid.

1.1 PROBLEMATIZAÇÃO

A problematização do trabalho será discutida nas próximas duas subseções, que

abordarão a formulação do problema e a solução proposta desenvolvida.

1.1.1 FORMULAÇÃO DO PROBLEMA

No cenário de softwares de código-fonte aberto, há uma grande carência de

ferramentas modernas voltadas à auditoria da navegação web dos usuários através de um

servidor proxy Squid. Este problema se evidencia em cenários de redes menores, como uma

empresa de pequeno ou médio porte, onde a necessidade de auditoria da navegação web

existe, porém o orçamento disponível não é suficiente para justificar a adoção de uma

ferramenta proprietário de alto custo.

1.1.2 SOLUÇÃO PROPOSTA

Este TTC desenvolveu um software que tem por finalidade permitir ao gestor da rede

visualizar detalhes de uso do tráfego web, podendo identificar os perfis de uso da rede por

parte dos funcionários e então melhorar a fundamentação de tomadas de decisões estratégicas,

como por exemplo, o fornecedor de Internet, a largura de banda contratada para a Internet, as

políticas de uso da rede, bem como a detecção de mau uso da Internet por parte dos usuários.

Para ser possível o fornecimento destes dados, a ferramenta tem por finalidade gerar

relatórios dinâmicos contendo diversas informações de acesso à sites capturadas do servidor

proxy Squid. Além disso, os relatórios contarão com diversos filtros para facilitar a

visualização da informação.

1.2 OBJETIVOS

Os objetivos deste Trabalho Técnico-científico de Conclusão de Curso estão separados

em um objetivo geral e seis objetivos específicos.

1.2.1 OBJETIVO GERAL

O objetivo geral é fundamentar e desenvolver o Octopus: sistema de análise e

auditoria do servidor proxy Squid.

1.2.2 OBJETIVOS ESPECÍFICOS

Os objetivos específicos são:

• Fundamentar a gerência de redes em geral e o recurso de proxy em específico;

• Especificar os objetos de análise e auditoria desejados para o Octopus;

• Modelar o Octopus;

• Desenvolver o Octopus;

• Testar e aferir o funcionamento do Octopus em um conjunto de logs do Squid,

comparando-o com o SARG; e

• Documentar e divulgar este TTC.

1.3 METODOLOGIA

Este trabalho utilizou-se de uma metodologia baseada nos seguintes itens:

• Fundamentação : nesta etapa foi realizado um estudo de toda a fundamentação

teórica necessária para desenvolver o trabalho, foi utilizada principalmente fontes

de livros;

• Especificação : nesta etapa foi levantado os requisitos dos objetos de análise e

recursos desejados para a ferramenta proposta;

• Modelagem : nesta etapa foi realizada toda a modelagem do projeto de engenharia

de software da ferramenta proposta utilizando como metodologia de modelagem a

UML (Unified Modeling Language);

• Implementação : etapa onde o software de fato foi implementado, tendo como base

as especificações e modelagem;

• Testes : etapa que trabalha junto com a etapa de implementação, pois basicamente

responde pelos testes realizados a cada parte da implementação;

• Validação final : ao final da implementação do software, foi executada uma

validação final do software utilizando-se diversos arquivos de registro de acessos

do Squid que foram coletados; e

• Texto : etapa onde documentou-se as etapas anteriores no documento do TTC e a

finalização geral do texto.

1.4 ESTRUTURA DO TRABALHO

Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução,

apresentou uma visão geral do trabalho. No Capítulo 2, Fundamentação Teórica, é

apresentada uma revisão bibliográfica e uma análise sobre os aspectos da Gerência de Redes,

além disso, será explicado o conceito de servidor Proxy. Neste capítulo também é feita uma

descrição do servidor proxy Squid onde é apresentado o seu funcionamento básico e

características. Além disso, o conceito de OLAP também foi explorado. Em seguida, são

apresentadas as ferramentas similares à ferramenta desenvolvida.

O Capítulo 3 apresenta o projeto da ferramenta desenvolvida, incluindo sua

especificação e a sua modelagem UML. O capítulo também discute a implementação dos

módulos da ferramenta além de no final apresentar os testes finais de conformidade da

ferramenta com o que foi proposto.

Concluindo, no Capítulo 4, apresentam-se a conclusão do trabalho, onde são

abordados principalmente os resultados alcançados, considerações gerais e os trabalhos

futuros.

17

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo, é apresentada uma revisão bibliográfica e uma análise sobre os

aspectos da Gerência de Redes, tais como a sua definição e algumas das suas subdivisões.

Além disso, será revisado o conceito de servidor Proxy, onde será descrito seu

funcionamento. Neste capítulo também é feita uma descrição do servidor proxy Squid onde

apresenta-se suas características. Em seguida, explora-se o conceito de OLAP, útil na

elaboração dos relatórios da ferramenta. No final do capítulo, apresenta-se uma comparação

das ferramentas similares à ferramenta projetada e implementada neste trabalho.

2.1 GERÊNCIA DE REDES

Segundo McCabe (2007), A gerência de redes consiste no conjunto de ações para

controlar, planejar, alocar, implantar, coordenar e monitorar recursos de uma rede. Uma

gerência de rede adequada é fundamental para o sucesso de qualquer rede.

Para Kurose e Keith (2006), uma rede é composta por diversos ativos complexos

(hardware e software), sejam eles componentes físicos, enlaces, protocolos e outros, que

interagem entre si. Todos esses componentes demandam uma organização e uma gerência

para seu correto funcionamento. Até porque, como menciona McCabe (2007), hoje e no

futuro, redes constituem um recurso em que sua integridade é crítica e deve ser mensurada e

verificada.

Segundo Lopes, Sauve e Nicolletti (2003), o objetivo da gerência de redes é monitorar

e controlar os elementos da rede (sejam eles físicos ou lógicos), garantindo um certo nível de

qualidade de serviço. Para o cumprimento desta tarefa, os gerentes de redes são geralmente

auxiliados por um sistema de gerência de redes. Um sistema de gerência de rede pode ser

definido como uma coleção de ferramentas integradas para a monitoração e controle da rede .

Pode-se comparar essa questão com uma usina de geração de energia elétrica (de

modo geral), onde há um sistema complexo com diversos componentes integrados entre si e

que devem ser monitorados, gerenciados e controlados por um administrador em uma sala de

controle, onde há mostradores, medidores e lâmpadas monitorando o estado (temperatura,

pressão, vazão) de válvulas, tubulações, vasos, entre outros. Esses dispositivos permitem que

o operador monitore os muitos componentes da planta e permite reagir reativamente aos

alertas de problemas iminentes. (KUROSE; KEITH, 2006).

18

A sala de monitoramento e controle de uma rede, segundo Kusore e Keith (2006), é

comumente chamada de NOC (Network operations center – Centro de operações de rede). É o

local onde é tomado conta da parte de operações da gerência de rede, é onde é feito todo o

monitoramento e controle de uma rede.

McCabe (2007) separa a gerência de redes em múltiplas camadas, como demonstrado

na Figura 1 e descrito abaixo:

• Camada de gerência de negócio : Gerência dos aspectos de negócio de uma rede –

por exemplo, gerência dos orçamentos e recursos, planejamento e políticas;

• Camada de gerência de serviço : Gerência dos serviços oferecidos aos usuários –

por exemplo, gerência de largura de banda, armazenamento de dados,

disponibilidade de aplicações;

• Camada de gerência de rede : Gerência de todos os ativos de redes em toda a rede;

• Camada de gerência de ativos de rede : Gerência de uma coleção de ativos de rede

similares – por exemplo, roteadores de acesso, switchs de distribuição;

• Camada de gerência de dispositivo : Gerência individual de um ativo de rede –

por exemplo, um único roteador, switch, hub.

Figura 1. Hierarquia das camadas da Gerência de Rede

Fonte: Adaptado de McCabe (2007).

19

Essa estrutura de camadas apresentadas na Figura 1, consiste na camada mais abstrata

no topo da hierarquia (camada de gerência de negócio) e a mais específica (camada de

gerência de dispositivo) está no final.

As duas primeiras camadas (gerência de negócio e gerência de serviço), serão as

principais camadas abordadas para este trabalho, já que a aplicação a ser desenvolvida neste

trabalho será um proxy que visa permitir que se audite as políticas de rede determinadas

(camada de gerência de negócios) para o serviço de navegação web (camada de gerência de

serviço). Além disso, também permite coletar o padrão de comportamento da navegação web

assim fundamentando melhor as estratégias futuras de melhoramento da rede.

2.2 PROXY

Segundo Ricci e Mendonça (2006), o servidor proxy pode ser definido como um

software que atua como gateway de aplicação entre o cliente e o serviço que é acessado, como

exemplificado na Figura 2.

Como apresentado na Figura 2, o servidor proxy intercepta as requisições do cliente

enviadas ao servidor, as interpreta e então repassa as requisições ao servidor de destino

responsável pelo serviço a ser acessado, realizando o mesmo procedimento com a resposta.

Aprofundando-se mais no servidor proxy, Ricci e Mendonça (2006) ressaltam que o

servidor proxy é capaz de analisar os pacotes de rede na camada de aplicação, ou camada 7,

do modelo OSI (Open Systems Interconnection). Dessa forma é possível oferecer uma grande

flexibilidade pois permite que o tráfego de dados de um serviço possa ser analisado e assim

permitindo diversos tipos de ações, como por exemplo a aplicação de filtros de bloqueio, ou

então o registro dos dados trafegados (para fins estatísticos e/ou de monitoramento, por

exemplo).

Figura 2. Funcionamento de um servidor proxy

20

O foco deste TTC é dado a um servidor proxy para o protocolo HTTP (Hypertext

Transfer Protocol), ou seja, tráfego web, mais especificamente o servidor proxy Squid.

2.3 SQUID

O Squid é um servidor proxy de código-fonte aberto onde seu projeto iniciou-se em

1996 e utilizou-se como base o código-fonte do software Harvest cache project (WESSELS,

2004).

Wessels (2004) ressalta ainda que o Squid é um servidor proxy bastante popular e

oferece também a funcionalidade de cache de conteúdo. Wessels (2004) destaca alguns dos

principais usos do Squid:

• Economizar banda do provedor de Internet enquanto se navega na web;

• Diminuir o tempo que uma página leva para carregar;

• Coletar estatísticas sobre o tráfego web da rede;

• Bloquear o acesso dos usuários à páginas inapropriadas conforme a política de

uso da empresa;

• Garantir que apenas usuários autorizados possam navegar na Internet.

O fluxo básico do tráfego da rede passando pelo Squid descrito por Wessels (2004) é

exemplificado na Figura 3.

21

O autor descreve o fluxo básico de intermediação do Squid nas transações web da

seguinte maneira: o Squid aceita uma conexão do cliente, processa a requisição e encaminha a

requisição para o servidor de destino original.

Durante esse processo, segundo Wessels (2004), uma requisição pode ter suas

informações salvas em um arquivo de registro de acessos, assim como a requisição pode

também ser rejeitada ou até mesmo modificada antes do encaminhamento para o servidor de

destino original.

O servidor proxy Squid é o software foco deste TTC. A ferramenta produto deste TTC

extrairá do Squid as requisições de acesso de usuários aos sites e suas informações.

2.3.1 REGISTRO DAS INFORMAÇÕES DE ACESSOS

Segundo Wessels (2004), o Squid armazena as informações chaves de acesso dos

usuários aos sites em um arquivo chamado “access.log”. Esse arquivo é baseado por linhas,

ou seja, cada linha corresponde à uma requisição HTTP de um cliente.

O autor explica que o formato padrão do arquivo de registro de acessos do Squid

consiste em dez campos. A cada requisição feita por um cliente à um servidor, é armazenada

no arquivo “access.log” uma linha contendo dez campos com as informações chave a respeito

da conexão.

Figura 3. Funcionamento do servidor proxy Squid em uma rede

22

Pode-se ver no Quadro 1 um arquivo de exemplo com quatro requisições. Nas linhas

longas, foram inseridas uma ou mais quebras de linhas de acordo com a necessidade, e o

início das linhas cortadas foram recuadas.

Como observado, tem-se uma linha representando cada requisição. A linha é divida

em dez campos que contém os principais atributos da respectiva requisição, conforme

descreve Wessels (2004), estes atributos são listados como:

• timestamp;

• response time;

• client address;

• result/status codes;

• transfer size;

• request method;

• URI;

• client identity;

• peering code/peerhost; e

• content type.

Estes atributos são descritos por Wessels (2004) nas subseções a seguir.

1066037222.011 34173 166.181.33.71 TCP_MISS/200 559 GET http://coursesites.blackboard.com/service/collab/../1090/ - DIRECT/216.200.107.101 application/octet-stream

Quadro 1. Exemplo de arquivo com um registro de acesso do Squid

23

Atributo “timestamp”

Este atributo expressa a data e hora da finalização da requisição no formato timestamp,

ou seja, representa o número de segundos desde o surgimento do Unix (01/01/1970 00:00:00

UTC) juntamente com os milissegundos, representado pelos três últimos números após o

ponto, exemplo: “1066037222.011”.

Atributo “response time”

Atributo que representa o tempo total de duração, em milissegundos, de

processamento de uma determinada transação HTTP. O contador é iniciado quando o Squid

recebe a requisição HTTP e é congelado quando a requisição é entregada completamente.

Atributo “client address”

Atributo que representa o endereço IP (Internet Protocol) do cliente.

Atributo “result/status codes”

Este campo consiste em dois atributos divididos por uma barra (caractere “/”). O

primeiro atributo determina o protocolo e o resultado da transação (exemplo: “TCP_HIT”,

“TCP_MISS”). O segundo atributo corresponde ao código de resposta da requisição HTTP

(exemplo, “200” para sucesso, “404” para arquivo não encontrado).

Atributo “transfer size”

Atributo que indica o número de bytes transferidos para o cliente. De maneira mais

específica, é o valor em bytes que o Squid informa à pilha TCP/IP (Transmission Control

Protocol / Internet Protocol) para o envio ao cliente.

Atributo “request method”

Atributo que representa o método HTTP da requisição (exemplo, “GET”, “POST”).

Atributo “URI”

Atributo que indica o endereço web da requisição HTTP (exemplo,

“http://www.squid-cache.org/intro/who.html”, “http://www.univali.br”).

24

Atributo “client identity”

Atributo que indica o nome de usuário quando o recurso de autenticação de usuários

está ativado no Squid, caso contrário é utilizado um traço (caractere “-”).

Atributo “peering code/peerhost”

Campo que apresenta dois atributos divididos por uma barra (caractere “/”). Estes

atributos só tem relevância quando o conteúdo a ser buscado não foi encontrado no cache

local, então o conteúdo é buscado em outro servidor proxy irmão (caso exista), ou então

diretamente do servidor de origem. Caso o conteúdo tenha sido buscado no cache local, o

campo em questão apresentará seu conteúdo como “NONE/-”.

O primeiro atributo indica como o servidor com o conteúdo foi buscado (exemplo,

“DIRECT”, indicando que o conteúdo foi buscado diretamente do servidor de origem). Já o

segundo atributo indica o endereço IP do servidor onde foi buscado o conteúdo.

Atributo “content type”

Atributo que representa o tipo de conteúdo que foi buscado. Esta informação é obtida

pelo Squid obtendo-se o valor do atributo “Content-Type” do cabeçalho HTTP da requisição,

caso este atributo do cabeçalho não seja encontrado, o Squid utilizará um hífen (caractere “-”)

no campo em questão.

2.3.2 FONTE DO REGISTRO DE INFORMAÇÕES DE ACESSO

Foi utilizada uma base de registros de acessos do Squid obtidos em uma instalação

deste proxy na empresa onde o autor trabalha. Trata-se de uma leitura dos últimos meses de

acessos à Internet contendo o uso diverso por aproximadamente cinquenta pessoas, sendo as

mesmas de diversos setores da empresa, como diretoria, comercial, suporte, infraestrutura,

desenvolvimento, qualidade, recursos humanos e financeiro.

Os dados específicos capazes de identificar usuários de forma única foram mascarados

com representações equivalentes dos mesmos, assim protegendo a privacidade dos usuários.

25

2.4 OLAP (ONLINE ANALYTICAL PROCESSING)

Thomsen (2002) define OLAP como sendo um sistema de informação

multidimensional. O autor associa o conceito de OLAP à noção de múltiplas dimensões

hierárquicas que podem ser utilizados por todos para a obtenção de informações, desde em

uma escala atômica (informação mais detalhada), como também em uma escala galáctica

(informação menos detalhada). Ou seja, a visão das informações se dá em um mundo

multidimensional e com diversos níveis.

O autor ainda aponta que o termo OLAP possui várias abordagens já que seus

elementos são manifestáveis em diversas camadas de tecnologia, que vão desde o

armazenamento e acesso até camadas de linguagem. Pode-se então discutir sobre conceitos

OLAP, linguagens OLAP, camadas de produto OLAP e produtos OLAP completos.

Os conceitos de OLAP, ainda segundo o autor, agregam as noções de múltiplas

dimensões, níveis e escalas. Nas linguagens OLAP, onde inclui-se linguagens formais como

DDL (Data Definition Language), DML (Data Manipulation Language), DRL (Data

Representation Language) e seus analisadores associados são utilizados para qualquer

modelagem descritiva transacional ou de suporte à tomada de decisão. As camadas de produto

do OLAP residem-se normalmente em cima de banco de dados relacionais, onde a partir de

determinadas combinações, geram SQL (Structured Query Language) como saída. Nesta

questão, o banco de dados fica responsável pelo armazenamento e o acesso aos dados. Já os

produtos OLAP completos que incluem métodos de acesso e armazenamento, são otimizados

para cálculos rápidos e acesso a dados, assim usando-se principalmente para modelagem

descritiva de dados.

Thomsen (2002) exemplifica o uso do formato de visualização de dados bidimensional

como sendo útil para qualquer tipo de controle, por exemplo, horas de funcionários, custo por

departamento. Neste caso, a variável de dimensão são dispostas nas colunas (horas

trabalhadas, horas extras) e outra dimensão identificadora (também conhecida como chave ou

localizadora) de funcionários que estarão dispostos nas linhas.

Em cima disso, pode-se adicionar uma terceira dimensão, que é chamada de produto.

Consequentemente, a visualização dos dados acaba se tornando um cubo. Aplicando-se esse

26

conceito à realidade proposta neste TTC em questão, pôde-se observar na Figura 4 a metáfora

visual do que seriam os dados apresentados para o usuário.

Pode-se observar então na Figura 4 as três dimensões juntas formando um cubo, sendo

a primeira dimensão atribuiu-se variáveis que representam alguns dos atributos do registro de

acessos do Squid. Na segunda dimensão atribuiu-se os produtos, que no caso em questão está

utilizando-se do atributo de endereço IP do usuário da rede. Na terceira dimensão atribuiu-se

o tempo, que no caso em questão está agrupado em meses.

No entanto, o autor ressalta que devido a limitação da tela do computador – a tela do

computador é bidimensional – é necessário adaptar a forma de apresentar as informações na

tela. Devido a esta limitação, divide-se o cubo em fatias, onde cada fatia será uma página

(uma dimensão) e então dentro de cada página aparecerá mais duas dimensões com as

informações de acordo com a dimensão da página.

Dessa forma, o usuário que utilizará a ferramenta desenvolvida neste TTC poderá

definir os atributos coletados do registro de acessos do Squid em relatórios de duas ou três

dimensões.

Figura 4. Metáfora visual para visualização dos dados de acessos do Squid

Fonte: Adaptado de Thomsen (2002).

27

2.5 POSTGRESQL

Riggs e Krosing (2010) descrevem o PostgreSQL como um avançado servidor de

banco de dados SQL de código-fonte aberto, disponível em uma grande gama de plataformas.

Além disso, o PostgreSQL é conhecido por ser um banco de dados que apresenta alta

disponibilidade, requisitando pouca manutenção e resultando em um baixo custo total de

propriedade.

O autor menciona ainda que o PostgreSQL possui uma grande gama de recursos

avançados que foram desenvolvidos ao longo de vinte anos de desenvolvimento contínuo. O

PostgreSQL foi originalmente desenvolvido pelo grupo de pesquisa em banco de dados da

Universidade da Califórnia e agora é desenvolvido por um grande time de colaboradores.

Muito desse colaboradores possuem trabalhos em tempo integral relacionados aos

PostgreSQL, trabalhando como desenvolvedores, designers, administradores de banco de

dados e instrutores. O autor destaca as principais funcionalidades:

• Excelente compatibilidade com os padrões SQL (compatibilidade até o padrão

SQL 2008);

• Arquitetura cliente-servidor;

• Arquitetura desenhada para alta concorrência;

• Altamente configurável e extensível; e

• Excelente escalabilidade e performance com diversos recursos de tunning.

Os recursos apresentados anteriormente e também a familiaridade do autor deste TTC

com a ferramenta, fizeram do PostgreSQL como sendo o banco de dados escolhido para o

desenvolvimento deste TTC.

28

2.6 FERRAMENTAS SIMILARES

Optou-se por utilizar como fonte principal de busca de ferramentas similares a página

de sugestões de analisadores de registro de acessos do site oficial do Squid1. A partir desta

página, foram escolhidas as ferramentas mais citadas em listas de discussões e fóruns. Foram

escolhidas ao todo seis ferramentas, sendo três comerciais e três de código-fonte aberto, como

podemos ver em seguida:

• SARG;

• Calamaris;

• Free-SA;

• Redline Internet Access Monitor;

• Firewall Analyzer; e

• Sawmill.

Será realizada uma análise das ferramentas similares escolhidas para poder efetuar um

comparativo mais preciso com a ferramenta proposta para este trabalho. Diante disso, definiu-

se as seguintes métricas de análise:

• Interface web;

• Relatórios dinâmicos;

• Controle de acesso à interface; e

• Aplicação de conceitos OLAP.

Pode-se verificar a seguir, no Quadro 2, o resumo do comparativo, sendo que na

última linha encontra-se a ferramenta desenvolvida neste TTC (chamada Octopus). Nas

subseções subsequentes encontram-se as analises de cada ferramenta.

1 Endereço web: http://www.squid-cache.org/Misc/log-analysis.html

29

Quadro 2. Comparativo de ferramentas similares

Nome da ferramenta

Interface web Relatórios dinâmicos

Controle de acesso à interface

Conceitos OLAP

SARG Atende completamente

Não atende Não atende Análise bidimensional

Calamaris Atende completamente

Não atende Não atende Não atende

Free-SA Atende completamente


Redline Internet Access Monitor

Atende parcialmente


Firewall Analyzer

Atende completamente



Análise bidimensional

Sawmill Atende completamente



Análise bidimensional

Octopus Atende completamente



Análise tridimensional

Como pode ser visto no Quadro 2, o Octopus (ferramenta desenvolvida neste TTC)

visa ser uma ferramenta flexível e simples de se utilizar. Para tanto, a ferramenta foi

implementada sob plataforma web, ou seja, é executada em um servidor web, fazendo com

que a ferramenta possa ser utilizada usando-se de um navegador web a partir de qualquer

computador na rede. Todas as ferramentas similares anteriormente apresentadas (com exceção

da Redline Internet Access Monitor) são ferramentas de plataforma web.

A característica de relatórios dinâmicos, se fez presente em apenas duas das

ferramentas similares apresentadas, ambas comerciais. Esse característica está presente

também na ferramenta Octopus.

A funcionalidade de controle de acessos de usuários à ferramenta só está presente em

duas ferramentas (ambas comerciais). Essa funcionalidade também está presente na

ferramenta Octopus.

Na questão de aplicação dos conceitos OLAP é onde a ferramenta proposta neste

trabalho se diferenciou das demais. Nas ferramentas similares, foram encontrados alguns

pontos que podem lembrar algum conceito OLAP, porém não de forma marcante. Porém, para

o Octopus, foi realizada uma fundamentação dos conceitos de OLAP para a aplicação do

mesmo na ferramenta.

30

2.6.1 SARG

Segundo Gangitano (2010), SARG (Squid Analysis Report Generator), é uma

ferramenta que analisa os registros de acesso de um proxy e permite que se visualize quais

sites os usuários estão navegando. O SARG suporta coletar os registros de acessos do Squid

(escopo deste TTC) e também do Microsoft ISA. O relatório gerado é em HTML (HyperText

Markup Language) e os arquivos HTML gerados são armazenados em um local definido na

configuração da ferramenta.

Na Figura 5 pode-se observar a tela inicial do relatório do SARG. Na primeira tela em

questão, o SARG mostrará os períodos onde o SARG gerou os relatórios de acesso. No caso

da captura de tela em questão, existe apenas um período gerado, e o mesmo corresponde ao

intervalo de 06/06/2004 até 13/09/2004.

Figura 5. Captura de tela da ferramenta SARG na página inicial de relatórios

31

Na Figura 6 tem-se a tela de relatório de um usuário em específico onde é listado os

domínios das páginas acessadas pelo mesmo e também alguns atributos relacionados à página

acessada (por exemplo, a soma dos tamanhos das requisições).

Pôde-se constatar após a análise da ferramenta utilizando como base as métricas

definidas na Seção 2.6:

• Interface web;

◦ Resultado : Atende completamente;

◦ Motivo : Sempre que o SARG é executado, o mesmo gera diversos arquivos do

tipo HTML com os relatórios do último período não processado, e estes HTML

são acessados via servidor web;


◦ Resultado : Não atende;

◦ Motivo : O mesmo gera os relatórios de estaticamente porque o SARG é

executado no servidor e então o mesmo gera arquivos HTML estáticos com os

relatórios já processados;

Figura 6. Captura de tela da ferramenta SARG no relatório de um usuário

32

• Controle de acesso à interface;


◦ Motivo : A ferramenta não possui qualquer tipo de funcionalidade nativa de

controle de acesso para visualização dos relatórios;

• Aplicação de conceitos OLAP;

◦ Resultado : Análise bidimensional;

◦ Motivo : A ferramenta apresenta um conceito bidimensional básico.

2.6.2 CALAMARIS

Segundo Beermann (2007), o Calamaris é uma ferramenta escrita em Perl, que gera

um relatório a partir da análise do arquivo de registros de acessos de usuários em diversos

servidores proxy, que são eles:

• Squid (escopo deste TTC);

• NetCache;

• Inktomi Traffic Server;

• Oops! proxy server;

• Novell Internet Caching System;

• Compaq Tasksmar; e

• Netscape/iplanet Web Proxy Server.

Segundo ainda o autor, o Calamaris oferece a possibilidade de geração do relatório

tanto em formato de texto puro como também em formato HTML. A ferramenta é chamada e

então realiza uma análise do arquivo de registro de acessos do Squid gerando um relatório do

período de acessos que consta no arquivo.

33

A Figura 7 refere-se ao início do relatório onde encontra-se um sumário das

estatísticas geradas pela ferramenta. As estatísticas apresentadas no relatório são estáticas,

sendo que foram geradas quando o HTML foi gerado. Além disso pode-se notar que as

estatísticas apresentadas são focadas principalmente ao administrador do servidor proxy, pois

apresentam métricas mais técnicas acerca do perfil de tráfego de dados.

Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,

pôde-se constatar:

• Interface web;


Figura 7. Captura de tela da ferramenta Calamaris no início do relatório

34

◦ Motivo : A ferramenta possui a opção de geração de relatórios em formato

HTML, onde os mesmos são colocados em um servidor web para o acesso

externo;



◦ Motivo : O relatório, em formato HTML, é gerado apenas quando a ferramenta

é executada, onde é gerado um relatório estático dos dados processados;







◦ Motivo : A ferramenta gera relatórios que não apresentam conceitos OLAP.

2.6.3 FREE-SA

Segundo Free-SA (2012), o Free-SA é uma ferramenta para análise de registro de

acessos do Squid bastante similar ao SARG. Entre suas principais diferenças em relação ao

SARG é sua maior performance, maior variedade de relatórios e um maior suporte aos

padrões HTML da W3C (World Wide Web Consortium) nos relatórios gerados no formato

HTML.

35

A Figura 8 demonstra a tela inicial da ferramenta com os períodos de tempo que

tiveram seus relatórios gerados. Como pode-se perceber, essa ferramenta funciona de forma

similar ao SARG no que tange aos relatórios serem gerados de forma estática.

A Figura 9 demonstra a tela após a seleção de um período de relatórios apresentado na

Figura 8. Nesta tela, pode-se observar os tipos de relatórios que foram gerados pela

ferramenta dentro do período de tempo gerado e selecionado anteriormente. Pode-se

confirmar o número maior de tipos de relatórios em relação ao SARG.

Figura 8. Captura de tela da ferramenta Free-SA na tela de escolha dos períodos de tempo disponíveis

Figura 9. Captura de tela da ferramenta Free-SA com os tipos de relatórios gerados

36

Na Figura 10 apresenta-se um relatório gerado com a listagem de domínios acessados

por um usuário específico e mais alguns atributos relacionados.


pôde-se constatar:

• Interface web;


◦ Motivo : A ferramenta gera seus relatórios em formato HTML, onde os mesmos

são colocados em um servidor web para o acesso externo;



Figura 10. Captura de tela da ferramenta Free-SA na página de relatório de domínios acessados de um usuário

37

◦ Motivo : O relatório, em formato HTML, é gerado apenas quando a ferramenta

é executada, onde são gerados os relatórios estático de acordo com o período

não processado;







◦ Motivo : A ferramente apresenta estatísticas fixas que não exploram os

conceitos multidimensionais, apenas bidimensionais.

2.6.4 REDLINE INTERNET ACCESS MONITOR

Segundo Redline (2012), o Redline Internet Access Monitor é uma ferramenta

comercial para monitorar a eficiência do uso da banda de Internet por parte dos funcionários

de uma empresa. A ferramenta permite a visualização de quais usuários estão utilizando mais

a Internet, o que cada usuário está acessando além também de observar quanto tempo que o

usuário gasta na navegação. Além disso a ferramenta suporta diversos servidores proxy,

dentre eles o Squid, foco deste TTC. Na Figura 11 tem-se uma visão geral de uma das telas de

relatórios da ferramenta, mais especificamente, a tela de relatórios de acesso a sites dos

usuários.

38

Como pôde-se notar na Figura 11, a ferramenta funciona sob plataforma desktop, ou

seja, é um aplicativo que possui um executável e o mesmo é aberto no próprio computador do

usuário onde deseja-se visualizar os acessos. Apesar disso, a ferramenta possui uma opção de

exportar um determinado relatório para o formato HTML, pode-se ver o resultado na Figura

12.

Figura 11. Captura de tela da ferramenta Redline Internet Access Monitor

39

Pode-se notar, na Figura 12, que o relatório exportado em HTML é simples é referente

a um relatório específico com atributos específicos que foram definidos dentro dos software.


pôde-se constatar:

• Interface web;

◦ Resultado : Atende parcialmente;

◦ Motivo : A ferramenta é executada em plataforma desktop, o que acaba fazendo

necessário a instalação do mesmo em cada computador onde se acessará os

relatórios dos acessos do Squid;



◦ Motivo : A ferramenta dispõem de diversas opções para a geração dos relatórios

utilizando-se diversos atributos e filtros;


Figura 12. Captura de tela da ferramenta Redline Internet Access Monitor com o relatório de uso diário exportado em HTML

40






◦ Motivo : A ferramenta apresenta levemente relatórios com conceito

bidimensional.

2.6.5 FIREWALL ANALYZER

Segundo ManageEngine (2012), o Firewall Analyzer é uma ferramenta de gerência de

rede para análise de logs de dispositivos de segurança de redes. A ferramenta é útil para

analisar os logs dos firewalls da rede, possibilitando assim a detecção de falhas de segurança

como tráfego de vírus, ataques, entre outros. Além disso, também é possível analisar outros

itens, como o uso da banda de rede, possibilitando identificar o perfil de uso do tráfego da

rede, além também de monitorar a navegação web de usuários da rede. Na Figura 13 tem-se a

tela inicial da ferramenta na página inicial de relatórios do Squid.

Figura 13. Captura de tela da ferramenta Firewall Analyzer na página inicial do relatório

41

A captura de tela da Figura 13, apresenta no centro alguns gráficos básico de

utilização do Squid. Além disso, também é apresentado no menu localizado na parte esquerda

e no topo da tela outras opções para visualização dos demais relatórios. É fornecido também

opções para a geração de relatórios personalizando, disponibilizando filtros e restrição de

períodos. A ferramenta também permite a geração de um relatório de acesso geral de um

usuário, como apresentado na Figura 14.

Na Figura 14 pode-se observar a página de relatório de acesso da máquina de um

usuário da rede. Pode-se perceber também que o relatório em questão faz um apanhado das

principais estatísticas refentes ao dados de navegação do usuário. No menu da esquerda, é

oferecido outras opções de relatório com informações mais específicas acerca de cada tipo de

estatística.

Figura 14. Captura de tela da ferramenta Firewall Analyzer na página de relatório de um usuário

42


pôde-se constatar:

• Interface web;


◦ Motivo : A ferramenta é executada em um servidor web, permitindo assim que

a mesma possa ser acessada de qualquer máquina com navegador web;




utilizando diversos atributos e filtros;



◦ Motivo : A ferramenta dispõe da possibilidade de criação de usuários no

sistema para controle de acesso aos relatórios;



◦ Motivo : A ferramenta apresenta alguns conceitos de OLAP, principalmente no

que diz respeito ao conceito bidimensional.

2.6.6 SAWMILL

Segundo Sawmill (2012), o Sawmill é uma ferramenta para análise de logs que roda

nas principais plataformas. O mesmo suporta o processamento de diversos tipos de dados,

dentre eles o arquivo de registro de acessos do Squid. Pode-se observar na Figura 15 a tela

inicial da ferramenta.

43

Na tela inicial da ferramenta, Figura 15, observa-se que o Sawmill é uma ferramenta

que dispõe de interface web, ou seja, o mesmo é executado em plataforma web, sendo

executado em um servidor web. Dessa maneira, pode-se acessar a ferramenta de qualquer

máquina da rede. Ainda na Figura 15, tem-se algumas estatísticas gerais e então é apresentado

no menu da esquerda diversos relatórios que são gerados em tempo real. Por exemplo, o

relatório de URLs acessadas pode ser visualizado na Figura 16.

Figura 15. Captura de tela da ferramenta Sawmill na página inicial

44

Na Figura 16 podemos observar o relatório com a listagem de acessos com alguns

atributos, como por exemplo, o endereço IP do cliente, usuário do cliente e o tipo do conteúdo

acessado. Para o aprimoramento da visualização das informações do relatório, pode-se utilizar

também as opções de filtros de atributos e de períodos de tempo disponíveis no menu

superior.


pôde-se constatar:

• Interface web;


◦ Motivo : A ferramenta é executada em um servidor web, permitindo assim que

a mesma possa ser acessada de qualquer máquina com um navegador web;



Figura 16. Captura de tela da ferramenta Sawmill na tela de relatório de acessos

45


permitindo a personalização dos mesmos com filtros de períodos de tempo e

atributos;



◦ Motivo : A ferramenta dispõe da possibilidade de criação de usuários no

sistema para controle de acesso aos relatórios;



◦ Motivo : A ferramenta apresenta alguns conceitos de OLAP aplicados, como

relatórios bidimensionais.

46

3 DESENVOLVIMENTO

Neste capítulo são documentados o projeto do software desenvolvido bem como sua

implementação e validação. Primeiramente será apresentada a modelagem do software, com

utilização da UML, onde será apresentado diversos itens como o levantamento de requisitos,

modelos de classes, modelos de casos de uso e modelo do banco de dados. Segundo Pedrycz e

Peters (2001), nesta etapa é feita a descrição das principais funcionalidades de um software,

bem como seu fluxo, comportamento e atributos. Basicamente é fornecido a estrutura básica

para o desenvolvimento de um software.

Após a etapa de modelagem, será apresentada a etapa do trabalho que contempla a

implementação da ferramenta, que por sua vez é composta por dois módulos cuja

implementação é demonstrada na Seção 3.2. Subsequentemente será apresentado o processo

de validação da ferramenta com a finalidade de atestar o atendimento aos objetivos deste

trabalho.

3.1 MODELAGEM DO SOFTWARE

O software foi divido basicamente em dois módulos. O módulo coletor, que faz a

leitura dos dados gerados pelo servidor proxy Squid e os salva em um banco de dados, e o

módulo interface de visualização, que fornecerá a interface para geração de relatórios.

Serão apresentados os seguintes artefatos:

• Levantamento de requisitos;

◦ Um diagrama de regras de negócio;

◦ Um diagrama de requisitos funcionais;

◦ Um diagrama de requisitos não funcionais;

• Dois diagramas de modelo de classes;

• Um diagrama de modelo de casos de uso;

• Um diagrama entidade relacionamento – conhecido também como modelo ER

(Entity-relationship) – do banco de dados; e

• Dois protótipos de tela.

47

3.1.1 LEVANTAMENTO DE REQUISITOS

O levantamento de requisitos do projeto será constituído pelos requisitos funcionais,

requisitos não funcionais e as regras de negócio. Os mesmos serão listados nas subseções não

numeradas a seguir.

Requisitos funcionais

Baseando-se nas funcionalidades esperadas, foi identificado os seguintes requisitos

funcionais:

• RF01 : O usuário poderá se autenticar no sistema;

• RF02 : O administrador poderá criar, editar e excluir outros usuários;

• RF03 : O usuário do sistema poderá acessar o relatório tridimensional;

• RF04 : O usuário do sistema poderá acessar o relatório bidimensional;

• RF05 : O relatório tridimensional deverá permitir a escolha de um período de

tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo

da terceira dimensão;

• RF06 : O relatório bidimensional deverá permitira escolha de um período de

tempo, atributos visíveis, ordenação e filtros de atributos;

• RF07 : O administrador poderá definir se outro usuário é administrador ou não; e

• RF08 : O usuário poderá alterar sua senha.

Requisitos não funcionais

Foram definidos os seguintes requisitos não funcionais:

• RNF01 : A senha dos usuários do sistema deve ser armazenada de forma

criptografada em hash MD5 no banco de dados;

• RNF02 : Somente usuários autenticados podem acessar o sistema;

• RNF03 : Qualquer página do sistema deverá ser carregada em no máximo 5

segundos em condições normais de rede, com o servidor de relatório e banco de

48

dados com um hardware de no mínimo um processador Intel Core 2 Duo 2,13Ghz,

com 3 GB de memória e disco de armazenamento padrão SATAII e o banco de

dados contendo 1 milhão de registros de acessos;

• RNF04 : A interface de visualização de relatórios deverá funcionar nos

navegadores Mozilla Firefox 12, Google Chrome 18 e Microsoft Internet Explorer

8;

• RNF05 : O módulo coletor será implementado utilizando-se a linguagem de

programação Python;

• RNF06 : O módulo de interface de visualização será desenvolvido na linguagem

PHP utilizando-se o framework Symfony; e

• RNF07 : O SGBD (Sistema de Gerenciamento de Banco de Dados) usado será o

PostgreSQL.

Regras de negócio

Foram identificadas as seguintes regras de negócio no sistema:

• RN01 : Somente os usuários autorizados a monitorar os dados de navegação podem

acessar o sistema; e

• RN02 : O servidor proxy utilizado é o Squid.

3.1.2 MODELO DE CASOS DE USO

Os casos de uso são úteis para modelar as funcionalidades que os usuários utilizarão

no sistema, ou seja, é possível ter uma visão geral dos recursos que serão oferecidos pelo

software proposto. (PENDER, 2004).

É apresentado a seguir, na Figura 17, o diagrama dos casos de uso descrevendo os

recursos da ferramenta proposta neste trabalho. A visão detalhada de cada caso de uso é

apresentada no APÊNDICE A..

49

Na Figura 17 observa-se seis casos de uso referentes ao projeto do módulo de interface

de visualização. Tem-se dois perfis específicos de usuários, o “Gestor” e o “Administrador”.

O perfil “Gestor” refere-se aos gestores da determinada empresa que teriam acesso ao painel

de visualização de relatórios. Já o perfil “Administrador” refere-se ao administrador da

ferramenta que terá a tarefa de gerir os usuários autorizados a visualizarem os relatórios. Cada

um dos dois perfis possui seu ator com mesmo nome. Além disso, existe outro ator que

representa os dois atores especializados citados anteriormente, utilizado para os casos de uso

que podem ser realizados tanto pelo ator “Gestor” e o ator “Administrador”.

A gestão de usuários conta com quatro casos de uso (UC01.01 ao UC01.04). O

primeiro caso de uso, identificado como UC01.01, refere-se ao processo de autenticação do

sistema (obrigatório para poder acessar qualquer parte da ferramenta). O segundo caso de uso

é identificado como UC01.02 e diz respeito ao processo de alteração de senha do usuário

atualmente autenticado. O terceiro caso de uso é identificado como UC01.03 e diz respeito ao

processo de criação, edição e exclusão de usuários, que é executado apenas pelo perfil

“Administrador”. O quarto caso de uso é identificado como UC01.04 e diz respeito ao

Figura 17. Diagrama do modelo de casos de uso

50

processo de definição, por parte do perfil “Administrador”, se um usuário fará parte do perfil

“Administrador” ou não.

A geração de relatórios conta com dois casos de uso (UC01.05 e UC01.06). O

primeiro caso de uso, identificado como UC01.05, diz respeito à geração de relatório

bidimensionais, juntamente com suas opções de filtragem e ordenação. O segundo caso de uso

é identificado como UC01.06 e diz respeito à geração de relatórios tridimensionais,

juntamente com a aplicação de alguns conceitos OLAP, seleção de pivôs e outras opções de

filtragem e ordenação.

3.1.3 MODELO DE CLASSES

Na seção em questão, foi apresentado um diagrama de classes de domínio para o

módulo coletor, Figura 18, e outro diagrama de classes de domínio para o módulo interface de

visualização, Figura 19.

As classes descritas nos diagramas apresentam sua identificação, principais atributos e

principais métodos. A visão detalhada dos modelos de classes dos diagramas está no

APÊNDICE B..

51

Módulo coletor

A Figura 18 apresenta o diagrama o diagrama de modelo de classes do módulo coletor.

Nela pode-se observar a presença de duas classes, sendo que a primeira chama-se

“SquidLogFile” que representa o arquivo com os registros de acessos do Squid, sendo que a

mesma possui um atributo com a localização do arquivo dentro do sistema de arquivos local

além de um método principal utilizado para iniciar o processamento do arquivo. Já segunda

classe, chama-se “SquidAccessLogRequest”, que representa cada registro do arquivo de

registros de acessos do Squid, sendo que seus atributos estão fundamentados na Subseção

2.3.1.

Figura 18. Diagrama do modelo de classes do módulo coletor

52

Módulo interface de visualização

A Figura 19 apresenta o diagrama de modelo de classes do módulo interface de

visualização. Pode-se observar a presença de duas classes. A primeira classe chama-se “User”

e representa o cadastro de usuários autorizados a acessar a ferramenta Octopus, juntamente

com alguns atributos como o nome completo, senha, e-mail e se possui direitos

administrativos. Já a segunda classe, representa cada registro de acesso do Squid que está

armazenado no banco de dados, seus atributos estão fundamentados na Subseção 2.3.1.

3.1.4 DIAGRAMA ENTIDADE RELACIONAMENTO (MODELO ER)

O software utiliza o SGBD PostgreSQL para armazenar todo os registros de acessos

(alimentado pelo módulo coletor e acessado/visualizado pelo módulo interface de

visualização). Além disso, será armazenado também o cadastro de usuários que podem

acessar o módulo interface de visualização para a geração de relatórios, como pode ser visto

no diagrama na Figura 20.

Figura 19. Diagrama de modelo de classes do módulo interface de visualização

53

No diagrama em questão, na Figura 20, é mostrado o modelo ER do banco de dados.

O banco de dados será composto por duas tabelas, sendo a primeira chamada “user”,

responsável por armazenar o cadastro de usuários que terão acesso autorizado para utilizar a

ferramenta. Esta tabela armazenará as informações de nome completo, senha, e-mail e se o

usuário possui direitos administrativos na ferramenta. Já a tabela “squid_access_log_request”,

ficará responsável por armazenar cada requisição que o Squid registrar em seu arquivo de

registros de acessos utilizando os atributos disponíveis pelo mesmo, fundamentados na

Subseção 2.3.1.

No APÊNDICE C. é apresentado a visão detalhada do modelo.

3.1.5 PROTÓTIPO DE TELA

Para melhorar o entendimento sobre os relatórios da ferramenta Octopus, optou-se por

elaborar dois protótipos de tela demonstrados na Figura 21 e Figura 22. Os protótipos foram

desenhados utilizando a ferramenta Balsamiq Mockups.

Figura 20. Diagrama modelo entidade relacionamento (modelo ER)

54

Na Figura 21 podemos visualizar um relatório bidimensional onde tem-se na parte

superior um filtro de período de tempo, seleção de campo visíveis e uma tabela com as

informações de acesso de acordo com a configuração selecionada pelo usuário.

Figura 21. Protótipo de tela do relatório bidimensional

55

Na Figura 22 tem-se o protótipo de tela do relatório tridimensional, onde pode-se

observar na parte superior, o filtro de período de tempo por data e hora, além também da

seleção de campos visíveis que permite o usuário escolher a quantidade de atributos que

deseja visualizar. Já na parte central do relatório, observa-se a tabela com as informações de

acesso, onde junto com a tabela, na parte superior, tem-se as abas que referem-se ao atributo

de usuário autenticado do Squid. Dessa maneira, as abas funcionam como as fatias do cubo de

informações presentes na tela, sendo assim, tem-se a terceira dimensão.

3.2 IMPLEMENTAÇÃO DA FERRAMENTA

A implementação da ferramenta proposta foi divida em duas partes, ou ainda, em dois

módulos: (i) Implementação do módulo coletor, responsável pela coleta das informações

brutas do servidor proxy Squid onde serão salvar em um banco de dados; (ii) Implementação

do módulo de interface de visualização, responsável pela interface de geração de relatórios.

Figura 22. Protótipo de tela do relatório tridimensional

56

3.2.1 IMPLEMENTAÇÃO DO MÓDULO COLETOR

O módulo coletor foi desenvolvido na linguagem de programação Python. Utilizou-se

duas classes principais conforme especificado na subseção 3.1.3.

A Figura 23 demonstra a classe “SquidAccessLogRequest”, onde pode-se observar os

seus atributos. Cada atributo da classe em questão se refere ao seu respectivo campo contido

em um linha do arquivo de registro de acessos do Squid – que por sua vez, representa uma

requisição de um usuário da rede.

Figura 23. Classe “SquidAccessLogRequest” do módulo coletor

Figura 24. Classe "SquidLogFile" do módulo coletor (método "parse" recolhido)

57

Na Figura 24, pode-se observar a classe “SquidLogFile”, que representa o arquivo de

registro de acessos do Squid. Na classe em questão, tem-se um construtor que definirá a

localização do arquivo de registro de acessos do Squid ao se realizar o instanciamento do

objeto. Além disso, tem-se o método “clean”que realiza a limpeza do arquivo de registro de

acessos do Squid. Tem-se também o método “parse”, onde será realizado o processamento do

arquivo de registro de acessos do Squid. O método “parse” realiza primeiramente a leitura do

arquivo de registro de acessos do Squid, sendo que após o término, é realizada a limpeza do

arquivo. Logo após essa etapa, é realizada então um laço que percorre todos os acessos

registrados no arquivo criando os objetos correspondentes a todos os registros, juntamente

com suas informações recolhidas de cada campo do arquivo de registro de acessos do Squid.

Após todo esse processo, ao final da execução do módulo em questão, os objetos serão

persistidos em banco de dados.

3.2.2 IMPLEMENTAÇÃO DO MÓDULO DE INTERFACE DE VISUALIZAÇÃO

O módulo de interface de visualização foi desenvolvido utilizando-se a linguagem de

programação web PHP, juntamente com o framework Symfony versão 2.2. Além disso,

utilizou-se um framework de interfaces HTML chamado Twitter Bootstrap. Com o mesmo,

foi possível criar e manipular a interface das páginas de maneira fácil e com alguns estilos pré

definidos.

Para a melhor organização da implementação, foram criados três bundles (ou pacotes):

• OctopusFrontendBundle : Pacote que contém a entidade referente aos registros de

acessos do Squid (camada de modelo), bem como as camadas de controle e de

visão de toda a ferramenta, com exceção da seção de autenticação de usuários da

ferramenta;

• OctopusSecurityBundle : Pacote que conterá a camada de controle e de visão

referente a seção de autenticação de usuários da ferramenta; e

• OctopusUserBundle : Pacote que conterá a camada de modelo de usuário, ou seja,

conterá a entidade que representa um usuário na ferramenta.

58

Entidades

Na camada de modelo da implementação, conforme a especificação elaborada na

Seção 3.1, foram criadas duas classes, juntamente com as suas respectivas anotações

referentes ao seu mapeamento para persistência no banco de dados. A primeira classe, é a

“SquidAccessLogRequest”, criada dentro do pacote “OctopusFrontendBundle”. A classe em

questão conterá as informações que constituirão cada registro de acesso ao Squid.

A segunda classe de modelo criada, é a classe “User”, criada dentro do pacote

“OctopusUserBundle”, que representa o usuário que irá utilizar a ferramenta para a

visualização dos relatórios. A classe em questão, conterá as informações que constituirá a

entidade de representação de um usuário da ferramenta.

Autenticação

O Symfony tornou a implementação da autenticação uma tarefa simples de executar.

Foi necessário editar o arquivo “app/config/security.yml” e definir algumas configurações:

• Algoritmo de criptografia de senha : MD5;

• Entidade de usuário : “Octopus\UserBundle\Entity\User”;

• Credenciais de autorização;

◦ “ROLE_USER” : Credencial de usuário normal;

◦ “ROLE_ADMIN” : Credencial de administrador;

• Área segura : Definiu-se que o sistema inteiro necessitará de autenticação (com

exceção da página de autenticação), sendo que ao acessar as páginas protegidas

sem possuir a credencial necessária ou sem estar autenticado, a página será

redirecionada para o formulário de autenticação.

59

A Figura 25 demonstra a tela de autenticação do sistema com os campos de e-mail e

“Password” (senha), onde após inseridas as informações corretas de e-mail e senha, o acesso à

ferramenta será concedido.

Relatório bidimensional

A tela de relatórios bidimensionais gera um relatório em uma tabela onde os dados são

mostrados em duas dimensões. A tela é demonstrada na Figura 26 e na Figura 27.

Figura 25. Captura de tela do formulário de autenticação do sistema

60

A Figura 26 demonstra a tela do relatório bidimensional com os parâmetros para

configuração do relatório. Da esquerda para a direita, observa-se primeiramente a seleção do

intervalo de data e hora para o relatório, “Date & Time range”. Após o mesmo, tem-se a

seleção das colunas a serem exibidas no relatório, subsequentemente observa-se o “Column

filter” que permite filtrar uma determinada coluna por um determinado padrão de texto ou

números a ser informado no campo “Filter text”. Por último, o “Order by” permite selecionar

o campo a ser utilizado para ordenação e sua orientação, ascendente “ASC” ou descendente

“DESC”. Além disso, há o botão “Save current query” que fornece a possibilidade de salvar a

consulta em questão para um fácil acesso posterior. A tabela com o relatório se encontra mais

abaixo na página, onde há o título “Result”, como observa-se na Figura 27.

Figura 26. Captura de tela do relatório bidimensional com destaque para os parâmetros

61

Na Figura 27 observa-se o relatório bidimensional que localiza-se na mesma da Figura

26, porém abaixo no título “Result” citado anteriormente. Pode-se observar que ao lado do

título “Result” existe alguns dados referentes à quantidade dos dados que estão sendo

visualizados na página atual e o total encontrado. Mais abaixo observa-se as informações

sobre o número da página de resultados atuais acompanhado do total de páginas de resultado.

Ao lado direito e esquerdo tem-se os botões “Previous page” (para ir à página anterior) e

“Next page” (para ir à próxima página). Mais abaixo se observa o relatório de fato, gerado de

acordo com os parâmetros de configuração demonstrados na Figura 26.

Já a lógica de criação do relatório localiza-se na ação “twoDimensional” dentro da

classe controle “ReportController” no pacote “OctopusFrontendBundle”.

Figura 27. Captura de tela do relatório bidimensional com destaque ao relatório

62

Relatório tridimensional

A tela de relatórios tridimensionais gera um relatório utilizando-se de uma estrutura

tabular, porém utilizando dois pivôs na parte da esquerda que representarão duas das três

dimensões, sendo que a terceira dimensão, as das medidas, ficará na parte da direita. Na

implementação da tela em questão, a camada da visão foi implementada no arquivo

“threeDimensional.html.twig”. A tela é demonstrada na Figura 28 e na Figura 29.

Na Figura 28 observa-se a parte superior da tela de relatórios tridimensionais. Na parte

da tela em questão, pode-se selecionar o intervalo de data e hora referente à fatia do cubo que

se deseja visualizar. Ao lado, tem-se a seleção de medidas a serem visualizadas na parte da

direita no relatório demonstrado na Figura 29. A direita tem-se outro parâmetro para seleção,

que é a dos pivôs, onde seleciona-se os campos que serão utilizados como dimensões e

estarão localizados na parte esquerda do relatório demonstrado na Figura 29. Juntamente com

Figura 28. Captura de tela do relatório tridimensional com destaque para os parâmetros

63

os parâmetros de seleção de pivôs, estão os respectivos parâmetros de ordenação “ASC”

(ascendente) e “DESC” (descendente). Além disso, há o botão “Save current query” que

fornece a possibilidade de salvar a consulta em questão para um fácil acesso posterior.

Observa-se na Figura 29 a parte inferior da tela de relatório tridimensionais,

localização de fato do relatório. Semelhantemente ao relatório bidimensional, no topo

apresenta-se algumas informações referentes aos resultados exibidos além de informar o

número da página atual e o total de páginas juntamente com os botões de navegação entre as

páginas de resultados. Pode-se ainda destacar, na Figura 29, a metáfora das três dimensões

que são representadas. Como mencionado anteriormente, tem-se na direita as “Measures”

(medidas, ou métricas) que representam uma dimensão. Já na esquerda, tem-se os dois pivôs

que representam mais duas dimensões. Pode-se notar também que é possível clicar sobre os

valores apresentados nas duas colunas de pivôs, fazendo com que seja apresentado uma fatia

de resultados de acordo com o valor clicado.

Já a lógica de criação do relatório localiza-se na ação “threeDimensional” dentro da

classe controle “ReportController” no pacote “OctopusFrontendBundle”.

Figura 29. Captura de tela do relatório tridimensional com destaque para o relatório tridimensional

64

Gerenciamento de usuários

A ferramenta permite que um usuário troque sua senha, permite que um administrador

crie um novo usuário, permite que o administrador visualize as contas existentes além de

permitir que o administrador edite e exclua outro usuário.

Observa-se na Figura 30 a tela administrativa de listagem de usuários, onde na parte

superior, é fornecido um botão para realizar a criação de novos usuários para a ferramenta. Na

listagem de usuários, observa-se os diversos dados que compõem um usuário da ferramenta,

sendo que na coluna da direita, é apresentado duas ações para cada usuário, “Edit” (editar um

usuário) e “Remove” (remover um usuário).

Consultas salvas

Como citado anteriormente, o usuário da ferramenta poderá salvar as consultas ao

relatório bidimensional e ao relatório tridimensional para facilitação do acesso posterior. As

consultas salvas, estarão disponíveis na página inicial da aplicação como demonstrado na

Figura 31.

Figura 30. Captura de tela da listagem de usuários

65

Na Figura 31, pode-se observar a tela inicial da ferramenta, sendo que na parte inferior

da tela, encontra-se a listagem das consultas salvas, juntamente com uma opção de remover as

mesmas.

3.3 TESTES FINAIS DA FERRAMENTA

A fim de validar o funcionamento da ferramenta, foram realizados alguns testes finais

no mesmo. Para cada teste, serão definidos os seus parâmetros seguidos pela descrição da

execução do teste juntamente com a aferição do resultado esperado.

3.3.1 TESTE 1: NÚMERO REQUISIÇÕES COLETADAS

Para o teste em questão, foram definidos os seguintes parâmetros:

• Base de dados : Arquivo de registro de acessos do Squid com cindo mil linhas de

acessos variados;

Figura 31. Captura da tela inicial da ferramenta juntamente com a listagem de consultas salvas

66

• Descrição do teste : Realizar a importação de um arquivo de registros de acessos

utilizando o módulo coletor e então aferir o número total de registros importados

através de uma pesquisa sem filtros na interface de visualização de relatórios; e

• Resultado esperado : Relatório com resultado total de cinco mil registros.

Executou-se o módulo coletor, o mesmo leu o arquivo e converteu para o banco de

dados todos os registros sem apresentar nenhum erro, como demonstrado no Quadro 3.

No Quadro 3, observa-se a saída do comando de execução do módulo coletor. Nota-se

que o tempo total de sua execução foi de cerca de um minuto.

Com a importação realizada, pôde-se observar no módulo de interface de visualização

os dados populados correspondendo com os dados contidos no arquivo de registro de acessos

do Squid. Em ambos os relatórios (bidimensional e tridimensional) ao se utilizar um

abrangente filtro de data (com intenção de englobar todos os registros que foram lidos do

arquivo de registro de acessos do Squid) o número total de resultados encontrados pode-se

observar na Figura 32.

:: Starting @ 2012-11-01 18:05:40.858041 ::Connecting do database...Opening access log file...Found 5000 Squid access requests.Parsing log file...Saving to database...Closing database connection...:: Finished @ 2012-11-01 18:06:40.611274 ::

67

Na Figura 32 pode-se visualizar a comprovação do sucesso deste teste, pois ao lado do

título “Result” tem-se as estatísticas de resultados informando que o total de resultados é

cinco mil, coincidindo com o resultado esperado deste teste.

3.3.2 TESTE 2: VERIFICAR OS SITES ACESSADOS POR UM ENDEREÇO IP (USUÁRIO) DURANTE UM PERÍODO DE TEMPO

Para o teste em questão, utilizou-se uma base de dados com um dia inteiro de

utilização do servidor proxy na empresa em que o autor trabalha.


• Base de dados : Utilização do servidor proxy na empresa que o autor trabalha no

dia cinco de setembro de dois mil e doze;

• Descrição do teste : Acessar o relatório bidimensional e realizar um filtro pelo

endereço IP “192.168.1.199” no período de tempo entre as 8h e 17h48min do dia

cinco de setembro de dois mil e doze; e

• Resultado esperado : 250 páginas de resultados e 24.906 registros encontrados.

Figura 32. Captura de tela no número total de resultados no banco de dados

68

O teste foi executado acessando-se a opção “Two dimensional report” (relatório

bidimensional) juntamente com a definição de alguns parâmetros como demonstrado na

Figura 33.

Na Figura 33, pode-se observar a definição do intervalo de data e hora a serem

buscados, colunas a serem visualizadas, o filtro ao endereço IP do usuário e a ordenação das

requisições. Ao pressionar o botão “Apply filter”, será gerado o relatório apresentado na

Figura 34.

Figura 33. Teste 2 - Parâmetros do relatório bidimensional

69

Na Figura 34 pode-se observar o relatório de fato gerado a partir dos parâmetros

definidos. Pode-se observar que foi encontrado um total de 24.906 registros organizados em

250 páginas, o que coincide com o resultado esperado para o teste.

3.3.3 TESTE 3: VERIFICAR OS MAIORES ARQUIVOS BAIXADOS


• Base de dados : Acessos do dia cinco de setembro de dois mil e doze;

• Descrição do teste : O teste consiste em constatar quais foram as maiores

requisições efetuadas (seja download direto, vídeos sob-demanda, entre outros); e

• Resultado esperado : requisição realizada as 13h06min52s com tamanho

470.268.237 bytes e proveniente do endereço IP 192.168.1.199.

Figura 34. Teste 2 - Relatório bidimensional de acessos de um usuário específico

70

O teste foi executado acessando-se a opção a opção “Three dimensional report”

(relatório tridimensional) juntamente com a definição de alguns parâmetros como

demonstrado na Figura 35.

Na Figura 35 pode-se observar primeira a escolha da fatia do cubo correspondente a

data de pesquisa, que foi definida para o dia cinco de setembro do ano de dois mil e doze e

dentro do intervalo de horário de trabalho (das 8h até 17h 48min). Foram selecionadas três

medidas, data e hora, endereço acessado e o tipo de conteúdo. Nenhum filtro de texto foi

aplicado. Além disso, foram selecionados dois pivôs. O primeiro pivô, é refere-se ao tamanho

da requisição e terá ordenação descendente, ou seja, do maior para o menor. O segundo pivô,

refere-se ao endereço IP do usuário que acessou o endereço e utilizará ordenação ascendente,

ou seja, do menor para o maior. Após clicar em “Generate report”, será gerado o relatório

apresentado na Erro: Origem da referência não encontrada.

Figura 35. Teste 3 - Parâmetros do relatório tridimensional

71

Na Erro: Origem da referência não encontrada pode-se observar o relatório gerado. No

primeiro pivô da esquerda observa-se a coluna referente ao tamanho da requisição, já o

segundo pivô, corresponde ao endereço IP do usuário da requisição. Na primeira linha de

resultado, pode-se observar a requisição de maior tamanho, que possui o tamanho de

470.268.237 bytes (ou aproximadamente 450 Megabytes). Na requisição em questão, pode-se

observar que o mesmo trata-se de um vídeo visto no site YouTube que foi visualizado pelo

usuário de IP “192.168.1.199”..

Figura 36. Teste 3 - Relatório dos maiores arquivos baixados

72

4 CONCLUSÕES

Este trabalho consistiu em projetar e implementar uma ferramenta de código aberto

para a geração de relatórios para o servidor proxy Squid com aplicabilidade de alguns

conceitos de OLAP. A motivação do projeto se deu principalmente ao fato da dificuldade em

encontrar ferramentas de código aberto que forneçam interfaces intuitivas com altas curvas de

aprendizagem por parte dos usuários comuns, interfaces com flexibilidade na busca de

informações específicas, seja qual for o período de tempo escolhido, relatórios que permitam

controlar as informações a serem visualizadas conforme a necessidade,. quantidade de

informações exibidas além também de um controle de acesso de usuário à interface de

visualização das informações.

Foi elaborada a fundamentação teórica dos conceitos referentes a este trabalho, além

também de estudar o conceito de OLAP que serviu como base principalmente para a

funcionalidade de geração de relatório tridimensional desenvolvida neste trabalho. Terminada

esta etapa, elaborou-se o projeto de engenharia de software com todos os requisitos

levantados, onde gerou-se requisitos funcionais, requisitos não funcionais e regras de negócio,

além também da confecção dos modelos de casos de uso, modelos de classe, modelo de banco

de dados e protótipos de tela de baixa fidelidade das telas de relatórios bidimensionais e

tridimensionais. Com isso, foi possível guiar a implementação da ferramenta.

A etapa de implementação da ferramenta transcorreu sem maiores imprevistos. O

framework Symfony se mostrou uma ferramenta útil para o desenvolvimento de aplicações do

perfil da ferramenta Octopus. A implementação da ferramenta se deu de forma organizada

devida a forma do Symfony trabalhar com as divisões de camadas. Após o final da

implementação, os testes finais ocorreram sem problemas e atestaram o cumprimento dos

objetivos propostos.

Com a utilização da ferramenta Octopus, espera-se resolver a maioria dos problemas

que serviram de motivação para a elaboração deste trabalho. Pôde-se observar a melhoria na

interface e nas possibilidades de geração de relatórios, não ficando mais presos a modelos

estáticos como os da ferramenta SARG. Isto permite que se chegue de uma maneira muito

mais rápida e precisa à informação.

73

A ferramenta Octopus se transformará em um projeto público, onde contará com seu

código-fonte disponível na Internet e presente em um serviço de desenvolvimento

colaborativo, permitindo alavancar a evolução e a utilização da ferramenta.

4.1 TRABALHOS FUTUROS

Durante todo o projeto de desenvolvimento da ferramenta Octopus, foram

identificadas diversas funcionalidades que por estarem fora do escopo deste projeto, as

mesmas não foram incluídas, porém são funcionalidades interessantes para a evolução da

ferramenta tornando-a uma ferramenta mais completa e madura para ser adotada.

A fim de tornar a ferramenta mais completa no que tange à integração com o Squid,

mostra-se interessante a exibição de um módulo na ferramenta que explore as métricas de

funcionamento e estatísticas do servidor Squid. Ou seja, seriam informações de cunho mais

técnico, podendo-se assim visualizar informações de consumo de processamento, memória,

entrada e saída, configuração, requisições por segundo, eficiência do cache, entre outros.

Outro recurso interessante principalmente em meios corporativos, é a integração do

sistema de autenticação de usuários com o serviço de diretórios LDAP (Lightweight Directory

Access Protocol), permitindo assim o acesso da ferramenta a base de dados centralizada de

usuários de uma determinada empresa, facilitando o gerenciamento de usuários.

74

REFERÊNCIAS

BEERMANN, Cord. Calamaris. 2007. Disponível: <http://cord.de/tools/squid/calamaris/>. Acesso em 4 jul. 2012.

FREE-SA. Free-SA: Description. 2012. Disponível: <http://sourceforge.net/projects/free-sa/>. Acesso em 4 jul. 2012.

GANGITANO, Luigi. SARG. 2010. Disponível: <http://sarg.sourceforge.net/sarg.1.html>. Acesso em 4 jul. 2012.

KUROSE, James F.; ROSS, Keith W. Redes de computadores e a Internet: Uma abordagem top-down. 3 ed. São Paulo: Pearson Addison Wesley, 2006.

LOPES, Raquel V.; SAUVÉ, Jacques P.; NICOLLETTI, Pedro S. Melhores Práticas para Gerência de Redes de Computadores. Rio de Janeiro: Editora Campus, 2003.

MANAGEENGINE. Firewall Analyzer: Firewall Log Analysis Software. 2012. Disponível: <http://www.manageengine.com/products/firewall/>. Acesso em 4 jul. 2012.

MCCABE, James D. Network Analysis, Architecture, and Design. 3 ed. Burlington: Morgan Kaufmann Publishers, 2007.

PEDRYCZ, Witold; PETERS, James F. Engenharia de software: teoria e prática. Rio de Janeiro: Elsevier, 2001.

PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.

REDLINE. Redline Software: Internet Access Monitor. 2012. Disponível: <http://www.redline-software.com/eng/products/iam/>. Acesso em 4 jul. 2012.

RICCI, Bruno; MENDONÇA, Nelson. Squid – Solução Definitiva. Rio de Janeiro: Ciência Moderna, 2006.

RIGGS, Simon; KROSING, Hannu. PostgreSQL 9 Administration Cookbook. Birmingham: Packt Publishing, 2010.

SAWMILL. Sawmill: Features. 2012. Disponível: <http://www.sawmill.net/features.html>. Acesso em 4 jul. 2012.

THOMSEN, Erik. OLAP Solutions: building multidimensional information systems. New York: John Wiley & Sons, 2002.

WESSELS, Duane. Squid: The Definitive Guide. Sebastopol: O'Reilly, 2004.

75

GLOSSÁRIO

Código aberto É um termo que refere-se também ao software livre. Basicamente define o termo de liberdade de um software, onde respeita-se as quatro liberdades definidas pela Free Software Foundation.

Framework Abstração que une códigos comuns provendo uma funcionalidade genérica.

Hash Sequencia de bits gerados através de um algoritmo de dispersão. Essa sequencia busca identificar um arquivo ou informação de forma única.

MD5 Algoritmo de hash de 128 bits unidirecional desenvolvido pela RSA Data Security, Inc. É muito utilizado para verificação de integridade e também para proteção de informações de autenticação.

PHP Linguagem interpretada projetada para aplicações web.

PostgreSQL Sistema de gerenciador de banco de dados objeto relacional de código-fonte aberto.

Python Linguagem de programação interpretada, imperativa e orientada a objetos.

76

APÊNDICE A. DETALHAMENTO DOS MODELOS DE CASOS DE USO

A.1 UC01.01 – REALIZAR LOGIN

Permite que o usuário tenha acesso ao sistema, através do fornecimento do e-mail e da

senha.

Requisitos

• RF01 : O usuário poderá se autenticar no sistema;

• RN01 : Somente os usuários autorizados a monitorar os dados de navegação podem

acessar o sistema.

Condições

• Pré-condição : O usuário não deverá estar autenticado no sistema;

• Pós-condição : O usuário estará autenticado no sistema.

A.2 UC01.02 – ALTERAR SENHA

Permite ao usuário alterar sua senha através do fornecimento da senha nova.

Requisitos

• RF08 : O usuário poderá alterar sua senha;

• RNF01 : A senha dos usuários do sistema deve ser armazenada de forma

criptografada em hash MD5 no banco de dados.

Condições

• Pré-condição : O usuário deverá estar autenticado no sistema;

• Pós-condição : O usuário terá uma nova senha para se autenticar no sistema.

77

A.3 UC01.03 – CRIAR, EDITAR E EXCLUIR USUÁRIO

Permite ao administrador criar, editar informações ou excluir um usuário do sistema.

Requisitos

• RF02 : O administrador poderá criar, editar e excluir outros usuários.

Condições

• Pré-condição : O administrador deverá estar autenticado no sistema;

• Pós-condição : As alterações na base de usuários serão aplicadas.

A.4 UC01.04 – DEFINIR OUTRO USUÁRIO COMO ADMINISTRADOR OU NÃO

Permite ao administrador definir se outro usuário será administrador ou não.

Requisitos

• RF07 : O administrador poderá definir se outro usuário é administrador ou não.

Condições

• Pré-condição : O administrador deverá estar autenticado no sistema;

• Pós-condição : O usuário será administrador ou não.

A.5 UC01.05 – GERAR RELATÓRIO BIDIMENSIONAL

Permite ao usuário gerar relatórios bidimensionais podendo-se personalizar a escolha

de um período de tempo, atributos visíveis, ordenação e filtros de atributos.

Requisitos

• RF04 : O usuário do sistema poderá acessar o relatório bidimensional;

78

• RF06 : O relatório bidimensional deverá permitira escolha de um período de

tempo, atributos visíveis, ordenação e filtros de atributos.

Condições


• Pós-condição : Gerado o relatório bidimensional.

A.6 UC01.06 – GERAR RELATÓRIO TRIDIMENSIONAL

Permite ao usuário gerar um relatório tridimensional podendo-se personalizar o

período de tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo

da terceira dimensão.

Requisitos

• RF03 : O usuário do sistema poderá acessar o relatório tridimensional;

• RF05 : O relatório tridimensional deverá permitir a escolha de um período de

tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo

da terceira dimensão.

Condições


• Pós-condição : Gerado o relatório tridimensional.

79

APÊNDICE B. DETALHAMENTO DOS MODELOS DE CLASSES

A seguir será apresentado as classes, e sua descrição, do módulo coletor e do módulo

interface de visualização.

B.1. Classes do módulo coletor

• SquidLogFile : Classe que representa os arquivos com as informações de acesso do

servidor proxy Squid;

• Squid AccessLogRequest : Classe que representa cada registro (linha) no arquivo de

informações de acesso do servidor proxy Squid, ou seja, cada acesso feito pelos

usuários será representado por um objeto da classe.

B.2. Classes do módulo interface de visualização

• User : Classe que representa os usuários que acessam o sistema de relatórios;

• Squid AccessLogRequest : Classe que representa cada registro de acesso no

servidor proxy Squid, registros esses que estão localizados no banco de dados. Ou

seja, cada objeto da classe, representa um acesso.

80

APÊNDICE C. DETALHAMENTO DO MODELO ENTIDADE RELACIONAMENTO (MODELO ER)

C.1. Tabela “user”

Tabela para o armazenamento do cadastro de usuários que acessam o módulo interface

de visualização.

Atributos:

• id;

◦ Tipo : INT;

◦ Descrição : código do usuário;

• given_name;

◦ Tipo : VARCHAR(255);

◦ Descrição : primeiro nome;

• surname;


◦ Descrição : sobrenome;

• password;

◦ Tipo : CHAR(32);

◦ Descrição : senha do usuário criptografada com hash MD5;

• is_admin;

◦ Tipo : BOOLEAN;

◦ Descrição : define se o usuário é administrador ou não;

• e-mail;


◦ Descrição : endereço de e-mail.

81

C.2. Tabela “squid_access_log_request”

Tabela para o armazenamento dos dados de acesso coletados pelo módulo coletor.

Atributos:

• id;

◦ Tipo : INT;

◦ Descrição : código identificador do registro de acesso;

• timestamp;

◦ Tipo : timestamp;

◦ Descrição : Data e hora do acesso;

• response_time;

◦ Tipo : INT;

◦ Descrição : tempo de duração da requisição;

• client_adress;


◦ Descrição : endereço IP do cliente que está acessando algum site;

• result;


◦ Descrição : resultado do cache (se veio do cache local ou do destino original);

• status_code;

◦ Tipo : INT;

◦ Descrição : Código HTTP de retorno;

• size;

82

◦ Tipo : INT;

◦ Descrição : tamanho da requisição pedida;

• request_method;


◦ Descrição : método HTTP usado;

• uri;

◦ Tipo : TEXT;

◦ Descrição : o endereço web acessado;

• user;

◦ Tipo: VARCHAR(255);

◦ Descrição: Nome de usuário, para o caso de a autenticação estiver ativada no

Squid;

• peering_code;


◦ Descrição : código informando como o servidor com o conteúdo foi alcançado;

• peering_host;


◦ Descrição : IP do servidor que forneceu o conteúdo;

• content_type;


◦ Descrição : content-type da resposta.

Modelo de TCC para o Curso de Ciência da Computação da …siaibib01.univali.br/pdf/Matheus Weber...

Documents

Transcript of Modelo de TCC para o Curso de Ciência da Computação da …siaibib01.univali.br/pdf/Matheus Weber...