FRAMEWORK DE SUPORTE PARA UM SISTEMA DE ANÁLISE DE FRAUDES EM SEGUROS

FRAMEWORK DE SUPORTE PARA UM SISTEMA DE ANÁLISE DE FRAUDES EM SEGUROS Ramon Worme dos Santos Vianna Projeto de Graduação apresentado ao Curso de Engenharia Eletrônica e de Computação da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Flávio Luis de Mello Rio de Janeiro Setembro de 2016

FRAMEWORK DE SUPORTE PARA UM SISTEMA DE ANÁLISE DE FRAUDES EM SEGUROS Ramon Worme dos Santos Vianna PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO DE ENGENHARIA ELETRÔNICA E DE COMPUTAÇÃO DA ESCOLA POLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO ELETRÔNICO E DE COMPUTAÇÃO Autor: Orientador: Examinador: Examinador: Ramon Worme dos Santos Vianna Flávio Luis de Mello, DSc Heraldo Luis Silveira de Almeida, DSc Mário Côrtes Duarte, MSc Rio de Janeiro RJ, Brasil Setembro de 2016 ii

Declaração de Autoria e de Direitos Eu, Ramon Worme dos Santos Vianna CPF 134.928.047-05, autor da monografia Framework de Suporte para um Sistema de Análise de Fraudes em Seguros, subscrevo para os devidos fins, as seguintes informações: 1. O autor declara que o trabalho apresentado na disciplina de Projeto de Graduação da Escola Politécnica da UFRJ é de sua autoria, sendo original em forma e conteúdo. 2. Excetuam-se do item 1. eventuais transcrições de texto, figuras, tabelas, conceitos e ideias, que identifiquem claramente a fonte original, explicitando as autorizações obtidas dos respectivos proprietários, quando necessárias. 3. O autor permite que a UFRJ, por um prazo indeterminado, efetue em qualquer mídia de divulgação, a publicação do trabalho acadêmico em sua totalidade, ou em parte. Essa autorização não envolve ônus de qualquer natureza à UFRJ, ou aos seus representantes. 4. O autor pode, excepcionalmente, encaminhar à Comissão de Projeto de Graduação, a não divulgação do material, por um prazo máximo de 01 (um) ano, improrrogável, a contar da data de defesa, desde que o pedido seja justificado, e solicitado antecipadamente, por escrito, à Congregação da Escola Politécnica. 5. O autor declara, ainda, ter a capacidade jurídica para a prática do presente ato, assim como ter conhecimento do teor da presente Declaração, estando ciente das sanções e punições legais, no que tange a cópia parcial, ou total, de obra intelectual, o que se configura como violação do direito autoral previsto no Código Penal Brasileiro no art.184 e art.299, bem como na Lei 9.610. 6. O autor é o único responsável pelo conteúdo apresentado nos trabalhos acadêmicos publicados, não cabendo à UFRJ, aos seus representantes, ou ao(s) orientador(es), qualquer responsabilização/ indenização nesse sentido. 7. Por ser verdade, firmo a presente declaração. Ramon Worme dos Santos Vianna iii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Escola Politécnica Departamento de Eletrônica e de Computação Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária Rio de Janeiro RJ CEP 21949-900 Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es). iv

DEDICATÓRIA Dedico este trabalho a minha família, amigos e a todos os que acreditaram e investiram em mim. v

AGRADECIMENTO Agradeço à minha família pelo apoio, ajuda, acompanhamento e investimento em meus estudos que me proporcionaram chegar até aqui e ter desenvolvido esse trabalho. Agradeço aos amigos que me acompanharam na graduação e participaram da minha formação. Agradeço aos Professores do Departamento que me ensinaram e orientaram no decurso dos anos. Mas devo um agradecimento especial ao meu orientador deste projeto, que esteve de perto acompanhando passo a passo o progresso do projeto, me dando dicas e ajudando. Agradeço também minha noiva que sempre me incentivou e me motivou para o desenvolvimento desse trabalho. Por fim devo um agradecimento ao povo brasileiro que contribuiu de forma significativa à minha formação e estada nesta Universidade. Este projeto é uma pequena forma de retribuir o investimento e confiança em mim depositados. vi

RESUMO Este trabalho consiste no desenvolvimento de um framework na plataforma web que tem a finalidade de auxiliar as seguradoras na identificação dos casos de fraudes em sinistros. Para desenvolver esse framework foram utilizados a linguagem de programação Python e o seu framework Django juntamente com o SGBD MySQL. O framework desenvolvido gerencia todo o processo de classificação de fraude dos casos de sinistros e utiliza o software chamado Mentor para a classificação. O processo inicia quando o framework obtém um arquivo de dump de uma seguradora contendo os casos de sinistros, então armazena os casos de sinistros no banco de dados interno. Com os dados armazenados o framework gera arquivos de texto com as informações necessárias para a classificação, então realiza uma comunicação socket via protocolo TCP com o Mentor solicitando a classificação. Ao fim do processo o framework lê o arquivo de resposta gerado pelo Mentor, salva no banco de dados interno as classificações e apresenta uma trilha de auditoria. O framework também possui a funcionalidade de exportar em um arquivo os casos de sinistros classificados que estão armazenados no banco de dados interno. Palavras-Chave: Framework, Seguradoras, Fraudes, Sinistros, Python, Django, MySQL, Mentor, Classificação. vi i

ABSTRACT This work is to develop a framework web platform that aims to assist insurers in identifying cases of fraud claims. To develop this framework were used the Python programming language and its Django framework along with the MySQL DBMS. The framework developed manages all fraud classification process cases of claims and uses software called Mentor for classification. The process starts when the framework gets a dump file from an insurer containing the cases of claims, and then stores the case of claims in the internal database. With the data stored, the framework generates text files with the information necessary for classification, and then performs a socket communication via TCP protocol with Mentor requesting classification. At the end of the process, the framework reads the response file generated by Mentor, saved in the internal database rankings and shows an audit trail. The framework also has the capability to export to a file the cases of claims classified that are stored in the internal database. Key words: Framework, Insurers, Fraud, Claims, Python, Django, MySQL, Mentor, Classification. vi ii

SIGLAS CPU Central Processing Unit DBMS Database Management System ETL Extract Transform Load HTML HyperText Markup Language IDE Integrated Development Environment MTV Model-Template-View MVC Model-View-Controller ORM Object-Relational Mapping SAS Sistema de Análise Estatística SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language TCP Transmission Control Protocol UDP User Datagram Protocol UFRJ Universidade Federal do Rio de Janeiro ix

Sumário 1 Introdução 1 1.1 - Tema........................................... 1 1.2 - Delimitação...................................... 1 1.3 - Justificativa...................................... 1 1.4 - Objetivos........................................ 3 1.5 - Metodologia..................................... 3 1.6 - Descrição....................................... 4 2 Ferramentas de software utilizadas 5 2.1 - A linguagem de programação Python.................. 5 2.2 - O framework Django............................... 6 2.3 - O Sublime Text.................................... 7 2.4 - O MySQL....................................... 7 2.5 - A comunicação via Socket........................... 8 2.6 - O Mentor........................................ 9 3 Configuração do ambiente 12 3.1 - Linux........................................... 12 3.2 - Processos iniciais de instalação e pacotes instalados....... 13 3.2.1 - O build-essential......................... 16 3.2.2 - O pacotes MySQL....................... 16 3.2.3 - Os pacotes Python 3...................... 17 x

3.2.4 - O pip e o virtualenv....................... 17 3.3 - Dependências iniciais do projeto....................... 17 3.4 - Iniciando o projeto.................................. 18 3.5 - Editando o arquivo de configuração do projeto............ 19 4 O framework de suporte 22 4.1 - Casos de uso e diagramas do projeto................... 22 4.2 - Estrutura do projeto................................ 26 4.3 - A app etl......................................... 27 4.3.1 - Persistindo os casos de sinistros............. 29 4.3.2 - A classe ETL............................ 30 4.3.3 - Modelo de dados do banco de dados interno... 31 4.4 - A app valuer...................................... 32 4.4.1 - O processo de classificação................ 34 4.4.2 - A exportação das classificações............. 37 4.5 - Administração do framework........................ 38 4.6 - O framework em funcionamento...................... 39 5 Conclusões e trabalhos futuros 45 5.1 - Conclusões....................................... 45 5.2 - Trabalhos Futuros.................................. 45 Bibliografia 47 xi

