SmartNodeDashboard Dias 2019

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
I NSTITUTO M ETRÓPOLE D IGITAL

P ROGRAMA DE P ÓS - GRADUAÇÃO EM E NGENHARIA DE
S OFTWARE
M ESTRADO P ROFISSIONAL EM E NGENHARIA DE S OFTWARE
SmartNode Dashboard: um framework

front-end baseado em Node-RED para criação
de City Dashboards
Cesimar Xavier de Souza Dias
Natal-RN
Janeiro de 2019
SmartNode Dashboard: um framework front-end baseado em

Node-RED para criação de Smart City Dashboards
Dissertação de Mestrado apresentada ao Pro-

grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Engenha-
ria de Software.
Universidade Federal do Rio Grande do Norte – UFRN

Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Prof. Dr. Frederico Araújo da Silva Lopes

Coorientador: Prof. Dr. Jair Cavalcante Leite
Natal/RN
2019
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Dias, Cesimar Xavier de Souza.

SmartNode Dashboard: um framework front-end baseado em Node-
RED para criação de City Dashboards / Cesimar Xavier de Souza
Dias. - 2019.
70 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande

do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação
em Engenharia de Software. Natal, RN, 2019.
Orientador: Prof. Dr. Frederico Araújo da Silva Lopes.
Coorientador: Prof. Dr. Jair Cavalcante Leite.
1. SmartNode Dashboard - Dissertação. 2. Cidades inteligentes

- Dissertação. 3. Dashboards - Dissertação. 4. Padrões de
interface web - Dissertação. 5. Node-RED - Dissertação. I.
Lopes, Frederico Araújo da Silva. II. Leite, Jair Cavalcante.
III. Título.
RN/UF/BCZM CDU 004.738.5
Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262

SmartNode Dashboard: um framework front-end baseado em

Node-RED para criação de Smart City Dashboards
Dissertação de Mestrado apresentada ao Pro-

grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Engenha-
ria de Software.
Trabalho aprovado. Natal/RN, 28 de janeiro de 2019:
Prof. Dr. Frederico Araújo da Silva Lopes

Orientador
Prof. Dr. Jair Cavalcante Leite

Coorientador
Prof. Dr. Gustavo Girão Barreto da Silva

Examinador Interno
Prof. Dr. André Gustavo Duarte de

Almeida
Examinador Externo
Natal/RN
2019
Dedico este trabalho às três mulheres que mais amo nesse mundo, esposa, filha e mãe.
Agradecimentos
Primeiramente agradeço a Deus por ter me dado a capacidade da ciência, o que

me fez chegar até aqui. Gostaria de agradecer aos envolvidos diretamente nesse processo
de escalada ao ponto mais alto do mestrado, o título. Sem eles eu apenas teria alimentado
minha agonia de estar andando em círculo num loop infinito e contraproducente. Assim
sendo, um obrigado especial ao meu orientador: Frederico Lopes que me ajudou a
concluir este trabalho, bem como ao meu coorientador: Jair Cavalcante. Ao coordenador
do mestrado em Eng. de Software, Carlos Eduardo, que prontamente me ajudou sempre
que precisei. Aos colegas de mestrado que estiveram juntos a todo instante e sempre
que foi possível e necessário: Allyson, Cephas, Jackson, Jorge, Reniere, Tarso e Welkson
(a ordem não revela o nível de importância de cada um). E por fim, mas não menos
importante, às mulheres da minha vida, que com amor me recebiam todos os dias no
regresso ao lar. A todos vocês, minha eterna gratidão.
Resumo
Atualmente diversas cidades têm se envolvido com pesquisas no intuito de fomentar a
criação de soluções que dispõe os dados e informações à população, são os chamados
City Dashboards. Estes projetos possibilitam aos cidadãos acompanhar os acontecimentos
da cidade em tempo real, possibilitando a essas pessoas planejarem suas rotinas baseado
no conhecimento gerado sobre o seu contexto local. Mesmo com o número crescente de
projetos sendo desenvolvidos com essa finalidade, não há, ainda, trabalhos que sejam
voltados a criar estruturas reaproveitáveis ou metodologias que utilizem outros produtos
de softwares de código aberto com vistas à padronização de produção de dashboards.
Diante disso, esse trabalho se propôs em criar um framework utilizando o Bootstrap.
O framework teve a intenção de implementar padrões de projetos e de interface web,
focados em conteúdos com estruturas reaproveitáveis, utilizando o Node-RED como pla-
taforma de execução. Como resultados deste trabalho, foi possível conceber o SmartNode
Dashboard, um framework para criação de interfaces padronizadas e customizáveis. Além
de oferecer aos desenvolvedores de dashboards uma metodologia de utilização do Smart-
Node Dashboard junto ao Node-RED para facilitar e ampliar a capacidade das equipes no
tocante ao desempenho, tempo e qualidade no desenvolvimento de dashboards.
Palavras-chave: SmartNode Dashboard. cidades inteligentes. dashboards. padrões de

interface web. Node-RED.
Abstract
Nowadays several cities have been involved in research in order to provide the city’s
data and information to the population through dashboards (so-called City Dashboards).
These solutions enable citizens to follow the events of the city in real time, enabling
these people to plan their routines based on the knowledge generated about their local
context. Even with the growing number of projects being developed for this purpose,
there are no jobs that are aimed at creating reusable structures or methodologies that
use other open source software products to standardize the production of dashboards.
Therefore, this work was proposed in creating a framework based on Bootstrap. The
framework was intended to implement standards projects and web interface, focused on
content with reusable structures, using Node-RED as an execution platform. As a result
of this work, it was possible to design SmartNode Dashboard, a framework for creating
standardized and customizable interfaces. In addition to offering dashboard developers
a methodology for using SmartNode Dashboard with Node-RED to facilitate and extend
teams’ ability to perform, time and quality in the development of dashboards.
Keywords: SmartNode Dashboard, smart cities, dashboards, web interface patterns,

Node-RED.
Lista de ilustrações
Figura 1 – Dashboard com resumo de informações . . . . . . . . . . . . . . . . . 22

Figura 2 – Projeto CityDashboard projetado para cidades do Reino Unido . . . . 25
Figura 3 – Projeto CityDashboard projetado para Sydney . . . . . . . . . . . . . 25
Figura 4 – Projeto CityDashboard projetado para Amsterdã . . . . . . . . . . . . 26
Figura 5 – Exemplo de dashboard utilizando cards como padrão de interface . . 30
Figura 6 – Funcionamento de um template . . . . . . . . . . . . . . . . . . . . . 34
Figura 7 – Tela principal do Node-RED com exemplo de fluxo de dados . . . . . 35
Figura 8 – Representação dos arquivos de um nó no Node-RED . . . . . . . . . . 35
Figura 9 – Código gerado após a configuração do package.json via linha de comando. 37
Figura 10 – Código gerado após a criação do onibus-natal.js para o nó. . . . . 37
Figura 11 – Código gerado após a criação do onibus-natal.html para o nó. . . . 38
Figura 12 – Exemplo do fluxo de dados no Node-RED . . . . . . . . . . . . . . . . 39
Figura 13 – Estrutura do Card utilizando a metodologia BEM . . . . . . . . . . . 42
Figura 14 – Estrutura do Card utilizando a metodologia BEM, aplicada para o card
de tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 15 – Visão geral do funcionamento do SmartNode Dashboard . . . . . . . 44
Figura 16 – Gráfico com os elementos comuns em city dashboards . . . . . . . . . 45
Figura 17 – Layout do template para cidade inteligente . . . . . . . . . . . . . . . 46
Figura 18 – Protótipo a partir da implementação do template utilizando o Smart-
Node Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 19 – Fluxo para o Template 1 . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 20 – Protótipo após da implementação do template e integração do fluxo
no Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 21 – Gráfico com tempos em que os participantes executaram as tarefas. . 58
Figura 22 – Gráfico com o percentual de completude que os participantes executa-
ram as tarefas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Lista de tabelas
Tabela 1 – Lista com os principais frameworks front-end do mercado . . . . . . . 33

Tabela 2 – Principais características do Bootstrap . . . . . . . . . . . . . . . . . . 40
Tabela 3 – Parâmetros incluídos no protótipo 1 . . . . . . . . . . . . . . . . . . . 47
Tabela 4 – Perfil dos participantes da validação de uso . . . . . . . . . . . . . . 57
Tabela 5 – Respostas da Questão 1 do questionário pós-teste. . . . . . . . . . . . 60
Tabela 6 – Respostas da Questão 6 do questionário pós-teste. . . . . . . . . . . . 61
Lista de abreviaturas e siglas
API Application Programming Interface (Interface de Programação de Apli-

cativos)
CSS Cascading Style Sheets (Folha de Estilo em Cascata)
HTML HyperText Markup Language (Linguagem de Marcação de Hipertexto)
HTTP Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)
IHC Interação Humano-Computador
JSON JavaScript Object Notation (Notação de Objetos JavaScript)
NPM Node Package Manager (Gerenciador de Pacotes do Node)
SDK Software Development Kit (Conjunto de Desenvolvimento de Software)
TIC Tecnologia da Informação e Comunicação
URL Uniform Resource Locator (Localizador Padrão de Recursos)
UX User Experience (Experiência de Usuário)

Sumário
Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Tipos de Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Projetos de Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2.1 Londres e outras cidades do Reino Unido . . . . . . . . . . . . . . . . . . . 24
2.2.2.2 Sydney . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2.3 Amsterdã . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Padrões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Padrões de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Padrões de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2.1 Consistência de Padrões . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.2 Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 BASE TECNOLÓGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.0.1 Frameworks Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Templates de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1 Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.1.1 Tipos de nós existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1.2 Criação de novos nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Fluxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 SMARTNODE DASHBOARD . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Desenvolvimento do Framework CSS . . . . . . . . . . . . . . . . . . . . 40
4.1.1 Customização do Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.2 Arquitetura de Código CSS . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Metodologia de utilização . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Template de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Processo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 Processo de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.4 Integração ao Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.4.1 Fluxo do template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 VALIDAÇÃO DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 Experimentos executados . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.2 Critérios avaliados . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.3 Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3.1 Orientação sobre Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3.2 Preparação do Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3.3 Processo de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Caracterização dos Participantes . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Critério de Eficiência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.2 Critério de Eficácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
APÊNDICES 67
APÊNDICE A – TERMO DE LIVRE CONSENTIMENTO ESCLARECIDO 68
APÊNDICE B – ROTEIRO DE AVALIAÇÃO . . . . . . . . . . . . . . . . 69
APÊNDICE C – TAREFAS . . . . . . . . . . . . . . . . . . . . . . . . . 70
13
1 INTRODUÇÃO
Segundo estimativas da União das Nações Unidas (ONU), até 2050 a população
mundial terá alcançado o patamar de 9 bilhões de habitantes. Um número alarmante se
for considerada a grande demanda de insumos que uma população tão grande expende
para se manter. Acrescendo a esse fator, estima-se que mais de 50% da população
mundial viva nas áreas urbanas (LOPES; OLIVEIRA, 2017). Vale ressaltar que até os anos
60, apenas 34% da população vivia nas áreas urbanas. Lopes e Oliveira (2017) destaca
que já se sabe que cerca de 80% da população do leste da Europa viverá nas grandes
cidades até o ano de 2020. Esse panorama traz novas responsabilidades às cidades. Traz
consigo a necessidade delas se reinventarem e desafios de como elas vão transformar
espaços urbanos em lugares mais inovadores, participativos, conectados e sustentáveis,
sem negligenciar a qualidade de vida de suas populações, nunca foram tão latentes.
O panorama defronte a dramática massa urbana representa desafios cruciais para
a logística da gestão pública. Estes, decorrentes principalmente da pressão por eficácia
no suprimento às demandas sociais, precisam adotar novas abordagens no tocante a
sistematização de soluções efetivas para os desafios enfrentados. Para Weiss, Bernardes
e Consoni (2015), esse cenário pode ser ainda mais desafiador do que parece. Para
estes autores as restrições no campo legal-institucional e econômico, em referência a
destinação de recursos públicos e na concorrência acirrada entre as cidades para angariar
investimentos, visto que as receitas governamentais demoram demais para chegar ou
são usadas de forma equivocada, é um fator preocupante quando se pensa em soluções
efetivas para estas cidades. Muitas vezes, demorar demais na entrega de projetos já em
curso, pode significar criar novos problemas.
Aliadas a isso, com o avanço das tecnologias e a urgência de refletir sobre como
estão sendo usados os espaços urbanos, respeitando a sustentabilidade, várias cidades ao
redor do mundo estão trabalhando continuamente em pesquisas com foco na criação de
soluções eficientes. Como reflexo disso, o conceito de cidade inteligente tem ganhando
cada vez mais notoriedade. De acordo com Macke et al. (2018), até o ano de 2020,
40 cidades serão consideradas inteligentes, e num intervalo de 5 anos esse número
aumentará para 88. Dentre estas cidades, duas capitais brasileiras - Rio de Janeiro e
Curitiba, deverão compor o grupo das 8 cidades mais inteligentes da América Latina.
Muitos são os exemplos de projetos que estão sendo desenvolvidos para tornar as cidades
inteligentes. Para se ter uma ideia, em 2010, a cidade de Curitiba se tornou a primeira
cidade do mundo a conectar ônibus públicos a uma rede de banda larga móvel 3G. Isso
abriu possibilidade para novas oportunidades na oferta de serviços aos turistas, por
exemplo, que podem planejar suas rotas, comprar ingressos, dentre outras conveniências
Capítulo 1. INTRODUÇÃO 14
ofertadas pelo mercado turístico local (MACKE et al., 2018). Outro exemplo ainda mais
arrojado, vem das duas cidades que foram planejadas do zero para se tornar exemplos
de cidades inteligentes. Songdo, na Coréia do Sul e Masdar, em Dubai. Estas cidades
utilizam todos os conceitos modernos do que deve existir num espaço urbano para serem
consideradas inteligentes.
Atualmente, nas cidades, é possível gerar dados por meio de sensores, sinais de
trânsito, câmeras espalhadas pelas ruas e até mesmo através dos próprios aparelhos
inteligentes dos cidadãos, e disponibilizar esses dados às massas de pessoas conectadas.
Esses dados, quando transformados em informação, são utilizados pelas pessoas de
diversas formas, desde a geração de novos negócios ou até mesmo no modo como os
cidadãos passam a utilizá-los como ferramentas auxiliares em tomadas de decisões nas
tarefas cotidianas. Os cities dashboards ou painel de dados das cidades, são ferramentas
disponibilizadas aos cidadãos com intuito de mostrar informações que sejam relevan-
tes. Um exemplo da importância dessas ferramentas é a influência que elas podem
desempenhar na escolha, dos cidadãos, de uma rota de trânsito na volta do trabalho
até sua residência. Eles podem até mesmo adiar o retorno em alguns minutos para
poder trafegar em vias menos movimentadas. Ou desistir de ir em algum local público,
por haver aglomeração de pessoas. Essa é a rede da internet das coisas, que interliga
mais que computadores, ela se tornou uma rede que interliga pessoas e comunidades.
Tornando os computadores invisíveis ao ponto das pessoas utilizarem seus aparelhos
de forma transparente, conforme afirmou o cientista da computação Mark Weiser, na
década de 90. Ele afirmou que essa seria conhecida como computação ubíqua, a era da
tecnologia calma, quando a tecnologia seria o plano de fundo das nossas vidas (DREY,
2015).
Weiser apontou que as tecnologias mais importantes são aquelas que desaparecem,
se integrando ao cotidiano das pessoas, até se tornarem indistinguíveis dele. Atualmente
as pessoas estão vivendo essa era e a informação nunca esteve tão presente. A internet
como meio de acesso à informação e as cidades como forma de geração de dados, tornou
a vida mais conectada e com isso impactando diretamente na maneira de como os
cidadãos utilizam seus espaços urbanos conectados. Os aparelhos móveis se tornaram
tão presentes no dia a dia a ponto de influenciar na maneira de como se utiliza um
determinado espaço urbano ou na escolha produtos de vestuário, na maneira como as
pessoas se vestem ou se integram à sociedade. Esse ambiente se tornou tão rico ao ponto
de ser possível ter informações em tempo real de um determinado espaço, orientando as
informações pelo perfil que cada pessoa e ambientes têm, reunindo a melhor forma de
apresentar os dados para essas pessoas, de maneira a mostrar apenas o que é útil.
É possível, por exemplo, ter acesso a detalhes destes locais, tais como: eventos,
promoções, características físicas e possibilidades extras que são inerentes a eles. Essas
informações podem ser fornecidas por seres humanos como também de forma automati-
zadas por sensores que geram dados em tempo real. Exemplo disso é a disponibilização
de dados sobre o tempo, temperatura ou até mesmo poluição do ar num dado local.
Sensores podem facilmente medir esse tipo de informação e informar com exata precisão,
e em tempo real. Pessoas podem informar do que se trata o espaço, para que serve, se é
cobrado ingresso para ter acesso, dentre outras referências. Os usuários podem acessar
essas informações através de interfaces que conversam com os ambientes. As informa-
ções dos locais podem se adequar aos usuários de forma dinâmica, podem até mostrar
informações que são úteis apenas a um público específico. As interfaces se adaptam aos
diferentes perfis e os ambientes mostram o que está acontecendo no momento em que
ocorre, se adequando num formato mais pertinente e útil a cada situação.
1.1 PROBLEMA
A interação da sociedade a toda essa inovação e a percepção sobre as melhorias
trazidas são de suma importância para que as ações realizadas sejam de fato relevantes.
Oferecer à população diferentes formas de interagir, para que dessa forma se consiga
extrair e usufruir da inovação gerada, é a essência de toda essa mudança. Neste contexto,
se revelam demandas no desenvolvimento de interfaces, onde estas se objetivam em
fornecer aos cidadãos uma maneira de interagir com a cidade, fornecendo informações
em tempo real e assim auxiliando a sociedade nas suas tomadas de decisões.
Atualmente, há um grande número de cidades ao redor do mundo que desen-
volvem e mantém projetos, com ferramentas próprias ou compartilhadas, na tentativa
de minimizar os esforços despendidos com esse problema. O governo de Amsterdã,
por exemplo, se empenhou em contribuir no desenvolvimento do que chama de City
Service Development Kit (CitySDK). O CitySDK é um sistema que coleta dados abertos
de governos, para disponibilizar de forma padronizada e em tempo real. Dentro deste
projeto, a Waag Society1 é responsável pelo domínio mobilidade. Contudo, apesar de
contar com pesquisas neste tocante, Amsterdã ainda não disponibilizou, para seus cida-
dãos, o seu city dashboard. Uma ferramenta que promete informar o que acontece na
cidade, em tempo real, mas que ainda se encontra em desenvolvimento. Paralelamente
a isso, A University of New South Wales (Universidade de Nova Gales do Sul) - UNSW,
na Faculdade de Ambientes Construídos, foi desenvolvido o City Futures Research Centre
(Centro de Pesquisa para Cidades do Futuro). Este centro acabou por se tornar referência
nacional pelas suas contribuições acerca das pesquisas urbanas aplicadas. Dentre diversas
contribuições por meio da pesquisa aplicada, destaca-se o seu city dashboard. Tratado
1
É uma organização composta de grupos de pesquisa que trabalham em conjunto com parceiros de base
e institucionais em toda a Europa.
ainda em forma de protótipo, englobando um número reduzido de serviços, demonstra

