Plataforma online sobre Perguntas e Respostas - Jogo Decifre

(1)

Rodrigo de Azevedo Fernandes

Plataforma online sobre Perguntas e Respostas - Jogo Decifre

Natal – RN

Abril de 2021

(2)

Rodrigo de Azevedo Fernandes

Plataforma online sobre Perguntas e Respostas - Jogo Decifre

Trabalho de Conclusão de Curso de Engenha- ria de Computação da Universidade Federal do Rio Grande do Norte, apresentado como requisito parcial para a obtenção do grau de Bacharel em Engenharia de Computação Orientador: Aquiles Burlamaqui

Universidade Federal do Rio Grande do Norte – UFRN Departamento de Engenharia de Computação e Automação – DCA

Curso de Engenharia de Computação

Natal – RN

Abril de 2021

(3)

Rodrigo de Azevedo Fernandes

Plataforma online sobre Perguntas e Respostas - Jogo Decifre

Trabalho de Conclusão de Curso de Engenha- ria de Computação da Universidade Federal do Rio Grande do Norte, apresentado como requisito parcial para a obtenção do grau de Bacharel em Engenharia de Computação Orientador: Aquiles Burlamaqui

Trabalho aprovado. Natal – RN, 22 de Abril de 2021:

Prof. Dr. Aquiles Burlamaqui - Orientador UFRN

Prof. Dr. Rummenigge Dantas - Banca UFRN

Prof. Dr. Igor Rosberg - Banca UFRN

Natal – RN

Abril de 2021

(4)

Dedico este trabalho aos meus pais. Sem o esforço deles não conseguiria chegar até aqui.

Vocês são meus heróis.

(5)

AGRADECIMENTOS

Aos meus pais, por todo o esforço e amor atribuídos a mim durante toda a minha vida.

Ao meu amigo Marcus Dantas, por ter desenvolvido este projeto comigo e me ensinado diversas coisas.

Ao professor Aquiles, por ter sido meu orientador e ter desempenhado tal função com dedicação.

Aos meus colegas de curso, com quem convivi intensamente durante os últimos anos, pelo companheirismo e pela troca de experiências que me permitiram crescer não só como pessoa, mas também como formando.

(6)

“O nitrogênio em nosso DNA, o cálcio em nossos dentes, o ferro em nosso sangue, o carbono em nossas tortas de maçã foi feito no interior das estrelas em colapso.

Nós somos feitos da poeira de estrelas."

(Carl Sagan)

(7)

RESUMO

Neste trabalho, foi desenvolvido um jogo de plataforma online sobre perguntas e respostas chamado Decifre. O jogo tem por objetivo a compra de cifras (moeda virtual do jogo) no intuito de jogar rodadas de perguntas aleatórias geradas automaticamente, tendo como premiação mais cifras ou prêmios especiais de patrocinadores. As cifras podem ser compradas no intuito de jogar rodadas com premiações melhores e, também, podem ser usadas para saque em dinheiro, utilizando de uma conversão do sistema. O jogo foi disponibilizado online e foi jogado por diversos jogadores.

Palavras-chaves: jogo, Decifre, rodadas, moedas.

(8)

ABSTRACT

In this work, an online platform game about questions and answers called decipher was developed. The game aims to purchase ciphers (virtual currency of the game) in order to play randomly generated rounds of random questions, with the awarding of more ciphers or special sponsor prizes. The figures can be purchased in order to play rounds with better payouts and can also be used for cash withdrawals using a system conversion. The game was made available online and was played by several players.

Keywords: game. Decifre, rounds, coins.

(9)

LISTA DE ILUSTRAÇÕES

Figura 1 – Estrutura de mensagens HTTP. . . 17

Figura 2 – A Camada MVC . . . 19

Figura 3 – Entidade no DER . . . 21

Figura 4 – Relacionamento Entre Entidade no DER . . . 21

Figura 5 – Associação Entre Classes . . . 22

Figura 6 – Diagrama de Classes . . . 23

Figura 7 – Tabela de Comparação Entre Jogos Relacionados . . . 28

Figura 8 – Banner de rodada aberta com taxa de entrada . . . 30

Figura 9 – Tela de compra de cifras . . . 30

Figura 10 – Tela de saque de cifras . . . 31

Figura 11 – Tela de Controle de Transações . . . 31

Figura 12 – Dados Gerais de uma Rodada . . . 35

Figura 13 – Dados de Cifras de uma Rodada . . . 36

Figura 14 – Banner de uma Rodada Aberta . . . 36

Figura 15 – Rodada Aberta . . . 37

Figura 16 – Rodada Finalizada . . . 38

Figura 17 – Classificação do Usuário na Rodada . . . 38

Figura 18 – Painel de Treino . . . 39

Figura 19 – Tela de Treino . . . 40

Figura 20 – Tela de Treino Sem Vidas . . . 41

Figura 21 – Tela de Ranking Semanal . . . 41

Figura 22 – Diagrama de Classes UML . . . 42

Figura 23 – Diagrama de Entidade Relacionamento DER . . . 43

Figura 24 – Arquitetura de Arquivos Front End . . . 49

Figura 25 – Tela Inicial Decifre . . . 52

Figura 26 – Taxas de Entrada de Rodadas . . . 53

Figura 27 – Premiações de Rodadas Jogadas . . . 53

(10)

LISTA DE TABELAS

Tabela 1 – Métodos HTTP mais comuns . . . 16 Tabela 2 – Status HTTP mais comuns . . . 17

(11)

LISTA DE CÓDIGOS

2.1 Mapeamento de Rotas com Express . . . 24

2.2 Requisição de API com Axios . . . 25

4.1 Algoritmo de Web Scraping . . . 32

4.2 Algoritmo de Persistência de Dados Raspados . . . 34

4.3 Trecho de Rotas para Cadatro de Novos Usuários . . . 46

4.4 Geração de Token de Usuário . . . 46

(12)

LISTA DE ABREVIATURAS E SIGLAS

HTML HyperText Markup Language HTTP Hypertext Transfer Protocol CSS Cascading Style Sheet JSON JavaScript Object Notation

API Application Programming Interface REST Representational State Transfer ODM Object Document Mapping

DER Diagrama de Entidade Relacionamento UML Unified Modeling Language

(13)

SUMÁRIO

1 INTRODUÇÃO . . . 14

1.1 Motivação . . . 14

1.2 Objetivos . . . 15

1.3 Estrutura do Trabalho . . . 15

2 FERRAMENTAS UTILIZADAS . . . 16

2.1 Sistemas Web . . . 16

2.2 Protocolo HTTP . . . 16

2.2.1 Métodos HTTP . . . 16

2.2.2 Status HTTP . . . 16

2.2.3 Mensagens HTTP . . . 17

2.3 API RESTFUL . . . 18

2.4 Json . . . 18

2.5 Modelo MVC . . . 18

2.6 Banco de Dados . . . 19

2.6.1 Mongo Database . . . 20

2.7 Diagrama de Entidade Relacionamento . . . 20

2.8 Diagrama de Classes . . . 22

2.9 NodeJS . . . 23

2.9.1 Express . . . 24

2.9.2 Middleware . . . 24

2.9.3 ODM . . . 24

2.9.3.1 Mongoose . . . ²⁴

2.10 React . . . 25

2.10.1 Axios . . . 25

2.11 Json Web Token . . . 25

2.12 Web scraping . . . 26

2.13 Scheduling Jobs . . . 26

3 TRABALHOS RELACIONADOS . . . 27

4 O JOGO DECIFRE . . . 30

4.1 Sobre o Jogo . . . 30

4.1.1 Cifras . . . 30

4.1.1.1 Transações . . . ³¹

4.1.2 Questões . . . 32

(14)

4.1.2.1 Mineração de Questões. . . ³²

4.1.3 Rodadas. . . 35

4.1.3.1 Jobs de Finalização de Rodada . . . ³⁸

4.1.4 Modo de Treino . . . 39

4.2 Modelagem . . . 41

4.2.1 Diagrama de Classes UML . . . 42

4.2.2 Diagrama de Entidade Relacionamento DER. . . 43

4.3 A API . . . 44

4.3.1 Arquitetura MVC . . . 44

4.3.1.1 Controllers . . . ⁴⁵