Lista de Figuras 2.1 Fluxo de troca de dados com sockets............................... 9 2.2 Representação esquemática dos módulos de funcionamento do Mentor.... 10 4.1 Diagrama de caso de uso do projeto................................ 23 4.2 Diagrama de sequência do projeto................................. 25 4.3 Diagrama de deployment do projeto................................ 25 4.4 Estrutura base do framework..................................... 26 4.5 Estrutura da app etl............................................. 27 4.6 Código fonte da view add_dump_file............................. 28 4.7 Código fonte da view list_request_analysis........................ 29 4.8 Simples representação esquemática do processo de armazenar os casos de sinistros no banco de dados interno.................................... 30 4.9 Classe ETL................................................... 31 4.10 O modelo do banco de dados do framework......................... 32 4.11 Estrutura da app valuer......................................... 33 4.12 Código fonte da view show_ratings............................. 34 4.13 Classe StorerCases............................................ 35 4.14 Classe RatingGenerator......................................... 36 4.15 Classe MentorClient........................................... 36 4.16 Classe RatingsRecorder........................................ 37 4.17 Código fonte da view export_ratings............................ 37 4.18 Classe ExportFileGenerator..................................... 38 4.19 Página de administração com a permissão criada..................... 39 4.20 Página de administração com usuários criados para teste............... 39 4.21 Página de login............................................... 40 xi i

4.22 Página com a mensagem informando que o usuário não tem permissão de acesso........................................................... 40 4.23 Página de início............................................... 41 4.24 Página de incluir arquivos de dump com retorno de erro............... 42 4.25 Listagem dos casos de sinistros armazenados no banco de dados........ 42 4.26 Tabela com as classificações dos casos de sinistros................... 43 4.27 Página para download do arquivo de exportação..................... 44 xi ii

Capítulo 1 Introdução 1.1 Tema Este projeto tem como tema principal o desenvolvimento de um framework na plataforma web para auxiliar seguradoras na identificação de casos de fraudes de sinistros. Neste sentido, o problema a ser resolvido é criar um framework que deve submeter as informações obtidas por uma seguradora a um classificador e retornar para a seguradora a análise realizada, que informa se o caso de sinistro é suspeito de fraude ou não. 1.2 Delimitação O projeto é direcionado a ajudar seguradoras na identificação de fraudes de sinistros, mediante a isso, o framework é desenvolvido para atender a demanda de algumas seguradoras específicas do mercado securitário. Apesar de ser construído para auxiliar algumas seguradoras específicas, existe a possibilidade de o framework atender as demais seguradoras mediante pequenas alterações para a inclusão de cada nova seguradora no framework. O projeto foi desenvolvido no âmbito do Laboratório de Inteligência de Máquina e Modelos de Computação e o software Mentor foi cedido pelo Grupo Metadox. 1.3 Justificativa As fraudes são um dos problemas mais relevantes para as empresas de Seguros no Brasil, a dificuldade de identificação de irregularidades nos casos de sinistro se torna cada vez maior, já que algumas seguradoras não fazem uso intenso de técnicas computacionais para essa identificação e apenas confiam na observação e sentimento do analista que avalia o caso de sinistro. Mesmo as seguradoras que utilizam algum 1

processo de identificação de fraudes ainda sim possuem problemas com falsos positivos e falsos negativos, pelo fato de que as técnicas acabam se tornando obsoletas com o tempo, pois os fraudadores estão descobrindo novas formas de agir e vêm se tornando mais profissionais. O extenso volume de dados contendo os casos de sinistros a serem avaliados pelas seguradoras também é outra dificuldade que impede com que a identificação de fraudes seja realizada de maneira mais eficiente e correta, pois é difícil o gerenciamento para um ser humano de um volume extenso de dados. As dificuldades apresentadas geram grandes prejuízos para as seguradoras devido ao volume de fraudes que ocorrem e não são identificadas e prevenidas. Para ilustrar esse cenário podemos analisar a pesquisa realizada pela empresa SAS [1], cuja sigla significava em sua origem sistema de análise estatística. Ela efetuou uma pesquisa no primeiro semestre de 2015 com 17 companhias de seguros no Brasil com o propósito de identificar as causas mais comuns de fraudes, desperdícios e abusos em que essas empresas são expostas, além de fazer uma avaliação das tecnologias e estratégias usadas para prevenir irregularidades. Os resultados obtidos pela pesquisa são: 59% das empresas possuem alguma tecnologia de prevenção a irregularidades no sinistro, porém menos da metade está utilizando tecnologias no processo de aceitação; 71% das empresas utilizam seus sistemas atuais há mais de cinco anos, porém são sistemas baseados em regras; 100% das empresas ainda confiam no sentimento do analista de sinistro para referenciar um caso para sindicância; O principal benefício percebido em se ter um sistema de prevenção a irregularidades é não incomodar os clientes honestos; O principal desafio em implantar um sistema mais moderno está na falta de recursos (Financeiros ou de TI). Esses resultados apresentados são a transcrição dos dados obtidos do site da empresa SAS [2]. Pelos resultados da pesquisa vemos que as tecnologias de prevenção não têm sido utilizadas no processo de aceitação pela maioria das empresas, mesmo 2

dentre as empresas que possuem alguma tecnologia apenas menos da metade delas a utilizam nesse processo. Podemos ver também que uma grande porcentagem das empresas utiliza seus sistemas atuais por mais de 5 anos. Observando esse cenário do mercado securitário e os resultados apresentados pela pesquisa, existe grande espaço para novas ferramentas tecnológicas que auxiliem as seguradoras na gestão de casos de sinistros e na identificação de fraudes nos mesmos. Novas ferramentas de qualidade ajudam na redução expressiva de prejuízos, o que possibilita preços reduzidos para os seguros, dessa forma aumentando a demanda para a contratação do serviço securitário. Aliado a esses benefícios, o framework desenvolvido proporciona melhoria e eficiência na classificação de fraudes em sinistros, pois trabalha com um classificador de qualidade, possui segurança no tratamento dos dados e retorna uma trilha de auditoria bem estruturada para facilitar o entendimento do analista de quais casos de sinistros devem ser analisados para averiguar se existe irregularidade e o porquê cada um deles deve passar pela auditoria de campo. 1.4 Objetivos O objetivo geral do trabalho é desenvolver um framework na plataforma web para gestão automatizada na classificação de casos de fraudes em sinistros. Como objetivos secundários pode-se listar a coleta de dados de maneira segura de cada seguradora, a geração de um banco de stage no framework para armazenamento do grande volume de dados dos casos de sinistros e suas correspondentes classificações, a submissão de casos de sinistros a um sistema especialista e a geração de uma trilha de auditoria com os dados armazenados em banco ao fim do processo. 1.5 Metodologia Para iniciar o projeto primeiramente foi feita uma análise de como deveria funcionar o framework, tendo como o auxílio o software Astah para a construir os diagramas de casos de uso, sequencial e de desenvolvimento. Em paralelo a essa análise foram definidas inicialmente as tecnologias a serem utilizadas para implementar o framework. 3

Inicialmente foi escolhido a linguagem de programação C# juntamente com o framework.net da Microsoft e o banco de dados SQL Server para desenvolver o framework em virtude de o servidor utilizado inicialmente ser uma máquina Windows, já que essas tecnologias são compatíveis com o Sistema Operacional. Porém, devido a imprevistos, não foi possível continuar trabalhando com o servidor Windows, então passamos a trabalhar com a plataforma Linux, dessa forma foi motivada a mudança da tecnologia utilizada para ser compatível com a plataforma, facilitar o desenvolvimento e manter a qualidade. Após a mudança de plataforma foi escolhida a linguagem de programação Python juntamente com seu framework Django, que possui uma excelente documentação. O Django pode ser integrado com tipos diferentes de banco de dados, para esse projeto foi utilizado o banco de dados MySQL. Escolhidas as tecnologias para o projeto, o projeto passou a ser desenvolvido por etapas tendo o andamento do projeto sendo acompanhado regularmente pelo orientador. É importante salientar que este trabalho dá continuidade à dissertação de Mestrado do Mário Côrtes Duarte [3]. 1.6 Descrição No capítulo 2 serão apresentadas as ferramentas de software utilizadas para desenvolver o projeto. O capítulo 3 apresenta a configuração que foi necessária para preparar o ambiente de trabalho afim de implementar o projeto. O framework em si é apresentado no capítulo 4. Nele serão explicitados os casos de uso, estrutura do projeto, funcionamento do framework e soluções para as dificuldades apresentadas. O capítulo 5 apresenta as conclusões do trabalho juntamente com propostas para trabalhos futuros. 4