alguns dos resultados alcançado por este centro. O centro atua desde 2012 e se firmou
como ambiente de valiosa contribuição para o planejamento urbano nacional, sendo
consolidado, ainda mais, por ter sido avaliado pelo Conselho Nacional Australiano de
Pesquisa. No mesmo sentido, a cidade de Gasglow, na Inglaterra, desenvolve o projeto
chamado de Future City Gasglow. Um projeto que se objetiva em mostrar o potencial que
é trabalhar com dados abertos gerados pelas cidades, explorando a capacidade do seu
uso na criação de ideias inovadoras. Projetos como esses revelam que as cidades estão
engajadas na busca por soluções mais eficazes para demandas recorrentes e cada vez
mais latentes no ambiente de smarts cities.
Esses projetos, sobretudo, demonstram peculiaridades similares: buscam con-
tribuir com soluções de softwares que disponibilizam dados aos seus cidadãos. Eles
revelam a necessidade, que comumente é negligenciada em projetos de softwares, do
processo de design centrado no usuário. Com o acentuado crescimento de soluções
dirigidas por dados, o projeto focado em experiência de usuário tem se tornado cada
vez mais relevante, visto que o sucesso dos projetos passam, também, pela aceitação
dos seus usuários. Atualmente o desenvolvimento dos produtos digitais está focado
nas tecnologias utilizadas, onde estas ditam as regras de negócio necessárias para tan-
genciar o desenvolvimento dos projetos de interface de dados. Cada projeto tem seu
desenvolvimento dirigido pela tecnologia que lhe suporta, e assim como o processo, os
resultados são baseados na tecnologia a qual o projeto esteja ligado, e isso acaba por
acarretar numa falta de padronização entre os artefatos produzidos, ou até mesmo entre
outros produtos com foco análogo. Um exemplo disso está na variação dos resultados
nos projetos supracitados. Eles não mantém entre si características semelhantes nem no
desenvolvimento e nem nos produtos obtidos.
Conforme foi mostrado anteriormente, há um grande esforço em pesquisas, e isso
acaba sendo muito custoso. Por conta disso, diversos grupos cooperam entre si na busca
por avançar no mesmo sentido de criar novas soluções. A Waag Society, por exemplo,
faz parte de um grupo de cooperação em pesquisas sobre soluções para cidades e já
demonstra perceptíveis contribuições. Mesmo com esses aportes, há ainda muito por
pesquisar, produzir e avançar. Considerando que esses projetos contribuem apenas no
contexto de plataformas de dados, mas não em aplicações com intuito de apresentação de
informações em interfaces digitais, revela-se uma carência em soluções neste sentido. Isso
se evidencia com a produção de muitas soluções que continuam por produzir material
que só servem para um contexto particular. Dessa forma, caso seja preciso construir uma
nova interface a partir das existentes, é necessário despender um alto custo de produção,
pois precisará realizar diversas melhorias naqueles projetos já consolidados.
1.2 Objetivos
Nesse contexto, o presente trabalho apresenta uma metodologia de trabalho que
alia o uso do SmartNode Dashboard, um framework para auxiliar na criação de dashboards
de informações para cidades inteligentes, a partir da junção de tecnologias front-end com
a ferramenta de programação por fluxo Node-RED. Seu objetivo é oferecer às equipes de
desenvolvimento de software, mais eficiência, padronização, flexibilidade, agilidade e
reutilização de códigos, para construção de novos projetos de city dashboards.
1.2.1 Objetivos Específicos
Os objetivos específicos deste projeto são:
• Desenvolver templates de dashboards para cidades inteligentes utilizando Node-RED

2
e tecnologias web front-end;
• Aplicar o framework SmartNode Dashboard em um estudo de caso para mostrar a

viabilidade da proposta;
• Avaliar com desenvolvedores a utilização do framework.
Para realizar o desenvolvimento desta proposta de trabalho, foi necessário realizar

os passos a seguir:
Desenvolvimento de templates: para realização dessa etapa foi necessário o desenvol-

vimento da proposta de um framework que utilizasse tecnologias web front-end.
Seu desenvolvimento possibilitou a construção de templates capazes de serem
reaproveitados na plataforma Node-RED. A junção dessas tecnologias pode elevar
o grau de qualidade e reusabilidade dos códigos produzidos. Assim, foi criada
uma metodologia que pudesse unir as tecnologias na perspectiva de reduzir o
ferramental utilizado no processo de desenvolvimento. Para tanto, foram seguidas
algumas etapas para que fosse possível chegar ao resultado esperado.
• Planejamento e programação do framework com programação front-end a

partir da customização do framework Bootstrap. Essa etapa foi realizada
conforme demanda inicial dos parâmetros levantados a partir dos estudos
sobre city dashboards;
2
Plataforma de programação por fluxos com foco em internet das coisas, desenvolvida pela IBM.
https://nodered.org
• Criação do padrão de interface: planejamento e programação do padrão

de interface para realizar a integração do SmartNode Dashboard. Essa fase
engloba a criação de uma interface web simples, ou seja, onde apenas o
esboço do layout e regras de navegação estão disponíveis. Posteriormente com
a inclusão do código HTML e CSS. Por fim, a integração dessa interface com
estrutura do Node-RED;
Aplicação do framework proposto: foi criado um dashboard utilizando serviços de

dados de diversas cidades espalhadas pelo mundo. A intenção era mostrar a
viabilidade do uso do framework. A aplicação consistiu de dois passos:
• Criação de um conjunto de nós para utilizar dados através de um fluxo. Foi

criado um conjunto de nós para demonstrar a funcionalidade do Node-RED e
sua integração com as APIs de dados abertos de cidades.
• Desenvolvimento de um protótipo com funções comuns às cidades inteligentes
de grande porte, demonstrando a utilização e funcionalidade dos nós no Node-
RED.
Avaliação da utilização do framework: com o intuito de validar a proposta junto aos

desenvolvedores, foi realizada uma avaliação que pudesse mensurar e concluir
sobre a experiência de utilização do framework no processo de criação de painéis
de dados para cidades inteligentes.
1.3 Justificativa
O desenvolvimento de novas tecnologias e métodos que facilitem o aumento de
produtividade de equipes de desenvolvimento de software, sempre foi uma temática
latente. Desenvolver software é uma tarefa complexa por si só, e isso foi estímulo para
muitas iniciativas que foram criadas durante a história da computação. Diante disso,
utilizar novas tecnologias no desenvolvimento de novos projetos vem sendo uma prática
cada vez mais difundida e sua aceitação cresce desde o momento mais incipiente desse
movimento. Os padrões de projetos 3 , por exemplo, foram meios de se elevar ganhos
na produção de software por utilizar soluções que resolviam problemas em contextos
semelhantes. Atualmente, utilizar esses padrões é algo comum no meio da comunidade
de desenvolvimento de software.
Diversas tecnologias surgiram com a visão de ajudar em como se cria produtos
digitais. Elas nascem na busca constante por melhorar processos, produtos, métodos e a
3
Um padrão descreve um problema que se repete constantemente. Eles foram postulados pelo arquiteto
Christopher Alexander.
cultura da comunidade de software. É de suma importância estar atento ao surgimento

dessas tecnologias, de modo a lançar mão delas na busca por oferecer agilidade, perso-
nalização e flexibilidade às equipes. Esse trabalho buscou unir tecnologias que surgiram
com essa perspectiva, com foco voltado ao desenvolvimento de dashboards para cidades
inteligentes.
1.4 Organização do Trabalho

Os capítulos subsequentes são organizados da seguinte forma: o Capítulo 2
apresenta uma revisão teórica que trata dos elementos preponderantes desta pesquisa:
as smart cities e os dashboads. Ademais, mostra também alguns trabalhos relacionados e
uma discussão sobre a contribuição que estes trabalhos têm sobre o desenvolvimento
desta pesquisa. O Capítulo 3 traz as bases tecnológicas para o tangenciamento da
criação do framework, bem do uso da metodologia proposta. Os padrões de projeto e
também os padrões de interface web, assim como o Node-RED. Mostrando como estes
elementos se entrelaçam para proporcionar o melhoramento no desenvolvimento de
dashboards. O Capítulo 4 apresenta o SmartNode Dashboard, sua construção, arquitetura,
possibilidades e perspectivas. Outrossim, este capítulo expõe a metodologia de uso
do SmartNode Dashboard com a tecnologia Node-RED. Elencando sua metodologia de
aplicação, e comparativo entre outras metodologias para criação de dashboards. No
capítulo subsequente é exibido os resultados da validação de uso com programadores.
Essa validação trás resultados de testes realizados com programadores para aferir se
a metodologia proposta, assim como o uso das tecnologias trabalhadas, conseguem
cumprir os objetivos propostos. Por fim, no Capítulo 6 traz um resgate do trabalho
apresentado e suas considerações finais, assim como as contribuições e os trabalhos
futuros.
20
2 CONCEITOS BÁSICOS
Este capítulo descreve conceitos centrais relacionados aos temas abordados neste
trabalho, como (i) cidades inteligentes; (ii) padrões de interfaces; e (iii) node-RED, dos
quais foram utilizados para dar suporte ao desenvolvimento deste trabalho.
2.1 Smart City

Com uma população que cresce tão rapidamente, as cidades acumulam inúmeros
problemas que tendem a ser potencializados com esse aumento imensurável. Problemas
de congestionamento do trânsito, moradia, acesso à saúde, gerenciamento de resíduos,
poluição do ar, ocupação do espaço, transporte público, se tornam grandes desafios por
conta da alta demanda de acesso. É nesse contexto que o conceito de cidade inteligente
emerge como uma nova dimensão da gestão pública na difícil missão de solucionar esses
desafios (WEISS; BERNARDES; CONSONI, 2015).
O termo “Cidade Inteligente” teve seus primeiros registros no início da década de
90, contudo, apenas nos últimos anos é que as tecnologias estão sendo empregadas à
sistemas de informação na integração das operações de serviços e infraestrutura urbana
(FALCÃO; BAPTISTA; MENEZES, 2012). Esse termo foi cunhado a fim de conceituar o
fenômeno de desenvolvimento das cidades que cada vez mais se tornavam dependentes
de tecnologia, inovação e globalização, principalmente em uma perspectiva econômica
(RIZZON et al., 2017). Para Leem e Kim (2013), o fator central para mudança dos
paradigmas das cidades está relacionado diretamente com as TICs. A grande utilização
das TICs nas cidades, na busca por promover melhorarias estruturais e que consiga
entregar, de forma precisa e dinâmica, comodidade aos cidadãos, vários autores indicam
que uma Smart City pode ser definida principalmente, pelo amplo emprego de TICs em
infraestruturas tradicionais, bem como para melhorar a participação ativa de capital
humano e social (RIZZON et al., 2017). Essa noção está intimamente ligada à economia
do conhecimento, às mudanças na aglomeração espacial e ao desenvolvimento urbano
baseado no conhecimento (MACKE et al., 2018). De uma forma simples, o conceito de
smart cities, ou cidades inteligentes, pode ser definido pelo amplo uso das tecnologias
com intuito de melhorar a infraestrutura das cidades e transformar os centros urbanos
em locais mais eficientes e melhores de se viver.
Esse é um ambiente extremamente rico para novas experiências, onde o uso
intensivo de tecnologias de comunicação e informação está intimamente ligado ao
contexto, se tornando parte da gestão urbana, focadas nas ações sociais onde os dados
Capítulo 2. CONCEITOS BÁSICOS 21
são os fatores preponderantes que orientam essas estratégias. Dessa forma, os projetos
das cidades integram três principais áreas: Internet das Coisas (IoT); Big Data e a
governança por algoritmos, onde o planejamento está baseado em ações apoiadas por
algoritmos. O intuito maior é a geração de condições que enfoquem sustentabilidade,
melhoria das condições para as populações e incentivo a geração de uma economia
criativa pela gestão baseada em análise de dados.
Leem e Kim (2013) esclarecem que as cidades podem ser classificadas conforme
o nível de tecnologias que são empregadas em seus espaços, e assim poderiam ser
categorizadas em quatro diferentes nomenclaturas:
• Digital City: refere-se a uma comunidade conectada que combina infra-estrutura de