4.3.1.2 Models . . . ⁴⁵

4.3.2 Autenticação . . . 46

4.3.2.1 Cadastro de Usuários. . . ⁴⁶

4.3.2.2 Middleware . . . ⁴⁷

4.4 A Aplicação . . . 48

4.4.1 Provedores . . . 49

4.4.2 Telas . . . 50

4.4.2.1 Funcionamento . . . ⁵⁰

5 RESULTADOS . . . 52

6 CONCLUSÃO . . . 54

REFERÊNCIAS . . . 55

(15)

14

1 INTRODUÇÃO

O mercado de jogos online pertence a um nicho geral de jogos, contendo desde dispositivos portáteis como oPlaystation, até jogos de tabuleiro mais simples. No entanto, os jogosonline vêm apresentando um crescimento exponencial nos últimos anos, chegando próximo dos chamados jogos offline. Por exemplo, "Em 2013, a H2 Gambling Capital, a maior fonte de dados sobre este mercado, apresentou dados que mostravam como a vertente online representava mais de 17% do mercado total europeu do jogo"(FEP, 2016, p. 4).

Dentro do nicho interno de jogosonline, encontram-se os jogos de apostas. Este tipo de jogoonline vem se expandindo de forma exponencial, tendo crescido 14% na década de 2001 à 2010. Contudo, desde a década passada, os jogos de apostas deste nicho possuem um crescimento acelerado de 9% anual, cujo foi responsável por uma receita bruta de 28.24 bilhões de euros em todo o mundo no ano de 2015.(GAINSBURY NERILEE HING, 2014, p. 4).

Em um contexto ainda mais específico, existem os jogos de quiz. Desde o ano de 2016 este tipo de jogo online começou a juntar milhões de usuários na China e, logo após, expandindo-se para todo o mundo. Jogos chineses comoBaiwan Yingjia,Zhishi Chaoren e oChongding Dahui apareceram como os jogos mobile mais jogados na época. Segundo o Centro de Informação de Internet da China, até junho de 2017, o número de usuários que jogavam este tipo de jogo na China, seja por celular ou computador, já chegava a marca de 343 milhões de pessoas, representando 45.6% da população que utilizava internet no país. Estima-se também que este conjunto de jogos movimentaram cerca de 3 bilhões de dólares na China só em 2016.

1.1 Motivação

Devido a alta dos jogos de apostas apontados anteriormente, obtivemos o encoraja- mento de desenvolver um jogo online para web e mobile. O jogo trata-se de um esquema de perguntas e respostas em que pessoas do mundo inteiro possam fazer transações de uma moeda virtual interna para jogar rodadas de perguntas e respostas à fim de de obter mais moedas e/ou premiações patrocinadas. As moedas poderiam ser usadas como um pagamento de entrada de rodadas com premiações melhores, estimulando a compra das mesmas por usuários através da nossa plataforma. Os usuários vencedores de rodadas com premiações em moeda virtual, poderiam realizar um saque, em dinheiro, oferecendo suas moedas de acordo com uma conversão do sistema em reais.

(16)

Capítulo 1. Introdução 15

1.2 Objetivos

O objetivo inicial do projeto é de desenvolver um jogo online para web e mobile, de uma forma escalável. Inicialmente, o jogo estaria hospedado em um ambiente gratuito com o intuito de que usuários beta testers possam jogar o máximo possível, oferecendo correções eventuais e feedbacks de novas funcionalidades futuras.

Em um segundo momento, para que o jogo possa ter uma confiança de que perguntas não sejam repetidas com certa frequência, tem-se o objetivo de cadastrar previamente uma grande quantidade de questões no sistema.

Por fim, ao fim de cada rodada de perguntas, as transferências das premiações em moedas virtuais, devem ser feitas de forma automática pelo sistema para evitar atrasos manuais ou até mesmo falhas humanas, garantindo assim a melhor experiência possível para os usuários jogadores.

1.3 Estrutura do Trabalho

Este trabalho apresenta uma introdução sobre o tema, mostrando um pouco sobre o mercado de jogos, com ênfase no mercado de jogos de apostas. Logo após é apresentado os fatores que motivam a implantação da ideia, além da justificativa e dos objetivos.

Em sequência, o Capítulo 2 aborda todo o referencial teórico dos temas abordados no projeto. O Capítulo 3, por sua vez, traz um comparativo entre o projeto e outros trabalhos relacionados. O Capítulo 4 trata de explicar mais a solução do projeto, aprofundando no uso das tecnologias e nas metodologias utilizadas. O Capítulo 5 apresenta os resultados obtidos a partir das metodologias e tecnologias aplicadas no capítulo anterior. Por fim, o Capítulo 6 traz as principais conclusões e contribuições deste trabalho.

(17)

16

2 FERRAMENTAS UTILIZADAS

2.1 Sistemas Web

Um sistema web é uma aplicação disponível na internet ou localmente, normalmente acessada por uma navegadorweb. Os sistemas web são hospedados por servidores, sendo estes responsáveis por se comunicar com o cliente (normalmente um navegadorweb) por requisições HTTP.

2.2 Protocolo HTTP

O HTTP (Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto) é uma linguagem global usado por toda a internet, em que todas as páginas, navegadores e servidores comunicam-se entre si. Ele utiliza de um protocolo de transmissão de dados seguro que garante que todos os dados enviados sejam recebidos sem dano e sem duplicidade, garantindo confiabilidade e segurança.

2.2.1 Métodos HTTP

Quando entramos em um site em um navegador, digitamos uma URL na barra de endereços e fazemos uma requisição HTTP à um servidor que, por sua vez, irá receber esta requisição, realizar os processamentos necessários e retornar uma resposta. No entanto, para que o servidor saiba qual a ação que o cliente espera que ele realize, ele necessita que o cliente identifique um método na requisição. Os métodos HTTP mais comuns são especificados na Tabela 1.

Método HTTP Descrição

GET Envia o recurso nomeado do servidor para o cliente.

POST Envia dados do cliente para um aplicativo de gateway de servidor PUT Armazena dados do cliente em um recurso de servidor nomeado DELETE Exclui o recurso nomeado de um servidor

HEAD Envia apenas os cabeçalhos HTTP da resposta para o recurso nomeado Tabela 1 – Métodos HTTP mais comuns

Fonte – (O’REILLY, 2002, p. 11, tradução do autor)

2.2.2 Status HTTP

Depois que o cliente envia a requisição HTTP para um servidor contendo um método, o servidor processa a informação de acordo com o método passado e retorna o

(18)

Capítulo 2. Ferramentas Utilizadas 17

resultado. Para que o cliente entenda se a requisição teve sucesso ou falha, o servidor necessita enviar de volta um código de status HTTP. O status HTTP é um código numérico de três dígitos que possui um significado. A Tabela 2 apresenta alguns dos status mais comuns.

Status HTTP Descrição

200 Ok. Documento retornado corretamente.

201 Dado criado com sucesso.

203 Não autorizado. A informação não pode ser exibida devido a falta de autorização.

400 Requisição ruim. Não processa a requisição devido a um erro do cliente.

404 Não encontrado. Não consegue encontrar o recurso.

500 Erro interno. Erro não esperado no servidor.

Tabela 2 – Status HTTP mais comuns

Fonte – (O’REILLY, 2002, p. 12, tradução do autor)

2.2.3 Mensagens HTTP

No protocolo HTTP, existem dois tipos de mensagens: a mensagem de requisição e a mensagem de resposta. A mensagem de requisição possui uma linha inicial e um cabeçalho, enquanto a mensagem de saída, além dos dois citados, possui também um corpo, como mostrado na figura Figura 1.

Figura 1 – Estrutura de mensagens HTTP.

Fonte – (O’REILLY, 2002, p. 13).

• Linha inicial (Start line): Mostra o que fazer com a requisição ou o que aconteceu de resposta.

• Cabeçalho (Header): Conjunto de linhas, em que cada linha possui uma chave/valor.

A última linha do cabeçalho é uma linha em branco. Itens apenas informacionais.

• Corpo (Body): Qualquer tipo de dado como resposta à uma requisição.

(19)

2.3 API RESTFUL