Capítulo 2 Ferramentas de software utilizadas Este capítulo tem como objetivo apresentar e introduzir ao leitor um pouco sobre as tecnologias que foram utilizadas para auxiliar no desenvolvimento do framework. Inicialmente é apresentada a linguagem de programação Python, que foi a linguagem escolhida após a mudança de plataforma, juntamente com o conceito de ambientes virtuais para desenvolvimento, que foi de grande importância para o desenvolvimento do projeto. No tópico seguinte é apresentado o Django, que é um framework para desenvolvimento web em Python, e o motivo pelo qual ele foi a principal ferramenta de desenvolvimento no projeto. Nos tópicos posteriores são apresentados o editor de texto Sublime Text que foi utilizado no processo de desenvolvimento e o MySQL para gerenciar o banco de dados do framework. Nos tópicos finais são apresentados os conceitos de comunicação via Socket e o Mentor, que é um excelente software no qual é utilizado com a funcionalidade de classificador para o framework. 2.1 A linguagem de programação Python Python [4] é uma das mais populares linguagens dinâmicas de programação, juntamente com Perl, PHP e Ruby. É uma poderosa linguagem e além de simples é de fácil aprendizado, possui uma tipagem dinâmica, ou seja, o tipo de uma variável é atribuído dinamicamente, não havendo necessidade de declaração de variável. O código Python é interpretado, diferente das linguagens que necessitam ser compiladas, o Python é interpretado em tempo de execução. Python é uma linguagem de alto nível que possui uma abordagem eficiente para a programação orientada a objetos. Atualmente existem dois conjuntos de versões mais utilizados da linguagem Python, são esses o Python 2.x, que é conhecido como Python 2 [5] e já vem sendo chamado de Python legado e o Python 3.x, que é mais conhecido como Python 3 [6]. Na grande maioria das distribuições do Linux o Python 2 vem instalado como padrão no Sistema Operacional. 5

No projeto foi utilizado o Python 3 em virtude de ser a versão mais atualizada da linguagem, da base de código existente estar sendo migrado para o Python 3 e de o framework desenvolvido ser um projeto iniciado do zero, não dependendo de código legado. Como o Python padrão no Linux é o Python 2, e com o objetivo de não interferir no funcionamento do Sistema Operacional, de alguma forma, não foi alterado o Python padrão do sistema, foi necessário adotar uma estratégia para a convivência destas duas versões de linguagem de programação. Assim, para utilizar o Python 3 como padrão para o projeto, o projeto foi desenvolvido em um ambiente virtual de desenvolvimento. Um ambiente virtual de desenvolvimento permite que um projeto possa ser desenvolvido em um ambiente separado com suas dependências sendo instaladas nesse ambiente não afetando o Sistema Operacional, dessa forma múltiplos projetos podem ser desenvolvidos em paralelo, mas em ambientes diferentes com suas dependências isoladas. No projeto foram utilizadas as ferramentas Python virtualenv, que é utilizada para criar ambientes virtuais, e o virtualenvwrapper, que torna mais simples a utilização do virtualenv. Dentro do ambiente virtual do projeto foi definido o Python 3 como padrão, não interferindo assim nas configurações do Sistema Operacional. 2.2 O framework Django Django [7] é um poderoso framework para desenvolvimento web escrito em Python. Ele segue o padrão de desenvolvimento em camadas MVC (model, view, contoller), mas no Django esse padrão tem uma nomenclatura ligeiramente diferente, dessa forma em Django o padrão poderia se chamar MTV (model, template, view). O MVC é uma boa prática para montar a arquitetura do projeto, além de ser muito utilizada. Além do desenvolvimento em camadas, o Django apresenta também outras vantagens importantes como o fato de ser voltado para o desenvolvimento ágil, possuir uma grande comunidade de desenvolvedores e ser full stack (ser uma solução para tudo). O framework Django possui características importantes que auxiliam no desenvolvimento de sistemas web, entre essas características temos o fato de ele possuir roteador de urls, trabalhar com templates, validação de formulários, persistência de 6

dados (Sqlite, MySQL, Postgresql e Oracle), trabalhar com cache em memória, autenticação e permissão, possuir interface administrativa automática, biblioteca para testes, internacionalização e uma ampla documentação. Devido a todas as suas características e vantagens o Django foi a principal ferramenta para desenvolver estrutura do projeto. Após instalar o Django no ambiente virtual com apenas um comando todo uma estrutura inicial de projeto já é criada automaticamente, adiantando e auxiliando em muito o trabalho de desenvolvimento. 2.3 O Sublime Text O Sublime Text [8] é um excelente editor de código-fonte multiplataforma. Ele foi escrito em C++. Possui muitas facilidades para o desenvolvedor como por exemplo a pesquisa e substituição com suporte a expressões regulares, auto completar e correspondência de parênteses, teclas de atalho personalizáveis e edição multi-painel. Ele não chega a ser uma IDE, mas é um editor muito eficiente cumprindo ao que se propõe, não interfere no desempenho do Sistema Operacional e pode ser customizado com a instalação de plug-ins para ele. 2.4 O MySQL O MySQL [9] é um sistema de gerenciamento de banco de dados (SGBD). Um SGBD é o software responsável por gerenciar um banco de dados, ele permite criação e remoção do banco de dados, modificação dos dados no banco, remover e inserir dados, tabelas e colunas, além de outras funcionalidades de gerência no banco. Existem diferentes SGBD s no mercado, entre eles estão o SQL Server, Oracle, PostgreSQL, MySQL, entre outros. O SQL Server [10] é um SGBD desenvolvido pela Microsoft, ele possui uma ótima interface gráfica em suas ferramentas de administração, porém ele só pode ser instalado no Sistema Operacional Windows e sua versão Enterprise possui um custo de licença elevado por CPU. O Oracle [11] foi o primeiro Banco de Dados relacional a ser comercializado no mundo, ele pode ser instalado em diferentes plataformas, possui ótimos recursos de segurança e performance, porém sua licença da versão Enterprise vem com um custo ainda mais elevado que o SQL Server. 7

O PostgreSQL [12] é um SGBD com ótimas características como suporte a um grande volume de dados e tabelas, aceita vários tipos de consultas, possui um número maior de tipos de dados, e um bom mecanismo de segurança contra falha. O PostgreSQL é otimizado para aplicações mais complexas e tem a vantagem de ser gratuito. O MySQL também é gratuito, assim como o PostgreSQL, além disso tem uma ótima vantagem, que é a velocidade de acesso, que é maior comparada aos outros SGBD s e consome menos recursos da máquina. Ele é de fácil manuseio e tem uma ótima integração com Python e o Django, além de possuir um excelente desempenho e estabilidade. 2.5 A comunicação via Socket Um Socket [13] é uma abstração computacional que mapeia diretamente uma porta de transporte [14], através de um protocolo definido (como por exemplo TCP ou UDP) permitindo a comunicação em aplicações Cliente/Servidor por esse protocolo, havendo troca de mensagens entre o Cliente e o Servidor estando ambos na mesma máquina ou em máquinas diferentes. O funcionamento simplificado da comunicação via Socket acontece da seguinte maneira (Figura 2.1): existem uma ou mais aplicações implementadas, cada uma chamada de Cliente para se comunicarem com uma aplicação Servidor, que por sua vez está aberto a aceitar novas conexões. O Cliente cria um Socket utilizando um protocolo de comunicação e então tenta se conectar com o Servidor. Uma porta de conexão é atribuída pelo Servidor, e tendo estabelecida uma conexão, o Cliente envia uma mensagem ao Servidor, que recebe a mensagem e processa a informação gerando um resultado, então transmite uma resposta ao Cliente, dessa forma havendo troca de mensagens. Quando o Cliente termina a conexão, o Servidor volta ao estado de aceitar novas conexões, aguardando assim uma nova conexão de um Cliente. 8

