João Gabriel da Silva Santos Lucas da Silva dos Santos
Scraver: Um microsserviço para coleta de dados semiestruturados disponíveis em páginas
web estáticas e dinâmicas
Campos dos Goytacazes-RJ
Junho de 2022
Lucas da Silva dos Santos
Scraver: Um microsserviço para coleta de dados semiestruturados disponíveis em páginas web estáticas e
dinâmicas
Trabalho de Conclusão apresentado ao curso Bacharelado em Engenharia de Computa- ção do Instituto Federal de Educação, Ci- ência e Tecnologia Fluminense, como parte dos requisitos para a obtenção do título de Bacharel em Engenharia de Computação.
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
Orientador: M.Sc. Vinicius Barcelos da Silva
Campos dos Goytacazes-RJ
Junho de 2022
Elaborada pelo Sistema de Geração Automática de Ficha Catalográfica da Biblioteca Anton Dakitsch do IFF com os dados fornecidos pelo(a) autor(a).
S237s
Santos, João Gabriel da Silva
Scraver: Um microsserviço para coleta de dados semiestruturados disponíveis em páginas web estáticas e
dinâmicas / João Gabriel da Silva Santos, Lucas da Silva dos Santos - 2022.
87 f.: il. color.
Orientador: Vinicius Barcelos da Silva
Trabalho de conclusão de curso (graduação) -- Instituto Federal de Educação, Ciência e Tecnologia Fluminense, Campus Campos Centro, Curso de Bacharelado em Engenharia de Computação, Campos dos Goytacazes, RJ, 2022.
Referências: f. 63 a 65.
1. Web Scraping. 2. Microsserviço. 3. Raspagem de Dados. 4. Coleta de Dados. I. Santos, Lucas da Silva dos . II. Silva, Vinicius Barcelos da , orient. III. Título.
INSTITUTO FEDERAL FLUMINENSE CAMPUS CAMPOS CENTRO
RUA DOUTOR SIQUEIRA, 273, PARQUE DOM BOSCO, CAMPOS DOS GOYTACAZES / RJ, CEP 28030130 Fone: (22) 2726-2903, (22) 2726-2906
TERMO 9/2022 - CBECCC/DIRESTBCC/DGCCENTRO/REIT/IFFLU
13 de julho de 2022
João Gabriel da Silva Santos Lucas da Silva dos Santos
Trabalho de conclusão de curso apresentado ao Ins tuto Federal de Trabalho de conclusão de curso apresentado ao Ins tuto Federal de Educação, Ciência e Tecnologia Fluminense como requisito parcial para Educação, Ciência e Tecnologia Fluminense como requisito parcial para conclusão do curso de Bacharelado em Engenharia da Computação.
conclusão do curso de Bacharelado em Engenharia da Computação.
Aprovado em 14 de Junho de 2022.
Aprovado em 14 de Junho de 2022.
Banca Avaliadora:
Banca Avaliadora:
M.Sc. Vinicius Barcelos da Silva (Orientador) / IFF M.Sc. Vinicius Barcelos da Silva (Orientador) / IFF
D.Sc. Fernando Luiz de Carvalho e Silva (Examinador) / IFF D.Sc. Fernando Luiz de Carvalho e Silva (Examinador) / IFF D.Sc. Fábio Duncan de Souza (Examinador) / IFF
D.Sc. Fábio Duncan de Souza (Examinador) / IFF D.Sc. Luiz Gustavo Lourenço Moura (Examinador) / IFF D.Sc. Luiz Gustavo Lourenço Moura (Examinador) / IFF
Brasil Brasil 2022 2022
Código Verificador:
Código de Autenticação:
Documento assinado eletronicamente por:
Luiz Gustavo Lourenco Moura
Luiz Gustavo Lourenco Moura, COORDENADOR - FUC1 - CBECCCCOORDENADOR - FUC1 - CBECCC, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃOCOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO, em 18/07/2022 15:43:39.
Fabio Duncan de Souza
Fabio Duncan de Souza, PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃOCOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO, em 15/07/2022 18:39:25.
Fernando Luiz de Carvalho e Silva
Fernando Luiz de Carvalho e Silva, PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DACOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
COMPUTAÇÃO, em 15/07/2022 17:51:53.
Vinicius Barcelos da Silva
Vinicius Barcelos da Silva , PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃOCOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO, em 13/07/2022 21:05:01.
Este documento foi emi do pelo SUAP em 13/07/2022. Para comprovar sua auten cidade, faça a leitura do QRCode ao lado ou acesse https://suap.iff.edu.br/autenticar-documento/ e forneça os dados abaixo:
372741 302506cba6
TERMO 9/2022 - CBECCC/DIRESTBCC/DGCCENTRO/REIT/IFFLU | Página 1 de 2
Gostaríamos de começar agradecendo ao nosso bom Deus, que nos permitiu chegar até a conclusão desta etapa, com vida e saúde, nos amparando nos momentos mais difíceis ao longo do curso, e não deixando que nada viesse faltar.
Agradecemos também aos nossos familiares, que durante todo o período árduo traçado durante esses cinco anos de curso, nos deram todo o apoio que precisávamos para continuar. Sem dúvidas essa conquista também é deles.
Agradecemos ao nosso orientador, por todo o empenho, dedicação e amizade.
Esteve presente ao longo de toda a nossa trajetória dentro curso, e não foi diferente na construção deste projeto, abrindo mão do seu tempo com a família e também horas de sono, para nos auxiliar nas nossas tarefas.
Agradecemos ao Instituto Federal Fluminense campus Campos centro, com todos os seus funcionários dos mais diversos setores, que com toda certeza contribuíram de alguma forma para que este momento chegasse. Além disso, a instituição sempre propiciou um ambiente inigualável para o fomento da ciência e inovação aqui na nossa região, e sem esse amparo também, não seria possível concluir este trabalho.
Não podemos deixar de agradecer aos nossos professores do curso de Engenharia da Computação, que além de nos passar o conhecimento necessário para iniciarmos nas nossas carreiras, também nos ensinaram através dos seus exemplos, a ser cidadãos éticos e honestos.
Por fim, mas não menos importante, gostaríamos de agradecer nossos colegas de curso, que em diversos momentos agiram com atos de companheirismo, compartilhando esforços e conhecimentos para que os nossos objetivos, enquanto alunos do curso, fossem alcançados. Vocês foram peça chave nesta nossa trajetória.
Os dados são considerados por muitos o novo ouro do mundo moderno. Obtendo de fontes confiáveis e manipulando corretamente os mesmos, é possível extrair uma imensurável quantidade de conhecimento, seja qual for a natureza destes dados. O que dificulta esse processo, no entanto, é o fato de que na maioria das vezes tais dados não estão disponíveis, prontos para serem utilizados. Isso abre caminho para novos trabalhos ligados à coleta e tratamento dessas informações, como é o caso da aplicação em questão. Neste projeto, o objetivo é entregar ao usuário uma forma simples e eficiente de coletar informações que estão presentes em páginas web de forma semiestruturada, dentro do código HTML, o que resulta em um significativo ganho de tempo, principalmente para o time de desenvolvimento, onde agora os mesmos não terão que se preocupar em fazer todo o tratamento desses dados do zero. Dado que a aplicação já entrega esses dados de maneira facilitada, ela possibilita realocar recursos em outras áreas mais críticas, o que culmina em um aumento da eficiência como um todo para quem a utilizar. Apelidada de Scraver, a ferramenta foco deste trabalho foi desenvolvida nos moldes da arquitetura de microsserviço, e se mostrou eficiente em cumprir todos os objetivos específicos previamente determinados. Apesar de terem sido identificados pontos onde há espaço para melhorias, uma primeira versão de testes já se encontra disponível para uso. Em conjunto, foi desenvolvido uma aplicação como prova de conceito, que teve como objetivo principal validar o funcionamento e a eficiência da ferramenta Scraver, e que, futuramente, pode se tornar um complemento oficial, adicionando ainda mais facilidade em seu uso.
Palavras-chaves: Web Scraping, Microsserviço, Raspagem de Dados, Coleta de Dados.
Data is considered by many, the new gold in the modern world. Obtaining it from reliable sources and correctly manipulating them, it is possible to extract an immeasurable amount of knowledge, no matter the nature of this data. What makes this process difficult, however, is the fact that most of the time, such data is not available, out-of-the-box. This opens the way for new works related to the extraction and treatment of this information, as is the case for this application. In this project, the objective is to provide the user with a simple and efficient way of extracting information present in web pages, in a semi-structured way, within the HTML code, which results in a significant time save, especially for the development team, since they won’t have to worry about handling all this data from scratch. Because the application already delivers the data in an easier to work way, it makes it possible to reallocate resources in other more critical areas, culminating in an increase in efficiency as a whole. Nicknamed Scraver, the tool that this work focus on was developed along the lines of the microservice architecture, and proved to be efficient in fulfilling all the specific objectives previously determined. Despite having identified points where there is room for improvement, a first test version is already available for use. Futhermore, an application was developed, serving as a proof of concept, whose main objective was to validate the functionality and efficiency of said Scraver tool, and which in the future, can become an official complement, adding even more ease of use for the final application.
Keywords: Web Scraping, Microservice, Data Scraping, Data Collection, Data Extrac- tion.
Figura 1 – Arquitetura Monolítica x Microsserviços . . . 4
Figura 2 – Artigos retornados por cada string de busca . . . 17
Figura 3 – Trabalhos relacionados ao tema da pesquisa. . . 18
Figura 4 – Artigos selecionados por Editora . . . 19
Figura 5 – Artigos selecionados por País . . . 19
Figura 6 – Artigos selecionados por questões de pesquisa . . . 20
Figura 7 – Fluxo do processamento da requisição dentro do Scraver. . . 32
Figura 8 – Retorno dos comandos executados. . . 37
Figura 9 – Teste de performance, site nacional. . . 39
Figura 10 – Teste de performance, site internacional. . . 40
Figura 11 – Copiando a URL . . . 41
Figura 12 – Copiando o CSS Selector do dado - Parte 1 . . . 41
Figura 13 – Copiando o CSS Selector do dado - Parte 2 . . . 42
Figura 14 – Corpo da requisição a ser enviada para o microsserviço. . . 43
Figura 15 – Código 200 . . . 43
Figura 16 – Código 401 . . . 44
Figura 17 – Exemplo real de raspagem no site Fundamentus . . . 44
Figura 18 – Raspagem de dado malsucedida em site dinâmico . . . 45
Figura 19 – Raspagem de dado bem-sucedida em site dinâmico . . . 46
Figura 20 – Diagrama Geral . . . 47
Figura 21 – Diagrama Entidade-Relacionamento. . . 51
Figura 22 – Diagrama de casos de uso. . . 53
Figura 23 – Tela de login . . . 54
Figura 24 – Criação das rotinas . . . 55
Figura 25 – Lista das rotinas . . . 56
Figura 26 – Dados da última execução . . . 57
Figura 27 – Dados de todas as execuções . . . 57
Figura 28 – Parâmetros a serem informados . . . 58
Figura 29 – Dado sujo com expressão regular inapropriada . . . 59
Figura 30 – Salvando um parâmetro . . . 59
Figura 31 – Lista de parâmetros . . . 60
Tabela 1 – Artigos Selecionados . . . 18
Tabela 2 – Softwares Encontrados . . . 21
Tabela 3 – Termos ou palavras-chave . . . 69
Tabela 4 – Expressões de Busca . . . 70
API Application Programming Interface
ARFA Automated Ranking by Fundamental Analysis CRUD Create, Read, Update, Delete
CSS Cascading Style Sheet CSV Comma Separated Values
DER Diagrama Entidade Relacionamento DPO Data Protection Officer
GDPR General Data Protection Regulation HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure HTML Hyper Text Markup Language
iAIMS Integrated Agricultural Information and Management System JSON JavaScript Object Notation
JWT JSON Web Token
LGPD Lei Geral de Proteção de Dados
MB Megabyte
POC Proof of Concept QP Questão de Pesquisa
REST Representational State Transfer RPC Remote Procedure Call
SOAP Simple Object Access Protocol SSL Secure Sockets Layer
TCC Trabalho de Conclusão de Curso
VPN Virtual Private Network WSGI Web Server Gateway Interface XML Extensible Markup Language YAML Extensible Markup Language
Sumário . . . . xii
Contents . . . xiv
1 INTRODUÇÃO . . . . 1
1.1 Objetivos . . . 2
1.1.1 Objetivos Específicos . . . 2
1.2 Justificativa . . . 2
1.3 Estrutura do Trabalho . . . 3
2 FUNDAMENTAÇÃO TEÓRICA . . . . 4
2.1 Arquiteturas de serviços de software . . . 4
2.1.1 Arquitetura Monolítica . . . 5
2.1.2 Arquitetura de Microsserviços . . . 6
2.2 Application Programming Interface (API) . . . 7
2.2.1 API SOAP . . . 7
2.2.2 API RPC . . . 7
2.2.3 API REST . . . 8
2.2.4 Segurança em APIs . . . 9
2.3 Web Scraping . . . 10
2.4 Dados . . . 11
2.4.1 Dados Estruturados . . . 11
2.4.2 Dados Não Estruturados . . . 12
2.4.3 Dados Semiestruturados . . . 12
2.4.4 A Profissão . . . 12
2.4.4.1 Engenheiro de Dados. . . 13
2.4.4.2 Cientista de Dados . . . 13
2.4.4.3 DPO . . . 14
3 MAPEAMENTO SISTEMÁTICO DA LITERATURA. . . 15
3.1 Mapeamento Sistemático da Literatura com foco em aplicações de coleta e tratamento automática de dados e Serviços de coleta de dados Financeiros disponíveis na web . . . 15
3.1.1.1 Expressões de busca e artigos retornados . . . 16
3.1.1.2 Artigos Selecionados . . . 18
3.1.2 Resultados . . . 19
3.1.3 Considerações Finais sobre o Mapeamento Sistemático . . . 22
4 TECNOLOGIAS UTILIZADAS . . . 24
4.1 Python . . . 24
4.1.1 Regex . . . 24
4.1.2 Beautifulsoup . . . 25
4.1.3 Selenium . . . 25
4.1.4 Flask . . . 26
4.1.5 Módulo WSGI. . . 27
4.2 Docker . . . 27
4.2.1 Docker Compose . . . 28
4.3 Apache2 . . . 28
4.4 PostgreSQL . . . 28
4.5 Dart . . . 29
4.5.1 Flutter . . . 30
4.6 Mozilla Firefox . . . 30
5 DESCRIÇÃO DO MICROSSERVIÇO . . . 31
5.1 Microsserviço Scraver . . . 31
5.2 Instalação . . . 35
5.3 Raspagem de Dados . . . 37
5.3.1 Sites estáticos. . . 37
5.3.2 Sites dinâmicos . . . 37
5.3.3 Comparação entre os tipos de raspagem . . . 38
5.4 Parâmetros e execução . . . 40
5.4.0.1 Parâmetros . . . 41
5.4.1 Execução . . . 43
6 PROVA DE CONCEITO . . . 47
6.1 Arquitetura geral do sistema . . . 47
6.2 Prova de Conceito . . . 49
6.2.1 Diagrama Entidade-Relacionamento . . . 50
6.2.2 Diagrama de Casos de Uso . . . 52
6.2.2.1 Fazer login . . . 53
6.2.2.2 Criar rotina . . . 54
6.2.2.3 Listar rotinas. . . 55
6.2.2.5 Listar parâmetros . . . 59
7 CONSIDERAÇÕES FINAIS . . . 61
7.1 Trabalhos Futuros . . . 61
REFERÊNCIAS . . . 63
APÊNDICE A – MAPEAMENTO SISTEMÁTICO DA LITERATURA COM FOCO EM APLICAÇÕES DE COLETA E TRATAMENTO AUTOMÁTICA DE DADOS E SERVIÇOS DE COLETA DE DADOS FINANCEI- ROS DISPONÍVEIS NA WEB . . . 67
A.1 Introdução . . . 67
A.1.1 Problema de pesquisa e contexto . . . 67
A.1.2 Justificativa . . . 68
A.1.3 Objetivo do mapeamento da literatura . . . 68
A.1.4 Questões de Pesquisa . . . 68
A.2 Métodos e Recursos . . . 68
A.2.1 Estratégia de busca . . . 68
A.2.1.1 Ferramentas . . . 68
A.2.1.2 Idiomas e Período . . . 69
A.2.1.3 Termos ou palavras-chaves . . . 69
A.2.1.4 Expressão de Busca . . . 69
A.2.1.5 Critérios para avaliar a expressão de busca . . . 69
A.3 Estratégia de seleção . . . 70
A.3.1 Critérios de Inclusão . . . 70
A.3.2 Critérios de Exclusão . . . 71
A.3.3 Procedimentos de Seleção . . . 71
A.4 Estratégia para extração de dados e análise . . . 71
A.4.1 Classificação dos dados . . . 71
A.4.2 Instrumentos de coleta de dados . . . 72
A.4.3 Procedimentos . . . 72
A.5 Ameaças à validade . . . 73
1 INTRODUÇÃO
Em 2020 foi estimado que 1.7 MB de dados foram criados a cada segundo para cada pessoa do planeta (DOMO, 2020), e as pesquisas mostram que esse número só tende a crescer com o passar do tempo.
Um fato interessante é que cerca de 90% desses dados se enquadram na categoria de não estruturados e semiestruturados, sendo a maioria deles provenientes de páginas web, mídia social, fotos digitais, serviços e Internet das Coisas (MARR, 2019). Somente os 10% restantes são de dados estruturados, isto é, aqueles com estrutura bem definida e, normalmente, menos complexos de analisar. Além disso, a categoria de dados semiestrutu- rados não é uma definição com 100% de adesão por parte dos pesquisadores, e dependendo do autor, alguns tipos de dados "semiestruturados"são considerados como não estruturados e vice-versa.
É conhecimento comum a grande importância de se trabalhar com dados nos dias atuais, porém esse trabalho ainda continua sendo um grande desafio para as empresas.
Essas empresas enfrentam diversas barreiras na tentativa de, além de trabalhar com dados, transformá-los em insights úteis. Duas dessas barreiras são o deficit de habilidades gerado pela falta de força de trabalho especializada e a dificuldade na descoberta dos dados, devido, por exemplo, a má qualidade dos dados (e das formas de armazenamento dos mesmos), fontes de dados desconhecidas e de difícil extração, entre outros motivos (FRICKE, 2021).
Por outro lado, surgem como efeito dessa alta demanda, muitos estudos científicos e aplicações voltados ao assunto de tratamento e análise de dados livres na internet. A medida que as empresas aprendem a lidar com essas tecnologias e métodos, e passam a colocar em prática no seu dia a dia todo esse conhecimento, vemos mais e mais a crescente evolução desses campos. Além disso, evoluem também, ao mesmo tempo, as práticas realizadas pelas empresas, como a maneira com que elas desenvolvem seus produtos, gerenciam seus clientes e principalmente, prospectam suas marcas e negócios.
Apesar disso, um ponto notável dessa área é que se desenvolve muita tecnologia para, uma vez em posse dos dados, trabalhar em cima deles a fim de transformar dados brutos em informações úteis. Podemos citar como exemplo a evolução da área de Machine Learning, no qual uma vez que a empresa já possua os dados, manipular grandes massas de dados ficou muito mais fácil nos dias atuais, devido a grande quantidade de bibliotecas existentes nas principais linguagens de programação. Porém, a coleta e adequação do formato dos dados muitas vezes é deixada na responsabilidade do usuário/cliente, ou dada menos importância, mesmo sendo uma tarefa muitas vezes extremamente custosa no que
diz respeito ao tempo e aos recursos.
Assim, o que presente trabalho propõe, é uma ferramenta que trabalha no início do processo de transformar dados brutos em informação útil, ou seja, na coleta. Uma ferramenta independente e adaptável, capaz de recuperar dados disponíveis nawebe fornecê- los de maneira automatizada, prontos para utilização, de acordo com a configuração feita pelo usuário da ferramenta.
1.1 OBJETIVOS
O objetivo geral deste projeto é desenvolver um sistema que seja capaz de coletar e fornecer dados da web (estruturados ou não) de maneira automática, retirados de diversas fontes de informação segundo a necessidade do usuário, diminuindo drasticamente o tempo de codificação de aplicações que venham usar esses dados a fim de gerar algum valor para empresas ou usuários comuns.
1.1.1 Objetivos Específicos
Dentre os objetivos específicos deste trabalho, destacam-se:
• O1: Desenvolver a funcionalidade de coleta de dados em sites estáticos;
• O2: Desenvolver a funcionalidade de coleta dados em sites dinâmicos;
• O3: Criar um microsserviço único, com as duas funcionalidades previamente de- senvolvidas, disponibilizando as rotas que receberão os argumentos provenientes do usuário;
• O4: Encapsular toda a aplicação utilizando containers Docker;
• O5: Disponibilizar a aplicação para uso como serviço, através de uma plataforma na nuvem, em estágio de testes;
• 06: Desenvolver uma PoC (Proof of Concept), simulando uma aplicação real que consuma o microsserviço, de forma a testar a viabilidade técnica, a capacidade de integração e o funcionamento propriamente dito da solução objetivo deste trabalho.
1.2 JUSTIFICATIVA
É evidente que há uma crescente necessidade do mercado em trabalhar com grandes volumes de dados. Temas como Big Data e Data analysis estão sempre presentes nos times de estratégia das empresas, e torna-se um desafio adequar todos os processos já
existentes na corporação para processos que venham ser orientados a dados. A existência de ferramentas que agem sobre essa "dor"é de grande importância.
A ferramenta a ser desenvolvida e apresentada neste trabalho mostra-se então uma grande candidata à assumir esse papel, entregando de maneira simples e transparente ao usuário dados estruturados de basicamente qualquer página web, de maneira simples e intuitiva, sem a necessidade de criar códigos específicos para cada aplicação.
Sua implementação pode mudar a forma com que as empresas lidam com dados, pois tornará muito mais fácil fazer a captura e, consequentemente, o tratamento dos mesmos. Assim, recursos que antes seriam usados para tais tarefas, serão agora liberados para uso em outros campos e necessidades dessas empresas.
É importante salientar também que, uma vez que as funcionalidades dessa fer- ramenta serão encapsuladas em um microsserviço único, com uma API conhecida e documentada, torna-se fácil integrá-la com os sistemas existentes das empresas. Assim, não há necessidade de grandes reformualações de aplicações, ou criação de intermediários ou novos sistemas, pois a solução proposta é completamente independente, modular e integrável.
Resumindo, de um lado estão os dados que contém a informação necessária para a realização de um negócio, e do outro, a empresa e os desenvolvedores, com as ferramentas para processar esses dados. É neste meio/lacuna que o software proposto neste projeto pretende se inserir.
1.3 ESTRUTURA DO TRABALHO
Este trabalho será dividido em capítulos, como apresentado a seguir. O Capítulo 1 expõe o contexto, as justificativas e os objetivos desta pesquisa. O Capítulo 2 apresenta conceitos e definições sobre os diversos temas englobados pelo trabalho, além das teorias existentes que contribuem para o desenvolvimento deste projeto. O Capítulo 3 descreve os resultados do Mapeamento Sistemático da literatura realizado no início do desenvolvimento deste trabalho. O Capítulo 4 dispões das ferramentas, tecnologias e técnicas utilizadas no desenvolvimento do projeto e da aplicação. O Capítulo 5 descreve a estrutura do sistema desenvolvido, os documentos que permitem um melhor entendimento da aplicação e foca em esclarecer as principais funcionalidades disponíveis. O Capítulo 6 trata da aplicação prova de conceito desenvolvida, a estrutura geral do sistema (que inclui o microsserviço e a PoC), os documentos que os descrevem, a maneira como o microsserviço e a PoC interagem, além de uma visão geral do funcionamento e utilização desse sistema. Por fim, oCapítulo 7 apresenta as considerações finais a cerca do desenvolvimento do projeto, além de apresentar as pretenções futuras que envolvem o mesmo.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta a fundamentação teórica do trabalho, trazendo as caracte- rísticas e conceitos inerentes à área de estudo deste projeto, além de informações a respeito do contexto/mercado para o qual o sistema foi desenvolvido.
2.1 ARQUITETURAS DE SERVIÇOS DE SOFTWARE
Arquitetura de software é um padrão, uma solução (normalmente já testada e documentada) que define a estrutura de um programa/sistema. O conceito, que vem da mesma ideia utilizada na área de arquitetura, serve para definir e descrever um "formato"de sistema que possua uma série de vantagens (o máximo possível) e desvantagens (o mínimo possível), de forma a ser mais indicada para casos ou aplicações específicas.
Figura 1 – Arquitetura Monolítica x Microsserviços
Fonte: Elaborada pelo Autor (2022).
Duas das principais e mais utilizadas arquiteturas de hoje em dia são a Monolítica
e a de Microsserviços. A Monolítica, mais antiga e amplamente estabelecida, ainda existe em muitos projetos (legados e correntes), mas segue em decrescente adesão em relação a de Microsserviços, mais nova e moderna, que surge para combater alguns problemas existentes na primeira.
Na Figura 1 é possível observar a principal diferença entre as duas. A arquite- tura Monolítica, altamente acoplada, tem todas as funções compondo um único grande processo, enquanto a arquitetura de microsserviços separa as funcionalidades em blocos independentes, cada um com suas devidas responsabilidades. Ambas as arquiteturas tem especificidades e serão discutidas adiante.
2.1.1 Arquitetura Monolítica
A arquitetura monolítica é um padrão para desenvolvimento de software mais comum e antigo em relação a Arquitetura de Microsserviços. Segundo Machado (2017), a Arquitetura Monolítica de um sistema complexo pode ser representada por um único processo onde estão implementadas todas as funções de negócio, de forma que, com o passar do tempo, o sistema se torna maior, mais complexo e consome mais recursos, o que pode se tornar um problema substancial no futuro. A arquitetura monolítica, para Machado (2017), pode ser caracterizada por:
• Aumento de tamanho/complexidade com o passar do tempo;
• Escalabilidade Limitada;
• Alta dependência de componentes de código;
• Dificuldade de Alteração;
• Falta de flexibilidade no desenvolvimento.
Apesar desses problemas, é importante notar que a arquitetura monolítica, apesar de mais antiga, possui vantagens e aplicações, como relata Souza (2017). Entre as vantagens, pode-se considerar as principais delas como o desenvolvimento simplificado (principalmente para pequenas aplicações), simplicidade de instalação (deploy), visto que costuma ser apenas a instalação de um único grande pacote, além de escalonamento intuitivo, bastando ter réplicas da aplicação rodando paralelamente atrás de um balanceador de carga.
Dessa forma, é possível observar que há aplicabilidade para esse tipo de arquitetura, que inclusive ainda é bastante usada nos dias de hoje, porém, como veremos adiante, a arquitetura chamada de "microsserviços"apresenta outras vantagens que também a tornam muito atrativa para o mercado de desenvolvimento de software atual.
2.1.2 Arquitetura de Microsserviços
A Arquitetura de Microsserviços, assim como a Monolítica, também é um padrão para desenvolvimento de software, que nesse caso vem ganhando muita força e notoriedade nos últimos tempos. Segundo Machado (2017), é caracterizada por definir o desenvolvi- mento de sistemas como um conjunto de pequenos serviços, cada um funcionando em seu próprio processo, seguindo regras de negócio específicas e implementados de maneira independente. A Arquitetura de Microsserviços se caracteriza, ainda segundo Machado (2017), por:
• Baixo nível de Acoplamento/Interdependência;
• Alta Escalabilidade;
• Redução de custos;
• Maior facilidade/estabilidade da manutenção, evolução e alteração dos serviços;
• Maior flexibilidade quanto ao desenvolvimento.
SegundoSouza (2017), a ideia da arquitetura de microsserviços vem da utilidade de criar pequenas unidades independentes de software, que podem ser atualizadas e substituídas individualmente. Usando o conceito de serviços como componentes, é possível decompor uma grande aplicação em múltiplos serviços que se relacionam através de algum tipo de comunicação, com interfaces bem definidas, garantindo as vantagens citadas anteriormente.
Outra vantagem interessante é que, se aplicada corretamente, a arquitetura de microsserviços torna mais natural o desenvolvimento seguro das aplicações, pois permite dividir as responsabilidades do sistema, de forma que apenas aquilo que realmente deve ser acessível ao usuário seja exposto ao mesmo. Nesse caso, o que é crítico para o sistema e deve ter acesso restrito e bem regrado, pode ficar "escondido"do acesso público.
Porém, é importante ressaltar que assim como a arquitetura monolítica, a ar- quitetura de microsserviços possui seus problemas e desvantagens. Em comparação a monolítica, pode ser um desperdício o uso dessa arquitetura em aplicações pequenas, pela maior complexidade de implementação. Além disso, uma vez que os serviços se comunicam por chamadas remotas, isso significa um maior custo em desempenho, que deve ser levado com seriedade, principalmente quando trabalhado em sistemas críticos.
Tendo em vista a crescente adesão pela arquitetura de microsserviços, sua po- pularidade nos dias de hoje e todas as vantagens que ela trás para o desenvolvimento, principalmente na independência e modularidade das funcionalidades, além da facilidade de integração com outros sistemas, é nos conceitos dela que este trabalho se baseia.
2.2 APPLICATION PROGRAMMING INTERFACE (API)
API (Application Programming Interface) pode ser entendida como um conjunto de instruções, rotinas e padrões de programação que permite a comunicação com um aplicativo (um microsserviço, por exemplo), de forma que outro aplicativo possa "enten- der"as instruções do primeiro e possa o "utilizar"(ou consumir) com algum fim específico (RIBEIRO, 2016).
Na prática, a API faz o papel de "tradutor", permitindo que duas aplicações se comuniquem independente da maneira como foram desenvolvidos, da linguagem de programação usada, ou da arquitetura na qual se baseiam. Elas podem ser classificadas quanto a utilização ou a maneira que foram criadas (tecnologia utilizada), sendo elas, segundoRibeiro(2016), APIs financeiras, APIs de CRM, APIs de ERP, APIs de programas gráficos, entre outras; ou ainda quanto a tecnologia utilizada, tais como APIs Rest, APIs SOAP e as APIs RPC.
2.2.1 API SOAP
O protocolo SOAP (Simple Object Access Protocol), é uma especificação para troca de informação entre sistemas, definindo o formato de dados a ser utilizada, com um padrão para interoperabilidade entre serviços (ATTORRE, 2015). Essa comunicação pode ocorrer independente da plataforma na qual o serviço é executado ou a linguagem na qual é desenvolvido.
Diferente do REST, SOAP é um protocolo, e por conta disso, é bem mais regrado e "restritivo", o que gera uma série de vantagens e desvantagens. O site da RedHat (2021) descreve as principais desvantagens do SOAP, tais como: o aumento de complexidade e sobrecarga do serviço web desenvolvido, o que aumenta a lentidão no carregamento de páginas (causado, por exemplo, pelo uso de XML como formato de arquivo para troca de informação), já as principais vantagens, sendo a conformidade integrada (por ser um padrão com regras bem delimitadas) e a inclusão de padrões de segurança e ACID (propriedades que objetivam assegurar transações confiáveis de bancos de dados).
2.2.2 API RPC
API RPC (Remote Procedure Call) são aquelas que fazem requisições síncronas sem um padrão observável de interface (não são REST, por exemplo), seguindo a ideia de chamadas de procedimentos remotos. A chamada de procedimentos remoto, como no nome desse padrão, e segundo Nally (2018), funciona da mesma maneira que chamar uma função numa linguagem de programação comum, porém, usa um protocolo de rede (por exemplo, e mais comumente, HTTP) para fazer a chamada ao procedimento que está
numa máquina remota. Parte das vantagens do RPC é que, muitas vezes, essas chamadas são muito parecidas, sintaticamente, com as chamadas comuns de funções, e aprender a usar é tão fácil quanto aprender a usar uma nova biblioteca.
APIs RPC podem utilizar diferentes "protocolos", todos seguindo o formato RPC, porém diferindo na estrutura de dados utilizada para realizar a comunicação entre cliente e servidor. Exemplo deles são APIs XML-RPC e JSON-RPC, que diferem entre si pelo uso de do XML (linguagem de marcação extensível) ou do formato JSON (Notação de Objeto Javascript).
Além disso, por ser um padrão menos restrito, é possível utilizar estruturas de dados customizadas para a comunicação. Apesar disso, é um padrão de API não muito mais utilizado, pois foi, em parte substituído, em parte "absorvido", pelo REST, que ficou mais popular por permitir uma comunicação mais direta de dados, com a utilização de parâmetros reduzidos nas chamadas, simplificando o desenvolvimento, além da adoção do REST por grandes empresas como Facebook e Twitter (entre outros).
É importante ressaltar também que, apesar da adoção preferencial do REST nos dias de hoje, muitas APIs, as vezes, até sem saber, implementam misturas da arquitetura RPC com REST, o que, no fim, não é certo ou errado, entretanto mostra que nem sempre é preciso escolher um único padrão para desenvolvimento de APIs, desde que feito conscientemente, de acordo com a necessidade.
2.2.3 API REST
Uma API REST é uma interface de programação que respeita as restrições definidas pela arquitetura REST (Representational State Transfer), Transferência Representacional de Estado, em português (REDHAT, 2020a).
O REST não chega a ser um protocolo ou um padrão, mas sim um conjunto de princípios de arquitetura. Para que uma API seja considerada RESTful, segundo RedHat (2021) ela precisa atender os seguintes critérios:
• Possui Interface Uniforme;
• Usar conexão sem estado (ComunicaçãoStateless);
• Faz uso eficiente de Cache;
• Segue arquitetura dividida em recursos e relação cliente-servidor;
• Sistema desenvolvido em camadas (hierarquização da comunicação cliente-servidor);
• Opcionalmente, implementar código sob demanda (transferência de código executável do servidor para o cliente);
Normalmente utilizada para comunicação via protocolo HTTP, APIs REST cos- tumam ser mais flexíveis e adaptáveis do que os padrões anteriores, mais antigos. Isso acontece por REST não ser em si, um padrão, mas funcionar mais como "recomendações".
Isso significa que, de acordo com o caso e as necessidades da aplicação, ela pode ser adaptada para melhor se encaixar no que é preciso para o sistema em questão.
Isso claro, não ocorre sem desvantagens. Não ter definições muito restritas e bem regradas faz com que as APIs precisem ser muito bem documentadas e feitas seguindo padrões de código e segurança bem pensados, para que, além de segura, a API seja fácil de usar e integrar. Porém, as vantagens vem se mostrando maiores que as desvantagens, visto o crescimento constante na utilização desses tipos de APIs, e por esses motivos, este trabalho adotou o REST para desenvolvimento da API utilizada na comunicação com o microsserviço objetivo do projeto.
2.2.4 Segurança em APIs
A segurança das APIs é de suma importância, pois APIs desprotegidas ou hackeadas podem causar sérios problemas de violação de dados, expondo publicamente, por exemplo, dados pessoais, financeiros, entre outros (REDHAT, 2020b).
Algumas práticas comuns de segurança de APIs são:
• Uso de tokens;
• Uso de gateway de API;
• Uso de cotas e limites de chamadas;
• Identificação de Vulnerabilidades;
• Uso de criptografia e assinaturas.
O uso de tokens permite verificar se determinada requisição veio de um cliente autorizado, funcionando de forma semelhante a uma senha. Os Gateways de API, por sua vez, funcionam como centralizadores de tráfego da API, fazendo controle e análise de uso, além de permitir autenticação do tráfego para a API. O uso de cotas e limites de chamadas por fim, limita a liberdade de um possível atacante de fazer chamadas a API, além de auxiliar na detecção de problemas de programação.
O uso de criptografia/assinaturas deve ser considerado sempre que se tem uma aplicação web, principalmente quando há tráfego de informações sensíveis, além disso, identificar vulnerabilidades deve ser parte tanto do desenvolvimento quanto da manutenção das APIs, pois permite identificar os pontos fracos e vulneráveis da aplicação que devem ser reforçados, além de possibilitar a melhora contínua do serviço desenvolvido.
Essas práticas, descritas porRedHat(2020b), podem ser entendidas como exemplos que são importantes para a segurança de APIs, mas a segurança das APIs não estão restritas somente a elas. O entendimento do desenvolvedor, a utilização de bibliotecas, frameworks e linguagens populares e confiáveis, com comunidades fortes, e boa manutenção/taxa de atualização também contribuem para garantir a segurança da aplicação.
Para este trabalho, além das boas práticas na codificação e uso de ferramentas, foi utilizado o sistema de tokens como método primário de segurança. A aplicação PoC que se conecta ao microsserviço utiliza-se de tokens, onde cada usuário cadastrado no sistema possui o seu próprio (no esquema de chave de integração), garantindo assim, que somente usuários autorizados tenham acesso aos dados coletados e organizados pela aplicação. Esse esquema foi adotado pois é uma maneira simples mas bastante utilizada para comunicação entre sistemas, principalmente em ambiente interno de rede (fora da internet ou com uso de VPN).
Para uma versão final da aplicação, é sabido que o uso de uma forma mais atual e desenvolvida de token, como o JWT (JSON Web Token) seria preferível, assim como o uso de conexão criptografada via SSL (Protocolo HTTPS). Porém, considera-se que apenas a efeito de Prova de Conceito, não se fez necessário o uso desses métodos.
2.3 WEB SCRAPING
Web Scraping pode ser entendido como uma espécie de "garimpo"da internet.
Segundo Moraes (2018), Web Scraping envolve extrair informações relevantes de sites para posterior utilização em análises ou outros fins.
A ideia por trás doWeb Scraping é que essa é uma tarefa que poderia ser realizada manualmente. Porém, com essas técnicas, pode-se automatizar o trabalho através de
"bots"("robôs"). Dada a natureza do Web Scraping de coletar dados de sites "públicos", é importante verificar as questões legais e morais antes de utilizar dessas técnicas, pois essas questões podem diferir para uso pessoal, comercial, e muitas vezes, para fazer uso, pode exigir permissão do detentor dos direitos daqueles dados.
Para o escopo deste projeto, a ferramenta desenvolvida trata de maneira genérica a parametrização e coleta de dados disponíveis em qualquer site da web. Dessa forma, fica a
cargo do usuário que utilizar a ferramenta/implementar o microsserviço em seus sistemas, garantir o uso correto e íntegro, seguindo os termos de serviço do site onde os dados forem coletados. Para aplicação PoC desenvolvida para se conectar ao microsserviço, os dados coletados para testes vieram sempre de fonte de acesso público e, ainda assim, não foram usados para nenhum fim além de comprovar o funcionamento da aplicação.
OWeb Scraping surge como uma opção interessante de coleta de dados públicos, pois permite que a coleta ocorra de maneira automatizada. Essa característica pode gerar oportunidades de negócio interessantes, visto que, não só permite a aquisição de dados mais precisos, mas faz isso sem a necessidade de utilizar um intermediário humano na coleta e tradução da informação.
Sendo assim, o uso dessas técnicas oferece grandes vantagens, como a economia de tempo e esforço na coleta de dados, a geração de insights interessantes para o desenvolvi- mento de negócios, a viabilização de coletas de dados mais precisas, diretamente da fonte, evitando erros humanos e mudança dos dados no caminho, entre outras.
2.4 DADOS
Dados, segundo Zins (2007), são símbolos/sinais "captados"e armazenados, que incluem palavras, números, diagramas e imagens, além de, num conceito mais amplo, também leituras sensoriais de luz, cheiro, som, gosto e tato. Eles se diferenciam da informação que é composta por comunicação e os próprios dados, e tem significado relevante e implicação por si só. Os dados, por conta própria, são "representações de um significado", mas sozinhos, não tem significado em si, portanto, eles são uma representação
"histórica"de algo, que para ter significado precisa ser transformado.
Tratamos como dados da web, os dados que estão disponibilizado através de páginas na internet, como fotos, texto, gráficos, diagramas, entre outros. Esses dados ficam disponíveis e, quando captáveis através do HTML da página, se torna possível a extração automatizada dos mesmos, objetivo deste trabalho.
Estes dados podem ser agrupados em categorias, de acordo com a maneira como são disponibilizados, e a forma/nível de organização dos mesmos, entre Estruturados, não estruturados e semiestruturados. Essas categorias serão mais discutidas a seguir.
2.4.1 Dados Estruturados
Os dados estruturados são aqueles organizados e representados com uma estrutura rígida, a qual foi previamente planejada para armazená-los (GRANCONCURSOS, 2020).
Nesse tipo, os dados brutos são, por exemplo, mapeados de modo a representar campos
(estrutura campo-valor), não permitindo que tipos de dados diferentes das estruturas preestabelecidas sejam carregados.
Por ter estrutura bem definida, esses dados normalmente são de análise facilitada em comparação aos demais, e são uma das principais formas de armazenamento de dados, na área de computação e sistemas de informação nos dias de hoje, através dos bancos de dados relacionais.
2.4.2 Dados Não Estruturados
Esses dados não possuem estruturas bem definidas, alinhadas, padronizadas, po- dendo ser compostos por diversos elementos diferentes dentro um todo (DIGITALHOUSE, 2020). São dados em forma bruta, mais difíceis de analisar (por sua natureza complexa), e estão presentes de diversas formas, como postagens de redes sociais, imagens, informação provenientes de sensores, entre outros.
Um exemplo de dado não estruturado bem comum, mas simples de entender, são os textos planos. Um texto, como o de uma reportagem, o corpo de uma mensagem, etc, não tem uma estrutura definida. Ele é escrito por uma pessoa e, apesar de, ao ler, ter significado para seres humanos, no ponto de vista de análise de dados, ele não tem uma estrutura definida e padronizada, que permita retirar significado de maneira facilitada apenas coletando as palavras ali escritas.
2.4.3 Dados Semiestruturados
Dados semi-estruturados são dados que não são armazenamos em um banco de dados ou em qualquer outra tabela de dados, mas possuem algumas propriedades internas organizadas (CULTURAANALíTICA,2018). Dados não estruturados que possuem alguma característica consistente/definida, e portanto, são um meio-termo entre os outros dois tipos, acabam sendo classificados como semiestruturados. Um exemplo, em alguns casos, seriam as imagens digitais com metadados, uma vez que não possuem estrutura na imagem em si, mas sim alguns atributos (os metadados) que ajudam a definir suas propriedades.
Alguns autores também consideram as mensagens de e-mail como um tipo de dados semiestruturado. Isso acontece, pois apesar de conter campos estruturados, como remetente, assunto, destinatário, que seguem estrutura definida chave-valor, o corpo da mensagem, em texto corrido, é considerado não estruturado.
2.4.4 A Profissão
Como já citado anteriormente neste trabalho, se tornou nos dias atuais muito importante para uma empresa, investir em toda essa área que envolve trabalhos e estudos
com dados. O contrário disso pode desencadear uma abrupta desvantagem competitiva frente aos concorrentes.
Porém, obter um dado bruto, transformar em informação, em seguida em conhe- cimento, garantindo a segurança ao longo de todo o processo, requer uma mão de obra capacitada e bem especializada na área. A seguir serão listadas algumas das principais profissões que já fazem parte do cotidiano das empresas de ponta, e farão cada vez mais parte dos contingentes não somente das grandes empresas, mas também das médias.
2.4.4.1 Engenheiro de Dados
O engenheiro de dados trata-se do profissional que atuará no processo de trans- formação dos dados brutos. Segundo White (2018), suas atividades se concentraram na tríade formada pela coleta, armazenamento e distribuição dos dados, sendo responsável por gerenciar, otimizar, supervisionar e monitorar esses processos.
Este profissional atuará criando e dando manutenção em toda a infraestrutura montada para que o processo de descoberta de conhecimento, através dos dados coletados, seja feito da maneira mais eficiente e otimizada possível.
Além disso, os engenheiros de dados precisam, para exercer suas funções, um grande conjunto de habilidades técnicas e de comunicação, pois podem também precisar, desde entender e reportar informações e insights encontrados nos dados, até ter que colocar a mão na massa e desenvolver algoritmos para facilitar o acesso/recuperação de dados brutos (WHITE, 2018).
2.4.4.2 Cientista de Dados
Segundo a Castanha(2021), "Cientista de dados é o profissional responsável por extrair insights de dados brutos por meio de técnicas analíticas avançadas, ao passo em que atende às necessidades e aos objetivos de negócios específicos de uma empresa".
As empresas estão cada vez mais em busca desse tipo de profissional, uma vez que cada vez mais essas empresas dependem dos dados para que se possa tomar decisões estratégicas e relevantes na organização. É uma profissão que exige do profissional um profundo entendimento dos objetivos da empresa, e uma grande capacidade analítica e de solução de problemas.
Sendo uma profissão que envolve necessidade de conhecimentos multidiscplinares, Castanha (2021) cita que é necessário conhecimentos de Matemática, Estatística, e, considerando as atribuições normalmente impostas ao cargo, como análises estatísticas, identificação de padrões/trends, trabalhos envolvendo inteligência artificial e machine
learning, faz-se necessário também boas habilidades de comunicação e conhecimentos da área de computação.
2.4.4.3 DPO
O DPO, Data Protection Officer, é o responsável por garantir toda a proteção e segurança dos dados ao longo dos processos, em uma determinada organização, sejam esses dados do cliente, dos fornecedores ou da própria empresa (BALDISSERA,2021).
Já é uma tendência ao redor do mundo, legislações se moldarem a este novo universo que gira em torno dos dados, a exemplo da GDPR, da União Europeia. Como exemplo, aqui no Brasil, temos a entrada em vigor da Lei Geral da Proteção de Dados (LGPD) em 2020. Com isso, este profissional acaba se tornando fundamental para as organizações, no processo de adaptação às novas regras, garantindo segurança ao usuário, e também o compliance das empresas.
É importante salientar que esse profissional, que surge definido inicialmente pela GDPR, segundo a LGPD, é obrigatório de existir nas empresas, independente do tamanho, seja ele interno ou terceirizado (DPO as a service).
SegundoBaldissera (2021), esse profissional precisa ter domínio da própria LGPD, das leis de proteção dos dados de outros países, das leis setoriais do segmento em que atua a sua empresa, do modelo de negócio da empresa e das boas práticas de governança corporativa, processos e segurança da informação. Além disso, suas atribuições são determinadas pela LGPD e aumentam com o passar do tempo, conforme a lei é aprimorada.
3 MAPEAMENTO SISTEMÁTICO DA LI- TERATURA
A proposta inicial deste Trabalho de conclusão de curso surgiu em 2020, a partir da ideia de criar uma ferramenta de extração de dados, que coletasse especificamente dados financeiros (principalmente indicadores fundamentalistas de ações da bolsa de valores) de páginas da web.
Porém, através do próprio mapeamento, e, conforme as pesquisas e o desenvolvi- mento evoluíram, novos insights direcionaram o trabalho para oportunidade de criar uma ferramenta genérica, que não estivesse associada a nenhuma fonte de dados específica, e que pudesse ser parametrizada de acordo com o usuário, para atender as suas necessidades, de maneira personalizada, dado que a maioria dos trabalhos/ferramentas encontrados são focados em alguma área específica.
Neste capítulo, será então apresentado o mapeamento sistemático da literatura, desenvolvido no início das pesquisas que tornaram o presente trabalho possível.
3.1 MAPEAMENTO SISTEMÁTICO DA LITERATURA COM FOCO EM APLICAÇÕES DE COLETA E TRATAMENTO AUTOMÁ- TICA DE DADOS E SERVIÇOS DE COLETA DE DADOS FINANCEIROS DISPONÍVEIS NA WEB
O Mapeamento sistemático da literatura é um estudo secundário e sistemático, que tem o objetivo de classificar e identificar os estudos primários relativos a uma determinada área de interesse. Chama-se sistemático pois é um método, que deve seguir um protocolo desenvolvido pelo pesquisador, para que o estudo seja repetível e verificável.
O protocolo utilizado neste trabalho pode ser verificado com mais detalhes no Apên- dice A. Os principais objetivos desse mapeamento são identificar as pesquisas (divulgadas por meio de artigos científicos) que relacionem softwares voltados a coletar e disponibilizar dados de indicadores financeiros (fundamentalistas), sobre as empresas listadas em bolsas de valores, além de determinar as características desses softwares e analisar trabalhos que estejam relacionados a esse tema, de forma a embasar e compará-los com a proposta desse TCC.
3.1.1 Caracterização dos Estudos
A realização da pesquisa ocorreu em novembro de 2020, utilizando a ferramenta de buscaScopuse também oGoogle Acadêmicocomo ferramenta secundária, complementando o primeiro na tentativa de conseguir acesso a artigos pagos.
As 3 questões de pesquisa definidas para o mapeamento foram:
• QP1: Quais software coletam ou fornecem dados de indicadores fundamentalistas de empresas listadas em bolsas de valores?
• QP2: Quais as características dos Softwares que coletam e disponibilizam dados sobre indicadores fundamentalistas de empresas listadas em bolsas de valores?
• QP3 - Quais propostas de microsserviços aplicam web scraping?
3.1.1.1 Expressões de busca e artigos retornados
As questões de pesquisa nortearam a criação das strings de busca e consequente- mente os artigos retornados. Além disso, respondê-las é o objetivo de qualquer mapeamento sistemática da literatura. No primeiro momento, tinha-se apenas as duas primeiras questões de pesquisa, porém, devido a baixa quantidade de artigos retornados, por conta do escopo reduzidos das questões, se fez necessário a criação de mais uma questão de pesquisa, com um escopo mais aberto, possibilitando assim, um retorno maior de artigos da literatura relacionados ao tema pesquisado, mas que não fossem específicos como determinado em QP1 e QP2.
As expressões de busca foram formadas pelas palavras-chaves definidas na Tabela 3 localizada no apêndice A, seguindo a formatação necessária para execução da busca através do Scopus. Essas expressões podem ser checadas na Tabela 4, no apêndice A, com detalhes referentes a questão de pesquisa motivadora da expressão (QP1, QP2 e QP3), artigos encontrados/selecionados, entre outras informações.
A seguir no gráfico da figura 2 é apresentado a quantidade de artigos retornados por string. Abaixo, uma rápida descrição de cada string de busca.
• E1: Relacionada a QP3, retornou 267 artigos, dos quais nenhum foi selecionados.
• E2: Relacionada a QP1 e QP2, retornou 1563 artigos, dos quais nenhum foi selecio- nados.
• E3: Relacionada a QP1 e QP2, retornou 1501 artigos, dos quais nenhum foi selecio- nados.
Figura 2 – Artigos retornados por cada string de busca
Fonte: Elaborada pelo Autor (2020).
• E4: Relacionada a QP1 e QP2, retornou 1610 artigos, dos quais 1 foi selecionado.
• E5: Relacionada a QP3, retornou 220 artigos, dos quais 6 foram selecionados.
O gráfico da figura 3 trata de um compilado dos resultados de todas as strings criadas, onde foram retirados os artigos repetidos entre elas. É possível verificar o grande aumento no número de pesquisas, no geral, a partir de 2010. Isso indica que as pesquisas nessa área ainda estão em seu início, tendo aumentado em número significativamente há apenas 10 anos, pouco tempo se comparado com outros campos científicos.
Além disso, com as informações das expressões de busca, percebe-se que dos 5161 artigos retornados, ficaram 1982 após remoção dos artigos duplicados, dentre os quais, apenas 7 (0,3% aproximadamente) foram selecionados. Isso pode ser explicado por dois fatores principais, sendo eles:
• Dos 1982 artigos únicos retornados, apenas cerca de 320 foram analisados, o que muda o percentual de artigos selecionados para aproximadamente 2,2%
• O grande número de artigos retornados se deve em maior parte a algumas generaliza- ções feitas para alcançar um maior número de trabalhos, porém dado o escopo deste mapeamento, grande parte dos trabalhos são excluídos quando analisados pela ótica das strings mais específicas, o que indica que de fato, a área de APIs/Microsserviços
Figura 3 – Trabalhos relacionados ao tema da pesquisa.
Fonte: Scopus, tradução nossa (2020).
relacionados a indicadores fundamentalistas ainda está em seu início, e as pesquisas científicas relacionadas ao tema ainda são poucas.
3.1.1.2 Artigos Selecionados
Dentre todos os artigos encontrados nas pesquisas, foram selecionados (até o mo- mento) 7, que podem ser conferidos na tabela 1. As colunas tratam de ID (identificador de
Tabela 1 – Artigos Selecionados
Fonte: Elaborada pelo Autor (2020).
cada artigo), ano de publicação, autores, título do artigo, critérios de seleção que justificam a inclusão do artigo, país onde foram publicados, editora, afiliação (universidade/organiza- ção a qual os autores são filiados), relevância para a pesquisa (Escala de 1 a 5 definida
pelos autores, após leitura dos trabalhos), String de origem (expressão de busca) e QP (questão de pesquisa relacionada).
Ainda entre os artigos selecionados, pode-se verificar também a relação de editoras que mais publicaram sobre o tema no gráfico da figura 4, além dos países que mais produziram trabalhos relevantes (selecionados), no gráfico da figura 5.
Analisando o gráficos da figura 4 percebe-se que, dentre os artigos selecionados (considerados mais relevantes) a editora IEEE é a que publica a maioria desses trabalhos, o que pode estar associado ao fato de que, durante a seleção dos trabalhos, tal editora sempre disponibilizou os textos completos dos artigos, enquanto outras editoras nem sempre, tendo sido excluídos diversos artigos assim, de acordo com critério de inclusão C1 (critérios esses que podem ser verificados no Apêndice A).
Figura 4 – Artigos selecionados por Editora
Fonte: Elaborado pelo Autor (2020).
Já para o gráfico da figura5, percebe-se que, dentre os artigos selecionados, o país que mais contribuiu foi os Estados Unidos, com os outros bem divididos.
Figura 5 – Artigos selecionados por País
Fonte: Elaborado pelo Autor (2020).
3.1.2 Resultados
Os resultados do mapeamento são verificados por meio dos trabalhos e softwares encontrados, através das expressões de busca, que respondem as questões de pesquisa
definidas no protocolo do mesmo. Maiores detalhes podem ser verificados nas planilhas referenciados na seção A.4.2 do Apêndice A deste trabalho.
Observando o gráfico da figura6, é notável a contribuição da questão de pesquisa 3 para o aumento da seleção de artigos selecionados. Por mais que o resultado traga artigos não totalmente específicos para a proposta geral do mapeamento, ainda sim são trabalhos com grande valor, pois tratam de tecnologias que são usadas na base da aplicação desenvolvida neste TCC.
Figura 6 – Artigos selecionados por questões de pesquisa
Fonte: Elaborada pelo Autor (2020).
Na tabela 2 serão tratadas as respostas das questões de pesquisa, no caso, os softwares encontrados nos artigos selecionados pelo mapeamento até o momento.
Analisando os softwares encontrados (tabela 2), temos que, para responder QP1 e QP2, são considerados 2 softwares, relacionados a seguir.
• QP1: Quais software coletam ou fornecem dados de indicadores fundamentalistas de empresas listadas em bolsas de valores?
• QP2: Quais as características dos Softwares que coletam e disponibilizam dados sobre indicadores fundamentalistas de empresas listadas em bolsas de valores?
O primeiro software, referente ao artigo A1 (Islam, Zaman e Ahmed, 2009) trata de uma aplicação web chamada de ARFA (Automated Ranking by Fundamental Analysis).
Tem como função criação e edição de indicadores fundamentalistas, onde os mesmos são tratados e processados a fim de se ter um ranking de empresas com base nesse indicador.
Tabela 2 – Softwares Encontrados
Fonte: Elaborada pelo Autor (2020).
O segundo software, referente à A3 (Maurya et al., 2019) apresenta um modelo de predição gerado por machine learning que coleta automaticamente dados técnicos de ações de empresas da bolsa de valores indiana usando web scraping, e usa esses dados para fazer predições de futuros valores das ações.
Para QP3, foram encontrados até o momento 5 software, o que bate com o fato de QP3 ser mais "geral"e ampla em relação a QP1 e QP2.
• QP3: Quais propostas de microsserviços aplicam web scraping?
Para QP3, o primeiro software, encontrado no artigo A2 (Yang, Wilson e Wang, 2010), descreve um Web Crawler chamado iAIMS (Integrated Agricultural Information and Management System) que coleta, trata e armazena automaticamente dados climáticos, de solo e cultivo usando Web scraping em diversas fontes de informação. Esse dados podem ser buscados através de uma interface web para acesso dinâmico por usuários em outras aplicações.
O sistema, retirado do trabalho A4 (Bahana et al., 2017) trata de um sistema chamado Noox Project, que utiliza web scraping para coletar notícias de diversos portais na internet, armazena e trata esses dados com um CMS (Content Management System) e banco de dados, disponibilizando as notícias agregadas em uma aplicação mobile/portal web para usuários (leitores). Além disso, trata as notícias com detecção de fake news (utilizando técnicas de Inteligência artificial), com o objetivo de aumentar a confiabilidade
das informações apresentadas ao usuário.
O software encontrado em A5 (Bakaev e Mavdeenko, 2015) apresenta um web crawler que monitora o mercado de trabalho em uma cidade da Rússia chamada de Novosibirsk. A aplicação faz a varredura de várias fontes, e posteriormente trata, processa e estrutura tais dados para depois serem disponibilizados para aplicações, direcionadas a assuntos internos da cidade.
A aplicação descrita em A6 (Hosen e Alfina, 2016), é uma aplicação web que tem como objetivo exibir informações sobre educação e vagas de emprego na cidade de Jacarta na Indonésia, através de gráficos e painéis de visualização. Os dados são coletados através de técnicas de web scraping, em fontes específicas.
Por fim, o software encontrado em A7 (Chaulagain, Pandey, Basnet e Shakya, 2017) descreve uma arquitetura implementada em nuvem que faz a "raspagem"(coleta) e tratamento dos dados disponíveis em URLs inseridas pelo usuário. Sendo as principais funções: Coleta, tratamento, estruturação e disponibilização desses dados automaticamente.
Para a coleta dos dados utiliza o Selenium (biblioteca que tem como uma de suas funções a aplicação de web scraping), que embora um método mais "lento", tem vantagens quanto a possibilidade de coleta de dados gerados dinamicamente. Além disso, o sistema contorna o problema utilizando várias máquinas virtuais na nuvem, simultaneamente, dividindo o trabalho paralelamente, e aumentando o desempenho do sistema como um todo.
Sendo assim, temos 5 sistemas aplicados em diversas área diferentes, porém com bases semelhantes e que funcionam segundo o mesmo princípio: coletando e disponibilizando (ou processando) informações, todos eles, cada um com suas peculiaridades, extremamente
úteis como referência para a API desenvolvida neste TCC.
3.1.3 Considerações Finais sobre o Mapeamento Sistemático
No desenvolvimento deste mapeamento, nota-se como a quantidade imensa de trabalhos encontrados é algo necessário, para definir precisamente o estado das pesquisas numa determinada área, mas também fator que dificulta bastante o desenvolvimento do mesmo, dado limitações de tempo e recurso dos pesquisadores, principalmente considerando a grande quantidade de artigos pagos encontrados.
Algo importante a salientar, é que devido a natureza específica do mapeamento realizado, parte dos artigos lidos não puderam ser aproveitados. São escassos os trabalhos acadêmicos na literatura envolvendo a parte de microsserviços, APIs, cloud computer e web scraping aplicados a indicadores fundamentalistas de ações de empresas, de forma que, mesmo com algumas generalizações feitas para aumentar o aproveitamento dos trabalhos verificados, ainda assim foi possível notar, principalmente no meio acadêmico, uma certa escassez de estudos.
Além disso, entre os trabalhos e ferramentas selecionados, a maioria deles são específicos para uma determinada área, normalmente pouco personalizáveis, o que é um indicativo de oportunidade para exploração de ferramentas que permitam a coleta de dados de maneira personalizada, conforme as necessidades do usuário.
Um ponto interessante que decorre do mapeamento realizado, é que com os dados encontrados e sumarizados nos gráficos deste capítulo, é possível também fazer uma análise do desenvolvimento da área de Microsserviços e APIs relacionados a Web scraping, Computação em Nuvem e Mercado Financeiro/Indicadores Fundamentalistas, verificando como houve um aumento gigantesco no número de pesquisas envolvendo esses temas, a partir do ano de 2010.
Porém, ao analisar os resultados que foram fruto da QP3 (mais genérica), também é perceptível que, mesmo com mais trabalhos/ferramentas selecionadas, o número não é grande o suficiente para afirmar que a área já está madura. Pelo contrário, demonstra como o desenvolvimento da mesma ainda engatinha, o que reforça a oportunidade presente, de explorar essa área enquanto ela ainda está no início.
Por fim, os softwares encontrados nesses trabalhos trazem diversas lições a serem aprendidas, tanto no paradigma para desenvolvimento de software (como metodologias ágeis), até a maneira de aplicar tecnologias e técnicas no sistema propriamente dito.
Entende-se que o tempo é fator limitador para o mapeamento, mas que com o desenvolvi- mento deste TCC, esse mapeamento será ferramenta de extrema utilidade para o aumento da qualidade da pesquisa e do sistema desenvolvido como um todo.
4 TECNOLOGIAS UTILIZADAS
Este capítulo apresenta as técnicas, tecnologias e ferramentas utilizadas no desen- volvimento da aplicação.
4.1 PYTHON
O Python é uma linguagem de programação interpretada e orientada a objetos, criada no final da década de 80, pelo holandês Guido van Rossum. Foi criada com o foco no programador, visando, como objetivo principal, a produtividade. Segundo Menezes (2010), é uma linguagem interessante para iniciantes por ser clara e objetiva, porém mesmo
assim poderosa.
Além de ter aplicabilidade em diversas áreas, desde inteligência artificial, apli- cações matemáticas, indo para biotecnologia e até aplicações móveis/web, é conhecida por ter "batteries included"(baterias inclusas), fazendo referência a ser um "produto com- pleto"(MENEZES, 2010).
Python possui uma comunidade muito forte, com muitas bibliotecas e informação disponível para desenvolvimento, e, na atualidade, é uma das linguagens mais populares no mercado. Além disso, está presente em diversas aplicações, de gigantes como Google, Dropbox, Youtube e Instagram.
Por esses motivos e mais, foi a linguagem escolhida para ser usada neste projeto, principalmente por se tratar de uma linguagem extremamente versáti, fácil de aprender/de- senvolver, e possuir todas as bibliotecas e frameworks necessários para o desenvolvimento do mesmo.
4.1.1 Regex
Regex é a abreviação deRegular Expressions. Expressões regulares são utilizadas para encontrar padrões dentro de qualquer cadeia de caracteres, como por exemplo um texto, ou no caso específico do projeto apresentado neste trabalho, cadeias de caracteres contidas dentro de códigos HTML de páginas na web.
Em suma, são uma notação que permite descrever, de maneira resumida, usando símbolos específicos, palavras, conjuntos de expressões e até linguagens inteiras. As expressões são usadas em diversos contextos, tanto nas áreas acadêmicas e de pesquisa, descrição de linguagens, até no meio de desenvolvimento de software, que é o contexto no
qual esse trabalho se insere.
Segundo (KUCHLING, 2022), na documentação oficial da biblioteca de regex em Python, expressões regulares são essencialmente uma mini linguagem de programação altamente especializada incluída dentro da própria linguagem e disponível através do módulo re. Usando esta pequena linguagem, especificam-se as regras para o conjunto de strings possíveis que se quer combinar, e então, entre outras coisas, pode se utilizar para verificar se strings batem com o padrão, ou converter strings existentes para o padrão estabelecido.
No contexto deste trabalho, as regex são usadas como input do usuário, para permitir que o mesmo filtre a informação que se pretende captar daweb, de forma que seja capturado apenas o dado que é de interesse desse usuário, e seja eliminada a "sujeira"ao redor desses dados.
4.1.2 Beautifulsoup
De acordo comCrummy (2020), na documentação oficial, Beautiful Soup é uma biblioteca Python para extrair dados de arquivos HTML e XML. Ela funciona em cima de um parser (analisador), de forma que, ao recuperar, por exemplo, o HTML de um site, seja possível modificar a árvore de análise (desse parser), para extrair exatamente os dados desejados de dentro da página.
Uma das grandes vantagens desse biblioteca é a simplicidade de implementação e o alto desempenho. É possível, através dela, coletar dados de maneira rápida e efetiva, economizando muito tempo de desenvolvimento. Apesar disso, caso o site utilize muitas funções com JavaScript e disponibilize seus dados através dessa tecnologia, de maneira dinâmica, essa não é a ferramenta indicada para o trabalho. O foco é, de fato, nas páginas estáticas, com conteúdo disponível diretamente no HTML.
Neste trabalho, essa biblioteca integrará o motor de raspagem de páginas web estáticas do microserviço. Sua escolha foi feita devido a grande facilidade de implementação, alto desempenho para páginas estáticas e a disponibilidade e integração com a linguagem Python.
4.1.3 Selenium
Selenium é um projeto abrangente para uma variedade de ferramentas e bibliotecas que permitem e dão suporte à automação de navegadores da web (SELENIUM, 2020).
Entre elas, e para este trabalho, a mais importante é sem dúvidas o Selenium WebDriver.
Apesar de ser normalmente utilizada para testes de aplicações web, simulando um