API (Application Programming Interface - Interface de Programação de Aplicação) é um conjunto de normas de alto nível, utilizadas para estabelecer comunicações entre plataformas por meio de padrões e protocolos. REST (Representational State Transfer - Transferência Representacional de Estado) é uma arquitetura de comunicação que utiliza de princípios e protocolos existentes naweb. O termo RESTFUL vem de que a maioria das APIs nos dias de hoje possuem conceitos de outras tecnologias que não apenas o HTTP ou REST, ou seja, há uma junção de tecnologias próprias do protocolo HTTP com outras existentes em outros programas como, por exemplo, a definição deendpoints e parâmetros.

A formatação de dado mais comum para realizar a transferência de informações entre duas aplicações por meio de uma APIRestful, é o Json.

2.4 Json

JSON (JavaScript Object Notation - Notação de Objetos JavaScript) é uma formata- ção de troca de dados leve, muito fácil para interpretação humana e facilmente manipulada pelas máquinas. É baseado em Javascript, mas pode ser usado por qualquer liguagem de programação, fazendo com que seja uma formato ideal e fácil para troca de dados. O Json pode ser definida em duas estruturas diferentes: uma coleção de chave/valor, conhecimento em várias linguagens comoobject,struct, dicionários, entre outros. E também como uma lista ordenada de valores, conhecida em outras linguagens como lista, array, vetor ou sequência. No desenvolvimento de APIs, o JSON é um dos formatos de troca de dados mais utilizadas devido a todas as facilidades apresentadas nesta subseção.

2.5 Modelo MVC

Dentro de um projeto de desenvolvimento de software, precisamos organizar o código de uma maneira que fique de fácil visualização e manutenção para terceiros. Ou seja, o código precisa estar organizado para que qualquer outro programador possa entendê-lo e, principalmente, para que quando haja alguma alteração ou manutenção em algum ponto do projeto, outros lugares não sejam afetados.

O modelo MVC é uma forma de organização do código de uma aplicação em camadas, separando todo o código em três partes bem distintas, facilitando o entendimento e desacoplando dependências entre elas.

A sigla MVC vem do termo Model-View-Controller (Modelo-Visão-Controlador), sendo representado pelas três camadas de organização do código mostrado na Figura 2.

(20)

Figura 2 – A Camada MVC

Fonte – (BALTHAZAR FáBIO M. R. GUIMARãES, 2006, p. 3)

A camada View é a responsável por apresentar todas as interfaces visuais que iteragem com o usuário da aplicação, permitindo a entrada de dados. Por outro lado, a camada deController faz apenas uma intermediação entre as outras duas camadas, sendo responsável por receber as requisições da View e, a partir delas, chamar a camada de Model. Por fim, a Model é a camada que possui todos os dados da aplicação, assim como regras de negócio, ou seja, a "cabeça"da aplicação.

2.6 Banco de Dados

Primeiramente precisamos definir alguns conceitos:

• Dado: um valor de um campo armazenado, uma matéria-prima para obtenção de uma informação.

• Informação: são dados compilados e processados de acordo com uma solicitação.

Um banco de dados nada mais é que uma coleção de dados relacionados com algum significado, de forma que conseguimos obter informações dele. As informações podem ser obtidas através de um Sistema Gerenciador de Base de Dados (SGBD), sistema esse constituído por diversos programas que permitem usuários a criar e manipular um banco de dados.

Dentro do âmbito dos bancos de dados, existem dois tipos predominantes: os bancos relacionais e os não relacionais. Para este trabalho, iremos nos aprofundar em relação aos bancos não relacionais, comumente chamados de NoSQL. Os bancos NoSQL oferecem mais escalabilidade, flexibilidade e uma melhor performance quando comparados aos bancos relacionais e são divididos em quatro tipos:

(21)

• Bancos de Dados de Chave/valor: são bancos de dados simples em que cada item contém chaves e valores, similiar ao json. Esse tipo de banco oferece uma facilidade maior para realizar consultas complexas, pois os resultados das buscas podem ser obtidas diretamente pelas chaves armazenadas. Bancos NoSQL comuns baseados em chave/valor são o Redis e o DynamoDB.

• Bancos de Dados Orientados a Colunas: são bancos que armazenam dados em tabelas, linhas e colunas dinâmicas. Diferentemente dos bancos relacionais, nos bancos NoSQL orientados a coluna, as linhas de uma tabela não precisam ter as mesmas colunas, fazendo com que esse tipo de banco NoSQL seja algo como um banco de chave/valor em uma dimensão 2D. No mercado atual, bancos como Cassandra e HBase utilizam este tipo de armazenamento.

• Bancos de Dados de Grafos: são dados armazenados em grafos, em que cada nó do grafo representa um tipo de informação, e as arestas realizam um relacionamento entre os mesmos. Neo4j e JanusGraph são exemplos deste tipo de banco NoSQL.

• Bancos de Dados de Documentos: são dados armazenados em documentos com estrutura dinâmica, como json ou xml. Como nestes documentos podem ser armazenados quaisquer tipos de dados com uma estrutura de chave/valor, os bancos NoSQL baseado em documentos são os mais comumente usados para a grande parte das aplicações existentes. Neste trabalho iremos nos aprofundar um pouco em um banco de dados de documentos chamado MongoDB.

2.6.1 Mongo Database

MongoDB é um banco de dados de código aberto baseado em documentos, desenvolvido em C++. O Mongo é o banco de dados NoSQL mais popular do mundo e ele armazena dados em documentos BSON, que nada mais são que documentos json binários. Quando comparados a estrutura de bancos relacionais, um documento do Mongo seria o banco de dados em si e uma coleção seria uma tabela. Dentro das coleções, o Mongo armazena cada item como um par de chave/valor, com o valor podendo ser qualquer tipo de dado. Além disso, o mongo suporta uma escalabilidade horizontal com uma fragmentação automática dos seus recursos em servidores, permite o uso de indexes para aumentar a velocidade das consultas de determinadas coleções e possui uma linguagem de consultas simples, baseada em javascript.

2.7 Diagrama de Entidade Relacionamento

O Diagrama de Entidade Relacionamento (DER) é uma ferramenta usada para modelar dados com a finalidade de descrevê-los ou retratá-los de uma forma abstrata. É

(22)

muito utilizado na engenharia de software para descrever ou projetar bancos de dados relacionais. A ideia é de retratar conjunto de dados como entidades e para cada uma das entidades, seus atributos. Cada entidade pode se relacionar com uma ou várias outras de diferentes maneiras possíveis.

A figura abaixo demonstra uma representação de uma entidade padrão. Nela, se tem um cabeçalho com a informação do nome da entidade e, logo abaixo, a lista de atributos que a entidade possui. Em um conceito de banco de dados, o nome da entidade seria o nome da tabela e os atributos suas colunas.

Figura 3 – Entidade no DER

Fonte – O que é um diagrama entidade relacionamento? Disponível em <https://www.lucidchart.com/

pages/pt/o-que-e-diagrama-entidade-relacionamento>. Acessado em 19/03/2021 às 20:02.

Existem vários tipos de relacionamentos entre entidades que podem ser usadas no desenvolvimento de um DER. Dentre as várias opções visuais utilizadas no meio da engenharia de software, as mais comuns são as das relacões de um para um e de um para muitos, mostrados respectivamente na figura abaixo.

Figura 4 – Relacionamento Entre Entidade no DER

Fonte –Cardinality and Modality. Disponível em <https://www.calebcurry.com/

cardinality-and-modality>. Acessado em 19/03/2021 às 21:22.

Uma relação um para um acontece quando a entidade tem uma relação única com alguma outra. Por exemplo, a relação entre uma entidade Pessoa e uma entidade CPF seria de um para um, pois uma pessoa pode ter apenas um CPF e um CPF pode estar ligado apenas a uma pessoa.

Já para uma relação um para muitos, temos por exemplo, uma relação entre um Cliente e um Pedido de um restaurante. A entidade Cliente teria uma relação de um para muitos com a entidade Pedido, pois o primeiro poderia realizar um ou vários pedidos no

(23)

restaurante. O inverso deste exemplo também é bem comum e é chamado de muitos para um, a imagem visual aqui é apenas a inversão da imagem de relação um para muitos.

2.8 Diagrama de Classes