Figura 2.1 Fluxo de troca de dados com sockets [14]. Existem muitos exemplos onde é aplicado a comunicação via socket, como por exemplo, o uso de um sensor de temperatura, ou outra grandeza física, enviando dados a uma aplicação Servidor que controla esse sensor, uma sala de chat, uma rede doméstica de computadores, comunicação web, entre outros exemplos. 2.6 O Mentor O Mentor, antigamente chamado Witty [16], é um ambiente interativo para processar conhecimento. Ele possui seis módulos interligados operacionalmente, são eles o provador automático de teoremas, processador de cadeias por casamento de padrões, estrutura sequencial de bases de conhecimento, Interface de interação com o usuário, ambiente de programação e uma linguagem de programação interpretada semelhante ao Prolog. A linguagem para representar o conhecimento é a de primeira ordem simplificada por Skolemização (método de eliminação de quantificadores existenciais). O sistema de dedução emprega o processo de refutação em resolução, onde se nega a pergunta original e se a resolução chega a uma cláusula vazia, a resposta é sim, quando não encontra cláusula vazia percorrendo todos os caminhos a resposta é 9

não. Além disso são utilizados mecanismos e recursos no Mentor para tornar sua resolução mais rápida e eficiente. Além disso, o Mentor também permite ser operado no modo Servidor, dessa forma outras aplicações podem se comunicar com ele via Socket. Mentor [16]. Figura 2.2 Representação esquemática dos módulos de funcionamento do Na Figura 2.2 está representado a estrutura de funcionamento do Mentor. O Módulo Principal se encarrega de iniciar o sistema e gerenciar o processo de execução de comandos no sistema. O Módulo Linguagens analisa os comandos que serão executados e monta a expressão que será interpretada pelo controle. O Módulo Controle se encarrega do fluxo de execução dos programas e dos comandos inseridos. O Módulo Máquina de Inferência é responsável pelo processo de dedução do sistema. O Módulo Bases de Conhecimento se encarrega de criar e fazer a manutenção do conjunto de bases de conhecimento do Mentor. O Módulo Casamento de Padrões faz o tratamento das linguagens por meio de gramáticas. O Módulo Interfaces implementa os dois tipos de interface, são eles, a interface com disco e a interface com teclado e vídeo. O Módulo Rede possui funções voltadas para a comunicação do Mentor com aplicações externas. O Módulo Máquina de Estados interpreta a máquina de estados. O Módulo Aritmética realiza funções aritméticas básicas. O Módulo Gerência de Memória gerencia a memória das execuções. 10

A arquitetura do Mentor possui certas características que foram úteis ao desenvolvimento do framework. Uma dessas características é a formulação de bases de conhecimento, no qual possibilita a criação de um ambiente onde os dados relacionados a um sinistro podem ser armazenados para o processo de dedução, não havendo mistura com os demais sinistros. Outra característica é o fato do Mentor possuir uma máquina de inferência dedicada ao processo de dedução, não havendo necessidade de implementar algoritmos para esse fim. E por fim o fato de o Mentor permitir a comunicação com outras aplicações foi fundamental para o desenvolvimento desse projeto. Os dados de cada sinistro ficam armazenados no banco de dados do framework, dessa forma é necessário que o framework se comunique com o Mentor via Socket, utilizando o protocolo TCP, para transmitir esses dados para ele e receber dele a classificação de cada sinistro para criar a trilha de auditoria. 11

Capítulo 3 Configuração do ambiente Este capítulo apresenta a configuração que foi necessária para preparar o ambiente de trabalho, dessa forma é apresentado a plataforma de trabalho, os pacotes que foram necessários serem instalados na plataforma, a criação do ambiente virtual Python e o início do Projeto. O tópico inicial trata do Linux, que foi a plataforma de trabalho escolhida. No tópico é explicado um pouco mais sobre a plataforma, definido o que são distribuições e gerenciadores de pacotes. No tópico seguinte são apresentadas as etapas iniciais de instalação explicando o passo a passo de como foi realizado, além dos pacotes que foram instalados, explicando um pouco mais sobre eles. O tópico posterior trata das instalações das dependências iniciais. O penúltimo tópico fala sobre a estrutura inicial criada para desenvolver o projeto e o último sobre a edição do arquivo de configuração do projeto. 3.1 Linux Linux [17] é o kernel (núcleo) do Sistema Operacional, que é responsável por gerenciar a CPU, memória e os dispositivos periféricos, dessa forma ele é responsável pelo funcionamento do computador fazendo a comunicação entre o hardware (impressora, monitor, mouse, teclado, etc.) e o software (programas). O Sistema Operacional é o conjunto do kernel e os programas responsáveis por interagir com este. Diferente do Mac e do Windows, o Linux é um sistema de código aberto desenvolvido por programadores espalhados pela internet. Existem diferentes versões de Linux para atender a diferentes tipos de usuários, essas versões são chamadas de distribuições (ou, numa forma mais curta, distros ). Cada distribuição tem uma diferente interface gráfica, algumas possuem interfaces mais 12

modernas, outras mais tradicionais. Alguns exemplos das distribuições mais populares do Linux são Ubuntu Linux, Linux Mint, Fedora, Debian e opensuse. Para configurar um ambiente de desenvolvimento com o fim de trabalhar em um projeto no Linux é necessário a instalação de alguns programas, esses programas são instalados no Linux a partir de um gerenciador de pacotes. O gerenciador de pacotes é uma ferramenta de software utilizada para instalar, remover e atualizar programas, e os programas são distribuídos em pacotes. Um pacote de software é um arquivo, normalmente compactado, que contém os arquivos necessários para instalar um software. A distribuição Linux escolhida para desenvolver o framework foi o Linux Mint versão 17.3 [18], que é uma distribuição baseada no Ubuntu Linux, originado do Debian, seu gerenciador de pacotes é o mesmo do Debian e chama-se apt-get, que foi utilizado para instalar os pacotes necessários para configurar o ambiente de desenvolvimento. 3.2 Processos iniciais de instalação e pacotes instalados Para iniciar a configuração do ambiente, o primeiro pacote a ser instalado foi build-essential, por que como algumas bibliotecas em Python tem extensões em C, para evitar erros futuros na instalação de outras bibliotecas é preciso ter os compiladores de C e C++ instalados, como o pacote build-essential é o que cumpre o papel de instalar as bibliotecas de C e C++, então torna-se recomendável, portanto, instalá-lo primeiro. Para instalá-lo foi necessário escrever o seguinte comando no terminal de comando do Linux: sudo apt-get install build-essential Inicialmente podemos ver que o comando começa com a palavra chamada sudo, essa palavra informa ao Sistema Operacional que o comando deve ser executado com permissão de superusuário, isso é necessário pois um novo pacote está sendo instalado ao Sistema Operacional possibilitando alterações nele, dessa forma é preciso ter permissão da conta de administrador. O termo apt-get informa ao Sistema Operacional que queremos utilizar alguma funcionalidade do aplicativo apt-get. O install, é o parâmetro passado ao apt-get para que ele procure no repositório de aplicativos, baixe e instale um determinado pacote. 13

Por fim o build-essential é o pacote a ser instalado. A instalação de qualquer pacote utilizando o apt-get no Sistema Operacional segue o mesmo padrão acima. Após solicitar a execução do comando é feita a solicitação de senha de superusuário para permitir a execução do comando. Após instalar o build-essential foi feita a instalação dos pacotes do MySQL, que é o SGBD escolhido para gerenciar o banco de dados do framework. Os pacotes MySQL são mysql-server, mysql-client, libmysqlclient-dev. Para instalá-los basta usar o comando padrão de instalação do apt-get, portanto foi escrito no terminal de comando Linux: sudo apt-get install mysql-server mysql-client No comando acima foram feitos a solicitação de instalação de dois pacotes de uma única vez, o mysql-server e o mysql-client, o apt-get aceita comandos escritos dessa forma, basta escrever um pacote após o outro separando-os por um espaço em branco. Depois foi instalado o libmysqlclient-dev, para isso foi escrito no terminal de comandos: sudo apt-get install libmysqlclient-dev O passo seguinte foi realizar a instalação do Python 3: sudo apt-get install python3 Após instalar o Python3, foi preciso instalar as ferramentas de desenvolvimento para ele, além do gerenciador de pacotes pip: sudo apt-get install python3-pip python3-dev Sendo instalado o pip, a etapa seguinte foi instalar os pacotes escritos em Python. Os primeiros pacotes que foram instalados foram os do virtualenv, que são o virtualenv e o virtualenvwrapper. A instalação de pacotes pelo pip segue o mesmo padrão que o apt-get, apenas substituindo o apt-get pelo pip. Os comandos para instalar os pacotes foram: 14

