SmartNode Dashboard: um framework front-end baseado em … · 2019-05-26 · SmartNode Dashboard: um framework front-end baseado em Node-RED para criação de City Dashboards / Cesimar

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

INSTITUTO METRÓPOLE DIGITAL

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE

SOFTWARE

MESTRADO PROFISSIONAL EM ENGENHARIA DE SOFTWARE

SmartNode Dashboard: um frameworkfront-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 deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa 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

Dias, Cesimar Xavier de Souza. SmartNode Dashboard: um framework front-end baseado em Node-RED para criação de City Dashboards / Cesimar Xavier de SouzaDias. - 2019. 70 f.: il.

Dissertação (mestrado) - Universidade Federal do Rio Grandedo Norte, Instituto Metrópole Digital, Programa de Pós-Graduaçãoem 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 deinterface 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

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

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


SmartNode Dashboard: um framework front-end baseado emNode-RED para criação de Smart City Dashboards

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa 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 LopesOrientador

Prof. Dr. Jair Cavalcante LeiteCoorientador

Prof. Dr. Gustavo Girão Barreto da SilvaExaminador Interno

Prof. Dr. André Gustavo Duarte deAlmeida

Examinador Externo

Natal/RN2019

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 SmartNodeDashboard, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.1 Tipos de Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 Projetos de Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 Padrões de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Padrões de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2.1 Consistência de Padrões . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.2.2 Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 BASE TECNOLÓGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.0.1 Frameworks Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Templates de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1 Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.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 . . . . . . . . . . . . . . . . . . . . 404.1.1 Customização do Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 404.1.2 Arquitetura de Código CSS . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Metodologia de utilização . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.1 Template de Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 Processo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 474.2.3 Processo de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.4 Integração ao Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.4.1 Fluxo do template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 VALIDAÇÃO DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.1 Experimentos executados . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.2 Critérios avaliados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.3 Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.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 . . . . . . . . . . . . . . . . . . . . . . 565.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3.1 Critério de Eficiência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3.2 Critério de Eficácia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 626.1 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.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 CityService 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. Tratado1 É 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 dashboardsde 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-RED2 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 a3 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çõesFonte: 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 dashboardnã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 UnidoFonte: 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 SydneyFonte: 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 backgroundde 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 redor6 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 estruturadaspara 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 queas 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 paraum problema e utilizá-lo em uma nova situação, mas o aproveitamento de soluções deprojetos 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 ofthe 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 interfaceFonte: 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 podemos8 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-trelas no Github)

Versão Ano

Bootstrap Mark Otto e JacobThornton

125.353 4.0 2011

Foundation Zurb 27.383 6.0 2011Pure CSS Yahoo 18.710 1.0.0 2013

Semantic UI Jack Lukic 41.651 2.2 2013UI 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 linhade 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ó.Fonte: Adaptado do site oficial do Node-RED

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ó.Fonte: Adaptado do site oficial do Node-RED

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 Dashboardconsiste 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çãoLicença MIT

Conceitos Webdesign Responsivo e MobileFirst

Pré-processador SassResponsivo Sim

Modular SimDocumentaçã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 de10 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 depadronizar 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 frameworkatua 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 dashboardsforam 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 templateutilizando 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

ClimaInformações sobre clima: temperatura atual, velocidade dovento e umidade do ar.

BicicletasInformações sobre bicicletas de aluguel, e as estações sãomostradas aleatoriamente: nome da estação, slots de devolu-ção disponíveis, bicicletas disponíveis.

Qualidade do ArInformações sobre qualidade do ar: status da qualidade doar, nível de poluição, níveis de: CO2, NO2, SO2, O3.

Linhas de ÔnibusInformações sobre ônibus urbanos que circurlam nas proxi-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.