comunicações de banda larga; uma infraestrutura de computação flexível, orientada
a serviços, baseada em padrões abertos da indústria; e serviços inovadores que
atendam às necessidades dos governos e seus funcionários, cidadãos e empresas.
• Intelligent City: são definidas como territórios que trazem sistemas de inovação
e TICs dentro da mesma localidade, combinando a criatividade de indivíduos
talentosos que compõem a população da cidade, instituições que melhoram a
aprendizagem e inovação e espaços de inovação virtual facilitando a inovação e
gestão do conhecimento.
• Smart City: se destaca pelo uso de tecnologias de computação inteligente para

tornar os componentes e serviços de infraestrutura crítica de uma cidade (admi-
nistração municipal, educação, saúde, segurança pública, imóveis, transporte e
serviços públicos) mais inteligentes, interconectados e eficientes.
• Ubiquitous City: caracteriza a cidade totalmente equipada com redes através das
quais as autoridades municipais do governo, central e local, podem monitorar quase
tudo o que está acontecendo na cidade. Um exemplo disso é o monitoramento do
trânsito, prevenção de crimes e incêndio. Além disso, os usuários tem a capacidade
de acessar os serviços da rede de qualquer lugar.
O conceito de smart city é geralmente integrado ao uso de Tecnologia de Informa-

ção e Comunicação, especialmente na infraestrutura para monitoramento, gerenciamento
e tomada de decisão (SUAKANTO et al., 2013; BARNS, 2018). Esse conceito está for-
temente ligado a forma como as pessoas utilizam as informações para organizar suas
tarefas diárias, consumir informação ou até mesmo tomar decisões. Está intimamente
relacionado ao uso de tecnologias que facilitam o acesso aos dados proveniente das cida-
des. Dados sobre o trânsito, que ajudam a cidadãos orientar-se sobre que rota tomar para
ir às suas casas no retorno do trabalho, informações de promoções sobre algum assunto
de interesse baseado na sua localização, ou até mesmo suas preferências, previsão do
tempo para determinada região, são exemplos de como a população está ligando suas
vidas aos dados gerados pelas cidades.
2.2 Dashboard
O atual volume de dados e informações coletadas, armazenadas, compartilhadas
e usadas nos centros urbanos, são quase ilimitados (KOURTIT; NIJKAMP, 2018). Os
dados oriundos do monitoramento das cidades podem ser sumarizados numa estrutura e
disponibilizados para a visualização, servindo como ferramenta de tomada de decisões.
Esses dados podem ser alimentados em diversas formas de fontes, espalhadas por uma
cidade, que podem registrar informação e enviar para uma base concentradora de
dados. A informação sobre previsão do tempo, poluição do ar, o nível das águas dos
rios, indicador econômico, até mesmo as condições do tráfego, podem ser exibidas num
único painel (SUAKANTO et al., 2013). Kourtit e Nijkamp (2018) explicam que um
dashboard é uma ferramenta de gerenciamento estratégico que usa fatores críticos de
sucesso e indicadores-chave de desempenho para traduzir a missão e a estratégia de uma
organização em um conjunto equilibrado de medidas de desempenho integradas à ações
concretas relacionadas. A Figura 1 ilustra um dashboard com informações resumidas a
partir de dados gerados e tratados anteriormente.
Figura 1 – Dashboard com resumo de informações

Fonte: https://dribbble.com/shots/3768342-Robo-Advisor-Web-App/attachments/848451
Kourtit e Nijkamp (2018) esclarece que, na literatura sobre arquitetura de dashbo-

ards, ainda há muitas incertezas sobre como criar essas interfaces interativas para tomada
de decisões. Na maioria dos casos, as decisões sobre a concepção do design do painel é
baseado em circunstâncias específicas ou julgamento pessoal dos tomadores de decisão,
culminando numa falta de consistência. Com a grande utilização dos aparelhos móveis,
que dispõe de capacidade de processamento análoga aos computadores pessoais, os
indivíduos estão gradualmente mais habituadas a estes dispositivos, empregando-os nas
atividades mais triviais do dia a dia. A forma como esses sujeitos acessam informações
está extremamente diversificada, o que obriga a criação de novas facetas nas tecnologias
de disponibilização de informações. Isso mostra que os dashboards digitais se tornaram
uma constante nas nossas vidas digitais (BARNS, 2018).
A utilização dos dashboards deve ocorrer quando é necessário fornecer uma visão
geral de alto nível dos dados que permita descobrir tendências viáveis. Eles fornecem
informações em tempo real sobre o estado das métricas mais importantes de um deter-
minado sistema. Assim, a disponibilização desse tipo de ferramenta, para orientar os
cidadãos, de forma simples, é uma decisão que requer planejamento prévio sobre que
tipo de interface é mais adequada num determinado contexto.
2.2.1 Tipos de Dashboards
Existem 3 tipos mais comuns de dashboards, cada um desenvolvido com um

propósito específico. São eles:
Dashboards operacionais : exibem informações que facilitam as operações do dia a dia

de uma empresa. Os objetivos comuns podem ser monitorar o tempo de atividade
do servidor, as vendas diárias, as chamadas diárias feitas ou os compromissos
reservados. Painéis operacionais tornam-se o coração do negócio e geralmente
exigem dados em tempo real ou quase em tempo real.
Dashboards estratégicos e executivos : exibe KPIs (Key Performance Indicators) impor-

tantes, que as equipes executivas rastreiam periodicamente - diariamente, semanal-
mente ou mensalmente. O painel estratégico se concentra em fornecer uma visão
geral de alto nível do estado do negócio e aborda as principais mudanças que o
negócio cria. Exemplos de KPIs comuns podem ser a receita (em comparação com
o período anterior), os custos (em comparação com o período anterior), o pipeline
de vendas etc.
Dashboards analíticos : exibe dados operacionais ou estratégicos - ou ambos. O painel

analítico oferece funcionalidades de detalhamento, permitindo que os usuários
explorem dados em maiores detalhes.
2.2.2 Projetos de Dashboards
Atualmente há diversos trabalhos sendo desenvolvidos com foco na apresentação

de dados de cidades inteligentes. Londres, Boston, Dublin, Madrid, Macedônia, Amsterdã
tem se engajado no desenvolvimento de ferramentas para criar e manter city dashboards.
Há grande diversidade entre eles e suas propostas de interface são bastante heterogêneas.
Apesar essa grande variação, todos tem o mesmo propósito, exibir dados sumarizados.
Nessa seção são apresentados e discutidos trabalhos que abordam o tema central desta
pesquisa.
2.2.2.1 Londres e outras cidades do Reino Unido
O CityDashboard (nomenclatura dada ao projeto inglês) foi criado para dar

suporte às principais cidades do Reino Unido e foi desenvolvido por pesquisadores do
Centro de Análise Espacial Avançada da University College London - UCL. Ele resume dados
quantitativos vindo de fontes oficiais ou por meio de cooperação voluntária, das principais
cidades do Reino Unido (Londres, Cardiff, Edimburgo, Glasgow, Manchester, Leeds,
Birmingham e Newcastle). Este projeto é atualmente considerado uma referência entre a
maioria dos projetos e casos de estudo, para este tema. A Figura 2 mostra esse projeto
em duas fases. A primeira (projeto original), lado esquerdo, é a interface idealizada pelo
projetista de interfaces. A segunda, lado direito, é a interface implementada com dados
reais.
Das características mais relevantes deste projeto, seu padrão modular se destaca.
Ele é projetado para se adaptar conforme a tecnologia que dá suporte aos dados, se
expandindo quando é necessário. Por exemplo, caso as cidades que dispõe apenas de
módulos básicos, quiser incluir mais informações sobre determinado parâmetro (ou
novos), o projeto consegue se adaptar. A cidade de Londres, atualmente é a cidade
que contém mais módulos e é a interface que mais se aproxima do projeto de tela
original completa (onde todos os parâmetros projetados podem ser vistos, Figura 2,
lado esquerdo). As demais cidades contam com módulos mais genéricos e por isso o
dashboard mostra apenas alguns poucos dados.
Um ponto negativo a ser destacado é que a interface criada para este dashboard
não foi planejada para dar suporte a outros tipos de telas, além do desktop. Esse é um
aspecto que vai na contramão da evolução das tecnologias móveis e da experiência do
usuário. Apesar de ter sido criado em 2012, esse projeto não evoluiu seus padrões de
interface.
Figura 2 – Projeto CityDashboard projetado para cidades do Reino Unido

Fonte: http://oobrien.com/2012/04/citydashboard/
2.2.2.2 Sydney
O projeto de Sydney4 (Figura 3) aborda elementos visuais mais modernos que o

anterior. Assim como o dashboard da UCL, esse também foi desenvolvido num centro
de pesquisa. Ele faz parte do projeto City Futures, centro de estudos em ambientes
construídos da Universidade USNW5 Sydney.
Figura 3 – Projeto CityDashboard projetado para Sydney

Fonte: http://citydashboard.be.unsw.edu.au/
Este projeto se destaca dos outros city dashboards por oferecer uma característica
de layout fluído e que se adapta a diferentes telas, sobretudo em aparelhos celulares.
4
http://citydashboard.be.unsw.edu.au/
5
https://www.unsw.edu.au/
Apesar de contar com esse aspecto de adaptabilidade, vários de seus elementos não
se ajustam adequadamente em telas menores. Os elementos são ajustados de forma a
esticar o item para encaixar em espaços projetados. O mesmo acontece com as tabelas,
que precisam ficar exageradamente comprimidas nas telas menores, fazendo com que
seja necessário suprimir alguns dados, por não caber no espaço da tela.
2.2.2.3 Amsterdã
O City Dasboard6 (Figura 4) de Amsterdã é um esboço ainda em construção.

Apesar de já está em desenvolvimento há algum tempo, a sua primeira versão ainda
não foi lançada. Ainda assim, a sua interface e informações sobre o funcionamento já
podem ser acessadas na página oficial do projeto. Ele utiliza os dados abertos dispo-
nibilizados pela cidade e sua visualização pode ser realizada em tempo real. Outras
cidades podem utilizar esse projeto com a mesma interface. Ele utiliza como background
de pesquisa a dados a API CitySDK Linked Data7 , que pode tornar os dados em fontes
pesquisáveis e disponíveis sob demanda. Apesar de ser possível reaproveitar a interface e
replicar em outras cidades, essa replicação não contempla as diversas diferenças contidas
nas cidades. Onde cada centro urbano tem sua particularidade e demanda que suas
nuances sejam consideradas. A adaptação a diferentes tipos de centros é um aspecto
importante e fundamental para que os projetos, assim como esse, possam ser facilmente
reaproveitados.
Figura 4 – Projeto CityDashboard projetado para Amsterdã

