UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
B3-FEED: FEED DE NOTÍCIAS DA BOLSA DE VALORES
BASEADO EM SENTIMENTO
MARCELO WIPPEL
BLUMENAU 2020
MARCELO WIPPEL
B3-FEED: FEED DE NOTÍCIAS DA BOLSA DE VALORES
BASEADO EM SENTIMENTO
Trabalho de Conclusão de Curso apresentado ao curso de graduação em Sistemas de Informação do Centro de Ciências Exatas e Naturais da Universidade Regional de Blumenau como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação.
Prof. Marcel Hugo, Mestre – Orientador
BLUMENAU 2020
B3-FEED: FEED DE NOTÍCIAS DA BOLSA DE VALORES
BASEADO EM SENTIMENTO
Por
MARCELO WIPPEL
Trabalho de Conclusão de Curso aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II pela banca examinadora formada por:
______________________________________________________
Presidente: Prof(a). Marcel Hugo – Orientador(a), FURB
______________________________________________________
Membro: Prof(a). Roberto Heinzle – FURB
______________________________________________________
Membro: Prof(a). Aurélio Faustino Hoppe – FURB
Dedico este trabalho aos meus pais, meu irmão, amigos e, especialmente, aos meus professores que me ajudaram a chegar até aqui e executá-lo com sucesso.
AGRADECIMENTOS
Aos meus pais e meu irmão pelo apoio que sempre me foi fornecido. Aos meus amigos que sempre estiveram presentes desde o início do curso.
Aos meus colegas de trabalho que me auxiliaram nos momentos de dificuldade deste trabalho.
À Andreza Sartori, por ter me auxiliado na primeira etapa deste trabalho, sempre dando o apoio necessário.
Ao meu orientador, Marcel Hugo, que foi muito atencioso e prestativo durante todo o desenvolvimento deste trabalho, sempre disposto a ajudar e propor melhorias.
Stay hungry, stay foolish.
RESUMO
Este trabalho apresenta o desenvolvimento de um aplicativo móvel que disponibiliza um feed de notícias da Bolsa de Valores classificado por sentimento. Como motivação para o desenvolvimento deste trabalho, tem-se o crescimento da quantidade de pessoas físicas na Bolsa de Valores bem como a carência da população brasileira no campo da educação financeira. Dessa forma, este trabalho visa desenvolver um aplicativo contendo um feed de notícias classificado por sentimentos com objetivo de auxiliar os investidores da Bolsa de Valores nas suas transações no mercado acionário. A aplicação foi desenvolvida utilizando uma arquitetura cliente-servidor. Na camada cliente, o aplicativo móvel utilizado pelo usuário foi implementado utilizando o framework Flutter, possibilitando a utilização em dispositivos Android e iOS. A camada de servidor é dividida em dois serviços, o Web Scraper e o backend: o Web Scraper foi implementado em Python, salvando as notícias num banco de dados SQL Server hospedado na Azure; o backend foi implementado em Java utilizando o framework Spring Boot, fazendo a análise de sentimentos através do serviço Amazon Comprehend. Os dois artefatos da camada de servidor rodam em imagens Docker no serviço de Aplicativos Web para Contêineres da Azure. O levantamento das informações foi realizado através de busca na literatura sobre a educação financeira no Brasil, Web Scrapers e processamento de linguagem natural, mais especificamente, análise de sentimentos. Foram utilizados diagramas da Unified Modeling Language (UML) para representar os fluxos e a estrutura do que foi desenvolvido, bem como foi realizado um questionário on-line com objetivo de avaliar o aplicativo desenvolvido. Assim, foi possível inferir que o trabalho realizado atingiu todos os objetivos propostos, além de facilitar os investidores no processo de leitura de notícias antes de seus investimentos. Por fim, foram levantadas extensões e melhorias futuras para este trabalho.
ABSTRACT
This project presents the development of a mobile application that provides a stock market news feed classified by sentiment. As a motivation for the development of this project, there is an increase in the number of stock investors in Brazil as well as the lack of the Brazilian interested in the field of financial education. Considering that, this work aims to develop an application containing a news feed classified by sentiment with the objective of assisting stock exchange investors in their stock market transactions. The application was developed under a client-server architecture. In the client layer, the mobile app was implemented using the framework Flutter, enabling use on Android and iOS devices with a single code base. The server side layer is divided into two services, the Web Scraper and the backend: the Web Scraper was implemented in Python, saving the news in a SQL Server database hosted in Azure; the backend was implemented in Java as the programming language and Spring Boot as the main framework, analyzing the sentiment with Amazon Comprehend. Both artifacts of the server side run in a Docker image on Azure Web App for Containers. The information gathering was done through search in the literature about the financial education in Brazil, Web Scrapers, and the natural language processing, more specifically its subfield, sentiment analysis. UML diagrams were used to present the developed structures and flows, as well as an online questionnaire that was applied in order to rate the developed app. It was possible to conclude that this project accomplished all the proposed objectives, in addition to making the daily news reading easier for investors. At last, extensions and future improvements were raised for this project.
LISTA DE FIGURAS
Figura 1 – Três perspectivas diferentes da estrutura de páginas web ... 17
Figura 2 – Coletando informações da página através de um agente scraper utilizando XPath 18 Figura 3 – Buscas pelo termo sentiment analysis ... 20
Figura 4 – Tela de Coleta de Tweets ... 21
Figura 5 – Tela de Predição da Ação ... 22
Figura 6 – Tela inicial do Brand Feeling ... 23
Figura 7 – Tela de resultado da pesquisa do Brand Feeling ... 23
Figura 8 – Tela de polarização de sentenças extraídas do Twitter ... 24
Figura 9 – Diagrama de Caso de Uso do aplicativo móvel ... 30
Figura 10 – Diagrama de Sequência do Web Scraper ... 32
Figura 11 – Diagrama de Sequência do aplicativo móvel ... 33
Figura 12 – Diagrama de sequência da API ... 34
Figura 13 – Diagrama de classes do Web Scraper ... 35
Figura 14 – Diagrama de Classes da tela de log in do aplicativo móvel ... 36
Figura 15 – Diagrama de Classes da tela principal do aplicativo móvel ... 37
Figura 16 – Diagrama de Classes da tela de detalhe da notícia ... 38
Figura 17 – Diagrama de Classes da tela de histórico de cotação do ativo ... 38
Figura 18 – Diagrama de Classes – domínio de notícias da API ... 39
Figura 19 – Diagrama de Classes – domínio de parágrafos da API ... 40
Figura 20 – Diagrama de Classes – domínio de tarefas agendadas ... 41
Figura 21 – Diagrama de Implantação da aplicação ... 42
Figura 22 – Modelo Entidade Relacionamento ... 44
Figura 23 – Protótipo das telas iniciais da aplicação ... 44
Figura 24 – Protótipo das telas de notícia e detalhes da notícia ... 45
Figura 25 – Repositórios Github ... 47
Figura 26 – Tela de Log in e Registro do B3-Feed ... 54
Figura 27 – Tela de Últimas Notícias ... 55
Figura 28 – Tela de detalhe da notícia ... 56
Figura 29 – Tela de Histórico de Cotação ... 57
Figura 30 – Primeira Pergunta ... 59
Figura 32 – Terceira Pergunta ... 59
Figura 33 – Quarta Pergunta ... 60
Figura 34 – Quinta Pergunta ... 60
Figura 35 – Sexta Pergunta ... 60
Figura 36 – Sétima Pergunta ... 61
Figura 37 – Primeira parte do questionário aplicado ... 66
Figura 38 – Segunda parte do questionário aplicado ... 67
Figura 39 – Terceira parte do questionário aplicado ... 68
Figura 40 – Quarta parte do questionário aplicado... 69
Figura 41 – Quinta parte do questionário aplicado... 70
Figura 42 – Sexta parte do questionário aplicado... 71
LISTA DE QUADROS
Quadro 1 – Comparativo entre os trabalhos correlatos ... 25
Quadro 2 – Requisitos Funcionais do aplicativo móvel e sua relação com os UC ... 28
Quadro 3 – Requisitos Não Funcionais do aplicativo móvel ... 28
Quadro 4 – Requisitos Funcionais do Web Scraper ... 29
Quadro 5 – Requisitos Não Funcionais do Web Scraper ... 29
Quadro 6 – Requisitos Funcionais da API... 29
Quadro 7 – Requisitos Não Funcionais da API ... 30
Quadro 8 – Registro da execução das varreduras ... 47
Quadro 9 – Busca de notícias e parágrafos do Exame.com... 48
Quadro 10 – Busca de notícias e parágrafos da Suno Notícias ... 49
Quadro 11 – Busca das notícias e parágrafos do InfoMoney ... 50
Quadro 12 – Registro do timer de execução da análise de sentimento das notícias... 51
Quadro 13 – Registro do timer de execução da análise de sentimento das notícias... 52
Quadro 14 – Serviço de detecção de sentimento ... 53
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface APK – Android Application Package AVD – Android Virtual Device AWS – Amazon Web Services CSS – Cascading Style Sheets DOM – Document Object Model HTML – HyperText Markup Language HTTP – Hyper Text Transfer Protocol
HTTPS – Hyper Text Transfer Protocol Secure MER - Modelo de Entidade Relacionamento ORM – Object-relational mapping
PLN – Processamento de Linguagem Natural RF – Requisitos Funcionais
RNF – Requisitos Não Funcionais SDK – Software Development Kit
SGBD – Sistema Gerenciador de Banco de Dados SVM – Support Vector Machine
UC – Caso de Uso
UML – Unified Modeling Language
XHTML – eXtensible Hypertext Markup Language XML – Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ... 14
1.1 OBJETIVOS ... 15
1.2 ESTRUTURA ... 15
2 FUNDAMENTAÇÃO TEÓRICA ... 16
2.1 EDUCAÇÃO FINANCEIRA NO BRASIL ... 16
2.2 WEB SCRAPERS ... 17
2.3 PROCESSAMENTO DE LINGUAGEM NATURAL: ANÁLISE DE SENTIMENTOS 19 2.4 TRABALHOS CORRELATOS ... 20
2.4.1 Um modelo para predição de Bolsa de Valores baseado em mineração de opinião ... 20
2.4.2 Brand Feeling: um sistema para analisar o sentimento dos usuários em relação a uma marca ... 22
2.4.3 Uso de técnicas de computação social para tomada de decisão de compra e venda de ações no mercado brasileiro de Bolsa de Valores ... 24
2.4.4 Comparativo entre os trabalhos correlatos ... 25
3 DESENVOLVIMENTO ... 27
3.1 LEVANTAMENTO DE INFORMAÇÕES ... 27
3.2 ESPECIFICAÇÃO ... 28
3.2.1 Diagrama de Caso de Uso do aplicativo móvel ... 30
3.2.2 Diagrama de Sequência do Web Scraper ... 31
3.2.3 Diagrama de Sequência do aplicativo móvel ... 32
3.2.4 Diagrama de Sequência da API... 33
3.2.5 Diagrama de Classes do Web Scraper ... 34
3.2.6 Diagrama de Classes do aplicativo móvel ... 35
3.2.7 Diagrama de Classes da API ... 39
3.2.8 Diagrama de Implantação ... 41
3.2.9 Modelo Entidade Relacionamento ... 43
3.2.10Protótipo de telas da aplicação B3-Feed ... 44
3.3 IMPLEMENTAÇÃO ... 45
3.3.1Técnicas e ferramentas utilizadas ... 45
3.3.2.1Web Scraper de notícias ... 47 3.3.2.2Análise de sentimentos ... 51 3.3.3 Operacionalidade da implementação ... 53 3.4RESULTADOS E DISCUSSÕES ... 57 4CONCLUSÕES ... 62 4.1EXTENSÕES ... 63 REFERÊNCIAS... 64
14
1 INTRODUÇÃO
O número de novos investidores na Bolsa de Valores brasileira no ano de 2019 representa mais que o dobro de investidores registrados no fim do ano de 2018, demonstrando que mais pessoas físicas estão buscando investir seu dinheiro no mercado de capitais (BRASIL BOLSA BALCÃO, 2020). De acordo com dados de Brasil Bolsa Balcão (2020), em 2018, 633.889 pessoas físicas investiam na Bolsa, em dezembro de 2019 1.292.536 de pessoas físicas possuíam o CPF cadastrado em alguma corretora da Bolsa de Valores (BRASIL BOLSA BALCÃO, 2020).
Ferreira (2017) reforça essa questão, apontando que o povo brasileiro está num momento de ascensão econômica, e, que, com a democratização da informação, cada vez mais a população deve estar a par do que é informado pelos grandes bancos e mídia de massa. Com isso, as pessoas podem passar a estar numa posição de controle do seu dinheiro, além da ciência dos investimentos que mais se encaixam com o seu perfil.
Ainda, pode-se cruzar a esses dados o fato de grande parte dos movimentos do mercado acionário serem influenciados por notícias dos mais diversos tipos (SILVA; CARVALHO; NUNES, 2012). Conforme evidenciado por Silva, Carvalho e Nunes (2012), os ativos listados na Bolsa de Valores possuem a característica de oscilarem de preço baseado em acontecimentos ocorridos na política, economia e sociedade, que geralmente são veiculados através de notícias. Como cada vez mais o acesso à informação está democratizado, o mercado tende a refletir a curtíssimo prazo os noticiários que, normalmente, são acessados pelos investidores em seus portais na internet.
Silva, Carvalho e Nunes (2012) também apontam que os principais movimentos que acontecem a curto prazo em algum ativo, tanto para altas quanto para baixas, estão relacionados às notícias que causam uma oscilação, devido a um sentimento de nervosismo no mercado. Esses movimentos de altas e baixas são os que possibilitam os investidores a gerarem suas margens de lucro através da venda após a valorização de seus ativos, ou até mesmo através de uma operação vendida, no qual o lucro é feito através da desvalorização de um ativo.
Diante desse cenário, este trabalho tem como objetivo desenvolver um sistema capaz de extrair informação dos principais portais de notícias referentes ao mercado de capitais, analisar o sentimento do conteúdo extraído da notícia e disponibilizá-la num aplicativo, contendo o feed de notícias. Com isso, os investidores brasileiros serão capazes de consumir suas notícias diárias sobre o mercado financeiro de forma fácil e intuitiva, já com o viés da matéria sem a necessidade de uma leitura detalhada.
15 1.1 OBJETIVOS
O objetivo deste trabalho é desenvolver um sistema capaz de extrair informação dos principais portais de notícias e disponibilizar num aplicativo contendo um feed de notícias classificado por sentimentos, a fim de auxiliar os investidores da Bolsa de Valores nas suas transações no mercado acionário.
Os objetivos específicos são:
a) extrair as informações das últimas notícias de revistas on-line sobre economia, política, finanças, ações, Bolsa de Valores e investimentos através da extração do conteúdo das páginas web;
b) efetuar o processamento dos dados vindos das páginas web, buscando no texto o nome de ativos e empresas listadas na Bolsa de Valores para efetuar uma classificação;
c) classificar o sentimento das informações coletadas utilizando a API do serviço Amazon Comprehend para a de análise de sentimentos, visando medir automaticamente o sentimento relatado na notícia, para que possa ser previsto um viés de alta ou baixa para o ativo;
d) disponibilizar um aplicativo que apresenta um feed de notícias diárias classificadas por seu sentimento, utilizando o framework Flutter para o desenvolvimento.
1.2 ESTRUTURA
Este trabalho está dividido em quatro capítulos. O primeiro capítulo apresenta a introdução do trabalho desenvolvido, a justificativa, os objetivos e a definição de sua estrutura.
No segundo capítulo, são abordados os fundamentos e conceitos mais relevantes para o desenvolvimento deste trabalho. São abordados os temas referentes à educação financeira no Brasil, Web Scrapers, processamento de linguagem natural, mais especificamente sobre análise de sentimentos, por fim, são apresentados os trabalhos correlatos.
O terceiro capítulo aborda o desenvolvimento do trabalho, sendo apresentados o levantamento de requisitos, os diagramas de sequência, a atividade, a implantação e o modelo de entidade e relacionamento; também é apresentada a implementação, as técnicas e ferramentas utilizadas e a operacionalidade da implementação. Assim como os resultados e discussões.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, serão apresentados os principais conceitos e fundamentos para a pesquisa proposta, organizados da seguinte forma: a seção 2.1 aborda sobre a educação financeira no Brasil; a seção 2.2 apresenta o conceito de Web Scrapers; e a seção 2.3 contextualiza a parte da análise de sentimentos.
2.1 EDUCAÇÃO FINANCEIRA NO BRASIL
Conforme Savoia, Saito e Santana (2007), existe uma situação muito preocupante quanto à educação financeira no Brasil, requisitando uma urgência com relação à inserção desse tema para a população brasileira. Por ser um país com uma distribuição de renda desigual, no qual a maioria dos recursos são direcionados ao Estado, a propagação de uma educação financeira de qualidade é essencial para seu povo, para que possa existir uma excelência na administração dos recursos contidos pelos indivíduos e famílias, os quais são escassos (SAVOIA; SAITO; SANTANA, 2007).
Conforme Silva et al. (2017), mesmo que as instituições governamentais de educação não obriguem o ensino de uma disciplina específica de educação financeira, ela poderia ser espalhada de forma multidisciplinar, sendo suficiente para os indivíduos conseguirem administrar sua vida financeira. Todavia, a educação financeira, não estando presente diretamente na base educacional das crianças, também não estará presente no dia a dia das famílias, dificultando a fixação dessa disciplina na base populacional.
Silva et al. (2017) adicionam que a questão da previdência também influencia diretamente na educação financeira da população, já que boa parte dela conta com a aposentadoria para se manter no futuro. Por outro lado, as políticas de aumento da contribuição mínima e o aumento da idade mínima para a aposentadoria evidenciam cada vez mais a necessidade de o povo estar no controle da administração do seu próprio dinheiro.
Ferreira (2017) complementa que nos últimos tempos o povo brasileiro está passando por uma ascensão econômica, aumentando o poder de compra da população, e, cada vez mais, aumenta o acesso à informação. Por outro lado, os grandes bancos abrem cada vez mais um leque de possibilidades de investimento, o que dificulta o entendimento de tudo isso pela grande massa. Apesar desse movimento ser muito bom, o autor afirma que isso tudo pode piorar a situação financeira da maioria da população, que não possui o conhecimento básico sobre o assunto, o que pode se tornar desastroso para a vida deste indivíduo, ou até mesmo para a economia de todo o país.
17 2.2 WEB SCRAPERS
Web Scrapers são um conjunto de técnicas de extração de dados desestruturados de páginas da internet, incluindo o processamento e a transformação desses dados, finalizando com a persistência numa base estruturada de dados. Normalmente, o conceito de Web Scrapers caminha junto ao conceito de Web Crawlers – programas que possuem uma rotina de extração de dados automatizada, de diferentes tipos de sites, em que esses robôs varrem os links para outros sites, e, assim, extraem dados, através de uma busca recursiva na web (VARGIU; URRU, 2013).
Conforme Adams e McCrindle (2008), os Web Crawlers são robôs que visam extrair dados específicos do máximo de páginas possíveis, normalmente com o objetivo de indexar as páginas para serem usadas em motores de busca, como o Google. Os Web Scrapers extraem dados de páginas específicas, tendo em vista a obtenção de dados para um caso de uso característico. Quando uma API provendo dados estruturados não é disponibilizada, os Web Scrapers são uma boa alternativa para extração de dados (VARGIU; URRU, 2013).
De acordo com Saurkar, Pathare e Gode (2018), as páginas web são documentos escritos em Hypertext Markup Language (HTML) ou em eXtensible Hypertext Markup Language (XHTML). Os documentos web são representados por uma estrutura de elementos em árvore (Figura 1), chamada de Document Object Model (DOM). Nessa estrutura, todo o conteúdo da página é disposto através de elementos que exibem o conteúdo da página.
Figura 1 – Três perspectivas diferentes da estrutura de páginas web
Fonte: Saurkar, Pathare e Gode (2018).
Saurkar, Pathare e Gode (2018) observam que, do ponto de vista operacional, o Web Scraper atua como se fosse uma cópia e cola de dados, porém, a diferença é que esses passos são feitos através de um script, em que o primeiro passo é a extração do HTML da página através de um agente, que também pode ser chamado de robô. Esse agente interage com a
18 página da mesma forma que um ser humano interagiria, acessando links, submetendo formulários, navegando em diferentes páginas (SAUKAR; PATHARE; GODE, 2018).
Após efetuar a extração do HTML da página, o agente busca na página o conteúdo que for especificado no script através de seletores CSS ou XPaths. Cascading Style Sheets (CSS) é uma linguagem utilizada para adicionar estilo numa página, dessa forma, é possível encontrar elementos numa página através do estilo que esse elemento possui ou através dos atributos
class e id. Outra forma existente de extrair conteúdo é através da XPath, uma linguagem de consulta utilizada para selecionar elementos em documentos baseados em Extensible Markup Language (XML) (SAUKAR; PATHARE; GODE, 2018). Esse processo de busca de elementos pode ser representado através da Figura 2.
Figura 2 – Coletando informações da página através de um agente scraper utilizando XPath
Fonte: Saurkar, Pathare e Gode (2018).
Após extrair os conteúdos de interesse utilizando os seletores CSS ou XPaths, Glez-Peña et al. (2013) observam que o agente pode extrair qualquer propriedade de uma tag HTML. Porém, é importante que a implementação do agente seja feita da forma mais genérica possível, para que o agente se torne menos vulnerável a alterações nas páginas HTML ou seletores do CSS. Esse é um problema que é recorrente na implementação de Web Scrapers, já que os robôs extraem o conteúdo de uma página por meio de sua estrutura. Caso ela sofra alterações pelo provedor da página, o robô pode não encontrar determinado dado (GLEZ-PEÑA et al., 2013).
Sobre a segurança e os direitos autorais dos dados coletados, Vargiu e Urru (2013) citam a importância da verificação da política de privacidade e termos de uso dos websites que são extraídos através de Web Scrapers, para que a extração seja feita de forma consciente, a fim de não existirem problemas legais na utilização dos dados extraídos. Outro ponto
19 levantado é quanto aos anúncios contidos em páginas web, que, se forem considerados na extração e transformação dos dados, podem trazer imprecisões e ruídos à base de dados, já que os anúncios normalmente não estão relacionados ao assunto que está sendo extraído na página (VARGIU; URRU, 2013).
2.3 PROCESSAMENTO DE LINGUAGEM NATURAL: ANÁLISE DE SENTIMENTOS De acordo com Rosa (2011), o Processamento de Linguagem Natural (PLN) pode ser definido como a capacidade de uma máquina interpretar e processar a mesma linguagem que os seres humanos utilizam. Finatto, Lopes e Silva (2015) citam também que, para o PLN, o objetivo é criar soluções para problemas relativamente pontuais, sempre considerando uma margem de erro, bem como uma abrangência de atuação pré-definida do algoritmo.
De acordo com Liu (2012), a análise de sentimentos, também conhecida como Mineração de Opinião, é o processo de extrair o sentimento de determinada sentença, que é um desafio do PLN. Como a análise de sentimentos possui grande aplicabilidade para a área de serviços e indústria, houve uma explosão de pesquisas acadêmicas nesta área, trazendo diversas APIs para o mercado.
Liu (2012) afirma também que extrair os sentimentos das sentenças de forma precisa é uma tarefa difícil, já que, em muitos casos, as sentenças podem possuir mais de uma opinião retratada, ou, até mesmo, diversos sentimentos serem expressos numa mesma sentença. Essa dificuldade é também retratada por Fersini et al. (2016), que descrevem os três níveis da análise de sentimentos: message level (nível de mensagem), a análise é feita baseada no texto completo; sentence level (nível de sentença), o texto é fragmentado em sentenças e depois analisado; por fim, entity level (nível de entidade), toda a análise é feita somente nas entidades que a sentença possui, sendo a menor parte que uma sentença pode possuir.
Uma abordagem da análise de sentimentos é a classificação entre texto objetivo e subjetivo. Em casos em que o texto é identificado como objetivo, por exemplo: “Não sei se o nome dela é Maria.”, a análise de sentimentos não se faz necessária, já que o texto não possui opinião e não deve ser considerado para influenciar no sentimento do texto completo. Já no texto subjetivo, por exemplo: “Os óculos de Maria são tão lindos!”, normalmente são encontradas as opiniões sobre determinado assunto no qual a análise de sentimentos pode ser aplicada para descobrir a polaridade do texto (FERSINI et al., 2016).
De acordo com Fersini et al. (2016), é possível verificar o quanto a análise de sentimentos está se tornando cada vez mais relevante em termos de pesquisa. O gráfico apresentado na Figura 3 retrata as buscas no Google referente ao termo sentiment analysis
20 (análise de sentimentos), na qual é possível visualizar que o interesse na área é crescente, trazendo inovação e mais possibilidades nas diversas abordagens.
Figura 3 – Buscas pelo termo sentiment analysis
Fonte: Fersini et al. (2016).
2.4 TRABALHOS CORRELATOS
Neste capítulo, são apresentados três trabalhos correlatos, os quais possuem características diretamente relacionadas ao trabalho proposto. A seção 2.4.1 detalha o trabalho de Lima (2016), que propõe um modelo de predição de preços de ações da Bolsa de Valores baseado em mineração de opinião no Twitter. A seção 2.4.2 descreve um sistema para análise de sentimentos dos usuários sobre determinada marca, utilizando dados do Twitter (COPPI JUNIOR, 2017). Finalmente, a seção 2.4.3 apresenta um modelo de decisão de compras e vendas na Bolsa de Valores baseado em opinião no Twitter (ALVES, 2015).
2.4.1 Um modelo para predição de Bolsa de Valores baseado em mineração de opinião Lima (2016) propôs um modelo para predição de valores da Bolsa de Valores, baseado na mineração de opinião do Twitter. Para isso, técnicas de PLN e Support Vector Machine (SVM) foram utilizadas para prever o valor de determinada ação. Foi utilizado a API Sentiment140 para efetuar a análise de sentimentos dos dados extraídos do Twitter, junto a uma aplicação Java utilizando Weka, para a mineração e tratamento dos dados.
Segundo Lima (2016), o trabalho tem a finalidade de estabelecer um relacionamento direto entre o sentimento das pessoas expressos via redes sociais com os movimentos de mercado que acontecem na Bolsa de Valores. Além disso, Lima (2016) evidencia que o trabalho possui a finalidade de ser uma ferramenta para auxiliar os investidores na tomada de decisão em suas decisões de compra e venda de ativos no mercado acionário.
Após fornecer as credenciais e efetuar o log in, o usuário é redirecionado para a tela de coleta de Tweets (Figura 4), na qual será informado uma palavra-chave que servirá de argumento para a API do Twitter efetuar a pesquisa de Tweets relacionados. Após todo o processo de coleta e processamento das informações, os dados são gravados no banco de
21 dados, bem como é apresentado um gráfico contendo o percentual de polaridade do sentimento.
Figura 4 – Tela de Coleta de Tweets
Fonte: Lima (2016).
Por fim, o sistema disponibiliza a informação das predições através da tela de Predição da Ação (Figura 5), na qual apresenta o ativo que foi pesquisado e o período de coleta dos dados do Twitter. Também são apresentados os resultados numa tabela contendo as informações de data, Tweets positivos, Tweets negativos, valor de fechamento, bem como o viés, junto à informação de acerto ou erro do viés previsto pelo sistema.
22 Figura 5 – Tela de Predição da Ação
Fonte: Lima (2016).
2.4.2 Brand Feeling: um sistema para analisar o sentimento dos usuários em relação a uma marca
O trabalho de Coppi Junior (2017) tem como objetivo efetuar a análise de sentimentos de usuários em relação a uma marca baseada em mineração de opinião no Twitter. Para isso, utilizou a API do Twitter para efetuar a extração dos Tweets, e a biblioteca SentiWordNet para verificar os sentimentos relacionado a determinado Tweet. Para implementação do sistema foi utilizado Java na parte de servidor e a interface foi implementada em PHP e AngularJs.
Na solução proposta pelo autor são disponibilizadas duas telas para os usuários. Na tela inicial do sistema (Figura 6), é disponibilizada uma interface com um campo para efetuar a pesquisa sobre a marca informada, as últimas pesquisas efetuadas, bem como o histórico das marcas, no qual é possível filtrar pelos resultados de sentimento positivo e negativo.
23 Figura 6 – Tela inicial do Brand Feeling
Fonte: Coppi Junior (2017).
Após efetuar a pesquisa, o usuário é redirecionado para a outra tela do sistema (Figura 7), no qual é apresentado o resultado da pesquisa de diversas maneiras, dispondo ao usuário uma maior flexibilidade na leitura dos dados. Essa tela, além de apresentar os resultados obtidos, apresenta também as palavras com mais ocorrências, numa estrutura de nuvem de palavras.
Figura 7 – Tela de resultado da pesquisa do Brand Feeling
24 2.4.3 Uso de técnicas de computação social para tomada de decisão de compra e venda de
ações no mercado brasileiro de Bolsa de Valores
Alves (2015) descreve a aplicação de técnicas de Computação Social para a tomada de decisões nas operações de compra e venda de ativos da Bolsa de Valores. Para a aplicação deste trabalho, foram coletados Tweets de agosto de 2013 a abril de 2015 que continham palavras semelhantes ao nome de nove empresas listadas na Bolsa selecionadas pelo autor. Para efetuar a tomada de decisões de compra e venda, foi analisado o sentimento dos Tweets, juntamente aos dados históricos para a aplicação de tendências de valor.
De acordo com Alves (2015), para efetuar a análise de sentimentos, foi utilizada a ferramenta LingPipe. Essa biblioteca foi escolhida por permitir ao usuário efetuar o treinamento através de dois conjuntos de dados próprios, um de treinamento e outro de teste. Para efetuar o treinamento da aplicação, é necessária uma classificação manual de um conjunto de sentenças, para que a ferramenta possa posteriormente classificar os sentimentos baseado no que foi aprendido (ALVES, 2015).
Para efetuar a polarização de um conjunto de treinamento, Alves (2015) implementou uma ferramenta em Java que disponibiliza uma interface (Figura 8) para que um especialista possa, manualmente, polarizar um conjunto de sentenças previamente extraídas do Twitter. Desse modo, são gerados dois arquivos, um com as informações polarizadas positivamente, e, outro, com as informações polarizadas negativamente (ALVES, 2015).
Figura 8 – Tela de polarização de sentenças extraídas do Twitter
Fonte: adaptado de Alves (2015).
O trabalho não apresenta uma interface gráfica amigável ao utilizador do sistema, já que o objetivo é fornecer um modelo para a previsão da cotação de ativos da Bolsa de Valores somente para fins acadêmicos. Por fim, Alves (2015) descreve que os resultados obtidos no emprego da análise de sentimentos utilizando dados obtidos do Twitter é promissor.
25 Entretanto, faz-se necessário o cruzamento dessas informações obtidas em redes sociais com dados oriundos de análises técnicas, para que se possa ter um resultado mais preciso.
2.4.4 Comparativo entre os trabalhos correlatos
No Quadro 1 é apresentado um comparativo entre os trabalhos correlatos de Lima (2016), Coppi Junior (2017) e Alves (2015), no qual as linhas representam as funcionalidades e as colunas representam os trabalhos relacionados.
Quadro 1 – Comparativo entre os trabalhos correlatos
Correlatos
Características Lima (2016) Coppi Junior (2017) Alves (2015)
Objetivo Prever os valores de ativos Analisar o sentimento da população sobre alguma marca Tomar decisões de compra e venda de ativos Extração de dados API do Twitter API do Twitter API do Twitter Extração de dados de portais
de notícia Não Não Não
Algoritmo de aprendizado de máquina Support Vector Machine (SVM) Não Regressão Logística Algoritmo de Análise de
Sentimento Sentiment140 SentiWordNet LingPipe
Dicionário de dados utilizado pelo algoritmo de análise de sentimentos Não possui Fornecido pela biblioteca SentiWordNet Possui uma interface para classificar o dicionário de dados
que será utilizado para a análise de
sentimentos Interface para a apresentação
dos resultados obtidos após a análise de dados
Web Web Não possui Disponível para dispositivos
móveis Não
Sim, através de página Web
responsiva
Não
Fonte: elaborado pelo autor.
Conforme demonstrado no Quadro 1, pode-se verificar que os três trabalhos compartilham as características de extração de dados do Twitter bem como a análise de sentimentos dos dados extraídos, utilizando diferentes frameworks. Enquanto Lima (2016) e Alves (2015) buscam prever os valores de ativos da Bolsa e tomar decisões de compras e vendas, Coppi Junior (2017) analisa o sentimento da população sobre determinada marca.
Além disso, Alves (2015) utiliza dados históricos da Bolsa de Valores para efetuar uma verificação cruzada de dados técnicos sobre ativos bem como dados sobre o sentimento de determinado ativo na rede social Twitter. Para a análise de sentimentos, enquanto Alves (2015) e Coppi Junior (2017) utilizam frameworks que analisam o sentimento baseado num
26 dicionário de dados que pode ser customizado, Lima (2016) utiliza uma API que efetua a análise de sentimentos sem a necessidade de uma pré-informação de um dicionário de dados.
Referente ao dicionário de dados, Alves (2015) disponibiliza uma interface implementada em Java para que um especialista faça a leitura de diversos Tweets coletados e os classifique conforme seu sentimento, para que sirva como fonte de dados para a biblioteca LingPipe. Neste ponto, Alves (2015) se diferencia dos outros dois trabalhos, já que é o único que oferece uma interface na qual o especialista pode fazer um treinamento preliminar de forma mais fácil, já baseando-se em Tweets reais que foram previamente coletados pela ferramenta.
Quanto à interface disponibilizada para os usuários consultarem os resultados, Coppi Junior (2017) disponibiliza uma interface web para os usuários, com uma experiência agradável aos usuários, disponibilizando os dados coletados sobre uma marca de diversas formas: gráficos, nuvem de palavras e tabelas com dados históricos. Lima (2016) também disponibiliza uma interface web, apresentando os resultados obtidos através da análise de sentimentos, cruzando com o fechamento do ativo no dia em questão. Alves (2015) não disponibiliza uma interface para os usuários consultarem os resultados da aplicação, isto é, os seus resultados são disponibilizados somente através de dados brutos e planilhas. A aplicação de Coppi Junior (2017) é a única que oferece uma interface responsiva para ser acessada também via dispositivos móveis.
27
3 DESENVOLVIMENTO
Neste capítulo, será apresentado o conteúdo referente ao desenvolvimento da aplicação. A seção 3.1 apresenta o levantamento de informações; a seção 3.2 aponta a especificação dos Requisitos Funcionais (RF) e Requisitos Não Funcionais (RNF) do Web Scraper e do aplicativo móvel. Nesta seção ainda são apresentados outros diagramas da Unified Modeling Language (UML) utilizados para a representação do fluxo da aplicação, sua estrutura de classes e arquitetura. A seção 3.4 aborda os resultados e discussões, apresentando a comparação entre o trabalho desenvolvido e os trabalhos correlatos.
3.1 LEVANTAMENTO DE INFORMAÇÕES
Este trabalho apresenta o desenvolvimento de um feed de notícias do mercado financeiro classificado por sentimento, intitulado B3-Feed. A aplicação é composta por três partes. A primeira parte se trata de um Web Scraper, responsável por buscar as notícias de três portais diferentes e armazená-las no banco de dados. A segunda parte é a API, que é responsável por classificar o sentimento das notícias e disponibilizar para o consumo da aplicação cliente. A terceira parte se trata da aplicação cliente, um aplicativo móvel que é utilizado pelo usuário final e permite a visualização das notícias e os detalhes sobre o sentimento dela.
O Web Scraper é responsável por extrair as notícias sobre o mercado acionário de três portais: Exame.com1, Suno Notícias2 e InfoMoney3. Para cada portal, o Web Scraper busca a listagem das últimas notícias, e, após isso, extrai o conteúdo de cada uma delas. O título, os parágrafos e os metadados da notícia são gravados no banco de dados para serem acessados pela API.
A API possui a responsabilidade de extrair o sentimento dos títulos das notícias e seus parágrafos, além de disponibilizar os dados estruturados para serem consumidos pelo aplicativo móvel. O processo de extração de sentimento funciona mediante integração com o serviço de análise de sentimentos da Amazon Web Services (AWS), titulado AWS Comprehend. Após o processo de análise de sentimentos, todos os dados analisados são novamente atualizados no banco de dados.
O aplicativo móvel permite ao usuário final visualizar todas as notícias extraídas dos portais, podendo filtrar por título da notícia, ativos associados e por data de postagem. Além
1 Exame.com – Disponível em: https://exame.com/. Acesso em: 1° jun. 2020.
2 Suno Notícias – Disponível em: https://www.sunoresearch.com.br/noticias/. Acesso em: 1° jun. 2020. 3 InfoMoney – Disponível em: https://www.infomoney.com.br/. Acesso em: 1° jun. 2020.
28 disso, o usuário pode visualizar os detalhes da notícia, contendo a lista de ativos citados na notícia, gráfico com a média dos sentimentos dos parágrafos, link para a leitura da matéria na íntegra e também um gráfico interativo para a visualização da cotação de algum ativo que tenha sido citado na notícia.
3.2 ESPECIFICAÇÃO
Nesta seção é apresentada a especificação da ferramenta, contendo os requisitos funcionais e não funcionais das três partes da aplicação, além do diagrama de caso de uso do aplicativo móvel, diagramas de sequência, diagramas de classes, diagrama de implantação e o Modelo de Entidade Relacionamento (MER). Para o desenvolvimento dos diagramas foi utilizada a ferramenta Visual Paradigm Community Edition4.
O Quadro 2 apresenta os RFs do aplicativo móvel e o respectivo Caso de Uso (UC) referente ao requisito a partir da matriz de rastreabilidade. Os UCs referenciados nesse quadro encontram-se na Figura 9. Além disso, o Quadro 3 apresenta os RNFs do aplicativo móvel.
Quadro 2 – Requisitos Funcionais do aplicativo móvel e sua relação com os UC
Requisitos Funcionais Caso de Uso RF01: O aplicativo deve permitir ao usuário realizar o cadastro. UC01 RF02: O aplicativo deve permitir ao usuário realizar o log in. UC02 RF03: O aplicativo deve permitir ao usuário visualizar as notícias. UC03 RF04: O aplicativo deve permitir ao usuário filtrar as notícias por título. UC04 RF05: O aplicativo deve permitir ao usuário filtrar as notícias por noticiário. UC05 RF06: O aplicativo deve permitir ao usuário filtrar as notícias por data de
postagem. UC06
RF06: O aplicativo deve permitir ao usuário filtrar as notícias pelos ativos
relacionados. UC07
RF07: O aplicativo deve permitir ao usuário visualizar o gráfico de sentimento. UC08 RF08: O aplicativo deve permitir ao usuário visualizar os ativos relacionados
com a notícia. UC09
RF08: O aplicativo deve permitir ao usuário visualizar a cotação do ativo. UC10 RF09: O aplicativo deve permitir ao usuário ler a notícia na íntegra. UC11
Fonte: elaborado pelo autor.
Quadro 3 – Requisitos Não Funcionais do aplicativo móvel
Requisitos Não Funcionais
RNF01: O aplicativo deve ser desenvolvido utilizando o framework Flutter.
RNF02: O aplicativo deve efetuar a autenticação utilizando o Firebase Authentication. RNF03: O aplicativo deve estar disponível para as plataformas Android e iOS.
RNF05: O aplicativo deve mostrar a cotação do ativo através do site TradingView5.
RNF06: O aplicativo deve se comunicar apenas via HTTPS com a API
Fonte: elaborado pelo autor.
4 Visual Paradigm Community Edition – Disponível em: https://www.visual-paradigm.com/. Acesso em: 1° jun.
2020.
29 O Quadro 4 apresenta os RFs do Web Scraper.
Quadro 4 – Requisitos Funcionais do Web Scraper
Requisitos Funcionais
RF01: O Web Scraper deve varrer as últimas notícias do portal InfoMoney. RF02: O Web Scraper deve varrer as últimas notícias do portal Exame.com. RF03: O Web Scraper deve varrer as últimas notícias do portal Suno Notícias. RF04: O Web Scraper deve dividir o conteúdo da notícia em parágrafos. RF05: O Web Scraper deve remover parágrafos não referentes à notícia. RF06: O Web Scraper deve salvar as notícias no banco de dados. RF07: O Web Scraper deve salvar os parágrafos no banco de dados.
Fonte: elaborado pelo autor.
O Quadro 5 apresenta os RNFs do Web Scraper.
Quadro 5 – Requisitos Não Funcionais do Web Scraper
Requisitos Não Funcionais RNF01: O Web Scraper deve ser implementado em Python.
RNF02: O Web Scraper deve extrair o conteúdo das utilizando a biblioteca BeautifulSoup. RNF03: O Web Scraper deve salvar as notícias e parágrafos num banco de dados SQL Server. RNF04: O Web Scraper deve executar a varredura de novas notícias a cada 15 minutos. RNF05: O Web Scraper deve ser executado em uma imagem Docker.
RNF06: O Web Scraper deve ser implantado no serviço de Aplicativos Web para Contêineres da Azure.
Fonte: elaborado pelo autor.
O Quadro 6 apresenta os RFs da API.
Quadro 6 – Requisitos Funcionais da API
Requisitos Funcionais RNF01: A API deve permitir manter notícias.
RNF02: A API deve permitir manter parágrafos.
RNF03: A API deve analisar o sentimento dos parágrafos. RNF04: A API deve buscar os ativos relacionados às notícias.
RNF05: A API deve permitir manter os ativos relacionados às notícias.
30
O Quadro 7 apresenta os RNFs da API.
Quadro 7 – Requisitos Não Funcionais da API
Requisitos Não Funcionais RNF01: A API deve ser implementada utilizando a linguagem Java.
RNF02: A API deve ser implementada utilizando o framework Spring Boot.
RNF03: A API deve utilizar a API do serviço Amazon Comprehend para efetuar a análise de sentimentos.
RNF04: A API deve ser executada em uma imagem Docker.
RNF05: A API deve ser implantado no serviço de Aplicativos Web para Contêineres da Azure. RNF06: A API deve executar a análise de sentimentos de novas notícias a cada 15 minutos.
Fonte: elaborado pelo autor.
3.2.1 Diagrama de Caso de Uso do aplicativo móvel
A Figura 9 apresenta o diagrama de caso de uso do aplicativo móvel desenvolvido. No diagrama são apresentados dois atores envolvidos: o Usuário e o Firebase
Authentication.
Figura 9 – Diagrama de Caso de Uso do aplicativo móvel
31 O ator Usuário é quem realiza todas as interações no aplicativo utilizados pelo usuário final. O caso de uso referente à tela de cadastro é o UC02 – Efetuar Registro, inclui-se também o UC01 – Efetuar Log in, responsável por permitir o usuário efetuar log in. Em ambos os casos, o ator Firebase Authentication também possui associação, pois é um serviço de autenticação fornecido pela Google.
Após efetuar o log in na aplicação, a tela de listagem de leituras é demonstrada através dos casos de uso UC03 – Visualizar Notícias, a qual é a tela inicial do sistema, em que são apresentadas todas as notícias dos três portais, agrupadas por data de postagem e ordenadas de forma decrescente, para fornecer uma melhor experiência ao usuário. O ator
Usuário também pode ter acesso a quatro tipos de funcionalidades de filtro, sendo eles: UC04
– Filtrar Notícias por título; UC05 – Filtrar por portal de notícias; UC06 –
Filtrar por data de postagem e UC07 – Filtrar Notícias por ativo relacionado.
Ao clicar em uma notícia, para ver seus detalhes, o Usuário tem acesso aos casos de uso de visualização de detalhe da notícia, sendo eles: UC08 – Visualizar gráfico de
sentimento; UC09 – Visualizar cotação do ativo; UC10 – Visualizar ativos
relacionados e UC11 - Ler notícia na íntegra. Os casos de uso UC08 – Visualizar
gráfico de sentimento e UC10 – Visualizar ativos relacionados podem ser vistos
nessa mesma tela, já o caso de uso UC09 – Visualizar cotação do ativo redireciona o
Usuário para uma web view contendo um gráfico interativo com a cotação do ativo selecionado. Por fim, no UC11 – Ler notícia na íntegra o Usuário poderá clicar no que o redireciona para o link da notícia original.
3.2.2 Diagrama de Sequência do Web Scraper
Uma parte da aplicação desenvolvida pode ser ainda representada pelo diagrama de sequência (Figura 10), que apresenta o fluxo de execução do Web Scraper em nível de implementação, explicando também a periodicidade de execução do Web Scraper. Pela Figura 10 pode-se observar que a cada 15 minutos é iniciado o processo de varredura das últimas notícias, sendo que esse processo é executado para cada um dos três portais suportados pela aplicação.
32 Figura 10 – Diagrama de Sequência do Web Scraper
Fonte: elaborador pelo autor.
É possível observar que os métodos get_link e get_title são chamados fora do loop para cada notícia, já que, primeiramente, todas as últimas notícias são extraídas da página, para depois executar os métodos de extração do conteúdo de detalhe da notícia. No loop de execução para cada notícia pode-se verificar que as notícias são salvas no banco de dados através de uma única operação, a fim de tornar o código mais otimizado, gravando os dados em uma única transação.
3.2.3 Diagrama de Sequência do aplicativo móvel
O detalhamento do fluxo de execução do aplicativo móvel pode ser visto através da Figura 11, que apresenta a interação do usuário final com o aplicativo, e as chamadas que são executadas para o backend e para o serviço de autenticação do Firebase. Através da Figura 11 também pode-se observar que o usuário efetua log in na aplicação: o método
loginWithEmail é executado de forma assíncrona, apresentando um componente de
33 chamada do método fetchNews, em que são recuperadas todas as informações das notícias, para apresentar na tela de últimas notícias (Figura 27).
Figura 11 – Diagrama de Sequência do aplicativo móvel
Fonte: elaborado pelo autor.
3.2.4 Diagrama de Sequência da API
Esta subseção apresenta o diagrama de sequência da API (Figura 12), no qual é exposto a ordem de execução do processo de análise de sentimentos das notícias. Da mesma forma que é apresentado no diagrama de sequência do Web Scraper (Figura 10), a API atua de forma similar, a cada 15 minutos é iniciado o processo de análise de sentimentos, através da busca no banco de dados por notícias que ainda não foram analisadas. Essa busca é feita pelo método findByPositiveIsNull.
Após recuperar todas as notícias que ainda não foram analisadas, é executado o loop
para cada notícia, em que é feito a chamada do método detectSentiment do SDK do Amazon Comprehend para Java. Esse mesmo processo é executado no loop para cada parágrafo. Feita a análise, todas as notícias são atualizadas no banco, alimentando o campo que armazena o sentimento médio da notícia, informação que é necessária para que a notícia seja apresentada no aplicativo móvel.
34 Figura 12 – Diagrama de sequência da API
Fonte: elaborado pelo autor.
3.2.5 Diagrama de Classes do Web Scraper
A Figura 13 contempla o diagrama de classes do Web Scraper. A classe CronJob é a responsável por fazer o controle do temporizador de execução das varreduras, executadas pelas classes ScraperInfoMoney, ScraperExame e ScraperSuno. Apesar da similaridade semântica entre as três classes responsáveis pela varredura, não foi implementada uma classe abstrata contendo o comportamento genérico, pois no caso da linguagem Python se faz necessária a importação de uma biblioteca a parte para que seja possível implementar uma classe abstrata.
As classes com o sufixo Utils são utilitárias da aplicação, contendo métodos estáticos que são utilizados dentre as três classes de varredura das notícias. A classe NewModel é utilizada como modelo para persistência das notícias no banco de dados, de acordo com o estereótipo ORM Persistable. Para efetuar a persistência da notícia, utiliza-se a classe
35 Figura 13 – Diagrama de classes do Web Scraper
Fonte: elaborador pelo autor.
3.2.6 Diagrama de Classes do aplicativo móvel
Nesta subseção serão apresentados três diagramas de classes do aplicativo móvel, um para cada tela. Para implementação do aplicativo móvel foi utilizado a linguagem Dart6 com o framework Flutter7, possibilitando a disponibilização do aplicativo para Android e iOS utilizando apenas uma base de código. Utilizou-se a arquitetura Flux8 para a implementação do aplicativo, junto à biblioteca MobX9 para gerenciar o estado da aplicação. O MobX é utilizado para que o desenvolvedor possa focar somente na parte de implementação da tela, sem se preocupar com a sincronização dos dados entre a página e a store.
No padrão de arquitetura Flux com o MobX, as stores são utilizadas em conjunto às páginas, armazenando os valores que são utilizadas por elas. Dessa forma, quando um valor é atualizado na store, a página é automaticamente notificada, atualizando os dados que são apresentados. A MainStore é a store principal da aplicação, que possui associação com todas stores da aplicação. Esse é o padrão de implementação recomendado pela biblioteca e isso
6 Dart – Disponível em: https://dart.dev/. Acesso em: 3 jun. 2020. 7 Flutter – Disponível em: https://flutter.dev/. Acesso em: 3 jun. 2020.
8 Flux – Disponível em: https://facebook.github.io/flux/. Acesso em: 3 jun. 2020. 9 MobX – Disponível em: https://mobx.netlify.app/. Acesso em: 3 jun. 2020.
36 ocorre para que as páginas não precisem se associar a todas as stores existentes, e sim somente com a principal, acessando as stores filhas através da MainStore.
De acordo com a primeira tela que é apresentada ao abrir o aplicativo, tem-se o diagrama de classes da tela de log in (Figura 14). Conforme é visto no diagrama, a classe
LoginPage se associa com a MainStore, para que possa acessar a LoginStore, onde estão os atributos que armazenam os valores que são digitados na tela pelo usuário. Para efetuar o log in e o registro na aplicação, criou-se a classe AuthenticationService, que encapsula o comportamento de log in, registro, log out e busca do usuário autenticado.
Figura 14 – Diagrama de Classes da tela de log in do aplicativo móvel
Fonte: elaborado pelo autor.
Após o usuário autenticar-se na aplicação, ele é redirecionado para a tela home. Na Figura 15 é apresentado o seu diagrama de classes. Da mesma forma que é representado na Figura 14, a tela home também se associa com a MainStore, para pode acessar a HomeStore, que possui os atributos que armazenam as notícias vindas da API. Além de armazenar, a classe HomeStore também é responsável por controlar os valores informados nos filtros e fazer o acesso a API, através da classe HomeService. As classes de sufixo service são as classes que se encontram na camada de serviço da aplicação, em que toda a regra de negócio referente a determinado domínio deve estar escrita.
37 Figura 15 – Diagrama de Classes da tela principal do aplicativo móvel
Fonte: elaborado pelo autor.
Seguindo o mesmo modelo de arquitetura e desenvolvimento das outras telas, na Figura 16 é apresentado o diagrama de classes da tela de detalhe da notícia. Nela é apresentado o sentimento médio da notícia, gráfico de sentimentos dos parágrafos e os papéis relacionados a ela, além do botão que permite ao usuário acessar a notícia na íntegra.
38 Figura 16 – Diagrama de Classes da tela de detalhe da notícia
Fonte: elaborado pelo autor.
Por fim, na Figura 17, é apresentado o diagrama de classes da tela de histórico de cotação do ativo, que apresenta um gráfico interativo com a cotação do ativo selecionado na tela de detalhe da notícia.
Figura 17 – Diagrama de Classes da tela de histórico de cotação do ativo
39 3.2.7 Diagrama de Classes da API
Nesta subseção são apresentados os três diagramas de classe da API. Cada diagrama possui as especificações referentes a cada domínio da aplicação para que os diagramas não fiquem muito extensos. O objetivo da separação da implementação por domínio é tornar o código mais legível para os desenvolvedores, pois cada domínio deve representar uma unidade em nível de regra de negócio.
A Figura 18 detalha as classes envolvidas no domínio de notícia. A classe
NewsController é responsável por lidar com as requisições Hypertext Transfer Protocol (HTTP) vindas do aplicativo móvel, para isso, ela acessa os métodos de busca no banco de dados definidos pela interface NewsRepository.
Figura 18 – Diagrama de Classes – domínio de notícias da API
Fonte: elaborado pelo autor.
O domínio de notícia possui dependência do domínio de parágrafo, apresentado na Figura 19, pois o objeto retornado para o aplicativo móvel pelo NewsController inclui os parágrafos e seu sentimento, para que o gráfico de sentimentos possa ser montado. A API também expõe o ParagraphController, para caso seja necessário retornar os dados de algum parágrafo específico ou visualizar os ativos citados no parágrafo.
40 Figura 19 – Diagrama de Classes – domínio de parágrafos da API
Fonte: elaborado pelo autor.
Por fim, é apresentado o diagrama de classes do domínio de tarefas agendadas (Figura 20), na qual é executada a tarefa de análise de sentimento das notícias e parágrafos, representados por duas classes: ParagraphSentimentAnalyzerScheduler e
NewsSentimentAnalyzerScheduler. As duas tarefas são executadas de forma concorrente, a
classe ParagraphSentimentAnalyzerScheduler analisa o sentimento de todos os parágrafos que ainda não foram analisados, já a classe NewsSentimentAnalyzerScheduler
analisa o sentimento de todas as notícias que ainda não foram analisadas.
Para a execução de ambos os timers é utilizada a classe SentimentService, onde são encontrados os métodos contendo a regra de negócio para análise de sentimentos, que, nesse caso, é o acesso ao serviço AwsComprehendService, em que são chamados os métodos de análise de sentimento do SDK do Amazon Comprehend. A aplicação foi desenvolvida em camadas para diminuir o acoplamento entre as classes, por exemplo: caso seja necessário alterar o serviço de análise de sentimento, por algum motivo, é necessário efetuar a troca somente na classe SentimentService, acessando um novo serviço de análise de sentimentos. Dessa forma, o código se torna mais manutenível.
41 Figura 20 – Diagrama de Classes – domínio de tarefas agendadas
Fonte: elaborado pelo autor.
3.2.8 Diagrama de Implantação
A Figura 21 apresenta o diagrama de implantação da aplicação como um todo. É possível visualizar todos os artefatos implantáveis, parte das tecnologias que foram utilizadas para o desenvolvimento da aplicação, bem como o relacionamento entre os artefatos, com a descrição do protocolo de comunicação utilizado.
42 Figura 21 – Diagrama de Implantação da aplicação
Fonte: elaborado pelo autor.
Na Figura 21 é possível visualizar os componentes da arquitetura e a seção 3.3 descreve em maiores detalhes o funcionamento de cada componente, bem como a tecnologia utilizada durante o desenvolvimento, sendo:
a) Firebase Authentication: serviço de autenticação utilizado para registrar e autenticar usuários no aplicativo móvel, utilizado através do protocolo HTTP. b) AWS Comprehend: serviço de análise de sentimentos, utilizado pela API através do
protocolo HTTP.
c) Azure SQL Database: serviço de banco de dados em nuvem da Azure10, utilizado pelo Web Scraper e API.
43 d) Web Scraper: artefato responsável por extrair as notícias dos portais, implantado
numa imagem Docker no ambiente de Web App for Containers na Azure11, faz operações de escrita no banco de dados via conexão ODBC.
e) API: artefato responsável por expor os dados das notícias para o aplicativo móvel, implantado numa imagem Docker no ambiente de Web App for Containers na Azure, faz operações de leitura e escrita no banco de dados via conexão ODBC. f) B3-News App: aplicativo móvel utilizado pelo usuário final, interage com a API via
protocolo HTTP. Possui dois artefatos: b3_news.apk disponibilizado para dispositivos Android; b3_news.ipa disponibilizado para dispositivos iOS.
Na Figura 21 também é possível observar a legenda do diagrama, explicando alguns termos utilizados no desenvolvimento e implantação da aplicação.
3.2.9 Modelo Entidade Relacionamento
O MER (Figura 22) representa as entidades persistentes da aplicação no banco de dados SQL Server. Cada entidade é representada por uma tabela no banco de dados, a seguir é apresentada uma breve descrição de cada entidade utilizada pela aplicação:
a) news: entidade que armazena as informações das notícias e seu respectivo sentimento de forma detalhada, através dos campos mixed, negative, neutral e
positive. O campo sentiment armazena o sentimento médio da notícia;
b) paragraphs: entidade que armazena as informações dos parágrafos e seu respectivo sentimento de forma detalhada, seguindo o mesmo padrão de colunas da entidade news;
c) stocks: entidade que armazena todas as ações listadas na Bolsa, junto à razão social e ao nome fantasia da empresa;
d) stocks_news: entidade intermediária resultante da cardinalidade N para N entre as entidades stocks e news, armazena os ativos citados na notícia.
11 Aplicativos Web para Contêineres – Disponível em:
44 Figura 22 – Modelo Entidade Relacionamento
Fonte: elaborado pelo autor.
3.2.10 Protótipo de telas da aplicação B3-Feed
Para o levantamento das informações ainda foi utilizado uma abordagem de prototipação na ferramenta Draw.io12 para simular a usabilidade do aplicativo móvel e o fluxo de negócio que ele possui. Para a parte inicial do aplicativo foram feitos dois protótipos, apresentados na Figura 23, detalhando a página de log in (A) e a página de registro (B).
Figura 23 – Protótipo das telas iniciais da aplicação
Fonte: elaborado pelo autor.
Após autenticar-se na aplicação, o usuário é redirecionado para a tela home, onde são listadas as últimas notícias agrupadas por data e ordenadas de forma decrescente, podendo
45 também filtrar as notícias pelo título, ativos relacionados e data (Figura 24A). O usuário também pode clicar numa notícia, sendo redirecionado para a tela de detalhe da notícia (Figura 24B), em que é possível visualizar o gráfico de sentimentos da notícia, ler a notícia na íntegra e visualizar os ativos relacionados. Caso o usuário clique em algum ativo relacionado, ele será redirecionado para a tela de histórico de cotação (Figura 24C), no qual é apresentado um gráfico interativo do histórico de cotação do ativo.
Figura 24 – Protótipo das telas de notícia e detalhes da notícia
Fonte: elaborado pelo autor.
3.3 IMPLEMENTAÇÃO
Nesta seção são apresentadas as técnicas e as ferramentas utilizadas para o desenvolvimento da aplicação B3-Feed (subseção 3.3.1), junto à operacionalidade da implementação (subseção 3.3.2).
3.3.1 Técnicas e ferramentas utilizadas
Para desenvolver o projeto intitulado B3-Feed foram utilizados como linguagem de programação Java para a API, Python para o Web Scraper e Dart para o aplicativo móvel.
46 Para o desenvolvimento Java, utilizou-se a IDE Eclipse junto ao plugin Spring Tool Suite13, para facilitar o desenvolvimento utilizando o framework Spring Boot14. Para gerenciar as dependências em tempo de compilação, utilizou-se o Apache Maven15.
Na implementação do Web Scraper foi utilizado o editor Visual Studio Code16 em conjunto à extensão para desenvolvimento em Python. Para criar um ambiente virtual de desenvolvimento e gerenciar as dependências da aplicação foi utilizado o Pipenv17. No desenvolvimento do aplicativo móvel utilizou-se a linguagem Dart, adotada pelo framework Flutter, utilizada para implementar aplicativos para Android, iOS e web com uma única base de código.
Para o desenvolvimento do aplicativo móvel também foi utilizado o editor Visual Studio Code, junto à extensão disponibilizada pelo Flutter para agilizar o desenvolvimento. Durante a etapa de desenvolvimento e testes foram utilizados dois Android Virtual Device (AVD), criado através da plataforma Android Studio, para simular a aplicação em duas versões diferentes da API do Android18.
Para armazenamento de dados da aplicação utilizou-se o banco de dados SQL Server fornecido pelo serviço Banco de Dados SQL do Azure19. O Sistema Gerenciador de Banco de Dados (SGBD) utilizado foi o DBeaver20. A fim de manter os artefatos da aplicação na mesma plataforma que o banco de dados também foi utilizado o Azure para fazer a implantação dos artefatos em servidores remotos, sendo executados no serviço Aplicativos Web para Contêineres do Azure. As imagens Docker21 executadas no Azure estão armazenadas no DockerHub22, uma plataforma de hospedagem de imagens Docker.
Todo o código implementado está disponível no website Github23, uma plataforma de hospedagem de código-fonte que utiliza o Git24 como controlador de versão (GITHUB, 2020). Na Figura 25 é possível visualizar que a aplicação B3-Feed está separada em três repositórios, um para cada parte da aplicação: b3-news-api, b3-news-scraper e b3_news_app.
13 Spring Tool Suite – Disponível em: https://spring.io/tools. Acesso em: 6 jun. 2020.
14 Spring Boot – Disponível em: https://spring.io/projects/spring-boot. Acesso em: 6 jun. 2020. 15 Apache Maven – Disponível em: https://maven.apache.org/. Acesso em: 6 jun. 2020.
16 Visual Studio Code – Disponível em: https://code.visualstudio.com/. Acesso em: 6 jun. 2020. 17 Pipenv – Disponível em: https://pipenv.pypa.io/en/latest/. Acesso em: 6 jun. 2020.
18 Android – Disponível em: https://www.android.com/. Acesso em: 6 jun. 2020.
19 Banco de Dados SQL do Azure – Disponível em: https://azure.microsoft.com/pt-br/services/sql-database/.
Acesso em: 6 jun. 2020.
20 DBeaver – Disponível em: https://dbeaver.io/. Acesso em: 6 jun. 2020. 21 Docker – Disponível em: https://www.docker.com/. Acesso em: 6 jun. 2020. 22 DockerHub – Disponível em: https://hub.docker.com/. Acesso em: 6 jun. 2020. 23 Github – Disponível em: https://github.com/. Acesso em: 6 jun. 2020.
47 Figura 25 – Repositórios Github
Fonte: elaborado pelo autor.
3.3.2 Desenvolvimento do sistema
Nesta seção são apresentadas as principais funcionalidades que constituem a arquitetura da aplicação, bem como as partes integrantes necessárias para seu funcionamento. 3.3.2.1 Web Scraper de notícias
O Web Scraper é responsável por extrair as notícias e seus parágrafos de três portais de notícias: Exame.com, Suno Notícias e InfoMoney. Para isso, na primeira etapa de execução do Web Scraper são registradas as tarefas de execução de varredura de notícias a cada 15 minutos, como pode ser visto no Quadro 8.
Quadro 8 – Registro da execução das varreduras
48 Conforme apresentado no Quadro 8, a execução periódica é registrada na linha 9, através do modulo schedule que é disponibilizado pela linguagem Python. O callback da execução periódica é o método scrap, em que são invocadas as varreduras do Exame.com, Suno Notícias e InfoMoney, respectivamente, cada uma sendo executada em sua classe específica conforme apresentado na Figura 13.
A execução da varredura de notícias é feita em classes separadas, uma para cada portal noticiário. É possível visualizar no Quadro 9, Quadro 10 e Quadro 11 que o código, nos métodos get_news_ignoring_fetched_links e get_news_content_by_href, é muito semelhante, variando somente as classes CSS que são utilizadas para a busca de textos dentro de elementos HTML. O Quadro 9 apresenta a busca de notícias e parágrafos do portal Exame.com, primeiro a ser executado na chamada do callback scrap.
Quadro 9 – Busca de notícias e parágrafos do Exame.com