Câmeras de TráfegoExibe as imagens das câmeras de trânsito disponíveis nacidade, 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 templateengine (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 (HTTPrequest).

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 dashboardsna 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 Dashboardcom 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 dashboardsdiferentes 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 dashboardsutilizando 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 RespostaExperiência na área de computação Entre 6 e 30 anosConhecimento em ferramentas deprogramação por fluxos

80% responderam que sim.

Experiência com tecnologias web(HTML, CSS e Javascript)

100% dos participantes.

Dificuldades com tecnologias Web Os participantes não têm problemascom 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 RespostaP1 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-REDdashboard 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 nementender 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. Seeu precisasse fazer um dashboard na mão, teria aí uma série de coisas envolvidas eaqui eu só precisei, basicamente, fazer a ligação entre o endpoint que me dá essasinformaçõ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 teraté 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ásdo Node-RED que trouxe dificuldade.

P4 A ferramenta se mostrou muito intuitiva. Basta ter uma noção básica. Ela tem muitapraticidade. Achei uma ferramenta muito simples, porque basta clicar, arrastar econectar 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í oquão ficou fácil montar um dashboard, rapidamente. A partir de rápidas configuraçõesjá é possível trazer informações que são relevantes e úteis ao ambiente que está sepropondo. Então, nesse aspecto, a abordagem proposta foi bem satisfatória, nessequesito.

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 RespostaP1 Não vi nenhuma outra ferramenta que tenha exemplo de metodologia

como esse, não. A mais próxima dessa metodologia foi o Wirecloud, masuma metodologia bem mais complexa.

P2 Apenas com experiência de fazer manual. Também o fiware que é maisburocrático. Apesar de não ter usado na prática. Apenas vi o pessoalusando.

P3 Não, para mim é uma experiência bastante nova. Lembro de algo similarutilizando JavaBeans. Que utilizava classes em java que poderia plugaros 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 SmartNodeDashboard 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 SmartNodeDashboard 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 SmartNodeDashboard 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 emAbril 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 forsmart 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 2vezes nas páginas 21 e 23.

CAY, H. Padrões e Projeto Orientados a Objetos. Porto Alegre: Bookman, 2007. Citado 2vezes 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 naspá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: Utilizandosensores humanos como fonte de dados em cidades inteligentes. In: VIII SimpósioBrasileiro 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çõesreutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000. Citado napá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 Abril29, 2018. Citado na página 28.

https://medium.com/gridbox/the-5-most-popular-frontend-frameworks-to-consider-4cc0bb8dff08

https://medium.com/gridbox/the-5-most-popular-frontend-frameworks-to-consider-4cc0bb8dff08

https://www.keycdn.com/blog/front-end-frameworks/

http://www.sciencedirect.com/science/article/pii/S1877916617302047

https://www.tiespecialistas.com.br/definicao-e-principios-da-computacao-ubiqua//

https://www.tiespecialistas.com.br/definicao-e-principios-da-computacao-ubiqua//

https://www.sitepoint.com/most-popular-frontend-frameworks-compared/

https://www.sitepoint.com/most-popular-frontend-frameworks-compared/

https://www.nngroup.com/articles/efficiency-vs-expectations/

https://www.nngroup.com/articles/practiced-patterns-mistakes/

Referências 65

KALBACH, J. Design de Navegação web. Porto Alegre: Bookman, 2009. Citado na página33.

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 InternationalConference 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 monitoringfor smart cities. In: 2017 International Conference on Advances in Computing,Communications and Informatics (ICACCI). [S.l.: s.n.], 2017. p. 455–460. Citado napágina 34.

KOURTIT, K.; NIJKAMP, P. Big data dashboards as smart decision support tools fori-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 emAgosto 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 / HCist2017 - International Conference on Health and Social Care InformationSystems and Technologies, CENTERIS/ProjMAN/HCist 2017. Disponível em:<http://www.sciencedirect.com/science/article/pii/S1877050917322810>. Citado napágina 13.

MACKE, J.; CASAGRANDE, R. M.; SARATE, J. A. R.; SILVA, K. A. Smart cityand quality of life: Citizens’ perception in a brazilian case study. Journal ofCleaner Production, v. 182, p. 717 – 726, 2018. ISSN 0959-6526. Disponível em:<http://www.sciencedirect.com/science/article/pii/S0959652618303846>. Citado 3vezes 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.

https://link.springer.com/article/10.1007/s00779-012-0583-5

https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957



https://www.nngroup.com/articles/ten-usability-heuristics/

https://www.nngroup.com/articles/do-interface-standards-stifle-design-creativity/

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 Abril30, 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. Citadona página 32.

RIZZON, F.; BERTELLI, J.; MATTE, J.; GRAEBIN, R.; MACKE, J. Smart city: Um conceitoem 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 layoutsCSS 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 forintegrating various data of sensor networks. In: IEEE. ICT for Smart Society (ICISS), 2013International 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 novaprática para o gerenciamento dos serviços e infraestruturas urbanos: a experiênciada 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 deGestã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 deMarketing. 2014. Dez., 2014. Disponível em: <https://resultadosdigitais.com.br/blog/por-que-trabalhar-com-templates-facilita-muito-o-trabalho-de-marketing/>. Acesso em01-Maio-2018. Citado na página 33.

https://www.nngroup.com/articles/the-need-for-web-design-standards/

https://www.nngroup.com/articles/the-need-for-web-design-standards/

https://alistapart.com/article/building-twitter-bootstrap

https://alistapart.com/article/building-twitter-bootstrap

https://resultadosdigitais.com.br/blog/por-que-trabalhar-com-templates-facilita-muito-o-trabalho-de-marketing/

https://resultadosdigitais.com.br/blog/por-que-trabalhar-com-templates-facilita-muito-o-trabalho-de-marketing/

Apêndices

68

APÊNDICE A – Termo de Livre

Consentimento Esclarecido

69

APÊNDICE B – Roteiro de Avaliação

70

APÊNDICE C – Tarefas

Documents

SmartNode Dashboard: um framework front-end baseado em … · 2019-05-26 · SmartNode Dashboard: um framework front-end baseado em Node-RED para criação de City Dashboards / Cesimar