Fonte: https://waag.org/en/article/city-dashboard-amsterdam
Essa seção mostrou alguns projetos de City Dasboards criados para as cidades do
Reino Unido, Sydney e Amsterdã. Há ainda diversos outros projetos espalhados ao redor
6
http://citydashboard.waag.org/
7
Uma API para a distribuição e anotação de dados abertos, para pequenas cidades ou até grandes áreas
metropolitanas. Ela faz parte do projeto CitySDK. (http://citysdk.waag.org/)
do globo que revelam inúmeras diferenças entre si, mas que seguem na mesma direção.
Alguns apenas mostram dados de forma sintética, sem o ideal de envolver o usuário no
processo ou de oferecer informação relevante. Nessa perspectiva, a escolha dos projetos
supracitados foi embasada na oferta de informações que sejam relevantes aos cidadãos.
Os projetos apresentados nessa seção se assemelham em diversos aspectos. In-
formações de dados como: saúde, transporte, recursos naturais, dentre outros; são
recorrentes nessas interfaces. Isso é comum pelo fato de que os cidadãos necessitam
basicamente dos mesmos tipos de serviços. Desse modo, é natural apresentar esses
parâmetros em tela. Contudo, mesmo mantendo os elementos comuns, cada cidade se
difere uma da outra, por diversas questões, e por isso um projeto que foi pensado para
um tipo de urbe pode não servir a muitas outras ou até mesmo nenhuma outra. Esse
é um fator que norteou o presente trabalho durante todo o percurso de análise. Cada
projeto tem como característica ou objetivo, sanar problemas de um determinado con-
texto. O SmartNode Dashboard, proposto na Seção 4, tem como principal característica
a adaptação a diversos tipos de situações diferentes. Por se tratar de um projeto de
código aberto, a própria comunidade de desenvolvimento de software pode contribuir e
se engajar na evolução dele.
2.3 Padrões
Para Cybis, Betiol e Faust (2015), "padrões se referem aos problemas mais comuns
e às boas soluções para esses problemas, que são capturadas, compartilhadas e reuti-
lizadas por profissionais atuando no projeto de diversos tipos de produtos e serviços".
Seu uso aumenta a eficiência não somente na etapa de programação, mas também na
utilização, onde oferece aos usuários usabilidade na interação com o sistema. O arquiteto
Christopher Alexander afirmou que um padrão descreve um problema e norteia a solução
de modo que se possa utilizar esta solução inumeráveis vezes sem nunca fazê-la da
mesma forma (GAMMA et al., 2000). Gamma et al. (2000) corrobora a asserção do
arquiteto e explica que, apesar de Alexander relacionar suas proposições ao contexto da
arquitetura, o cerne para ambos os tipos de padrões está a solução para um problema
num determinado contexto.
2.3.1 Padrões de Projetos
Na Engenharia de Software, os padrões de projeto são soluções bem estruturadas

para problemas frequentes, dentro de um contexto específico. Leite (2005) explica que:
"Uma coisa que os projetistas avançados sabem que não devem fazer é
resolver cada problema a partir de princípios elementares do zero. Ao
invés disso, eles reutilizam soluções que funcionaram no passado, e que

as utilizam repetidamente em seus projetos".
Dessa forma, os problemas recorrentes, que já contam com soluções testadas, são
reaproveitados num momento futuro, resolvendo um outro problema num contexto
semelhante. O foco por trás disso é não necessariamente reaproveitar o código criado para
um problema e utilizá-lo em uma nova situação, mas o aproveitamento de soluções de
projetos de uma maneira geral.
2.3.2 Padrões de Interface Web
Para a equipe que deve desenvolver novos produtos, os padrões são uma forma
de reduzir tempo no processo de desenvolvimento. Além de terem maior consistência e
menor risco em violar os padrões de interface, a cultura de padronizar eleva a qualidade
dos artefatos construídos. A adoção dos padrões de interface permitem:
• Minimizar o tempo e esforço de design;
• Aumentar a qualidade das soluções de design;
• Auxiliar na comunicação entre designers e programadores.
Cybis, Betiol e Faust (2015) explicam que diversas bibliotecas de padrões de

projeto de interfaces estão disponíveis pela web. Esses conjuntos de padrões são úteis
para ajudar os projetistas como fonte de inspiração e pesquisa, quando é necessário
projetar um determinado recurso ou elemento da interface. Dentre essas bibliotecas, as
mais utilizadas são:
• Ui Patterns, disponível em: http://ui-patterns.com/;
• WELIE Interaction Design Patterns, disponível em: http://www.welie.com;
• Patternry, disponível em: http://www.patternry.com/;
• ZURB Library, disponível em: http://patterntap.com/library;
• Designing Interfaces: Patterns for Effective Interection Design,

disponível em: http://designinginterfaces.com/;
Do ponto de vista de quem interage com a interface, os padrões podem proporci-

onar níveis superiores na intuitividade e facilidade de uso para usuários intermediários
e avançados. Harley (2017) explica que experiências passadas e práticas repetidas in-
formam expectativas aos usuários. Desvios da rotina aprendida levam os usuários a
enganos. Ao manusear uma interface que já foi utilizada antes, um usuário irá reco-
nhecer padrões, essa é a parte que nos permite executar processos complicados sem
esforço consciente à medida em que praticamos esse processo. A reprise de uma ação -
idealmente do mesmo modo a cada vez - é como aprendemos e guardamos essa ação
em nossa memória processual. As variadas formas como os usuários têm para interagir
com uma interface, tomar uma ação específica (ou conjunto de ações) e obter o mesmo
resultado, servem para reforçar o padrão e consolidá-lo em nossa memória (HARLEY,
2015). A mudança dos padrões quebram as expectativas dos usuários, fazendo com que
seja necessário reaprender uma interface que já havia sido desmistificada anteriormente,
gerando uma maior esforço cognitivo. Segundo uma lei de usabilidade criada por Jakob
Nielsen, intitulada Lei de Jakob sobre a experiência do usuário na Web (Jakob’s Law of
the Web User Experience), os usuários passam a maior parte do tempo navegando em
diferentes sites. Dessa forma, qualquer coisa que seja uma convenção e usada na maioria
dos outros sites, será gravada na memória destes usuários e o custo para desviar-se delas
é ser penalizado com grandes problemas de usabilidade para seu site (NIELSEN, 1999).
Nielsen (2004) explica que é preciso eliminar elementos de design que causam
confusão e procurar mover-se o máximo possível para o campo das convenções de design.
Não só isso, é preciso estabelecer padrões de projeto para todas as tarefas importantes
da interface. Os padrões podem garantir aos usuários:
• saber quais recursos esperar;
• saber como esses recursos serão exibidos na interface;
• saber onde encontrar esses recursos no site e na página;
• saber como operar cada recurso para atingir seu objetivo;
• não precisem ponderar sobre o significado de elementos de design desconhecidos;
• não percam recursos importantes por ignorar um elemento de design fora do

padrão; e
• não terem surpresas desagradáveis quando algo não funciona como esperado.
Esses benefícios aumentam o senso de domínio dos usuários sobre o site, au-
mentam sua capacidade de realizar tarefas e aumentam sua satisfação geral com a
experiência.
2.3.2.1 Consistência de Padrões
Para Nielsen (1995), os usuários não devem se perguntar se palavras, situações ou

ações diferentes significam a mesma coisa. Sua responsabilidade é eliminar ao máximo
a frustração oriunda de comportamento inesperado e/ou que não foram claramente

informados pelo sistema. É necessário assegurar a consistência da interface com o modelo
conceitual embutido no sistema (BARBOSA; SILVA, 2010). Dessa forma, ao lançar mão
de tecnologias que utilizam padrões, é possível conceber projetos mais qualificados e
que têm menor tendência em confundir seus usuários.
2.3.2.2 Cards
Os padrões de interface tem diversas aplicações. Elas implicam numa determinada

forma de visualizar conteúdo ou até mesmo como um determinado grupo de elementos
devem se comportar numa dada situação. Os cards (cartões), por exemplo, constitui um
grupo de padrões de interface do tipo conteúdo. Eles são usados para exibir conteúdo
de forma detalhada ou num formato específico. Um card pode conter apenas imagens,
imagens com textos, apenas textos ou apenas um link. Apesar de sua versatilidade em
poder ser manipulado de diversas formas, o seu formato mais tradicional, geralmente, é
composto dos seguintes tipos de mídias: título, imagem, breve resumo e um botão de
ação.
Uma das características mais importantes acerca dos cartões é sua capacidade de
ser manipulado quase infinitamente. Eles podem ser virados para revelar mais informa-
ções, empilhados para economizar espaço, dobrados para um resumo - e expandidos para
mais detalhes, classificados e agrupados. Sua versatilidade é ideal para uso em diversas
plataformas de renderização, tais como: smartphones, tablets, notebooks, desktops, dentre
outros. Na Figura 5, o dashboard composto por cards, mostra como este padrão pode ser
Figura 5 – Exemplo de dashboard utilizando cards como padrão de interface

Fonte: https://dribbble.com/shots/3768342-Robo-Advisor-Web-App
utilizado de forma diferentes, em vários tipos de conteúdos, se adequando a eles.

31
3 BASE TECNOLÓGICA
Esse capítulo procura apresentar a base tecnológica em que este trabalho se

utilizou para desenvolver o SmartNode Dashboard, bem como a metodologia de uso de
criação de dashboards utilizando a plataforma Node-RED.
3.1 CSS
A finalidade das CSS é oferecer um mecanismo de estilizar o conteúdo das
linguagens de marcação. No presente contexto, a linguagem de marcação, HTML, será o
responsável por estruturar o documento de conteúdos e o CSS irá realizar a tarefa de
configurar a aparência do documento.
3.1.1 Características
CSS é capaz de estilizar uma página web de forma padronizada, fornecendo mais
funcionalidades com um número reduzido de instruções. Entre as principais vantagens,
é possível destacar:
• Facilidade de manutenção: é possível atualizar um projeto inteiro com poucas

alterações no código de estilo. O efeito que é produzido em cascata faz com que
todos os projetos que utilizem o recurso de estilo, seja afetado de igual forma;
• Separação dos documentos de formatação e estilo: é possível um documento

referenciar um documento de estilo, dessa forma é possível reaproveitar o mesmo
código CSS em diversos projetos diferentes.
3.2 Frameworks
Um framework pode ser definido como um conjunto de conceitos para resolver
problemas de um determinado contexto (CAY, 2007). No desenvolvimento de software, o
framework consiste de uma abstração que é constituída de vários códigos pré-formatados
que tem por filosofia promover uma funcionalidade padronizada. Eles capturam as
funcionalidades comuns a várias aplicações e fornecem a reutilização de código e
padrões de design. Monteiro (2002) faz uma definição de framework dentro do contexto
Capítulo 3. BASE TECNOLÓGICA 32
de padrões de projetos. Para ele, podemos ver um mecanismo como um padrão de projeto
de forma aplicada a um conjunto de classes e um framework é um padrão de arquitetura
que fornece um modelo extensível a qualquer aplicação dentro de um domínio específico.
Essa visão pode ser útil quanto a utilização e reutilização de um framework, onde é
possível a evolução de padrões já implementados, na forma de especialização, por
conta de uma necessidade específica dentro de um projeto. Cay (2007) explica que isso
acontece devido a necessidade que cada projeto pode apresentar, e dessa forma um
programador pode criar uma funcionalidade nova no domínio do problema, bastando
para isso estender as classes do framework. Essa abordagem pode ser aplicada a diversos
domínios de problemas e em outras tecnologias. Esse mesmo tipo de abstração, de
orientação a objetos, pode ser aplicada no contexto das linguagens de marcação, como é
o caso de projetos escritos em CSS.
3.2.0.1 Frameworks Front-end
Os frameworks front-end tem seu foco voltado para o desenvolvimento de in-

terfaces web, ou que seja executado por meio do auxílio de um navegador. Há ainda
a possibilidade de diversificar sua finalidade baseando-se nos objetivos intrínsecos ao
qual foi projetado. Um exemplo disso são os projetos focados apenas na construção de
artefatos para dispositivos móveis, outros que tem a única finalidade de formatar o grid,
ou aqueles projetados para suprir demandas do desenvolvimento em dispositivos de
impressão. Estes são frameworks menos comuns, haja visto que a maioria abarca uma
grande variedade de dispositivos, e assim se tornam mais interessantes aos desenvolve-
dores, que não precisam procurar vários projetos para cada demanda específica. Assim
como nos frameworks desenvolvidos em linguagens de programação, utilizando a ideia
de design patterns, estes bebem da mesma fonte, buscando abstrair os fundamentos
básicos e aplicando de forma a solucionar os problemas deste domínio próprio.
Esses frameworks front-end se tornaram muito populares em agosto de 2011,
quando houve uma primeira publicação do projeto Twitter Bootstrap8 . Otto (2012) define
o Bootstrap como sendo um kit de ferramentas de front-end de código aberto criado
para ajudar designers e desenvolvedores a construir de maneira rápida e eficiente coisas
incríveis on-line. O Bootstrap é um projeto desenvolvido pela equipe do Twitter, original-
mente chamado de Twitter Blueprint e sua ideia principal era servir como instrumento
para incentivar os projetistas e programadores a trabalhar com mais consistência no
desenvolvimento de projetos de interface web (SILVA, 2015).
Atualmente há um número vasto de frameworks disponíveis na internet. Gerchev
(2018), Arsenault (2018), Anand (2017) apontam que entre os mais populares podemos
8
http://getbootstrap.com/
destacar os projetos mostrados na Tabela 1. Silva (2015) defende que a utilização de um

Tabela 1 – Lista com os principais frameworks front-end do mercado
Nome Criador Popularidade (es- Versão Ano
trelas no Github)
Bootstrap Mark Otto e Jacob 125.353 4.0 2011
Thornton
Foundation Zurb 27.383 6.0 2011
Pure CSS Yahoo 18.710 1.0.0 2013
Semantic UI Jack Lukic 41.651 2.2 2013
UI Kit YOOtheme 11.604 3.0.0 2013
framework front-end ajuda a aumentar a flexibilidade na codificação, além de oferecer

vários componentes de design flexíveis, com documentação robusta. Isso ajuda tanto na
manutenibilidade, quanto na evolução dos projetos. Recorrer a esse tipo de estrutura,
torna o desenvolvimento front-end acentuadamente mais rápido e menos complexo,
sobretudo garantindo mais conformidade ao código produzido.
Arsenault (2018) destaca que a escolha de um framework front-end não deve
ser baseada em sua popularidade, essa decisão precisa ser focada na conformidade da
estrutura com necessidade do desenvolvimento de cada projeto em questão. Todos os fra-
meworks listados anteriormente implementam diversos padrões de interface, utilizando
para isso código HTML e CSS.
3.2.1 Templates de Interface Web
Kalbach (2009) define templates como sendo coleções de arranjos de mecanismos

de navegação pré-definidas. É desejável que para projetos grandes ou que envolvam
muito trabalho, a sistematização de regras que gerenciem como a navegação e conteúdo
são mostrados, seja empregada para que o projeto apresente consistência. Esse tipo de
abordagem garante que os módulos terão o comportamento previsível, conforme foram
projetados. A Figura 6 mostra o funcionamento de um template web.
Conforme a Figura 6 ilustra, há uma estrutura pré-definida que recebe dados e
é processada pelo Template Engine que tem a responsabilidade de fundir o modelo e
os dados, e posteriormente gerar o documento visual como produto resultante desse
processo.
Essas estruturas também permitem que seja possível reutilizar módulos, facili-
tando e reduzindo o trabalho com implementação. Isso acontece porque não é necessário
nem redesenhar e nem reprogramar módulos comuns, ao invés disso é possível utilizá-los
novamente sempre que preciso (KALBACH, 2009; ZANETTE, 2014).
Figura 6 – Funcionamento de um template
3.3 Node-RED
O Node-RED é uma ferramenta para conectar virtualmente os dispositivos, APIs e
serviços online. Ele fornece um editor baseado em fluxo, com interface em navegador
web, que facilita a tarefa de conectar os fluxos apenas arrastando e soltando os nós
(KIRAN et al., 2017). Kiran et al. (2017) destaca que o ponto mais interessante dessa
ferramenta se concentra no tempo de execução leve, pois é construído sobre o Node.js, e
por isso aproveita ao máximo o modelo não bloqueante e orientado a eventos que esta
tecnologia oferece. Originalmente desenvolvida pela equipe de Serviços de Tecnologia
Emergentes da IBM e, posteriormente, tornou-se tecnologia de código aberto, atualmente
mantida pela Fundação JS (KODALI; MANDAL; HAIDER, 2017).
3.3.1 Nós
Os nós consistem, geralmente, em um par de arquivos: (i) um arquivo JavaScript,

que é responsável por definir a funcionalidade do nó, ou seja, toda programação do nó
fica nesse arquivo; e (ii) arquivo HTML, para a definição das propriedades, edição da
Figura 7 – Tela principal do Node-RED com exemplo de fluxo de dados
caixa de diálogo e o texto de ajuda. O nó é empacotado como um módulo npm9 através

de um arquivo package.json. A Figura 8 mostra os arquivos presentes em um nó.
Figura 8 – Representação dos arquivos de um nó no Node-RED
3.3.1.1 Tipos de nós existentes
No Node-RED cada nó é desenvolvido com uma finalidade. Eles podem ser subdi-
vididos em três tipos distintos: entrada, processamento e saída.
9
NPM é a abreviatura para Node Package Manager. Ele pode ser utilizado para representar o repositório
online para publicação de projetos de código aberto para o Node.js, além de ser um utilitário de linha
de comando responsável por interagir com o repositório e instalar dependências.
Nó de entrada (inputs): são responsáveis pela entrada de dados em uma aplicação.

Assim sendo, todos os nós que lidam com a entrada de dados a partir de fontes
externas, são categorizados como nós de entrada;
Nó de processamento (functions): são as funções que manipulam dados oriundos pe-

los nós de entrada. Esses são os nós mais comuns, pois eles processam e disponibi-
lizam estes dados para uma determinada saída;
Nó de saída (outputs): são responsáveis pela saída dos dados, ou seja, externaliza os
dados tratados para um outro meio.
3.3.1.2 Criação de novos nós
Antes de criar um nó, é recomendado uma versão 5.0 ou superior da máquina

virtual do Node.js instalada. Conforme é mostrado na Figura 8, um nó é composto de
três arquivos. Para ilustrar o processo de criação de um nó, é descrito os passos básico
para concepção do OnibusNatal (um nó para recuperar dados dos ônibus da cidade de
Natal). Esse exemplo é mostrado a seguir, com as funcionalidades básicas que devem
conter na criação de um nó:
• package.json: este é um arquivo padrão usado pelos módulos Node.js para descre-
ver seu conteúdo e o Node-RED segue esse mesmo padrão. Para gerar esse arquivo,
a documentação oficial indica a utilização do prompt, usando o seguinte comando:
npm init. Na sequência é necessário responder uma série de perguntas para ajudar
na criação do conteúdo inicial deste arquivo de configuração. O resultado final
deverá se parecer com a Figura 9.
Ele informa, em tempo de execução, quais arquivos o módulo contém. Essa es-
trutura de documento é uma estrutura básica que um package.json deve conter,
contudo é possível obter mais informações sobre configurações extras e outras
propriedades que podem ser definidas antes de publicar o nó. Para isso basta
consultar o guia de pacotes, disponível no site oficial.
• onibus-natal.js: O Node-RED empacotado o nó como um módulo Node.js. O módulo

exporta uma função que é chamada quando o nó é carregado na inicialização. A
função é chamada com um único argumento, RED, que fornece acesso do módulo
ao Node-RED runtime API. O próprio nó é definido como uma função, OnibusNatal(),
que é chamada sempre que uma nova instância, sua, é criada. É então passado um
objeto contendo as propriedades específicas, definidas no editor de fluxo. A função
chama a função RED.nodes.createNode para inicializar os recursos compartilhados
por todos os nós. Posteriormente o código específico dele permanece.
Figura 9 – Código gerado após a configuração do package.json via linha de comando.

Fonte: Adaptado do site oficial do Node-RED
Figura 10 – Código gerado após a criação do onibus-natal.js para o nó.

Nessa instância, o nó registra um ouvinte (listener) no evento de entrada, que

é chamado sempre que uma mensagem chega ao nó. Dentro desse ouvinte, ele
altera o payload para minúscula, em seguida, chama a função enviar (send) para
transmitir a mensagem no fluxo. Finalmente, a função OnibusNatal() é registrada
em tempo de execução usando o nome do nó, onibus-natal. Se o nó tiver al-
guma dependência de módulo externo, elas deverão ser incluídas na seção de
dependências do arquivo package.json. A Figura 10 mostra o resultado do arquivo
onibus-natal.js.
• onibus-natal.html: Como já foi descrito anteriormente, esse arquivo tem a fina-

lidade de definir propriedades do nó que são visualizadas no editor visual. Ele
contém três partes distintas, sempre envolvidas entre as tags <script>.
– A definição principal do nó, registrada no editor. Ela indica informações como:

categoria da paleta, as propriedades editáveis e ícone a ser utilizado.
– Modelo de edição que define o conteúdo da caixa de diálogo de edição
do nó. Ele é definido dentro de um <script> do tipo text/x-red com o
data-template-name definido para cada tipo de nó.
– Texto de ajuda que é mostrado na barra lateral de informações. Ele é defi-
nido dentro de um <script> do tipo text/x-red com o data-template-name
configurado para cada tipo de nó
Para ilustrar a descrição realizada nessa seção, a Figura 11 mostra o código para
editar a propriedade nome, do nó.
Figura 11 – Código gerado após a criação do onibus-natal.html para o nó.

Essa seção mostrou, ainda que de forma sucinta, a sequência para criação de
um nó. Ainda que de forma simples, é o processo que deve ser seguido para construir
um nó em Node-RED. Para mais informações sobre o funcionamento e a documentação
completa, é importante acessar a página oficial. Outras propriedades e funcionalidades

podem ser inseridas e proporcionar a criação de nós mais complexos e funcionais.
3.3.2 Fluxos
A programação no Node-RED acontece através da conexão de nós. Obrigatoria-

mente, é preciso de um nó de entrada e um nó de saída. O nó de entrada é responsável
por iniciar a aplicação. Enquanto o nó de saída é responsável por realizar a saída do
processamento dos dados. Geralmente uma aplicação é desenvolvida utilizando os três
nós, gerando uma estrutura de fluxo com entrada, processamento e saída. A junção dos
nós, organizados numa sequência de funcionamento, trabalhando em conjunto para
obter um determinado resultado, é considerado um fluxo. Os dados seguem a estrutura
desenhada pelo fluxo, ao longo dos nós, percorrendo cada ponto, onde este é responsável
por uma ação isolada ou uma conjunto de ações. A Figura 12 ilustra o funcionamento de
um fluxo de dados simples.
Figura 12 – Exemplo do fluxo de dados no Node-RED
Por ter o desenvolvimento baseado em fluxos de dados, o Node-RED reduz a

complexidade no desenvolvimento de projetos de software. Através da sua interface de
editor, baseada em navegador, é possível realizar a conexão entre os nós, usando uma
coleção de nós na paleta. Eles podem ser inseridos em tempo de execução, de forma
rápida e dinâmica, através de poucos cliques.
Os fluxos criados no Node-RED são armazenados usando o formato JSON, que
podem ser facilmente importados de outras fontes ou exportados para compartilhamento
com outros desenvolvedores.
40
4 SMARTNODE DASHBOARD
Este capítulo apresenta o framework SmartNode Dashboard como resultado do

desenvolvimento deste trabalho, seus componentes de interface padronizados, bem
como o seu funcionamento e a metodologia de utilização. O SmartNode Dashboard
consiste num framework CSS que é responsável pela padronização dos elementos de
interfaces do dashboard. Por meio de sua estrutura de customizada de código, fornece
aos programadores a criação de interfaces mais eficazes e num curto espaço de tempo.
4.1 Desenvolvimento do Framework CSS

Para realizar a o desenvolvimento do SmartNode Dashboard foi necessário utilizar
a base de outro framework front-end, o Bootstrap Framework. Bootstrap oferece uma
biblioteca de componentes fáceis de serem customizados e reaproveitados, além de ser
um projeto de código aberto.
4.1.1 Customização do Bootstrap
Este framework front-end é voltado para o desenvolvimento rápido e fácil de sites

e aplicações web responsivos e alinhados com a filosofia mobile-first10 (SILVA, 2015). A
Tabela 2 mostra suas principais características.
Tabela 2 – Principais características do Bootstrap
Característica Descrição
Licença MIT
Conceitos Webdesign Responsivo e Mobile
First
Pré-processador Sass
Responsivo Sim
Modular Sim
Documentação Excelente
Suporte aos navegadores Últimos lançamentos do Fire-
fox, Chrome, Safari, IE810-11-
Microsoft Edge.
Atualmente o framework se encontra na versão 4.1, que expandiu o número de

componentes de interface disponíveis. Para o SmartNode Dashboard, ele é utilizado de
10
Conceito aplicado aos projetos web onde o foco parte inicialmente de uma arquitetura e desenvolvi-
mento centrado nos dispositivos móveis e posteriormente para os desktops.
Capítulo 4. SMARTNODE DASHBOARD 41
forma customizada, usando a base original do Bootstrap e algumas variantes extendidas,

que mudam de acordo com a aplicação. Para remover os demais arquivos do código
foi necessário recompilar o arquivo bootstrap.scss, removendo as importações dos
componentes extras e incluindo apenas a linha de importação de componente card; e os
demais arquivos base do Bootstrap.
4.1.2 Arquitetura de Código CSS
Para que a estrutura do código11 CSS fosse de fácil compreensão e reutilizável, foi
escolhida a metodologia de arquitetura de formatação BEM 12 . Essa arquitetura organiza
o código em três níveis: (i) bloco, (ii) elemento e (iii) modificador. Essa estrutura
é utilizada para organizar os componentes do framework. O componente básico do
SmartNode Dashboard é o card e dessa forma ele segue a estrutura mostrada na Figura
13.
Como mostrado na Figura 13, a nomenclatura básica das classes define como o
elemento do bloco é formatado.
.card: classe básica do componente card. Ele é o nível mais alto do bloco. É responsável
pela formatação do bloco principal;
.card__header: classe responsável por formatar o bloco de cabeçalho do card;
.card__body: classe que formata os elementos de conteúdo do card. O bloco de con-

teúdo que é formatado por esta classe, contém três sub-blocos, que dividem o
espaço de conteúdo e que pode ser formatado livremente. Os blocos internos são:
.card__body__top, um bloco para conteúdo acima; .card__body__content, que é
organizado para ser o elemento do conteúdo principal e .card__body__down, bloco
para conteúdo complementar;
.card__footer: classe responsável pela formatação do elemento de rodapé do card. Esse

bloco é voltado para incluir elementos de interação, como links.
Para que seja possível estender as funcionalidades, o bloco principal recebe uma
classe adicional. Essa classe deve manter a padronização nos nomes e adicionar um
modificador. Assim, ao invés de seguir a padronização dos nomes de blocos, deve receber
o nome do elemento pai e (14), adicionalmente, dois traços com o nome do modificador.
11
Para ter acesso ao repositório do código desse trabalho, acesse: https://github.com/cesimar/smart-
node-dashboard.
12
BEM significa Bloco, Elemento, Modificador. Metodologia de nomenclarturas de classes em CSS, para
criar código reutilizável. Criado em 2005, por uma empresa russa, surgiu por conta necessidade de
padronizar o código.
Figura 13 – Estrutura do Card utilizando a metodologia BEM
A Figura 14 mostra este padrão sendo utilizado com a nomenclatura da classe. Ela
está sendo modificada para receber uma especialização, a classe .card--tempo. Nesse
card de exemplo, os blocos estão sendo utilizados e cada um recebe uma formatação
diferente.
• o bloco de título recebe alguns dados extras, como um ícone que representa o card,
e seu respectivo título;
• o bloco de conteúdo com o seu topo contendo um texto informativo, no bloco

principal a informação da temperatura e no bloco abaixo, com informações com-
plementares;
• no bloco do rodapé, um link foi inserido para dar mais funcionalidades ao card.
Nele é possível acessar o link e "Ver em todos os bairros".
Figura 14 – Estrutura do Card utilizando a metodologia BEM, aplicada para o card de tempo.
4.2 Metodologia de utilização

A seguir é apresentada a metodologia proposta para criação de interfaces web
utilizando este framework, assim como os detalhes de utilização, funcionamento e
customização para se adequar aos projetos. Uma visão geral do processo de criação do
dashboard utilizando o SmartNode Dashboard é mostrada na Figura 15. O framework
atua como um formatador de estrutura front-end, através do código CSS. Por meio
dos padrões de interface, que são constituídos de códigos tags HTML, os elementos da
interface são organizados e estilizados.
De forma simplificada, a referida figura mostra a sequência de funcionamento de
todo o processo que é necessário seguir para atingir o resultado esperado, a organização
da interface do dashboard. Existem dois processos (processo de desenvolvimento e pro-
cesso de utilização) que podem acontecer de forma paralela ou sequenciada, dependendo
da necessidade do projeto.
Figura 15 – Visão geral do funcionamento do SmartNode Dashboard
4.2.1 Template de Interface Web
Para alcançar o objetivo geral deste trabalho, outros projetos de city dashboards
foram consultados com intuito de levantar os parâmetros mais comuns e relevantes às
cidades. A escolha das cidades para este levantamento foi baseada nos seus respectivos
portes e características, em comparação com a cidade de Natal. A partir do resultado
dessa análise os parâmetros foram agrupados considerando os que mais vezes se re-
petiram. A Figura 16 apresenta um gráfico com o percentual das ocorrências de cada
parâmetro neste conjunto de cidades.
Essa análise orientou no desenvolvimento do primeiro template, norteando sobre
os elementos que deveriam constar nessa interface. Itens de interface (clima, qualidade
do ar, qualidade de água, mapas da cidade, mapa do trânsito, câmeras de tráfego,
notícias, turismo, eventos, dados sobre transporte público, etc.) que geralmente constam
e que são importantes para que os cidadãos tenham acesso, foram definidos nesta etapa,
a partir do resultado apresentado na Figura 16. Aliado a isso, foi necessário levar em
conta outro fator sobre a cidade de Natal: seu grande potencial turístico. Por isso, para
esse template, usando o SmartNode Dashboard, convencionou-se que o dashboard seria
voltado à cidades com características turísticas.
Para testar a funcionalidade do SmartNode Dashboard, foi criado um template
utilizando um primeiro cenário para a cidade de Natal. Assim, foi possível utilizar
componentes de interface capazes de ilustrar o funcionamento de um City Dashboard
Figura 16 – Gráfico com os elementos comuns em city dashboards
com parâmetros comuns a outros centros urbanos com os mesmos aspectos. A Figura 17
apresenta a proposta de template simples, com as regras de navegação, com função de
mostrar como os elementos serão dispostos em tela.
Esse layout funciona como um mapa de navegação. Com as regras que cada
elemento deve seguir e consequentemente como será a visualização na tela. A Figura
17 mostra uma layout simples para tela desktop e smartphone. Todos os elementos
possuem perfil similar, com variação nas dimensões de largura e altura, que representam
a categorização das informações. Ou seja, mostra que cada informação pertence a um
grupo de informação diferente. A proposta deste template está dividida em três áreas
diferentes:
Cards fixos (CF00) : correspondem aos elementos de dados que não devem mudar.
Após definido pela equipe de desenvolvimento, esses dados não devem variar seus
elementos. Devem ser utilizados para elementos que devem exibir dados constantes
e que sejam de extrema relevância para os cidadãos. Exemplos: níveis poluição do
ar, informações do tempo, locais e disponibilidade de bicicletas, estações de metrô,
Figura 17 – Layout do template para cidade inteligente
dentre outros;
Cards destacados (CP00) : esse espaço pode ser configurado para se tornar variável, ou
seja, modificar conforme programação. Sua principal função e exibir informações
com mais destaques. Pode ser configurada para exibir informações do trânsito em
tempo real. Pode ser interessante a programação para ser exibida em horários de
grandes fluxos de tráfego;
Cards dinâmicos (CD00) : este espaço é direcionado para mudança de informação de

acordo com o local da cidade que o usuário se encontre. Dessa forma os dados
são visualizados e dinamicamente atualizados de acordo com o contexto que ele
esteja inserido. Oferecendo, desta forma, informações mais relevantes para que os
cidadãos consigam utilizar o dashboard como uma ferramenta que os auxiliem na
tomada de decisões.
A organização da interface na Figura 17 foi pensada de modo a organizar os

elementos da página de acordo com a tecnologia de visualização utilizada pelo o usuário.
Essa é uma preocupação com a experiência que o usuário terá ao navegar na página de
visualização de dados. É comum e desejável, por exemplo, que as pessoas acessem os
dashboards utilizando seus aparelhos móveis. Apesar de ser um desafio extra para os
projetistas, é mais cômodo e agradável às pessoas. Dessa forma, os itens que compõem
o layout precisam oferecer a esses utilizadores um modelo de navegação adequada.

Essa é uma preocupação que deve nortear qualquer projeto de interface, por isso, os
cards representados na Figura 17, com seus aspectos intrínsecos para serem ajustados a
diversificada gama de telas, foram escolhidos como padrão de interface. Essa figura além
de mostrar os itens visualizados em tela de desktops, exibir a progressão de informação
em interface móvel, ou seja, como ficará a mesma interface ajustada à tela de um
smartphone.
A partir do layout proposto na etapa de planejamento de interface do template, foi
criado o protótipo navegável. Os parâmetros incluídos nessa versão de protótipo são os
seguintes: clima, bicicletas, qualidade do ar, linhas de ônibus, mapa do trânsito, câmeras
de tráfego, agenda cultural. Para entender melhor cada parâmetro presente no protótipo,
a Tabela 3 descreve cada um.
Tabela 3 – Parâmetros incluídos no protótipo 1
Nome Descrição
Informações sobre clima: temperatura atual, velocidade do
Clima
vento e umidade do ar.
Informações sobre bicicletas de aluguel, e as estações são
Bicicletas mostradas aleatoriamente: nome da estação, slots de devolu-
ção disponíveis, bicicletas disponíveis.
Informações sobre qualidade do ar: status da qualidade do
Qualidade do Ar
ar, nível de poluição, níveis de: CO2, NO2, SO2, O3.
Informações sobre ônibus urbanos que circurlam nas proxi-
Linhas de Ônibus
midades.
Mapa do Trânsito Exibe o mapa com o status do trânsito em tempo real.
Agenda Cultural Informações sobre eventos culturais na cidade.
Exibe as imagens das câmeras de trânsito disponíveis na
Câmeras de Tráfego
cidade, informa total de câmeras.
O resultado da integração entre o SmartNode Dashboard e o template é apresen-

tado na Figura 18. Por ainda se tratar de uma demonstração, os dados apresentados na
figura são oriundos de base dados de diversos lugares diferentes. Isso foi feito com a
finalidade de demonstrar a capacidade da plataforma de se adequar a diferentes APIs de
dados.
4.2.2 Processo de Desenvolvimento
Esse processo corresponde aos métodos de implementação de uma estrutura de

código para o dashboard. Vale ressaltar que há dois formatos de template, o primeiro
é uma estrutura que contém apenas HTML e CSS. Ou seja, é a perspectiva de como
ficará a interface, código front-end. Já o segundo é o modelo reutilizável na plataforma
Figura 18 – Protótipo a partir da implementação do template utilizando o SmartNode Dashboard
Node-RED, ou seja, é um fluxo utilizando os nós propostos. Para deixar essas diferenças
mais claras e realizar a implementação, os passos seguintes mostram como isso funciona:
Passo 1. Criação do modelo de renderização: no primeiro momento, o desenvolvedor

deve criar uma estrutura de código em HTML, do template. Esse código já se integra
ao código CSS do SmartNode Dashboard. Ele é apenas um código base, para a
organização da interface, sendo considerado uma prévia da estrutura final;
Passo 2. Implementação do fluxo: em seguida é necessário utilizar o node-RED para

criar do fluxo de como o template (modelo de renderização) deverá funcionar.
Há o fluxo principal e diversos sub-fluxos funcionando juntos. Cada sub-fluxo,
contido nesse fluxo principal, representará um parâmetro (card) de visualização
no dashboard (clima, trânsito, etc). Cada sub-fluxo funciona com um par de nós,
um para se conectar às fontes de dados e um segundo para receber e renderizar
os dados. Dessa forma, o fluxo principal será divididos em vários fluxos menores
e no fim eles se ligarão no último nó, que é um nó de configuração do layout do
dashboard. Esse fluxo terá dois nós, respectivamente, o primeiro para entrada da
requisição e último para resposta com o dashboard renderizado;
Passo 3. Compartilhamento de fluxo: o compartilhamento do código do template fina-

lizado através do repositório oficial do Node-RED. Para isso é preciso primeiramente
criar uma conta no repositório oficial deles. Após esse passo, basta acessar a página
de flows do site oficial. Nessa página contém um guia de como fazer a inclusão de
um novo nó ou fluxo e em seguida compartilhar.
4.2.3 Processo de Implantação
Esse segundo estágio corresponde a etapa de utilização do fluxo e implantação do

painel de dados. Ou seja, eles não são obrigatoriamente sequenciais, podem acontecer
isoladamente. É possível uma equipe de desenvolvimento utilizar uma estrutura pronta
a partir da importação do repositório oficial. Bastando para isso, realizar a instalação
dos nós por meio do editor, no Gerenciador de Paleta, ou proceder com a cópia do
código disponível na página do repositório e importar no Node-RED. Para isso, a seguir é
explicado a sequência de passos necessários:
Passo 1. Importação de fluxo: para executar a importação da estrutura compartilhada,

a partir do repositório, basta utilizar a Gerência de Paletas (Manage Palette) da
plataforma, digitando o nome do arquivo cadastrado no repositório. Após isso, caso
o item seja encontrado, irá aparecer a opção de instalar;
Passo 2. Configuração dos serviços: Após o passo anterior, é preciso configurar os

serviços. Alguns serviços de acesso a dados, disponibilizados por meio de APIs
das cidades, precisam de credenciais de acesso. Algumas delas precisam, obriga-
toriamente, de usuário e senha, ou até mesmo outras formas de segurança mais
complexas. Há outros serviços que precisam configurar o retorno de dados e por
isso é preciso realizar a configuração de cada uma delas.
Passo 3. Deploy e publicação: Esse passo corresponde a última atividade antes da

disponibilização do dashboard. Para isso basta realizar a implantação (deploy)
direto na plataforma.
4.2.4 Integração ao Node-RED
Antes de explicar a integração ao Node-RED, vamos retornar à Figura 6, que

fornece uma visão geral de como é o funcionamento de um template. A interface final
é resultado da composição de três elementos que funcionam em conjunto: (i) a fonte
de dados (nesse contexto, os serviços de dados das cidades), (ii) o padrão web (com
a estrutura HTML do conteúdo e o formatador de conteúdo em CSS) e (iii) o template
engine (a tecnologia que combina todos os elementos para visualização) para compilar
em artefato digital com as informações. O Node-RED faz o papel do template engine e é o

responsável por toda parte de lógica e programação do processo.
A principal função do Node-RED no contexto desse projeto é abstrair a comple-
xidade de uma infraestrutura robusta e de grande porte para executar o projeto de
city dashboard. Isso é possível pela capacidade que essa infraestrutura oferece, além do
seu padrão de programação por fluxos, que oferece altos níveis de produtividade no
desenvolvimento. Assim, é possível, de forma simples e rápida, a disponibilização do
template em execução.
Para tanto, foi criado um fluxo de dados e nós específicos. Alguns nós já são
disponibilizados na biblioteca de itens do Node-RED, o que reduz drasticamente o
trabalho para algumas demandas de desenvolvimento do projeto. Por exemplo, a Figura
19 mostra o fluxo criado para desenvolver o primeiro template de Dashboard, esse fluxo
criado para demonstrar a funcionalidade da plataforma, utilizou nós do próprio Node-
RED, outros disponibilizados por terceiros, além dos nós criados neste projeto, para
representar os cards que renderizam os dados.
4.2.4.1 Fluxo do template
A Figura 19 apresenta um fluxo com alguns sub-fluxos do Processo de Implan-

tação, que define a metologia de utilização de um template lançando mão do Node-RED.
A ideia é mostrar como são criados os fluxos para consumir os serviços de dados.
Figura 19 – Fluxo para o Template 1
Cada sub-fluxo representa uma saída no template. Cada saída é demarcada por um
par de nós (nó de dados e nó de renderização) que origina um card de saída, conforme a
Figura 17. Como é possível perceber, praticamente todos os nós de saída (identificados
pela cor verde) são antecedidos de um nó que tem a função de ser a conexão com os
dados, ou seja, são responsáveis por fornecer um meio de comunicação com a fonte de
dados e tratá-los para que o nó de saída possa realizar a renderização.
CF01: fluxo sobre dados do clima e representar a saída na interface no card específico.
Ele utiliza dois nós: o primeiro é o nó de clima, que é fornecido por terceiros. Sua
função é abstrair a complexidade de criar um algoritmo específico para coletar
dados de clima. Ele se conecta com o site Open Weather Map e realiza a consulta
sobre as informações do clima da cidade, de acordo com a configuração realizada.
O segundo nó é responsável por renderizar a saída em HTML com os dados do
tempo. Basicamente ele organiza os dados vindos do nó de clima e ajusta no código
HTML;
CF02: fluxo sobre bicicletas de aluguel da cidade do Recife. O primeiro nó acessa a API
de dados das bicicletas. O segundo nó recebe os dados do primeiro e organiza a
saída de dados para visualização em HTML;
CF03: fluxo da qualidade do ar. Responsável por mostrar dados sobre a qualidade do ar.
Utiliza dois nós. O primeiro faz a consulta a API de dados, utilizando um nó que
recupera dados de uma URL. O segundo recebe os dados e representa em código
HTML;
CF04: fluxo para mostrar dados sobre as linhas de ônibus. Utiliza dois nós, com o
primeiro sendo responsável por recuperar informações por requisição em uma URL,
na API de dados. O segundo nó é responsável pelo card de visualização, que retorna
uma listagem de linhas de ônibus;
CP01: fluxo para projetar o card de tráfego. Ele não precisa de um nó auxiliar para
consulta de dados pelo fato de apenas rendizar um código gerado pela fonte de
dados;
CD01: fluxo com a função de consultar a API de dados sobre eventos na cidade e
lidar com a saída no card CD02. Utiliza dois nós: o primeiro recupera os dados
disponíveis numa determinada URL (API de dados). O segundo é o nó responsável
por gerar o card em HTML, que organiza os dados de saída de interface;
CD02 : fluxo para consulta API com imagens de câmeras de trânsito. Ele é responsável
por consultar a API de dados sobre imagens de tráfego e recuperá-las para serem
visualizadas na saída do card, onde o segundo nó será o responsável por essa
renderização;
Dashboard Natal: esse nó é responsável por configurar o layout de saída. Ou seja, nas
suas configurações é possível escolher dentre algumas possibilidades de visualiza-
ção de layouts diferentes. Esse nó recebe os dados gerados pelos nós anteriores e
configura para ser renderizado no padrão de interface do dashboard;
response: Por fim, o último nó trata de uma resposta (HTTP response). Seu objetivo
é fornecer uma resposta à solicitação gerada pelo nó inicial de entrada (HTTP
request).
Para ilustrar a saída desse fluxo a Figura 20 exibe o resultado na interface web.
Figura 20 – Protótipo após da implementação do template e integração do fluxo no Node-RED
O fluxo CF01, CF02, CF03, CF04, CP01 e CD01, CD02 são responsáveis pelas
saídas nos cards CF01, CF02, CF03, CF04, CP01, CD01 e CD02, respectivamente.
Como resultado deste trabalho, foi criado alguns nós para contribuir com a
comunidade de desenvolvedores Node-RED. O resultado disso é a criação dos nós do
SmartNode Dashboard, com a função de lidar com a formatação de saída dos elementos
de interface. O seu código está disponível no repositório criado para este fim, no GitHub.
Assim é possível que outros desenvolvedores consigam ampliar o alcance deste projeto e
contribua em novas demandas, solucionando outros problemas.
53
5 VALIDAÇÃO DE USO
Este capítulo apresenta a validação sobre o uso do SmartNode Dashboard, bem

como a abordagem utilizada e os resultados obtidos. Ele se organiza da seguinte forma:
(i) abordagem; (ii) caracterização dos participantes; (iii) resultados e (iv) discussão.
Conforme a problemática apresentada por essa pesquisa, a falta de padrões (mé-
todos, códigos e interfaces) e projetos que auxiliem desenvolvedores voltados a produção
de city dashboards torna o processo mais complexo e dispendioso. O objetivo deste
trabalho é apresentar uma proposta que possa ajudar aos desenvolvedores de dashboards
na melhoraria de seus processos, além de ganhos na produtividade, lançando mão das
tecnologias atuais. Diante disso, foi proposto, no Capítulo 4, o SmartNode Dashboard
com sua metodologia de utilização junto ao Node-RED. Essas ferramentas são capazes
de facilitar o processo de desenvolvimento, possibilitando tanto o reaproveitamento
de código e estruturas pré-formatadas, como a possibilidade de estender as ferramen-
tas disponibilizadas através de especialização de códigos abertos, fornecidos por este
trabalho.
Outrossim, esse estudo propõe a validação da proposta apresentada no capítulo
anterior. Esta validação foi realizada por meio de uma avaliação qualitativa. Onde
avaliou-se a experiência de uso da proposta trazida por esse trabalho.
5.1 Abordagem
Para realizar essa validação foram utilizados os métodos de questionários e
observação. No Apêndice 1, Apêndice 2 e Apêndice 3, são mostrados, respectivamente, o
Termo de Livre Consentimento Esclarecido, o Roteiro de Avaliação e as Tarefas solicitadas
aos participantes. Esses instrumentos de pesquisa foram utilizados para conduzir a
avaliação junto aos participantes. Além desses documentos, foi utilizado um software de
captura de tela, para registrar os participantes realizando as tarefas solicitadas, assim
como um aplicativo instalado num smartphone para gravação de áudio, que serviu para
registrar as respostas dos questionários estruturados: um questionário que antecedia o
teste e outro que foi feito após a realização das tarefas.
Após a realização dos estudos deste projeto, verificou-se que as ferramentas exis-
tentes não atendem completamente aos problemas aqui apontados. Assim, as conclusões
sobre o que se tem disponível na comunidade de software atualmente, é ainda insufici-
ente para garantir que os desenvolvedores possam melhorar seus projetos, num modelo
Capítulo 5. VALIDAÇÃO DE USO 54
simplificado e que garanta maior automação na confecção de novos artefatos. Essa con-
clusão se delineou durante o percurso de estudos sobre as ferramentas e projetos voltados
aos dashboards. Isso acontece pelo fato de que é comum as equipes desenvolvedoras
criarem seus próprios projetos, baseando-se no seu contexto e assim não compartilham
seus códigos e métodos com a comunidade, ao ponto que os programadores possam
utilizar a base feita anteriormente para ampliar na construção de novos softwares.
Essa avaliação procurou analisar se a proposta apresentada no capítulo 4 atende
o objetivo deste trabalho. Ou seja, verificar se o SmartNode Dashboard e sua metodologia
que utiliza o Node-RED como plataforma de desenvolvimento é eficaz na busca por
melhoria no processo de criação de dashboards.
5.1.1 Experimentos executados
A realização desse estudo foi composta de atividades com intuito de avaliar o

nível de dificuldade que os participantes tiveram para construir um dashboard utilizando
a abordagem proposta. Dessa forma, a avaliação se dividiu em : (i) treinamento e (ii)
execução das tarefas.
• No treinamento, os participantes do experimento receberam instruções sobre a

ferramenta de fluxo e como ela funciona. Esse ponto é particularmente importante
pelo fato de que os participantes deveriam se nivelar ao ponto de construir um pro-
jeto sem necessidade de recorrer a outros materiais. Esse passo não era obrigatório,
e por isso os participantes poderiam dispensar se se sentissem confortáveis com o
Node-red;
• Na execução das tarefas foi solicitado a criação de alguns tipos de dashboards

diferentes utilizando o SmartNode Dashboard dentro do Node-RED.
5.1.2 Critérios avaliados
Alguns critérios foram tomados como base relevante de comparação para validar
esse estudo, afim de que sua aferição possa legitimar os objetivos desta pesquisa.
Eficiência: este critério foi utilizado para mensurar a duração em que cada participante
levou para concluir as atividades propostas. Ou seja, ele procura avaliar o esforço
empregado para realizar o trabalho;
Eficácia: esse critério procura mensurar se a execução das tarefas propostas foram
concluídas, sem que os participantes tenham deixado de realizar nenhuma das
tarefas propostas. Quanto maior a quantidade de tarefas realizadas, mais eficaz foi
ele em realizar a tarefa;
A abordagem empregada nessa avaliação teve o intuito de avaliar a experiência

de usuário, onde o participante técnico da área de computação, com experiência em
desenvolvimento, teria em utilizar a metologia proposta por esse trabalho.
5.1.3 Metodologia utilizada
Para realizar essa avaliação foi necessário subdividi-la em quatro etapas: (i) Ori-
entação sobre Node-RED, onde os participantes eram instruídos de suas funcionalidades;
(ii)Preparação do Ambiente de Testes, criação de um ambiente simples para realizar os
experimentos com os nós a serem utilizados; (iii) Processo de Avaliação, descrevendo
como foram realizadas as avaliações; e (iv) Resultados do estudo na seção 5.3.
5.1.3.1 Orientação sobre Node-RED
Antes de iniciar cada avaliação, foi necessário apresentar a plataforma que seria
utilizada, o Node-RED. Essa etapa não era obrigatória, mas teve o intuito de instruir os
participantes sobre o funcionamento da plataforma. Cada avaliado poderia, a qualquer
tempo, pular esse estágio caso julgasse necessário. Isso pelo fato de quê, para aqueles
que já tinham alguma experiência com o Node-RED, poderia acreditar que não seria
necessário essa explanação.
5.1.3.2 Preparação do Ambiente de Testes
Para oferecer um ambiente próximo do real, onde o programador poderá utilizar o

SmartNode Dashboard e sua metodologia, foram disponibilizado nós com funcionalidades
de painéis para cidades inteligentes. Dessa forma, os participantes teriam os nós já
instalados no ambiente.
Como tarefas, foi definido que seria necessário criar e configurar dois dashboards
utilizando os nós do framework disponíveis. As saídas desses painéis seriam distintas,
para verificar se o participante conseguiria entender a dinâmica da plataforma e as
funcionalidades que o framework oferece.
5.1.3.3 Processo de Avaliação
A avaliação foi planejada e dividida nas seguintes fases encadeadas:

Apresentação do framework: apresentação do trabalho e da ferramenta de fluxo a ser

utilizada. Essa apresentação teve o intuito de introduzir ao participante o que é o
trabalho que está sendo feito, bem como as suas funcionalidades e possibilidades.
Após uma breve explanação, o participante já deveria ser capaz de entender a
função da plataforma, assim como os objetivos do SmartNode Dashboard;
Termo de Livre Consentimento de Esclarecido: esse um documento discorre sobre as

intenções da pesquisa, esclarecendo as metas e atribuições. Além do mais, ele
esclarece como os dados coletados serão utilizados pelos pesquisadores, resguar-
dando os pesquisadores e entrevistados. O participante da avaliação deve assinar
o documento antes de iniciar os testes. Nele, é possível ter todas as informações
relevantes sobre a aplicação dos testes, além de informar que é possível desistir a
qualquer tempo;
Questionário pré-teste: esse questionário teve o objetivo de realizar levantamento

sobre o perfil dos participantes. Assim era possível identificar se eles estavam
próximo ao perfil esperado para realizar o ensaio.
Realização de tarefas: As tarefas que executadas foram concebidas de acordo com o

objetivo desta validação, ou seja, verificar se a abordagem é capaz de melhorar
o processo de desenvolvimento. Duas tarefas de criação de dashboards foram
utilizadas, cada tarefa era compostas algumas sub-tarefas que exigiam que o
participante procurasse utilizar os nós mais afundo e assim entender melhor o
funcionamento. Durante a realização das tarefas era possível realizar consultas,
desde ao avaliador ou a materiais disponíveis na internet. Caso os participantes
julgassem que não conseguiriam concluir e quisessem desistir, era facultado sua
conclusão, mesmo podendo realizar consultas. Todos esses passos foram registrados
por meio de software de captura de tela para análise posterior.
Questionário pós-teste: esse questionário foi aplicado para avaliar a experiência do

participante com as tarefas utilizando a ferramenta e suas respectivas impressões. A
perguntas realizadas foram todas abertas, com a possibilidade de que o entrevistado
ficasse a vontade sobre explicar suas percepções e ampliar as interpretações. Esse
questionário foi aplicado tão logo as tarefas foram finalizadas.
5.2 Caracterização dos Participantes

O foco deste estudo é orientado pela perspectiva de oferecer uma abordagem que
fosse capaz de diminuir o trabalho das equipes de desenvolvimento de dashboards. Dessa
forma, a escolha dos participantes para essa validação foi baseada na ideia de que eles
deveriam ser da área de computação, com alguma experiência em programação e que

tivessem pouco ou algum conhecimento sobre tecnologias web. Dito isto, a escolha dos
participantes foi norteado por esse direcionamento.
Os participantes da validação, em sua totalidade, tinham experiência com desen-
volvimento de software e familiaridade com tecnologias web. Isso é um fator importante,
considerando que os conceitos e experiências anteriores possibilitam que os desenvolve-
dores possam se adequar com maior facilidade. Dentre eles, mais de 80% responderam
que tiveram alguma experiência com alguma ferramenta de programação por fluxos. A
Tabela 4 apresenta o perfil completo dos participantes da pesquisa, com os pontos chaves
mais relevantes para este contexto de estudo. Vale ressaltar que o estudo foi realizado
com cinco participantes.
Tabela 4 – Perfil dos participantes da validação de uso
Ponto chave Resposta
Experiência na área de computação Entre 6 e 30 anos
Conhecimento em ferramentas de 80% responderam que sim.
programação por fluxos
Experiência com tecnologias web 100% dos participantes.
(HTML, CSS e Javascript)
Dificuldades com tecnologias Web Os participantes não têm problemas
com essas tecnologias. Ou seja, pro-
blemas que possam impedir de de-
senvolver ou que dificulte a utiliza-
ção das mesmas.
5.3 Resultados
Com a realização desta avaliação foi possível obter informações contundentes
sobre as perspectivas que nortearam este trabalho. Elas mostraram que as proposições
iniciais foram ratificadas, dessa forma justificando o desenvolvimento da pesquisa. Os
dados recolhidos foram analisados em dois formatos: (i) transcrição dos questionários e
sua posterior análise; e (ii) análise dos vídeos com as tarefas. Essa operação proporcionou
uma base de informações capaz de direcionar as conclusões sobre a avaliação.
Com a finalização dos testes, foi possível realizar análises nos vídeos das tarefas e
mensurar os critérios avaliativos, citados anteriormente (eficiência e eficácia).
5.3.1 Critério de Eficiência
No critério de tempo, os resultados de todos os participantes foram analisados,

avaliando quanto a duração dispendido por cada um levou para concluir a atividade.
Apesar de haverem duas tarefas, o tempo avaliado foi o quantitativo total gasto, pelo
fato de ambas as atividades oferecerem o mesmo nível de dificuldade.
Figura 21 – Gráfico com tempos em que os participantes executaram as tarefas.
A análise dos vídeos propiciou a percepção a cerca da experiência com a criação

de dashboards através da utilização das ferramentas desenvolvidas neste projeto. A Figura
21 apresenta a duração que os testes levaram por cada participante, para ser concluído.
Os Participantes 1 e 5, respectivamente, foram identificados como os mais experientes,
pelos relatos apresentados nos questionários. Apesar disso, não apresentaram os menores
tempos da avaliação, com exceção do Participante 1. O Participante 2, já havia utilizado
uma ferramenta de criação por fluxo, por conta disso também, a duração do seu teste
ficou entre os menores apresentados. Os Participantes 3 e 4 responderam não ter tido
experiência anterior com ferramentas de programação por fluxos. Apesar desse fato, o
Participante 4 obteve o terceiro menor tempo de execução. Já o Participante 3, levou um
prazo de execução consideravelmente maior que os demais. Este necessitou tirar dúvidas
com o entrevistador, que prontamente auxiliou com dúvida oriundas da estrutura do
Node-RED. A duração do seu teste levou aproximadamente 50% a mais que a média de
todos os tempos.
É importante destacar que alguns participantes não quiseram receber instrução
sobre o Node-RED. Os entrevistados que já tiveram alguma experiência anterior com
outras ferramentas, três dos cinco avaliados, dispensaram essa etapa. Vale destacar que
dentre eles, o Participante 5 teve dificuldade para conseguir completar e demorou mais
do que a média dos outros avaliados do grupo dos experientes. A Tabela 5 mostra os
relatos a cerca do experimento realizado, onde é possível ter uma maior amplitude das
opiniões dos avaliados.
5.3.2 Critério de Eficácia
Para este critério, foi analisado o quanto das atividades propostas os avaliados
conseguiram concluir, de forma adequada (funcional). Dos cinco entrevistados apenas
40% não conseguiram concluir todas as tarefas. Particularmente, o Participante 5 pulou
uma tarefa, por alegar que não estava entendendo o que a tarefa queria dizer.
Figura 22 – Gráfico com o percentual de completude que os participantes executaram as tarefas.
Para ilustrar os resultados de completude das tarefas, a Figura 22 mostra como

os participantes se saíram nas atividades realizadas. A taxa de falha significa dizer que
os avaliados não conseguiram concluir ou precisaram lançar mão de ajuda do avaliador,
para finalizar suas tarefas.
5.4 Discussão
De uma maneira geral, os participantes concordaram que a metodologia proposta
reduziu drasticamente a perspectiva de trabalho a ser despendida. O Node-RED oferece
recursos que maximizam a realização das tarefas, possibilita a reutilização e o comparti-
lhamento de código. O SmartNode Dashboard utilizou essa perspectiva da plataforma
para estender sua capacidade e criar uma estrutura de código capaz de ser melhorada
por equipes de softwares que trabalham nessa frente de desenvolvimento.
Após a conclusão das tarefas, os participantes foram questionados sobre sua
experiência com a utilização do SmartNode Dashboard na plataforma Node-RED. Esse
questionário foi utilizado para avaliar a experiência sobre a contribuição da proposta na
criação de dashboards. Ao todo foram três perguntas abertas, com três sub-perguntas mais
detalhadas sobre as respostas das questões 2, 3 e 4, além de duas questões reflexivas.
A Questão 1 solicitou um relato sobre a experiência com o uso da metodologia.
Essas respostas estão disponíveis na Tabela 5.
Tabela 5 – Respostas da Questão 1 do questionário pós-teste.

Participante Resposta
P1 Inicialmente eu comecei usando só o Node-RED e alguns funções que já havia visto.
Tive dificuldades porque não tinha prática em si. Mas quando as tarefas foram de-
senvolvendo, para dashboard e imprimir, mostrar a previsão do tempo e o Node-RED
dashboard facilitou muito, porque trazia tudo pronto. Só precisou configurar o token,
que precisou e informar a cidade. Ajudou muito mesmo. Não precisa criar nó e nem
entender de fluxo.
P2 Eu achei a metodologia muito "massa"(SIC), onde você só vai ligando os pontos. Então,
termina sendo tanto didático quanto simples, porque facilita bastante o trabalho. Se
eu precisasse fazer um dashboard na mão, teria aí uma série de coisas envolvidas e
aqui eu só precisei, basicamente, fazer a ligação entre o endpoint que me dá essas
informações e os cards do próprio framework. Acredito que vai ser bem interessante.
Se for usado mesmo para criação de dashboards em cidades inteligentes poderia ter
até outras coisas que automatizasse isso. Do jeito que tá hoje já está bem simples.
P3 Não ficou claro que isso era uma metodologia. Fiquei em dúvida com alguns conceitos,
pois os conceitos por trás não ficaram claros. Os próprios conceitos que estão por trás
do Node-RED que trouxe dificuldade.
P4 A ferramenta se mostrou muito intuitiva. Basta ter uma noção básica. Ela tem muita
praticidade. Achei uma ferramenta muito simples, porque basta clicar, arrastar e
conectar os nós.
P5 Eu inicialmente tive um pouco de dificuldade pela questão de um ano, mais ou menos,
sem ter mexido no Node-RED. Então, após concluir as etapas, as tarefas, concluí o
quão ficou fácil montar um dashboard, rapidamente. A partir de rápidas configurações
já é possível trazer informações que são relevantes e úteis ao ambiente que está se
propondo. Então, nesse aspecto, a abordagem proposta foi bem satisfatória, nesse
quesito.
A intenção com esse relato é identificar a percepção da contribuição ou se ao

invés disso há negatividade a cerca da experiência. Os relatos denotam, que apesar
de ser uma vivência nova, os avaliados perceberam a vantagem que essa ferramenta
ofereceu. O tempo de realização das tarefas, com o maior intervalo não ultrapassando os
40 minutos, demonstra que ao realizar a criação e publicação de um dashboard pode ser
muito simples, contrariando a perspectiva de outros projetos com essa mesma temática.
A Questão 6 solicita ao entrevistado que compare essa experiência com outras
anteriores, com o mesmo problema de construção de interfaces de painéis. O propósito
dessa questão é realizar um paralelo entre a experiência aqui posta, com outras já
vivenciadas em momentos anteriores, do ponto vista dos participantes. Essas respostas
estão disponíveis na Tabela 6.
Tabela 6 – Respostas da Questão 6 do questionário pós-teste.

Participante Resposta
P1 Não vi nenhuma outra ferramenta que tenha exemplo de metodologia
como esse, não. A mais próxima dessa metodologia foi o Wirecloud, mas
uma metodologia bem mais complexa.
P2 Apenas com experiência de fazer manual. Também o fiware que é mais
burocrático. Apesar de não ter usado na prática. Apenas vi o pessoal
usando.
P3 Não, para mim é uma experiência bastante nova. Lembro de algo similar
utilizando JavaBeans. Que utilizava classes em java que poderia plugar
os elementos com gets e sets
P4 Não tenho experiência com outras.
P5 Comparado com o que existe, achei mais bonito e a questão do layout res-
ponsivo, além do layout ser mais fácil e mais prático de ser configurado,
do que o dashboard fornecido pelo Node-RED.
Os participantes 1 e 2, que já tiveram experiências anteriores com outra ferra-

menta voltada a construção de dashboard, fizeram um comparativo e relataram que
utilizar a proposta deste trabalho agrega mais vantagens do que em práticas com outras
tecnologias.
Poucos foram os que relataram que já haviam realizado alguma tarefa com outros
projetos de linguagem baseada em fluxos, mas que ficaram satisfeitos com a experi-
ência. Isso evidencia que essa vivência se mostra proeminente para futuros trabalhos.
Tornando a ideia de produzir artefatos de softwares para dashboards mais fácil do que é
atualmente. Essa é uma proposta de melhorar os processos já existentes, introduzindo
novos panoramas e potencialmente incentivando a interação entre a comunidade de
desenvolvimento de software.
5.5 Conclusão
Depois de analisar os experimentos, coletar as respostas e avaliar as opiniões dos
participantes, posterior a realização das tarefas, foi possível concluir que a metodologia
utilizando o Node-RED agregado ao uso SmartNode Dashboard foi capaz de melhorar
o processo de desenvolvimento de dashboards, alcançando, desta forma, os objetivos
desta proposta. Com as respostas dos participantes da validação, que elencaram diversas
características positivas durante o processo, o objetivo principal deste trabalho se com-
pleta e abre oportunidade para novas demandas. Uma das perguntas questiona sobre
a percepção do ponto de vista de quem é avaliado, se há como implantar melhorias.
Suas indicações são incluídas na seção de trabalhos futuros, por se tratar, desde já, do
engajamento de melhorias em potencial.
62
6 CONSIDERAÇÕES FINAIS
A discussão em torno dos dados vem sendo tracionada pela evolução das cidades
inteligentes e no crescimento de suas massas de dados, que agora são geradas por
uma gama diversificada de fontes (governo, cidadãos, sensores instalados em cidades,
etc.). Apresentar novas soluções para essa problemática é um fator crucial na incessante
busca por oferecer cidades mais inteligentes. Utilizar isso, apresentando informações
que auxiliem, de maneira significativa, aos cidadãos, considerando seu contexto de uso e
necessidades mais relevantes, é uma premissa que deve estar presente na criação de novos
projetos. Este trabalho trouxe a união de tecnologias mais atuais para criar o SmartNode
Dashboard e alinhando-se a isso, desenvolver uma metodologia que apoie na criação de
novos artefatos digitais relevantes no contexto de dashboards. O SmartNode Dashboard
é um framework focado no desenvolvimento de painéis para diversificados tipos de
aplicações. Esse trabalho teve seu foco voltado ao contexto das cidades inteligentes,
contudo, sua aplicação não se restringe apenas a isso.
Além dessa nova tecnologia criada, o trabalho mostrou também, a utilização do
Node-RED. Uma ferramenta de programação por fluxos que possibilita a redução da
complexidade de desenvolvimento de novos projetos. Ela reduziu o ferramental que os
programadores necessitam para realizar o desenvolvimento de novos dashboards. Os
testes realizados mostraram o quanto que ele facilitou a criação dos serviços e interfaces,
além de potencializar o desenvolvimento de novos projetos a partir destes. Vale ressaltar
que o uso de tecnologias como essas, não só ajudam a melhorar em como se desenvolve
projetos de softwares, conferindo agilidade, flexibilidade e dinamismo, mas também
contribui na difusão e crescimento de novas tecnologias.
6.1 Principais contribuições

Entre as principais contribuições trazidas por essa pesquisa, é possível destacar
que o SmartNode Dashboard trás consigo não apenas um framework que auxilia no
desenvolvimento de novos artefatos digitais, mas uma perspectiva de evolução das
tecnologias e como elas estão presentes cada vez mais no dia a dia do desenvolvimento
de software. Este trabalho faz um aporte como suas principais contribuições sendo: (i)
o SmartNode Dashboard, (ii) a metodologia de utilização e integração do SmartNode
Dashboard ao Node-RED, e (iii) os nós rotulados como SmartNode Dashboard para
utilização e ampliação de elementos que servem para criar painéis de dados.
Capítulo 6. CONSIDERAÇÕES FINAIS 63
Apesar de ter constructos finitos, essa dissertação apresenta a riqueza que é

olhar para novas tecnologias, que surgem diariamente, e que podem auxiliar e ampliar
a capacidade que as equipes de desenvolvimento de software tem para solucionar
problemas.
6.2 Limitações
Após a validação, percebeu-se que os programadores antes de utilizar o SmartNode
Dashboard em conjunto com o Node-RED, necessitam antes se familiarizar com esta
última. Isso porque os conceitos que o Node-RED apresenta pode ser diferente dos que
os programadores estão acostumados, incorrendo em erro e um aumento na curva de
aprendizagem.
Por não se tratar do escopo dessa pesquisa, não foi tratado detalhes de design mais
aprofundados. Os elementos de interface criados são oriundos do Bootstrap Framework.
6.3 Trabalhos futuros

Com o desenvolvimento deste trabalho foi possível perceber que ele tem um
grande potencial de crescimento. Essa percepção se ratificou ao longo do desenvol-
vimento, na etapa de testes e na validação do uso. Dessa forma, é possível apontar
contribuições que podem ampliar, melhorar e tornar ainda maior a riqueza das contribui-
ções deste trabalho. Para tanto, é possível apontar os seguintes trabalhos futuros:
• Ampliar o número de nós do SmartNode Dashboard: esse é um trabalho impor-

tante, pois os programadores poderão contribuir com este projeto e oferecer novas
possibilidades de nós, baseando-se em suas demandas;
• Tornar a customização do nó de layout de saída mais simples de ser configurada,

podendo ser feita através da funcionalidade de arrastar e soltar;
• Criar a possibilidade de escolher temas para os dashboards: com a contribuição

de outros desenvolvedores, ou até mesmo designers, a criação de temas para os
dashboards poderia contribuir na diversificação do material disponível.
• Ampliar a capacidade dos nós criados e possibilitar que os usuários possam cus-
tomizar a interface de visualização dos seus dashboards, onde seja possível eles
escolherem ver apenas o que é de seu interesse.
64
Referências
ANAND, R. The 5 Most Popular Frontend Frameworks To Consider.

2017. Fev., 2018. Disponível em: <<https://medium.com/gridbox/
the-5-most-popular-frontend-frameworks-to-consider-4cc0bb8dff08>>. Acesso em
Abril 25, 2018. Citado na página 32.
ARSENAULT, C. Top 10 Front-End Frameworks of 2016. 2018. Fev., 2018. Disponível em:
<<https://www.keycdn.com/blog/front-end-frameworks/>>. Acesso em Abril 25,
2018. Citado 2 vezes nas páginas 32 e 33.
BARBOSA, S. D. J.; SILVA, B. S. d. Interação Humano-Computador. Rio de Janeiro:
Elsevier, 2010. Citado na página 30.
BARNS, S. Smart cities and urban data platforms: Designing interfaces for
smart governance. City, Culture and Society, v. 12, p. 5 – 12, 2018. ISSN 1877-
9166. Innovation and identity in next generation smart cities. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1877916617302047>. Citado 2
vezes nas páginas 21 e 23.
CAY, H. Padrões e Projeto Orientados a Objetos. Porto Alegre: Bookman, 2007. Citado 2
vezes nas páginas 31 e 32.
CYBIS, W.; BETIOL, A. H.; FAUST, R. ERGONOMIA E USABILIDADE: CONHECIMENTOS,
METODOS E APLICAÇOES. 3th. ed. São Paulo: Novatec, 2015. Citado 2 vezes nas
páginas 27 e 28.
DREY, R. F. Definição e princípios da Computação Ubíqua. 2015. Jan., 2015. Disponível em:
<https://www.tiespecialistas.com.br/definicao-e-principios-da-computacao-ubiqua/
/>. Acesso em 29-Agosto-2018. Citado na página 14.
FALCÃO, A. G. R.; BAPTISTA, C. d. S.; MENEZES, L. C. d. Crowd4city: Utilizando
sensores humanos como fonte de dados em cidades inteligentes. In: VIII Simpósio
Brasileiro de Sistemas de Informação. [S.l.: s.n.], 2012. p. 144–149. Citado na página 20.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de projeto: soluções
reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000. Citado na
página 27.
GERCHEV, I. The 5 Most Popular Front-end Frameworks Compa-
red. 2018. Fev., 2018. Disponível em: <<https://www.sitepoint.com/
most-popular-frontend-frameworks-compared/>>. Acesso em Abril 25, 2018.
Citado na página 32.
HARLEY, A. Don’t Prioritize Efficiency Over Expectations. 2015. Disponível em:
<https://www.nngroup.com/articles/efficiency-vs-expectations/>. Acesso em Abril 30,
2018. Citado na página 29.
HARLEY, A. Variations on Practiced Patterns Cause Mistakes. 2017. Disponível em:
<https://www.nngroup.com/articles/practiced-patterns-mistakes/>. Acesso em Abril
29, 2018. Citado na página 28.
Referências 65
KALBACH, J. Design de Navegação web. Porto Alegre: Bookman, 2009. Citado na página
33.
KIRAN, B. M.; MADHUSUDHAN, C.; FARHAN, M. M.; MANZOOR, M. B.; KARIYAPPA,

B. S. Testing and validation of uart using cloud based gui. In: 2017 2nd IEEE International
Conference on Recent Trends in Electronics, Information Communication Technology
(RTEICT). [S.l.: s.n.], 2017. p. 782–786. Citado na página 34.
KODALI, R. K.; MANDAL, S.; HAIDER, S. S. Flow based environmental monitoring

for smart cities. In: 2017 International Conference on Advances in Computing,
Communications and Informatics (ICACCI). [S.l.: s.n.], 2017. p. 455–460. Citado na
página 34.
KOURTIT, K.; NIJKAMP, P. Big data dashboards as smart decision support tools for
i-cities–an experiment on stockholm. Land Use Policy, Elsevier, v. 71, p. 24–35, 2018.
Citado na página 22.
LEEM, C.; KIM, B. P. Taxonomy of ubiquitous computing service for city development.
Personal and Ubiquitous Computing, v. 17, p. 1475 – 1483, 2013. ISSN 1877-0509.
Disponível em: <https://link.springer.com/article/10.1007/s00779-012-0583-5>.
Citado 2 vezes nas páginas 20 e 21.
LEITE, A. F. Conheça os Padrões de Projeto. 2005. Fev., 2005. Disponível em:

<https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957>. Acesso em
Agosto 04, 2018. Citado na página 27.
LOPES, I. M.; OLIVEIRA, P. Can a small city be considered a smart city?

Procedia Computer Science, v. 121, p. 617 – 624, 2017. ISSN 1877-0509.
CENTERIS 2017 - International Conference on ENTERprise Information Systems
/ ProjMAN 2017 - International Conference on Project MANagement / HCist
2017 - International Conference on Health and Social Care Information
Systems and Technologies, CENTERIS/ProjMAN/HCist 2017. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1877050917322810>. Citado na
página 13.
MACKE, J.; CASAGRANDE, R. M.; SARATE, J. A. R.; SILVA, K. A. Smart city

and quality of life: Citizens’ perception in a brazilian case study. Journal of
Cleaner Production, v. 182, p. 717 – 726, 2018. ISSN 0959-6526. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0959652618303846>. Citado 3
vezes nas páginas 13, 14 e 20.
MONTEIRO, O. L. D. "Aplicação de Padrões de Projeto no Desenvolvimento de Frameworks:

Um estudo de caso. Dissertação (Mestrado) — "Universidade Federal de Santa Catarina",
"ago"2002. Citado na página 31.
NIELSEN, J. 10 Usability Heuristics for User Interface Design. 1995. Disponível em:
<https://www.nngroup.com/articles/ten-usability-heuristics/>. Acesso em Abril 30,
2018. Citado na página 29.
NIELSEN, J. Do Interface Standards Stifle Design Creativity? 1999. Disponível em:

<https://www.nngroup.com/articles/do-interface-standards-stifle-design-creativity/>.
Acesso em Abril 30, 2018. Citado na página 29.
Referências 66
NIELSEN, J. The Need for Web Design Standards. 2004. Disponível em: <https:
//www.nngroup.com/articles/the-need-for-web-design-standards/>. Acesso em Abril
30, 2018. Citado na página 29.
OTTO, M. Building Twitter Bootstrap. 2012. Jan., 2012. Disponível em: <https:
//alistapart.com/article/building-twitter-bootstrap>. Acesso em 01-Maio-2018. Citado
na página 32.
RIZZON, F.; BERTELLI, J.; MATTE, J.; GRAEBIN, R.; MACKE, J. Smart city: Um conceito
em construÇÃo. In: Revista Metropolitana de Sustentabilidade. [S.l.: s.n.], 2017. v. 7(3),
n. 3, p. 144–149. ISSN 23183233. Citado na página 20.
SILVA, M. S. Bootstrap 3.3.5: Aprenda a usar o framework Bootstrap para criar layouts
CSS complexos e responsivos. São Paulo: Novatec, 2015. Citado 3 vezes nas páginas 32,
33 e 40.
SUAKANTO, S.; SUPANGKAT, S. H.; SARAGIH, R. et al. Smart city dashboard for
integrating various data of sensor networks. In: IEEE. ICT for Smart Society (ICISS), 2013
International Conference on. [S.l.], 2013. p. 1–5. Citado 2 vezes nas páginas 21 e 22.
WEISS, M. C.; BERNARDES, R. C.; CONSONI, F. L. Cidades inteligentes como nova

prática para o gerenciamento dos serviços e infraestruturas urbanos: a experiência
da cidade de porto alegre. In: PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ,
PROGRAMA DE PÓS-GRADUAçãO EM GESTÃO URBANA. Urbe : Revista Brasileira de
Gestão Urbana. [S.l.], 2015. p. 310–324. Citado 2 vezes nas páginas 13 e 20.
ZANETTE, F. Por que trabalhar com templates facilita (muito) o trabalho de

Marketing. 2014. Dez., 2014. Disponível em: <https://resultadosdigitais.com.br/blog/
por-que-trabalhar-com-templates-facilita-muito-o-trabalho-de-marketing/>. Acesso em
01-Maio-2018. Citado na página 33.
Apêndices
68
APÊNDICE A – Termo de Livre

Consentimento Esclarecido
69
APÊNDICE B – Roteiro de Avaliação

70
APÊNDICE C – Tarefas

SmartNodeDashboard Dias 2019

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SmartNodeDashboard Dias 2019

Enviado por

Direitos autorais:

Formatos disponíveis

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE

I NSTITUTO M ETRÓPOLE D IGITAL

SmartNode Dashboard: um framework

Cesimar Xavier de Souza Dias

SmartNode Dashboard: um framework front-end baseado em

Dissertação de Mestrado apresentada ao Pro-

Universidade Federal do Rio Grande do Norte – UFRN

Orientador: Prof. Dr. Frederico Araújo da Silva Lopes

Dias, Cesimar Xavier de Souza.

Dissertação (mestrado) - Universidade Federal do Rio Grande

1. SmartNode Dashboard - Dissertação. 2. Cidades inteligentes

RN/UF/BCZM CDU 004.738.5

Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262

SmartNode Dashboard: um framework front-end baseado em

Dissertação de Mestrado apresentada ao Pro-

Trabalho aprovado. Natal/RN, 28 de janeiro de 2019:

Prof. Dr. Frederico Araújo da Silva Lopes

Prof. Dr. Jair Cavalcante Leite

Prof. Dr. Gustavo Girão Barreto da Silva

Prof. Dr. André Gustavo Duarte de

Primeiramente agradeço a Deus por ter me dado a capacidade da ciência, o que

Palavras-chave: SmartNode Dashboard. cidades inteligentes. dashboards. padrões de

Keywords: SmartNode Dashboard, smart cities, dashboards, web interface patterns,

Figura 1 – Dashboard com resumo de informações . . . . . . . . . . . . . . . . . 22

Tabela 1 – Lista com os principais frameworks front-end do mercado . . . . . . . 33

API Application Programming Interface (Interface de Programação de Apli-

CSS Cascading Style Sheets (Folha de Estilo em Cascata)

HTML HyperText Markup Language (Linguagem de Marcação de Hipertexto)

HTTP Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)

IHC Interação Humano-Computador

JSON JavaScript Object Notation (Notação de Objetos JavaScript)

NPM Node Package Manager (Gerenciador de Pacotes do Node)

SDK Software Development Kit (Conjunto de Desenvolvimento de Software)

TIC Tecnologia da Informação e Comunicação

URL Uniform Resource Locator (Localizador Padrão de Recursos)

UX User Experience (Experiência de Usuário)

APÊNDICE A – TERMO DE LIVRE CONSENTIMENTO ESCLARECIDO 68

APÊNDICE B – ROTEIRO DE AVALIAÇÃO . . . . . . . . . . . . . . . . 69

ainda em forma de protótipo, englobando um número reduzido de serviços, demonstra

1.2.1 Objetivos Específicos

Os objetivos específicos deste projeto são:

• Desenvolver templates de dashboards para cidades inteligentes utilizando Node-RED

• Aplicar o framework SmartNode Dashboard em um estudo de caso para mostrar a

• Avaliar com desenvolvedores a utilização do framework.

Para realizar o desenvolvimento desta proposta de trabalho, foi necessário realizar

Desenvolvimento de templates: para realização dessa etapa foi necessário o desenvol-

• Planejamento e programação do framework com programação front-end a

• Criação do padrão de interface: planejamento e programação do padrão

Aplicação do framework proposto: foi criado um dashboard utilizando serviços de

• Criação de um conjunto de nós para utilizar dados através de um fluxo. Foi

Avaliação da utilização do framework: com o intuito de validar a proposta junto aos

cultura da comunidade de software. É de suma importância estar atento ao surgimento

1.4 Organização do Trabalho

2.1 Smart City

• Digital City: refere-se a uma comunidade conectada que combina infra-estrutura de

• Smart City: se destaca pelo uso de tecnologias de computação inteligente para

O conceito de smart city é geralmente integrado ao uso de Tecnologia de Informa-

Figura 1 – Dashboard com resumo de informações

Kourtit e Nijkamp (2018) esclarece que, na literatura sobre arquitetura de dashbo-

2.2.1 Tipos de Dashboards

Existem 3 tipos mais comuns de dashboards, cada um desenvolvido com um

Dashboards operacionais : exibem informações que facilitam as operações do dia a dia

Dashboards estratégicos e executivos : exibe KPIs (Key Performance Indicators) impor-