sudo pip install virtualenv sudo pip install virtualenvwrapper Para armazenar os ambientes virtuais é necessário criar um diretório para esse fim, portanto foi escrito o seguinte comando para criar esse diretório: mkdir -p ~/Django/.virtualenvs O mkdir é o comando Linux para criação de diretórios, a opção -p do comando permite a criação dos subdiretórios descritos no caminho do diretório a ser criado, caso eles ainda não existam, por exemplo, o diretório a ser criado é o.virtualenvs, caso o diretório Django não exista ele será criado. O ~/Django/.virtualenvs é caminho do diretório a ser criado, onde o ~ representa o caminho do diretório do usuário desde o diretório raiz do sistema. Para que o virtualenvwrapper funcione corretamente é necessário adicionar duas linhas de texto no corpo do arquivo.bashrc, que é um arquivo que permite algumas automatizações ao iniciar o terminal de comandos. As linhas são: export WORKON_HOME=~/Django/.virtualenvs source /usr/local/bin/virtualenvwrapper.sh A primeira linha está criando uma variável de ambiente chamada WORKON_HOME, que possui o caminho do diretório onde ficam armazenadas os ambientes virtuais de desenvolvimento. Essa variável de ambiente é utilizada pelo script do virtualenvwrapper. A segunda linha executa o script do virtualenvwrapper. O próximo passo foi criar um ambiente virtual para desenvolver o projeto. No momento de criar o ambiente virtual foi possível estabelecer qual versão do Python instalado no Sistema Operacional utilizar, então o ambiente virtual foi criado com o Python 3 como padrão. Para criar o ambiente virtual bastou digitar o seguinte comando: mkvirtualenv --python=python3 fraud_analisis 15

O mkvirtualenv é o comando do virtualenvwrapper para criar ambientes virtuais, a opção --python=python3 serve para definir a versão Python padrão do ambiente. O fraud_analisis é o nome do ambiente virtual criado. Para iniciar o desenvolvimento basta digitar no terminal: workon fraud_analisis Com o comando acima o ambiente virtual é ativado. Dentro do ambiente virtual podem ser instalados as dependências do projeto utilizando o gerenciador de pacotes pip. A primeira dependência instalada foi o Django, com o seguinte comando: pip install django No comando acima não foi necessário a utilização do sudo no comando por não haver necessidade de permissão de superusuário. Esse comando instala a última versão estável do django. Em seguida foi instalado o pacote mysqlclient, que permite a conexão do Python com o MySQL, que foi feito com o seguinte comando: pip install mysqlclient A seguir são descritos os conteúdos de cada pacote que foi instalado. 3.2.1 O build-essential O build-essential [19] instala as bibliotecas de C e C++, para compilar programas em C e C++. Algumas bibliotecas em Python têm extensões escritas em C, por esse motivo foi necessário instalar o build-essential. 3.2.2 O pacotes MySQL O MySQL foi o SGBD escolhido para gerenciar o banco de dados do framework, para tê-lo instalado no Sistema Operacional é preciso fazer a instalação de 16

alguns pacotes. Um dos pacotes é o mysql-server [20] que possui a infraestrutura requerida para configurar o banco de dados do sistema, outro é o mysql-client [21] que contém os arquivos binários do cliente e ferramentas adicionais. O último o pacote é o libmysqlclient-dev [22] que possui bibliotecas de desenvolvimento do MySQL. 3.2.3 Os pacotes Python 3 Para ter o Python 3 instalado no sistema é preciso instalar o pacote python3 [23], porém mesmo após a instalação desse pacote o Python 2 ainda permanecerá o padrão do Sistema Operacional. Para adicionar funcionalidades ao Python 3 foi instalado também o pacote python3-dev [24], que possui uma biblioteca estática e ferramentas de desenvolvimento que possibilitam construir módulos Python, tornar o seu interpretador mais extenso ou para embarcar o Python em aplicações. 3.2.4 O pip e o virtualenv O Python possui um gerenciador de pacotes próprio chamado pip. Por meio do pip podemos instalar e gerenciar pacotes escritos em Python, para utilizar o pip foi preciso instalar o pacote python3-pip [25]. Após a instalação do pip, as dependências para os projetos escritos em Python podem ser instaladas com mais facilidade. O virtualenv [26] é uma ferramenta que permite a criação de ambientes de desenvolvimento Python isolados. Por meio do virtualenv é possível trabalhar com múltiplos projetos com dependências diferentes em paralelo sem afetar o Sistema Operacional. Para auxiliar o uso do virtualenv foi instalado o virtualenvwrapper [27], que é um conjunto de extensões para o virtualenv. 3.3 Dependências iniciais do projeto A primeira dependência instalada no ambiente virtual foi o Django na versão 1.9.7 [28], que era a versão estável mais recente no início do projeto. Não é recomendado instalar o Django diretamente no Sistema Operacional, mas sim no ambiente virtual Python, para permitir o desenvolvimento de múltiplos projetos em versões do Django diferentes sem interferência entre eles. 17

A outra dependência importante instalada no ambiente virtual foi o mysqlclient [29], ele é um fork (derivação com base em um aplicativo) do MySQL-python para o Python 3. O mysqlclient é o pacote que contém o MySQLdb, que é uma interface Python para se conectar com o servidor MySQL. 3.4 Iniciando o projeto Com as dependências do projeto instaladas, o próximo passo foi iniciar o projeto. O Django é uma ferramenta com funcionalidades de automação de software, e por isso com alguns comandos ele já cria uma estrutura inicial de projeto. Para criar o projeto bastou digitar o seguinte comando: django-admin.py startproject insurance_fraud_analysis_system O django-admin.py executa ações de administração do Django, com o parâmetro startproject ele cria um diretório dentro do diretório atual com a seguinte estrutura: insurance_fraud_analysis_system / manage.py init.py settings.py urls.py wsgi.py O diretório insurance_fraud_analysis_system/, que foi criado, corresponde a estrutura inicial do projeto Django, onde cada arquivo tem uma finalidade: O manage.py é um utilitário da linha de comando que permite interagir com o projeto. O init.py é um arquivo vazio que diz ao Python que o diretório pode ser considerado um pacote Python. O settings.py é o arquivo de configurações Django do projeto. 18

O urls.py é um arquivo de declarações de URL, "tabela de conteúdo do site" O wsgi.py é um ponto de entrada para servidores web compatível com WSGI para servir o projeto. Dentro do diretório do projeto foram criados 4 outros diretórios para armazenamento de arquivos. Os diretórios criados foram: media/ sitestatic/ static/ templates/ O diretório media/ armazena os uploads de arquivos. O diretório sitestatic/ armazena os arquivos estáticos, como por exemplo: arquivos de imagem, arquivos css e arquivos javascript. O diretório static/ é para o uso do aplicativo staticfiles. O diretório templates/ armazena os templates do projeto. 3.5 Editando o arquivo de configuração do projeto O arquivo settings.py possui as configurações de projeto do Django, foi necessária a edição desse arquivo para iniciar o desenvolvimento do projeto. No início do arquivo foi adicionado a seguinte linha: # -*- coding: utf-8 -*- Esta linha é um comentário Python informando que a codificação do arquivo de configuração é utf-8. Em seguida foram adicionadas as seguintes linhas abaixo da entrada DEBUG: ADMINS = [('<Nome>,'<E-mail>'),()] MANAGERS = ADMINS 19