Assim como o diagrama de entidade relacionamentos, o diagrama de classes também é uma ferramenta para análise e descrição de projetos desoftware. Diferentemente do DER, o diagrama de classes (dependendo do seu nível de abstração) possui a capacidade de representar conceitos do projeto, apresentar implementações a nível de código e especificar soluções finais.

Enquanto no DER os conceitos do sistema são chamados de entidades, aqui eles são chamados de classes. As classes são um pouco mais específicas que entidades, pois elas representam um conceito físico de algo que irá ser armazenado no projeto a nivel de código ou de banco de dados, levando em consideração um paradadigma de programação orientada a objetos.

Uma representação de uma classe possui o seu nome e, possivelmente, atributos e métodos. Atributos são dados que pertencem a classe, por exemplo, em uma classe Pessoa, dados como nome e cpf seriam atributos dela. Os métodos são funcionalidades que a classe possui, sendo algo bem mais específico para desenvolvimento e não para um modelo conceitual como apresentado neste projeto.

Classes conceituais de um modelo de diagrama de classes também se comunicam entre si através de relacionamentos. Existem diversos tipos de relacionamentos que podem ser usadas dependendo do conceito do projeto, porém a mais comum delas é a relação de associação, mostrada na Figura 5.

Figura 5 – Associação Entre Classes

Fonte – (PEREIRA, 2011, p. 74).

Pela associação acima podemos notar que existem duas classes, Galinha e Ovo, e que elas se relacionam de maneira que uma galinha bota um ou mais ovos. Podemos também ver pelo inverso, em que um ovo é "botado"por uma galinha apenas.

Um exemplo mais completo de um diagrama de classses pode ser visto na Figura 6.

(24)

Figura 6 – Diagrama de Classes

Fonte – (PEREIRA, 2011, p. 63).

Na imagem acima podemos notar que existem dez classes conceituais no diagrama, e na sua maioria atributos foram atribuídos. Por exemplo, um Produto possui código, descrição, preço unitário e quantidade em estoque e ele se associa a um ItemDePedido de forma que um produto pode estar relacionado a vários itens de pedido. O item de pedido por sua vez, se relaciona com um Pedido de forma que um Pedido pode ter um ou vários itens.

No diagrama também notamos um tipo de relacionamento diferente entre ClientePF e ClientePJ com a classe Cliente. Esse tipo de relacionamento é chamado de generalização e é usado quando elementos mais específicos herdam todas as caracterísitcas de um elemento mais geral.

2.9 NodeJS

NodeJS é um ambiente de execuçãojavascript server-side, ou seja, podemos rodar uma aplicação javascript na nossa máquina sem a necessidade de um navegador web. Por ser muito simples, baixo custo, flexível e ter uma alta capacidade de escala, o NodeJS torna-se uma tecnologia excelente para desenvolvimento de APIs e microsserviços e é utilizado por várias empresas grandes como Uber, Netflix, e Linkedin, por exemplo.

(25)

2.9.1 Express

Express é umframework para NodeJS extremamente simples e flexível e fornece um conjunto de recursos para aplicaçõesweb. Dentro dos mais importantes, podemos destacar o a diferenciação de métodos HTTP em diferentes URLs, a definição de configurações comuns da aplicação e o uso de middlewares para processar requisições. O Código 2.1 mostra um exemplo básico de mapeamento de rotas com Express.

1 var express = r e q u i r e (’ express ’) ; 2 var app = express ( ) ;

3

4 app . get (’/ ’, function ( req , r e s ) {

5 r e s . send (’ Resposta de uma requisicaoo GET ’) ;

6 }) ;

7

8 app . post (’/ ’, function ( req , r e s ) {

9 r e s . send (’ Resposta de uma requisicaoo POST ’) ;

10 }) ;

Código 2.1 – Mapeamento de Rotas com Express

2.9.2 Middleware

O middleware é uma camada oculta que se localiza entre uma parte mais interna e externa de uma aplicação. No caso de desenvolvimento de aplicações Web e APIs, o middleware pode ser usado como uma função de comunicação podendo realizar ações como autenticações de segurança, consulta de mensagens e processamento de ações.

2.9.3 ODM

ODM (Object Document Mapping - Mapeamento de Documento de Objeto) é um modelo de dados capaz de performar comandos a nível de banco de dados não relacionais, como o MongoDB. Ele pode realizar operações comoqueriese CRUDS (create,read,update, delete - criar, ler, atualizar, deletar), usando um paradigma orientado à objetos, sem a

necesidade de usarmos a própria sintaxe do banco de dados que estamos trabalhando.

2.9.3.1 Mongoose

Mongoose é uma biblioteca de ODM para MongoDB e NodeJS. Ele faz o mapeamento dos dados do Mongo, provê validação de esquemas e realiza a tradução entre os objetos do código com os documentos do Mongo.

(26)

2.10 React

O React é uma biblioteca javascript de código aberto desenvolvida pelo Facebook para construir aplicações de interface para front end. Um dos pontos principais do React é o fato de que é possível criar componentes, sendo estes uma forma fácil de reusar elementos HTML, dando maior agilidade e efetividade na criação de toda a interface. Além dos componentes, o React também possui o conceito de estado, que nada mais é que um objeto json global que facilita a manipulação de dados para envio e recebimento através de uma API.

2.10.1 Axios

Axios é uma biblioteca de código aberto desenvolvimento pela comunidade, usado como um cliente HTTP para realizar requisições. A biblioteca traz diversas facilidades, pois adota uma sintaxe simples, suporta a proteção contra XRSF, intercepta requisições e respostas e transforma automaticamente os dados recebidos em JSON. O Código 2.2 mostra um exemplo básico de uma requisição GET para um endpoint disponível em

"alguma-api". O Axios automaticamente já recebe a requisição, com sucesso ou não, e a transforma em JSON.

1 import a x i o s from ’ axios ’; 2

3 const requisicaoAPITeste = async ( ) => {

4 l e t dataResponse ;

5

6 try {

7 dataResponse = await ax i o s . get ( ‘/ alguma−api ‘ ) ; 8 }catch( e r r o r ) {

9 dataResponse = e r r o r . response . data ;

10 }

11

12 return dataResponse ;

13 }

Código 2.2 – Requisição de API com Axios

2.11 Json Web Token

JSON Web Token (JWT) é uma estrutura compacta e segura utilizada para transmitir informações entre duas ou mais partes, utilizando de um objeto json. O JWT pode ser considerado seguro porque é gerado e verificado digitalmente, podendo ser utilizado

(27)

um algoritmo de criptografia/descriptografia com um segredo ou por um par de chaves públicas/privadas, usando algoritmos como RSA ou ECDSA.

2.12 Web scraping

Web scrapingengloba uma ampla variedade de técnicas de programação e tecnologias para análise e extração de dados de sitesweb. Por meio de um algoritmo automatizado, esta técnica permite extrair cópia de dados de informações específicas disponíveis emweb sites e manipulá-las ou armazená-las da forma de interesse.

2.13 Scheduling Jobs

Em desenvolvimento de uma aplicações, as vezes surgem tarefas que devem ser repetidas ou apenas acionadas em um determinado tempo. Por exemplo, precisamos que uma aplicação rode um script para atualizar alguns dados de sua base todos os dias ao meio dia.

Para resolver esse tipo de problema, várias bibliotecas foram desenvolvidas em diversas linguagens de programação com o conceito dejobs ou scheduling Jobs, ou seja, são bibliotecas que rodam um determinado trecho de código de tempos em tempos, definido pelo usuário.

(28)

27

3 TRABALHOS RELACIONADOS

Nesta seção irão ser abordados dois jogos online relacionados ao tema do projeto, o Perguntados, oQuizze e oHQ Trivia. Todos os jogos serão descritos das suas principais funcionalidades, mostrando os pontos fortes e fracos. Ao final, uma tabela comparativa entre os dois aplicativos e o projeto Decifre será representada.

O jogoPerguntadosse baseia no mesmo conceito do trabalho deste projeto: perguntas e respostas. O jogo possui uma boa identidade visual e, na sua mais atual versão, consegue se dividir em quatro variações de jogo: clássico, sobrevivência, pergunta diária e triviathon.

