sistema de apoio à decisão para futebol · pdf filejson – javascript...
TRANSCRIPT
SISTEMA DE APOIO À DECISÃO PARA FUTEBOL
BASEADO EM LÓGICA FUZZY
André Silveira de Araujo
Projeto de Graduação apresentado ao Curso de
Engenharia de Computação e Informação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientador: Flávio Luis de Mello
Rio de Janeiro
Setembro de 2017
ii
SISTEMA DE APOIO À DECISÃO PARA FUTEBOL
BASEADO EM LÓGICA FUZZY
André Silveira de Araujo
PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO DE
ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA ESCOLA POLITÉCNICA
DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS
REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO
DE COMPUTAÇÃO E INFORMAÇÃO
Rio de Janeiro – RJ, Brasil
Setembro de 2017
iii
Araujo, André Silveira de
Sistema de Apoio à Decisão para Futebol Baseado em
Lógica Fuzzy / André Silveira de Araujo. – Rio de Janeiro:
UFRJ/ Escola Politécnica, 2017.
XII, 47 p.: il.; 29,7 cm.
Orientador: Flávio Luis de Mello
Projeto de Graduação – UFRJ/ Escola Politécnica/ Curso
de Engenharia de Computação e Informação, 2017.
Referências Bibliográficas: p. 45-47.
1. Sistema de Apoio à Decisão para Esportes 2. Interface
Gráfica 3. Lógica Fuzzy I. Mello, Flávio Luis de. II.
Universidade Federal do Rio de Janeiro, Escola Politécnica,
Curso de Engenharia de Computação e Informação. III. Título.
iv
AGRADECIMENTO
Agradeço primeiramente ao meu amigo Luiz Henrique, que colaborou comigo não
apenas nesse projeto, mas também em várias outras disciplinas no decorrer da UFRJ.
Assim como à amiga Lygia Marina, que sempre esteve presente para ajudar em momentos
de dúvida.
E em segundo lugar, aos professores e a todos os responsáveis por manter essa
universidade funcionando e proporcionando uma formação sólida para seus alunos.
v
Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como parte dos
requisitos necessários para a obtenção do grau de Engenheiro de Computação e
Informação.
SISTEMA DE APOIO À DECISÃO PARA FUTEBOL BASEADO EM LÓGICA
FUZZY
André Silveira de Araujo
Setembro/2017
Orientador: Flávio Luis de Mello
Curso: Engenharia de Computação e Informação
Este trabalho aborda o desenvolvimento de um Sistema de Apoio à Decisão
baseado na aplicação de lógica fuzzy sobre dados estatísticos de futebol coletados da
internet. Para isso, dados técnicos de partidas de futebol são extraídos de sites e
armazenados de forma centralizada em um servidor localizado na nuvem. Diferentes
modelagens fuzzy são submetidas a testes a fim de dar aos dados uma leitura mais
simples, na qual todo o seu conteúdo é reduzido a apenas oito variáveis, as dimensões
técnicas. Uma interface gráfica é por fim produzida servindo como meio de operação
entre o usuário que deve tomar uma decisão e a nova abstração dos dados.
Palavras-chave: Sistema de Apoio à Tomada de Decisão, Lógica Fuzzy, Banco de Dados
Relacional, Futebol, Estatística.
vi
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of the
requirements for the degree of Computer and Information Engineer.
FUZZY LOGIC BASED SOCCER DECISION SUPPORT SYSTEM
André Silveira de Araujo
September/2017
Advisor: Flávio Luis de Mello
Course: Computer and Information Engineering
This work deals with the development of a Decision Support System based on the
application of fuzzy logic on soccer statistics collected from the internet. Technical data
of soccer matches are crawled from websites and stored centrally on a server located in
the cloud. Different fuzzy models are subjected to tests in order to give the data an easier
meaning, in which all its content is reduced to only eight variables, the technical
dimensions. A graphical user interface is then produced serving as a mean of operation
between the user who must make a decision and the new abstraction of the data.
Key-words: Decision Support System, Fuzzy Logic, Relational Database, Football,
Statistics.
vii
SIGLAS
EC2 – Amazon Elastic Compute Cloud
IDE – Ambiente de Desenvolvimento Integrado
JSON – JavaScript Object Notation
RAM – Random Access Memory
SAD – Sistema de Apoio à Decisão
SFTP – SSH File Transfer Protocol
SGBD – Sistema de Gerenciamento de Banco de Dados
SI – Sistemas de Informação
SQL – Structured Query Language
SSH – Secure Shell
SaaS – Software as a Service
UML – Linguagem de Modelagem Unificada
VO – Value Object
WEB – World Wide Web
viii
Sumário
Capítulo 1 Introdução .................................................................................................... 1
1.1 Tema ....................................................................................................................... 1
1.2 Delimitação ............................................................................................................. 1
1.3 Justificativa ............................................................................................................. 2
1.4 Objetivos ................................................................................................................. 2
1.5 Metodologia ............................................................................................................ 3
Capítulo 2 Fundamentação teórica ............................................................................... 3
2.1 Sistema de Apoio à Decisão ................................................................................... 3
2.2 Lógica Fuzzy .......................................................................................................... 4
2.2.1 Conjuntos fuzzy ............................................................................................... 4
2.2.2 Regras fuzzy .................................................................................................... 6
2.2.3 O Sistema fuzzy ............................................................................................... 7
2.3 Computação em Nuvem ......................................................................................... 7
2.3.1 Software como serviço .................................................................................... 8
2.3.2 Serviço de Computação em Nuvem ................................................................ 9
2.4 Sistemas de Informação aplicados ao Esporte ...................................................... 11
Capítulo 3 Implementação ........................................................................................... 13
3.1 Apresentação do Problema ................................................................................... 13
3.2 Arquitetura do Sistema ......................................................................................... 14
3.3 Modelagem Matemática do Fuzzy ....................................................................... 16
3.2.1 Dimensões técnicas ....................................................................................... 16
3.2.2 Variáveis linguísticas ..................................................................................... 19
3.2.3 Conjuntos Fuzzy ............................................................................................ 21
3.3 Implementação em Nuvem ............................................................................... 22
3.4 Implementação da Interface.................................................................................. 25
3.4.1 Operação ........................................................................................................ 25
ix
3.5 Engenharia de Software ........................................................................................ 29
3.5.1 Banco de Dados ............................................................................................. 29
3.5.2 Estrutura do código ........................................................................................ 31
3.5.3 Bibliotecas ..................................................................................................... 37
3.6 Modelo de Negócio .............................................................................................. 38
3.7 Análise dos Resultados ......................................................................................... 41
Capítulo 4 Considerações Finais ................................................................................. 44
4.1 Conclusões ............................................................................................................ 44
4.2 Trabalhos Futuros ................................................................................................. 44
Referências bibliográficas ............................................................................................ 45
x
Lista de Figuras
Figura 2.1 – Formatos de função de pertinência [1]. ........................................................ 5
Figura 2.2 – Exemplo de uma variável linguística Temperatura [4]. ............................... 6
Figura 2.3 – Funcionamento de um SaaS [8]. .................................................................. 9
Figura 2.4 – Ilustração do consumo de recursos por diferentes demandas com capacidade
de processamento fixada [8]. .......................................................................................... 10
Figura 2.5 – Tentativas de conversão de quatro jogadores diferentes em um período de
seis anos [10]. ................................................................................................................. 11
Figura 2.6 – Gráfico mostrando como a previsão da máquina fica pior na medida em que
é alimentada com dados de uma janela maior tempo [11]. ............................................ 12
Figura 3.1 – Arquitetura do SAD. .................................................................................. 14
Figura 3.2 – Comando que sincroniza os dados da interface com os coletados pelo robô.
........................................................................................................................................ 15
Figura 3.3 – Comando que sincroniza os dados da interface com os coletados pelo robô.
........................................................................................................................................ 15
Figura 3.4 – Tela de ajuste do motor fuzzy. ................................................................... 15
Figura 3.5 – Menu de comando para iniciar a fuzzificação dos dados coletados. .......... 16
Figura 3.6 – Modelo antigo da árvore fuzzy para à dimensão técnica finalização [1]. .. 17
Figura 3.7 – Árvore fuzzy para a dimensão técnica finalização. .................................... 18
Figura 3.8 – Árvore fuzzy para a dimensão técnica passe curto. ................................... 18
Figura 3.9 – Árvore fuzzy para a dimensão técnica passe longo. .................................. 18
Figura 3.10 – Árvore fuzzy para a dimensão técnica controle de bola. ......................... 18
Figura 3.11 – Árvore fuzzy para a dimensão técnica marcação. .................................... 19
Figura 3.12 – Árvore fuzzy para a dimensão técnica disciplina. .................................... 19
Figura 3.13 – Árvore fuzzy para a dimensão técnica passe jogo aéreo. ......................... 19
Figura 3.14 – Árvore fuzzy para a dimensão técnica bola parada. ................................. 19
Figura 3.15 – Arcabouço para variáveis linguísticas de entrada. ................................... 21
Figura 3.16 – Arcabouço para variáveis linguísticas de saída. ....................................... 22
Figura 3.17 – Painel de instâncias virtuais com apenas uma máquina em funcionamento.
........................................................................................................................................ 23
Figura 3.18 – Tela do WinSCP mostrando os arquivos do robô extrator no servidor.... 24
Figura 3.19 – Arquivos JSON extraídos pelo robô. ....................................................... 24
xi
Figura 3.20 – Área de operação da interface. Em (1) estão listados todos os jogadores
extraídos, (2) as telas para as diferentes exibições e (3) é o espaço onde as telas são
manuseadas. .................................................................................................................... 25
Figura 3.21 – Interface com as listagens de jogadores e de telas expandidas. ............... 26
Figura 3.22 – Tela Ficha Técnica. .................................................................................. 26
Figura 3.23 – Tela Comparador. ..................................................................................... 27
Figura 3.24 – Tela Comparador Gráfico. ....................................................................... 27
Figura 3.25 – Tela Overall. ............................................................................................. 28
Figura 3.26 – Tela Overall com a posição atípica, DL, assinalada. ............................... 29
Figura 3.27 – Modelagem da base de dados com a nova tabela Playerfuzzy na cor vinho.
........................................................................................................................................ 30
Figura 3.28 – Diagrama de componentes. ...................................................................... 32
Figura 3.29 – Diagrama UML do pacote Sad. ................................................................ 33
Figura 3.30 – Diagrama UML do pacote IO. ................................................................. 34
Figura 3.31 – Diagrama UML do pacote Fuzzy. ............................................................ 34
Figura 3.32 – Diagrama UML do pacote VO. ................................................................ 35
Figura 3.33 – Diagrama UML do pacote Screen. ........................................................... 36
Figura 3.34 – Canvas do modelo de negócio. ................................................................ 39
Figura 3.35 – Planilha de custos e receitas. .................................................................... 40
xii
Lista de Tabelas
Tabela 2.1 – As três técnicas mais comuns de computação em nuvem e seus apoiadores
[6]. .................................................................................................................................... 8
Tabela 3.1 – Relação entre dimensões técnicas e estatísticas de desempenho. .............. 20
Tabela 3.2 – Tabela Playerfuzzy. ................................................................................... 31
Tabela 3.3 – Melhores em bola parada e avaliação em WhoScored?. ........................... 41
Tabela 3.4 – Melhores em controle de bola e avaliação em WhoScored?. .................... 41
Tabela 3.5 – Melhores em finalização e avaliação em WhoScored?. ............................ 42
Tabela 3.6 – Melhores em passe curto e avaliação em WhoScored?. ............................ 42
Tabela 3.7 – Melhores em passe longo e avaliação em WhoScored?. ........................... 42
Tabela 3.8 – Melhores em marcação e avaliação em WhoScored?. ............................... 42
Tabela 3.9 – Melhores em disciplina e avaliação em WhoScored?. .............................. 42
Tabela 3.10 – Melhores em jogo aéreo e avaliação em WhoScored?. ........................... 43
1
Introdução
1.1 Tema
O tema deste trabalho é o desenvolvimento de um Sistema de Apoio à Decisão
(SAD) que permita avaliar o desempenho de jogadores de futebol. Desta forma, os
problemas a serem resolvidos são a disponibilização de uma base de dados estatísticos
sobre jogadores em um serviço de computação em nuvem e o desenvolvimento de
software gráfico para comparação e apoio à análise de jogadores de futebol através do
uso de lógica fuzzy.
1.2 Delimitação
Primeiramente a disponibilização dos dados e estatísticas dos jogadores obtidos
durante o trabalho de Pinho [1] em uma base de dados na nuvem, com o objetivo de
facilitar seu acesso para o projeto atual e futuros que venham a ocorrer.
A segunda e principal parte do projeto, o tratamento através da lógica fuzzy e
exposição das informações de caráter técnico dos atletas em uma interface gráfica, serão
feitos tendo em mente o que poderiam auxiliar, do ponto de vista de um clube de futebol,
nas etapas de contratação de novos jogadores, avaliação do próprio repertório para
escalação e análise de um time rival.
O trabalho também se limita a tratar toda a base como pertencendo a um mesmo
universo. No sentido de que não há distinção ou aplicação de peso entre o desempenho
obtido em um campeonato europeu ou campeonato brasileiro.
A estratégia adotada na interpretação dos dados poderia ser aplicada sobre outros
esportes coletivos desde que suas características sejam adequadamente remapeadas, isto
é, ao aplicar nosso algoritmo em uma base de jogadores de basquete, as sextas
substituiriam os gols, por exemplo.
2
1.3 Justificativa
Nos tempos recentes temos presenciado o surgimento progressivamente mais fácil
de enormes concentrações de dados. No escopo do futebol, isso pode ser ilustrado com o
fato de ao término de uma única partida, cada jogador muito provavelmente teve sua
distância, trajeto e quiçá toques na bola contabilizados e armazenados em alguma
planilha.
Todo esse conjunto de informações é valioso, pois representa de forma
extremamente enxuta incontáveis horas de partidas reais. E dele pode-se extrair
correlações que um olheiro ou técnico presente não tenham sido capazes de abstrair no
momento em que ocorreram.
Ao investir sobre esse problema, uma modelagem matemática fazendo uso de
lógica booleana poderia ser a aproximação mais intuitiva. Entretanto, essa abordagem
restringida ao verdadeiro ou falso seria limitada demais no escopo do projeto. A lógica
fuzzy, sendo capaz de estender essas respostas ao retornar valores parciais, poderia
fornecer a capacidade de que estados inicialmente não visíveis possam ser tratados na
modelagem matemática escolhida.
1.4 Objetivos
O objetivo principal é desenvolver um software intuitivo para desktops, o qual
através da implementação e ajustes sobre a modelagem fuzzy feita no trabalho de Pinho
[1]. Neste sentido os objetivos específicos são:
Popular uma base de dados relacional com dados de jogadores e clubes;
Posicionar a base em um ambiente de nuvem;
Implementar a modelagem conceitual fuzzy produzida por Pinho;
Implementar uma interface gráfica funcional em linguagem JAVA.
Terminado os objetivos anteriores, reformular a modelagem fuzzy inicial
para conseguir melhores resultados.
3
1.5 Metodologia
Inicialmente, dando continuidade ao trabalho de Pinho, é feita a captura de dados
estatísticos e fotos dos jogadores do site WhoScored.com, através do programa extrator
desenvolvido por ele, assim como a modelagem conceitual dos conjuntos fuzzy.
Terminado esse trabalho, primeiramente uma base de dados contendo as
informações coletadas para consulta do software é devidamente instalada em um servidor.
Em seguida, o software é desenvolvido até que atinja uma maturidade mínima
onde a visualização dos dados e a interação com a interface já possam ocorrer de forma a
auxiliar a fase seguinte, a de realização de ajustes na implementação fuzzy.
Por fim, a modelagem fuzzy implementada no software tem seus atributos, como
tipos de conjuntos difusos, operadores, implicações, regras e combinações de saídas,
alternados em um processo de tentativa e erro até que se encontre uma configuração que
retorne resultados compatíveis com a realidade. Jogadores que forem classificados com
notas mais altas (baixas) deverão ter seu desempenho elogiado (criticado) nas mídias
esportivas.
Fundamentação teórica
2.1 Sistema de Apoio à Decisão
Durante as décadas de 70 e 80, a crescente evolução dos computadores tornou-os
cada vez mais capazes de armazenar e processar dados. Aliada à natureza competitiva das
grandes organizações no mercado, instalou-se um ambiente propício ao desenvolvimento
de Sistemas de Informação (SI) que pudessem auxiliar o ser humano na tomada de
decisões. O Sistema de Apoio à Decisão (SAD) é, portanto, um sistema que auxilia e/ou
fornece informações para apoiar a tomada de uma decisão [2].
4
Conforme explicado por Bohanec [2], a fim de cumprir com sua função, um SAD
deverá implementar um algoritmo tomador de decisão que normalmente envolve etapas,
como:
Identificação do problema;
Coleta e verificação de informações relevantes;
Identificação das decisões possíveis;
Cálculo das consequências sobre as decisões;
Realização da decisão;
Avaliação das consequências da decisão.
Sendo a etapa “Realização da decisão” a mais importante de todas.
2.2 Lógica Fuzzy
“A Lógica Fuzzy (Nebulosa) é a lógica que suporta os modos de raciocínio que
são aproximados ao invés de exatos. Modelagem e controle fuzzy de sistemas são técnicas
para o tratamento de informações qualitativas de uma forma rigorosa” [3].
Por essas características, ela é comumente empregada em modelagens
matemáticas que apresentam entradas imprecisas ou subjetivas [1]. Uma forma mais
simples de apresentá-la seria imaginar o caso de um forno de cozinha a temperatura de
179º C, no qual se deseja saber se já está preaquecido em no mínimo em 180º C. A lógica
mais tradicional responderia simplesmente que não, pois ele está abaixo da temperatura
exigida. A lógica fuzzy, em contrapartida, acusaria que o forno está suficientemente
próximo de pré-aquecido, o que seria a leitura mais útil no escopo do exemplo.
A saída gerada por uma modelagem fuzzy pode ser ajustada através da
manipulação de três componentes em sua implementação: conjuntos fuzzy, regras fuzzy e
sistema fuzzy.
2.2.1 Conjuntos fuzzy
5
Conforme explicado por Pinho [1], o conjunto fuzzy é usado para classificar a
pertinência de um elemento (entrada) a um dado conjunto. Voltando novamente ao
exemplo do forno de cozinha, ele é capaz de acusar que o elemento temperatura em 179ºC
pertence tanto ao conjunto das temperaturas quentes (aquelas superiores as 180ºC)
quanto, embora em menor grau, ao conjunto de temperaturas frias.
Formalizando:
𝐴 = {(𝑥, 𝜇𝐴(𝑥)), 𝑥 ∈ 𝑋}
Sendo:
𝑥: elemento (valor de entrada);
𝜇𝐴(𝑥): função de pertinência, associada ao conjunto fuzzy A;
X: universo do discurso (domínio).
A função de pertinência exprime o grau de pertinência e pode assumir qualquer
valor pertencente ao intervalo [0, 1].
𝜇𝐴(𝑥) = {1, 𝑠𝑒𝑥 ∈ 𝐴0, 𝑠𝑒𝑥 ∉ 𝐴
0 < 𝜇𝐴(𝑥) < 1, 𝑠𝑒 𝑥 𝑝𝑒𝑟𝑡𝑒𝑛𝑐𝑒 𝑝𝑎𝑟𝑐𝑖𝑎𝑙𝑚𝑒𝑛𝑡𝑒 𝑎 𝐴
A função de pertinência é escolhida de forma a melhorar a saída gerada pela
modelagem. As usadas com mais frequência possuem o formato triangular, trapezoidal
ou gaussiano.
Figura 2.1 – Formatos de função de pertinência [1].
Ainda relacionado aos conjuntos fuzzy, tem-se a variável linguística. “Uma
variável linguística é uma variável cujos valores são nomes de conjuntos fuzzy. Por
exemplo, a temperatura de um dado processo poderia ser uma variável linguística
assumindo valores baixa média, alta, etc. Estes valores são descritos por intermédio de
conjuntos fuzzy. A principal função das variáveis linguísticas é fornecer uma maneira
sistemática para uma caracterização aproximada de fenômenos complexos ou mal
definidos” [4].
6
Figura 2.2 – Exemplo de uma variável linguística Temperatura [4].
Sobre as variáveis linguísticas empregam-se os conectivos lógicos: NÃO, E e OU
[1].
NÃO: 𝑁𝑂𝑇𝐴 = �́� = {(𝑥, 1 − 𝜇𝐴(𝑥)), 𝑥 ∈ 𝑋}
E: 𝐴 ∧ 𝐵 = 𝐴 ∩ 𝐵 = {(𝑥, 𝑚𝑖𝑛(𝜇𝐴(𝑥), 𝜇𝐵(𝑥))) , 𝑥 ∈ 𝑋}
OU: 𝐴 ∨ 𝐵 = 𝐴 ∪ 𝐵 = {(𝑥, 𝑚𝑎𝑥(𝜇𝐴(𝑥), 𝜇𝐵(𝑥))) , 𝑥 ∈ 𝑋}
2.2.2 Regras fuzzy
A lógica fuzzy possui um sistema de regras no formato:
SE (x é A) ENTÃO (y é B)
A variável linguística A, por estar na operação SE é chamada de variável de
entrada. Da mesma forma, pertencendo ao ENTÃO, a variável linguística B é dita variável
de saída. As letras x e y são elementos (valores de entrada/saída).
Os conectivos lógicos também são usados na composição de uma regra:
SE (x é A) E SE (y é B) ENTÃO (y NÃO é B)
7
2.2.3 O Sistema fuzzy
Com o que foi apresentado já é possível ter a base de um sistema fuzzy em
funcionamento, que tem sua operação dividida em cinco etapas sequenciais:
1. Fuzzificação das variáveis de entrada, isto é, dado um valor de entrada, aplica-
se as funções de pertinência e encontramos um valor entre 0 e 1 para cada
conjunto;
2. Aplicação dos operadores E e OU;
3. Aplicação da implicação;
4. Transformação das saídas em um conjunto fuzzy;
5. Desfuzzificação da variável linguística de saída obtida na etapa 4, obtendo
um valor numérico.
A segunda e terceira etapas também são conhecidas como inferência.
Um sistema fuzzy pode ter seus atributos ajustados em um nível mais profundo
que o apresentado. O detalhamento limitou-se ao necessário para compreender a
implementação do trabalho.
2.3 Computação em Nuvem
“Computação em nuvem refere-se tanto às aplicações entregues como serviços
através da Internet quanto ao hardware e sistemas nos data centers que oferecem esses
serviços. Os próprios serviços têm sido chamados de Software Como um Serviço (SaaS),
então usamos esse termo. O hardware e o software do datacenter é o que chamaremos de
Cloud” [5].
De acordo com Jaatun et al. [6], a computação em nuvem pode ser visto como
uma técnica de computação onde serviços de tecnologia de informação são providos por
uma larga malha de unidades computacionais de baixo custo através de um protocolo de
internet. Ela apresenta cinco características marcantes:
Recursos de computação de grande escala;
Alta capacidade de escalabilidade e elasticidade;
Recursos compartilhados (tanto recursos virtualizados, quanto físicos);
Alocação de recurso dinâmico;
8
Propósito de adoção geral.
Armbrust el al. [5], destaca que a elasticidade dos recursos, sem pagar um enorme
valor por novos data centers, é uma possibilidade inédita na história da tecnologia da
informação.
Os maiores prestadores de computação em nuvem atualmente são três e adotam
técnicas diferentes de abstração. São eles: Amazon (com um modelo baseado em
virtualização de servidor), Google (técnicas de sandbox, AppEngine) e Microsoft
(Windows Azure Hypervisor). Atualmente a Amazon, com seu produto EC2, é a mais
popular [6].
Tabela 2.1 – As três técnicas mais comuns de computação em nuvem e seus apoiadores
[6].
Técnica de Abstração Adotantes
Virtualização de servidor
Amazon EC2 (Xen), GoGrid (Xen),
21vianet CloudEx (Xen), RackSpace
Mosso (Xen), Joyent (Accelerator),
AT&T Synaptic (Vmware), Verizon CaaS
(Vmware)
Técnicas específicas de sandbox GAE (Python & JVM), Heroku (Ruby),
Morph Application Platform(Ruby)
Virtualização de servidor e técnicas de
sandbox Microsoft Azure (WAH & .NET)
Armbrust et al. [5] ressalta que a abordagem empregada na Amazon EC2 cria
instancias de servidores virtuais que, para o usuário final, se assemelha a possuir um
hardware físico real. Sendo possível manipular até o núcleo do sistema ou kernel
instalado. Todavia esse baixo nível de acesso prejudica a capacidade da EC2 de fornecer
escalabilidade automática e proteção contra falhas.
2.3.1 Software como serviço
O conceito software como serviço, mais conhecido do inglês Software as a Service
(SaaS), é um modelo de distribuição de software no qual não há mais a ideia da aquisição
de um programa por completo, mas sim de seu acesso, normalmente via assinatura.
9
Conforme explica Guo [7], essa configuração apresenta outras mudanças se
comparadas ao modelo tradicional: ao invés de instalados nas máquinas dos usuários, as
aplicações costumam operar de um servidor central e serem acessadas via internet, tal
formato dispensa os clientes de gastos com manutenção de máquinas e controle sobre
atualizações.
Figura 2.3 – Funcionamento de um SaaS [8].
A cobrança é feita proporcionalmente ao uso, em formato de assinatura, não
havendo mais a venda de uma licença completa e sem prazo de expiração para o software.
Isso reduz o investimento financeiro inicial do usuário para se adotar uma nova
ferramenta. O formato de assinatura também garante aos desenvolvedores um fluxo
contínuo de recursos para continuar a trabalhar em novas funcionalidades.
2.3.2 Serviço de Computação em Nuvem
O termo computação em nuvem compreende tanto os serviços disponibilizados
via internet, os SaaS, quanto as máquinas e seus sistemas que provém esses serviços, a
nuvem em si.
De acordo com Armbrust et al. [8], essa arquitetura torna o uso da nuvem
excepcionalmente atrativo em três cenários:
Em um serviço que apresenta demanda variável: sua adoção permitiria a
alocação de recursos de forma proporcional à necessidade. Dessa forma, não há
desperdícios financeiros quando a demanda é abaixo da esperada e, ao mesmo
10
tempo, não há e perda da oportunidade momentânea quando a mesma cresce de
forma inesperada.
Em um serviço que apresenta demanda desconhecida: durante o lançamento
de um novo produto não é possível saber como será sua aceitação no mercado. O
sistema de computação em nuvem permite então que novas ideias sejam
exploradas sem a necessidade e risco de um grande investimento financeiro
inicial. Toda a infraestrutura poderá ser instantaneamente ampliada para suportar
um feliz crescimento acelerado de demanda.
Quando é desejado terminar um processamento mais rápido: a elasticidade
de um hardware presente na nuvem torna financeiramente viável que se aumente
o poderio de processamento temporariamente a fim de reduzir o tempo de trabalho
necessário. Isso é possível, pois o custo de se contratar mais n instâncias virtuais
para acelerar um cálculo seria próximo ao de computar o mesmo cálculo em uma
instância individual, mas por n horas a mais.
A Figura 2.4 ilustra graficamente alguns desses cenários. Em (a) a capacidade de
processamento alocada foi suficiente para cobrir a demanda, porém houve desperdícios
(em verde). A figura (b) retrata uma capacidade que não foi suficiente para suprir a
demanda. A (c) indica a queda gradativa da demanda causada pela insatisfação dos
usuários com a má experiência decorrente da capacidade e insuficiente.
Figura 2.4 – Ilustração do consumo de recursos por diferentes demandas com
capacidade de processamento fixada [8].
A decisão final de quando investir em um datacenter próprio e quando contratar
uma solução em nuvem pode ser encontrada com a ajuda da equação proposta por
Armbrust el al. [5]. Nela, o lado que for maior representa a maior oportunidade de receita:
𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑢𝑠𝑜𝑛𝑢𝑣𝑒𝑚 × (𝑅𝑒𝑐𝑒𝑖𝑡𝑎 − 𝐶𝑢𝑠𝑡𝑜𝑛𝑢𝑣𝑒𝑚)
≥
11
𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑢𝑠𝑜𝑑𝑎𝑡𝑎𝑐𝑒𝑛𝑡𝑒𝑟 × (𝑅𝑒𝑐𝑒𝑖𝑡𝑎 −𝐶𝑢𝑠𝑡𝑜𝑑𝑎𝑡𝑎𝑐𝑒𝑛𝑡𝑒𝑟
𝑢𝑡𝑖𝑙𝑖𝑧𝑎çã𝑜)
2.4 Sistemas de Informação aplicados ao Esporte
O uso de sistemas de informação no mundo dos esportes surgiu e cresceu de forma
proporcional ao desenvolvimento e barateamento de microcomputadores. Desde a década
de 70 há relatos do uso de computadores principalmente para coleta e processamento de
dados [9].
Goldsberry [10] apresenta o que chama de CourtVision. Uma forma de analisar
estatísticas em jogos de basquete que dá importância ao posicionamento espacial do
jogador em quadra. A Figura 2.5 mostra como funciona sua leitura. Nela estão
representados os arremessos que foram tentados em cada posição do campo. Quanto
maior o quadrado, mais tentativas foram feitas naquele ponto e quanto mais sua cor se
aproxima do vermelho, maior foi a taxa de conversão.
Figura 2.5 – Tentativas de conversão de quatro jogadores diferentes em um período de
seis anos [10].
12
No trabalho [11], é proposto o uso do aprendizado de máquina para prever os
resultados de partidas futuras de jogos de futebol. Em seus resultados foi detectado que a
porcentagem de acerto nas previsões pela máquina, era melhor usando apenas uma faixa
de dados reduzida e com dados mais recentes, do que usando uma gama maior de
informação. Ou seja, de acordo com o projeto [11], o resultado de uma partida está mais
atrelado ao desempenho atual do time em estudo do que ao seu histórico de conquistas.
Figura 2.6 – Gráfico mostrando como a previsão da máquina fica pior na medida em
que é alimentada com dados de uma janela maior tempo [11].
O artigo [12] afirma que diferentes estudos vêm sendo desenvolvidos inclusive
com a lógica fuzzy. O trabalho [13] mostrou como usar lógica fuzzy para determinar a
melhor posição de jogo para um jogador de futebol. Seu processo da avaliação consistiu
em analisar 264 jogadores cujas estatísticas eram conhecidas, mas sua posição de jogo
não, e tentar, através de sua modelagem, acertar a posição de cada um. Se a posição
correta estivesse entre as três primeiras sugestões de seu produto, o resultado era
considerado preciso. Nesse formato, sua modelagem acertou a posição correta em 91%
dos casos (240 jogadores).
13
Implementação
3.1 Apresentação do Problema
Atualmente o mundo apresenta uma quantidade crescente de dados digitais. A
Opta, uma das maiores empresas de captura estatística em futebol, afirma que é capaz de
registrar até 2000 eventos ao vivo durante uma partida [14]. Não há dúvidas de que existe
valor no aumento dessas informações, pois ele significa simplesmente que um
administrador pode saber mais sobre seu negócio do que sabia no passado. No entanto,
para isso é preciso saber como interpreta-lo e readaptar sua conduta para tal [15].
O SAD proposto neste projeto busca resolver precisamente o problema de ter
informação em excesso. Para isso, faz uso de lógica fuzzy a fim de comprimir a extensão
dos dados disponíveis para apenas oito variáveis, chamadas dimensões técnicas.
Tornando com isso, sua interpretação mais simplificada para o operador do sistema.
Os itens a seguir enumeram alguns requisitos que devem ser atendidos para que o
projeto possa solucionar o problema:
O robô extrator produzido por Pinho [1] deve ser capaz de funcionar na nuvem
sem qualquer divergência de quando operou no seu projeto original;
A aplicação para desktop deve ser capaz de se conectar com a nuvem e requisitar
os dados previamente coletados, tanto via consulta ao banco de dados quanto
transferindo os arquivos de imagens. Tal funcionalidade deve ser provida através
de um comando no menu.
A modelagem fuzzy tem que ser capaz de separar os atletas em três conjuntos fuzzy
(ruim, mediano e bom).
Durante as comparações com uma ferramenta similar, o WhoScored.com, os
sistemas não podem gerar avaliações opostas, isto é, o SAD não pode fazer uma
classificação positiva, ao mesmo tempo em que o WhoScored.com avalia
negativamente.
14
3.2 Arquitetura do Sistema
A Figura 3.1 ilustra um esquema gráfico do projeto em sua totalidade.
Figura 3.1 – Arquitetura do SAD.
O projeto pode ser dividido em dois subgrupos: um robô (crawler) extrator de
dados de campeonatos da Internet e uma aplicação gráfica para desktop.
A implementação do robô foi realizada e detalhada por Pinho [1]. No que
corresponde ao trabalho atual, o robô foi transportado e posto para funcionar em um
servidor remoto na nuvem, mais precisamente, uma instância de máquina virtual nos
servidores da Amazon EC2. Pelo fato do robô ser escrito em uma linguagem
multiplataforma (Python) ele pôde ser aproveitado sem necessidade de adaptações.
Resumidamente, o crawler se conecta aos sites que usa como fontes, como o
WhoScored.com, e realiza as extrações. Os dados técnicos são inicialmente recebidos em
formato JSON. Em seguida, ele verifica se o SGBD (PostgreSQL) já possui as tabelas
esperadas. Em caso negativo, ele as cria. Os dados JSON extraídos são inseridos nas
tabelas correspondentes e então apagados. Por fim, o robô, agora em posse dos
identificadores dos jogadores (playerId) e clubes (teamId), realiza chamadas por suas
imagens correspondentes, salvando-as em pastas comuns. Em seu estado atual, são
capturadas as imagens dos escudos dos clubes e fotos de rosto dos jogadores.
15
A interface gráfica funciona de forma local, na máquina pessoal do usuário final.
Tanto na primeira vez em que é iniciada, quanto quando se desejar atualizar seus dados,
é necessário realizar o comando “Atualizar a base de dados” (Figura 3.2), presente barra
de menus. Essa ordem fará com que o software se conecte ao servidor na nuvem e faça
uma cópia dos dados para uma base de dados local.
Figura 3.2 – Comando que sincroniza os dados da interface com os coletados pelo robô.
A modelagem fuzzy pode ser ajustada manualmente através da entrada
“Configurar Fuzzy”, Figura 3.3, que apresentará uma tela com as opções disponíveis para
o refinamento, Figura 3.4.
Figura 3.3 – Comando que sincroniza os dados da interface com os coletados pelo robô.
Figura 3.4 – Tela de ajuste do motor fuzzy.
Essa etapa é opcional e, se pulada, usará as configurações que foram adotadas para
a apresentação desse projeto como padrão.
16
Em sequência, o comando “Calcular Fuzzy” deve ser acionado. Os dados crus
serão trabalhados sobre o modelo fuzzy e seu resultado é salvo na mesma base local.
Figura 3.5 – Menu de comando para iniciar a fuzzificação dos dados coletados.
Terminado essas etapas, é concluído todo o fluxo apresentado na Figura 3.1, o
SAD estará funcional e poderá ser usado pelo usuário final.
3.3 Modelagem Matemática do Fuzzy
Este trabalho busca dar continuidade ao iniciado por Pinho [1], por isso, a
modelagem implantada no sistema segue próxima à versão idealizada original. Apenas as
diferenças serão destacadas e justificadas nesta seção.
3.2.1 Dimensões técnicas
Assim como no trabalho [1], a lógica fuzzy é aplicada sobre todos os dados
estatísticos presentes na base de dados obtendo como saída um leque menor de valores e
com significado mais claro. Esse leque é composto pelas chamadas dimensões técnicas
do atleta. São elas:
1. Finalização;
2. Passe Curto;
3. Passe Longo;
4. Controle de Bola;
5. Marcação;
6. Disciplina;
7. Jogo Aéreo;
8. Bola Parada.
17
Para cada uma das dimensões listadas existe uma modelagem fuzzy própria que
considera apenas os valores estatísticos pertinentes. É também nessas modelagens que se
têm as primeiras diferenças em relação ao proposto por Pinho [1].
A Figura 3.6 ilustra uma árvore do modelo fuzzy, ou seja, vários sistemas fuzzy
encadeados, para a dimensão “finalização”, conforme o trabalho [1]. Pode-se observar
que o bloco de regras RB3 é aplicado sobre as saídas dos blocos RB1 e RB2. Em um
momento inicial essa configuração parece plausível, mas na prática não rendeu o
resultado esperado. Após analisar as saídas intermediárias (antes de passar por RB3) com
as saídas finais, observou-se que a aplicação do fuzzy sobre fuzzy tende a bagunçar os
resultados. Jogadores cujo desempenho decididamente era bom (ruim) por possuírem
estatísticas claramente altas (baixas), acabavam por vez ou outra, aparecer no extremo
oposto ao final da fuzzificação. Mesmo manipulações nos seus conjuntos fuzzy não
surtiram um efeito final satisfatório.
Figura 3.6 – Modelo antigo da árvore fuzzy para à dimensão técnica finalização [1].
A saída encontrada foi encurtar a árvore, removendo todas as aplicações de um
fuzzy sobre outro. A Figura 3.7 mostra como ficou a nova versão dessa mesma árvore de
finalização. Nas Figura 3.8 até a Figura 3.14 tem-se as sete outras dimensões técnicas
restantes.
18
Figura 3.7 – Árvore fuzzy para a dimensão técnica finalização.
Figura 3.8 – Árvore fuzzy para a dimensão técnica passe curto.
Figura 3.9 – Árvore fuzzy para a dimensão técnica passe longo.
Figura 3.10 – Árvore fuzzy para a dimensão técnica controle de bola.
19
Figura 3.11 – Árvore fuzzy para a dimensão técnica marcação.
Figura 3.12 – Árvore fuzzy para a dimensão técnica disciplina.
Figura 3.13 – Árvore fuzzy para a dimensão técnica passe jogo aéreo.
Figura 3.14 – Árvore fuzzy para a dimensão técnica bola parada.
3.2.2 Variáveis linguísticas
As dimensões técnicas recém-apresentadas são as variáveis linguísticas de saída.
Já as de entrada, são compostas pelos dados estatísticos conforme foram extraídos e
presentes no banco de dados.
20
As variáveis linguísticas de entrada escolhidas neste trabalho estão levemente
diferentes das propostas no modelo original desenvolvido por Pinho [1]. Com a
fuzzificação posta em prática, notou-se que, da forma como se encontravam, havia
variáveis que praticamente ditavam sozinhas a saída do bloco. Essas foram enfraquecidas.
Assim como outras poucas que não eram capazes de influenciar o valor da saída. Foram
removidas. A nova relação entre a dimensão técnica e os dados estatísticos utilizados
podem ser vistos na Tabela 3.1:
Tabela 3.1 – Relação entre dimensões técnicas e estatísticas de desempenho.
Dimensão técnica
(variável de saída) Estatística de desempenho (variável de entrada)
Finalização
goaltotal
shotontarget
shotstotal - shotblocked
Passe Curto
assistthroughball + keypassshort
shortpassaccurate
Shortpassaccurate + shortpassinaccurate
Passe Longo
keypasslong
passlongballaccurate
Passlongballaccurate + passlongballinaccurate
Controle de Bola
dribbletotal
dribblewon
turnover + dispossessed
Marcação
foulcommitted
interceptionall
outfielderblock + passcrossblockeddefensive+
outfielderblockedpass + clearancetotal
tackletotalattempted
Disciplina
foulcommitted
redcard
yellowcard
Jogo Aéreo
duelaerialtotal
duelaerialwon
goalhead
shothead
Bola Parada goalsetpiece
keypasscorner + keypassfreekick + keypassthrowin
21
shotsetpiece
3.2.3 Conjuntos Fuzzy
Seguindo com os aprimoramentos sobre o desenho proposto por Pinho [1]. Após
a redução do tamanho das árvores e o balanceamento das variáveis de entrada, tem-se um
modelo que entrega em sua defuzzificação valores muito próximos. Os resultados não
estavam de todo errado, pois um grande jogador não teria como saída um valor inferior a
outro atleta em sua especialidade, mas empatava com muitos outros. O que acontece é
que praticamente todos os jogadores são classificados como médio ou médio e uma
parcela mínima de alto/baixo, resultando em uma massa de valores praticamente iguais.
A postura adota foi a de tentar mover essa concentração de médio para as
extremidades baixo e alto. Assim, sempre verificando a saída final após cada alteração,
os conjuntos alto e baixo das variáveis linguísticas foram alongados em direção ao centro
do conjunto médio.
Além disso, no caso das variáveis linguísticas de entrada, ao contrário da versão
original [1] em que as funções de pertinência usavam percentis para calcular suas
extremidades, agora uma porcentagem relativa ao maior valor encontrado em cada
variável é empregada. O desenho final dos conjuntos fuzzy representando baixo (rampa),
médio (triângulo) e alto (rampa) para as variáveis linguísticas de entrada pode ser visto
na Erro! Fonte de referência não encontrada..
Figura 3.15 – Arcabouço para variáveis linguísticas de entrada.
22
Com o avançar dessa operação já era possível ver uma representação de saídas
baixas e altas mais numerosa.
Para as variáveis linguísticas de saída, o conjunto que representa médio foi
expandido sobre alto e baixo para tornar os valores defuzzificados finais mais esparsos,
uma vez que o grau médio foi fortemente reduzido nas variáveis de entrada. Para isso, foi
adota uma função gaussiana com desvio padrão de 0,4, substituindo a triangular original.
A representação final para as variáveis linguísticas de saída encontra-se na Figura
3.16.
Figura 3.16 – Arcabouço para variáveis linguísticas de saída.
3.3 Implementação em Nuvem
Uma das escolhas iniciais sobre como operar sobre o modelo SaaS é a escolha da
própria nuvem. Criar uma infraestrutura própria foi descartado logo de início. A próxima
decisão passou a ser qual serviço usar.
A Amazon oferece, dentre outros produtos, o Amazon Elastic Compute Cloud
(EC2) o qual permite a criação de instâncias virtuais. Trata-se de um serviço muito
semelhante a possuir um servidor particular físico, com tamanho e capacidade
personalizáveis. Oferecendo um modelo de pagamento onde o custo é proporcional ao
uso e com um ano de teste gratuito. O ambiente se mostrou perfeito para a prototipação
do trabalho.
A versão gratuita com memória RAM, processamento e armazenamento reduzidos
(t2.micro) foi escolhida na listagem de opções disponíveis e se mostrou mais do que
23
suficiente. O sistema operacional selecionado foi o Ubuntu Server 14.04 e, minutos
depois, uma instância virtual foi então gerada.
A Figura 3.17 mostra o painel de controle das instâncias. Nele são listadas todas
as máquinas pertencentes ao usuário, além de todas as operações possíveis. É através
desse painel que uma máquina pode ser pausada, ter seus recursos aumentados e até
excluída.
Figura 3.17 – Painel de instâncias virtuais com apenas uma máquina em funcionamento.
Com o servidor em funcionamento, a próxima tarefa foi instalar o SGBD
PostgreSQL presente no repositório do Ubuntu e configurar suas permissões para permitir
acesso remoto pela porta especificada pela Amazon.
Para comunicação e troca de arquivos com o servidor foi utilizado o protocolo
SSH, fazendo uso da aplicação para Windows WinSCP [16]. Também através dele, o
robô extrator, já em posse das credenciais de acesso ao banco de dados previamente
instalado, foi movido via SFTP, ver Figura 3.18, e iniciado via SSH.
24
Figura 3.18 – Tela do WinSCP mostrando os arquivos do robô extrator no servidor.
Durante a execução do robô foi notado um inesperado alto consumo de memória
em uma ocasião, tendo inclusive superado a capacidade da limitada máquina virtual que
possui apenas 1 GB de memória RAM. O problema reside no fato de que antes de inserir
as informações no banco, o robô carrega todos arquivos JSONs de uma só vez na
memória, em estrutura de lista. Uma reescrita do código, fazendo-o trabalhar em lotes de
tamanho predeterminado resolveria o incômodo. Salvo esse caso, ele funcionou
perfeitamente, atualizando a base de dados conforme o esperado. A Figura 3.19 apresenta
os arquivos JSON extraídos antes de irem para banco, um total de aproximadamente 207
MB.
Figura 3.19 – Arquivos JSON extraídos pelo robô.
25
3.4 Implementação da Interface
Desenvolvida em linguagem de programação Java, ela suporta os três maiores
sistemas operacionais de computadores caseiros (Mac OS X, Windows e Linux). Seu
meio de operação tem como influência um Home Broker de corretora para mercado de
ações. A ideia básica consiste em abrir uma das múltiplas telas e arrastar um jogador para
seu interior a fim de ver os dados cabíveis. Além ilustrar os dados coletados, ela também
é a responsável por todos os cálculos fuzzy.
3.4.1 Operação
A visão geral do software quando o mesmo é recém-aberto é exibida na Figura
3.20 a seguir:
Figura 3.20 – Área de operação da interface. Em (1) estão listados todos os jogadores
extraídos, (2) as telas para as diferentes exibições e (3) é o espaço onde as telas são
manuseadas.
26
O menu lateral (1) dá acesso a todos os jogadores presentes na base ordenados
pelo nome. Por sua vez, (2) exibe as telas de visualização disponíveis, conforme a Figura
3.21.
Figura 3.21 – Interface com as listagens de jogadores e de telas expandidas.
Cada uma das telas possui uma finalidade específica e é através delas que o
usuário final deverá realizar suas análises.
A tela Ficha Técnica apresenta informações breves sobre os jogadores, como
idade e a que clubes constam de acordo com a base de dados.
Figura 3.22 – Tela Ficha Técnica.
27
A visão Comparador apresenta os jogadores em colunas e lista seus atributos
gerados pelo fuzzy. A Figura 3.23 compara o jogador Cristiano Ronaldo, um atacante,
com David Luiz, que costuma jogar como zagueiro. Perceba que o atacante tem notas
melhores em atributos como bola parada e passe curto. É válido destacar que a interface
não faz normalização sobre o que é retornado pelo fuzzy. A nota máxima calculada para
bola parada, por exemplo, foi de 0,813029358.
Figura 3.23 – Tela Comparador.
A Figura 3.24, tela Comparador Gráfico, transmite a mesma informação que a
anterior, nota nos macro atributos, mas as ilustra com um gráfico radar.
Figura 3.24 – Tela Comparador Gráfico.
28
A tela de Overall , Figura 3.25, recebe um jogador e procura dar uma avaliação
única de desempenho para ele em cada posição. Essa nota overall é calculada como
demonstrada no trabalho [1].
Por padrão, essa visão já mostra as notas para as posições em que o jogador está
habituado a jogar, mas é possível escolher outras e ver como seria o possível rendimento
do atleta. Na Figura 3.26 vemos a posição defensiva DL assinalada e como o desempenho
seria levemente inferior se o atleta for posto para jogar ali. Novamente, vale ressaltar que
não é feita a normalização sobre os valores.
Figura 3.25 – Tela Overall.
29
Figura 3.26 – Tela Overall com a posição atípica, DL, assinalada.
3.5 Engenharia de Software
A interface gráfica do projeto foi desenvolvida em linguagem de programação
Java 1.6, utilizando a IDE Netbeans 8.0.0 [17].
A instalação e configuração da base de dados PostgreSQL remota na nuvem, foi
feita com o software pgAdmin III [18], se conectando remotamente aos servidores da
Amazon via SSH.
Por fim, a base de dados local SQLite era manipulada com o cliente SQL DBeaver
[19].
3.5.1 Banco de Dados
Na nuvem, o banco de dados usado pelo robô extrator segue a mesma modelagem
usada no trabalho de Pinho [1].
Inicialmente, tentou-se usar a aplicação para desktop realizando consultas
diretamente à nuvem. Tal formato, porém, apresentava um nítido atraso entre o comando
executado na interface e a visualização de sua resposta na tela, o que prejudicava a sua
utilização. Uma medição mostrou que, em média, as queries demoravam 254
30
milissegundos para serem processadas, já a operação em sua totalidade (ir ao servidor e
retornar ao computador do usuário), 1386 milissegundos.
A seguir, é apresentada a consulta usada na medição de tempo.
SELECT *
FROM nnplayerteam as pt, team as t
WHERE pt.playerid = 11119
AND pt.teamid = t.teamid;
Como a latência se mostrou o maior causador da demora, uma atualização da
instância Amazon para um nível mais caro, permitiria um aumento de prioridade no
tráfego de dados da rede, representando uma possibilidade de solução. Para o propósito
desse trabalho, porém, foi decidido que a aplicação para desktop faria uso de um banco
de dados local seguindo praticamente a mesma modelagem presente na instância virtual.
Passando a baixar os dados e salvá-los localmente. Apenas após o cálculo do fuzzy
ocorrer, esses valores gerados são registrados em uma nova tabela denominada
Playerfuzzy. Ela participa do modelo através de um relacionamento 1:1 com a tabela
Player, usando playerId como sua chave estrangeira.
Figura 3.27 – Modelagem da base de dados com a nova tabela Playerfuzzy na cor vinho.
A tabela Playerfuzzy possui uma coluna para cada uma das oito dimensões
técnicas, mais uma para a chave estrangeira e outra para a primária.
31
Tabela 3.2 – Tabela Playerfuzzy.
Playerfuzzy
(pk) id (int)
finalizacao (real)
passecurto (real)
passelongo (real)
controledebola (real)
marcacao (real)
disciplina (real)
jogoaereo (real)
(fk) playerid (int)
3.5.2 Estrutura do código
A interface gráfica para desktop foi escrita usando a linguagem de programação
Java e o paradigma de orientação a objetos.
O código final contém um total de 44 classes. Uma parte considerável apenas
reescreve classes nativas do Java para alterar seu comportamento e portanto, não serão
apresentadas neste documento. A funcionalidade “arrastar e soltar” é o principal exemplo
dessa necessidade, pois os componentes não a suportam por padrão.
Diagrama de Componentes
A Figura 3.28 exibe os componentes que compõe o projeto da interface gráfica:
32
Figura 3.28 – Diagrama de componentes.
De forma macroscópica, o funcionamento de cada componente se resume a:
Sad: Contém as classes inicializadoras do sistema, assim como seus valores
padrões iniciais;
Fuzzy: Responsável pela lógica fuzzy, sua modelagem e aplicação sobre os dados;
IO: Realiza os processos de entrada e saída de informações no sistema.
Screens: Contém classes relacionadas as telas para a composição da interface
gráfica.
InternalLogic: Contêm classes nativas do Java que foram sobrescritas para
alterar seu comportamento padrão.
VO: Todas as classes deste pacote funcionam como value object, agrupando
informações de um mesmo conceito para trafegarem entre métodos de diferentes
classes do sistema;
Images: funciona como um repositório de ícones que são usados na interface;
Jfuzzylite: Biblioteca externa com implementação de modelagem fuzzy [20];
Docking-frames-core: Biblioteca externa para permitir que telas sejam
manuseadas dentro de outra tela [21];
Jfreechart: Biblioteca externa para apresentação visual de gráficos [22];
Ao longo desta seção, as classes do código final da aplicação serão apresentadas
conforme o pacote ao qual pertencem para facilitar a visualização.
33
Pacote Sad
Figura 3.29 – Diagrama UML do pacote Sad.
Soccer: Classe principal do projeto, possuindo o método main(). Ela invoca a
classe responsável por desenhar a janela (Window) e inicializa as classes que
fazem as consultas de jogadores e times do banco local.
Common: Contém as constantes do sistema, variáveis estáticas e métodos úteis
também estáticos, acessíveis por todo o projeto.
Routine: Contém e dispara as rotinas que rodam em uma thread paralela para:
o Baixar os dados da nuvem para a base local;
o Calcular os valores fuzzy de todos os jogos e registra-los na base de dados
local.
Team: Value Object que não representa um time em si, mas os parâmetros que
serão usados na consulta de clubes ao banco de dados.
Player: Semelhante ao Team, mas armazena os parâmetros para a consulta de
jogadores.
34
Pacote IO
Figura 3.30 – Diagrama UML do pacote IO.
SQLite: Contém métodos para todas as consultas e escritas necessárias na base
de dados local.
RemoteDataBase: Contém métodos para todas as consultas à base de dados na
nuvem.
Pacote Fuzzy
Figura 3.31 – Diagrama UML do pacote Fuzzy.
35
Fuzzy: Classe responsável por aplicar a lógica fuzzy sobre os dados. Faz uso da
biblioteca FuzzyLite.
FuzzySettings: Representa uma modelagem fuzzy completa, como quais funções
de pertinência usar e como são as regras de inferência.
FuzzyInputPercentiles: Usada para ajustar os intervalos dos conjuntos fuzzy. Foi
criada apenas para acelerar testes até se alcançar a modelagem que foi apresentada
nesse trabalho.
Overall: Classe que calcula a nota geral para o jogador. Possui regras para cada
uma das posições em que um jogador venha a jogar.
Pacote VO
Figura 3.32 – Diagrama UML do pacote VO.
Todas as classes deste pacote funcionam como value object, com exceção da
classe SoccerElement que não é instanciada por ninguém e serve para centralizar o
método de capturar a imagem e texto de exibição. Assim sendo:
PlayerFuzzy: Agrupa dados do jogador após a passagem pelo motor fuzzy.
PreTerm: Agrupa dados para ajustar as funções de pertinência na biblioteca
FuzzyLite.
PlayerVO: Agrupa dados do jogador antes de passar pelo motor fuzzy.
36
Season: Agrupa dados que remetem a uma temporada de futebol.
PlayerOverall: Agrupa as notas de overall para todas as posições no campo de
um jogador
Listitem: Agrupa dados que serão trafegados entre componentes do tipo lista.
PlayerBio: Classe que agrupa dados de caráter pessoal de um jogador. Como
nome e data de nascimento.
Pacote Screens
Figura 3.33 – Diagrama UML do pacote Screen.
Em Java cada tela é uma classe que herda as propriedades da classe nativa JFrame.
Por isso, só é necessário implementar métodos simples de resposta a eventos. Os quais
são disparados quando um botão é clicado, por exemplo.
FuzzyTuning: Classe responsável pela tela de ajuste fino do motor fuzzy,
mostrada na figura 3.4;
37
ScreenList: Tela com a listagem de todos os jogadores. Presente no painel
esquerdo.
ScreenScreensList: Tela com a listagem com todas as telas para análise dos
jogadores. Também presente no menu esquerdo.
Window: É a tela principal do sistema, todas as outras estão contidas em seu
interior. Para isso foi necessário usar a biblioteca DockingFrames [21].
Screen: Essa classe nunca é instanciada diretamente. Possui a implementação
necessária para que seja possível arrastar um jogador da listagem e soltá-lo no
interior de um componente, que por herança está presente em suas classes filhas.
ScreenOverall: Tela que apresenta a nota de um jogador para cada posição do
campo.
ScreenComparator: Tela que contém o gráfico radar de comparação, faz uso da
biblioteca JFreeChart [22].
ScreenRawComparator: Tela que permite a comparação entre as dimensões
técnicas dos jogadores em uma tabela.
panelBio: Classe que herda as propriedades da classe nativa JPanel, não sendo
portanto uma tela em si. É um painel com diferentes componentes visuais para
exibir texto e foto.
ScreenForm: Tela que exibe as informações pessoais do jogador, como
aniversário e nome. A classe em si é praticamente vazia. Quando um objeto
jogador é liberado sobre sua superfície, ela cria uma instância da classe panelBio
anterior sobre si, que se encarrega de mostrar o conteúdo esperado.
3.5.3 Bibliotecas
Para desenvolver todas as suas funcionalidades, são usadas quatro bibliotecas
externas, todas de licença livre. A mais importante para o projeto é a FuzzyLite [20]. Esta
biblioteca é responsável pela implementação do motor fuzzy, ela apresenta ajustes finos
ao nível de: controladores, variáveis linguísticas, métodos de ativação, tipos de
conjunções e disjunções e defuzzificadores.
A segunda em ordem de importância é a biblioteca DockingFrames [21],
responsável pela dinamicidade das telas do sistema. Graças a ela é possível arrastar uma
38
tela para outro monitor ou mudar seu posicionamento dentro da tela principal, por
exemplo.
O gráfico radar, presente na tela de comparação, é produzido com a JFreeChart
[22]. Ela suporta diversos outros tipos de gráficos não aproveitados, que podem vir a
serem usados em projetos futuros.
3.6 Modelo de Negócio
Levando em consideração o perfil SaaS de distribuição de software, uma vez que
parte do produto se encontraria na nuvem e não inteiramente com o cliente, seria possível
cobrar um modelo de assinatura. Esse formato poderia garantir um fluxo de capital para
manter a evolução da ferramenta. Novas fontes de dados poderiam ser adicionadas ao
robô extrator ou novas modelagens fuzzy poderiam ser testadas e aprimoradas. A Figura
3.34 apresenta a modelagem de negócio na ferramenta de planejamento estratégico
canvas:
39
Figura 3.34 – Canvas do modelo de negócio.
Com o canvas devidamente determinado é possível prosseguir com a elaboração
de uma planilha de custos e receitas.
Para planejar a progressão financeira da empresa foi estipulado que o valor da
assinatura seria de R$ 230,00 mensais. Chegou-se nesse valor levando em consideração:
Não existem dados estatísticos de futebol no mercado, com essa variedade,
disponíveis de forma gratuita para baixar. Existem apenas versões pagas ou
gratuitas, porém limitadas a forma que o site as exibir.
O produto pode ser interpretado como sendo dois: dados estatísticos de jogadores
de futebol e software de apoio à decisão.
Também foi considerado que a cada mês ter-se-ia cinco novos assinantes
conquistados, isto é, existiriam cinco assinantes no primeiro mês, dez no segundo e assim
por diante. Algo razoável, uma vez que entre os custos está uma quantia direcionada para
o marketing digital. Para encontrar o valor da Amazon EC2 foi pego seu custo de $0.023
por hora [23] e multiplicado por um mês inteiro, usando o dólar igual a R$3,10.
40
Figura 3.35 – Planilha de custos e receitas.
Observando a Figura 3.35, é possível observar que a receita supera as despesas no
sexto mês. Além disso, o capital investido é recuperado no décimo. Com um total de 50
assinantes.
Outra abordagem que esse sistema permitiria seria tornar o acesso ao banco na
nuvem livre e só cobrar pelo uso da interface. Um repositório de dados estatísticos onde
a criatividade de cada um faria surgir novas abordagens para explorar a informação. Ao
mesmo tempo, esse movimento ao redor do banco também traria contribuidores, isto é,
pessoas que também o alimentariam com novas fontes de dados ou corrigiriam os já
presentes e incorretos. Consequente aprimorando o potencial da interface.
NOME MÊS
1 2 3 4 5
Amazon EC2 53,05R$ 53,05R$ 53,05R$ 53,05R$ 53,05R$
Marketing 100,00R$ 100,00R$ 100,00R$ 100,00R$ 100,00R$
Salário 5.000,00R$ 5.000,00R$ 5.000,00R$ 5.000,00R$ 5.000,00R$
Aluguel 650,00R$ 650,00R$ 650,00R$ 650,00R$ 650,00R$
Água 30,00R$ 30,00R$ 30,00R$ 30,00R$ 30,00R$
Energia 60,00R$ 60,00R$ 60,00R$ 60,00R$ 60,00R$
Tefone 100,00R$ 100,00R$ 100,00R$ 100,00R$ 100,00R$
Contador 200,00R$ 200,00R$ 200,00R$ 200,00R$ 200,00R$
IPTU 110,00R$ 110,00R$ 110,00R$ 110,00R$ 110,00R$
Assinatura 1.150,00R$ 2.300,00R$ 3.450,00R$ 4.600,00R$ 5.750,00R$
TOTAL 5.153,05-R$ 4.003,05-R$ 2.853,05-R$ 1.703,05-R$ 553,05-R$
ACUMULADO 5.153,05-R$ 9.156,10-R$ 12.009,15-R$ 13.712,20-R$ 14.265,25-R$
CUSTO FIXO
RECEITA
NOME MÊS
6 7 8 9 10
Amazon EC2 53,05R$ 53,05R$ 53,05R$ 53,05R$ 53,05R$
Marketing 100,00R$ 100,00R$ 100,00R$ 100,00R$ 100,00R$
Salário 5.000,00R$ 5.000,00R$ 5.000,00R$ 5.000,00R$ 5.000,00R$
Aluguel 650,00R$ 650,00R$ 650,00R$ 650,00R$ 650,00R$
Água 30,00R$ 30,00R$ 30,00R$ 30,00R$ 30,00R$
Energia 60,00R$ 60,00R$ 60,00R$ 60,00R$ 60,00R$
Tefone 100,00R$ 100,00R$ 100,00R$ 100,00R$ 100,00R$
Contador 200,00R$ 200,00R$ 200,00R$ 200,00R$ 200,00R$
IPTU 110,00R$ 110,00R$ 110,00R$ 110,00R$ 110,00R$
Assinatura 6.900,00R$ 8.050,00R$ 9.200,00R$ 10.350,00R$ 11.500,00R$
TOTAL 596,95R$ 1.746,95R$ 2.896,95R$ 4.046,95R$ 5.196,95R$
ACUMULADO 13.668,30-R$ 11.921,35-R$ 9.024,40-R$ 4.977,45-R$ 219,50R$
CUSTO FIXO
RECEITA
41
3.7 Análise dos Resultados
A fim de avaliar o desempenho da ferramenta, foram selecionados os três atletas
que obtiveram as melhores notas no SAD, em cada uma das oito dimensões técnicas.
Em seguida, os mesmos atletas foram consultados no site WhoScored?, que além
de dados estatísticos já coletados pelo robô extrator, também faz suas próprias análises.
Dentre as informações disponíveis, foi consultada a seção com a listagem das
características fortes de um jogador, como “muito forte em drible”, por exemplo.
Com ambas as informações, foram comparados a dimensão técnica em que o
jogador se destacou, com seus pontos fortes obtidos no WhoScored?. O objetivo da
comparação é verificar se há coerências entre seu dado técnico e seus supostos pontos
fortes. Por exemplo, se a ferramenta SAD indicou que o atleta apresenta um alto grau de
bola parada, é esperado que tivesse “muito forte em tiros livres” dentre seus pontos
positivos. Caso ocorra o oposto, isto é, SAD indica alto grau de bola parada, já o site
afirma “ruim em tiros livres”, tem-se uma incoerência entre as duas avaliações.
Nas Tabela 3.3 até a Tabela 3.10 são exibidos para cada indivíduo: seu nome, o
valor de sua avaliação na dimensão técnica e seu ponto forte mais pertinente à
comparação, no WhoScored?. Também é apresentado uma coluna Nota, que é o valor
fornecido pelo SAD normalizado no intervalo [0,1], para facilitar o entendimento sobre
o quão bom a ferramenta creditou o jogador na dimensão técnica.
Tabela 3.3 – Melhores em bola parada e avaliação em WhoScored?.
Bola Parada
Jogador SAD Nota WhoScored?
Hakan
Calhanoglu 0,813029357853349 1,0000 Muito forte em tiros livres
Memphis
Depay 0,66918739431626 0,7774 Forte em tiro livre direto
Hulk 0,623250323328124 0,7063 Forte em tiro livre direto
Tabela 3.4 – Melhores em controle de bola e avaliação em WhoScored?.
Controle de Bola
Jogador SAD Nota WhoScored?
Lionel Messi 0,809802240166836 1,0000 Muito forte em drible
Forte em prender a bola
Karim
Bellarabi 0,692473973130903 0,8175 Muito forte em drible
42
Neymar 0,660422079068251 0,7677 Muito forte em drible
Forte em prender a bola
Tabela 3.5 – Melhores em finalização e avaliação em WhoScored?.
Finalização
Jogador SAD Nota WhoScored?
Bradley Wright-
Phillips 0,685399233151067 1,0000 Forte em finalização
Lionel Messi 0,579287516179307 0,7603 Muito forte em
finalização
Robert
Lewandowski 0,547078905626514 0,6875 Forte em finalização
Tabela 3.6 – Melhores em passe curto e avaliação em WhoScored?.
Passe Curto
Jogador SAD Nota WhoScored?
Lionel Messi 0,833325 1,0000 Muito forte em passes
Cesc Fàbregas 0,833325 1,0000 Muito forte em passes
Santiago Cazorla 0,833325
1,0000 Muito forte em passes
Forte em passes chave
Tabela 3.7 – Melhores em passe longo e avaliação em WhoScored?.
Passe Longo
Jogador SAD Nota WhoScored?
Johannes Geis 0,833325 1,0000 Forte em passes longos
Granit Xhaka 0,833325 1,0000 Muito forte em passes em
geral
Kevin McDonald 0,833325 1,0000 Muito forte em passes em
geral
Tabela 3.8 – Melhores em marcação e avaliação em WhoScored?.
Marcação
Jogador SAD Nota WhoScored?
Andrew Farrell 0,76534756113141 1,0000 -
Saba Kverkvelia 0,649276616338287 0,8061 Muito forte em
interceptação e tomada de
bola
Zach Loyd 0,64696311931068 0,8022 Forte em interceptação de
bola
Tabela 3.9 – Melhores em disciplina e avaliação em WhoScored?.
Disciplina
Jogador SAD Nota WhoScored?
43
Sam Vokes 0,833325000000001 1,0000 -
Marco Di Vaio 0,833325000000001 1,0000 -
Timmy Simons 0,833325000000001 1,0000 -
Tabela 3.10 – Melhores em jogo aéreo e avaliação em WhoScored?.
Jogo Aéreo
Jogador SAD Nota WhoScored?
Rudy Gestede
0,833325 1,0000 Muito forte em jogo aéreo
Forte em tentativas de cabeçada
Sean Morrison
0,613269203067448 0,6699 Muito forte em jogo aéreo
Aduriz 0,588943675419041 0,6334 Muito forte em jogo aéreo
Forte em tentativas de cabeçada
Não foi possível verificar o fator disciplina, pois o site WhoScored.com não
destacava pontos fortes dos jogadores nesse aspecto.
Nas dimensões técnicas bola parada, passe curto e passe longo as comparações se
mostraram coerentes. Jogadores com a nota do SAD mais alta apresentam pontos fortes
maiores ou iguais a outro com nota menor.
Controle de bola, finalização, jogo aéreo e marcação apresentaram leves
divergências. Em jogo aéreo, Aduriz ficou abaixo de Sean de acordo com o SAD, mas
WhoScored? o consideraria melhor, pois atribui-lhe “forte tentativas de cabeçada” que
Sean não tem. Em finalização, Messi está em segundo lugar, mas é o único do
agrupamento com “Muito forte em finalização”. Em controle de bola, Neymar possui
“forte em prender a bola” que Karim Bellarabi não possui, mas SAD o avaliou como
inferior. Por fim, em marcação, o zagueiro Andrew Farrell recebeu a melhor nota, embora
WhoScored? não lhe tenha destacado nenhuma característica.
Essas leves divergências foram causadas porque a modelagem fuzzy em sua versão
atual não aplica pesos diferentes entre os campeonatos. Fazendo com que um bom
rendimento em um campeonato pouco competitivo tenha a mesma boa avaliação do que
em um muito competitivo. O que não é o desejado, mas justificam os casos de leve
discordância que a plataforma apresentou.
44
Considerações Finais
4.1 Conclusões
Tanto a ferramenta coletora de dados de jogadores desenvolvida por Pinho [1],
quanto sua própria de base de dados SQL foram migradas com sucesso para uma instância
de máquina virtual nos servidores Amazon EC2 e podem ser operadas remotamente,
caracterizando a identidade SaaS do projeto.
A interface gráfica multiplataforma foi desenvolvida, sendo capaz de se conectar
ao servidor, baixar as novas extrações do robô e apresentar diferentes visões que
possibilitam o correto estudo dos dados fuzzificados.
A modelagem fuzzy proposta por Pinho [1] foi implementada e seus resultados
estudados. Desse estudo foram feitas modificações em sua modelagem com resultados
positivos após algumas tentativas. A ferramenta passou a ser capaz de discernir quais
atletas tiveram um bom ou mau desempenho com uma precisão satisfatória, sendo
possível identificar o quanto um atleta foi melhor que um segundo, por exemplo.
Jogadores classificados como medianos, entretanto, possuem as notas sempre muito
próximas, sendo difíceis de comparar os rendimentos de dois atletas distintos nesse
agrupamento.
Ao final do projeto obteve-se uma ferramenta funcional que captura, processa e
apresenta dados de jogadores de futebol de forma útil para auxílio em uma tomada de
decisão. Dessa forma, todos os objetivos listados na seção 1.4 foram cumpridos.
4.2 Trabalhos Futuros
A primeira melhoria possível seria introduzir um peso distinto para cada um dos
campeonatos de futebol na modelagem fuzzy desenvolvida. Uma maneira de definir esse
peso de forma embasada seria calcular a média salarial dos jogadores em cada
45
campeonato e usá-la como peso, apostando que a dificuldade e competitividade que um
atleta enfrenta em cada torneio foram precificadas pelo mercado.
Novas formas de coleta de dados poderiam ser desenvolvidas. Atualmente tem-se
apenas um dado pontual como passes. Para um dado mais vivo, poder-se-ia criar um
interpretador de narrações das próprias partidas e dessa forma possivelmente capturar
toda uma cena. Isto é, seria registrado, por exemplo, que um jogador conduziu a bola
sentido o centro do campo, olhou para o lado de sua perna dominante e só então executou
o passe. Essa mesma cena poderia vir a ser repetida outras vezes no decorrer da mesma
ou outras partidas, mapeando uma nova característica do comportamento daquele
jogador.
O projeto limitou-se a trabalhar com apenas oito dimensões técnicas, mas seria
válido fazer experimentos com uma maior variedade, principalmente para aumentar a
confiabilidade da nota por posição (overall). Um porte físico avantajado, por exemplo, é
imprescindível para um jogador defensivo, mas não é um dado considerado durante o
cálculo da nota para as posições defensivas, o que faz com que o overall gerado para
jogadores baixos ou leves tenha menor credibilidade.
A interface do sistema poderia ser reescrita para funcionar na web (através de
navegadores). Ela foi desenvolvida em linguagem Java para atender aos três principais
sistemas operacionais de computadores, mas ignora os dispositivos móveis. Sua
reformulação para web resolveria esse impasse mantendo uma única base de código e
reforçaria o modelo SaaS do projeto. Facilitando o controle de atualizações do sistema e
aumentando o número usuários possíveis.
Referências bibliográficas
[1] PINHO, L.H. Sistema de Apoio à Decisão para avaliação técnica de jogadores de
futebol: implementação de ferramenta de ETL e modelagem conceitual baseada em
Lógica Fuzzy., 2016
[2] BOHANEC, M. Decision Making: A Computer-Science and Information-Technology
Viewpoint. Interdisciplinary Description of Complex Systems, v. 7, n. 2, p. 22–
37, 2009.
46
[3] SANDRI, S.; CORREA, C. Lógica Nebulosa. Instituto Tecnológico da Aeronáutica
- ITA. V Escola de Redes Neurais., p. 73–90, 1999.
[4] GOMIDE, F. A. C.; GUDWIN, R. R.; TANSCHEIT, R. Conceitos Fundamentais Da
Teoria De Conjuntos Fuzzy , Lógica Fuzzy E Aplicações. n. June, 1995.
[5] ARMBRUST, M. et al. Above the clouds: A Berkeley view of cloud
computing. University of California, Berkeley, Tech. Rep. UCB , p. 07–013,
2009.
[6] JAATUN, M. G. et al. Cloud Computing: An Overview. LNCS, v. 5931, p. 626–631,
2009.
[7] GUO, P. A Survey of Software as a Service Delivery Paradigm. 2009.
[8] ARMBRUST, M. et al. A View of Cloud Computing Clearing the clouds away from
the true potential and obstacles posed by this computing capability.
CommuniCAtionS of thE ACm, v. 53, n. 4, 2010.
[9] LESS, A. Computers in sport. Applied Ergonomics, v. 16, n. 1, p. 3–10, 1985.
[10] GOLDSBERRY, K. Courtvision: New visual and spatial analytics for the NBA.
Proc. 6th Annual MIT Sloan Sports Analytics Conference, p. 1–7, 2012.
[11] KUMAR, G. Machine Learning for Soccer Analytics., p. 1–2, 2013.
[12] SA, L. H. P. ; MELLO, Flávio Luis de . Modelagem Fuzzy para Avaliação Técnica
de Jogadores de Futebol. In: ELFA 2016, 2016, Rio de Janeiro. 1o Encontro de
Lógica Fuzzy Aplicada em Administração. Rio de Janeiro.
[13] BAZMARA, M. A Novel Fuzzy Approach for Determining Best Position of Soccer
Players. International Journal of Intelligent Systems and Applications, v. 6, n. 9,
p. 62–67, 2014.
[14] Opta Home. Disponível em: <http://www.optasports.com/>. Acesso em: 25 ago.
2017.
[15] MCAFEE, A.; BRYNJOLFSSON, E. HBR.ORG Spotlight on Big Data Big Data:
The Management Revolution. 2012.
[16] WinSCP :: Official Site :: Download. Disponível em:
<https://winscp.net/eng/download.php>. Acesso em: 25 ago. 2017.
[17] Welcome to NetBeans. Disponível em: <https://netbeans.org/>. Acesso em: 25 ago.
2017.
[18] pgAdmin - PostgreSQL Tools. Disponível em: <https://www.pgadmin.org/>.
Acesso em: 25 ago. 2017.
47
[19] DBeaver | Free Universal SQL Client. Disponível em: <https://dbeaver.jkiss.org/>.
Acesso em: 25 ago. 2017.
[20] FuzzyLite | The FuzzyLite Libraries for Fuzzy Logic Control. Disponível em:
<http://www.fuzzylite.com/>. Acesso em: 25 ago. 2017.
[21] Docking Frames. Disponível em: <http://www.docking-frames.org/>. Acesso em:
25 ago. 2017.
[22] JFreeChart. Disponível em: <http://www.jfree.org/jfreechart/>. Acesso em: 25 ago.
2017.
[23] Definição de preço de instâncias EC2- Amazon Web Services (AWS). Disponível
em: <https://aws.amazon.com/pt/ec2/pricing/on-demand//>. Acesso em: 23 ago.
2017.