visbig · visbig visualizar bigdata em tempo real gonçalo fialho pires dissertação para...
TRANSCRIPT
VisBigVisualizar BigData em tempo real
Gonçalo Fialho Pires
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Orientador: Prof. Daniel Jorge Viegas Gonçalves
Júri
Presidente: Prof. Miguel Nuno Dias Alves Pupo CorreiaOrientador: Prof. Daniel Jorge Viegas Gonçalves
Vogal: Prof. Sandra Pereira Gama
October 2018
ii
Agradecimentos
Gostaria de agradecer a minha mae por todo o apoio, coragem e carinho dado ao longo de toda a minha
vida e por estar sempre do meu lado em todo este percurso, sem ela a concretizacao deste projeto nao
seria possıvel.
Ao professor Daniel Goncalves por me ter confiado este trabalho e pelo seu apoio constante ao
longo deste ano, e nos anos em que fui seu aluno cujos conhecimentos adquiridos foram fundamentais
para a realizacao deste trabalho.
A minha namorada pelo apoio e carinho durante este percurso, a minha motivacao nao teria sido a
mesma sem o seu acompanhamento e ajuda nas fases mais desgastantes.
A minha famılia por me ajudar e acreditar no meu trabalho, pelas suas palavras de carinho e mo-
mentos passados.
A todos os meus colegas e amigos que me acompanharam pela ajuda que me deram durante estes
5 anos.
Este trabalho foi financiado por fundos nacionais atraves da FCT - Fundacao para a Ciencia e a
Tecnologia, no projeto VisBig - Visualizacao em Tempo Real de Big Data em Streaming com a referencia
PTDC/CCI-CIF/28939/2017, e pelo financiamento plurianual do INESC-ID - UID/CEC/50021/2013.
iii
iv
Resumo
Hoje em dia dispositivos eletronicos podem ser encontrados em qualquer lugar, seja num computador
pessoal, smartwatch ou ate mesmo nos nossos eletrodomesticos. Estes dispositivos criam informacao
relevante para a identificacao de padroes ou anomalias dos sistemas. Dado este crescimento, alguns
metodos de visualizacao deixam de ser capazes de responder eficientemente as necessidades dos uti-
lizadores. Embora existam solucoes para a visualizacao deste tipo de informacao e relevante procurar
novas maneiras de as apresentar num ambiente em tempo real para que seja possıvel aos utilizadores
agir com rapidez a alteracao brusca no fluxo natural dos dados e poderem tomar acoes na tenta-
tiva de resolver os problemas dos sistemas. Esta tese fornece uma solucao para apresentar grandes
quantidades de dados em tempo real em que os utilizadores sejam capazes de identificar anomalias e
tendencias na informacao assim como manter o contexto quando existem alteracoes no fluxo de dados.
Propomos o sistema VisMillion, uma interface de visualizacao de grandes quantidades de dados
em tempo real. Esta solucao web e baseada na tecnologia CANVAS. Utilizando diferentes modulos
o sistema representa a informacao de diferentes maneiras. Quanto mais recente a informacao, mais
detalhada ela e, assim cada modulo utiliza diferentes tecnicas para agregar e processar a informacao.
Este trabalho faz uma analise pelo estado da arte no que diz respeito a visualizacao de grandes
quantidades de dados em tempo real. De seguida apresenta a arquitetura da solucao e respetivas
justificacoes as opcoes tomadas e no final realiza uma avaliacao detalhada dos resultados obtidos.
No final e feita uma reflexao onde e tambem referido algum do trabalho futuro que poderia melhorar o
sistema.
Palavras-chave: Grandes Quantidades de Dados, BigData, Tempo Real, Streaming, Visualizacao,
Fluxo, Tendencias, Valores atıpicos, Padroes
v
vi
Abstract
Nowadays information devices can be found anywhere, whether in a personal computer, smartwatch
or even in our appliances. These devices create relevant information to the identification of patterns or
anomalies of the systems. Given the significant growth of those devices, some representation methods
are no longer able to respond efficiently to users needs. Although there are solutions to visualize this
type of information it’s important to look for new ways to present them in a real-time environment so
users can act quickly to the abrupt change of the regular flow of data so they can attempt to solve the
problems of the systems. This thesis provides a solution for presenting large amounts of real-time data
where users are able to identify anomalies and trends in information as well as maintain context when
changes in data flow exist.
We propose VisMillion, a visualization interface for large amounts of data in real-time. This web
solution is based on Canvas technology. Using different modules the system represents data in many
ways. The more recent the data, the more detailed it is, so each module uses different techniques to
aggregate and process information.
This report does a state-of-the-art analysis for viewing large amounts of data in real time. Then it
presents the architecture of the solution and its justifications for the options taken. Finally, carries out a
detailed evaluation of the obtained results and a final analysis and reflection where some of the future
work is also mentioned which could improve the system.
Keywords: Large ammount of data, BigData, Real-Time, Streaming, Visualization, Flow, Trend,
Outliers, Patterns
vii
viii
Conteudo
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Lista de Sımbolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introducao 1
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Trabalho Relacionado 5
2.1 Metodos Gerais de Visualizacao de BigData em tempo real . . . . . . . . . . . . . . . . . 5
2.1.1 Rethinking Visual Analytics for Streaming Data Applications . . . . . . . . . . . . . 5
2.1.2 Information Visualization and Visual Data Mining . . . . . . . . . . . . . . . . . . . 6
2.2 Solucoes de Visualizacao de dados em larga escala e em tempo real . . . . . . . . . . . 7
2.2.1 Towards an Adaptive Framework for Real-Time Visualization of Streaming Big
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Real-Time Visual Analytics for Event Data Streams . . . . . . . . . . . . . . . . . . 8
2.2.3 I2 - Interactive Real-Time Visualization for Streaming Data . . . . . . . . . . . . . 9
2.2.4 Real-time large-scale big data networks analytics and visualization architecture . . 10
2.2.5 A Framework for Monitoring and Measuring a Large-Scale Distributed System in
Real Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.6 LiveRAC: Interactive Visual Exploration of System Management Time Series Data 11
2.2.7 An Online Visualization System for Streaming Log Data of Computing Clusters . . 12
2.2.8 Trend Analysis in Large Timeseries of High-Throughput Screening Data Using a
Distortion-Oriented Lens with Semantic Zooming . . . . . . . . . . . . . . . . . . . 13
2.2.9 BinX: Dynamic Exploration of Time Series Datasets Across Aggregation Levels . . 14
2.2.10 imMens: Real-time Visual Querying of Big Data . . . . . . . . . . . . . . . . . . . . 16
ix
2.3 Metodos de reducao e amostragem de dados . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Sampling Techniques to Improve Big Data Exploration . . . . . . . . . . . . . . . . 16
2.3.2 CEDARS: Combined Exploratory Data Analysis Recommender System . . . . . . 17
2.4 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Servidor - Streammer 21
3.1 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Ferramentas para a ligacao e transmissao de dados . . . . . . . . . . . . . . . . . . . . . 23
3.3 Comunicacao Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Envio de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Metodo de envio dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.3 Servidor para Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Gerador de Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Front End - Interface 31
4.1 InfoVis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1 Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3 Modulo Outliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.4 Modulo Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.5 Animacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 Demonstracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Avaliacao 59
5.1 Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 Questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Testes de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Conclusoes 77
6.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Bibliografia 81
A Documento Testes de Usabilidade 85
x
B Questionarios 91
C Resultados Qualitativos dos Questionarios 97
xi
xii
Lista de Tabelas
2.1 Resumo entre os trabalhos analisados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Propriedades do dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Exemplo ficheiro servidor de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Diferencas entre DOM e Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Escalas disponıveis na biblioteca D3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Caracterısticas do modulo Barchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Caracterısticas do modulo Linechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Caracterısticas do modulo Scatterchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Caracterısticas do modulo de Outliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Variacoes de tendencias - 1o Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Outliers e agregacoes atıpicas - 2o Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Variacoes de fluxo - 3o Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-
mente) do 1o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-
mente) do 2o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6 Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-
mente) do 3o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7 Estatısticas das respostas dos utilizadores aos questionarios . . . . . . . . . . . . . . . . 70
xiii
xiv
Lista de Figuras
2.1 Correlacao entre os diferentes tipos, por [Keim, 2002] . . . . . . . . . . . . . . . . . . . . 7
2.2 Relaxed Timelines, por [Fischer et al., 2012] . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Visualizacoes do sistema de monitorizacao, por [Zhan et al., 2013] . . . . . . . . . . . . . 11
2.4 Visao global do sistema LiveRac e interacao, por [McLachlan et al., 2008] . . . . . . . . . 12
2.5 Cluster Insight View, por [Xia et al., 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Diferentes nıveis de detalhe disponıveis no sistema TrendDisplay, por [Brodbeck and Gi-
rardin, 2003] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Componentes de visualizacao interligados BinX, por [Berry and Munzner, 2004] . . . . . 15
3.1 a) WebSockets b) HTTP Long Polling , por [Pimentel and Nickerson, 2012] . . . . . . . . 22
3.2 Estrutura Global do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Exemplo de comunicacao Interface-Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Valor da Bitcoin (BTC) em 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Exemplo de um dataset gerado pelo programa . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Desenhos em papel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Implementacao utilizando elementos DOM . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 UML da interface VisMillion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Fluxo da interface VisMillion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Instanciacao do Chart para transacoes BTC . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Chart de transacoes BTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Opcoes geradas por cada objeto. Chart, Barchart, Linechart, Scatterchart da esquerda
para a direita respetivamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8 Barchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Mousehover do Barchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.10 Linechart com ligacao a todos os pontos . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.11 Linechart em fluxo baixo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.12 Divisao de seccoes dos diagramas em caixa . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.13 Linechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.14 Mousehover do Linechart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.15 Scatterchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
xv
4.16 Interacao ScatterChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.17 Modulo de Outliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.18 Instanciacao da ligacao ao servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.19 Agregacoes atıpicas verificadas atraves do Barchart . . . . . . . . . . . . . . . . . . . . . 55
4.20 Tendencias e valores mınimos e maximos do Linechart . . . . . . . . . . . . . . . . . . . 55
4.21 Tendencias e agregacoes atıpicas Scatterchart . . . . . . . . . . . . . . . . . . . . . . . . 56
4.22 Demonstracao de todos os modulos em conjunto . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Dataset do teste de tendencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Dataset do teste de Outliers e agregacoes atıpicas . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Dataset do teste de Fluxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Dataset do teste Aberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Frequencia de cada idioma conhecido pelos utilizadores . . . . . . . . . . . . . . . . . . . 66
5.6 Boxplot de Timestamps do 1o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.7 Boxplot de timestamps do 2o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.8 Boxplot de Timestamps do 3o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.9 Frequencia de cada idioma conhecido pelos utilizadores . . . . . . . . . . . . . . . . . . . 71
5.10 FPS - 2 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.11 Memoria utilizada - 2 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.12 FPS - 3 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.13 Memoria utilizada - 3 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.14 Boxplot de Timestamps do 1o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.15 Boxplot de timestamps do 2o teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.1 Questionario - Variacoes de Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.2 Questionario - Outliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.3 Questionario - Valores Medios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.4 Questionario - Agregacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.5 Questionario - Intervalos de valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.6 Questionario - Maximos mınimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.7 Questionario - Transicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.8 Questionario - Intervalos temporais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.9 Questionario - Compreensao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.10 Questionario - Interacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.11 Questionario - Aprendizagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
xvi
Glossario
API Application Programming Interface. 22
BTC BitCoin. xv, 26, 27, 38–40, 60
CSS Cascading Style Sheets. 35
CSV Comma-Separated Values. 23, 27, 29
D3 Data-Driven Documents. 4, 37, 38, 53, 78
DOM Document Object Model. xiii, xv, 36
FPS Frames per Second. xvi, 36, 37, 42, 50, 72–75
GB GigaByte. 26
GPU Graphics Processing Unit. 16
HCI Human-Computer Interaction. 59
HTML Hypertext Markup Language. 22, 35
IoT Internet of Things. 5
IP Internet Protocol. 52
SQL Structured Query Language. 27
SVG Scalable Vector Graphics. 35–37, 53
XML Extensible Markup Language. 35
xvii
xviii
Capıtulo 1
Introducao
Com o aumento notorio de dispositivos capazes de processar e armazenar informacao existe a neces-
sidade de criar sistemas capazes de representar os dados gerados por estes equipamentos, sejam eles
dos mais simples smartphones e tablets passando por smart meters e ate chegar aos componentes
mais avancados como os supercomputadores. A lei de Moore [Moore, 1965] indica que a cada dois
anos o poder de processamento dos dispositivos duplica, este processo de melhoria do hardware e
realizado porque a quantidade de informacao tem vindo a aumentar e e necessario manipular esta
informacao em intervalos de tempo uteis.
Os dados sao gerados de multiplas fontes e com diferentes propositos, na maioria dos casos por
cada acao/clique que uma pessoa realiza num dispositivo eletronico e registado algures numa cloud ou
base de dados um registo desse acontecimento [Madden, 2012], seja para analise de tendencias dos
utilizadores ou para estrategias de comercializacao das empresas. Os robots e maquinas que realizam
trabalho autonomo geram os registos operacionais dos equipamentos, os sistemas de monitorizacao
de redes complexas recolhem de milhares de dispositivos informacao importante para a analise, o
aparecimento de sistemas embebidos (como sensores) tambem geram informacao. Estes sao alguns
dos exemplos que levam ao aparecimento de aglomerados de informacao e e por isso cada vez mais
comum observar o crescimento da capacidade de armazenamento das memorias dos equipamentos.
Uma vez gerada esta informacao existem varias formas de a utilizar, seja a treinar algoritmos de
aprendizagem [Landset et al., 2015], ou para colmatar falhas ou inferir padroes de um determinado
estudo ou analise [Katal et al., 2013], a estes agregados volumosos de dados chamamos de Big Data.
A quantificacao de Big Data nunca foi um termo especıfico e nao quantifica com exatidao o valor
de dados que e necessario ter para um determinado dataset poder ser considerado BigData [Ward
and Barker, 2013]. Os dados considerados Big Data sao tao volumosos que as ferramentas que pro-
cessam, recebem e manipulam esta informacao nao o conseguem fazer num determinado espaco de
tempo toleravel e e por isso necessario arranjar metodos para tornar estas tarefas mais eficientes. A
ordem de grandeza e muitas vezes associada a capacidade computacional dos sistemas que proces-
sam a informacao, para um computador quantico que processa uma elevada quantidade de dados por
segundo 100GB de informacao nao sao significativos, porem para um simples computador de trabalho
1
o tempo de processamento da mesma informacao pode levar imenso tempo, ou ate nem mesmo ser
possıvel [Jacobs, 2009].
Uma das solucoes para a analise deste tipo de informacao e a visualizacao da mesma atraves de
representacoes que revelam padroes e caracterısticas sobre ela, a sua interpretacao pode ser reali-
zada desde um maior grau de detalhe ate a agregacoes que tornam a sua descricao mais abrangente.
Porem o facto deste tipo de dados ser bastante volumoso faz com que a descoberta de elementos
relevantes ou especıficos seja mais difıcil de realizar sendo que a configuracao dos dados (que podem
nao ser estruturados) tambem pode provocar uma analise mais complexa e morosa. Alem disso e
inconcebıvel representar toda a informacao de uma so vez visto que a resolucao dos dispositivos de
visualizacao e limitada, uma das solucoes para este problema passa por os sistemas realizarem uma
representacao dos dados com diferentes graus de detalhe. Por outro lado a capacidade cognitiva do
ser humano e tambem um problema uma vez que nao e possıvel analisar cada elemento com detalhe
num conjunto alargado, isto significa que por vezes e necessario realizar operacoes estatısticas para
resumir grupos de dados. O aumento das redes de informacao e dos sistemas distribuıdos elevam
este problema num novo nıvel em que e necessario acompanhar a evolucao dos elementos e vigiar o
seu comportamento. Muitas destas atividades necessitam de ser executadas em tempo real para que
haja intervencao humana caso seja necessario, os dados sao transmitidos atraves de fluxos (streams)
e enviados para interface que realiza a representacao necessaria para uma analise do utilizador. Seja
numa rede institucional ou num sistema peer-to-peer existem meios para monitorizar cada computador
e a sua interacao com todo o sistema. ClockView [Kintzel et al., 2011] e um exemplo de sistema para a
visualizacao em tempo real de dispositivos ligados a uma rede informatica.
Apesar de existirem bastantes sistemas de analise e monitorizacao de informacao muitos deles
estao limitados na quantidade de informacao que podem receber (ex. largura de banda, capacidade
de armazenamento) ou na forma como o utilizador pode explorar e interagir com os dados. Grande
parte destes sistemas tambem nao esta preparada para lidar com a alteracao brusca da informacao,
isto e, de como apresentar mudancas nos elementos ao utilizador de forma a que sejam implıcitas as
alteracoes que ocorreram e possıveis causas do mesmo. Para alem destes desafios cada interface e
criada com o intuito de resolver uma visualizacao de um domınio de dados especıfico, e e importante
que existam aplicacoes que sejam independentes e se possam adaptar a diferentes modelos.
De certo modo, a visualizacao de informacao em tempo real comporta desafios que muitas vezes
nao sao considerados em ambientes onde a informacao e estatica, este problema torna-se ainda maior
quando a quantidade de dados e elevada. A representacao da informacao pode ajudar o utilizador
a interpretar estes volumes generosos de dados utilizando idiomas de visualizacao que agregam e
tornam interpretacao global mais simples.
Geralmente a computacao destes metodos e realizada com toda a informacao dos datasets e o seu
processo e tao moroso quanto maior o numero de dados existentes (isto porque o processamento e
renderizacao de mais elementos leva mais tempo a ser realizada). Apos a geracao desta visao global
o utilizador e capaz de navegar por todos os caminhos existentes que foram criados pelas interfaces
e interagir com os elementos, uma vez que o seu processamento ja foi criado e nao existe um atraso
2
na sua apresentacao (ja nao ha necessidade de processar estes dados novamente). Em contrapartida
este tipo de abordagem nao e possıvel numa implementacao em tempo real.
A inclusao da caracterıstica do tempo real torna esta tarefa mais complexa no sentido em que nao
existe margem de tempo para que tratamento da informacao seja demorado uma vez que deve ser
visualizado no momento em que os dados sao recebidos pelo utilizador, sendo que os saltos abrup-
tos derivados a elevados debitos da informacao levam a que o utilizador prejudique a interpretacao
realizada aquando da sua visualizacao.
Para alem destes problemas e necessario compreender o domınio que esta a ser analisado para
ser possıvel prever eventuais erros ou anomalias na informacao e fazer com que os sistemas possam
adaptar-se a estas mudancas sem que o utilizador seja prejudicado por estas falhas, isto e, interprete
mal os resultados que estao a ser visualizados.
1.1 Objetivo
Com estas premissas surge o sistema VisMillion, uma interface de visualizacao de informacao com o
objetivo de
Estudar novas tecnicas de visualizacao de informacao capazes de representar grandes quan-
tidades de dados (”Big data”) em streaming, de modo a que o utilizador perceba o contexto
global da informacao a medida que novos pacotes vao sendo recebidos.
Para encontrar solucoes ira ser usado o paradigma da exploracao visual dos dados que segue o
princıpio Information Seeking Mantra: “Overview first, zoom and filter, then details-on-demand” [Sh-
neiderman, 1996], em que o utilizador recebe uma visao global do sistema e deteta os padroes que
pretende analisar, ao analisar estes padroes e importante que a vista geral do sistema nao seja per-
dida ou entao usar uma sub visualizacao de modo a que nao exista perda do contexto. Para adaptar
este paradigma a solucao ira existir uma visualizacao que agregue a informacao ao longo do tempo,
fazendo com que os dados mais recentes tenham mais detalhe (pontos recebidos) e a medida que o
tempo avanca torna estes elementos numa representacao diferente atraves de metodos estatısticos
(aglomerando os pontos). E tambem relevante apresentar dados que estejam foram do padrao natural
do dataset (outliers) e representa-los a parte para que possam ser analisados com mais detalhes pelo
utilizador.
E importante que o utilizador seja capaz de realizar uma analise a conjuntos de dados atraves da
visualizacao e interacao da interface consoante o tipo de grafico apresentado. Alem disso e tambem re-
levante que consiga comparar diferentes segmentos temporais (informacao mais antiga e mais recente)
e tambem manter o contexto dos dados previamente recebidos com os mais novos.
Este sistema e composto por modulos, cada um representa os dados de maneira diferente mas
e o seu proposito complementarem-se entre eles, a medida que a informacao percorre um eixo hori-
zontal esta vai sendo agregada em diferentes metodos (pelos diferentes modulos). O eixo horizontal
representa o tempo enquanto o eixo vertical representa o domınio da informacao representada.
O principal proposito deste sistema e ser capaz de responder eficientemente a disparidades de
3
debitos de dados, manter o contexto da informacao a medida que esta vai sendo recebida e anali-
sar tendencias. E tambem importante que sempre que existam alteracoes abruptas na informacao o
utilizador seja capaz de agir rapidamente a estas mudancas uma vez que podem vir a ter impactos sig-
nificativos nos sistemas em analise. Para alem destes aspetos a interface e desenhada e arquitetada
para conseguir suportar elevadas quantidades de dados por segundo.
Para testar a interface realizaram-se testes de usabilidade que permitiram compreender se os utili-
zadores percebem as mudancas de fluxo, agregacoes, tendencias, entre outros aspetos importantes na
visualizacao deste tipo de aplicacoes, com estes testes e possıvel inferir se o sistema e user-friendly e
responde aos requisitos enunciados, assim como ideias e sugestoes para posteriores implementacoes.
E tambem realizado testes de eficiencia para identificar quais os pontos de rotura e colocar um limite
do fluxo de informacao recebida.
1.2 Contribuicoes
Foi criado o sistema VisMillion, uma interface web de visualizacao de grandes quantidades de da-
dos em tempo real. Utilizando a biblioteca D3 esta aplicacao e composta por tres modulos (barchart,
linechart, scatterchart), cada uma representa a informacao de diferentes modos. Desde zonas de
informacao mais mais detalhada a agregacoes da informacao mais superficiais. O grafico e desen-
volvido para que nao exista perca do contexto da informacao e crie uma ligacao entre o processo de
transferencia dos dados pelos modulos. A interface tem tambem a capacidade de se adaptar ao tipo de
informacao que se quer visualizar atraves de opcoes na sua instanciacao. Posteriormente sera possıvel
criar outros modulos e interligar entre os ja existentes.
Para alem disso foi criado um Servidor para transmitir a informacao assim como uma aplicacao
para a geracao de datasets, onde e possıvel configurar tendencias, outliers e mudancas de fluxo em
determinados momentos, este programa ajuda na realizacao de testes e inferir padroes e tendencias
nos dados (repositorio 1).
1.3 Estrutura do Documento
A organizacao deste documento e realizada da seguinte maneira. Na seccao 2 e discutido o trabalho
ja realizado no tema. A seccao 2.1 e abordado as metodologias e requisitos para a representacao
de informacao. Posteriormente a seccao 3 apresenta a implementacao e estrutura do sistema, assim
como o funcionamento do backend e dos sistemas associados (gerador de datasets). Na seccao 4 e
descrita a resolucao da interface VisMillion em conjunto com os seus desafios e solucoes. De seguida
na seccao 5 sao descritos os testes de usabilidade e eficiencia assim como as conclusoes tiradas dos
mesmos. Finalmente no capıtulo 6 e realizada a conclusao do trabalho assim como o trabalho futuro
para melhorar o sistema.
1https://github.com/Portulinas/VisMillion, ultimo acesso 15 Outubro 2018
4
Capıtulo 2
Trabalho Relacionado
A solucao deste trabalho passa por compreender os diferentes metodos ja usados para a visualizacao
de grandes quantidades de dados em tempo real, de modo a compreender melhor o estado da arte
esta seccao e dividida em tres partes que tornam o estudo do tema mais abrangente. A primeira esta
relacionada com os metodos gerais de visualizacao de grandes quantidades de dados e em tempo
real, de seguida sao apresentadas algumas solucoes para o problema baseados em aplicacoes de
monitorizacao e visualizacao. No final sao apresentadas tecnicas gerais de reducao dimensional de
dados e agregacao.
2.1 Metodos Gerais de Visualizacao de BigData em tempo real
Esta seccao apresenta uma interpretacao geral das diferentes tecnicas de visualizacao mais usadas e
quais as suas implicacoes assim os metodos de filtragem e agregacao de dados.
2.1.1 Rethinking Visual Analytics for Streaming Data Applications
Neste trabalho [Crouser et al., 2017], os autores revelam que a analise de grandes quantidades de
informacao em tempo real trazem mais desafios nas visualizacoes e interacoes entre os dados e o
utilizador. Devido ao crescimento exponencial da IoT existe a necessidade de armazenar e visualizar
informacao de elevada dimensao num curto espaco de tempo, e por esse motivo o utilizador passa a
despender mais tempo e esforco cognitivo para analisar e avaliar dados.
A rececao de dados em tempo real tem muitas vezes picos de trafego impossibilitando assim a visualiza-
cao de todas as unidades de informacao, os programas ficam encarregues de realizar filtragens e
amostragens dos dados mais relevantes a cada situacao, podendo deixar sequelas na interpretacao
dos elementos.
O primeiro desafio enquadra-se com o conhecimento do domınio da representacao, chamada de
‘Orientacao’ passa por perceber quais sao os dados que sao expectaveis pelo sistema e de que forma
e que este se deve comportar, assim e possıvel compreender as possıveis alteracoes dos dados e quais
as implicacoes derivadas a essas mudancas. O segundo problema passa por reagir eficientemente as
5
mudancas do sistema que nao se enquadram nas alteracoes expectaveis do sistema e que violam
princıpios considerados na primeira fase (’Orientacao’), a este problema chamamos de ‘Reorientacao’.
De seguida deve sumarizar-se a informacao e realizar estatısticas de modo a conservar o historico
da informacao ja processada. Finalmente, um dos problemas mais complexos e tornar o sistema es-
calavel ao grande volume de dados a ser recebido simultaneamente, obrigando os algoritmos a realizar
aproximacoes (amostragens) de alguma informacao para que as visualizacoes nao percam eficiencia.
Segundo os autores existe um ciclo de visualizacao em stream que passa pela amostragem de
dados de diferentes fluxos, o processamento e destaque das alteracoes relevantes, e o mapeamento
da informacao para uma dimensao visual. Posteriormente a visualizacao e interpretada pelo utilizador
que tomando em conta o contexto da visualizacao interage com o sistema apresentado.
Em resumo este artigo revela as tecnicas e metodologias necessarias para a visualizacao de dados
em tempo real.
2.1.2 Information Visualization and Visual Data Mining
Este artigo fala sobre a visualizacao de enormes quantidades de dados e das tecnicas usadas para
explorar e analisar este tipo de informacao. Uma das grandes vantagens da exploracao visual de
dados e que e mais facil para um Humano interagir com dados inesperados do que um programa de
computador, alem disso visualizar informacao nao requer a compreensao de expressoes matematicas
complexas ou algoritmos estatısticos para tirar conclusoes de um conjunto de dados. Deste modo e
possıvel obter uma analise da informacao de uma forma mais rapida e com melhores resultados do que
com algoritmos de data mining. Em [Keim, 2002], os autores classificam as tecnicas de visualizacao
em tres tipos diferentes: Tecnica, Interatividade e Dados.
Os tipo de Tecnica utilizados que podem ser: Geometrically-Transformed Displays que ajudam
a encontrar transformacoes relevantes de datasets multi dimensionais, que incluem algoritmos de
exploracao estatıstica para o processamento da representacao da informacao. O Parallel Coordina-
tes que permite mapear k-dimensoes do espaco em 2 dimensoes usando k eixos equidistantes que
sao paralelos a um dos eixos de exibicao. O Iconic Displays que associam os atributos a ıcones. Os
Dense Pixel Displays que mapeiam cada elemento da dimensao a uma cor e agrupam os pixeis que
pertencem a mesma dimensao em areas adjacentes. E os Stacked Displays que apresentam particoes
de dados num modo hierarquico.
Os tipos de Interaccao permitem que o utilizador explore os dados, podendo realizar comparacoes
e relacionar multiplas visualizacoes. Dynamic Projections e uma tecnica que altera dinamicamente
as projecoes para explorar um dataset multidimensional. O metodo Interactive Filtering realiza o par-
ticionamento dos dados em segmentos mais pequenos assim consegue-se analisar detalhadamente
subseccoes de dados. O Interactive Zooming manipula grandes quantidades de informacao de modo
a poder comprimir ou ajustar os dados consoante o utilizador deseje no ecra, apresentando com mais
ou menos detalhes a informacao. Interactive Distortion preserva a visao global dos dados enquanto o
utilizador realiza uma analise aprofundada de determinados objetos. Interactive Linking and Brushing
6
interliga diferentes metodos de visualizacao existindo uma correlacao entre todos.
Os tipos de Dados consistem em elementos compostos por varios numeros de variaveis. Essas
dimensoes podem ser One-dimensional em que cada elemento tem uma dimensao (geralmente dados
temporais). Two-dimensional que tem duas dimensoes distintas (por exemplo dados geograficos x/y).
Multidimensional consiste em dados com mais de tres atributos e nao permitem visualizacoes tao sim-
ples. Text and Hypertext texto geralmente encontrado na web e a maioria dos idiomas de visualizacao
nao o consegue representar. Hierarchies and Graphs sao outro tipo de dados que interligam os ele-
mentos entre si. E os Algorithms and Software representam informacao de algoritmos e programas
para representar fluxos e entendimento do codigo.
Em suma este artigo refere um conjunto de tecnicas de visualizacao e interacao na visualizacao de
grandes conjuntos de dados assim como o tipo de informacao que pode ser representada, na figura 2.1
o grafico correlaciona estes tres diferentes tipos.
Figura 2.1: Correlacao entre os diferentes tipos, por [Keim, 2002]
2.2 Solucoes de Visualizacao de dados em larga escala e em tempo
real
De seguida sao apresentados alguns trabalhos relacionados com o domınio do problema da visualizacao
em tempo real de enormes quantidades de informacao com o objetivo de perceber quais as principais
metodologias e dificuldades na implementacao das solucoes.
7
2.2.1 Towards an Adaptive Framework for Real-Time Visualization of Streaming
Big Data
Este poster [Khan et al., 2017] propoe uma arquitetura de visualizacao e interacao de dados em tempo
real resistente ao volume e fluxo da informacao. Esta framework deve fazer com que seja possıvel
detetar anomalias relevantes no sistema em tempo real, destacando as entidades que merecem uma
analise mais detalhada por parte do utilizador e tambem escolher os idiomas de visualizacao ideais
para cada momento do sistema. E importante que a alteracao de visualizacoes seja feita em transicoes
suaves para que o utilizador nao perca o contexto da informacao recebida. De modo a tornar esta abor-
dagem inovadora sao focados 3 aspetos importantes. A agregacao dos dados e reducao dimensional
na camada de acesso e feita atraves da ferramenta da Pentaho1 em conjunto com Apache Spark2 que
permite a analise e processamento da informacao em tempo real. Finalmente com a ajuda do motor
de recomendacao e possıvel a introducao de novos modelos de visualizacao mais apropriados a gran-
des quantidades de dados em tempo real adaptados ao tipo de dados que estao a ser transmitidos. A
transicao entre diferentes mudancas drasticas de informacao e um dos problemas a resolver uma vez
que nao existe nenhuma maneira automatica de realizar uma mudanca de visualizacao sem que o uti-
lizador perca o contexto da informacao que esta a visualizar, a alternativa proposta passar por realizar
transicoes suaves recorrendo a idiomas de visualizacao intermedios e de forma gradual ao longo do
tempo.
2.2.2 Real-Time Visual Analytics for Event Data Streams
Os autores apresentam uma solucao de visualizacao chamada Event Visualizer [Fischer et al., 2012]
que consiste em adquirir, processar, analisar e visualizar eventos dinamicos em tempo real. Para
resolver o problema da visualizacao em tempo real, sao propostas 3 contribuicoes: Inicialmente criar
uma arquitetura de analise e processamento de eventos que suporta aplicacoes de visualizacao em
tempo real, construir um sistema que suporte visualizacoes em tempo real e com historico de eventos,
e por ultimo um cronograma dinamico de modo a interagir diretamente com multiplos fluxos de dados e
visualizacoes de eventos altamente concorrentes.
Para existir flexibilidade no sistema foram criados alguns modulos, o Event Service & Analyzer re-
cebe e regista os eventos recebidos pelos diferentes fluxos e realiza o pre-processamento desses
eventos tornando-os mais genericos e que possam ser todos interpretados da mesma forma. Para re-
cuperar dados omitidos um analisador faz a procura e classificacao da informacao em falta, esta tarefa
e realizada por processos paralelos e distribuıdos reduzindo a carga computacional. O modulo Event
Visualizer e a interface e categoriza os eventos em tipos para estes poderem ser fixados em diferentes
barras horizontais com diferente largura de acordo com o seu tempo de vida (relaxed timeline). Existem
multiplas relaxed timelines (fig. 2.2) cada uma e especıfica a um fluxo ou categoria em particular. Cada
evento e representado com uma cor de acordo com a sua importancia. Seguindo a linha temporal os
1https://www.hitachivantara.com/go/pentaho.html, ultimo acesso 15 Outubro 20182http://spark.apache.org/, ultimo acesso 15 Outubro 2018
8
eventos a esquerda sao os mais antigos enquanto os da direita correspondem aos mais recentes.
Figura 2.2: Relaxed Timelines, por [Fischer et al., 2012]
Para a interacao o sistema utiliza Pan & Zoom possibilitando a investigacao mais detalhada em areas
especıficas de cada evento, a mudanca entre eventos antigos e mais recentes e feita com transicoes
suaves. Para evitar um grande aglomerado de eventos a aplicacao determina um limite por intervalo,
removendo os de menor relevancia atraves de um analisador automatico.
As vantagens desta solucao passam pela possibilidade de relacionar eventos antigos com os mais re-
centes, combinar os algoritmos de classificacao e pontuacao com anomalias em eventos e a visualizacao
dos mesmos, e tornar a troca entre o historico de eventos e os eventos mais recentes mais suave fa-
zendo com que o utilizador nao perca o contexto da informacao.
2.2.3 I2 - Interactive Real-Time Visualization for Streaming Data
I2 [Traub et al., 2017] e um sistema interativo que comanda aplicacoes de cluster e as suas respetivas
visualizacoes. O nome (I2) enfatiza dois aspetos relevantes de interatividade do sistema, a interativi-
dade atraves de modificacao de codigo e a interacao atraves da interface assim e possıvel diminuir a
carga de trabalho dos clusters e tambem da interface de visualizacao.
Geralmente em situacoes de Big Data a representacao de dados em Time Series e tao volumosa
que nao existe capacidade de representar cada elemento por pixel, a utilizacao do algoritmo M4 [Jugel
et al., 2014] permite reduzir os dados para agrupar 4 valores por pixel sem perdas comparado com os
graficos originais. Dado o contexto do problema e necessario manipular este algoritmo para suportar o
processamento destes dados em tempo real. Existem problemas como os dados serem recebidos fora
de ordem, ou existir uma lacuna entre o timestamp do evento e do tempo do seu processamento que
leva a criacao de um pipeline que realiza a compressao dos dados recebidos.
O backend da aplicacao funciona com base na aplicacao Apache Flink3 que e capaz de processar
grandes fluxos de dados em paralelo, o frontend funciona com a ferramenta Apache Zeppelin4 mo-
dificada para permitir a reducao dimensional automatica dos dados dependendo dos parametros da
visualizacao. Estes sistemas comunicam de maneira a que quando o utilizador realiza alteracoes na
3https://flink.apache.org/, ultimo acesso 15 Outubro 20184https://zeppelin.apache.org/, ultimo acesso 15 Outubro 2018
9
visualizacao o Flink seja notificado e possa fornecer os dados pedidos.
O grande benefıcio desta solucao e que o utilizador pode especificar em tempo real quais as alteracoes
que quer fazer na visualizacao e altera-las sem ter que reiniciar o sistema, dado que as aplicacoes
cluster se adaptam a visualizacao reduzindo o numero de dados a serem transmitidos e sem perdas
na sua qualidade.
2.2.4 Real-time large-scale big data networks analytics and visualization archi-
tecture
Os autores deste poster propoem o sistema X-SimViz [Chopade et al., 2015], uma aplicacao de visualizacao
em tempo real de redes complexas de larga escala. Um dos grandes problemas apresentados e o au-
mento da quantidade de informacao disponıvel tornando a interacao e a visualizacao dos dados um
processo complexo e que de certa forma necessita de outra abordagem na sua implementacaoExistem
4 categorias em que o sistema esta desenhado, sao elas a Interface que conecta o utilizador com
o sistema, o Visualizador que converte os dados em informacao visual, os Dados que o utilizador
quer visualizar e a Exibicao que consiste na ligacao entre o utilizador e a interface. Estas catego-
rias interligam-se entre si dado que o utilizador interage com a interface que por sua vez determina
as opcoes para o visualizador, este processa os dados e no final os resultados sao exibidos para o
utilizador.
Esta ferramenta utiliza um sistema de Interface Inteligente que permite adaptar-se ao utilizador con-
forme as suas necessidades, utilizando diferentes nıveis de interacao de acordo com as capacidades
de cada utilizador. Existe tambem um sistema de Visualizacao Inteligente que trabalha cooperativa-
mente com o sistema de Interface Inteligente e permite que este determine qual e o melhor idioma de
visualizacao a ser apresentado, facilitando a compreensao dos dados.
Para alem disso a Visualization Knowledge Base que guarda toda a informacao sobre a visualizacao,
graficos, percecoes visuais, mapeamentos de visualizacao, ferramentas de visualizacao e exemplos de
tecnicas de visualizacao que ajuda os sistemas anteriores a tomar decisoes e a apresentar os dados
da melhor maneira possıvel.
Este sistema permite tecnicas de processamento paralelo que melhoram a performance global da
aplicacao. Este processo consiste na particao dinamica de processos baseado na velocidade de rede,
capacidades computacionais e localizacao dos dados de modo a coordenar multiplas tarefas e realizar
analise automatica de dados.
Em suma esta aplicacao permite que o sistema se adapte a cada tipo de utilizador e fornece de
maneira simples e de facil compreensao os dados propostos a visualizacao.
2.2.5 A Framework for Monitoring and Measuring a Large-Scale Distributed Sys-
tem in Real Time
Os autores propoem uma solucao de monitorizacao de sistemas complexos [Zhan et al., 2013], como
por exemplo sistemas P2P. A arquitetura e composta por quatro componentes: End Hosts, Coordina-
10
tor , Feedback Servers e Monitoring Platform. Os End Hosts fazem medidas periodicas do sistema
e enviam essa informacao para o Coordinator que por sua vez agrega todas as mensagens recebidas
e envia para os Feedback Servers, por fim a Monitoring Platform contacta os Feedback Servers
periodicamente para adquirir as informacoes agregadas disponıveis, de seguida analisa e apresenta os
resultados em tempo real. A Monitoring Platform analisa a informacao recebida e apresenta diferentes
visualizacoes aos administradores do sistema.
Sobre a visualizacao dos dados, a plataforma fornece diferentes tipos de views apresentando as
medidas em diferentes formas. Estas visualizacoes sao geradas de acordo com as metricas dos dados
e com os interesses dos administradores do sistema, por exemplo localizacao geografica, distribuicao
das estatısticas, alteracoes ao longo do tempo.
No contexto da solucao sao apresentadas quatro visualizacoes para a monitorizacao do sistema
P2P (fig. 2.3), um Map View que indica a localizacao dos peers, District View similar a anterior mas
que combina com outras visualizacoes, Histogram View que apresenta os dados em formato de his-
togramas, ajudando os administradores a compreender as distribuicoes das performances para uma
dada metrica, e a Timeline View que apresenta os resultados num domınio temporal.
Figura 2.3: Visualizacoes do sistema de monitorizacao, por [Zhan et al., 2013]
Dado que existem muitos modulos por onde os dados passam ate chegarem realmente a inter-
face existe um atraso (derivado ao tempo de transmissao e o seu processamento) que provoca a
visualizacao de dados em tempo real nao ser completamente em “tempo real”. A vantagem deste
sistema e que e pode suportar milhoes de peers dado que a rececao das medidas nao esta centrada
num unico ponto.
2.2.6 LiveRAC: Interactive Visual Exploration of System Management Time Se-
ries Data
LiveRAC [McLachlan et al., 2008] e um sistema de visualizacao dados temporais com elevada densi-
dade de informacao, permite a comparacao lado a lado de diferentes nıveis de detalhe dado um conjunto
de dados e parametros. Criado para permitir a analise de sistemas de gestao em grande escala (redes
complexas, monitorizacao de datacenters, etc.). Sao utilizadas tecnicas como o Semantic Zooming,
onde os objetos se adaptam a sua representacao de acordo com a dimensao do ecra. E o Stretch and
Squish Navigation que promove a expansao de determinadas areas de visualizacao comprimindo as
restantes.
As principais limitacoes nas solucoes de sistemas de monitorizacao em larga escala e a falta de
11
visualizacoes intermedias, escondendo detalhes importantes onde a unica forma de os encontrar e
”escavar”em outras visualizacoes, perdendo o contexto das principais e impedindo o utilizador de fazer
comparacoes entre elas. Outra falha destes sistemas e a utilizacao de regras e tecnicas de aprendi-
zagem para descobrir problemas, levando a um elevado numero de falsos alarmes que conduzem os
utilizadores a nao confiar na sua fiabilidade.
As representacoes mais usadas no sistema sao graficos de barras e temporais, utilizando cores de
acordo com a importancia da informacao. As visualizacoes sao feitas lado a lado (fig. 2.4) uma vez que
e mais facil do que relembrar uma view que ja nao esteja a ser apresentada, as escalas dos graficos
sao preservadas e iguais em todas as views facilitando assim a tarefa de comparacao.
Figura 2.4: Visao global do sistema LiveRac e interacao, por [McLachlan et al., 2008]
Um dos princıpios da visualizacao e ordenar espacialmente as entidades para poder relacionar
parametros de diferentes grupos, assim na matriz de visualizacao do sistema cada linha representa um
grupo e as colunas representam os parametros, facilitando assim a ordenacao tanto de linhas como
colunas. Outro dos princıpios do sistema e tornar as views eficazes e criando uma ligacao especıfica
entre elas.
Esta solucao permite aos utilizadores analisarem multiplas entidades de informacao e correlacio-
nar esses dados entre si inferindo anomalias nos sistemas que muitas vezes nao sao detetados. Esta
aplicacao permite apresentar um grande numero de dispositivos e parametros e deixar que o utiliza-
dor interaja e descubra informacao que normalmente nao e capaz de encontrar com as ferramentas
existentes.
2.2.7 An Online Visualization System for Streaming Log Data of Computing
Clusters
Este sistema [Xia et al., 2013] realiza uma visualizacao integrada com duas fases de processamento
de dados em streaming de registos de informacao de clusters onde a principal dificuldade e a hetero-
genidade dos dados e o do seu fluxo proveniente de diferentes fontes.
Esta aplicacao e responsavel pelo processamento dos dados e pela sua visualizacao, na fase de
processamento a informacao e uniformizada e guardada numa base de dados estruturada e estavel.
Na visualizacao existem multiplos idiomas tanto para os tipos de dados hierarquicos como sequenciais.
O processamento e representacao e realizado isoladamente tornando o sistema global mais eficiente.
12
Depois de os dados serem processados pelo sistema de processamento, o servidor de visualizacao
acede a base de dados onde estao os dados uniformizados e apresenta os resultados.
A parte da visualizacao fornece informacoes sobre as maquinas em tempo real e deteta eventos
crıticos, as tecnicas utilizam estatıstica com o historico de dados existente e a informacao atual para
gerar estas representacoes, assim o utilizador consegue monitorizar e responder eficazmente a falhas
nos clusters.
Existem duas tarefas de visualizacao, a Cluster Metric View que fornece uma visao global do
conjunto de clusters, e e composta por tres paineis, Parallel Coordinate Plot, o Selection Widget (que
agrupa ou isola diferentes maquinas), o Barcharts e o Expandable Time Sequence Chart que utiliza
um radar para metricas em tempo real e um grafico temporal para apresentar o historico dos comporta-
mentos dos clusters mostrados no radar. Para fornecer uma representacao da hierarquia dos clusters e
dos nıveis associados a arquitectura a Cluster Insight View (fig. 2.5) utiliza um Time Sequence Graph
que apresenta a hierarquia estrutura dos nos. Na mesma visualizacao e usado um TreeMap indicando
uma visao global do desempenho de todos os nos.
Figura 2.5: Cluster Insight View, por [Xia et al., 2013]
Este sistema permite que apenas os dados mais importantes sejam apresentados, evitando que
informacao irrelevante distorca a interpretacao do utilizador, a informacao mais relevante e identificada
eficientemente. O facto da aplicacao utilizar apenas duas visualizacoes com multiplas tecnicas de
apresentacao ajuda o analista a nao perder o contexto do sistema ao interagir com ele.
2.2.8 Trend Analysis in Large Timeseries of High-Throughput Screening Data
Using a Distortion-Oriented Lens with Semantic Zooming
Este poster [Brodbeck and Girardin, 2003] apresenta uma solucao de visualizacao para a analise de
tendencias em dados em larga escala, sumarizando os dados no espaco e tempo atraves de distorcao
ampliada e zoom semantico. TrendDisplay resolve os problemas de representacao e avaliacao de dados
13
que sao dependentes do tempo, assim como a representacao das tendencias dos dados e variacao da
escala do tempo.
A interface e composta por dois paineis, o principal que apresenta os valores detalhados e o se-
cundario apresenta valores derivados. Ambos os paineis partilham a mesma escala no eixo horizontal.
Para suportar um numero elevado de dados e fornecer detalhes em diferentes escalas de tempo , e
usado a tecnica de ampliacao orientada a distorcao permitindo que o utilizador “amplifique” elementos
e manipule a sua posicao adquirindo uma area de interesse de um intervalo desejado (fig. 2.6). A
representacao dos valores derivados e estatısticas e utilizado o Zoom Semantico, existem diferentes
idiomas desde, distribuicao de densidades, thin box plots, box plots, outliers, e histogramas. Ambos
os eixos podem ser ampliados atraves dos sliders, e todas as transicoes entre as visualizacoes sao
acompanhadas com transicoes suaves para manter o contexto.
Figura 2.6: Diferentes nıveis de detalhe disponıveis no sistema TrendDisplay, por [Brodbeck and Girar-din, 2003]
Caso existam multiplas estatısticas a serem apresentadas ao mesmo tempo, estas sao apresenta-
das no mesmo grafico mas com camadas diferentes e cada uma pode ser ajustada independentemente,
tambem pode ser definido um valor maximo e mınimo de modo a nao serem visualizadas estatısticas
que nao facam parte do estudo alvo. Para o utilizador conseguir interagir e estudar melhor os dados
apresentados e possıvel associar etiquetas, ligar e selecionar diferentes elementos.
Esta solucao apresenta tecnicas de visualizacao interessantes do ponto de vista da informacao em
larga escala e soluciona alguns aspetos importantes no contexto da visualizacao para que nao exista
perda de contexto nas transicoes entre idiomas.
2.2.9 BinX: Dynamic Exploration of Time Series Datasets Across Aggregation
Levels
A ferramenta BinX [Berry and Munzner, 2004] fornece uma visualizacao dinamica de datasets com
series temporais longas, o utilizador controla a agregacao de dados, que e gerida por diferentes tecnicas
de visualizacao. As tarefas dos utilizadores na visualizacao passam por monitorizar diferentes perıodos
14
de tempo, diferentes nıveis de detalhe e encontrar semelhancas e pontos interessantes no conjunto de
dados.
A Time Series dinamica apresenta os dados como uma linha num determinado nıvel de agregacao
que pode ser controlado, assim como a escala do eixo temporal. A informacao e apresentada na ıntegra
no ecra, o eixo horizontal apresenta a totalidade do dataset, e o nıvel de agregacao e controlado pelo
utilizador de modo a que um numero pequeno de caixas forneca uma visao global encurtando o espaco
entre elementos. O aumento do numero de caixas (menor agregacao) faz o oposto, mostrando maior
detalhes sobre a informacao. As mudancas de nıveis de agregacao e alteracoes de intervalos de tempo
sao realizadas por transicoes suaves. E possıvel selecionar perıodos de tempo que despoletam uma
timebox, permitindo a visualizacao pormenorizada do nıvel de agregacao selecionado, assim como os
valores maximos, mınimos e o desvio padrao de cada elemento.
Na interface existem dois componentes de visualizacao (fig. 2.7) que realizam a mesma tarefas e
que podem ser ligados entre si, cada um tem um foco e nıvel de agregacao diferente. Caso exista
ligacao entre ambos os componentes tudo o que o utilizador selecionar ou marcar e apresentado
de forma a relacionar os dois elementos. Apesar disso cada componente tem o seu proprio nıvel
de agregacao ajundado o utilizador a verificar detalhes importantes de determinados elementos e ao
mesmo tempo ter uma visao global de todo o conjunto de dados.
Figura 2.7: Componentes de visualizacao interligados BinX, por [Berry and Munzner, 2004]
O sistema tambem oferece um mecanismo de clustering que classifica os conjuntos de dados. Estas
classificacoes sao apresentadas diretamente no grafico junto ao ponto a que correspondem, existindo
tambem uma janela que apresenta um grafico com os valores de todos os grupos.
15
O modo como este sistema dispoe a informacao facilita a compreensao da informacao por parte
do utilizador, uma vez que as opcoes de navegacao permitem uma fluidez entre as janelas e utilizam
transicoes suaves mantendo o foco em pontos interessantes. A visualizacao da informacao em dois
contextos diferentes e util no sentido em que o utilizador pode ter uma visao global do sistema ao
mesmo tempo que analisa com mais detalhe outro tipo de informacao relevante.
2.2.10 imMens: Real-time Visual Querying of Big Data
Este artigo descreve o sistema imMens [Liu et al., 2013], uma interface web de visualizacao em tempo
real de Big Data que permite a interacao com multiplos idiomas. Usando WebGL e Javascript a inter-
face utiliza o processamento grafico dos dispositivos para realizar a renderizacao e processamento da
informacao. A representacao dos dados fica a cargo de Binned Plots e sao processados os Multivariate
data tiles que correspondem a projecoes materializadas de bases de dados [Gupta and Mumick, 1999],
transformando os datasets em projecoes multi dimensionais que a aplicacao posteriormente necessita
para realizar a tecnica de brushing & linking.
O princıpio de que a escalabilidade interativa e percetual deve ser limitada pela resolucao dos dados
visualizados e nao pelo seu tamanho e chave para a escolha dos metodos de filtragem, agregacao e
modelacao dos dados. A visualizacao e focada em Binned Aggregation como a principal estrategia de
agregacao de dados, uma vez que permite a visualizacao dos valores globais (ex. padroes) e locais (ex.
outliers). Sao considerados quatro tipos de dados que podem ser utilizados neste sistema: ordinais,
numericos, temporais e geograficos. Os graficos apresentados podem ser de uma ou duas dimensoes,
a cor e utilizada para codificar a densidade de informacao e outros metodos como textura ou tamanho
sao evitados para nao interferir com a interpretacao do utilizador.
A interacao dos graficos e realizada atraves do metodo de brushing & linking, utilizando o metodo de
binned aggregation o sistema efetua Data Cube Queries que contem o nıvel mais baixo de resolucao
dos dados, estes resultados sao posteriormente transformados em data tiles e representados ao utili-
zador consoante a interacao que tem com o sistema.
Este sistema tira vantagem do GPU para realizar a consulta e processamento de grandes quantida-
des de informacao, tornando a tarefa da interacao e procura de informacao do utilizador mais facil uma
vez que os resultados sao imediatos apesar do nıvel de processamento exigido.
2.3 Metodos de reducao e amostragem de dados
Nesta seccao sao apresentadas algumas solucoes para a reducao e amostragem de informacao de
modo a colmatar as dificuldades no processamento de dados em larga escala.
2.3.1 Sampling Techniques to Improve Big Data Exploration
A exploracao de grandes datasets requer um tratamento dos dados para gerar uma quantidade pequena
e representativa de informacao que possa ser facilmente exibida. Este trabalho revela algumas tarefas
16
para facilitar a geracao destes dados.
A exploracao de informacao inclui tarefas de criacao de graficos, estimativa de estatısticas, alteracao
e procura de anomalias, porem estes metodos nem sempre sao possıveis de analisar em grandes
quantidades de dados ou requerem muitas horas a serem analisados pelos utilizadores, desse modo
a criacao de amostras de informacao possibilita que esta exploracao seja feita eficientemente e em
menos tempo. A maioria das amostragens adquiridas pelos analistas que estudam Big Data sao obtidas
atraves de escolha aleatoria.
As tecnicas de amostragem descritas neste artigo [Rojas et al., 2017] sao Query By Committee
(QBC), Uncertainty Sampling e Density Sampling. A amostragem aleatoria peca no facto de ser
difıcil detetar anomalias nos dados, tecnicas alternativas proporcionam que a selecao seja pre definida
ajudando os utilizadores a focarem-se nos pontos de maior interesse.
Os resultados do estudo indicam que os utilizadores se sentem mais confiantes sobre as suas
analises usando Density Sampling uma vez que este metodo filtra os pontos mais anomalos e utiliza os
dados que estao mais agrupados num dataset, tornando os dados menos homogeneos. O metodo QBC
por outro lado pode servir como um complemento ao Density Sampling dado que foca agrupamentos
mais especıficos e com um elevado crescimento. O Uncertainty Sampling funciona como uma especie
de complemento ao sampling identificando os outliers dos datasets.
Com este estudo e possıvel concluir que utilizar apenas uma tecnica de de amostragem nao e sufi-
ciente para gerar resultados e exploracoes adequadas para o estudo de grandes datasets, e importante
complementar as diferentes tecnicas.
2.3.2 CEDARS: Combined Exploratory Data Analysis Recommender System
A solucao proposta e um sistema de recomendacao de que ajuda na analise e exploracao de informacao
dos utilizadores [Livingston et al., 2015], criando relacoes entre as variaveis para tirar conclusoes so-
bre o dataset em estudo. Este metodo ajuda os utilizadores a tomar decisoes sobre o domınio da
informacao, para isso sao utilizadas regras gerais de analise com as preferencias dos analistas.
O objetivo desta solucao e proporcionar uma ferramenta que consiga fazer analise de datasets do
mesmo modo que um analista especialista faria, permitindo que as analises a este sistema possam ser
feitas mais pormenorizadamente pelos analistas ou por outros.
O sistema esta organizado em agentes que realizam analises baseadas em regras na informacao,
ou com a interacao que o utilizador faz. Um servidor gere a informacao que e guardada numa base de
dados assim como as potenciais operacoes e os interesses dos utilizadores. As analises sao recomen-
dadas com base na descoberta de operacoes e variaveis de interesse, caso nao exista esta descoberta,
e pedido aos agentes para as gerarem.
A interface contem tres visualizacoes, uma permite que o utilizador realize pedidos de operacoes,
outra lista as operacoes pendentes e a ultima apresenta as operacoes disponıveis (ordenadas por
interesse). O utilizador pode alterar a ordem desta lista, informando o servidor da nova ordenacao.
17
Artigo TempoReal
LargaEscala
Reducao Di-mensional
Tecnicas de Visualizacao Interatividade Tecnicas Relevantes
[Khan et al.,2017]
Sim Sim Sim Sim Motor de recomendacao;Transicoes Suaves
[Fischeret al., 2012]
Sim Sim Nao Relaxed Timelines Cronograma Dinamico
[Traub et al.,2017]
Sim Sim Sim Sim Utiliza algoritmo M4
[Chopadeet al., 2015]
Sim Sim Nao Interface Inteligente
[Chopadeet al., 2015]
Sim Sim Sim Mapas, Histogramas,Timeline, District Views Nao
[McLachlanet al., 2008]
Nao Sim Nao Semantic ZoomingLinkedViews
Stretch and Squish Navi-gation
[Xia et al.,2013]
Sim Sim Sim
Parallel Coordinate Plot,Selection Widget,Treemap, Time sequencechart
Sim
[Brodbeckand Girar-din, 2003]
Nao Sim NaoDistortion OrientedMagnification,Semantic Zooming
Etiquetar, selecionar ligar Transicoes Suaves
[Berry andMunzner,2004]
Nao Nao Sim Transicoes Suaves
[Liu et al.,2013]
Sim Sim Sim Scatterchart, Heatmaps,etc.
Brushing & Linking Multivariate data tiles,Binned Aggregation
Tabela 2.1: Resumo entre os trabalhos analisados
2.4 Discussao
Apos a analise dos diferentes documentos podemos obter uma visao global sobre o panorama atual
o estado da arte relativamente a visualizacao de dados em tempo real de grandes quantidades de
informacao.
A tabela 2.1 apresenta os artigos mencionados na seccao 2.2 assim como os criterios fundamentais
para a compreensao e interpretacao do problema e posterior solucao. O criterio Tempo Real e impor-
tante pois o sistema tera de implementar uma solucao que seja capaz de receber um fluxo de dados
ao inves de apenas suportar um conjunto de dados estatico e predefinido. A coluna de Larga Escala
menciona quais as solucoes que sao capazes de realizar a visualizacao de grandes quantidades de
informacao.
A coluna de Reducao Dimensional e agregacao de dados refere se existe ou nao a preocupacao/necessidade
de realizar a simplificacao/reducao de dados, importante devido ao facto de se apresentarem grandes
quantidades de dados.
Na coluna de tecnicas de visualizacao sao referidas as tecnicas usadas para a apresentacao da
informacao, e na interatividade os metodos que existem para que o utilizador possa interagir com o
sistema. Foi adicionada uma coluna extra com tecnicas relevantes que indica aspetos sao considerados
relevantes na implementacao dos sistemas.
Os principais metodos de resolucao do problema passam por realizar uma simplificacao ou reducao
da informacao, a maior parte dos artigos da tabela realiza este processo para obter um conjunto de
18
dados de dimensao menor mas que ao mesmo tempo revele todas as caracterısticas importantes da
informacao a analisar, existem multiplas tecnicas para realizar esta operacao, atraves de regras gerais,
processos de aprendizagem, recolha aleatoria de amostras. Cada um destes metodos tem vantagens
e desvantagens e e preciso jogar com cada um deles encontrando a solucao perfeita, se por um lado as
regras gerais obtem um conjunto de dados relevantes por outro podem nao ser beneficas para novos
tipos de informacao que surjam e para o qual o sistema nao esta preparado para lidar.
Alem destas tecnicas, e necessario realizar uma limpeza de dados, dado que por vezes a informacao
que e recebida pelos programas de visualizacao tem problemas a interpretar dados nao expectaveis
pelo sistema e que podem prejudicar a analise do utilizador.
A rececao de grandes quantidades de informacao implica que os sistemas sejam capazes de reagir
a picos que nem todos os sistemas estao aptos a realizar, por esse motivo aquando da realizacao da
solucao e necessario ter em conta o suporte que ira existir para situacoes de elevado fluxo de dados.
Uma das principais limitacoes da analise de largos conjuntos de informacao e o facto de nao exis-
tirem recursos nos dispositivos de visualizacao para dispor toda a informacao disponıvel uma vez que
o espaco e limitado pelos ecras. E por esta razao que muitas das solucoes apresentadas agregam e
simplificam a informacao que e recebida.
Existem tambem dificuldades em conciliar a visualizacao de dados em tempo real com a quantidade
de informacao a receber, podemos concluir isto observando a tabela uma vez que existem sistemas
que nao suportam ambos os componentes em simultaneo, uma das maneiras de simplificar este pro-
cesso e dividir o sistema em duas componentes essenciais, na primeira e realizado o processamento
da informacao e so depois e que a informacao chega a camada de visualizacao, criando uma inde-
pendencia entre os dois componentes que apenas interagem de acordo com os requisitos do utilizador
e que modelam a informacao que daı ira ser processada, alem disso a camada de processamento
transmite os dados que irao ser apresentados pela camada de visualizacao. Uma das vantagens desta
abordagem e que os programas consomem muito menos processamento e permitem ao utilizador focar-
se apenas no aspeto da visualizacao.
Guardar um historico de estatısticas da informacao recebida e tambem um dos metodos que facili-
tam a interacao e visualizacao uma vez que e possıvel criar algoritmos que revelem tipos de visualizacao
mais interessantes de acordo com o conjunto de dados que esta a ser transmitido num dado momento,
para isso podem ser utilizados metodos de aprendizagem ou sistemas baseados em regras.
Maior parte dos sistemas analisados anteriormente utilizam diferentes tecnicas de visualizacao que
em conjunto tentam chegar num unico objetivo de analise de determinado tipo de informacao, todos
eles enfatizam a necessidade de realizar as mudancas de visualizacao de forma suave para que o
utilizador nao perca o contexto global do sistema e possa comparar diferentes pontos de dados sem
que seja confundido pelas alteracoes abruptas da interface.
Encontrar formas de realizar estas transicoes de maneira suave e um dos aspetos mais importantes
e crucial uma vez que nao serve de nada ter um sistema que possa ser eficaz do ponto de vista da
visualizacao se nao ajudar o utilizador a realizar as tarefas para o qual esta a utilizar o sistema.
Em relacao a interatividade com o sistema existem diferentes metodos a ser utilizados, a maior parte
19
utiliza aplicacoes de mudanca de detalhe da informacao para que o utilizador consiga visualizar com
mais pormenor determinados elementos da informacao, porem existe sempre a preocupacao de deixar
o utilizador alerta em relacao aos dados que estao a ser recebidos em tempo real. A maior parte dos
artigos analisados utilizam tecnicas onde este ponto nao e muito abordado e deve haver a preocupacao
de considerar este problema.
Deste modo e compreensıvel a necessidade de encontrar uma solucao que possa ser viavel do
ponto de vista da visualizacao da BigData e que ao mesmo tempo o consiga fazer em tempo real, alem
disso deve ajudar os analistas da informacao a encontrar pontos de interesse nos conjuntos de dados
sem tornar a interacao e compreensao do sistema morosa e complicada.
20
Capıtulo 3
Servidor - Streammer
A estrutura tomada para a realizacao do projecto e baseada numa arquitectura cliente-servidor onde o
sistema VisMillion e o cliente que funciona num ambiente web e o servidor (Streammer ) que envia os
pacotes de dados atraves de websockets para o sistema.
Neste capıtulo e abordada a implementacao do Backend. Dado que para existir a visualizacao de
dados e necessario que exista uma entidade que envie a informacao para a interface. Houve a ne-
cessidade de criar um subsistema que fosse capaz de transmitir a informacao para o browser onde
esta a correr o sistema VisMillion. A este sistema que realiza o envio da informacao chamamos Stre-
ammer, escrito na linguagem python este programa serve de suporte o consumo de informacao de
determinados datasets e seu posterior envio. Esta implementacao nao comporta ferramentas de su-
porte a Big Data, uma vez que o foco deste trabalho e a Visualizacao, a abordagem a este aspecto e
de uma complexidade tal que poderia ser realizada num outro trabalho. A implementacao deste servico
e fundamentalmente essencial para testar a plataforma VisMillion.
De seguida e tambem explicado como funciona a comunicacao entre o cliente e o servidor e tambem
os metodos utilizados para a extracao dos diferentes datasets utilizados na implementacao. No fim
existe tambem uma explicacao de uma extensao necessaria ao servidor para a realizacao dos testes
de usabilidade.
3.1 Estrutura
Dado que o foco do trabalho e a visualizacao optou-se por realizar uma arquitetura fat-client, isto implica
que o cliente (interface) e responsavel por realizar as operacoes de processamento da informacao.
Uma das principais razoes para escolher este formato foi devido ao maior foco do trabalho na parte
do cliente e tambem porque muito do processamento envolvido dependia das especificacoes tomadas
pelo utilizador no arranque da interface uma vez que cada modulo (seccao 4.3.2) pode processar a
informacao de maneiras diferentes.
A implementacao deste prototipo passa pela criacao de uma aplicacao web, foi por isso necessario
pesquisar quais seriam as melhores maneiras de transmitir grandes quantidades de dados sem que
21
Figura 3.1: a) WebSockets b) HTTP Long Polling , por [Pimentel and Nickerson, 2012]
exista um atraso significativo na rececao dos mesmos. Para a transmissao da informacao em tempo
real foram considerados dois tipos de implementacao:
• HTTP Long Polling: O cliente faz um pedido ao servidor que por sua vez deixa esse pedido em
aberto e aguarda que exista informacao para enviar ao cliente. Assim que existirem novos dados
prontos a enviar para o cliente o servidor responde com a nova informacao e assim que o cliente
recebe estes novos dados faz imediatamente um novo pedido, repetindo a mesma operacao.
• WebSockets: Este protocolo permite uma ligacao bidirecional entre o cliente e o servidor e opera
entre um unico canal de comunicacao.
A Figura 3.1 ilustra a conexao dos dois protocolos enunciados. Chegou-se a conclusao que a utilizacao
de HTTP Long Polling nao seria exequıvel uma vez que a sua escalabilidade para uma grande quanti-
dade de dados poderia nao ser suficiente, isto porque quanto maior o debito mais transacoes existiriam
e o cliente teria a responsabilidade de fazer os pedidos da informacao no ritmo certo. Usando os web-
sockets a ligacao bidirecional permite esta troca de informacao de um modo mais simples e nao obriga
o cliente a fazer os pedidos.
Por outro lado um estudo realizado [Pimentel and Nickerson, 2012] comparou a latencia media dos dois
protocolos e concluiu-se que os WebSockets tem valores mais baixos que o outro protocolo (uma vez
que a comunicacao bidirecional diminui significativamente os pedidos, em comparacao com o HTTP
Long Polling.
Uma vez que os WebSockets permitem uma melhor experiencia em tempo real optou-se pela sua
utilizacao, outra das razoes foi que dado que a maioria dos browsers atuais suportam HTML5 a API de
WebSockets tambem e suportada.
A estrutura da aplicacao (ilustrada na figura 3.2) permite perceber qual a projeccao global do sistema
utilizado para a transmissao dos eventos. Apos a ligacao da interface, o servidor realiza a leitura do
22
dataset (no formato CSV) e consequentemente comeca a enviar linha a linha a informacao contida
no ficheiro. Cada linha enviada corresponde a um pacote de informacao enviado para a interface e o
intervalo de tempo entre cada transmissao pode ser definido pelo utilizador na interface (por motivos
de implementacao), que por sua vez comunica com o servidor e altera esse tempo. Por definicao o
intervalo de tempos que o utilizador pode alterar varia entre 2 e 1000 pacotes por segundo.
Figura 3.2: Estrutura Global do Sistema
3.2 Ferramentas para a ligacao e transmissao de dados
A utilizacao da linguagem de programacao python e importante na medida que existem imensas biblio-
tecas que ajudam a criar de uma maneira facil e eficiente solucoes para o problema colocado. Para a
sua criacao foi necessario arranjar ferramentas para ler ficheiros CSV e transmitir os dados atraves de
WebSockets.
Para a leitura de ficheiros CSV utilizou-se a biblioteca pandas1, esta tecnologia permite a utilizacao
e manipulacao de estruturas de dados de uma maneira intuitiva e com elevado grau de desempenho.
A leitura de ficheiros com elevadas quantidades de informacao necessita de uma gestao cuidada. Esta
ferramenta permite a leitura e armazenamento temporario de chunks de informacao a medida que o
CSV vai sendo consumido pelo Streamer , estes chunks sao guardados em memoria e apos a sua lei-
tura e substituıdo pelo chunk seguinte, o seu tamanho pode ser definido pelo utilizador na inicializacao
do servico, assim a capacidade da memoria da maquina que esta a correr o servidor nao e excedida e
a sua gestao pode ser controlada.
Posteriormente, alem de armazenar os dados, esta tecnologia possibilita a realizacao de uma analise
de informacao em conjunto com outras ferramentas (por ex. IPython2). Apesar de nao existir na parte
do servidor, o processamento da informacao poderia ser realizado a com a ajuda do pandas.
Para a comunicacao entre servidor-cliente a geracao do WebSocket e feita atraves de uma extensao
a biblioteca Flask3 chamada SocketIO4 uma interface que permite a criacao de WebSockets, ajudando
assim a transmissao em tempo real de dados e a uma comunicacao bidirecional e baseada em eventos.
Esta aplicacao contem o codigo fonte que permite ao servidor e ao cliente iniciarem uma comunicacao
em apenas algumas linhas de codigo de maneira simples e rapida.
1https://pandas.pydata.org/, ultimo acesso 15 Outubro 20182https://ipython.org/, ultimo acesso 15 Outubro 20183http://flask.pocoo.org/, ultimo acesso 15 Outubro 20184https://socket.io/, ultimo acesso 15 Outubro 2018
23
3.3 Comunicacao Cliente-Servidor
A comunicacao bidirecional entre cliente e servidor nao so realiza a transmissao da informacao para a
interface como tambem permite que o utilizador efetue alteracoes ao servidor do lado do cliente sem
este ter de ter acesso remoto ao servidor (assim e possıvel alterar o debito da informacao na fase de
implementacao do sistema de modo a testar diferentes abordagens). Assim e possıvel fazer alteracoes
em tempo real sem que seja necessario reiniciar todo a aplicacao.
A comunicacao entre a interface e o servidor comeca com o pedido de ligacao por parte do cli-
ente utilizando o endereco estabelecido pelo servidor, a figura 3.3 ilustra um exemplo de comunicacao
interface-servidor. Apos esta conexao ser estabelecida o servidor inicia uma nova thread para o envio
dos pacotes de dados com um intervalo de tempo pre-definido. Este intervalo (que denominamos de de-
lay ) pode ser alterado pelo cliente enviando uma mensagem com o valor pretendido, quando o servidor
recebe esta mensagem altera o tempo que a thread adormece ate ao proximo envio de informacao. O
utilizador e capaz enviar comandos para pausar e continuar a transmissao de dados, apesar da inter-
face nao prever momentos de pausa do sistema (pois o requisito do sistema e ser em tempo real) esta
pausa pode ser importante para analisar partes de informacao relevantes. E tambem possıvel fazer um
teste de ping ao servidor para que seja compreensıvel se a conexao entre as entidades nao foi perdida.
Em resumo os comandos que podem ser trocados entre a interface e o servidor sao enumeradas no
seguinte paragrafo com a sua respetiva funcionalidade:
• Connect - O cliente envia uma mensagem ao servidor para iniciar a ligacao entre ambos.
• Delay - O cliente pede ao servidor para enviar os pacotes de dados no intervalo de tempo espe-
cificado.
• Pause - O servidor para de enviar pacotes de dados
• Resume - O servidor reinicia o envio de pacotes
• Ping - O cliente pede que o servidor envie uma mensagem de resposta ao cliente a fim de ver se
a conexao continua viva.
3.4 Envio de Dados
Como referido na seccao 3.1 o envio da informacao a cargo dos WebSockets requer de uma previa
leitura do dataset.
3.4.1 Dataset
Para cumprir os requisitos do sistema e necessario que o conjunto de dados utilizado seja em elevada
escala e que possa conter a componente tempo real, isto e, um dataset que seja possıvel representar
em streaming. Nao faria sentido por exemplo, utilizar um conjunto de dados que representasse as cores
dos clubes de futebol no mundo ou uma base de dados que dissesse o preco da gasolina num paıs
24
Figura 3.3: Exemplo de comunicacao Interface-Cliente
num determinado momento. Estes dados nao sao do nosso interesse uma vez que nao e possıvel criar
uma cadeia temporal dos mesmos. Por outro lado, os datasets associados a ocorrencia de eventos
possibilitam a abordagem pretendida dado que a cada evento podemos associar uma timestamp e re-
presenta-lo. Aliado a isto, a grande parte de datasets baseados em eventos tipicamente geram grandes
quantidades de informacao porque os eventos podem ser registados numa larga escala de intervalos
de tempo. Um exemplo deste tipo de bancos de dados sao as viagens realizadas pelos utilizadores de
transportes publicos, as transacoes de criptomoedas, etc. Note-se que a cada evento nestes exemplos,
esta associado o momento em que esse evento ocorreu e o seu valor. O dataset e uma das pecas mais
relevantes na elaboracao deste trabalho pois vai permitir analisar e inferir dados relevantes do mesmo
atraves da visualizacao apresentada pela interface.
A procura de um dataset com estas caracterısticas tem vindo a ser facilitada ao longo do tempo
uma vez que a sua geracao pode ser proveniente de multiplas fontes [Sagiroglu and Sinanc, 2013] ,
desde vendas de lojas [Keim, 2001], logs, redes sociais, sensores de saude, telemoveis, etc. Qualquer
25
um destes exemplos e capaz de gerar largas quantidades de informacao que em conjunto com outros
metodos geram milhares de milhoes de dados. Para a inclusao dos dados neste trabalho procuraram-se
datasets pelo menos 100 mil entradas por ficheiro.
Existindo multiplas fontes deste tipo de dados as mais indicadas para este tipo de trabalho foram:
• Kaggle5 - E uma plataforma de competicoes de modelacao preditiva e analıtica onde os partici-
pantes competem para produzirem o melhor modelo que descreve um dataset. Apesar de nao
ser do ambito do trabalho, esta plataforma fornece bancos de dados que cumprem os requisitos
pretendidos (grandes quantidades de dados por dataset e alguns baseados em eventos).
• Google BigQuery6 - E um webservice que permite a analise interativa de enormes conjuntos de
dados em conjunto com o Google Storage. E possıvel fazer pedidos com queries SQL para obter
grandes quantidades de dados e posteriormente guardar em ficheiros.
Apos uma analise da informacao disponıvel, chegou-se a conclusao que os datasets mais indicados
para a utilizacao neste trabalho fossem aqueles que de uma maneira geral possibilitassem a utilizadores
nao experientes analisar informacao de uma forma simples e explicita. Isto e, por exemplo, a analise
de um conjunto de dados das vendas ocorridas por uma cadeia de supermercados (ver o valor medio
das vendas, no de vendas, oscilacoes) e muito mais simples que analisar e tirar conclusoes que a
analise das correntes de tensao eletrica numa estacao termoeletrica (por exemplo). Houve o cuidado
de escolher informacao de facil analise a utilizadores nao experientes com o domınio a visualizar.
Numa primeira fase o dataset utilizado foi adquirido atraves do servico SocrataSocrata Open Data7
uma plataforma de recolha de datasets, os dados extraıdos eram compostos pela duracao das viagens
realizadas pelos taxis de Chicago8. Apesar de multiplas variaveis para cada viagem a escolhida para
representar pela interface era o tempo de duracao de cada viagem. Com o passar do tempo e com
a iteracao dos modulos da interface, este dataset foi substituıdo por outro que viria a servir melhor o
proposito do problema.
O novo banco de dados foi recolhido na plataforma BigQuery da Google. O seu domınio consiste
nas transacoes realizadas da criptomoeda Bitcoin (BTC). Cada venda ou transferencia desta moeda e
registada num sistema denominado de Block Chain que pode ser visualizado publicamente por qualquer
um. [Garcia and Schweitzer, 2015]
Este conjunto de dados aproximava-se mais ao pretendido para a analise de dados, podendo ser
analisadas as tendencias das transacoes, padroes [McGinn et al., 2016; Battista et al., 2015], os valores
atıpicos e momentos onde ocorria um maior fluxo das trocas ocorridas. Este banco de dados9 contem
330 milhoes de entradas, cada uma representa uma transacao, o seu tamanho e de aproximadamente
572 GB, estas caracterısticas fazem dele o dataset ideal para o desenvolvimento e testes da interface.
Dado o tamanho absurdamente elevado deste conjunto de dados e necessario extrair a informacao de
5https://www.kaggle.com/datasets?sortBy=hottest&group=public&size=large, ultimo acesso 15 Outubro 20186https://bigquery.cloud.google.com/welcome/bigdatadatasets, ultimo acesso 15 Outubro 20187https://dev.socrata.com/, ultimo acesso 15 Outubro 20188https://dev.socrata.com/foundry/data.cityofchicago.org/wrvz-psew, ultimo acesso 15 Outubro 20189https://bigquery.cloud.google.com/table/bigquery-public-data:bitcoin_blockchain.transactions?tab=
details, ultimo acesso 15 Outubro 2018
26
uma forma cuidada. Para cada entrada, existe informacao que nao era necessaria para o domınio do
problema, como por exemplo a origem da transacao, o id, bloco, destinatario, nounce, etc. A informacao
a ser recolhida foi o timestamp e o satoshis (quantia com a qual conseguimos saber qual o valor da
transacao). Dado que a extracao completa do dataset nao seria uma escolha viavel (dado o seu ta-
manho) e porque para efeitos de teste so se quer analisar alguns segundos da interface selecionou-se
apenas as transacoes do dia 12 de Dezembro de 2017, durante esta altura os valores da criptomoeda
atingiam maximos historicos (levando muitas pessoas a questionar este aumento10 (a figura 3.411 ilustra
esse crescimento) e por isso seria uma boa oportunidade para analisar as transacoes ocorridas.
Figura 3.4: Valor da Bitcoin (BTC) em 2017
A extracao deste dia requer a escrita em SQL da query e dos parametros necessarios. Com a ajuda
da library BigQueryHelper disponibilizada na linguagem Python a query realizada consistia na recolha
dos campos timestamp, data, id e satoshis. O valor satoshis corresponde a fracao mais pequena da
moeda que pode ser transacionada, correspondendo a 0.00000001 BTC. Apos a extracao de todos os
valores este campo era convertido para o valor real em BTC e guardado num ficheiro CSV. No total
foram recolhidas 1 047 080 transacoes, correspondendo a um tamanho total de aproximadamente 109
Megabytes.
Para sumarizar a tabela 3.1 apresenta as caracterısticas que um dataset deve ter para poder ser
utilizado pela interface:
3.4.2 Metodo de envio dos dados
O metodo de envio dos dados para interface passa pela leitura do ficheiro CSV especificado no arranque
do servidor. Antes da sua iniciacao e necessario indicar qual a coluna onde estao os valores a ser
enviados, assim como especificar o ficheiro que deve ser lido e ate que linha do ficheiro o servidor deve
10https://www.quora.com/Why-is-Bitcoin-exploding-in-December-2017, ultimo acesso 15 Outubro 201811https://www.coindesk.com/price/, ultimo acesso 15 Outubro 2018
27
Disponibilidade Dinamico, os dados sao por stream emtempo real, o dataset nao e estatico
Tipo Tabelas, FieldsAtributos Atributo unico que deve ser ordinal, quan-
titivo ou contınuo.Time-Based Deve possuir um atributo temporal para
representar mudancas ao longo do tempo
Tabela 3.1: Propriedades do dataset
ler. Para alem disso o utilizador pode indicar em que linha do ficheiro deve o servidor comeca a ler,
assim e possıvel analisar alturas especıficas do dataset sem ter de rever partes menos relevantes do
mesmo. Antes da ligacao com o cliente e realizada uma leitura do conjunto de dados para a memoria do
programa e posteriormente e lida cada entrada no momento de envio para o cliente. O pacote enviado
contem apenas um dicionario o respetivo valor da transacao.
3.4.3 Servidor para Testes de Usabilidade
Para a realizacao dos testes de usabilidade houve a necessidade de criar um sub-servico de envio de
informacao uma vez que o servidor criado nao permitia a inclusao do timestamp nos pacotes enviados
a interface, esta nova funcionalidade faz com que exista menos trabalho no lado do cliente para a
atribuicao de um timestamp quando recebe um pacote. Esta solucao e eficaz para casos em que o
servidor nao conseguiu enviar em tempo real os dados, para assim poderem ser representados na
altura em que ocorreram e nao no momento em que foram recebidos.
Por outro lado o controlo do intervalo (delay ) entre o envio de dois pacotes passa a depender do
dataset e nao do utilizador, desta maneira e possıvel identificar alteracoes no fluxo dos dados sem
recorrer a sua intervencao manual realizada pelo cliente na interface. Por essa razao a forma como os
datasets estavam estruturados tambem sofreu mudancas criando um novo campo delay que representa
o tempo em milissegundos ate o envio do proximo pacote, como ilustrado na tabela 3.2.
Delay Valor
100 25.2150 20.5200 21.4
Tabela 3.2: Exemplo ficheiro servidor de testes
Esta solucao tornou-se definitiva uma vez que soluciona os problemas descritos acima e torna a
visualizacao dos dados mais realista e intuitiva, pelo facto dos timestamps corresponderem ao tempo
real em que os dados foram gerados e nao ao momento em que foram recebidos pela interface (a
caracterıstica temporal faz parte do dado recebido e deve ser acompanhado pelo mesmo).
28
3.5 Gerador de Datasets
Apesar dos datasets obtidos para a representacao da informacao serem uteis para testar o sistema,
existiu a necessidade de se criar um script para a geracao de fluxos e tendencias nos dados a apre-
sentar nos testes de usabilidade, na seccao 5.1 esta descrita uma resposta a esta necessidade.
A criacao deste programa consiste numa serie de comandos e opcoes que gera um ficheiro CSV
pronto para ser processado e enviado para a interface pelo utilizador. O utilizador explicita inicialmente
os parametros que quer ter no seu dataset e posteriormente o programa cria uma sequencia aleatoria
de valores de acordo com os padroes explicitados. Esses comandos (funcoes) sao os seguintes:
• Linear Generation - E responsavel por um crescimento positivo ou negativo dos valores medios
dos dados.
• Constant Generation - Mantem um valor constante dos dos valores medios dos dados.
• Mark Outlier - Gera um valor atıpico num determinado momento do dataset
Para a utilizacao destas funcoes e necessario que o utilizador forneca as opcoes que quer ter no
seu dataset :
• Size int - O quantidade de pontos que devem ser gerados
• Delta Interval [int, int] - O intervalo de valores em que se deve gerar um numero aleatorio para o
delay entre cada pacote/dado (utilizado para aumentar ou diminuir o fluxo de dados).
• Vals [int, int] - O intervalo de valores produzido em que se deve gerar um numero aleatorio para
o valor do pacote/dado.
• Prob Chance int - Valor entre 0 e 1 de probabilidade em que a cada ponto possa ser gerado outro
aleatoriamente (isto permite tornar o dataset mais fiavel)
• Prob Interval [int, int] - O intervalo de valores aleatorios que o valor gerado aleatoriamente (pro-
veniente da prob. chance) pode tomar.
• Alfa Random [int, int] (apenas para a Linear Generation) - Uma vez que os valores sao gera-
dos linearmente e necessario adicionar aos mesmos um valor aleatorio para que nao se note a
’fabricacao sintetica’ dos valores. Esse valor aleatorio esta entre este intervalo.
• Positive bool (apenas para a Linear Generation) - Indica se o crescimento dos valores positivo
ou negativo.
A utilizacao destas funcoes permite a criacao da informacao de acordo com as caracterısticas enun-
ciadas anteriormente. Por outro lado, e necessario que os datasets gerados nao passem a ideia de que
os pontos nao foram colocados em sıtios estrategicos, isto e, que nao foram colocados de maneira ma-
nual e nao transmitam uma ideia realista dos mesmos. Por esse motivo os parametros de alfa random,
29
prob interval e delta interval desviam os pontos utilizando valores aleatorios e criam outros pontos fora
das regressoes estabelecidas, criando um dataset mais genuıno e que nao pareca ”fabricado”.
Na figura 3.5 esta um exemplo de um dataset produzido pelo programa de geracao constituıdo por
3 fases:
Figura 3.5: Exemplo de um dataset gerado pelo programa
1. 1o Fase - Inicialmente usou-se a funcao Constant Generation com 1150 pontos (Size), o in-
tervalo entre pontos (Delta Interval) definiu-se entre os [10,20] milissegundos (fluxo alto) e com
valores constantes entre [80,90] (Vals). A probabilidade de geracao de numeros aleatorios tem o
valor de 5% (Prob Chance) e os valores que pode tomar sao entre [35,90] (Prob interval). Nesta
fase podemos identificar facilmente a grande agregacao dos pontos consequente do baixo valor
do Delta Interval, para alem disso eventualmente encontramos valores fora do intervalo constante
(os valores gerados com uma probabilidade de 5%) e que dao a ideia de um dataset menos
”fabricado”.
2. 2o Fase - De seguida usou-se a funcao Linear Generation para criar uma descida dos valores
medios dos dados. Com 250 pontos (Size) e um intervalo entre pontos (Delta Interval) entre os
[20,80], os valores desceram de 80 para 20 (descida linear) com uma diferenca aleatoria (Alfa
Random) entre [-10,10]. A probabilidade de geracao de numeros aleatorios tem o valor de 10%
(Prob Chance) e os valores que pode tomar sao entre [35,65] (Prob interval).
3. 3o Fase - Por ultimo voltou-se a usar a funcao Constant Generation com 150 pontos (Size), mas
com um intervalo entre pontos (Delta Interval) muito mais elevado entre os [100,200] milissegun-
dos (fluxo baixo) e com valores constantes entre [20,30] (Vals). A probabilidade de geracao de
numeros aleatorios tem o valor de 5% (Prob Chance) e os valores que pode tomar sao entre
[36,65] (Prob interval). Neste perıodo constatamos um fluxo muito mais reduzido de dados e por
consequencia um volume inferior ao da 1o Fase. E tambem de notar que a quantidade de valores
aleatorios gerados e bastante inferior uma vez que o numero de pontos tambem e baixo.
30
Capıtulo 4
Front End - Interface
Neste capıtulo e explicada a abordagem tomada para a resolucao do problema assim como a
implementacao e os processos realizados no seu desenvolvimento. Para alem disso e descrito quais
as ferramentas utilizadas e a sua utilidade para a interface.
4.1 InfoVis
Hoje em dia e cada vez mais comum empresas como Amazon, Google, Facebook, Apple, etc. investi-
rem na investigacao e criacao de formas de apresentar os seus dados como forma de melhorar as suas
decisoes no mercado e aumentarem os seus lucros [Simon, 2014]. O principal objetivo deste trabalho
e fornecer uma interface que possibilite a analise e compreensao de informacao que esta a ser gerada
em tempo real e que o utilizador possa atuar em caso de anomalias nos dados. E tambem relevante
que este sistema seja eficaz na apresentacao de informacao em diferentes momentos de fluxo dado
que a representacao de uma grande quantidade de pontos dificulta a analise feita pelos utilizadores
[Evgeniy Yur’evich Gorodov, 2013].
Podemos nomear este conjunto de palavras ”Grandes quantidades de informacao”num unico termo:
BigData, apesar da sua definicao ser vaga e nao consensual entre os investigadores, apos um es-
tudo realizado por Andrea De Mauro [De Mauro et al., 2015] define a palavra como um conjunto de
informacao caracterizada pelo seu elevado volume, velocidade e variedade que requer tecnologia e
metodos para o seu processamento.
Como referido na seccao 2.1.1 existem diferentes metodos para manipular e filtrar este tipo de
dados. Conjuntos com elevados atributos sao representados atraves de cores, formas, e tamanhos
diferentes [Grinstein and Trutschl, 2001]. No caso deste trabalho a intencao e abordar apenas um
atributo do dataset, apesar de futuramente, com a implementacao de novos modulos esse caso poder
ser possıvel, utilizando para isso diferentes metodos de interacao como filtering, zooming, linking and
brushing e distortion. Por este motivo, estes dados sao caracterizados por dados uni dimensionais e
obtem tipicamente um por um fator temporal associado [Keim, 2002].
A fase de reducao e composta pela Filtragem que pode ser feita pela reducao de elementos ou
31
atributos, que e caracterizada pelas acoes que removem dados da visualizacao atual, alguns exemplos
destas tarefas sao o zoom geometrico ou semantico, translacao e constrangimento da visualizacao. A
reducao de atributos e feita atraves de cortes que correspondem aos requisitos do utilizador. Algumas
formas de agregacao mais gerais sao os histogramas, boxplots, heatmaps, clustering, entre outros.
Existem tambem algoritmos para realizar uma reducao de dimensionalidade da informacao, os princi-
pais sao o Principal Component Analysis (PCA) [Shlens, 2014], e o Multidimensional Scaling (MDS)
[Buja et al., 2008].
Para alem da filtragem pode ser realizada tambem a Agregacao de elementos criando outros
que sumarizam e representam conjuntos de dados. Estas agregacoes geralmente envolvem metodos
estatısticos calculando medias, medianas, mınimos, frequencias, etc. Por outro lado estas funcoes
podem resultar numa vista distorcida da informacao e e importante que sejam utilizadas com cuidado.
4.1.1 Requisitos
Os requisitos levantados antes da producao de uma solucao sao essenciais para descobrir quais sao
as principais exigencias e dificuldades na visualizacao de dados. Sabendo que a solucao passa por
ter um sistema que funcione em tempo real e que suporte uma elevada quantidade de dados e apos
a pesquisa descrita no capıtulo 2 podemos concluir que o sistema deve estar condicionado por alguns
aspetos:
• Exploracao Interativa - Necessario para que o utilizador consiga explorar interativamente os
eventos ocorridos do mesmo modo a que consiga visualizar a informacao que esta a receber em
tempo real.
• Localidade das Mudancas - Para que a adicao de nova informacao as visualizacoes nao afetem
o sistema na sua globalidade.
• Preservacao do Contexto Temporal - Para ser possıvel transmitir eventos passados e recentes
e possam ser reconhecidos padroes temporais na informacao.
Existem tambem outros princıpios que devem ser levados em conta, os mais conhecidos no domınio
da visualizacao sao:
• Expressiveness - A visualizacao deve expressar todas e somente as informacoes que estao nos
conjuntos de dados [Mackinlay, 1986]
• Effectiveness - Identifica quais das visualizacoes sao mais eficazes na exploracao da informacao
e na capacidade de compreensao do utilizador [Mackinlay, 1986]
• Appropriateness - Esta relacionado com o tradeoff entre os esforcos para criar a representacao
visual e os benefıcios que ela comporta, se esta troca for balanceada entao a visualizacao e
considerada apropriada [Schumann and Muller, 1999]
32
4.2 Abordagem
A implementacao deste projeto tem em conta a compatibilidade que a interface ira ter com os diferentes
sistemas operativos, de modo a ter um sistema que funcione em todos os dispositivos optou-se por criar
uma solucao web1, desta forma qualquer browser poderia aceder a aplicacao independentemente do
sistema utilizado.
Para alem da modularidade que uma web app permite, existem tambem ferramentas (libraries) para
facilitar o desenvolvimento do sistema de visualizacao, neste caso a principal e mais usada para o pro-
jecto foi a biblioteca D3 - Data Driven Documents2 que ajuda na criacao de visualizacoes dinamicas
e que de acordo com analises realizadas [Bostock et al., 2011] entrega melhores resultados em ter-
mos de eficiencia, tendo melhores tempos na iniciacao das paginas e no frame rate das imagens em
comparacao com outras aplicacoes como Flash3 ou ProtoViz4. Todas as visualizacoes criadas tive-
ram em conta a apresentacao de apenas um atributo por visualizacao (representacao uni variavel dos
dados).
A procura de um modelo que complementasse estes aspetos comecou pela ideia de que a inter-
face deveria realizar uma degradacao graciosa da informacao, isto e, a medida que o tempo avanca os
micro-dados que foram recebidos ha mais tempo devem comecar a ser agregados atraves de medidas
estatısticas para o efeito (medias, quartis, tendencias, etc.) assim o utilizador pode estar focado na
informacao mais recente sem que perca o contexto da informacao que ja foi recebida anteriormente.
Esta degradacao graciosa deve ser feita de um modo progressivo e de forma a que o utilizador per-
ceba as alteracoes que estao a ser realizadas pelo sistema. Isto permite tambem que o utilizador tire
conclusoes da informacao mais antiga e compare com a mais recente.
Foi desta premissa e depois de muitos desenhos em papel (figura 4.1) que surgiu a ideia de criar
modulos de visualizacao, cada um representa a informacao num idioma diferente permitindo assim que
o cliente tenha uma experiencia mais abrangente da informacao que esta a analisar. Estes modulos
dispostos lado a lado pretendem criar uma experiencia inovadora na investigacao de conjuntos de
dados. A ligacao destes modulos possibilita que a informacao realize uma navegacao entre os mesmos
e no momento de transicao para um novo idioma os dados sejam representados de uma maneira
diferente, o facto de estes objetos estarem lado a lado cria uma visao contınua do sistema e interliga
a informacao, unificando a analise e ajudando o utilizador a compreender todo o fluxo da informacao
tendo diferentes metricas apresentadas para os mesmos dados em diferentes momentos.
Estes modulos podem ir de simples graficos de linhas ate visualizacoes mais complexas e detalhadas.
A ideia destes modulos proporciona tambem que o sistema integre novas visualizacoes criadas de
acordo com as necessidades dos utilizadores, isto porque o tipo de visualizacao utilizado e muitas vezes
dependente do domınio que esta a ser estudado.
Neste trabalho foram implementados 3 tipos de modulos: Linechart, Scatterchart, Barchart. Cada
um representa um idioma de visualizacao diferente e a estrategia foi encontrar metodos em que a
1https://en.wikipedia.org/wiki/Web_application, ultimo acesso 15 Outubro 20182https://d3js.org/, ultimo acesso 15 Outubro 20183https://get.adobe.com/flashplayer/, ultimo acesso 15 Outubro 20184http://mbostock.github.io/protovis/, ultimo acesso 15 Outubro 2018
33
Figura 4.1: Desenhos em papel
navegacao dos mesmos facultasse uma compreensao do utilizador a representacao em tempo real da
informacao recebida. Estes idiomas foram escolhidos de acordo com o conhecimento existente sobre
os mesmos por parte dos utilizadores, a seccao 5.1.4 na imagem 5.5 revela que estes 3 estao entre os
5 mais conhecidos pelos utilizadores que realizaram os testes de usabilidade do sistema.
Para alem deste aspeto, a utilizacao destes idiomas representa a informacao de maneiras diferentes
ajudando a tirar diferentes conclusoes em cada fase da representacao dos pacotes recebidos, por um
lado o Scatterchart dispoe os pontos detalhados enquanto o Linechart mostra as medidas estatısticas
sobre uma seccao existente (mediana, quartis, maximos e mınimos), e o Barchart junta a informacao de
maneira a visualizar-se agregados em determinados intervalos de valores a partir de um determinado
momento.
A medida que a interface recebe os dados, estes vao sendo apresentados da direita para a esquerda
e passando de um modulo para outro. A informacao e processada de acordo com as especificacoes
desse modulo. Como referido no paragrafo anterior a principal vantagem deste metodo e que e possıvel
que a medida que a informacao percorra cada modulo esta seja processada e agregada de diferentes
maneiras criando assim a ideia de ”degradacao graciosa” e ajudando o utilizador a retirar conclusoes
provenientes de diferentes tipos de visualizacoes [Viau and McGuffin, 2012]. Estes multiplos modos
de representacao sao ainda mais importantes quando estao a ser analisados grandes quantidades de
dados [Demir et al., 2014].
Para a interacao com cada modulo decidiu-se que a interface deveria ser o mais simples possıvel e
nao conduzir o utilizador a uma exploracao complexa da informacao, por este motivo o unico meio de
interacao existente e a sobreposicao do rato pelos elementos desenhados na tela. Esta sobreposicao
posteriormente desencadeia o aparecimento de uma tooltip do modulo correspondente e apresenta a
informacao (valores) dos elementos sobrepostos. Derivado ao facto de estar presente a visualizacao
em tempo real optou-se que esta informacao nao fosse atualizada a medida que os elementos navegam
pelo grafico, caso contrario o utilizador teria dificuldade em acompanhar o rato pelos elementos, assim
34
sendo os valores so sao atualizados nas alturas em que existe movimento (input) por parte do utilizador.
Se por um lado a visualizacao do grafico global permite uma analise correspondente a exploracao
livre da informacao, a visualizacao focada num dos modulos presentes no grafico faz com que a tarefa
de procura seja diferente, dependendo do tipo de informacao que se quer extrair esta tarefa pode ser
orientada para o estudo num determinado perıodo do tempo (onde e necessario verificar e procurar os
modulos que correspondem a esse intervalo), ou orientado a observacao dos valores medios ocorridos
onde a visualizacao conjunta de todos os idiomas pode revelar variacoes ou existencia de anomalias
na informacao apresentada. Os requisitos de expressiveness e effectiveness sao demonstrados por
estes parametros, a principal funcao deste sistema e permitir que o utilizador nao perca o contexto da
informacao recebida (caso que e dificultado pela caracterıstica de tempo real) e ao mesmo tempo pela
expressao concreta da informacao recebida por parte dos modulos.
4.3 Implementacao
A implementacao deste projeto ficou dividida em duas partes distintas, inicialmente pensou-se em re-
alizar uma abordagem de manipulacao de elementos SVG em conjunto com a biblioteca D3 para a
criacao de visualizacoes dinamicas. Na segunda abordagem utilizou-se a tecnologia Canvas usada
para desenhar graficos em paginas web.
A ferramenta D3 utiliza metodos para inserir, remover, e atualizar objetos existentes na pagina. Esta
biblioteca manipula os elementos de tal forma que nao existe necessidade de remove-los sempre que
exista uma nova modificacao nos mesmos (ao contrario da implementacao de Canvas onde os objetos
tem de ser redesenhados). Entre estes metodos existe a possibilidade de aumentar tamanhos, cores,
texto, posicao, entre outras caracterısticas.
Podemos definir ambas as aplicacoes por:
• Canvas - Area retangular numa pagina HTML usada para desenhar graficos atraves de scripts
utilizando diferentes metodos de desenho (paths, boxes, text, etc). Uma vez desenhado nao e
possıvel aceder aos seus elementos, sendo que para alterar alguma propriedade e necessario
redesenhar o quadro todo.
• SVG - Os elementos habitualmente usados para criar graficos sao os SVG, estes objetos sao
definidos atraves de XML e tratados como um unico elemento podendo assim serem alterados a
qualquer altura.
Estas duas tecnologias costumam ser utilizadas para a renderizacao e visualizacao de graficos e
visualizacoes, ambas possuem as diferencas descritas na tabela 4.1.
Enquanto Canvas e uma tecnologia baseada em Pixels e composta por um unico elemento HTML,
os SVG baseiam-se em formas e os graficos sao geralmente compostos por multiplos elementos. Para
alem disso a manipulacao do Canvas so pode ser feita atraves de scripts enquanto os SVG sao dese-
nhados por regras CSS ou por scripts Em termos de eficiencia o Canvas pode desenhar milhares de
35
SVG CANVASDesempenho Os objetos ocupam espaco na
memoria do browser e quanto maisobjetos mais lento pode ficar
Nao existindo uma camada deabstracao para o desenho dos ob-jetos como existe nos elementos SVGnao existem operacoes que atrasem arenderizacao dos objetos.
Complexidade Existem ferramentas que ajudam namanipulacao dos objetos criados e asua interacao e mais simples
A interacao entre os elementos dese-nhados e mais complexa uma vez queestes eventos devem ser programadospelo utilizador
Acessibilidade Os elementos sao acessıveis, cada ob-jeto pode ser manipulado
Nao existem elementos, os objetos saopintados na tela e nao e possıvel ace-der aos seus atributos
Animacoes A elaboracao de animacoes e facili-tada pelo suporte do CSS e das duasfuncoes de transicoes
A realizacao de transicoes fica a cargodo utilizador tendo este de elaborar ostempos de execucao da mesma, sendoum processo complexo
Flexibilidade Nao existe tanta flexibilidade emrelacao a manipulacao de objetos umavez que estao dependentes do tipo debrowser que estao a utilizar
Uma vez que o utilizador controla todosos aspetos a desenhar, e possıvel al-terar qualquer atributo dos elementosdesenhados.
Tabela 4.1: Diferencas entre DOM e Canvas
elementos sem comprometer o desempenho do sistema enquanto os elementos SVG sao mais eficazes
para um baixo numero de elementos.
Apos a primeira implementacao constatou-se que a renderizacao de uma elevada quantidade de
elementos exigia uma elevada carga computacional ao browser que estava a apresentar os dados. Isto
levava a que os requisitos da apresentacao de grandes quantidades de informacao e de tempo real fos-
sem postos em causa uma vez que existia um limite muito baixo para que os frames/FPS diminuıssem
consideravelmente. Esta primeira fase nao tinha uma arquitetura especıfica e ambos os modulos eram
muito autonomos por si, na figura 4.2 podemos verificar esta abordagem utilizando os elementos SVG.
Figura 4.2: Implementacao utilizando elementos DOM
36
Esta implementacao era mais simples uma vez que a utilizacao da biblioteca D3 permitia realizar
transicoes e manipulacoes nos elementos eficientemente e com a ajuda de metodos da biblioteca (inse-
rir objetos, mover, pintar, remover, etc.). A migracao para a abordagem canvas acarretou alguns custos
na dificuldade da implementacao projeto uma vez que estes metodos so funcionam para a manipulacao
dos elementos SVG.
A arquitetura do sistema ilustrada pelo UML na figura 4.3 e composta por uma classe principal
Chart, esta classe e a responsavel por manter o sistema e coordenar os modulos nas suas tarefas, por
outro lado, e tambem esta classe que define alguns criterios padrao como a escala em que os graficos
devem aparecer, os dados, a ligacao ao servidor, a altura e largura do grafico, entre outros.
Figura 4.3: UML da interface VisMillion
Os modulos sao uma classe e fazem parte do Chart, eles controlam os dados que pertencem ao
seu domınio temporal e processam e representam a informacao de acordo com as especificacoes e
programacao da classe. Estes modulos sao tambem responsaveis pelo desenho e representacao da
informacao do seu espaco temporal.
O fluxo da interface 4.4 segue a arquitetura update and draw. Apos a instanciacao dos Modulos e
do Chart os graficos sao desenhados de acordo com um ciclo. Primeiro o quadro e limpo e desenhados
os eixos principais do grafico (aqueles que sao gerais a toda a visualizacao e nao a cada modulo), de
seguida todos os modulos iniciam um ciclo de update onde realizam o processamento dos dados e de
como e que estes irao ser apresentados. Ao inıcio de cada ciclo o Chart regista um timestamp que e
propagado para os modulos, assim cada modulo pode processar a informacao relativa ao seu intervalo
de tempo.
De seguida e apos ser realizado o processamento (update) de todos os modulos, o Chart evoca a
funcao de draw de cada modulo que ira utilizar os novos dados processados da fase anterior. A cada
ciclo global (update + draw) sao calculados os FPS (quadros por segundo) que a aplicacao realiza
utilizando a formula Math.round(1000/performance.now()−previousDate), quanto mais dados e mais
modulos menor serao os FPS da interface uma vez que as funcoes a realizar exigem um maior grau de
complexidade para o processamento da informacao.
37
Figura 4.4: Fluxo da interface VisMillion
4.3.1 Chart
Como referido na seccao anterior 4.3 a classe Chart e responsavel por gerir todos os modulos inerentes
a mesma, sendo peca fundamental na interface. E assim que o contexto entre os modulos e mantido
uma vez que todos utilizam informacao proveniente desta classe (domınios, escalas, etc.).
E atraves desta classe que o utilizador pode definir a maneira como os valores devem ser apre-
sentados na interface, tendo em conta o domınio dos dados e os tipos de dispositivos de visualizacao
(smartphones, desktops, etc.). Este tipo de flexibilidade permite que a interface criada seja utilizada no
maior numero de casos possıvel e tambem ajudar os utilizadores a definirem quais as melhores opcoes
para a sua visualizacao.
Esta peca do sistema revela a interpretacao da globalidade do sistema, uma vez que unifica todas
as instancias criadas pelo utilizador e torna o sistema num so. A figura 4.6 apresenta a visualizacao
global de uma monitorizacao em tempo real de transacoes BTC. Com este conceito e possıvel cumprir
alguns requisitos enunciados na seccao 4.1.1, a exploracao interativa e realizada uma vez que toda a
informacao recebida ate ao momento e encontrada em qualquer parte do grafico, e a localidade das
mudancas e a preservacao do contexto temporal realizadas de acordo com a navegacao natural da
informacao (mais antiga a esquerda e recente a direita). Para alem destes requisitos, a escolha deste
tipo de implementacao ajudou a criar uma ”independencia”aos modulos contidos nesta classe, nao
obstante do facto destes modulos deverem realizar uma interligacao coerente entre os mesmos, para
que nao exista perca de contexto da informacao por parte do utilizador.
Notemos por exemplo o caso de uma monitorizacao de transacoes de moeda virtual (como por
exemplo a BTC) em que os valores transacionados estao na maioria das vezes compreendidos entre o
intervalo [0.0001, 1]. Faz sentido neste caso apresentar os valores numa escala logarıtmica dado que
estas transacoes nao sao uniformes. Neste caso o utilizador pode definir estas variantes no inıcio da
visualizacao e algumas destas opcoes podem ate ser manipuladas em tempo real consoante as suas
necessidades. Na figura 4.5 temos um exemplo de instanciacao para este caso.
O posicionamento dos dados e feito com a ajuda de ferramentas da biblioteca D3 atraves das suas
funcoes de escala que ajudam a mapear unidades quantitativas para pixeis no ecra. Como referido no
38
chart = new Chart({
width: \$(’.container’).width() ,
height: 400,
margin: {top: 30, right: 40, left: 40, bottom: 25},
transitions: 300,
yDomain: [1e-6,100],
yScale: d3.scaleLog(),
selfDelay: 1000,
container: d3.select(’.bigvis’),
sci_notation: true,
outlier: true
})
Figura 4.5: Instanciacao do Chart para transacoes BTC
ultimo paragrafo, estas escalas sao passadas pelo utilizador existindo inumeras opcoes que podem ser
utilizadas e enumeradas na tabela 4.2. Por outro lado a escala horizontal que corresponde ao tempo e
por definicao scaleTime() e nao pode ser alterada. Para alem destas, outras funcoes de mapeamento
sao utilizadas, por exemplo na mudanca de cor de alguns elementos e animacoes.
Funcao D3 EquacaoscaleLinear() y = m ∗ x+ bscalePow(exp) y = m ∗ xexp + bscaleSqrt() y = m ∗ x0.5 + bscaleLog() y = m ∗ log(x) + bscaleTime() Similar ao scaleLinear()
Tabela 4.2: Escalas disponıveis na biblioteca D3
O utilizador tem a possibilidade de adaptar a interface ao dispositivo (altura, largura e margens) e
tambem ao tempo das transicoes. Para a visualizacao especıfica da informacao existem propriedades
como o domınio vertical, escala, outliers, notacao cientıfica que tambem devem ser definidos, caso
contrario a aplicacao ira utilizar valores padrao que podem nao corresponder a uma boa representacao
do dataset. A figura 4.6 apresenta a configuracao para este tipo de instanciacao do Chart.
Por definicao o eixo horizontal representa o tempo em que os dados foram recebidos, o fluxo e
realizado da direita para a esquerda, assim e possıvel observar os dados mais recentes em modulos
de representacao mais detalhada que ao longo da sua progressao vao sendo agregados em modulos
com informacao menos minuciosa.
O Chart recebe os pacotes enviados pelo servidor (explicados na seccao 3.4.2) atraves da classe
Connection que e responsavel pela comunicacao entre as duas entidades. Os pacotes recebidos sao
guardados numa lista que e posteriormente disponibilizada aos modulos com os sub-conjuntos associ-
ados ao seu intervalo temporal atraves de uma funcao de filtragem que recebe como argumentos um
intervalo de tempo e retorna todos os elementos que correspondem a esse conjunto.
A interacao de todo o sistema tem o seu ponto de partida no Chart uma vez que e o modulo
que comanda os restantes modulos e os informa de todos os processos que ocorrem, um deles e a
interacao do utilizador realizada atraves da sobreposicao do rato no grafico. Esta acao faz com que o
39
Figura 4.6: Chart de transacoes BTC
grafico associe a posicao com o modulo que esta a ser sobreposto e desencadeia a execucao da funcao
de mouseEvent do modulo correspondente. Este tipo de abordagem permite que o utilizador consiga
realizar uma exploracao interativa dos dados e torna a experiencia do utilizador mais enriquecedora no
sentido em que consegue obter mais informacao sobre os segmentos que quer analisar.
E possıvel alterar opcoes da interface e dos modulos em tempo real, sem existir a necessidade de
reiniciar o sistema. A implementacao desta feature foi necessaria no sentido de testar quais seriam os
canais mais indicados para a representacao dos dados, as suas caracterısticas podem ser alteradas
em tempo real e ajudam os utilizadores na analise do sistema. Estas opcoes nao foram testadas pelos
utilizadores nos testes realizados uma vez que a sua interpretacao iria ser diferente de acordo com
as alteracoes que cada um realizasse no teste. A utilizacao desta feature num contexto real poderia
ter impactos significativos na analise dos sistemas (por exemplo, mudar a densidade dos quadrados no
Scatterchart (seccao 4.3.2) ajuda interpretar o debito recebido). Abaixo do grafico existe um conjunto de
opcoes (ilustrado na figura 4.7) para o chart e respetivos modulos alterarem alguns dos seus atributos,
estas ferramentas sao geradas automaticamente apos a instanciacao de cada objeto. No caso do Chart
e possıvel pausar, resumir e alterar a cor de fundo.
4.3.2 Modulos
A criacao de cada modulo deve ter, por definicao, alguns metodos e caracterısticas semelhantes entre
todos, por essa razao existe uma classe abstrata a qual todos os modulos herdam a sua definicao.
Caracterısticas como o intervalo de tempo, escalas, etc. fazem parte deste modulo e devem ser es-
pecificados na inicializacao. Dos metodos principais para cada modulo fazem parte o Draw, Update e
MouseEvent.
A inicializacao de cada modulo requer, por motivos obvios, que seja atribuıdo um Chart, sem ele
nao e possıvel definir aspetos fundamentais da representacao dos dados como o domınio vertical.
40
Figura 4.7: Opcoes geradas por cada objeto. Chart, Barchart, Linechart, Scatterchart da esquerda paraa direita respetivamente.
E tambem fundamental definir aspetos relevantes para o contexto do problema, como por exemplo
o intervalo de tempo entre o inicio e o fim do modulo (deltaRange) e o seu ındice para ser possıvel
posicionar cada modulo (existindo excecoes a este criterio os modulos que agregam toda a informacao
recebida desde o ınicio da visualizacao e que se devem encontrar o mais a esquerda possıvel do Chart
para nao existir perda de contexto).
Para alem dos seus tres principais metodos, os modulos partilham outras semelhancas, a principal
e a sua largura que esta dividida pelo numero de modulos contidos na classe Chart, cada largura e
uniforme e calculada de acordo com a formula: module.width = chart.width/(chart.modules.length +
1). Quando existe a insercao de um novo modulo este metodo e recalculado para todos os modulos
ja existentes, assim cada um ira partilhar a mesma largura dos outros. A uniformidade desta largura
permite ao utilizador ter uma nocao exata dos intervalos existentes nas diferentes seccoes do grafico, se
existissem modulos com diferentes tamanhos o utilizador facilmente poderia ser induzido a erro dados
os intervalos de tempo existentes. Imaginando um modulo com um intervalo de tempo de 15 segundos
e tamanho 400 pixeis, e outro com um intervalo de 60 segundos e 50 pixeis, e evidente o segundo
teria mais dificuldade em apresentar a informacao em alturas de elevado debito e a informacao seria
condensada num espaco muito pequeno com um intervalo de tempo grande, podendo levar a analises
erradas do sistema como falsa percecoes de fluxo ou tendencias nos dados.
O facto da interface VisMillion ter uma representacao dinamica (tempo real) da informacao faz com
que o seu fluxo navegue entre os modulos. Por este motivo tem de existir uma maneira de tornar esta
navegacao percetıvel ao utilizador, isto significa que os dados devem percorrer continuamente e sem
disrupcoes os graficos de maneira fluıda. Este metodo e realizado atraves do timestamp transmitido
pelo Chart na altura do update de cada modulo, dado que o timestamp e o mesmo para cada modulo
e possıvel calcular atraves da escala horizontal de cada grafico a posicao associada a um determinado
ponto no tempo. Por exemplo, um Chart inicializado dois modulos, Linechart e Scatterchart em que
cada um tem deltaRange de 15000 e 30000 milissegundos e ordenados da esquerda para a direita
respetivamente. Imaginando que o Chart transmite um timestamp com o valor 0, o intervalo de ambos
41
e calculado pela formula:
endT ime = timestamp−length∑i=index
module[i].deltaRange
startT ime = endT ime− this.deltaRange
O endTime corresponde ao tempo mais recente e startTime ao tempo mais antigo. Desta forma
e possıvel criar uma progressao suave dos dados e evitar que ocorram saltos entre os modulos (o
endTime do Linechart e igual ao startTime do Scatterchart uma vez que sao a fronteira entre ambos
os graficos. Quanto maiores forem os FPS mais suaves sao as transicoes, apesar de a partir dos 20/30
frames por segundo ja nao existir uma percecao de lentidao e saltos nas animacoes da interface.
A transicao entre cada modulo pode ou nao ser realizada de maneiras diferentes, caso nao seja pro-
gramado no modulo uma transicao especıfica a partir do momento que a informacao deixa de pertencer
a um determinado modulo desaparece do mesmo. Este princıpio viola a manutencao do contexto do
utilizador e e importante realizar tarefas que permitam que a informacao seja transmitida de um modulo
para o outro de maneira explicita. Na explicacao de cada modulo e enunciada a tarefa que previne esta
situacao.
Os modulos enunciados de seguida foram implementados de acordo com as especificacoes e ideias
que surgiram no desenho da interface. Num total de 3 modulos implementados com os seguintes
idiomas: Barchart, Linechart e Scatterchart. Estes modulos foram escolhidos pois cada um permite
analisar requisitos distintos que eram necessarios a este trabalho, entre eles a analise de fluxo, valores
medios, agregacoes atıpicas, intervalos de valores onde existem mais quantidade de pacotes, medias,
maximos, mınimos, entre outros.
Para alem disso cada a maioria das pessoas esta mais habituada a visualizar este tipo de graficos no
seu dia-a-dia a comparar com graficos de rede, mapas, etc. Estes idiomas de visualizacao preenchem
os requisitos necessarios para posteriormente serem avaliados.
Barchart
O modulo Barchart e o unico que nao possui o requisito de intervalo de tempo uma vez que acumula
todos os dados desde a instanciacao do mesmo e o tempo menos recente do seu modulo vizinho
(modulo a direita). A figura 4.8 ilustra um exemplo de representacao deste modulo.
As barras dispostas na horizontal representam a frequencia dos dados num determinado intervalo
de valores. O numero de barras e especificado pelo utilizador na criacao do modulo e nao e possıvel
ser alterado durante a visualizacao uma vez que iria existir uma perda do contexto da informacao. Esta
apresentacao da informacao revela uma acumulacao da informacao e consequentemente um fenomeno
de agregacao que leva o utilizador a entender os intervalos onde existiram mais pacotes com um de-
terminado valor, a sua implementacao tem em conta a manutencao do contexto temporal de toda a
informacao ja recebida ate ao momento e tornando a analise da informacao mais completa a longo
prazo.
42
Figura 4.8: Barchart
A filtragem da informacao recebida por este modulo e realizada apos uma divisao dos elementos
em cada barra respetiva, se existir novos dados a adicionar a cada barra e realizada uma animacao
suave do aumento gradual da barra e existe um ’blink’ da mesma, assim o utilizador e informado que
existiram novos dados a entrar naquele intervalo. Esta implementacao foi relevante no sentido em que
era necessario dar a entender os momentos em que existiu mais debito recebido num determinado
momento, quanto maior o numero de vezes que a barra pisca por segundo, mais informacao esta a
ser recebida nesse intervalo, dando a percecao dos momentos de maior fluxo. Por outro lado esta
caracterıstica de adicao de elementos as barras leva o utilizador a compreender quais sao as barras
que estao a receber informacao naquele determinado momento, como existe uma transicao suave de
incremento do tamanho de barra os utilizadores poderiam ser induzidos a erro no momento em que
aquele intervalo recebeu um pacote ou nao, este ’blink’ previne estas falsas interpretacoes. Para alem
destas razoes o facto de existir uma mudanca na cor da barra associada ao aparecimento de novos
pacotes naquele intervalo torna a analise do utilizador mais facil neste grafico uma vez que este evento
pode ser notado a qualquer momento da visualizacao.
E de notar que o eixo horizontal deste modulo, ao contrario dos outros nao representa o tempo mas
sim uma variavel quantitativa, esta escala e apresentada na parte superior do modulo com a quantidade
de pacotes recebidos em cada intervalo. No posicionamento da legenda desta escala e tido em conta
o contexto visual do utilizador, uma vez que na parte de baixo do grafico sao apresentadas as escalas
temporais, optou-se por nao misturar esta escala com as outras para nao criar uma analise incorreta
do utilizador aos valores apresentados, assim do lado de cima e apresentada a escala com os valores
43
das quantidades de pacotes recebidos e nos outros modulos em baixo e apresentado o valor temporal
da separacao entre cada modulo.
Uma vez que a quantidade de informacao recebida pode exceder a escala horizontal existe uma
percentagem que define o limite de largura que as barras podem ter (maxWidth) e consequentemente
processar um reajustamento do domınio horizontal, desta forma, quando alguma das barras atinge esta
percentagem o domınio superior aumenta na proporcao de dominio + (dominio ∗ (1 − percentagem).
Esta percentagem pode ser alterada em tempo real atraves das opcoes geradas pelo modulo assim
como a cor das barras.
Este modulo tem necessariamente de se encontrar o mais a esquerda possıvel do Chart uma vez
que agrega toda a informacao recebida pela interface, caso isto nao ocorresse haveria uma perda de
contexto temporal pelo facto do eixo horizontal ser diferente dos restantes modulos. Por este motivo
a transicao dos dados de um modulo para outro tambem pode ser realizada de acordo com o tipo
do modulo vizinho (prevenindo a perda de contexto e a informacao desvanecer repentinamente do
utilizador) no caso do modulo vizinho ser o linechart as barras estao dispostas com a sua origem da
direita e crescimento para a esquerda e sempre que e recebido um novo pacote neste modulo as barras
piscam. Por outro lado, caso o modulo vizinho seja um scatterchart esta disposicao pode ser invertida
e os pontos caiem sobre as barras dando a nocao de rececao dos pontos e criando uma degradacao
dos pontos suave.
Para o utilizador interagir com este modulo utiliza o rato sobre as barras de maneira a obter o seu
valor, e realizada uma conversao da posicao do rato de modo a descobrir qual e a barra que o utilizador
quer obter mais detalhes, de seguida e apresentada a frequencia dos pacotes para esse objeto no
formato Intervalo - Valor. A figura 4.9 ilustra um exemplo de interacao com este modulo.
Figura 4.9: Mousehover do Barchart
A interacao ocorrida procura ser o mais simples possıvel e nao prejudicar a interpretacao de outras
visualizacoes, daı a informacao obtida ser apenas a informacao relativa a barra sobreposta.
Em suma este modulo caracterizado pela tabela 4.3:
44
Tipos dedados
Quantitativo para os intervalos de valores e Quantitativo para afrequencia dos pacotes
Codificacao As barras correspondem os elementos distribuıdos por um intervalo devalores e a sua frequencia nesse intervalo
Tarefas Procurar e comparar a frequencia de valores recebidos pelo modulo
Escala A escala e definida a priori pelo utilizador e vai aumentado pela per-centagem (maxWidth) definida pelo utilizador
Tabela 4.3: Caracterısticas do modulo Barchart
Linechart
O modulo Linechart comporta um tipo de agregacao dos pontos correspondentes ao seu intervalo de
tempo. A principal tarefa deste modulo e inferir tendencias ao longo do tempo. Inicialmente a sua
funcao era ligar todos os dados e criar uma linha unica mas rapidamente percebeu-se que quanto mais
elevada a quantidade de pontos menos percetıvel era a curva e nada se conseguia interpretar dessa
visualizacao, a figura 4.10 ilustra este caso.
Figura 4.10: Linechart com ligacao a todos os pontos
Por este motivo optou-se por criar dois estados do modulo, Alto (fig. 4.13) e Baixo fluxo (fig. 4.11), o
modo de Baixo Fluxo permite que os pontos sejam ligados por uma linha enquanto o estado Alto Fluxo
realiza uma agregacao dos dados. Estes estados nao podem coexistir uma vez que a sobreposicao
de ambos os graficos levaria a uma desorganizacao da visualizacao e perca de contexto por parte do
utilizador. Assim existiu a necessidade de criar um interruptor que alternasse entre os dois modos em
tempo real consoante o fluxo de dados que esta a ser recebido, num trabalho futuro seria interessante
tornar este mecanismo automatico e que a sua transicao ocorresse de maneira gradual.
Este modulo idealmente nao deve ser utilizado o mais a direita do Chart uma vez que a informacao
45
Figura 4.11: Linechart em fluxo baixo
representada pode confundir o utilizador ao analisar o fluxo da informacao (a interpretacao do numero
de pacotes recebidos e mais difıcil). Por outro lado, a analise das tendencias dos dados sao notadas
atraves deste tipo de visualizacoes e compreendidas as subidas e descidas de valores medios de
acordo com o desnıvel das linhas ao longo do tempo.
Uma vez que e ligacao de pontos muito juntos entre eles nao favorece uma visualizacao decente ao
utilizador decidiu-se dividir o grafico em seccoes especificadas na inicializacao do Linechart (variavel
boxPlotSteps). Nestas seccoes e calculado o seu intervalo de tempo e posteriormente gerado um
diagrama em caixa (BoxPlot), este calculo ajuda a entender qual a distribuicao dos dados quanto a sua
concentracao, simetria e existencia de valores fora do normal. Neste BoxPlot e calculado o maximo,
mınimo, 1o e 3o quartil e a mediana do intervalo da seccao, estes dados sao guardados num dicionario
onde se junta o timestamp que se encontra entre o intervalo dessa divisao. A figura 4.12 ilustra os
Boxplots lado a lado, o ponto medio de cada categoria e ligado formando varias linhas que dao origem
a forma final do modulo (figura 4.13).
A criacao destes BoxPlots necessita que existam dados a serem processados antes da sua chegada
ao modulo, caso contrario iriam existir saltos abrutos na formacao das linhas. O modulo realiza calculos
entre dois intervalos de tempo, isto significa que no BoxPlot mais a direita os seus valores teriam
de ser recalculados enquanto o seu intervalo estivesse fora do domınio, isto porque estao sempre a
chegar novos pacotes ao modulo. Para salvaguardar este problema os BoxPlots sao gerados antes de
atingirem o domınio do modulo. Assim a seccao que ainda nao faz parte do domınio temporal pode ir
sendo atualizada sem ser apresentada. Num caso natural esta solucao e eficaz se este modulo nao
estiver o mais a direita do Chart porque os dados ja estao na interface e e possıvel aceder aos seus
46
Figura 4.12: Divisao de seccoes dos diagramas em caixa
Figura 4.13: Linechart
valores e realizar o seu calculo, porem no caso de este ser o modulo que apresenta a informacao
mais recente e necessario criar um espaco de delay ate a informacao ser apresentada para que estes
calculos possam ser feitos. Este espaco de delay e implementado pelo Chart e e definido pelo utilizador
na sua instanciacao (variavel selfDelay ).
A area entre o 1o e 2o quartil e a mediana e preenchida por cores para tornar mais apelativa e intui-
tiva a visualizacao deste modulo. A linha da mediana e mais espessa que as restantes para simbolizar
a tendencia media global. Os maximos e os mınimos sao tambem representados por uma linha que
47
pode ser representada ou nao de acordo com as preferencias do utilizador.
Para manter o contexto e a tornar o sistema mais user-friendly adaptou-se este modulo para poder
coexistir com o Scatterchart a sua direita (modulo explicado na seccao seguinte). Foi programado para
caso existisse esta relacao a visualizacao comportar-se de maneira ligeiramente diferente ao normal.
Esta alteracao consistiu em criar um desvanecimento dos pontos provenientes do Scatterchart de ma-
neira gradual e suave, assim os pontos nao desaparecem de um momento para o outro, na figura 4.13
conseguimos perceber esta degradacao gradual.
Existem tambem opcoes que podem ser alteradas em tempo real (ilustrada na figura 4.7). E possıvel
trocar entre os fluxos para que o utilizador consiga entender consoante a carga de pacotes que esta a
ser recebida pelo modulo qual e a melhor visualizacao a ter. As cores das linhas e areas pode tambem
ser alterada antes ou durante a visualizacao.
A interacao feita pelo cliente neste grafico corresponde ao mouse hover nas seccoes coloridas que
apresenta a tooltip com a informacao do maximo, mınimo, mediana, 1o e 3o Quartil de cada seccao,
como no Barchart esta interacao tenciona ser o mais simples e concreta possıvel apresentando apenas
a informacao relevante a seccao sobreposta. E realizado um mapeamento entre a posicao do rato e
o intervalo que o utilizador quer visualizar e aparece tambem no topo do modulo o timestamp desse
momento, a figura 4.14 ilustra esta interacao.
Figura 4.14: Mousehover do Linechart
As caracterısticas deste modulo sao descritas pela tabela 4.4:
Tipos dedados Ordinal para o tempo e Quantitativo para o valor pacotes
Codificacao
Em Baixo fluxo a linha representaa ligacao entre todos os pontos.Em Alto fluxo e a representacao agregada dos pacotes.Mediana, quartil 25% e 75%, e maximos e mınimos por seccao
Tarefas Verificar a tendencia dos valores ao longo do tempo
EscalaA escala e definida esta definida pelo Chart e o intervalo detempo e calculado de acordo com o ındice do grafico e respe-tivo deltaRange
Tabela 4.4: Caracterısticas do modulo Linechart
48
Scatterchart
O Scatterchart representa os todos os pacotes recebidos atraves de pontos posicionados de acordo
com o seu valor.
Escolheu-se este idioma porque e o que melhor representa o tipo de fluxo que esta a ser trans-
mitido, dado que quantos mais pontos existirem maior o fluxo, e tambem pelo detalhe realizado na
representacao, mostrando todos os pacotes recebidos. E por este motivo que o seu posicionamento
deve ser feito o mais a direita possıvel, seguindo o princıpio de que a informacao deve ir sendo agre-
gada ao longo do tempo faz sentido que o modulo que apresenta maiores detalhes esteja nesta posicao.
Por outro lado podem ser programados outros modulos com a mesma funcionalidade e caracterısticas
diferentes.
Existem dois estados consoante o fluxo que esta a ocorrer, mas ao contrario do Linechart estes
podem coexistir. O estado de Baixo Fluxo representa os pontos na sua mais simples forma, a funcao de
mapeamento indica a posicao e posteriormente sao desenhados cırculos nesses sıtios. O Alto Fluxo
representa um mapa de calor (heatmap) as zonas onde existem maiores concentracoes de pontos,
sendo uma fonte de analise de padroes e correlacoes entre dados. Este heatmap e representado por
quadrados (fig. 4.15) cuja dimensao e previamente estipulada na instanciacao do modulo. Atraves deles
o utilizador consegue ter uma percecao das zonas onde ocorreram mais eventos numa determinada
altura.
O tamanho dos pontos e definido pelo utilizador, esta caracterıstica permite apresentar os pacotes
de uma maneira mais vincada, ou caso contrario, caso exista um debito alto os pontos podem ser
menores. O tamanho dos quadrados do heatmap da a liberdade a interface de agregar os pontos numa
area de acordo com as preferencias do utilizador. A escala de cores escolhida nesta implementacao
tem em conta os canais usados para uma representacao de fluxos e evidencia a preocupacao no
cumprimento dos requisitos enunciados na seccao 4.1.1, como e o caso do princıpio de effectiveness e
appropriateness, onde a representacao leva a que o utilizador consiga explorar e inferir padroes sobre
a informacao.
Caso ambos os estados estejam ativos (fig. 4.15) e possıvel compreender o nıvel de detalhe dos
pontos e ao mesmo tempo comparar valores. Por outro lado tambem se consegue identificar outliers
ou agregacoes atıpicas, para isso basta notar que se existirem pontos muito distanciados dos valo-
res medios do fluxo entao ha probabilidade de ter ocorrido alguma lacuna no sistema que esta a ser
analisado e intervir no local da falha.
A interacao realizada com este modulo resulta na sobreposicao do rato nos quadrados que indica
o intervalo de tempo e de valores associado a esse pacote assim como o numero de elementos nele
contido (fig. 4.16)
O calculo dos quadrados e realizado atraves da filtragem, ao contrario dos BoxPlots do Linechart
estes nao precisam ter um acesso precedente aos dados para realizar calculos uma vez que o seu
valor e incrementado a medida que vao aparecendo novos dados em cada intervalo. A intensidade
de cor dos quadrados e definida pela opacidade dos mesmos, uma funcao realiza o mapeamento da
quantidade de dados para um intervalo entre 0 e 1, o utilizador define o domınio da escala que quer
49
Figura 4.15: Scatterchart
Figura 4.16: Interacao ScatterChart
mapear, por exemplo, se o utilizador definir o domınio entre 0 e 300, o valor da opacidade do valor 150
e 0.5.
Para determinar quais sao os pontos que pertencem a cada quadrado e usada uma funcao de filtra-
gem que inicialmente calcula o numero de quadrados por coluna atraves da formula:
chart.width/squareLength de seguida, contabiliza para cada quadrado o numero de ocorrencias que
correspondem aquele quadrado e posteriormente e feito o mapeamento para a cor.
Uma das principais dificuldades inerentes a este modulo e o tempo de desenho de todos os pontos
do grafico, quantos mais pacotes maior o tempo de desenho destes elementos chegando facilmente a
um ponto em que os FPS diminuem drasticamente para valores que ja nao sao aceitaveis de produzir
uma visualizacao eficaz. Uma das alternativas a este problema foi a definicao de um ponto de rotura
onde os pontos deixariam de ser desenhados (o estado Baixo Fluxo nao pode ser habilitado), assim
ja nao existe um ciclo que percorra todos os pontos e consequentemente aumenta a eficiencia do
programa. Uma vez que este momento de rotura depende das especificacoes de cada dispositivo
50
o utilizador deve definir o maximo numero de pontos que se devem desenhar, esta opcao deve ser
escolhida na instanciacao do modulo.
Para alem das opcoes ja descritas existem outros atributos que podem ser atribuıdos no inicio do
Scatterchart e que sao possıveis de alterar em tempo real tais como o raio dos pontos, cor e domınio
de opacidade (ultimo modulo da fig. 4.7)
Em suma este modulo caracterizado pela tabela 4.5:
Tipos dedados Ordinal para o tempo e Quantitativo para o valor pacotes
CodificacaoEm Baixo fluxo cada pacote e representado por um ponto.Em Alto fluxo sao desenhados quadrados que representam umintervalo de valores e de tempo (heatmap)
Tarefas Identificar o padrao de valores e o fluxo da informacao recebida
EscalaA escala e definida esta definida pelo Chart e o intervalo detempo e calculado de acordo com o ındice do grafico e respe-tivo deltaRange
Tabela 4.5: Caracterısticas do modulo Scatterchart
4.3.3 Modulo Outliers
Este modulo foi criado com o intuito de representar os pontos que o utilizador considera que sao valores
atıpicos ou vulgarmente chamados de outliers. Tal como acontece noutros trabalhos [Novotny and
Hauser, 2006], este tipo de dados e tratado em visualizacoes a parte para uma melhor compreensao e
coerencia do sistema.
Para este sistema os outliers sao todos os valores que estao acima do domınio vertical definido
pelo utilizador. Dado que existe esta possibilidade de definir o domınio, o cliente que ira realizar a
visualizacao deve ter uma nocao a priori de que intervalo deve ser escolhido para a interface, e por
esse motivo caso existam pacotes acima desse intervalo estes devem ser representados de tal maneira
que o utilizador possa entender o seu valor e formular uma acao caso seja necessario.
Sendo uma visualizacao que nao requer tanta atencao do utilizador (dado que a presenca destes
valores deve ser rara), a complexidade de representacao deve ser menor que a dos restantes modulos.
Este grafico esta posicionado na parte superior da interface uma vez que os valores nele represen-
tados sao sempre maiores que o domınio (manutencao de contexto). Na figura 4.17 podemos ver a
representacao deste modulo. O modulo ocupa toda a largura Chart permitindo uma visualizacao mais
duradoura dos valores atıpicos ocorridos, dando tempo ao utilizador para analisar num momento opor-
tuno a sua ocorrencia e tomar acoes se necessario.
Figura 4.17: Modulo de Outliers
51
Cada pacote e representado por um ponto com o seu timestamp e valor. Este ponto navega da
direita para a esquerda do grafico de acordo com a implementacao do sistema e desaparece no mo-
mento em que ja nao se encontrar o intervalo temporal estabelecido pelo Chart. Este ponto possui uma
animacao em que aumenta e diminui o seu raio para que possa ser mais facilmente identificado pelo
utilizador. Este aspeto e uma maneira de chamar a atencao do utilizador para valores atıpicos ocorri-
dos que rapidamente o advertem, assim no caso de existirem acoes a tomar devido a esta ocorrencia
a resolucao do problema pode ser realizada o mais rapidamente possıvel.
A filtragem ocorre no momento de update onde se realiza a procura de valores entre valor maximo
do domınio vertical do grafico e o valor maximo que o modulo pode apresentar.
Para que o cliente possa receber mais detalhes relativos a cada ponto deve sobrepor o rato e tera a
informacao do Timestamp (no formato Dia/Mes/Ano, Hora:Minutos:Segundos ) e do respetivo valor.
Este modulo pode ser ou nao ativado consoante a intencao do utilizador na instanciacao do Chart,
o utilizador tem tambem a possibilidade de escolher a altura, threshold maximo do valor vertical, raio
dos pontos.
Resumindo o modulo e caracterizado pela seguinte tabela 4.6:
Tipos dedados Ordinal para o tempo e Quantitativo para o valor dos outliers
Codificacao
Cada outlier e representado por um ponto e sao cri-ados quadrados em volta dos pontos que se tornammais opacos quantos mais pontos existirem na sua area.Em Alto fluxo sao desenhados quadrados que representam umintervalo de valores e de tempo (heatmap)
TarefasIdentificar os valores que sao recebidos fora do padrao naturaldos dados e que merecem ser representados de maneira maisdetalhada
Escala A escala e definida esta definida pelo utilizador e o a posicao notempo definida pelo Chart
Tabela 4.6: Caracterısticas do modulo de Outliers
4.3.4 Modulo Connection
Esta classe e o intermediario entre o servidor e a interface, e ela que faz a ligacao e recebe os dados
que posteriormente sao enviados para o grafico. Por motivos obvios esta classe nao necessita de
passar pela fase de desenho.
E utilizada a biblioteca Socket.io5 para estabelecer a conexao via WebSockets, na instanciacao da
classe e necessario fornecer o IP, porta e o respetivo Chart para onde os dados devem ser transmitidos
(exemplo 4.18). Este sistema baseado em eventos aguarda que sejam recebidas mensagens da parte
do servidor e executa as funcoes associadas a esse tipo de mensagem.
Para a rececao de pacotes de dados cada pacote passa por uma verificacao para saber se contem
um timestamp, caso nao se verifique e adicionado um registo temporal no lado do cliente. Estas duas
opcoes surgiram para saber qual e a maneira mais realista e eficiente de apresentar a informacao e
5https://github.com/socketio/socket.io-client, ultimo acesso 15 Outubro 2018
52
connection = new Connection({
host : ’localhost’,
port : ’8002’,
chart: chart
})
Figura 4.18: Instanciacao da ligacao ao servidor
concluiu-se que se os dados ja vierem com o timestamp incluıdo existe uma maior uniformidade da
informacao, visto que a partir do momento em que se comeca a receber cada vez mais dados mais
semelhantes vao ser os timestamps, coisa que pelo outro metodo nao ocorre. Quando os pacotes com
timestamp sao recebidos passam tambem por uma conversao para o objeto Date nativo do Javascript.
Outra das funcoes desta classe e a possibilidade fazer um pedido ao servidor para enviar o numero
de pacotes por segundo desejado. Num caso natural esta opcao nao faria sentido mas em termos de
avaliacao de eficiencia e desempenho e importante que seja possıvel alterar o fluxo manualmente para
conseguir tirar conclusoes na fase da implementacao e testes da interface. Assim a interface manda
uma mensagem com o assunto ’delay’ (em milissegundos) e indica ao servidor de quanto em quanto
tempo deve ser enviado um novo pacote.
Para alem destas opcoes tambem e possıvel transmitir ao servidor pedidos para pausar e resumir o
fluxo de dados para que o utilizador possa temporariamente analisar com mais detalhe pontos interes-
santes na visualizacao. Uma das desvantagens deste metodo e que posteriormente a pausa, quando
o utilizador resumir o fluxo ira existir uma quebra de contexto proveniente de um salto dos dados para
um intervalo de tempo superior ao que existe no momento.
4.3.5 Animacoes
A realizacao de animacoes e fundamental para uma analise eficaz dos dados, dado que um dos re-
quisitos e tempo real e inevitavel existir movimentacao e navegacao da informacao a medida o tempo
avanca. As tecnicas utilizadas neste trabalho para a preservacao do contexto temporal envolvem a
aplicacao de transicoes nos objetos de cada modulo.
A biblioteca D3 permite realizar estas transicoes atraves de uma interface utilizando tecnicas de
interpolacao de um estado para outro realizando esta tarefa de forma suave nos elementos SVG conti-
dos na pagina.
Este metodo permite que exista uma abstracao a nıvel de como sao realizadas as transacoes.
Contudo nao e possıvel executar estas acoes em Canvas uma vez que nao existem elementos para
evocar mas sim um quadro pintado. Por essa razao existiu a necessidade de criar uma forma de
realizar esta funcao de transicao para o novo ambiente.
Dada a complexidade da tarefa tentou-se minimizar a sua aplicacao utilizando outros metodos para
a transicao suave entre a informacao, porem existem partes do sistema que necessitam fundamental-
mente desta solucao, nomeadamente o incremento gradual das barras do modulo Barchart e o seu blink
53
no momento em que novos dados sao recebidos em cada barra e tambem no aumento e decrescimo
do raio dos pacotes localizados no modulo dos Outliers.
A interpolacao de um estado para outro dos desenhos e feita manualmente com a ajuda da funcao
scaleTime() enunciada na seccao 4.3.1. Na instanciacao do Chart o utilizador indica o tempo em
milissegundos (transition time)das duracoes das transicoes e estas sao iguais para todos os modulos.
Quando ocorre a necessidade de uma transicao e calculado o instante inicial (t0) e o momento em que
a transicao deve terminar (t1 = t0 + transitiontime), posteriormente e atribuıdo o domınio [t0, t1] a
escala (scaleTime()) com uma extensao entre o valor inicial (v0) do elemento e o valor que ele deve
tomar (v1). Depois disto a cada fase de update e com o timestamp que e recebido pelo Chart e
verificado nesse elemento existe alguma escala de transicao associada, caso exista e calculado para
esse elemento o seu valor. Esta escala pode ser atualizada caso o valor final (v1) seja mudado. A partir
do momento em que o timestamp ultrapassar o valor de t1 ou atingir o valor v1 a escala deixa de existir
e consequentemente a transicao termina.
4.4 Demonstracao
Tendo em conta a explicacao detalhada nas seccoes anteriores e possıvel realizar uma demonstracao
do sistema e da sua potencialidade.
Sao referidos os requisitos base que sao avaliados no capıtulo 5, como a verificacao de fluxos,
tendencias, outliers, agregacoes, valores maximos e mınimos, medianas, conjuntos, entre outros. Serao
demonstrados algumas formas de analisar estas caracterısticas e a sua facilidade das identificar.
A utilizacao do Barchart permite uma analise das tendencias consequente do crescimento expo-
nencial das barras a medida que os dados vao sendo recebidos pelo modulo, dando a ideia de que
para um dado intervalo estao a ser recebidos pacotes, e possıvel tambem ter uma nocao da quantidade
de pontos que esta a ser recebida pela rapidez na animacao de crescimento, quanto mais rapido for
este crescimento mais pacotes estao a ser recebidos, e por esse motivo ter uma nocao do fluxo aı
transmitido. Para alem destes aspetos a verificacao de agregados atıpicos pode ser feita neste modulo,
sendo que caso exista uma barra com um crescimento fora do normal e nao regular de acordo com as
restantes e facil notar que existe ali um conjunto de valores que nao estao corretos, imaginemos um
caso em que o padrao medio dos valores varia entre os 30 e 70, e momentaneamente sao recebidos
pontos que variam entre 5 e 10, e possıvel notar esse padrao atıpico atraves deste modulo, a figura
4.19 evidencia um destes casos onde o intervalo 90 a 95 tem claramente um conjunto de agregados de
valores fora do valor medio entre 5 e 70.
Para alem destas caracterısticas a agregacao dos pacotes em barras e importante no sentido em
que e obtida uma referencia dos valores mais frequentes e identificar alturas em que a variacao desses
intervalos e mais verificada. Com isto e possıvel obter a frequencia total dos pacotes e a sua distribuicao
analisando assim se e normal e uniforme, caso nao seja o utilizador pode tomar acoes consoante as
suas necessidades.
Relativamente ao Linechart este para alem de permitir uma analise das tendencias que ocorrem
54
Figura 4.19: Agregacoes atıpicas verificadas atraves do Barchart
nos dados recebidos, tambem fornecem uma ideia dos pontos maximos e mınimos, fazendo com que
seja possıvel obter valores fora do padrao normal dos restantes. A formacao de areas entre o 1o quartil,
mediana e 3o quartil facilitam a nocao de agregacao da informacao nesse intervalo de valores e levam
o utilizador a verificar eficazmente onde existe uma maior concentracao de pontos em determinado
momento. O facto de existir um modo de baixo e alto fluxo ajuda o utilizador a definir quais os mo-
mentos em que a analise pode ser mais intuitiva de acordo com o debito existente, esta caracterıstica
evidencia a adaptabilidade existente na tarefa de processamento de grandes quantidades de dados e
na manutencao do contexto da informacao.
Figura 4.20: Tendencias e valores mınimos e maximos do Linechart
A figura 4.20 apresenta uma demonstracao que destaca a analise da variacao media da informacao
ao mesmo tempo que exibe os valores maximos e mınimos. Por ele conseguimos perceber que existem
pontos que se destacam como sendo fora do padrao natural da informacao, o mınimo no primeiro terco
do grafico e o maximo na parte final do grafico.
O Scatterchart ajuda a compreender uma grande parte das caracterısticas mencionadas anteri-
ormente. Os pontos que representam cada pacote recebido ajudam a compreender as agregacoes
existentes ao longo do tempo fazendo com que o utilizador tenha uma nocao da sua quantidade. Por
outro lado a dispersao destes pontos tambem pode significar outros padroes uteis e ajudar em decisoes
importantes atraves da sua monitorizacao. A variacao dos valores medios pode ser identificada pelo
crescimento gradual verificado durante a navegacao dos pontos. A agregacao de valores atıpicos e
55
tambem notada neste grafico, a partir do momento em que se verifica conjuntos de dados fora do inter-
valo normal dos restantes pontos.
A utilizacao do heatmap associado a este modulo ajuda a compreender os momentos de maior debito
ou menor debito, e realiza de uma maneira mais intuitiva a representacao dos agregados de informacao,
onde o utilizador pode ter em conta quais as situacoes onde ocorreram estes padroes e fazer uma
comparacao com os dados recebidos noutras alturas. Desta forma este modulo comporta medidas
fundamentais na analise de sistemas em tempo real.
Figura 4.21: Tendencias e agregacoes atıpicas Scatterchart
Na figura 4.21 e demonstrado um exemplo de analise da variacao dos valores medios, podemos ver
que o valor medio aumenta pelo heatmap criado, e posteriormente esses valores mantem-se constantes
no final. No canto superior esquerdo e possıvel encontrar uma agregacao atıpica, pelos pontos ou pelo
heatmap da para notar que estes pontos surgem numa zona onde existe pouca concentracao de dados.
Estes tres modulos principais atribuem a interface um grande grau de desempenho na compreensao
do utilizador, contudo a utilizacao do modulo dos Outliers permite um nıvel ainda maior de detalhe
da informacao representado os valores fora domınio inicialmente definido. A representacao destes
elementos pode ou nao ser relevante de acordo com o domınio da informacao a visualizar e por esse
motivo a sua representacao e definida pelo utilizador. Ao existirem valores atıpicos gera-se um ponto
que percorre a totalidade do chart, representado por um ponto em que a sua transicao e composta
por um aumento e diminuicao do seu raio, assim e possıvel estes valores serem mais notados que os
restantes.
No grafico 4.22 realiza-se uma visualizacao de todas as caracterısticas mencionadas em conjunto
inferindo padroes e acontecimentos do dataset recebido pela interface. Analisando o grafico de barras
temos a nocao que a maioria dos valores recebidos ha 45 segundos (aproximadamente 140 pacotes)
atras variam entre os 80 e 90 sendo que tambem existiram valores abaixo desse intervalo. Posterior-
mente no Linechart verificamos os pacotes que foram recebidos dos 45 aos 15 segundos, nota-se uma
diminuicao drastica dos valores neste intervalo para alem de que a concentracao dos pontos se man-
teve sempre no mesmo intervalo. A linha que apresenta os pontos mınimos e maximos evidencia que
existiram picos neste momento. No grafico dos pontos podemos verificar que a tendencia dos dados
volta a ser constante e que o fluxo e menor. Sao apresentados tambem dois valores atıpicos entre os
56
55 e os 15 segundos que podem ser adquiridos de uma forma simples pelo utilizador.
Estas conclusoes podem ser retiradas com a visualizacao simples do grafico, por outro lado a
interacao com os modulos permite um maior grau de detalhe, tornando alguns aspetos menos dire-
tos mais explıcitos ao utilizador.
Figura 4.22: Demonstracao de todos os modulos em conjunto
Foi criado um vıdeo de demonstracao6 para que seja possıvel entender como o sistema funcione
dinamicamente.
Utilizando as opcoes de instanciacao fornecidas pelo utilizador em conjunto com a possibilidade
de alterar caracterısticas de cada modulo em tempo real, o sistema VisMillion proporciona uma ex-
periencia de visualizacao bastante completa em todos os aspetos mencionados anteriormente. A
utilizacao de cada modulo permite a comparacao eficiente de determinados momentos da apresentacao
da informacao e ajuda o utilizador a decidir acoes a tomar em casos reais na monitorizacao de sistemas.
6https://drive.google.com/file/d/14hLs97_kIFi1Vt0NVuy-oyA-uYTfLH8h/view?usp=sharing, ultimo acesso 21 No-vembro 2018
57
58
Capıtulo 5
Avaliacao
Neste capıtulo sao abordadas a tecnicas utilizadas para avaliar o sistema VisMillion, tanto a nıvel de
eficiencia, como de compreensao e qualidade da representacao da informacao. Foram realizados testes
de usabilidade na seccao 5.1 e de eficiencia controlando o fluxo de informacao recebida na seccao 5.2,
ambos os resultados sao apresentados nas seccoes seguintes.
No final de cada seccao sao escrutinados os resultados de ambos os testes e feita uma avaliacao.
E realizada uma analise global da interface implementada (seccao 5.3).
5.1 Testes de Usabilidade
A interface VisMillion apresenta visualizacoes de grandes quantidades de dados em tempo real, de
modo a que os utilizadores consigam perceber as tendencias, fluxos, padroes ocorridos na informacao.
A disposicao dos modulos lado a lado permite realizar uma agregacao da informacao ao longo do
tempo, dando um contexto temporal da globalidade do dataset ao mesmo tempo que permite uma
descricao mais pormenorizada dos pacotes mais recentes.
A realizacao de testes de usabilidade sao das praticas mais recorrentes em sistemas de visualizacao
[Plaisant, 2004], uma vez que e possıvel receber comentarios dos utilizadores a problemas encontrados
nos programas e posteriormente realizar melhorias ou provar requisitos. Por este motivo estes testes
foram realizados, permitindo responder eficazmente as premissas propostas e encontrar problemas de
implementacao.
A utilizacao de Heurısticas de Avaliacao e um metodo bastante comum na area de HCI, os profis-
sionais em usabilidade avaliam sistemas e verificam se estes cumprem os seus objetivos utilizando
estas heurısticas. Forsell reune num documento [Forsell and Johansson, 2010] uma sumarizacao
destes metodos, sendo que os principais podem ser avaliados neste trabalho como a Codificacao de
Informacao, Accoes Mınimas, Flexibilidade, Ajuda e Orientacao, Organizacao espacial, Consistencia,
Reconhecimento ao inves de lembranca, Prompting, Remocao de valores distrativo e Reducao de da-
taset
Os testes realizados a um conjunto de 21 utilizadores consistiram na visualizacao de datasets gera-
59
dos pelo script descrito na seccao 3.5, e foram criadas tarefas de forma a conseguir inferir o contexto
dos utilizadores nas visualizacoes apresentadas.
Numa primeira fase os utilizadores sao submetidos a um questionario de reconhecimento das suas
caracterısticas e capacidades de visualizacao, assim e possıvel perceber qual o nıvel de destreza
dos participantes e encontrar utilizadores mais suscetıveis a erros. Posteriormente e realizada uma
demonstracao aos utilizadores e seguidamente sao realizados quatro testes, cada um com um proposito
distinto. No final e pedido aos utilizadores para preencherem um questionario final de satisfacao relaci-
onado com os testes realizados.
5.1.1 Metodologia
Antes de pensar no tipo de informacao e testes a realizar foi necessario procurar um conjunto de dados
onde o domınio fosse percetıvel e amigavel ao utilizador, desta forma nao se compromete o feedback
dos utilizadores com base na informacao visualizada mas sim na representacao dessa informacao.
Durante a implementacao utilizaram-se datasets de transacoes de BTC mas rapidamente percebeu-se
que este conjunto nao seria o mais indicado para a realizacao dos testes uma vez que o domınio varia
entre valores muito baixos (as transacoes de bitcoin geralmente sao valores baixos) e tambem porque
a representacao de valores em notacao cientıfica requer conhecimento previo de saber analisar esses
valores, por estes motivos a indicacao de valores por parte do utilizador poderia nao ser tao eficaz.
Assim optou-se por utilizar datasets gerados por um script automatico (seccao 3.5) que permitiram
criar padroes, outliers, tendencias e variacoes de fluxo. O domınio encontrado para criar uma ligacao
mais simples com o utilizador foram as vendas de uma grande cadeia de supermercados, e referido ao
utilizador que em paıses como os Estados Unidos onde existem milhares de superfıcies comerciais a
operar diariamente ha necessidade de monitorizar as vendas globais das lojas. Cada pacote recebido
pela aplicacao representava uma venda num determinado momento e com um determinado valor, o
domınio das vendas varia entre os 0 e 100 mas eventualmente poderao existir outliers acima desses
valores. Por definicao nao existem vendas com valores negativos.
Foi criado um documento (Apendice A) que e apresentado aos utilizadores de modo a perceberem o
proposito da aplicacao que iriam testar assim como o domınio, tarefas e explicacao das representacoes.
De acordo com SUS [Brooke, 2013] devem ser realizados dois tipos de questionarios, o primeiro sobre
o perfil do usuario realizado antes do teste e outro sobre sobre a satisfacao do utilizador no final. Deste
modo e possıvel caracterizar a populacao observada em termos de demografia, e sua experiencia de
visualizacao e posteriormente verificar os princıpios de Expressiveness, Effectiveness e Satisfacao.
Nos tres primeiros testes foi pedido aos utilizadores que identificassem as alteracoes mencionadas
antes do testes, posteriormente foi utilizado o metodo Think Aloud [Lewis and Rieman, 1993] no ultimo
teste onde os participantes foram incentivados a explicar a interpretacao dos dados apresentados com-
preendendo quais as suas maiores dificuldades na sua utilizacao.
Apos a realizacao de todos os testes fez-se uma analise estatıstica da informacao recolhida e que
e descrita nas seccoes seguintes.
60
5.1.2 Questionario
O questionario inicial recolhe a informacao relativa as caracterısticas pessoais do utilizador (sexo, idade,
etc.) e a sua experiencia em visualizacao (numero de vezes que utiliza o computador e idiomas de
visualizacao conhecidos), com base nestas informacoes e possıvel inferir se o utilizador possui um
conhecimento adequado a realizacao do teste.
As perguntas de caracter demografico ajudam a distribuir os utilizadores de uma maneira uniforme,
fazendo com que seja possıvel ter pessoas de diferentes faixas etarias e sexo a utilizar o sistema e
a tornar a aplicacao independente destes aspetos. A pergunta relativa aos idiomas de visualizacao
que o utilizar conhece permite fazer uma abordagem diferente nos casos de utilizadores que nao estao
acostumados a visualizacao de informacao, as opcoes dadas sao compostas pelos idiomas mais sim-
ples como barcharts, linecharts, scattercharts, piecharts, heatmaps, entre outros. O conhecimento de
pelo menos 3 tipos de graficos e fundamental uma vez que a aplicacao utiliza estas abordagens para
representar a informacao.
O questionario final realizado apos os testes recolhe os graus de satisfacao e compreensao dos
utilizadores a interface apresentada. Questionando as pessoas se a realizacao das tarefas foi facil e
se as transicoes e visualizacoes sao intuitivas na sua globalidade. Existe tambem uma seccao, onde
os utilizadores podem descrever os pontos negativos e positivos da sua experiencia e deixar melhorias
ou sugestoes da aplicacao. Por ultimo cada utilizador deve tambem revelar se a aplicacao se enquadra
num sistema de monitorizacao de grandes quantidades de dados em tempo real.
Ambos os questionarios encontram-se no Apencide B.
5.1.3 Testes
Um total de 21 utilizadores, entre amigos e colegas realizaram testes na interface VisMillion. Cada
um foi submetido ao mesmo procedimento e utilizando o mesmo datasets, sendo que o objetivo era
verificar se a aplicacao era simples e intuitiva ao ponto de ser percetıvel por utilizadores que nunca
tinham utilizado o sistema antes.
Antes de comecar os testes foi apresentado um documento com a explicacao de como funciona
a interface e quais os seus objetivos assim como o domınio a ser visualizado e os tipos de graficos
apresentados (Apendice A), pediu-se tambem ao utilizador para realizar o primeiro questionario de
reconhecimento.
Apos estes procedimentos realizou-se uma demonstracao da interface que consistia na visualizacao
de um dataset de transacoes de bitcoin permitindo que existisse interacao e aprendizagem do sistema.
Para alem disso nesta fase o utilizador e incentivado a tirar questoes sobre a interface para que exista
o mınimo de interferencia com os testes a realizar na fase seguinte.
Os testes realizados contemplam os tres tipos de modulos de visualizacao apresentados na seccao
4.3.2, o primeiro localizado mais a esquerda e o Barchart, a meio o Linechart e a direita o Scatterchart,
configurados com um domınio vertical no intervalo [0, 100] numa escala linear. O Scatterchart comple-
menta um intervalo temporal de 15 segundos, enquanto o Linechart possui um intervalo temporal de
61
30 segundos. Assim o utilizador e capaz de avaliar as diferentes visualizacoes e e possıvel analisar se
cada tipo de idioma e util e qual a necessidade de ter diferentes nıveis de representacao da informacao,
desde dados mais detalhados a direita ate a sua agregacao atraves de metodos estatısticos (como
medianas e frequencias). A ideia e quem esta a visualizar conseguir entender os dados que estao a ser
recebidos em tempo real ao mesmo tempo que tem uma visao global de toda a informacao recebida
ate ao momento sem perder o contexto da mesma.
A fase de testes e composta pela visualizacao de quatro tipos de datasets diferentes, usando o
domınio das vendas de supermercados e pedido ao utilizador que em cada teste identifique elemen-
tos da visualizacao e sao recolhidas as suas respostas e respetivas timestamps, posteriormente esta
informacao e apresentada na seccao 5.1.4 e feita uma analise dos mesmos. A timestamp recolhida e
calculada entre o momento em que o primeiro dado e recebido pela interface e a altura em que o utiliza-
dor identifica os elementos pedidos pelo teste. Cada registo e guardado numa lista na zona de cookies
do browser, este valor e registado pelo tester para nao existir interferencia na analise dos dados do
utilizador. Desta forma e possıvel saber os tempos medios que cada tarefa demora ate ser realizada e
quais as possıveis dificuldades colocadas pelo sistema.
Teste de Tendencias
Este teste consiste na verificacao da variacao dos valores medios das vendas ocorridas, desta forma o
utilizador e capaz de identificar os padroes e mudancas nos valores das vendas.
E pedido ao utilizador que identifique os momentos em que reconhece que existe uma variacao no
padrao medio do valor das vendas, isto e, quando existe um aumento, decrescimo ou momento contınuo
dos dados o utilizador deve indicar essa alteracao e identificar o seu tipo entre os tres possıveis: ”Au-
mentou o valor das vendas”, ”O valor das vendas diminuiu”, ”O valor das vendas esta constante”.
Quando existe um destes tres tipos de identificacao e recolhido o timestamp desse momento.
Para realizar esta tarefa o utilizador pode analisar o Scatterchart e verificar as variacoes pelo heatmap
gerado pelo mesmo, ou entao utilizando o Linechart e observar a linha da mediana.
Para este dataset foram gerados 7 variacoes, por definicao e ignorada a primeira variacao uma vez
que o utilizador precisa de realizar uma verificacao previa de alguns dados antes de identificar o padrao
seguinte.
A figura 5.1 mostra a historia deste conjunto de dados. A tabela 5.1 representa a informacao da
variacao e dos valores tomados pelo dataset, em que a coluna do estado representa a variacao do
valor medio dos dados (subida, descida ou constante), e a duracao em segundos da respetiva variacao
(valor aproximado), num total de 7 variacoes onde a primeira e descontada. Este dataset tem uma
duracao de aproximadamente 63 segundos.
Teste de Outliers e agregacoes atıpicas
O segundo teste representa a analise dos outliers (valores atıpicos) e agregacoes atıpicas, o utilizador
deve ser capaz de identificar os valores do modulo outliers (seccao 4.3.3) e as agregacoes atıpicas cuja
62
Figura 5.1: Dataset do teste de tendencias
Estado Duracao (segundos)1o Constante 102o Subida 63o Constante 114o Descida 65o Constante 66o Subida 147o Constante 63
Tabela 5.1: Variacoes de tendencias - 1o Teste
sua representacao nao se enquadra com o padrao natural dos valores medios recebidos.
E pedido ao utilizador que visualize o dataset e identifique os elementos que considera como outliers
e o seu respetivo valor assim como as agregacoes atıpicas, isto e, conjuntos de valores que nao se
encontram na media normal dos restantes elementos e o seu intervalo de valores. Quando o utilizador
identifica e recolhido o timestamp desse momento (e de salientar que este momento carece de um
intervalo de erro desde a altura em que o utilizador identifica a alteracao e o tempo em que efetivamente
e registado esse evento).
O utilizador deve utilizar o modulo dos outliers e interagir com a sobreposicao do rato nos pontos
recolhendo assim os outliers. Para as agregacoes o utilizador pode analisar o Scatterchart e recolher
o intervalo atraves da interacao, usando o Linechart tambem pode verificar estas agregacoes mas a
recolha do seu intervalo ja nao e possıvel. A utilizacao do Barchart tambem possibilita a visualizacao
destes agregados quando existe um aumento brusco e significativo de uma das barras, conseguindo
tambem analisar o seu intervalo.
A verificacao destas alteracoes permite determinar se o sistema consegue informar de maneira
clara aos utilizadores os momentos em que ocorrem ”falhas” nos sistemas que estao a monitorizar,
este aspeto e importante na medida em que deve existir rapidez na resolucao deste tipo de problemas
logo estes valores devem ser faceis de captar.
Para este dataset foram gerados 2 outliers e 2 agregacoes atıpicas, a figura 5.2 representa este
conjunto. A tabela 5.2 informa o tipo de ocorrencia, momento em que ocorre (em segundos aproxima-
damente) e o respetivo valor. A duracao deste dataset e de aproximadamente 62 segundos.
63
Figura 5.2: Dataset do teste de Outliers e agregacoes atıpicas
Tipo Momento Valor1o Agregacao 11 [90,95]2o Outlier 25 1503o Agregacao 42 [5,10]4o Outlier 54 110
Tabela 5.2: Outliers e agregacoes atıpicas - 2o Teste
Teste de Fluxos
A verificacao das variacoes de fluxo e importante na medida em que existem alturas onde existe um
maior numero de dados que estao a ser recebidos por unidade de tempo e essa quantidade pode variar
a qualquer instante, sendo que o sistema deve ser capaz de se adaptar a estas alteracoes bruscas e
ao mesmo tempo manter simples o contexto da visualizacao para o utilizador.
Neste teste e pedido ao utilizador que identifique as alteracoes de fluxo que existem durante a
rececao da informacao. Para isso o utilizador deve analisar o dataset e nos momentos em que encontra
um aumento ou um decrescimo da quantidade de dados recebidos por unidade de tempo deve indicar
essa alteracao. Posteriormente e recolhido o timestamp da identificacao.
O modulo Scatterchart ajuda na verificacao dessas alteracoes atraves do seu heatmap, quanto mais
carregada for a cor mais pacotes estao a ser recebidos, caso contrario a quantidade de informacao e
menor. O modulo Barchart tambem permite analisar este fluxo atraves dos ”blinks” das barras, porem
a analise deste fator neste modulo nao e tao eficiente e simples.
O sistema deve ser capaz de dar a entender ao utilizador quando ocorrem mudancas na corrente
dos dados, em dados sistemas de monitorizacao pode ser relevante apresentar esta informacao e tomar
acoes importantes.
Este dataset possui 6 alteracoes de fluxo, a figura 5.3 representa os dados. Na tabela 5.3 estao
dispostos os momentos das alteracoes (em segundos aproximadamente) e o seu estado (aumento ou
diminuicao do fluxo de acordo com o estado anterior). Este dataset tem uma duracao de 59 segundos.
64
Figura 5.3: Dataset do teste de Fluxos
Estado Momento1o Aumento 92o Diminuicao 153o Aumento 244o Diminuicao 365o Aumento 466o Aumento 54
Tabela 5.3: Variacoes de fluxo - 3o Teste
Teste Aberto
O ultimo teste e de natureza mais descritiva e permite ao utilizador descrever a informacao que esta a
visualizar ao mesmo tempo que outros componentes dos modulos sao avaliados. Neste teste e pedido
ao utilizador que visualize um dataset e sao realizadas questoes ao longo do teste.
Antes de iniciar este teste e pedido que o utilizador esteja atento a variacao de fluxo e do valor
medio das vendas, no final da visualizacao devem ser descritos estes dois parametros (ambos os
parametros so variam uma vez, o fluxo comeca alto e diminui ao longo do tempo, e o valor medio das
vendas tambem diminui). O utilizador e incentivado a ir relatando a sua percecao da visualizacao assim
consegue lembrar-se posteriormente destes dois parametros.
A meio do teste o utilizador deve identificar a venda com o valor mınimo e maximo recebidos ate
ao momento, o utilizador deve utilizar a interacao do Linechart para averiguar qual o valor mınimo e
maximo (dado que na altura em que e feita a questao esses valores se encontram nesse grafico).
Posteriormente o utilizador e questionado sobre qual o intervalo de valores onde existiram mais vendas,
para isso deve ser utilizado o Barchart, a maior barra representa esse intervalo que pode ser adquirido
utilizando a interacao de sobreposicao do rato. O intervalo de valores corresponde entre 85 e 90.
Este dataset tem uma duracao de aproximadamente 55 segundos. A figura 5.4 representa a sua
historia.
65
Figura 5.4: Dataset do teste Aberto
5.1.4 Resultados
Nesta seccao sao apresentados os resultados e analises das tarefas resultantes dos testes de usabili-
dade, inicialmente realiza-se a analise de perfil dos utilizadores, posteriormente cada tarefa e analisada
e no final faz-se uma apreciacao dos resultados de satisfacao.
Questionarios de Perfil
Os questionarios de perfil dos usuarios efetuados a 21 pessoas, 17 do sexo masculino e 4 do sexo
feminino. Com uma distribuicao de idades entre os 22 e 29 anos.
Relativamente a frequencia de utilizacao do computador 85.7% revela que usa todos os dias, 9.5% 2 a
3 vezes por semana e 4.8% raramente utiliza computador.
Em relacao ao numero de idiomas de visualizacao conhecidos, realizando uma media do total de idio-
mas conhecidos pelo numero de pessoas resulta de aproximadamente 7 idiomas por pessoa. A figura
5.5 revela a frequencia de cada idioma conhecido pelos utilizadores, num total de 140 selecoes.
Figura 5.5: Frequencia de cada idioma conhecido pelos utilizadores
66
Tarefas
Como referido nas seccoes anteriores, os dados recolhidos em cada teste foram as respostas dos
utilizadores e os respetivos timestamps.
A tabela 5.4 refere as estatısticas da 1o tarefa, podemos perceber que metade das variacoes foram
detetadas por todos os utilizadores (1, 3 e 6), por outro lado alguns utilizadores nao denunciaram algu-
mas das restantes variacoes. Com especial atencao para a taxa de 85.7% da 4o variacao (constante),
alguns referiram que o facto de ser um intervalo pequeno e antes de uma variacao gradual lenta nao era
percetıvel se existiria um valor medio constante naquele intervalo. O momento de identificacao de cada
variacao dos utilizadores varia bastante, podemos verificar isso pela figura 5.6 e pelo desvio padrao,
esta variacao pode dever-se ao facto dos utilizadores utilizarem diferentes modulos para esta analise, o
Linechart permite verificar esta alteracao pela mediana enquanto o Scatterchart pelo Heatmap gerado.
Por outro lado e possıvel verificar que a primeira variacao e a altura em que os utilizadores responderam
mais uniformemente a variacao ocorrida (quanto menor for o desvio padrao mais perto os utilizadores
responderam entre si), contudo o facto ja enunciado anteriormente da diferente analise dos utilizadores
a ambos os graficos torna todos os desvios padroes elevados porque a verificacao destas variacoes
pode ser feita no linechart ou no scatterchart.
Figura 5.6: Boxplot de Timestamps do 1o teste Figura 5.7: Boxplot de timestamps do 2o teste
Variacao dos valores medios1 2 3 4 5 6
Taxa de Sucesso 100% 85.7% 100% 85.7% 95.2% 100%Intervalo [10,16[ [16,27[ [27,33[ [33,39[ [39,53[ [53,63[Mediana 18.5 27.8 35.0 44.3 53.8 65.2
Media 19.6 30.4 38.6 47.2 55.4 65.7Desvio Padrao 4.282 10.65 9.451 9.51 8.61 6.368
Intervalo Confianca (95%) 17.721.6
25.135.7
34.342.9
42.551.9
51.459.5
62.868.6
Tabela 5.4: Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-mente) do 1o teste
Na tabela 5.5 podemos verificar que a 2o tarefa possui uma taxa de sucesso acima de 95% para
todos os eventos. Sendo que apenas uma pessoa dos testes falhou na interpretacao dos outliers e
67
agregacoes atıpicas, este erro pode ter sido cometido por uma falta de compreensao da tarefa realizada.
Os utilizadores utilizaram o modulo dos outliers para adquirir os valores em conjunto com o Heatmap
para as agregacoes. Desde que o pacote da agregacao/outlier foi recebido ate ao momento que o
utilizador a indicou demorou-se em media aproximadamente 8 segundos. Na figura 5.7 verifica-se que
para cada evento existiu tambem entre 1 e 2 outliers na verificacao atempada dos eventos. Porem a
maioria dos utilizadores tiveram um tempo uniforme entre eles. O intervalo de confianca de todos os
eventos varia entre os 5 e 7 segundos de diferenca, sendo que o desvio padrao para os mesmos e
relativamente semelhante (entre os 6.279 e os 7.273) o que pode significar nao existe muita diferenca
entre a analise de outliers e agregacoes e que o instante em que sao encontradas e um intervalo
semelhante.
Outliers e agregacoes atıpicas1 2 3 4
Taxa de Sucesso 95.2% 100% 95.2% 95.2%Momento do outlier (em segundos) 11 25 42 54
Mediana 16.6 30.8 49.0 62.5Media 18.1 33.2 50.5 64.6
Desvio Padrao 6.476 7.273 6.359 6.279Intervalo Confianca (95%) 15.1 21.1 29.8 36.5 47.5 53.5 61.7 67.6
Tabela 5.5: Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-mente) do 2o teste
A 3o tarefa e representada na tabela 5.6 onde se verifica que a taxa de acerto dos utilizadores foi
sempre superior a 90%, uma vez que as mudancas de fluxo sao facilmente analisadas pelo Heatmap
do Scatterchart sendo que verificando o intervalo de confianca de todos os eventos nenhum apresenta
um intervalo superior a aproximadamente 6 segundos. Isto significa que os utilizadores em media
identificam as alteracoes na variacao do debito da informacao (de maneira geral) rapidamente. Pelos
diagramas de caixa (fig. 5.8) e possıvel verificar que existem tambem utilizadores que identificaram
estas mudancas muito mais cedo do que o previsto (outliers inferiores). Nestes casos nota-se que o
desvio padrao e menor que nas outras tarefas, isto pode dever-se a verificacao destes padroes mais
evidente no primeiro modulo e por isso nao existe a necessidade de esperar que a informacao percorra
todo o grafico para analisar esta diferenca. As alturas em que o fluxo aumenta sao as que sao verifi-
cadas mais atempadamente pelos utilizadores (o desvio padrao e maior nos momentos em que o fluxo
baixa em relacao as alturas em que o fluxo aumenta).
Variacao do Fluxo1 2 3 4 5 6
Taxa de Sucesso 100% 100% 95.2% 100% 90.5% 95.5%Inıcio do Fluxo (em segundos) 9 15 24 36 46 54
Mediana 11.5 21.5 30.9 45.9 56.1 63.0Media 13.1 23.7 32.2 47.0 56.5 62.9
Desvio Padrao 4.635 5.489 3.397 5.630 4.348 2.283Intervalo Confianca (95%) 10.9
15.221.226.2
30.733.8
44.449.6
54.458.6
61.964.0
Tabela 5.6: Estatısticas de tempo (em segundos) e sucesso (utilizadores que responderam correta-mente) do 3o teste
68
Figura 5.8: Boxplot de Timestamps do 3o teste
No 4o teste de caracter mais aberto a pergunta da identificacao dos valores maximos e mınimos
67% dos utilizadores identificou corretamente o valor mınimo e 76% o valor maximo.
A questao relativa ao intervalo onde existiram maiores vendas 90.5% dos utilizadores respondeu cor-
retamente que o intervalo seria entre os 85 e 90. Os dois utilizadores que nao o fizeram optaram por
responder, de certa forma, corretamente utilizando um intervalo mais abrangente, entre 80 e 100, uma
vez que o intervalo entre 80 e 85 possuıa uma quantidade muito ligeiramente inferior ao intervalo maior.
Relativamente a analise completa do dataset e as questoes relacionadas com o fluxo e o valor medio
verificado ao longo da visualizacao desta tarefa, todos os utilizadores conseguiram responder cor-
retamente que o debito diminuiu ao longo do tempo enquanto 95.2% responderam corretamente a
diminuicao da variacao do valor medio dos dados. Nenhum utilizador errou no estado de fluxo ou
variacao, sendo que apenas um se esqueceu de um dos estados aquando da pergunta e nao conse-
guiu voltar a lembrar-se, devido as restantes perguntas realizadas.
Avaliacao do Utilizador e comentarios
Para alem das metricas retiradas das tarefas, realizou-se um questionario de satisfacao em que o
utilizador respondeu a perguntas relacionadas com o sistema. Os utilizadores utilizaram uma escala
de 1 a 5 em diferentes questoes. Numa primeira fase sao feitas 6 questoes relacionadas com os
testes e a facilidade ou percecao dos mesmos. Posteriormente sao realizadas outras perguntas sobre
a interface em si e no final existem 3 perguntas de resposta aberta que permitem aos utilizadores
tecerem comentarios sobre o sistema.
As perguntas sao enunciadas:
• 1o - ”As mudancas de fluxo/debito de vendas sao percetıveis?” (fig. C.1)
• 2o - ”E facil de identificar valores atıpicos/outliers nas vendas?” (fig. C.2)
• 3o - ”E facil de identificar variacoes nos valores medios das vendas ocorridas?” (fig. C.3)
• 4o - ”E facil de localizar onde existem maiores agregacoes de vendas?” (fig. C.4)
69
• 5o - ”Ao longo do tempo, e percetıvel qual o intervalo de valores em que existiram mais vendas?”
(fig. C.5)
• 6o - ”E facil de entender quais os valores maximos e mınimos de vendas num determinado mo-
mento?” (fig. C.6)
• 7o - ”A transicao de um idioma/modulo para outro e intuitiva?” (fig. C.7)
• 8o - ”E facil de compreender os intervalos temporais de cada idioma/modulo?” (fig. C.8)
• 9o - ”O sistema e facil de entender?” (fig. C.9)
• 10o - ”O sistema e facil de interagir?” (fig. C.10)
• 11o - ”O sistema e facil de aprender?” (fig. C.11)
A distribuicao das respostas tambem pode ser encontrada no apendice C. A tabela 5.7 apresenta
as media, mediana, desvio padrao e intervalo de confianca para cada pergunta. Na figura 5.9 existe
uma representacao visual destes resultados, facilitando a compreensao e analise dos mesmos, a linha
vermelha de cada boxplot representa a mediana e os asteriscos os outliers.
Estatısticas do Questionario1 2 3 4 5 6 7 8 9 10 11
Mediana 5 5 5 5 5 4 5 5 5 5 5Media 4.81 4.95 4.62 4.95 4.76 4.19 4.67 4.29 4.52 4.57 4.67
Desvio Padrao .402 .218 .498 .218 .436 .873 .577 .845 .602 .676 .577Intervalo Confianca (95%) 4.63
4.994.855.05
4.394.85
4.855.05
4.564.96
3.794.59
4.404.93
3.94.67
4.254.80
4.264.88
4.404.93
Tabela 5.7: Estatısticas das respostas dos utilizadores aos questionarios
Nas perguntas 1 e 2 pode-se verificar que os utilizadores responderam 5 excetuando alguns outliers
(figura 5.9), pelo desvio padrao e possıvel verificar que existe alguma homogeneidade destas respostas
e concluir que a partir da amostra verificada o intervalo de confianca de 95% tem valores superiores a
4.
Os utilizadores consideraram que a visualizacao das variacoes medias (pergunta 3) e percetıvel, o seu
intervalo de confianca varia entre os 4.39 e 4.85. Nas perguntas relativas a verificacao de fluxos e
quantidades de vendas (perguntas 4 e 5) os utilizadores responderam valores entre os 4 e 5 sendo que
o seu desvio padrao abaixo dos 0.5 revela uma certa homogeneidade na amostra.
A pergunta 6 relativa a verificacao de pontos maximos e mınimos e das tarefas com classificacao mais
baixa a comparar com as restantes, e a sua mediana encontra-se nos 4, o seu desvio padrao e tambem
o mais elevado concluindo que alguns dos utilizadores acharam a tarefa menos difıcil que outros.
Os utilizadores acharam que a mudanca entre idiomas e intuitiva dando uma classificacao com um
intervalo de confianca entre os 4.4 e 4.93. A interpretacao dos utilizadores aos intervalos temporais
existentes revelam um intervalo de confianca mais baixo em relacao aos restantes (excetuando a per-
gunta 6), porem a sua mediana segue a regra das restantes contendo uma classificacao de 5.
70
As tres ultimas perguntas tem valores muito semelhantes, sendo que as medias se encontram rela-
tivamente proximas e os seus intervalos de confianca tambem, considerando assim que o sistema e
facil de interagir, entender e aprender para utilizadores que nao estao familiarizados com o domınio da
aplicacao. Podemos tambem verificar pelos boxplots que da pergunta 1 a 5 nao existiram classificacoes
abaixo de 4 e que apenas a pergunta 6 contem uma classificacao para 2. As restantes tem valores
mınimos em 3 e todas elas tem o terceiro quartil na posicao 5.
Figura 5.9: Frequencia de cada idioma conhecido pelos utilizadores
Como referido foram tambem realizadas perguntas de resposta extensa. A primeira pergunta foi
”Quais foram as suas maiores dificuldades na utilizacao da interface?”ao que a maioria dos utili-
zadores evidenciou o facto da sobreposicao dos elementos ser difıcil uma vez que a informacao estava
em constante andamento, principalmente no segundo modulo (linechart) onde a interacao so e possıvel
na area pintada, por esse motivo a obtencao dos valores maximos e mınimos tornava-se complicada.
Outro utilizador revelou alguma dificuldade na transferencia dos dados do Linechart para o Barchart
dado que as barras cresciam automaticamente.
A pergunta ”Que aspectos achou mais faceis/intuitivos na interface?”o maior consenso que
existiu foi na facilidade da analise de variacoes de fluxo e valores medios, assim como na identificacao
de outliers. Existiram tambem utilizadores que evidenciaram que a utilizacao de diferentes modulos
permitiu comparar a informacao em diferentes intervalos de tempo e que a analise de grandes quan-
tidades de informacao e facilitada pelos idiomas utilizados. Outro utilizador referiu que a visualizacao
de diferentes idiomas permitiu que fossem analisados diferentes medidas estatısticas (medias, quar-
tis, maximos, mınimos) dos mesmos conjuntos de informacao e que esse era um aspeto benefico da
interface.
Na ultima pergunta de resposta aberta pediu-se aos utilizadores para realizarem sugestoes ”Tem al-
71
guma melhoria ou sugestao para o sistema?”. Alguns utilizadores sugeriram melhorias na interacao
com os modulos uma vez que o acompanhamento dos elementos era complicado, existiram utilizadores
que referiram que deveria existir uma opcao para a informacao da tooltip ir sendo alterada em tempo
real sem existir necessidade de movimento do rato e que houvesse uma janela que mostrasse os dados
mais detalhados da zona que esta a ser sobreposta.
Surgiu tambem a ideia de criar uma seccao com os dados e momentos que o utilizador quisesse guar-
dar para posterior analise (uma especie de bookmarks de informacao). Outro utilizador sugeriu criar
uma opcao onde fosse possıvel recuar no tempo e visualizar momentos que ja tivessem ocorrido.
Outra ideia foi a utilizacao de uma especie de heatmap temporal para o grafico de barras, onde as
barras com maior fluxo possuissem cores mais fortes, e no Linechart que a seccao entre o primeiro e
terceiro quartil fosse colorida de acordo com o fluxo desse intervalo de tempo, desse modo era possıvel
verificar o debito nestes modulos.
Existiu outro utilizador que referiu que poderia existir uma seccao com as medidas estatısticas globais
dos pacotes recebidos ate ao momento (valores como media, maximo, mınimos, etc.). Outra ideia foi a
introducao de um aviso sonoro quando houvesse aparicoes de outliers.
Por outro lado existiram utilizadores que sugeriram a existencia de uma opcao de pausa da interface,
ou da manipulacao das escalas em tempo real. Estas ideias carecem de uma analise mais exploratoria
do sistema uma vez que podem quebrar alguns dos requisitos apresentados.
Estas sugestoes podem ser utilizadas para um trabalho futuro numa tentativa de melhorar a inter-
face.
No final foi feita a questao Este sistema enquadraria-se na monitorizacao de eventos em larga
escala? com as opcoes: Sim, Nao, Talvez. Existiu unanimidade e todos os utilizadores responderam
que sim, podendo chegar assim a conclusao que utilizadores nao experientes conseguiram entender
um sistema de analise de grandes quantidades de informacao em tempo real.
5.2 Testes de Sistema
A realizacao destes testes e importante na medida em que a elevada quantidade de informacao pode
tornar o sistema lento ao ponto de nao existir fluidez necessaria para uma visualizacao compreensıvel
da informacao, o processamento e renderizacao de multiplos elementos pode levar a um enfraqueci-
mento e queda do numero de quadros por segundo desenhados (FPS).
Para a realizacao de testes de sistema utilizou-se a consola de ferramentas do Chrome que permite
a visualizacao da performance/desempenho da aplicacao e da duracao de cada funcao especıfica,
sendo que esta analise e importante para verificar os tempos de desenho e processamento dos ele-
mentos.
Utilizou-se uma implementacao com os modulos Barchart e Linechart e outra com os tres modulos
Barchart, Linechart e Scatterchart, ambas as implementacoes contiveram o modulo Outliers ativado.
Testaram-se os seguintes debitos de pacotes: 10, 100, 500, 1000 pacotes por segundo. Fez-se uma
analise de 30 segundos de cada debito individualmente, as medidas recolhidas foram os FPS e a
72
memoria utilizada. Posteriormente sao apresentados alguns graficos para verificar a correlacao exis-
tente entre o aumento de debito e os valores recolhidos.
Inicialmente instanciou-se um Chart com dois modulos Barchart e Linechart para verificar o desem-
penho destes dois idiomas em conjunto, dado que quantos mais modulos existirem maior e o processa-
mento e renderizacao dos elementos de cada grafico, outro dos motivos para nao incluir o Scatterchart
foi a nocao de que este modulo exige uma capacidade computacional naturalmente superior aos res-
tantes uma vez que o desenho de todos os pontos e dos processos mais moroso neste sistema.
Definiu-se um intervalo de tempo de 15 segundos para o Linechart, assim o modulo Barchart desenha
metade da informacao recebida (uma vez que o tempo total da analise foi de 30 segundos). Na figura
5.10 e 5.11 estao apresentados os resultados deste teste, cada debito corresponde a uma cor em que
o eixo horizontal sao o tempo e vertical os FPS e bytes calculados pela interface. E possıvel notar que
os frames seguiram uma distribuicao semelhante em todos os debitos e o seu intervalo nao passou na
maioria das vezes dos abaixo dos 30 FPS, excetuando o debito mais alto (1000 pacotes por segundo)
que teve os dois menores picos de quadros por segundo. Em relacao a memoria utilizada verifica-se
que quanto maior o debito mais rapidamente a memoria consumida aumenta e progressivamente vai-se
mantendo constante.
Figura 5.10: FPS - 2 Modulos Figura 5.11: Memoria utilizada - 2 Modulos
Neste teste utilizaram-se os tres modulos implementados, seguindo o mesmo formato da demo da
seccao 4.4. Com o pormenor dos modulos Linechart e Scatterchart terem um intervalo de tempo de
10 segundos, assim cada modulo realiza pelo menos 10 segundos de processamento e desenho. Ou-
tra alteracao realizada foi que o limite de pontos referido na seccao 4.3.2 foi desabilitado de forma a
verificar qual e o impacto da renderizacao de cada ponto no desempenho do sistema. Para este teste
iremos definir que valores abaixo dos 30 FPS comprometem a fluıdez do sistema.
No grafico 5.12 e possıvel verificar que os debitos de 10 e 100 mantem uma constante de FPS en-
quanto os restantes debitos criar uma descida acentuada logo no inıcio, tornando assim a visualizacao
menos fluıda, comparando com o teste anterior podemos perceber que o modulo Scatterchart tem
uma influencia direta neste caso. Em relacao a memoria utilizada (fig. 5.13) nota-se que existe um
crescimento muito mais cedo do que no teste anterior e que quanto maior o debito mais rapido e esse
aumento, sendo que a partir de um certo ponto essa fase comeca a diminuir de intensidade e o consumo
de memoria passa a ser relativamente constante e desce no final.
73
Figura 5.12: FPS - 3 Modulos Figura 5.13: Memoria utilizada - 3 Modulos
Utilizando o mesmo metodo do teste anterior realizou-se novamente outro teste com a variacao do
limite de pontos desenhados pelo Scatterchart, que seria de 3000 pontos, a partir desse momento o
modulo passa para o estado de Fluxo Alto e desenha apenas o heatmap da densidade de valores
(nenhum outro valor foi modificado alem deste criterio). Considera-se para este efeito que um fluxo alto
e gerado desde os 500 pacotes por segundo e por esse motivo apenas se obtiveram as metricas para
os debitos de 500 e 1000.
Os FPS obtidos (fig. 5.14) revelam uma estabilizacao no intervalo entre 45 e 65 frames de ambos os
fluxos, comparativamente ao teste anterior este teste obteve um resultado bastante superior ao anterior,
sendo que a fluidez do sistema nao foi comprometida. Relativamente a memoria consumida (fig. 5.15) e
possıvel notar que a mesma aumenta de acordo com o padrao do teste anterior e que a sua estabilidade
tambem e semelhante.
Figura 5.14: Boxplot de Timestamps do 1o teste Figura 5.15: Boxplot de timestamps do 2o teste
5.3 Discussao
No capıtulo 1 foi proposto um sistema que realizasse uma apresentacao eficiente de grandes quanti-
dades de dados em tempo real, tendo em consideracao que o sistema deveria ser intuitivo e que nao
existisse perca de contexto entre as diferentes fases da representacao. Resultando assim na criacao
do sistema VisMillion e do componente de transmissao de dados (Streammer ).
Para alcancar esta meta, a informacao e apresentada de diferentes modos ao longo do tempo com
74
a ajuda dos modulos. A sua aplicacao visa criar um elo de ligacao entre a componente tempo real e
grandes quantidades de informacao, utilizando uma ponte entre a complexidade do seu processo de
avaliacao e a maneira de como devem ser analisados pelo utilizador. Foram utilizados metodos para
que o utilizador conseguisse reconhecer padroes (tendencias), valores atıpicos e outliers, variacoes de
fluxo entre outros aspetos relevantes neste tipo de sistemas.
De acordo com estas caracterısticas e necessario ter em conta a taxa de sucesso no reconheci-
mento por parte do utilizador destes padroes e os tempos dessa identificacao.
Utilizando as respostas dos utilizadores aos questionarios tambem e possıvel saber que os utiliza-
dores classificaram com uma classificacao media de 4.67 (numa escala de 1 a 5) que o sistema era
facil de aprender e que era de facil compreensao (classificacao media de 4.52). Para alem destas
metricas os utilizadores tambem evidenciaram que a transicao entre modulos era intuitiva (classificacao
media de 4.66). As restantes classificacoes estao apresentadas na seccao 5.1.4 e e possıvel ver que
para a identificacao de tendencias, fluxos, valores e agregacoes atıpicas todas as classificacoes foram
superiores a 4.5 em media.
Para alem destas medidas os utilizadores identificaram alguns pontos menos bons no sistema e que
carecem de um desenvolvimento mais aprofundado, no caso da interacao com o sistema alguns refe-
riram que por vezes existiam tarefas complicadas no acompanhamento dos elementos com o rato. Por
outro lado a maioria a maioria referiu que a interface e os diferentes modulos permitiam analisar diferen-
tes dados em alturas distintas do tempo e que era facil de analisar padroes e tendencias na informacao.
Relativamente as melhorias, existiram algumas ideias que posteriormente podem ser efetuadas num
trabalho futuro, sempre tendo em conta os requisitos propostos.
No final todos os utilizadores concordaram que este sistema se enquadraria num caso real de
monitorizacao de grandes quantidades de dados em tempo real. Apesar de ser apenas um prototipo a
interface sugere que e possıvel realizar este tipo de analises atraves da solucao encontrada.
Relativamente aos testes de eficiencia e necessario ter em conta o tipo de modulo a implementar,
uma vez que este e um sistema com uma arquitetura fat client deve-se ter em consideracao o tipo
de processamento e a complexidade do mesmo, existindo varias ferramentas para o fazer de forma
eficiente. Outro aspeto e o tipo de desenho utilizado, que pode despender de mais ou menos tempo
para ser renderizado.
Durante os testes de sistema analisou-se o impacto dos diferentes modulos utilizando as metricas
enunciadas (FPS e memoria utilizada). A partir dos mesmos chegou-se a conclusao que quanto maior
o debito, maior a necessidade de que os modulos sejam adaptados para responder eficientemente a
quantidade de informacao recebida. Para alem disso, quanto maior o numero de modulos existentes,
maior a memoria utilizada e consequentemente o desempenho da interface tambem pode decrementar.
Criando limites, como foi criado no modulo Scatterchart e possıvel prever uma quebra da eficiencia, nao
comprometendo a analise feita pelo utilizador.
Apos o desenvolvimento desde sistema notou-se uma limitacao na quantidade de informacao a
ser transmitida, testando as condicoes limite chegou-se a conclusao que para la dos 1000 pacotes
o servidor ja nao consegue fazer emissao eficaz da informacao, isto e, o limite possıvel de debito
75
deste sistema e ate 1000 pacotes por segundo. A utilizacao de outras ferramentas pode prevenir esta
limitacao.
Relativamente a parte do front-end a arquitetura e fluxo do Javascript tambem nao permite receber esta
informacao exatamente em tempo real, sendo que a rececao de dados e feita atraves de eventos que
sao verificados apos a execucao das funcoes que estao numa pilha principal. E tambem por este motivo
que os timestamps de cada pacote devem ser enviados pelo servidor e nao gerados pela interface, uma
vez que so quando esta funcao ocorre e que o timestamp e atribuıdo e consequentemente em alturas de
maior fluxo, muitos destes pacotes podem ser receber tempos semelhantes. Uma forma de contornar
este problema e agregar estes pacotes quando o fluxo e mais alto, evitando assim um overflow no envio
e rececao dos dados. Outra alternativa e utilizar ferramentas que consigam suportar esta quantidade
de dados ou esperar por uma melhoria pelos developers dos browsers.
76
Capıtulo 6
Conclusoes
Nesta dissertacao realizou-se um estudo sobre as formas de visualizar grandes quantidades de dados
em tempo real, verificando-se que as maiores dificuldades nesta materia e a manutencao do contexto
do utilizador as mudancas que ocorrem ao longo do tempo, assim como a representacao de muita
informacao ao mesmo tempo, que leva a uma sobrelotacao dos elementos desenhados pelas interfa-
ces destes sistemas. Por esta razao existe a necessidade de criar abordagens que resolvam estas
dificuldades ajudando o utilizador a analisar padroes e ocorrencias nos conjuntos de dados transmiti-
dos.
Atraves da analise do estado da arte, e possıvel verificar que a maioria dos sistemas existentes
comportam um domınio especıfico de aplicabilidade, sendo que as principais resolucoes dos siste-
mas passam pelo processamento, agregacao e clustering dos dados visualizados realizando muitas
vezes medidas estatısticas para o efeito.As tecnicas de interacao usadas seguem os princıpios de uma
visualizacao global primeiro, e posteriormente com mais detalhe, sendo que a manutencao do contexto
continua a ser um problema desafiante para resolver. Uma dos grandes desafios encontrados neste
tipo de trabalhos e o modo de lidar com grandes quantidades de informacao para que os dados nao
cheguem atrasados ao utilizador ou que a interpretacao realizada pelo mesmo nao seja comprometida.
O objetivo foi encontrar uma solucao que permitisse a visualizacao independente do domınio do
dataset utilizado, sendo que na instanciacao do sistema o utilizador pudesse enunciar as suas pre-
ferencias, existindo um maior controlo e clareza da interface.
Esta tarefa foi baseada numa implementacao web que permite uma maior modularidade com to-
dos os sistemas existentes, e concedendo um desenvolvimento futuro mais abrangente quer seja na
execucao de melhorias e novas criacao de novas tecnicas de visualizacao.
A aplicacao segue uma arquitetura de cliente-servidor. Uma vez que o foco do trabalho e a visualizacao,
a parte do servidor serve apenas de base a transmissao dos dados criando uma simulacao da producao
da informacao em tempo real utilizando datasets previamente extraıdos de bancos de dados. O cliente
(interface) realiza todo o processamento e renderizacao dos elementos apresentados ao utilizador de
acordo com as suas preferencias. A utilizacao dos modulos faz com que a navegacao dos pacotes
recebidos seja realizada de forma a que ao longo do tempo exista uma agregacao cada vez mais acen-
77
tuada da informacao, assim o utilizador e capaz de inferir padroes entre diferentes timelines e analisar
os padroes existentes nos dados.
Uma das maiores preocupacoes deste trabalho e tambem fornecer toda esta representacao da
informacao sem comprometer o desempenho e eficiencia do sistema, a interface e capaz de se adaptar
a quantidade de informacao recebida e ao fluxo existente em momentos diferentes da visualizacao sem
que existam saltos ou interrupcoes abruptas que possam levar o utilizador a perder-se na sua analise
dos dados. Por este motivo procurou-se utilizar ferramentas que prevenissem uma renderizacao mais
rapida de acordo com as tecnologias existentes.
A implementacao de interacoes do sistema com o utilizador contempla o modo mais simples base-
ado na sobreposicao e a apresentacao mais detalhada dos elementos selecionados, evitando distracoes
intrusivas que possam levar a uma falsa interpretacao dos dados.
Para testar o sistema foram realizados testes de usabilidade, compreendendo fatores como a analise
de padroes, tendencias, valores atıpicos, agregacoes, maximos, mınimos, mudancas de fluxo, entre
outros. Obteve-se feedback relativamente aos aspetos menos positivos da aplicacao sendo que a
maioria apenas evidenciou alguma dificuldade na interacao com os elementos, por outro lado a maioria
referiu que a solucao apresentada era simples e intuitiva e que todas as tarefas pedidas foram realizadas
sem muita dificuldade.
Os testes de eficiencia do sistema conseguiram provar que a variacao de fluxo nao compromete a
fluidez da aplicacao e que apesar das limitacoes existentes pelos dispositivos web consegue-se realizar
uma analise intuitiva e sem disrupcoes na navegacao dos dados. Por outro lado, a implementacao dos
modulos deve sempre ter em conta o numero de elementos a renderizar dado que quanto maior o seu
numero mais tempo e gasto na representacao dos mesmos, uma das alternativas passa por arranjar
tecnicas de altos fluxos evitando a quebra de quadros por segundo.
Chegou-se ao objetivo de criar uma interface capaz de lidar com grandes quantidades de informacao
em tempo real atraves de um sistema de modulos que agrega os dados de diferentes maneiras sem
que o utilizador perca o contexto durante a navegacao.
Em suma o desenvolvimento deste trabalho consumou uma aprendizagem sobre os sistemas exis-
tentes e as tecnologias utilizadas para o efeito (Javascript, D3, websockets, CANVAS, entre outros),
alem disso aprendeu-se tambem diferentes tecnicas para representar e agregar a informacao.
6.1 Trabalho Futuro
Embora a aplicacao forneca uma solucao completa e representa a informacao em tempo real existem
algumas caracterısticas que podem ser incluıdas num trabalho futuro.
O aumento da capacidade do fluxo de dados recebidos e uma materia que pode ser melhorada,
seja atraves da utilizacao de novas tecnologias que permitam um envio e rececao de dados mais rapido
comparado com as existentes.
Relativamente a visualizacao, a utilizacao de transicoes suaves entre os modulos comporta um
outro mundo deste sistema e que pode ser visto de uma maneira mais detalhada. A introducao de
78
elementos que realizem uma degradacao graciosa da informacao, por exemplo, transformar os pontos
do Scatterchart em linhas ou areas do Linechart.
A implementacao de novos modulos e tambem importante para analisar outros valores estatısticos dos
dados, e de salientar que este e apenas um prototipo de uma solucao real e que por essa razao a sua
implementacao num contexto real comportaria sempre aspetos a considerar na sua utilizacao.
Outro aspeto a introduzir neste conceito e a representacao de pacotes com multiplas variaveis,
sendo que para este aspeto teria de ser realizado um novo estudo das tecnologias existentes que
envolvam a visualizacao de grandes quantidades de dados multi variaveis.
Em geral, nao excluindo tambem outras alteracoes, as melhorias mencionadas podem ser utilizadas
para aperfeicoamento global da interface criada.
79
80
Bibliografia
G. D. Battista, V. D. Donato, M. Patrignani, M. Pizzonia, V. Roselli, and R. Tamassia. Bitconeview:
visualization of flows in the bitcoin transaction graph. In 2015 IEEE Symposium on Visualization for
Cyber Security (VizSec), pages 1–8, 2015.
L. Berry and T. Munzner. Binx: Dynamic exploration of time series datasets across aggregation levels.
In IEEE Symposium on Information Visualization, pages p2–p2, 2004.
M. Bostock, V. Ogievetsky, and J. Heer. D3: Data-driven documents. IEEE Trans. Visualization & Comp.
Graphics (Proc. InfoVis), 2011.
D. Brodbeck and L. Girardin. Trend analysis in large timeseries of high-throughput screening data using
a distortion-oriented lens with semantic zooming. In IEEE Symposium on Information Visualization
2003, pages 74–75. IEEE, 2003.
J. Brooke. Sus: A retrospective. J. Usability Studies, 8(2):29–40, 2013.
A. Buja, D. F. Swayne, M. L. Littman, N. Dean, H. Hofmann, and L. Chen. Data visualization with
multidimensional scaling. Journal of Computational and Graphical Statistics, 17(2):444–472, 2008.
P. Chopade, J. Zhan, K. Roy, and K. Flurchick. Real-time large-scale big data networks analytics and
visualization architecture. In 2015 12th International Conference Expo on Emerging Technologies for
a Smarter World (CEWIT), pages 1–6, 2015.
R. J. Crouser, L. Franklin, and K. Cook. Rethinking visual analytics for streaming data applications. IEEE
Internet Computing, 21(4):72–76, 2017.
A. De Mauro, M. Greco, and M. Grimaldi. What is big data? a consensual definition and a review of key
research topics. AIP Conference Proceedings, 1644(1):97–104, 2015.
I. Demir, C. Dick, and R. Westermann. Multi-charts for comparative 3d ensemble visualization. IEEE
Transactions on Visualization and Computer Graphics, 20(12):2694–2703, 2014.
V. V. G. Evgeniy Yur’evich Gorodov. Analytical review of data visualization methods in application to big
data. Journal of Electrical and Computer Engineering, 2013:7, 2013.
F. Fischer, F. Mansmann, and D. A. Keim. Real-time visual analytics for event data streams. In Proce-
edings of the 27th Annual ACM Symposium on Applied Computing, SAC ’12, pages 801–806. ACM,
2012.
81
C. Forsell and J. Johansson. An heuristic set for evaluation in information visualization. In Proceedings
of the International Conference on Advanced Visual Interfaces, AVI ’10, pages 199–206. ACM, 2010.
D. Garcia and F. Schweitzer. Social signals and algorithmic trading of bitcoin. Royal Society Open
Science, 2(9), 2015.
G. Grinstein and M. Trutschl. High-dimensional visualizations. 2001.
A. Gupta and I. S. Mumick, editors. Materialized Views: Techniques, Implementations, and Applications.
MIT Press, 1999.
A. Jacobs. The pathologies of big data. Queue, 7(6):10:10–10:19, 2009.
U. Jugel, Z. Jerzak, G. Hackenbroich, and V. Markl. M4: A visualization-oriented time series data
aggregation. Proc. VLDB Endow., 7(10):797–808, 2014.
A. Katal, M. Wazid, and R. H. Goudar. Big data: Issues, challenges, tools and good practices. In 2013
Sixth International Conference on Contemporary Computing (IC3), pages 404–409, 2013.
D. A. Keim. Visual exploration of large data sets. Commun. ACM, 44(8):38–44, 2001.
D. A. Keim. Information visualization and visual data mining. IEEE Transactions on Visualization and
Computer Graphics, 8(1):1–8, 2002.
A. M. Khan, D. Goncalves, and D. C. Leao. Towards and adaptive framework for real-time visualization
of streaming big data. In Proceedings EuroVis 2017. Eurographics, 6 2017.
C. Kintzel, J. Fuchs, and F. Mansmann. Monitoring large ip spaces with clockview. In Proceedings of the
8th International Symposium on Visualization for Cyber Security, VizSec ’11, pages 2:1–2:10. ACM,
2011.
S. Landset, T. M. Khoshgoftaar, A. N. Richter, and T. Hasanin. A survey of open source tools for machine
learning with big data in the hadoop ecosystem. Journal of Big Data, 2:1–36, 2015.
C. Lewis and J. Rieman. Task-centered User Interface Design: A Practical Introduction. University of
Colorado, Boulder, Department of Computer Science, 1993.
Z. Liu, B. Jiang, and J. Heer. immens: Real-time visual querying of big data. Computer Graphics Forum
(Proc. EuroVis), 32, 2013.
M. A. Livingston, S. Russell, J. W. Decker, E. Leadbetter, and A. Gilliam. Cedars: Combined explora-
tory data analysis recommender system. In 2015 IEEE 5th Symposium on Large Data Analysis and
Visualization (LDAV), pages 139–140, 2015.
J. Mackinlay. Automating the design of graphical presentations of relational information. ACM Trans.
Graph., 5(2):110–141, 1986.
S. Madden. From databases to big data. IEEE Internet Computing, 16(3):4–6, 2012.
82
D. McGinn, D. Birch, D. Akroyd, M. Molina-Solana, Y. Guo, and W. J. Knottenbelt. Visualizing dynamic
bitcoin transaction patterns. Big Data, 4(2):109–119, 2016.
P. McLachlan, T. Munzner, E. Koutsofios, and S. North. Liverac: Interactive visual exploration of sys-
tem management time-series data. In Proceedings of the SIGCHI Conference on Human Factors in
Computing Systems, CHI ’08, pages 1483–1492. ACM, 2008.
G. E. Moore. Cramming more components onto integrated circuits. Electronics, 38(8), 1965.
M. Novotny and H. Hauser. Outlier-preserving focus+context visualization in parallel coordinates. IEEE
Transactions on Visualization and Computer Graphics, 12(5):893–900, 2006.
V. Pimentel and B. G. Nickerson. Communicating and displaying real-time data with websocket. IEEE
Internet Computing, 16(4):45–53, 2012.
C. Plaisant. The challenge of information visualization evaluation. In Proceedings of the Working Con-
ference on Advanced Visual Interfaces, AVI ’04, pages 109–116. ACM, 2004.
J. A. R. Rojas, M. B. Kery, S. Rosenthal, and A. Dey. Sampling techniques to improve big data explora-
tion. In 2017 IEEE 7th Symposium on Large Data Analysis and Visualization (LDAV), pages 26–35,
2017.
S. Sagiroglu and D. Sinanc. Big data: A review. In 2013 International Conference on Collaboration
Technologies and Systems (CTS), pages 42–47, 2013.
H. Schumann and W. Muller. Visualisierung: Grundlagen und allgemeine methoden. Springer Berlin
Heidelberg, 1999.
J. Shlens. A tutorial on principal component analysis. CoRR, abs/1404.1100, 2014.
B. Shneiderman. The eyes have it: a task by data type taxonomy for information visualizations. In
Proceedings 1996 IEEE Symposium on Visual Languages, pages 336–343, 1996.
P. Simon. The visual organization: data visualization, Big Data, and the quest for better decisions. Wiley,
2014.
J. Traub, N. Steenbergen, P. Grulich, T. Rabl, and V. Markl. I2: Interactive real-time visualization for
streaming data. In 20th International Conference on Extending Database Technology (EDBT), pages
526–529, 2017.
C. Viau and M. J. McGuffin. Connectedcharts: Explicit visualization of relationships between data
graphics. Computer Graphics Forum, 31(3pt4):1285–1294, 2012.
J. S. Ward and A. Barker. Undefined by data: A survey of big data definitions. CoRR, abs/1309.5821,
2013.
J. Xia, F. Wu, F. Guo, C. Xie, Z. Liu, and W. Chen. An online visualization system for streaming log data
of computing clusters. Tsinghua Science and Technology, 18(2):196–205, 2013.
83
L. Zhan, T. Z. Fu, D. M. Chiu, and Z. Lei. A framework for monitoring and measuring a large-scale
distributed system in real time. In Proceedings of the 5th ACM Workshop on HotPlanet, HotPlanet
’13, pages 21–26. ACM, 2013.
84
Apendice A
Documento Testes de Usabilidade
Este capıtulo possui o documento apresentado aos utilizadores antes dos testes de usabilidade.
85
VisMillion Testes de usabilidade com utilizadores
VisMillion é uma plataforma de visualização de grandes quantidades de dados em tempo real, o seu propósito é fornecer aos utilizadores uma nova técnica de representar informação de modo a poder ser interpretada em tempo real e também manter o contexto dos dados previamente recebidos.
Este sistema é composto por módulos apresentados nas páginas seguintes, cada um representa os dados de maneira diferente mas é o seu propósito complementarem-se entre eles, à medida que a informação percorre o eixo horizontal esta vai sendo agregada em diferentesmétodos. O eixo horizontal representa o tempo enquanto o eixo vertical representa o domínio da informação representada.
Para este caso específico o domínio de estudo são as vendas realizadas por uma cadeira de supermercados a nível nacional realizadas em tempo real. Cada ponto corresponde a uma venda realizada num determinado momento e respectivo valor:
𝑃𝑜𝑛𝑡𝑜 → { 𝑇𝑒𝑚𝑝𝑜, 𝑉𝑎𝑙𝑜𝑟 𝑑𝑎 𝑇𝑟𝑎𝑛𝑠𝑎çã𝑜 }
O principal propósito deste sistema é ser capaz de responder eficientemente a disparidades de débitos de dados e manter o contexto da informação à medida que esta vai sendo recebida. É também importante que sempre que existam alterações abruptas na informação o utilizador seja capaz de agir rapidamente a estas mudanças uma vez que podem vir a ter impactos significativos na vida e no cotidiano das pessoas.
Antes de começar por favor responda a este questionário
https://goo.gl/forms/5gj6rk7A7yMUjZXf2
86
87
88
Procedimento do teste
Numa primeira fase, para se familiarizar com o sistema, irão ser feitas umas
demonstrações simples de como funciona a interface e as interações que podem ser
realizadas. De seguida terá a liberdade de explorar o programa e de interagir com o
mesmo, esta fase não está incluída nos testes pelo que poderá fazer mais questões que
possam suscitar alguma dúvida.
De seguida irá ser fornecido um novo conjunto de dados ao sistema e é pedido que
visualize os dados e execute as tarefas pedidas pelo entrevistador.
1. Identificar variações nos valores médios de vendas ocorridas (subir, descer,
constante)
2. Identificar vendas atípicas e outliers
3. Identificar mudanças de fluxo nas vendas (aumentou, diminuiu)
4. Teste aberto
Durante a realização da sua visualização o entrevistador irá fazer questões e debater
alguns aspetos do que está a visualizar. Caso existam situações ao qual não seja capaz
de responder não se preocupe, pois poderá ser normal encontrar algumas dificuldades.
No final ser-lhe-à entregue um simples questionário, com um tempo máximo de 4-5
minutos. https://goo.gl/forms/NaAkepzGhX4EesFv1
Obrigado pela sua colaboração!
89
90
Apendice B
Questionarios
Este capıtulo possui os questionarios de usabilidade antes e depois dos testes respetivamente.
91
Com tecnologia
VisMillion*Obrigatório
1. ID *
2. 1 - Idade *
3. 2 - Sexo *Marcar apenas uma oval.
Masculino
Feminino
4. Com que frequência utiliza computador? *Marcar apenas uma oval.
Todos os Dias
2 a 3 vezes por semana
Raramente
Nunca
5. Quais dos seguintes gráficos de visualização conhece?Marcar tudo o que for aplicável.
Pie Charts
Diagrama de Caixa (Box Plot)
Cloropleth Map
Mapa de Árvore (Treemap)
Mapa de calor (Heatmap)
Matriz de Pontos (Dot Matrix Chart)
Gráfico de Barras e Histograma (Barchart/Histogram)
Chord Diagram
Gráfico de Pontos (Scatterchart)
Gráfico em Rede (Radar Chart)
Gráfico de Linha (Linechart)
Outra:
92
VisMillion*Obrigatório
1. ID *
2. As mudanças de fluxo/débito de vendas são perceptíveis? *Marcar apenas uma oval.
1 2 3 4 5
nada perceptível muito perceptível
3. É fácil de identificar valores atípicos/outliers nas vendas? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
4. É fácil de identificar variações nos valores médios das vendas ocorridas? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
5. É fácil de localizar onde existem maiores agregações de vendas? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
6. Ao longo do tempo, é perceptível qual o intervalo de valores em que existiram maisvendas? *Marcar apenas uma oval.
1 2 3 4 5
nada perceptível muito perceptível
7. É fácil de entender quais os valores máximos e mínimos de vendas num determinadomomento? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil93
8. A transição de um idioma/módulo para outro é intuitiva? *Marcar apenas uma oval.
1 2 3 4 5
nada intuitiva muito intuitiva
9. É fácil de compreender os intervalos temporais de cada idioma/módulo? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
10. O sistema é fácil de entender? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
11. O sistema é fácil de interagir? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
12. O sistema é fácil de aprender? *Marcar apenas uma oval.
1 2 3 4 5
muito difícil muito fácil
13. Quais foram as suas maiores dificuldades nautilização da interface?
14. Que aspectos achou mais fáceis/intuitivos na interface?
94
Com tecnologia
15. Tem alguma melhoria ou sugestão para o sistema?
16. Este sistema enquadraria-se na monitorização de eventos em larga escala? *Por exemplo: Monitorização de centrais termoeléctricas, análise de cotações na bolsa, etc...Marcar apenas uma oval.
Sim
Não
Não sei
95
96
Apendice C
Resultados Qualitativos dos
Questionarios
Neste apendice possui os resultados do questionario qualitativos utilizadores.
97
Figura C.1: Questionario - Variacoes de Fluxo Figura C.2: Questionario - Outliers
Figura C.3: Questionario - Valores Medios Figura C.4: Questionario - Agregacoes
Figura C.5: Questionario - Intervalos de valo-res Figura C.6: Questionario - Maximos mınimos
98
Figura C.7: Questionario - TransicoesFigura C.8: Questionario - Intervalos tempo-rais
Figura C.9: Questionario - Compreensao Figura C.10: Questionario - Interacao
Figura C.11: Questionario - Aprendizagem
99
100