Cada uma dessas variações de jogo provocam diferentes experiências de jogo para o usuário, o mantendo mais engajado no jogo. Além disso, o aplicativo possui diversos tipos de premiações que podem ser usadas para obter vantagens nos jogos, provocando o jogador mais assíduo a realizar uma compra desses objetos, caso sejam necessários. No entanto, o jogo não trás nenhum benefício financeiro aos seus usuários jogadores, sendo apenas uma plataforma em que pessoas podem jogar com seus amigos, sem vínculos financeiros.

OQuize possui uma temática bem mais simples, pois só possui um modo de jogo:

um desafio de perguntas e respostas entre dois amigos. O desafio se baseia em um conjunto de perguntas e respostas que são respondidos por ambos os jogadores. Cada jogador possui uma quantidade de vidas que são perdidas a medida que erros vão acontecendo. O grande diferencial do jogo é o fato da disponibilidade de umQuize Gold, um plano pago por mês que oferece ao jogador vidas extras, pulos extras de questões e três segundos a mais para responder cada uma delas. Contudo, o jogo não traz experiências diferentes para seus usuários e nem premiações, podendo causar uma evasão de um jogador em pouco tempo de experiência.

Diferentemente dos dois anteriores, oHQ Trivia traz uma funcionalidade particular:

a premiação em dinheiro. A ideia principal dogame é uma partida transmitida ao vivo, todos os dias e em horário marcado, com a apresentação de uma pessoa real. As partidas possuem doze perguntas de múltipla escolha, na qual todos os jogadores as respondem concorrentemente em um tempo de dez segundos. Ao final dos dez segundos, a resposta é mostrada e todas as pessoas que erraram são removidas da partida online. Ao final daz doze perguntas, as pessoas que conseguiram responder corretamente todas as perguntas dividem o prêmio geral em dinheiro estipulado para a partida. A fonte de renda principal deste jogo se dá pela venda de moedas na plataforma, sendo elas usadas para compras de itens facilitadores do jogo como vidas extras e um eliminador de alternativas. No entanto, o jogo apenas é jogável quando uma partidaonline é iniciada, sendo ineficiente num contexto offline.

(29)

Capítulo 3. Trabalhos Relacionados 28

Existem diversos outros aplicativos de jogos similares, principalmente chineses, destacando-se o Baiwan Yingjia (ou “Vencedor Milionário”), Zhishi Chaoren (ou “Su- perhomem do conhecimento”) e o Chongding Dahui (ou "Corrida ao Topo"). Todos estes aplicativos possuem as mesmas configurações do jogo HQ Trivia descrito anteriormente, portanto não serão abordados como termo de comparação nesta seção.

A Figura 7 faz um comparativo de seis itens entre os todos os jogos apresentados nesta seção com o projeto do jogo Decifre.

Figura 7 – Tabela de Comparação Entre Jogos Relacionados

Fonte – Feita pelo autor

As descrições das categorias definidas acima podem ser vista na listagem abaixo.

• Mais de uma opção de Jogo: Se dentro do jogo existe mais de uma opção de variação de jogo.

• Compra de Acessórios Na Plataforma: Se dentro do jogo existe algum item ou acessório disponível para compra.

• Jogar com um Amigo: Se o jogo permite um usuário jogar contra um amigo específico.

• Várias Opções de Categorias: Se o quiz possui questões com várias categorias diferentes.

• Jogar em Apenas uma Categoria: Se o jogo permite o usuário a responder questões de apenas uma categoria.

• Ganhar Premiações em Dinheiro: Se o jogo dá a possibilidade de premiações em dinheiro.

Quando comparamos o Descire fom oQuizze, vemos que o único ponto que este trabalho perde vem da opção de jogar uma partida com um amigo. Este projeto não tem por características partidas entre amigos em um primeiro momento, mas sendo totalmente plausível para o futuro uma funcionalidade de partidas entre dois usuários com a aposta de suas cifras.

(30)

Capítulo 3. Trabalhos Relacionados 29

Já quando comparada ao Perguntados, notamos a mesma diferença citada no parágrafo anterior, mas também a questão de poder jogar partidas de uma única categoria.

Este tipo especial de rodada já foi pensada e prevista para uma futura versão do jogo Decifre, podendo por exemplo, gerar rodadas específicas de categorias definidas por um patrocinador.

A comparação deste trabalho com o HQ Trivia, além dos aplicativos chineses citados anteriormente, traz questões novas. Tanto o Decifre quanto o HQ Trivia tem por objetivo principal dar a possibilidade ao usuário de ganhar dinheiro ao responder rodadas de perguntas e respostas. Porém, no aplicativo americano, o jogador tem por obrigação estaronline na hora determinada de início de partida para que tenha a chance de disputá-la, caso contrário, terá de esperar a próxima rodada aberta, podendo levar um ou mais dias. Enquanto isso, o Decifre possibilita o usuário de entrar no jogo no momento em que bem entender para responder a rodada que estiver aberto no momento (podendo entrar em mais de uma rodada), garantindo mais chances de obter sucesso ao decorrer de sua experiência no jogo. Além do ponto anterior, o Decifre também oferece do ambiente de treino, garantindo uma segunda opção a parte principal dogame, incentivando o usuário a permanecer na plataforma por mais tempo.

Mesmo este trabalho estando em um nível inicial de sua maturação, notamos que várias características presentes em outros jogos já estão inseridas aqui. Além disso, o Decifre possui um ponto único em relação a todos os outros jogos da categoria: as cifras.

As cifras permitem que os usuários possam jogar o game tranquilamente no horário que mais for oportuno para ele, ao invés de ter a obrigação de entrar em partidas com horários pré-definidos pela plataforma.

(31)

30

4 O JOGO DECIFRE

4.1 Sobre o Jogo

4.1.1 Cifras

Para que o jogo Decifre tivesse uma dinâmica fácil, rápida e com retorno financeiro, introduzimos o conceito de cifras. As cifras são as moedas virtuais do jogo e são utilizadas para entrar em rodadas que necessitam de uma taxa de entrada em cifras.

Figura 8 – Banner de rodada aberta com taxa de entrada

Fonte – Feito Pelo Autor

A Figura 8 mostra umbanner de uma rodada aberta na tela inicial do jogo com uma taxa de entrada de 100 cifras.

Para os casos em que o usuário não possui cifras o suficiente para adentrar em uma rodada com taxa de entrada, o sistema disponibiliza uma seção de compra de cifras em que o usuário escolhe a plataforma de pagamento e o valor, em reais, da compra. Por difinição inicial, as cifras equivalem a um centavo de real, por exemplo, ao pagar cem reais o usuário iria obter mil cifras. A tela de compra é mostrada abaixo.

Figura 9 – Tela de compra de cifras

Da mesma forma que o usuário pode realizar uma compra de cifras para o possibilitar de jogar rodadas com premiações melhores, ele também pode realizar um pedido de saque.

(32)

Capítulo 4. O jogo Decifre 31

O jogo também disponibiliza de uma tela para realizar o pedido de saque, mostrado na figura Figura 10.

Figura 10 – Tela de saque

4.1.1.1 Transações

Para um maior controle administrativo das movimentações das cifras dentro do sistema, um módulo de transações foi criado. Este módulo tem por objetivo dividir todas as transferências de cifras dentro do sistema em cinco categorias, como mostrado na Figura 11.

Figura 11 – Tela de Controle de Transações

Os tipos de transações podem ser definidas como:

• Premiação: Cifras transferidas do sistema para o usuário vencedor de uma rodada.

• Indicação: Cifras transferidas do sistema para o usuário indicador de um amigo.

• Saque: Cifras transferidas do usuário para o sistema à fim de realizar um saque em dinheiro.

• Compra: Cifras transferidas do sistema para o usuário depois de uma compra na plataforma de pagamento. Também é utilizado em transferências de usuários para o sistema ao pagar uma taxa de entrada de uma rodada.

(33)

• Transferência: Cifras transferidas de usuário para usuário, item ainda não desenvolvido no escopo deste projeto.

4.1.2 Questões

A base do jogo Decifre vem das questões. Cada questão no sistema possui um enunciado, uma categoria, um conjunto de alternativas (apenas uma correta) e uma pontuação de acerto. O sistema disponibiliza de uma tela para criação manual destas questões, no entanto, para que o jogo apresentasse uma maior confiabilidade e praticidade, necessitaríamos de uma base grande de questões e categorias cadastradas previamente.