A primeira linha define uma lista de desenvolvedores do projeto com nome e e- mail, no lugar de <Nome> foi escrito o nome e no lugar de <E-mail> escrito o e-mail. A linha seguinte define essa lista como gerenciadores do projeto, caso ocorra algum erro em produção no projeto é enviado um e-mail para os nomes listados caso seja configurado. Existe uma lista com um dicionário Python chamado TEMPLATES, nele foi adicionado o caminho do diretório de templates do projeto na chave DIRS, a chave APP_DIRS foi estabelecida como False e na chave OPTIONS, que é um outro dicionário, foi adicionado uma chave chamada loaders para carregar os diretórios. Dessa forma o TEMPLATES passa a ser: TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.djangotemplates', 'DIRS': [ os.path.join(base_dir,'templates'), ], 'APP_DIRS': False, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], 'loaders': [ 'django.template.loaders.filesystem.loader', 'django.template.loaders.app_directories.loader', ], }, }, ] 20

Em seguida foi editado o dicionário DATABASES para incluir os dados de conexão com o MySQL. Então o dicionário ficou dessa forma: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': ' fraud_analysis ', 'USER': 'root', 'PASSWORD': '<Senha>', 'HOST': 'localhost', 'PORT': '3306', } } Em seguida foram alterados o código de linguagem e o time zone que foram editados para estarem configurados da seguinte forma: LANGUAGE_CODE = 'pt-br' TIME_ZONE = 'America/Sao_Paulo' Por fim foram incluídos os diretórios media/, static/, sitestatic/, a url correspondente do diretório media/ e uma lista de localizadores dos arquivos estáticos. Dessa forma foram incluídas as seguintes linhas: MEDIA_ROOT = os.path.join(base_dir, 'media') MEDIA_URL = '/media/' STATIC_ROOT = os.path.join(base_dir, 'static') STATICFILES_DIRS = [ ('site',os.path.join(base_dir,'sitestatic')), ] STATICFILES_FINDERS = [ 'django.contrib.staticfiles.finders.filesystemfinder', 'django.contrib.staticfiles.finders.appdirectoriesfinder', ] 21

Capítulo 4 O framework de suporte Nos capítulos anteriores foram apresentadas as tecnologias utilizadas para desenvolver o framework e as configurações do ambiente de desenvolvimento. Esse capítulo irá tratar do framework em si, apresentando diagramas de projeto, os códigos fontes de algumas partes do framework, a administração do framework e a dinâmica de seu funcionamento. Primeiramente os casos de uso do projeto serão descritos e mostrados por meio dos diagramas criados. No tópico seguinte é apresentada a estrutura do projeto desenvolvido. Os tópicos posteriores explicarão um pouco mais a fundo o desenvolvimento do framework. Já os dois últimos tópicos apresentam a administração do framework e a dinâmica de funcionamento do mesmo. 4.1 Casos de uso e diagramas do projeto Na etapa inicial de análise do funcionamento do framework foram construídos alguns diagramas. O primeiro diagrama desenvolvido foi o de caso de uso com a finalidade de estabelecer os requisitos funcionais do framework (Figura 4.1). 22

Figura 4.1 Diagrama de caso de uso do projeto. No primeiro fluxo (Fluxo 1 na Figura 4.1) entre a seguradora e o framework observamos pelo diagrama que a ideia inicial era o sistema coletar as solicitações de casos de sinistros do banco de dados da seguradora, onde a seguradora envia as solicitações de casos de sinistros ao seu banco e o framework faria uma busca por essas solicitações. Devido a impossibilidade de acesso ao banco de dados da seguradora, por questões de segurança, o mecanismo de obtenção dos casos de sinistros foi alterado. No mecanismo desenvolvido a seguradora submete um arquivo de dump do banco de dados com as solicitações dos casos de sinistros, então o framework lê esse arquivo para obter os casos de sinistros. O segundo fluxo (Fluxo 2 na Figura 4.1), que ocorre entre o framework e o banco de dados, é o processo de salvar no banco de dados do framework os casos de sinistros coletados do arquivo de dump da seguradora. Na figura o SGBD apresentado é o SQL Server, porém houve uma substituição do SGBD para o MySQL, pois houve uma mudança da plataforma de desenvolvimento para o Linux, o que motivou a escolha do MySQL para ser compatível com a plataforma. O terceiro fluxo (Fluxo 3 na Figura 4.1) é a consulta e obtenção dos casos de sinistros no banco de dados do framework. No quarto fluxo (Fluxo 4 na Figura 4.1) o framework gera um arquivo com extensão. prg para cada caso de sinistro por vez no processo de classificação, esse 23

arquivo é um arquivo texto com a formatação necessária para ser submetida ao classificador (o Mentor), todo arquivo prg gerado é armazenado no repositório de casos do framework e após ser salva a avaliação no banco de dados o arquivo prg é deletado. No quinto fluxo (Fluxo 5 na Figura 4.1) o framework trabalha com a classificação de um caso de sinistro por vez, todo o processo é síncrono, ou seja, a avaliação do próximo sinistro só é feita depois da avaliação corrente. O framework envia ao Mentor o caminho onde o arquivo prg correspondente ao caso de sinistro corrente está armazenado e solicita sua classificação ao Mentor, então o Mentor fica responsável pelos dois fluxos seguintes. No primeiro fluxo do Mentor (Fluxo 5.1 na Figura 4.1) ele busca e recebe o arquivo prg no caminho informado pelo framework, após ler o arquivo prg o Mentor classifica o caso de sinistro e no segundo fluxo (Fluxo 5.2 na Figura 4.1) ele cria um arquivo texto com a classificação e salva o arquivo no repositório de avaliações. Ao fim de cada processo, o Mentor retorna ao framework uma mensagem informando se a operação foi realizada com sucesso ou não. No sexto fluxo (Fluxo 6 na Figura 4.1) o framework busca e obtém a avaliação corrente no repositório de avaliações. Como o processo é síncrono, então o fluxo 6 só ocorre após a etapa de classificação do caso de sinistro corrente. No sétimo fluxo (Fluxo 7 na Figura 4.1) o framework lê o arquivo de avaliação do caso de sinistro corrente e salva no seu banco de dados a sua avaliação correspondente. No oitavo fluxo (Fluxo 8 na Figura 4.1) todas as classificações já foram realizadas, então o framework faz a consulta e obtém os casos de sinistros com suas avaliações. Por fim, no último fluxo (Fluxo 9 na Figura 4.1) o framework envia as avaliações para a seguradora, como o framework não tem acesso ao banco de dados da seguradora, então, ele gera um arquivo de dump para exportação apenas com os casos de sinistros avaliados da seguradora. Para facilitar a visualização de todos os processos que acontecem no framework foi criado o diagrama de seqüência (Figura 4.2), que apresenta cada processo sequencialmente como já foi descrito. 24

Figura 4.2 Diagrama de sequência do projeto. O último diagrama criado foi o diagrama de deployment (Figura 4.3), esse diagrama apresenta a estrutura física do projeto. Figura 4.3 Diagrama de deployment do projeto. Como já foi descrito, a ideia inicial era o framework ter acesso ao banco de dados da seguradora, no diagrama acima podemos ver o framework ter acesso ao banco de dados da seguradora por meio de API e criptografia, porém, como ele não tem acesso ao banco de dados da seguradora, a estrutura física passa a ser apenas o servidor. O acesso ao Mentor ocorre via comunicação socket com o protocolo TCP. Já o framework se comunica com o banco de dados pela API do Django. O acesso ao repositório, por sua vez, ocorre via chamada do sistema. 25

Em todos os diagramas apresentados está descrito que SQL Server é o SGBD do banco de dados interno do framework, o C# a linguagem de programação de desenvolvimento e o.net o framework web, isso ocorre, pois, os diagramas foram criados antes da mudança de plataforma de desenvolvimento. Como já foi apresentado, o SGBD utilizado foi o MySQL, a linguagem de programação de desenvolvimento foi o Python e o framework web foi o Django. Houve essas alterações, pois, a plataforma utilizada anteriormente para desenvolver o projeto foi o Windows em virtude de existir um servidor disponível nessa plataforma para o desenvolvimento do framework, porém, devido a imprevistos, não foi mais possível a utilização desse servidor, então foi alterada a plataforma de desenvolvimento para o Linux, motivando, então, as alterações das tecnologias utilizadas para serem compatíveis com a nova plataforma, facilitando o desenvolvimento e mantendo a qualidade. 4.2 Estrutura do projeto Com o auxílio do Django foi possível construir a estrutura do projeto de maneira organizada e clara. O projeto em si é uma app Django com duas apps menores dentro, conforme podemos ver na Figura 4.4. Figura 4.4 Estrutura base do framework. A app etl é responsável pela parte de ler o arquivo de dump, salvar os dados dos casos de sinistros no banco de dados interno do framework e listar os dados armazenados. Nessa app também é construída o modelo de dados. A app valuer é responsável pela parte de geração dos arquivos prgs, se comunicar com o Mentor, ler os arquivos de classificação e gerar a trilha de auditoria, ou seja, é responsável pelo processo de classificação dos casos de sinistro. 26