Para resolver esta situação, utilizamos do conceito de web scraping definido seção 2.12 para minerar questões de umsite web público e gravá-los em nosso banco de dados.

4.1.2.1 Mineração de Questões

O processo para popularmos o nosso banco de dados com questões extraídas da internet possui dois procedimentos. O primeiro procedimento é realizado a mineração das questões utilizando um algoritmo de web scraping e inserindo os resultados dos dados minerados em um arquivo json. O segundo e último passo do processo, é de ler o arquivo json e armazenar cada item do objeto no banco de dados, utilizando de um algoritmo que consiga se comunicar com o mongo e fazer a inserção em lote.

O Código 4.1 mostra a função responsável por minerar as questões do siterachacuca.

com.br e as salvar em um arquivo chamadoquestoes.json. 1 l e t conjuntoUrls = await lerArquivo ( ) ;

2 f o r ( l e t i = 0 ; i<conjuntoUrls . length ; i++){

3

4 l e t questoes = JSON. parse ( f s . readFileSync (" ./ questoes . json ") ) ;

5 l e t questoesUrl = await scraping ( conjuntoUrls [ i ] . u r l ) ;

6 l e t urlRespostas = await pythonScript ( conjuntoUrls [ i ] . u r l ) ; 7

8 i f( urlRespostas!==" Erro ") {

9 l e t $ = c h e e r i o . load ( urlRespostas ) ;

10 l e t c a t e g o r i a = $ (’# breadcrumb ’) . f i n d (’li >a ’) . text ( ) ; 11 c a t e g o r i a = c a t e g o r i a . r e p l a c e (’ Racha CucaQuiz ’,’’) ; 12

13 l e t contador = 0 ;

14 $ (’ol > li ’) . each (function ( i ) {

(34)

15 questoesUrl [ contador ] . corretaTexto = $ ( t h i s ) . f i n d (’.

resposta - correta ’) . text ( ) ;

16 questoesUrl [ contador ] . c a t e g o r i a = c a t e g o r i a ;

17 contador++;

18 }) ;

19

20 questoes . push ( . . . questoesUrl ) ;

21 l e t salvarQuestoes = JSON. s t r i n g i f y ( questoes ) ; 22 f s . writeFileSync (’ index . txt ’, ‘ ${ i } ‘ , ’utf8 ’) ;

23 f s . writeFileSync (’ questoes . json ’, salvarQuestoes , ’utf8 ’ ) ;

24 f s . writeFileSync (’ informacoes . txt ’, ‘ I n d i c e do f o r : ${ i }\ nQuantidade de questoes : ${ questoes . length } ‘ , ’utf8 ’) ;

25 }

26 }

Código 4.1 – Algoritmo de Web Scraping

No código acima, primeiramente é realizado uma leitura de arquivos contendo URLs que serão utilizadas no algoritmo e, para cada uma delas, é realizado uma iteração no laço for. Dentro do laço, possuímos um passo a passo bem definido.

Na linha setenta e cinco, as questões já populadas anteriormente no arquivo json são armazenadas em uma variávelquestoes.

Na linha setenta e seis, chamamos o algoritmo deweb scrapingdesenvolvido passando como parâmetro uma URL contendo um conjunto de questões com suas respectivas alternativas.

No entanto, para que obtivéssemos as respostas das questões, seria necessário clicar em um botão para mostrá-las. Um algoritmo simples de web scraping em javascript não possuía tal funcionalidade. Então, na linha setenta e sete, é utilizado umscript em python que consegue fazer o mapeamento do botão no link específico e realizar o clique para que uma nova tela com as respostas seja carregada. Oscript, então, captura a nova URL e a retorna.

Caso ocorra tudo bem com o script python e a URL das respostas seja retornada, um novo algoritmo de raspagem de dados é implementado da linha oitenta à linha oitenta e nove. Nesta parte do algoritmo, para cada questão raspada anteriormente, uma resposta correta e a categoria são associadas.

Ao final da raspagem de todas as questões, os dados são armazenados no objeto questoes, transformados em string e salvos no aquivo questoes.json. O programa completo usado pode ser visto emhttps://github.com/mpsdantas/raspagem-de-dados-nodejs.

(35)

Após a raspagens dos dados, o segundo e último ponto a ser realizado é a gravação deles no banco de dados. O programa foi desenvolvido em NodeJS e foi utilizado a ODM mongoose definida na subseção 2.9.3.1, para facilitar a persistência dos dados com uma

sintaxe mais simples. Um trecho da função principal pode ser vista no código abaixo.

1 questoesLimpas . map( questao=>{

2 l e t categoriaQuestao ;

3 c a t e g o r i a s . map( ( c ategori a , index )=>{

4 i f( questao . c a t e g o r i a==c a t e g o r i a . nome) categoriaQuestao = index ;

5 }) ;

6 l e t indexCorreta ;

7 questao . a l t e r n a t i v a s . map( ( a l t e r n a t i v a , index )=>{

8 i f( a l t e r n a t i v a . d e s c r i c a o . r e p l a c e (/" "/g , "")==questao . corretaTexto . r e p l a c e (/" "/g , "") ) indexCorreta = index ;

9 }) ;

10 i f( indexCorreta!==undefined ) {

11 l e t novaQuestao = new Questao ({

12 usuario : buscarUsuario [ 0 ] . _id ,

13 enunciado : questao . enunciado ,

14 a l t e r n a t i v a s : questao . a l t e r n a t i v a s ,

15 c a t e g o r i a : c a t e g o r i a s [ categoriaQuestao ] . _id , 16 c o r r e t a : indexCorreta ,

17 corretaTexto : questao . corretaTexto ,

18 pontuacao : 10 ,

19 dataCriacao : new Date ( )

20 }) ;

21 arrayQuestoes . push ( novaQuestao )

22 }

23 }) ;

24 Questao . insertMany ( arrayQuestoes , ( err , docs )=>{

25 i f( e r r ) {

26 c o n s o l e . log (" Aconteceu um erro ") ; 27 }e l s e{

28 c o n s o l e . log ( ‘ ${ docs . length } Arquivos i n s e r i d o s com s u c e s s o . ‘ ) ;

29 p r o c e s s . e x i t (1) ;

30 }

31 })

Código 4.2 – Algoritmo de Persistência de Dados Raspados

(36)

A ideia do trecho definido acima é percorrer a lista de questões raspadas chamadas de questoesLimpas (limpas porque foi feito um processo prévio para eliminar registros nulos) e, para cada uma das questões, instanciar um novo objeto Questao contendo todos os dados necessários para a criação de uma questão na base de dados.

Para que a gravação dos dados não fosse muito custosa, ao invés de salvar questão por questão de forma separada, gravamos as instâncias das questões em um array e utilizamos do método insertMany do Mongoose. O méotodo insertMany é responsável por fazer uma inserção de registros em lote, sendo bem menos custoso pois apenas uma conexão com o banco de dados é necessária.

Todos os algoritmos utilizados para realizar os procedimentos descritos no Có- digo 4.2 podem ser visualizados nolink disponível em https://github.com/Rodrigoaz7/

script-popular-banco-Decifre.

4.1.3 Rodadas

Se as questões são a base do jogo, a rodada é o coração. Todo o jogo Decifre se baseia em rodadas, pois são nelas que os usuários poderão ganhar premiações caso tenham uma pontuação suficiente para finalizá-las na classificação estipulada.

O cadastros das rodadas podem ser divididas em duas etapas: dados gerais, e as premiações/taxa de entrada. A figura Figura 12 mostra o cadastro dos dados gerais de uma rodada, contendo o título, as datas de abertura e finalização com formatodd/mm/YYYY HH:mm, e a duração da rodada para o usuário responder as questões.

Figura 12 – Dados Gerais de uma Rodada

(37)

A Figura 13 mostra o cadastro dos dados referentes as cifras da rodada. Cada rodada tem uma premiação, uma taxa de entrada (ambas são cifras e podem ser zero) e uma lista de usuários premiados com as porcentagens específicas.

Figura 13 – Dados de Cifras de uma Rodada

Quando um usuário entra no jogo, na sua tela inicial são exibidas todas as rodadas abertas para aquele dia em forma de banner. A Figura 14 representa um banner de uma rodada aberta.

Figura 14 –Banner de uma Rodada Aberta

Na figura acima podemos ver todas as informações essenciais para adentrar na rodada em questão. Na parte superior da imagem vemos o horário de início e término da

(38)

rodada (00:00 às 23:59) e o tempo para responder questões (1 minuto). Na parte mais central da imagem vemos que dois usuários irão receber premiações, sendo o primeiro contemplado com 180 cifras e o segundo colocado com 120, além da quantidade de jogadores que já jogaram a rodada. Finalmente, na parte mais inferior do banner, temos o botão para iniciar a rodada de perguntas mostrando a taxa de entrada entre parênteses (100 cifras).

Ao adentrar em uma rodada, o usuário é redirecionado para a tela de questionário das questões. Cada usuário irá responder questões aleatórias, sendo elas sorteadas a todo momento que o usuário responder uma questão ou a pular.

Figura 15 – Rodada Aberta

A Figura 15 mostra uma questão sorteada para o usuário responder em uma rodada.

Neste questionário o usuário seleciona a pergunta que ele acredita ser a correta ou então a pula, dentro de um intervalo de trinta segundos. Para cada questão sorteada o usuário terá uma pontuação correspondente. A pontução para cada questão possui três cenários.

• Caso de Erro: Em caso do usuário responder a questão e errar, ele perde dois pontos.

• Caso de Acerto: Em caso do usuário responder a questão e acertar, ele irá receber a quantidade de pontos que a questão oferece.

• Caso de Pular: Em caso do usuário pular a questão, ele perde um ponto.

Ao final do tempo estipulado da rodada, o usuário é redirecionado para a tela de finalização da rodada, mostrada na Figura 16.

(39)

Figura 16 – Rodada Finalizada

A tela de finalização da rodada mostra a pontuação geral que o usuário conseguiu obter na rodada e quantas questões ele acertou. Existem também a possibilidade do usuário ver as respostas corretas ao clicar no botão "Respostas"e de ele ver a classificação geral dele na rodada com sua pontuação, como mostrado na Figura 17

Figura 17 – Classificação do Usuário na Rodada

Por fim, os usuários vencedores precisam receber as cifras da premiação assim que uma rodada finaliza. Para que isso aconteça, no momento em que uma rodada é criada, um job é gerado e agendado utilizando de umSchedulling Job, definido na seção 2.13.

4.1.3.1 Jobs de Finalização de Rodada

O código completo responsável por criar ojob de finalização de uma rodada e atri- buir as premiações aos vencedores pode ser visto em https://github.com/Rodrigoaz7/

descifre-back-end/blob/master/scripts/gerarGanhadoresRodada.js.

O método criarJobFinalizarRodada é chamado cada vez que uma rodada é criada, recebendo a data da finalização e o id dela. Todo o agendamento do job é realizado automaticamente pela bibliotecanode-schedule. Basicamente ele faz a consulta pela rodada finalizada, trazendo toda a lista dos usuários que a jogaram com suas respectivas pontuações.

O método gerarGanhadores é responsável por gerar a lista dos usuários vencedores, de

(40)

acordo com as regras implementadas na rodada. Com a lista completa de ganhadores e suas respectivas porcentagens da premiação, percorremos um por um gerando o valor em cifras de premiação.

4.1.4 Modo de Treino

Embora que várias rodadas possam existir no período de um dia, um usuário pode jogá-las rapidamente ou então não possuir cifras suficientes para adentrá-las. No caso de uma dessas situações ocorrerem, um grande tempo ocioso aconteceria entre os usuários da plataforma, levando a uma evasão ou descontentamento com o jogo.

Pensando nesta situação, um conceito de Modo de Treino foi criado. O modo de treino, é um esquema parecido com o de rodadas, porém ao invés do usuário ter um tempo predeterminado para responder as questões, aqui ele depende da sua quantidade de vidas. Além disso, ao final de cada semana, os dez melhores colocados receberiam cifras de premiação de acordo com suas posições finais e o raking seria reiniciado.

Quando o usuário entra pela primeira vez no portal de treinos, uma quantidade de cinco vidas são atribuídas a ele, além de uma data vinte e quatro horas a frente para recuperação dessas vidas, caso ele as perca. A Figura 18 mostra um exemplo de um treino ativo de um usuário.

Figura 18 – Painel de Treino

Ao clicar emIR PARA TREINO, o usuário é levado para a tela do treino. A tela de treino pode ser vista na Figura 19.

(41)

Figura 19 – Tela de Treino

A única diferença entre a tela acima e a de uma rodada é que, na imagem acima, o usuário tem a visão de quantas vidas ainda possui, podendo arriscar ou não em perguntas em que não saiba a resposta. A pontuação e a quantidade de vidas variam da seguinte forma:

• Caso o usuário pule uma questão, tanto a quantidade de vidas quanto a pontuação são mantidas.

• Caso o usuário erre uma questão, uma vida é perdida e menos dois pontos são computados.

• Caso o usuário acerte uma questão, uma vida é adicionada e mais dez ponto são computados.

Caso o usuário erre um número de questões que causem a perda de todas as suas vidas, ele fica impossibilitado de jogar por vinte e quatro horas, até que elas sejam recuperadas. A Figura 20 mostra um exemplo de um painel de treino com vidas zeradas.

(42)

Figura 20 – Tela de Treino Sem Vidas

Por fim, como uma forma de acompanhamento, cada jogador pode visualizar o ranking semanal dos treinos de todos os jogadores do sistema, como mostrado na Figura 21.

Figura 21 – Tela de Ranking Semanal

4.2 Modelagem

Os três objetivos principais para determinar o banco de dados neste projeto foram que, primeiramente, o banco em questão, pudesse realizar consultas de forma veloz, para que a tela de uma rodada fosse a mais rápida possível. Segundo, o banco também deve possuir também uma alta escalabilidade e, por fim, uma configuração simples e rápida.

Todos os itens citados podem ser obtidos em um banco de dados não relacional.

Dentre a vasta grande categoria de bancos não relacionais, oMongoDB foi o escolhido para o projeto, pois é o que mais se destaca no mercado, sendo o banco noSQL mais utilizado por usuários em todo o mundo.

(43)

4.2.1 Diagrama de Classes UML

A função do diagrama de classes desta seção é de dar apenas um embasamento geral sobre as principais entidades do sistema e seus relacionamentos, ou seja, não há necessidade aqui de se aprofundar nos conceitos da programação orientada a objetos das classes. A Figura 22 mostra o diagrama de classes deste projeto, de forma resumida.

Figura 22 – Diagrama de Classes UML

Todas as classes declaradas na figura acima já foram citadas em seções anteriores, com exceção da classe Quiz. A classe Quiz não foi citada anteriormente porque, diferentemente das outras classes, ela não é uma entidade física do jogo, mas sim uma entidade que representa uma rodada jogada por um usuário. Mais detalhes dos campos de cada uma das classes vão ser detalhadas na próxima subseção.

Cada relacionamento entre cada classe especificada na Figura 22 pode ser vista na listagem abaixo.

• Um usuário pode possuir nenhuma ou várias transações, pois as transações vão ser criadas caso: o usuário pague para adentrar em uma rodada paga; o usuário ganhe uma rodada; o usuário realize um saque de cifras em dinheiro; o usuário realize a compra de cifras em uma plataforma de pagamento disponível.

• Uma Questão possui uma relação de agregação com uma CategoriaQuestão, pois uma questão não necessita exatamente de uma categoria para poder existir, mas caso exista, apenas uma categoria é vinculada à ela.

• Uma rodada possui, obrigatoriamente, uma ou várias questões para poder existir.

• Um Quiz, obrigatoriamente, é vinculado a uma rodada jogada por um usuário.

(44)

• Um usuário pode estar vinculado a nenhum ou a vários quizzes, pois ele pode tanto optar por nunca jogar uma rodada, como também pode optar por jogar várias rodadas todos os dias.

• Um Treino tem, obrigatoriamente, uma ou várias questões respondidadas por um usuário.

• O usuário pode ter nenhum ou vários treinos, pois ele pode tanto optar por não jogar treinos, como também pode jogar novos todas as semanas.

4.2.2 Diagrama de Entidade Relacionamento DER

Como abordado nesta seção, o banco de dados utilizado para o desenvolvimento do projeto foi oMongo Database, que é um banco não relacional. Teoricamente, em um banco de dados desta abordagem, não existem relações entre os dados, ou seja, não há como descrever as relações entre entidades em um Diagrama de Entidade Relacionamento (DER). No entanto, com o uso de algumas ODMs, existe a possibilidade de simularmos relações entre os dados para facilitar o desenvolvimento. A Figura 23 representa o DER com as relações teóricas entre os dados.

Figura 23 – Diagrama de Entidade Relacionamento DER

Na subseção anterior já foi explicado boa parte das entidades repesentadas na figura acima e suas relações de uma forma mais geral e abstrata. No entanto, o diagrama DER

(45)

apresenta as relações de cada uma chaves estrangeiras presentes nas tabelas. Por exemplo, a relação entre as entidades Usuário e Transação na Figura 22 é definida como uma relação de um pra muitos apenas. Aqui, no Diagrama Entidade Relacionamento, o relacionamento é definido como duas relações de um pra muitos, pois existem duas chaves estrangeiras na tabela de transações, chamadas enviado por e recebido por. Estas chaves são usadas para relacionar os usuários que recebem e enviam cifras em uma transação.

Outra informação nova exibida no DER é a presença da entidade pessoa. Esta entidade é apenas uma tabela usada para armazenar dados pessoais do usuário, tendo uma relação um pra um com a tabela de usuário.

Entretanto, por se tratar de um banco de dados não relacional, algumas diferenças nesse diagrama podem identificadas nos campos das entidades. Diferentemente de uma tabela de um banco relacional, uma coleção de um banco não relacional pode possuir campos de array, possibilitando gravar relações entre coleções sem a necessidade uma tabela intermediária. Um exemplo pode ser vista na entidade rodadas, nela existem dois campos dearray: jogadores e ganhadores. Oarrayde jogadores armazena todos os usuários que jogaram a rodada, em que cada posição é um objeto JSON com o id do usuário e o id da entidade treino vinculadas a rodada. O array de ganhadores armazena a lista de usuários vencedores ao final da rodada, armazenando oid do usuário vencedor e sua porcentagem referente a premiação.

Outro exemplo é a entidade Quiz, ela é a responsável por armazenar as respostas do usuário para uma determinada rodada. No diagrama apresentado, a entidade Quizzes possui um aarray chamado jogadas. Este array é responsável por armazenar o id da questão respondida, seu status de acerto ou erro, a resposta do usuário e a pontuação creditada ou debitada. Ao final de uma rodada, cada entidade quiz irá percorrer oarray de rodadas, somando as pontuações individuais e, ao final, o campo pontuacao da tabela quiz irá armazenar apontuação geral do usuário na rodada.

4.3 A API

4.3.1 Arquitetura MVC

Oback end do trabalho é a API. Para estabeler uma estrutura de projeto de API REST sólida e escalável, utilizamos do paradigma MVC definido na seção 2.5. Por se tratar de uma API, a camada de view do MVC fica subentendida como sendo o front end da aplicação. No projeto desenvolvido em NodeJS, a camada de controller foi agrupada em routes e controllers.

(46)

4.3.1.1 Controllers

Dentro da nossa camada de controladores existem duas divisões: Rotas e Con- troladores. Como já expliado anteriormente, as rotas são as responsáveis por receber a requisição do cliente e a redirecionar para um controlador específico. O exemplo do arquivo de rotas para o contexto de rodadas pode ser visto emhttps://github.com/Rodrigoaz7/

descifre-back-end/blob/master/src/routes/rodada.js.

Inicialmente são feitas as importações de objetos e métodos que iremos utilizar na rota. O objetopermissao possui um conjunto de funções relacionadas as permissões de usuários no sistema, cujo será abordado na próxima subseção. O objeto variaveis possui dados globais de toda a aplicação, como por exemplo, a url base da aplicação. Os outros objetos importados são referentes aos controladores que serão chamados a cada URL e a cada método HTTP capturado pelas rotas.

Logo após as importações temos as definições das nossas rotas, definidas cla- ramente em rotas para administradores e rotas para usuários do sistema. Pegando o exemplo da primeira rota definida, vemos que a rota (definida como método da biblioteca Express definida na subseção 2.9.1) é responsável por interceptar requisições na URL "/administrador/rodadas"para métodos POST. O segundo parâmetro do método é um parâmetro de autenticação e permissão, definido na próxima subseção. Já o ter- ceiro e último parâmetro, é o controlador que chamamos para processar a requisição e retornar uma resposta. O controlador responsável por atender a rota dada como exemplo pode ser vista em https://github.com/Rodrigoaz7/descifre-back-end/blob/

master/src/controllers/administrador/rodadas/criarRodada.js.

A função cadastrarRodada pode ser vista como a função que é chamada pela rota para criar uma nova rodada. Inicialmente há uma validação dos dados de entrada enviados pelo cliente, e depois criado a instância do objeto Rodada (objeto da ODM Mongoose, definido na subseção 2.9.3.1). Por fim, é chamado um método genérico para salvar registros utilizando do objeto mongoose.

Com a rodada criada sem erros, o código gera ojobde finalização da rodada definido na subseção 4.1.3.1 e retorna o json de resposta para o cliente obtendo a mensagem e o status HTTP a partir de Enums declarados dentro do projeto.

4.3.1.2 Models

Na seção anterior vemos a importação de um objeto chamado Rodada no arquivo de controlador de rodadas. Este objeto é utilizado pela nossa ODM, o mongoose, para fazer o mapeamento da coleção Rodada do nosso banco de dados para um objeto no nosso código. O mapeamento pode ser visto emhttps://github.com/Rodrigoaz7/descifre-back-end/

blob/master/src/models/Rodada.js.

(47)

O conceito dos campos da rodada podem ser revistos na seção 4.2. Aqui declaramos o objeto Rodada adotando os tipos explicitamente para cada campo da nossa coleção. Por exmeplo, o tipoObjetId é um tipo vindo da biblioteca do mongoose para tipar os ids do mongo. Todos os outros tipos são primitivos, como String, Date e Number.

Com as coleções mapeadas pelo mongoose, todas as operações envolvendo banco de dados dentro do sistema são usados por manipulação desses objetos, sem qualquer lógica ou sintaxe própria do mongo.

4.3.2 Autenticação

Um ponto importante a destacar neste projeto é a autenticação e as permissões dos usuários. Toda a modelagem dos usuários a nível de banco de dados, juntamente com suas permissões são definidos na seção 4.2. Nesta subseção a abordagem da autenticação e das permissões serão abordadas a nível de código, obedencendo a arquitetura do modelo MVC.

4.3.2.1 Cadastro de Usuários

O cadastro de novos usuários no sistema segue o mesmo padrão MVC explicado na subseção 4.3.1.1, possuindo uma rota e um controlador. O Código 4.3 mostra a definição da rota para receber requisições POST pela URL "/publico/cadastro".

1 module . exports = ( a p p l i c a t i o n ) => {

2 a p p l i c a t i o n . post ( ‘ ${ v a r i a b l e s . base }/ publico / cadastro ‘ , ( req , r e s ) => { c o n t r o l l e r C a d a s t r o . r e a l i z a r C a d a s t r o ( req , r e s ) }) ; 3 } ;

Código 4.3 – Trecho de Rotas para Cadatro de Novos Usuários

O código completo do controlador chamado pela rota, por sua vez, é definido e disponibilizado em https://github.com/Rodrigoaz7/descifre-back-end/blob/master/

src/controllers/publico/autenticacao/cadastro.js.

Neste controlador podemos notar primeiramente a validação dos dados de entrada do cliente. Caso a primeira validação ocorra com sucesso, podemos prosseguir com a encriptografia da senha utilizando do algoritmo hash definido na seção 2.11. Logo após a senha encriptografada ter sido gerada, criamos o dado da coleção de Pessoa seguido da criação da coleção de Usuário com os dados passados pela requisição. Com todos os passos anteriores completados com sucesso, criamos um token utilizando da biblioteca jsonwebtoken passando os dados do usuário como um objeto json e o tempo de expiração como sendo trezentos e sessenta horas. A geração do token pela biblioteca pode ser vista no Código 4.4.