O diretório interno insurance_fraud_analysis_sytem é o projeto em si, onde são armazenados arquivos de configuração, alguns templates, arquivos estáticos, os repositórios de casos e avalições, os arquivos de dump da seguradora e os arquivos de dump com as avaliações que são exportados para a seguradora. 4.3 A app etl A estrutura da app etl é apresentada na Figura 4.5. Figura 4.5 Estrutura da app etl. Como pode ser observado, a estrutura possui arquivos comuns a apps Django, como os arquivos models.py, e views.py e outros específicos para a funcionalidade da app. Ao criar uma app com o Django alguns arquivos são gerados automaticamente. A seguir encontram-se descritos os propósitos de cada arquivo gerado pelo Django. O arquivo init.py é um arquivo em branco informando ao Python que esse diretório é um pacote. O arquivo admin.py é onde são registrados os modelos na administração do Django. O arquivo app.py é o arquivo de configuração da app. O arquivo models.py é o lugar onde são criados os modelos da aplicação. O arquivo tests.py é o lugar onde dão criados os testes da aplicação. Por fim o arquivo views.py é arquivo onde são criadas as views da aplicação. 27

Uma view é uma função Python que recebe uma requisição Web e retorna uma resposta Web. O arquivo views.py possui as duas views da app, são elas a add_dump_file e a list_request_analysis, sendo a view add_dump_file responsável por renderizar o formulário para inserção do arquivo de dump com os casos de sinistros e a view list_request_analysis responsável por renderizar uma página com uma tabela mostrando os dados dos casos de sinistros armazenados no banco de dados do framework. Na Figura 4.6 é mostrado o código fonte da view add_dump_file. Figura 4.6 Código fonte da view add_dump_file. Como pode ser observado na Figura 4.6 a view possui dois decorators Python, o @login_required e o @permission_required. Os decorators são utilizados para modificar o código em funções ou classes, os dois decorators são utilizados em todas as views do projeto. O decorator @login_required restringe o uso da página HTML gerada pela view a usuários logados ao sistema, ou seja, a view só é renderizada se o usuário está logado com uma conta ativa. O decorator @permission_required restringe o uso da página HTML a usuários que possuem permissão de acesso, a permissão de acesso é passada por parâmetro para o decorator, se o usuário não possui a permissão de acesso exigida então ele não tem acesso a página HTML. A view recebe a requisição Web por parâmetro, verifica então se o usuário está autenticado, se o usuário está autenticado ele obtém o nome da seguradora pela função get_insurer, que retorna o nome de usuário se a seguradora está logada, ou nome 28

escolhido no formulário renderizado para usuário administrador. Em seguida obtém o formulário, que possui os campos para inserir o arquivo de dump e a descrição, então o formulário é adicionado no dicionário context. Se os campos inseridos no formulário forem válidos a função run_etl_process é chamada para armazenar o arquivo de dump da seguradora, lê-lo e salvar os casos de sinistros no banco de dados. Caso a função run_etl_process retorne uma mensagem de erro então a operação não foi realizada com sucesso e a mensagem de erro é adicionada ao dicionário de contexto para ser visualizada pelo usuário juntamente com o formulário para ser preenchido novamente. Se a não houver mensagem de erro a view redireciona o usuário para uma página apenas com uma mensagem de sucesso. Ao fim a view retorna a rendrização do contexto obtido no template descrito. A Figura 4.7 mostra o código fonte da view list_request_analysis. Figura 4.7 Código fonte da view list_request_analysis. Como pode ser observado a view apresenta os mesmos decorators @login_required e o @permission_required, que já foram descritos anteriormente. A view basicamente obtém uma lista com todos os casos de sinistros armazenados, se o usuário for um administrador, ou todos os casos de sinistros armazenados para a seguradora logada e renderiza essa lista na página no formato de uma tabela. 4.3.1 Persistindo os casos de sinistros Para auxiliar o processo de salvar os casos de sinistros no banco de dados do framework foi criado um banco de dados auxiliar chamado stage. O stage é utilizado para importar o arquivo de dump fornecido. Dessa forma os dados dos casos de sinistros 29

passam a estar armazenados em uma estrutura de banco de dados. Com os casos armazenados no stage é feito então o acesso a ele para obtê-los e armazená-los no banco de dados interno com o auxílio do ORM (mapeador objeto relacional) do Django. A Figura 4.8 ilustra como o corre o processo. Figura 4.8 Simples representação esquemática do processo de armazenar os casos de sinistros no banco de dados interno. Na Figura 4.8 vemos o _import() representando o método que importa o arquivo de dump em stage e o _transform() e o _load() representando respectivamente os métodos que fazem a consulta e transformação dos dados em stage e a persistência dos dados no banco de dados interno. Esses métodos pertencem a classe ETL. Para auxiliar o acesso ao banco stage foi criado a classe DatabaseConnection, que dispõe de métodos para se conectar com um banco de dados no MySQL e fazer consultas nele. 4.3.2 A classe ETL A sigla ETL [30] representa um processo de extração, transformação e carga, para a construção de um Data Warehouse ou de um Data Mart. Para o sistema foi criada uma classe que desempenha as funções desse processo. No arquivo etl_routines.py existem funções auxiliares para criar um objeto da classe ETL e realizar outras tarefas no sistema. Devido ao fato de cada seguradora possuir estruturas diferentes de armazenamento de dados, para cada seguradora foi criada uma classe filha da classe ETL com a finalidade de obter os dados de maneira customizada para cada seguradora. O arquivo etl.py é onde foi criada classe ETL e suas classes filhas. Na Figura 4.9 podemos observar a classe ETL e seus métodos. 30

Figura 4.9 Classe ETL. O método init é o construtor da classe, onde é criado o objeto de conexão com o banco stage. Os métodos _read_dump_file_to_string e _execute_sql são métodos utilizados pelo método _import_dump para importar o arquivo de dump para o banco de stage. O método _transform realiza a consulta e transformação dos dados em stage e o método _load realiza a carga de dados no banco de dados interno do framework. O método _clean_database apaga os dados armazenados em stage após os dados serem carregados no banco de dados. Por fim o método run_services é responsável por realizar todo o processo ETL fazendo uso dos demais métodos anteriores. 4.3.3 Modelo de dados do banco de dados interno Visando facilitar o tratamento do grande volume de dados dos casos de sinistros e a geração da tabela de auditoria, o modelo de dados utilizado foi no formato de Data Warehouse [31], que corresponde a uma fonte única e completa de dados. Portanto o modelo possui apenas uma tabela com muitas colunas armazenando de forma detalhada os dados dos casos de sinistros e dados obtidos das classificações dos mesmos. Na Figura 4.10 podemos visualizar o modelo. 31

Figura 4.10 O modelo do banco de dados do framework. A tabela dispõe de colunas para armazenamento dos dados obtidos pelos arquivos de dump e os dados gerados pelas operações de importar o arquivo de dump, gerar a classificação e exportar os dados dos casos de sinistros classificados. O modelo do banco de dados foi escrito no arquivo models.py e por meio do auxílio da ORM do Django a estrutura do banco foi criada no MySQL. 4.4 A app valuer Na Figura 4.11 é apresentado a estrutura da app valuer. 32

Figura 4.11 Estrutura da app valuer. A app valuer é responsável pelo processo de classificação dos casos de sinistros armazenados no banco de dados do framework e exportar os casos classificados para serem analisados pela auditoria de campo ou não, para auxiliar esse processo foram criadas duas views. A view responsável pelo processo de classificação chama-se show_ratings, onde além de realizar esse processo a view retorna ao usuário uma tabela com uma trilha de auditoria. Na Figura 4.12 podemos visualizar o código fonte da view show_ratings. 33

Figura 4.12 Código fonte da view show_ratings. A view inicialmente obtém uma lista dos casos de sinistros armazenados para seguradora escolhida, se o usuário for um administrador, ou uma lista dos casos de sinistros armazenados da seguradora logada. Com a lista obtida, cada caso de sinistro que não foi classificado será submetido ao classificador, para isso é criado um objeto chamado rating_generator da classe RatingGenerator que recebe como parâmetro o registro do caso de sinistro. O método generate_ratings do objeto rating_generator é o responsável pelo processo de classificação de um registro de caso de sinistro, se esse método retorna uma mensagem de erro, então essa mensagem é adicionada ao contexto e o processo de classificação é interrompido. Ao fim do processo de classificação a lista com os casos de sinistros classificados são adicionados ao contexto. Por fim o contexto é renderizado no template. 4.4.1 O processo de classificação No processo de classificação um caso de sinistro é classificado por vez e ele é dividido por etapas. A primeira etapa é a geração do arquivo prg, o arquivo prg é um arquivo texto contento os dados necessários do caso de sinistro e os comandos para o Mentor poder realizar a classificação, nessa etapa o arquivo prg é gerado e armazenado no repositório de casos. A segunda etapa é enviar ao mentor o comando para carregar o arquivo prg armazenado e solicitar a classificação, essa etapa ocorre via comunicação 34

socket com protocolo TCP, o Mentor então por sua vez realiza a classificação e salva a classificação num arquivo texto no repositório de avaliações e retorna uma mensagem de sucesso ao sistema. A última etapa é a leitura desse arquivo de texto gerado pelo Mentor e o armazenamento no banco de dados da classificação obtida na leitura desse arquivo texto. Tanto o arquivo prg, quanto o arquivo de classificação do Mentor são deletados após o seu uso. Todos as etapas do processo são automáticas e gerenciadas pela classe RatingGenerator. A primeira etapa é realizada pelo objeto da classe StorerCases a segunda etapa é realizada pelos métodos da própria classe RatingGenerator, sendo que para estabelecer a comunicação socket com o Mentor foi criada a classe MentorClient, que realiza as operações de comunicação socket com o Mentor. A terceira etapa é realizada pelo objeto da classe RatingsRecorder. Nas Figuras 4.13, 4.14, 4.15 e 4.16 podemos ver as estruturas das quatro classes citadas com seus métodos. Figura 4.13 Classe StorerCases. Na classe StorerCases o método generate_prg é o responsável pela geração e armazenamento do arquivo prg, se utilizando dos demais métodos auxiliares da classe para esse fim. O método delete_prg_file é responsável por deletar o arquivo prg. 35

Figura 4.14 Classe RatingGenerator. Pode-se observar que o objeto responsável pela comunicação socket é criado no construtor da classe RatingGenerator. No construtor da classe são criados também o objeto que gera o arquivo prg e o objeto que armazena a classificação no banco de dados. O método generate_ratings é o responsável pelo gerenciamento do processo de classificação. Figura 4.15 Classe MentorClient. 36

A classe MentorClient possui os métodos necessários para a comunicação socket com o Mentor, sendo o método communicate_with_the_server responsável por realizar as etapas de comunicação. Figura 4.16 Classe RatingsRecorder. A classe RatingsRecorder possui os métodos necessários para armazenar no banco de dados um caso de sinistro classificado. 4.4.2 A exportação das classificações Para exportar as classificações realizadas foi criada uma view chamada export_ratings. O código fonte da view se encontra na Figura 4.17. Figura 4.17 Código fonte da view export_ratings. 37

Se o usuário solicitando a exportação for um administrador, então é renderizado para ele um formulário com as opções de seguradoras para exportação, ao selecionar uma das seguradoras o objeto export_file da classe ExportFileGenerator é criado com a seguradora escolhida. Porém se o usuário for uma seguradora o objeto export_file da classe ExportFileGenerator é criado com o nome de usuário. Com o objeto export_file criado, então o seu método chamado get_export_zip_file retorna o arquivo de exportação e o arquivo é adicionado ao contexto, caso ocorra algum erro na exportação ele retorna uma mensagem de erro e a mensagem é adicionada ao contexto. A Figura 4.18 mostra a classe ExportFileGenerator. Figura 4.18 Classe ExportFileGenerator. A classe ExportFileGenerator é responsável por gerar o arquivo de exportação com os dados dos casos dos sinistros classificados. 4.5 Administração do framework Para a administração do framework foi utilizado a própria app admin do Django, sem muitas alterações. A administração do framework é utilizada para criar novos usuários e permissões para o acesso ao framework. Foi criado uma permissão chamada Pode acessar a página, para que uma nova seguradora tenha acesso ao framework é necessário a criação de uma conta de usuário 38

com o nome da seguradora e com a permissão Pode acessar a página para que a seguradora tenha acesso aos serviços do framework. A Figura 4.19 apresenta a página de administração com a permissão criada e a Figura 4.20 apresenta a página de administração com os usuários criados para teste. Figura 4.19 Página de administração com a permissão criada. Figura 4.20 Página de administração com usuários criados para teste. O usuário ramon é o administrador do framework. O usuário Teste representa um usuário criado sem permissão de acessar as páginas do framework. O usuário Teste2 representa um usuário criado com a permissão de acessar as páginas do framework, porém não representa uma seguradora válida. Os usuários DPVAT e PS representam seguradoras válidas e possuem permissão de acessar as páginas do framework. 39

4.6 O framework em funcionamento A página inicial do framework é uma página de login customizada, que faz uso do sistema de gerenciamento de usuários próprio do Django. Para um usuário não logado, ao acessar qualquer rota url do framework automaticamente é feito um redirecionamento para a página de login. Se um usuário que não tem permissão para acessar as páginas ao fazer o login no framework aparece uma mensagem informando que o usuário não tem permissão de acesso. Nas Figuras 4.21 e 4.22 mostram as páginas de login e a página com a mensagem informando que o usuário não tem permissão de acesso. Figura 4.21 Página de login. Figura 4.22 Página com a mensagem informando que o usuário não tem permissão de acesso. 40

Quando um usuário com permissão de acesso faz o login no framework ele tem acesso a uma página de início com uma breve explicação da proposta do framework e um tópico de ajuda rápida. Já na página inicial é possível observar uma barra de navegação com as funcionalidades do framework e no canto superior direito da página aparece o nome do usuário logado e um link para sair do framework. A Figura 4.23 mostra a página de início do usuário logado. Figura 4.23 Página de início. Na barra de navegação temos as abas Início, Incluir, Listar, Classificar e Exportar. A aba Início corresponde a página inicial, a aba Incluir possui o formulário para inclusão do arquivo de dump, a aba Listar gera a listagem dos casos de sinistros armazenados, na aba Classificar é possível solicitar a classificação dos casos de sinistros ao framework, quando classificados o framework apresenta uma trilha de auditoria e por último a aba Exportar gera o arquivo de exportação compactado para download. Na Figura 4.24 podemos visualizar página correspondente a aba Incluir com o retorno de erro após ser inserido um arquivo de dump inválido. Caso o usuário insira arquivo inválido no campo de arquivo de dump o framework retorna o erro ao usuário no próprio formulário. 41

Figura 4.24 Página de incluir arquivos de dump com retorno de erro. Na Figura 4.25 é apresentado a listagem solicitada pelo usuário dos casos de sinistros armazenados no banco de dados, a listagem é mostrada em forma de tabela. Figura 4.25 Listagem dos casos de sinistros armazenados no banco de dados. 42

Após haver feita a solicitação de classificação dos casos de sinistros para a seguradora, o framework retorna uma tabela com os sinistros e suas classificações, podemos visualizar essa tabela na Figura 4.26. Figura 4.26 Tabela com as classificações dos casos de sinistros. Ao fim do processo o usuário pode fazer o download do arquivo de exportação como pode ser visualizado na Figura 4.27. 43

Figura 4.27 Página para download do arquivo de exportação. Um detalhe a mais das páginas Web do framework é que elas foram criadas para serem responsivas, ou seja, o design das páginas se adaptam ao tamanho da tela em que são vistas. Então as páginas mudam seu formato se forem visualizadas, por exemplo, na tela de um celular. 44