Uma proposta de framework para facilitar o desenvolvimento ......Uma proposta de framework para...
96
Transcript of Uma proposta de framework para facilitar o desenvolvimento ......Uma proposta de framework para...
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departmento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Uma proposta de framework para facilitar o
desenvolvimento de aplicações baseadas em
IoT
Dannylo Johnathan Bernardino Egídio
Natal Julho, 2018
Dannylo Johnathan Bernardino Egídio
Uma proposta de framework para facilitar o
desenvolvimento de aplicações baseadas em IoT
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.
Linha de pesquisa: Engenharia de Software
Orientador
Prof. Dr. Gibeon Soares de Aquino Junior
PPgSC � Programa de Pós-Graduação em Sistemas e Computação
DIMAp � Departamento de Informática e Matemática Aplicada
CCET � Centro de Ciências Exatas e da Terra
UFRN � Universidade Federal do Rio Grande do Norte
Natal
Julho, 2018
Egídio, Dannylo Johnathan Bernardino. Uma proposta de framework para facilitar o desenvolvimento deaplicações baseadas em IoT / Dannylo Johnathan BernardinoEgídio. - 2018. 94f.: il.
Dissertação (Mestrado) - Universidade Federal do Rio Grandedo Norte, Departamento de Informática e Matemática Aplicada(DIMAP), Programa de Pós-graduação em Sistemas e Computação(PPgSC), Natal, 2018. Orientador: Dr. Gibeon Soares de Aquino Júnior.
1. Virtualização - Dissertação. 2. Internet das Coisas -Dissertação. 3. Framework - Dissertação. I. Aquino Júnior,Gibeon Soares de. II. Título.
RN/UF/BCZM CDU 004.43-021.131
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 RAIMUNDO MUNIZ DE OLIVEIRA - CRB-15/429
Dedico este trabalho à minha esposa Francielly Luanne, inspiração de vida, e grande
motivadora desta vitória.
Agradecimentos
Agradeço inicialmente ao pai celestial, por ter me abençoado e protegido durante toda
esta caminhada.
A minha amada esposa Francielly Luanne que durante todo o Mestrado tem sido for-
taleza em minhas aspirações, e pacientemente tem aguentado meus estresses e frustrações
que foram reincidentes durante esta formação.
A meus pais, Vanderlei e Isabel, pelo exemplo que representam em minha vida e por
todo o incentivo e amor dedicados a mim desde meu nascimento até agora, esta vitória
jamais seria possível sem o amparo, exemplo e dedicação deles.
A meu orientador Gibeon Aquino, pelos ensinamentos e conselhos em minha formação
acadêmica, e por ser um exemplo de pro�ssional e humano na qual posso me espelhar.
Ao meu orientador da graduação e amigo Héldon José, por ter me motivado desde a
graduação a subir mais um degrau na escada do conhecimento e vir fazer este mestrado.
A meus amigos do LabCoMU, pelos conselhos, aprendizados, felicidades e frustrações
compartilhadas durante este tempo.
Aos amigos Thiago e Bruno, pelas revisões e dicas na produção deste trabalho.
Aos amigos Romerito, Sidney, Paulenne e Diego, por terem me acolhido em minha
chegada à Natal e pela amizade que foi dedicada a minha pessoa.
E a todos, que de forma direta ou indireta, puderam contribuir nesta caminhada e na
realização deste sonho.
"O fardo é proporcional às forças, como a recompensa será proporcional à resignação e
à coragem."
Allan Kardec
Uma proposta de framework para facilitar odesenvolvimento de aplicações baseadas em IoT
Autor: Dannylo Johnathan Bernardino Egídio
Orientador(a): Prof. Dr. Gibeon Soares de Aquino Junior
Resumo
Os últimos anos têm sido marcados por um crescente avanço na computação embarcada,
tecnologias de sensoriamento e dispositivos conectados. Tal avanço impactou de maneira
expressiva em paradigmas inovadores, tais como o de Internet das Coisas (IoT) que acre-
dita que objetos inteligentes capazes de se conectarem na rede poderão cooperar entre si
para alcançar um objetivo comum. Tal crescimento alavancou iniciativas de fornecedores
em produzir protocolos e padrões de comunicação que viabilizassem essa cooperação. No
entanto, a diversidade considerável de dispositivos e consequentemente de protocolos que
surgiram, acabaram por di�cultar esse processo. Inúmeros desa�os foram surgindo, den-
tre eles a heterogeneidade e a interoperabilidade. Esses desa�os tornaram o processo de
desenvolvimento das aplicações IoT uma tarefa complexa e custosa, pois as capacidades
destes protocolos e padrões voltadas à descoberta dos dispositivos na rede, comunicação
entre eles, entre outras, tornaram-se bastante especí�cas para cada dispositivo, obrigando
o desenvolvedor a criar estratégias de integração complexas para lidar com essa limita-
ção. Desta forma, este trabalho propõe um framework que buscará facilitar o processo de
desenvolvimento de aplicações IoT através da virtualização de dispositivos, de maneira
que, aspectos heterogêneos ligados aos dispositivos serão abstraídos por esta virtualização
e operações comuns dos protocolos tais como descoberta de dispositivos e comunicação
com estes serão abstraídos através de uma interface comum entre eles, integrando-os e
diminuindo os impactos das características heterogêneas.
Palavras-chave: Internet das Coisas, Framework, Simpli�cação, Desenvolvimento, Aplica-
ção, Virtualização.
A framework proposal to facilitate the development ofIoT-based applications
Author: Dannylo Johnathan Bernardino Egídio
Supervisor: Prof. Dr. Gibeon Soares de Aquino Junior
Abstract
Recent years have been marked by a growing advance in embedded computing, sensoring
technologies and connected devices. Such advance had a signi�cant impact on innovative
paradigms such as the Internet of Things (IoT), which believes that intelligent objects ca-
pable of connecting in the network can cooperate among each other to achieve a common
goal. Such growth has motivated supplier initiatives to produce protocols and communi-
cation standards that would enable such cooperation. However, the considerable diversity
of devices and consequently protocols that have emerged have made this process di�cult,
creating numerous challenges, including heterogeneity and interoperability. These chal-
lenges have made the IoT application development process a complex and costly task,
since the capabilities of these protocols and standards aimed at discovering the devices
on the network, communication among them, have become quite speci�c for each device,
forcing the developer to create complex integration strategies to deal with this limitation.
In this way, this work proposes a framework that seeks to facilitate the process of deve-
lopment of IoT applications through device virtualization, so that heterogeneous aspects
connected to devices will be abstracted by this virtualization, and common operations of
protocols such as discovery of devices and communication with them will be abstracted
through a common interface between them, integrating them and reducing the impacts
of the heterogeneous characteristics.
Keywords : Internet of Things, Framework, Simplifcation, Development, Application, Vir-
tualization.
Lista de �guras
1 Etapas da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2 Paradigma de IoT como sendo o resultado da convergência de três visões
(ATZORI; IERA; MORABITO, 2010) . . . . . . . . . . . . . . . . . . . . . p. 22
3 Modelo arquitetural genérico para IoT (KHAN et al., 2012) . . . . . . . . p. 23
4 Camada de mensagens do CoAP(SHELBY; HARTKE; BORMANN, 2014) . p. 27
5 Implementação proposta para interoperabilidade entre HTTP e CoAP.(BORMANN;
CASTELLANI; SHELBY, 2012) . . . . . . . . . . . . . . . . . . . . . . . . p. 27
6 Fluxo de funcionamento básico do UPnP.(ARUNACHALAM; GANAPATHY,
2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
7 Fontes de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
8 Veículos de Publicação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
9 Número de publicações por ano . . . . . . . . . . . . . . . . . . . . . . p. 35
10 Tipos de soluções encontradas . . . . . . . . . . . . . . . . . . . . . . . p. 36
11 Abordagens mais utilizadas . . . . . . . . . . . . . . . . . . . . . . . . p. 37
12 Requisitos atingidos pelas propostas . . . . . . . . . . . . . . . . . . . . p. 38
13 Objetivos das soluções encontradas . . . . . . . . . . . . . . . . . . . . p. 40
14 Aplicação IoT lidando com a heterogeneidade de Dispositivos. . . . . . p. 46
15 Aplicação IoT utilizando o framework para simpli�car o desenvolvimento. p. 47
16 Visão geral da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
17 Estrutura do dispositivo virtual. . . . . . . . . . . . . . . . . . . . . . . p. 50
18 Funcionamento do Tradutor Proxy. . . . . . . . . . . . . . . . . . . . . p. 53
19 Estrutura de comunicação entre os dispositivos. . . . . . . . . . . . . . p. 55
20 Estrutura operacional do Framework . . . . . . . . . . . . . . . . . . . p. 57
21 Diagrama de Classes da estrutura do Framework . . . . . . . . . . . . . p. 58
22 Con�guração do con�g.properties para de�nir proxies externos ao fra-
mework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
23 Instanciação do Framework. . . . . . . . . . . . . . . . . . . . . . . . . p. 61
24 Sequência de funcionamento do Proxy UPnP. . . . . . . . . . . . . . . p. 63
25 Sequência de funcionamento do Proxy Bluetooth. . . . . . . . . . . . . p. 64
26 Cenário do experimento utilizado como objeto de estudo. . . . . . . . . p. 67
27 Aplicativo Android representando um Termostato Bluetooth. . . . . . . p. 69
28 Aplicação cliente desenvolvida na plataforma Android. . . . . . . . . . p. 70
29 Funcionamento geral da aplicação cliente com o framework. . . . . . . . p. 71
30 Código utilizado para a instanciação do framework e descoberta dos dis-
positivos na aplicação cliente. . . . . . . . . . . . . . . . . . . . . . . . p. 71
31 Código necessário para a veri�cação do estado dos dispositivos e modi�-
cação do estado do termostato. . . . . . . . . . . . . . . . . . . . . . . p. 72
32 Log registrando a alteração bem-sucedida do estado do termostato. . . p. 72
33 LOC por classe mensuradas no experimento do Estudo de Caso. . . . . p. 74
34 Comparativo da Complexidade Ciclomática das aplicações IoT. . . . . p. 75
35 LOC para aplicação envolvendo 10 sensores e um atuador. . . . . . . . p. 76
36 Comparativo da complexidade ciclomática para a aplicação com 10 sen-
sores e dois termostatos. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
Lista de tabelas
1 Repositórios de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
2 Iteração de Leituras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3 Serviços utilitários fornecidos pelo núcleo do framework. . . . . . . . . . p. 65
4 Linhas de Código (LOC) extraídas das classes do caso de teste (um sensor
e um termostato). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73
5 Linhas de Código (LOC) extraídas das classes do caso de teste (dez
sensores e dois termostatos). . . . . . . . . . . . . . . . . . . . . . . . . p. 74
Lista de abreviaturas e siglas
IoT � Internet of Things
QoS � Quality of Service
SoA � Service-oriented architecture
CoAP � Constrained Application Protocol
REST � Representational State Transfer
URI � Uniform Resource Identi�er
HTTP � Hypertext Transfer Protocol
M2M - Machine-to-Machine
UDP � User Datagram Protocol
UPnP � Universal Plug and Play
XML � eXtensible Markup Language
URL � Uniform Resource Locator
IEEE � Institute of Electrical and Electronic Engineers
API � Application Programing Interface
JSON � JavaScript Object Notation"
WMC � Weighted Methods per Class
CCN � Cyclomatic Complexity Number
LOC � Lines of Code
MQTT � Message Queuing Telemetry Transport
SOAP � Simple Object Access Protocol
Lista de Listagens
4.1 Iniciação do framework e descoberta de dispositivos . . . . . . . . . . . p. 61
4.2 Solicitando dados dos dispositivos virtuais . . . . . . . . . . . . . . . . p. 61
4.3 Enviando dados para os dispositivos virtuais . . . . . . . . . . . . . . . p. 61
4.4 Componentes necessários para a de�nição de um novo proxy na camada
Proxy Translate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
Sumário
1 Introdução p. 17
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2 Fundamentação Teórica p. 21
2.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.1.1 Visões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.1.2 Modelo Arquitetural . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.1.3 Tecnologias envolvidas . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.2 Constrained Application Protocol . . . . . . . . . . . . . . . . . . . . . p. 26
2.3 Universal Plug and Play . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3 Revisão do Estado da Arte p. 31
3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.1.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.1.2 String de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.1.3 Fontes de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3.1.4 Execução da Revisão . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.1.5 Processo de Seleção . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.1.6 Extração dos Resultados . . . . . . . . . . . . . . . . . . . . . . p. 34
3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.2.1 Análise da QP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.2.2 Análise da QP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.2.3 Análise da QP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
3.3 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
4 Um framework para facilitar o desenvolvimento de aplicações base-
adas em IoT p. 44
4.1 Cenário de Exemplo: Controle de temperatura . . . . . . . . . . . . . . p. 45
4.2 Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2.2 Dispositivo Virtual . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
4.2.2.1 Componentes de De�nição . . . . . . . . . . . . . . . . p. 50
4.2.2.2 Componentes de Comunicação . . . . . . . . . . . . . p. 51
4.2.3 Gerenciador de Dispositivos . . . . . . . . . . . . . . . . . . . . p. 52
4.2.4 Servidor CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4.2.5 Módulo Health . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4.2.6 Tradutor Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.3 Comunicação entre Dispositivos Virtuais . . . . . . . . . . . . . . . . . p. 54
4.4 Operacionalização da Solução . . . . . . . . . . . . . . . . . . . . . . . p. 56
4.5 Desenvolvimento da Solução . . . . . . . . . . . . . . . . . . . . . . . . p. 57
4.5.1 Estrutura da Solução . . . . . . . . . . . . . . . . . . . . . . . . p. 57
4.5.2 Instanciação do Framework . . . . . . . . . . . . . . . . . . . . p. 60
4.5.3 Núcleo e Pontos de Extensão . . . . . . . . . . . . . . . . . . . . p. 62
4.5.3.1 Adicionando novos Proxies . . . . . . . . . . . . . . . . p. 62
4.5.3.2 O Núcleo . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
5 Avaliação do Framework p. 66
5.1 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
5.1.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
5.1.1.1 Questões de Pesquisa . . . . . . . . . . . . . . . . . . . p. 66
5.1.1.2 Sujeitos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
5.1.1.3 Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
5.1.1.4 Unidades de análise . . . . . . . . . . . . . . . . . . . p. 68
5.1.1.5 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . p. 68
5.1.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
5.1.2.1 A aplicação . . . . . . . . . . . . . . . . . . . . . . . . p. 68
5.1.2.2 A coleta e análise dos dados . . . . . . . . . . . . . . . p. 73
5.1.3 Respostas às questões de pesquisa . . . . . . . . . . . . . . . . . p. 74
5.1.3.1 Qual o impacto do uso do framework em uma aplicação
IoT quanto à diminuição do esforço de codi�cação de
seu desenvolvimento? . . . . . . . . . . . . . . . . . . . p. 74
5.1.3.2 Questão de pesquisa 2: Qual o impacto que pode haver
no aumento da quantidade de dispositivos envolvidos na
aplicação no tocante à complexidade de codi�cação da
aplicação que utiliza o framework? . . . . . . . . . . . p. 76
5.1.4 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . p. 77
6 Trabalhos Relacionados p. 79
6.1 Modelos de representação de Dispositivos . . . . . . . . . . . . . . . . . p. 79
6.2 Dispositivos abstraídos como Serviços . . . . . . . . . . . . . . . . . . . p. 81
7 Considerações Finais p. 83
7.1 Retrospectiva e conclusões do trabalho . . . . . . . . . . . . . . . . . . p. 83
7.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
Referências p. 87
8 Apêndice A p. 92
17
1 Introdução
Este capítulo tem a �nalidade de descrever em termos gerais a proposta desta pesquisa,
descrevendo os fatores motivadores na Seção 1.1, objetivos gerais e especí�cos pretendidos
na Seção 1.2, a metodologia utilizada para se atingir os objetivos na Seção 1.3, e por �m,
como o trabalho está estruturado na Seção 1.4.
1.1 Motivação
Os últimos anos têm sido marcados por um crescente avanço na computação embar-
cada, tecnologias de sensoriamento e dispositivos inteligentes sendo amplamente distribuí-
dos no mercado. Algumas previsões recentes estimam cerca de 29 bilhões de dispositivos
conectados até 2022 (MEHTA et al., 2017). Este expressivo surgimento de tecnologias mi-
niaturizadas inteligentes e conectadas tem propiciado o desenvolvimento de uma série de
serviços úteis e importantes para as pessoas.
Tal avanço impactou de maneira signi�cativa em conceitos inovadores, como o conceito
de Internet da Coisas (IoT ), que preconiza que objetos inteligentes, tidos como "coisas",
podem cooperar entre si através da internet para alcançar um objetivo comum (PATEL;
CASSOU, 2015). O conceito de IoT ganhou combustível neste cenário e consequentemente
o interesse da indústria e mercado em basear os novos serviços e aplicações oferecidas
em seus princípios (DATTA; BONNET, 2016). Desta forma, ecossistemas inteligentes têm
sido sugeridos para inúmeros contextos, tais como casas inteligentes, cidades inteligentes,
fazendas inteligentes, fábricas inteligentes, entre outros (YEN et al., 2017).
Porém, as tecnologias utilizadas por estas aplicações são portadoras de limitações
críticas que são cruciais para a concretização dos conceitos de IoT, dentre elas estão a
heterogeneidade e interoperabilidade entre dispositivos e padrões, sendo considerado um
dos maiores desa�os de IoT (TAYUR; SUCHITHRA, 2017), as restrições de recursos, que in-
cluem capacidade computacional, memória e armazenamento dos objetos constituintes da
18
aplicação (CARRANZA-GARCÍA et al., 2016), entre outras limitações em nível de hardware
que de alguma maneira constituem obstáculos para o avanço efetivo do conceito de IoT.
Ademais, a própria variedade de dispositivos existentes nos leva a compreender o
processo de desenvolvimento de aplicações IoT como algo complexo e custoso (PATEL;
CASSOU, 2015). Essa variedade de dispositivos implicam em várias formas de representa-
ção de dados, múltiplos protocolos de comunicação (SASIREKHA; SWAMYNATHAN, 2016),
uma variedade de implementações de serviços em nível de software especí�cas para cada
dispositivo (ASHRAF et al., 2016). Deste modo, abordagens diferentes podem ser sugeridas
para cada dispositivo especí�co.
Compreendendo as limitações voltadas ao vasto número de dispositivos diferentes exis-
tentes, torna-se interessante o uso da habilidade de descoberta de dispositivos. Essa habi-
lidade representa um princípio de projeto orientado a serviços capaz de tornar os serviços
identi�cáveis na rede através de meta-dados disponibilizados pelos mesmos facilitando a
colaboração entre eles (JARA et al., 2014). Tal modelo é muito adotado por aplicações IoT
que planejam facilitar o uso dos dispositivos envolvidos na aplicação (DATTA; BONNET,
2016) .
Observando todos os aspectos que tornam os dispositivos e seus serviços heterogêneos
e de baixa interoperabilidade, padrões foram sendo sugeridos por muitos consórcios de
fornecedores. No entanto, estes padrões apenas solucionam questões de interoperabilidade
para o conjunto de dispositivos que atendem, provendo mecanismos de registro, descoberta
e comunicação. Contudo, estes padrões geralmente costumam ser incompatíveis entre
si (TAYUR; SUCHITHRA, 2017). Sendo assim, o processo de descoberta e comunicação
envolvendo múltiplos padrões e protocolos em uma aplicação acabam por se tornarem
complexos de trabalharem em conjunto.
Desta forma, é perceptível a necessidade de soluções que busquem integrar as ca-
pacidades de protocolos heterogêneos, abstraindo as diferenças existentes entre eles e
viabilizando a simpli�cação do desenvolvimento de aplicações baseadas em IoT. Para tal,
acreditamos ser importante buscar uma abordagem orientada à virtualização de disposi-
tivos que os representará de maneira uniforme e permitirá o acesso direto às operações e
recursos disponibilizados por estes (SILVA et al., 2016; FERRERA et al., 2017). Neste con-
texto, aspectos heterogêneos e capacidades individuais dos mesmos �cam abstraídos do
ponto de vista do desenvolvedor.
Sendo assim, este trabalho de dissertação baseia-se na hipótese de que a de�nição
de um modelo homogêneo de representação de "coisas", através da virtualização, auxilia
19
na simpli�cação do desenvolvimento de aplicações baseadas em IoT. As especi�cidades
funcionais e técnicas, que podem ser heterogêneas, seriam abstraídas por este modelo de
representação.
1.2 Objetivos
Este trabalho tem como objetivo geral o desenvolvimento de um framework que visa
facilitar o desenvolvimento de aplicações baseadas em IoT, abstraindo e uniformizando
capacidades heterogêneas voltadas à protocolos de comunicação tais como mecanismos de
descoberta e colaboração entre dispositivos. A abordagem buscará tratar os dispositivos
da aplicação de maneira uniforme, propiciando recursos para a representação virtualizada
dos mesmos. Desta forma, os objetivos especí�cos pretendidos são os seguintes:
• Mapear os requisitos, limitações e abordagens mais comuns levantados em soluções
do estado da arte que objetivem a simpli�cação do desenvolvimento de aplicações
IoT.
• Implementar uma solução que viabilize a simpli�cação do desenvolvimento de apli-
cações IoT a partir da abstração e virtualização de dispositivos.
• Avaliar sob o ponto de vista da facilidade de desenvolvimento a solução desenvolvida,
utilizando-se de métricas que possam validar tal aspecto.
1.3 Metodologia
Esta seção descreve as etapas da metodologia (Vide Figura 1) que foram seguidas para
esta dissertação, dividindo-se em três etapas: Revisão Literária, Projeto e Implementação
do Framework e Avaliação.
Figura 1: Etapas da Metodologia
A primeira etapa consiste de um processo de pesquisa exploratória. Nessa etapa foi
de�nida uma string de busca com o objetivo de encontrar trabalhos relacionados à ferra-
mentas de software especializadas em simpli�car o processo de desenvolvimento de apli-
cações IoT. A string foi executada no repositório Scopus da Elsevier pelo fato do mesmo
20
indexar os principais e mais relevantes repositórios da engenharia e computação. Os re-
sultados foram então analisados. Toda a Metodologia é descrita em maiores detalhes no
Capítulo 3.
A etapa seguinte, concentra-se no projeto e desenvolvimento do framework na qual
essa dissertação tem como objetivo. Nesta etapa, a arquitetura do framework e seus com-
ponentes constituintes são projetados de modo a embasar detalhes mais técnicos do seu
desenvolvimento. Por �m, foi desenvolvida a solução utilizando a arquitetura mencionada.
Os detalhes inerentes a esse processo estão descritos no capítulo 4.
O último passo, o de Avaliação, trata-se de uma prova de conceito cujo objetivo é obter
resultados que possam avaliar sob o ponto de vista da facilidade de desenvolvimento o
framework proposto.
1.4 Organização do trabalho
O restante desse trabalho encontra-se organizado da seguinte forma:
• O capítulo 2 expõe a fundamentação teórica contendo os conceitos necessários ao
entendimento deste trabalho;
• O capítulo 3 apresenta a revisão do estado da arte realizada neste trabalho. Tal
revisão tem o objetivo de conhecer de maneira mais aprofundada as ferramentas
associadas à simpli�cação do desenvolvimento de aplicações IoT e alguns detalhes
relacionados a estas considerados importantes.
• O capítulo 4 expõe o framework proposto por este trabalho, cujo objetivo será de
simpli�car o desenvolvimento de aplicações baseadas em IoT.
• O capítulo 5, trata sobre a avaliação do framework proposto neste trabalho, e tal
avaliação se deu a partir de uma prova de conceito.
• O capítulo 6 expõe resumidamente os trabalhos relacionados ao proposto por essa
pesquisa.
• O capítulo 7 discorre sobre considerações �nais deste trabalho, as principais contri-
buições do mesmo e os trabalhos futuros propostos pelo autor desta pesquisa.
21
2 Fundamentação Teórica
Este capítulo discorre sobre os fundamentos no qual sustenta-se este trabalho. Seu
objetivo é explicar de maneira sucinta, as características gerais de cada um dos concei-
tos utilizados na construção da proposta desta pesquisa. Desta forma, este capítulo está
organizado em quatro seções: A primeira, a 2.1 trata sobre conceitualizar a Internet das
Coisas, suas visões, modelo arquitetural e tecnologias envolvidas, a 2.2 discorre sobre o
CoAP e suas características técnicas, a 2.3 busca explicar o funcionamento do UPnP, por
�m, a 2.4 explica sobre o funcionamento do protocolo Bluetooth.
2.1 Internet das Coisas
A Internet das Coisas, do inglês, Internet of Things (IoT) trata-se de um paradigma
inovador que vai além das soluções computacionais voltadas à desktop tradicionais (GUBBI
et al., 2013). O termo foi introduzido por Kevin Ashton no ano de 1998 em um contexto
de gerenciamento de cadeia de suprimentos, e passou a ganhar a partir disto, uma maior
atenção da academia e da indústria (GUBBI et al., 2013; BANDYOPADHYAY; SEN, 2011).
A ideia principal do paradigma centraliza-se em objetos comuns de nosso cotidiano
inseridos inevitavelmente na rede. Neste cenário, sensores, tecnologias de identi�cação,
dispositivos inteligentes de toda natureza, estarão em alta para embarcarem invisivelmente
em soluções que gerarão uma alta quantidade de dados. Essa massiva quantidade de dados
consequentemente necessitará de estruturas que possam comportar e processar tal volume
para que assim possa ter valor para a aplicação (GUBBI et al., 2013) .
Além de todos os benefícios oriundos desse novo modelo computacional, Atzori (AT-
ZORI; IERA; MORABITO, 2010) considera como sendo a principal força que norteará os
objetivos do paradigma, o impacto que ela terá no dia-a-dia e nos aspectos comportamen-
tais de seus usuários. Neste ponto de vista, o autor acredita que contextos domésticos,
de vida assistida, aprendizado e saúde, são apenas alguns poucos exemplos de cenários
22
em que a IoT desempenhará demasiada liderança no desenvolvimento de aplicações, bem
como no âmbito de negócios, havendo considerável impacto em aplicações de automação,
manufatura, gestão de negócios, transportes, etc.
2.1.1 Visões
O conceito de IoT é permeado de múltiplas visões e discussões diversas. Isso se dá
devido ao próprio nome "Internet das Coisas� carregar inúmeras formas de pensar. O
termo "Internet� nos direciona a uma visão de IoT focada diretamente na rede e em
seus recursos, já o termo "Coisas�, foca diretamente em múltiplos objetos inteligentes
e conectados que realizam operações especí�cas e estão integrados no cenário, havendo
comunicação entre eles (ATZORI; IERA; MORABITO, 2010). O termo "Coisas"também é
considerado uma nova dimensão da atual interação das aplicações com o ser humano (LU;
PAPAGIANNIDIS; ALAMANOS, 2018).
Figura 2: Paradigma de IoT como sendo o resultado da convergência de três visões (AT-ZORI; IERA; MORABITO, 2010)
.
Contudo, o uso desses termos em conjunto semanticamente nos diz que trata-se de um
conjunto de dispositivos heterogêneos, endereçáveis, e interconectados através de proto-
colos de comunicação (BANDYOPADHYAY; SEN, 2011). Uma terceira perspectiva também
é reconhecida neste aspecto: A semântica. Tal visão é orientada ao endereçamento (ou
identi�cação exclusiva), armazenamento e processamento da informação gerada nessas
aplicações, tal processamento deve considerar a natureza heterogênea da informação ge-
23
rada e dos dispositivos que a geraram.
Desta forma, acredita-se que o paradigma de IoT é o resultado da convergência des-
tas três visões (ATZORI; IERA; MORABITO, 2010), a Figura 2 ilustra esse fato, além de
apresentar algumas das principais tecnologias e conceitos mais comuns de cada visão.
Outras de�nições podem ser evidenciadas no estudo de Lu (LU; PAPAGIANNIDIS; ALA-
MANOS, 2018), dentre estas, sugere-se que IoT seja um conjunto de objetos capazes de
se identi�carem e conectarem-se em uma rede. E a de�nição proposta pela Comissão
Europeia, considerada pelo referido autor como uma das mais representativas de�nições
de IoT, considerando o paradigma como uma infraestrutura de rede global que agirá de
maneira integralizada como uma extensão da futura internet.
2.1.2 Modelo Arquitetural
A arquitetura considerada genérica do paradigma IoT precisa abordar muitos fatores
que vão além da arquitetura TCP/IP convencional (KHAN et al., 2012). Isto porque trata-
se de um modelo que gerará muito mais informação e tráfego, além dos desa�os voltados
à privacidade e segurança. Desta forma, um modelo arquitetural ideal para aplicações
IoT necessita tratar aspectos voltados à muitos fatores, tais como: interoperabilidade,
segurança, con�abilidade, QoS , etc (KHAN et al., 2012).
Figura 3: Modelo arquitetural genérico para IoT (KHAN et al., 2012).
Compreendendo estes aspectos, um modelo genérico baseado em camadas é proposto
por (KHAN et al., 2012) e ilustrado na Figura 3. Este modelo compreende cinco camadas
com responsabilidades bem-de�nidas: Percepção, Rede, Middleware, Aplicação e Negócio.
24
A camada de Percepção, que (BANDYOPADHYAY; SEN, 2011) considera como "Ca-
mada de Tecnologias de Borda", compreende todos os dispositivos físicos e sensores que
objetivam coletar informações do contexto para as camadas superiores. A camada de Rede
basicamente irá transferir as informações geradas pelos dispositivos sensores para os servi-
ços de processamento, desta forma, ela é um intermediador entra a camada de Percepção
e a de Middleware.
A camada deMiddleware por sua vez, padroniza e gerencia os serviços oferecidos pelos
dispositivos. Esta pode persistir os dados enviados a ela, bem como realizar processamen-
tos e tomar decisões com base nestes. A camada de Aplicação fornece o gerenciamento
dos serviços processados pela camada de Middleware, favorecendo o desenvolvimento de
múltiplos cenários de aplicação (saúde, agricultura, transporte, negócios, etc.). Por �m,
a camada de Negócios gera meios de analisar os dados produzidos pelas camadas inferio-
res através de recursos diversos que possam ser produzidos, tais como: grá�cos, modelos,
�uxogramas, etc.
Outros modelos arquiteturais também são propostos, eles buscam enxergar o para-
digma IoT através de SoA , e um dos modelos mais comuns utilizados é expressado por
Li et al.(LI; XU; ZHAO, 2015), o referido autor acredita que modelos baseados em SoA im-
pactam diretamente na heterogeneidade de dispositivos presentes nos ecossistemas IoT.
O modelo proposto é formado por 4 camadas de�nidas da seguinte forma:
• Camada de Sensoriamento: todos os hardwares dotados de sensores pertencem
a essa camada, e juntos proverão dados do mundo real para as próximas camadas.
• Camada de Rede: camada responsável pelos componentes que manterão a comu-
nicação entre things.
• Camada de Serviço: camada responsável pela criação e gerenciamento dos serviços
necessários para a aplicação e seus usuários.
• Camada de Interfaces: concentrará todos os mecanismos de interação da aplicação
com seus usuários.
Tais modelos arquiteturais buscam adapatarem-se às necessidades de cada aplicação,
por esta razão são considerados modelos genéricos.
25
2.1.3 Tecnologias envolvidas
Para atingir os objetivos pretendidos pelo paradigma de IoT, as arquiteturas pro-
postam buscam integrar as inúmeras tecnologias desenvolvidas. Dentre essas, Lee (LEE;
LEE, 2015) destaca as consideradas por ele como essenciais: Tecnologias de identi�cação,
Dispositivos sensores, Middlewares e Computação na nuvem.
• Tecnologias de Identi�cação: É basicamente composto por dispositivos capazes de
identi�car unicamente os objetos presentes na infraestrutura IoT. RFID possui de-
masiado destaque nesse caso (LI; XU; ZHAO, 2015), sua estrutura é composta por um
ou muitos leitor(es) e tags RFID. As tags são identi�cadores únicos e geralmente
estão associados a objetos na aplicação. Os leitores buscam constantemente por um
sinal apropriado que é emitido pelas tags espalhadas no ambiente. Tal tecnologia
é frequentemente utilizada em ambientes que possuem a necessidade de monitora-
mento em tempo real (ATZORI; IERA; MORABITO, 2010). Outras abordagens são
utilizadas para a de�nição de identi�cadores únicos nos dispositivos conectados,
Tiwary (TIWARY et al., 2018) destaca que endereços IPv4 e IPv6 são também alter-
nativas utilizadas como estratégias de identi�cação.
• Dispositivos sensores: São dispositivos equipados com sensores autônomos que po-
dem monitorar as condições físicas ou de ambiente (LEE; LEE, 2015). Estes sensores
são geralmente compostos por uma interface comum para manipulá-los, realizar
processamentos unitários, além disso também são dotados de unidades tradutoras e
fontes de energia (GUBBI et al., 2013).
• Middlewares : Representam camadas de softwares geralmente posicionadas na arqui-
tetura de modo a facilitar a comunicação de componentes da aplicação, esta costuma
ocultar detalhes irrelevantes ao ponto de vista do desenvolvedor (LEE; LEE, 2015). O
desenvolvimento de middlewares tem ganhado considerável crescimento face à ne-
cessidade de facilitar o desenvolvimento de novos serviços e a integração de serviços
novos e antigos. Para tal, arquiteturas orientadas a serviços (SOA) tem sido uma
abordagem aconselhada para esta �nalidade, pois permite a decomposição de siste-
mas complexos e monolíticos em aplicações mais simples e dotadas de componentes
bem-de�nidos (ATZORI; IERA; MORABITO, 2010).
• Computação na nuvem: Representa um modelo computacional de acesso sob de-
manda a recursos de con�guração compartilhados (LEE; LEE, 2015). O uso da com-
putação na nuvem nos direciona a uma abordagem orientada a recursos da internet,
26
de modo que possa lidar com a massiva quantidade de dados gerado pelos sensores
da aplicação e possa conter recursos que concedam: capacidades de análises de da-
dos, armazenamento escalável e capacidades de compartilhamento de dados em alto
nível (GUBBI et al., 2013).
2.2 Constrained Application Protocol
CoAP surge como um dos protocolos de nível de aplicação mais amplamente conside-
rados no tocante à "rede de coisas� no contexto de IoT (RUTA et al., 2017). Ele representa
um padrão entre clientes e servidores provendo uma interface RESTful simpli�cada, pois
aplicações baseadas em IoT necessitam de protocolos mais leves devido à sobrecarga de
tráfego de dados, capacidades energéticas e computacionais. Por esta razão, CoAP dis-
ponibiliza uma interface baseada em REST para habilitar sensores e dispositivos de
capacidades restritas a se comunicarem pela rede (SALMAN; JAIN, 2015).
O protocolo provê um modelo de interação requisição/resposta, suportando desco-
berta de serviços e recursos, incluindo alguns conceitos da Web tais como URI , tipos de
mídia, bem como busca ser interoperável com o HTTP (SHELBY; HARTKE; BORMANN,
2014). Dentre as características principais contempladas pela especi�cação CoAP, Shelby
(SHELBY; HARTKE; BORMANN, 2014) destaca as seguintes:
• Um protocolo WEB para requisitos de comunicações restritas M2M .
• Baseado em UDP , suportando comunicação unicast e multicast.
• Troca de mensagens assíncronas.
• Proxy simples e capacidades de caching.
Além das características supracitadas, CoAP de�ne uma simples camada de mensa-
gens para a retransmissão dos pacotes que possam perder-se no processo de transmissão,
bem como disponibiliza quatro métodos de requisição similares ao HTTP: GET, PUT,
POST e DELETE. Utiliza-se de apenas 4 bytes no cabeçalho seguido de opções, desta
forma, requisições típicas costumam possuir de 10 a 20 bytes de tamanho (BORMANN;
CASTELLANI; SHELBY, 2012).
A camada de mensagens do CoAP comporta 4 tipos básicos: Con�rmable(CON), Non-
con�rmable(NON), Acknowledgement(ACK) e Reset(RST). Estas ocorrem de acordo com
27
Figura 4: Camada de mensagens do CoAP(SHELBY; HARTKE; BORMANN, 2014)
a situação da requisição e do retorno da entidade receptora (servidor). Uma mensagem
Con�rmable requer uma resposta (Acknowledgement) da entidade receptora devido à
ser uma comunicação assíncrona. A entidade requisitante irá retransmitir a mensagem
(Con�rmable) até que a receptora a responda. No entanto, modelos de negócio que não
requerem transmissões con�áveis podem optar por enviar mensagens Non-con�rmable,
estas não requerem uma resposta do recebimento dos pacotes na entidade receptora, neste
caso, quando ela não pode responder, uma mensagem Reset é gerada (SHELBY; HARTKE;
BORMANN, 2014).
Figura 5: Implementação proposta para interoperabilidade entre HTTP eCoAP.(BORMANN; CASTELLANI; SHELBY, 2012)
CoAP e HTTP podem se comunicar plenamente, além de compartilhar as capacida-
des inerentes às suas aplicações através da implementação de proxys ou intermediadores
implementados sobre clientes. Uma arquitetura muito comumente usada é ilustrada na
Figura 5. Neste caso, os intermediadores conversariam ambos os idiomas CoAP e HTTP
sem a necessidade de conhecer requisitos especí�cos de cada aplicação. Neste caso, não há
sequer a necessidade de atualizar os intermediadores nos casos das aplicações envolvidas
sofrerem modi�cações (clientes ou servidores), tornando-os bem independentes. Esta capa-
28
cidade é possível devido às particularidades dos protocolos (códigos de resposta, métodos,
etc.) serem similares (assim como demonstrado na Figura 5(b)), tornando o mapeamento
de sua relação algo bem direto (BORMANN; CASTELLANI; SHELBY, 2012).
2.3 Universal Plug and Play
O UPnP foi desenvolvido pela Microsoft e pelo UPnP Fórum e de�ne um conjunto
de protocolos que permitem que dispositivos diversos à base de IP possam se conectar na
rede. É uma solução para padronizar protocolos na internet e não está voltado a nenhum
sistema operacional ou linguagem de programação especí�ca (MESHKOVA et al., 2008).
No UPnP, dispositivos e serviços são descritos através de XML , e utilizam-se de um
relevante número de protocolos que viabilizam a autocon�guração local, reconhecimento
na rede, descoberta, interação cliente/servidor, entre outras operações essenciais para seu
funcionamento. Deste conjunto de protocolos, estão incluídos o Atuo-IP, SSDP (Sim-
ple Service Discovery Protocol), SOAP (Simple Object Access Protocol), GENA (General
Event Noti�cation Architecture), entre outros (ALLARD et al., 2003).
A arquitetura considera dois tipos de dispositivos: o dispositivo controlado e o ponto
de controle. Dispositivos controlados são considerados os nós da rede que possuem servi-
ços disponíveis, e os pontos de controle são dispositivos que podem descobrir dispositivos
controlados na rede e utilizarem-se de seus serviços. Um dispositivo pode implementar
qualquer um desses conceitos, e em alguns contextos pode possuir ambos (TOSCHI; CAM-
POS; CUGNASCA, 2016). A sua proposta está direcionada à seis fases: Endereçamento,
Descoberta, Descrição, Controle, Eventos e Apresentação (SILVA et al., 2016). Cada fase
possui um objetivo especí�co para tornar o UPnP um padrão interoperável. Tais fases
foram explicadas por Lee (LEE; HELAL, 2002):
• Descoberta: A descoberta do UPnP é baseada em SSDP, desta forma, quando um
dispositivo é adicionado na rede, ele imediatamente anuncia para os pontos de con-
trole existentes, os serviços que possui. Este processo também ocorre quando um
dispositivo (ponto de controle) deseja buscar algum serviço especí�co na rede.
• Descrição: Após a descoberta, os pontos de controle podem descobrir mais infor-
mações sobre o dispositivo encontrado na rede e suas capacidades através da URL
oferecida pelo dispositivo na estrutura da mensagem de descoberta. A descrição é
expressa em XML, e além das informações que o identi�cam, também é possível
29
encontrar a lista de serviços disponíveis, estruturas para controle, eventos e apre-
sentação.
• Controle: Um ponto de controle, depois de possuir conhecimento sobre um disposi-
tivo e seus serviços, pode eventualmente enviar ações para um determinado serviço.
As mensagens de controle são também expressas em XML utilizando SOAP, e estas
ações podem ou não retornar valores.
• Eventos : O UPnP permite que pontos de controle possam inscrever-se em determina-
das ações de serviços na rede, para serem noti�cadas em caso destas ações alterarem
suas variáveis de estado (estas que podem representar o estado do dispositivo). Desta
forma, quando o dispositivo tem seu estado alterado, o mesmo publica a alteração
no sistema de mensagens de evento que noti�cará os dispositivos ouvintes. Todas as
mensagens são expressas em XML através do GENA.
• Apresentação: Esta capacidade é permitida para que dispositivos consigam expor
seu estado em navegadores, através de URLs representativas dos mesmos.
Figura 6: Fluxo de funcionamento básico do UPnP.(ARUNACHALAM; GANAPATHY, 2016)
Em um �uxo básico de execução, após um ponto de controle descobrir um deter-
minado dispositivo na rede (Descoberta), ele recupera então a URL disponibilizada pelo
dispositivo (Descrição), já que o dispositivo possui através desta, além da descrição da sua
identi�cação, a descrição dos serviços que pode realizar. Para executar as ações (Controle)
de qualquer serviço desse dispositivo, o ponto de controle recupera o serviço escolhido, e
neste é possível identi�car todas as ações e variáveis de estado necessárias para a execução
desta ação, o �uxo supracitado é ilustrado na Figura 6 (ARUNACHALAM; GANAPATHY,
2016).
30
2.4 Bluetooth
Bluetooth é um padrão baseado em comunicação sem �o de dispositivos, projetado
para comunicações de curto alcance. O padrão também é conhecido como IEEE 802.15.1
(LEE; SU; SHEN, 2007). Também é considerado uma tecnologia de baixo custo e está
presente em muitos dispositivos populares tais como Notebooks, telefones celulares, entre
outros (CHLAMTAC; CONTI; LIU, 2003).
As especi�cações do Bluetooth foram estabelecidas a partir de um consórcio de gran-
des companhias da indústria tecnológica incluindo IBM, Microsoft, Motorola, Intel, entre
outras(CHLAMTAC; CONTI; LIU, 2003). O protocolo é considerado uma tecnologia proe-
minente para projetos de casas e cidades inteligentes, no entanto, ainda possui algumas
limitações importantes a tratar, tais como a baixa taxa de dados, a descoberta ine�ciente
de dispositivos, o seu alcance limitado, interferências, etc (SALEM; NADEEM, 2018).
O ciclo de vida da comunicação Bluetooth ocorre em 5 passos: Escaneamento, StandBy,
publicidade, iniciação e conexão. Os dois primeiros passos representam o processo de
monitoramento passivo da pilha Bluetooth, a fase de publicidade é feita por um dispositivo
para anunciar sua disponibilidade através do envio de um pacote especí�co. Durante
o processo de publicidade, um dispositivo no estado de iniciador �ca aguardando este
pacote para responder com um outro, que guarda informações especí�cas para iniciar a
comunicação e trocar os dados nessa mesma comunicação. Logo em seguida, o estado
de conexão se mantém e os dispositivos começam a trocar suas informações (SALEM;
NADEEM, 2018).
31
3 Revisão do Estado da Arte
Este capítulo descreve uma revisão literária que utilizará o método exploratório para
conhecer as soluções oferecidas no estado da arte que simpli�cam o processo de desenvol-
vimento de aplicações baseadas em IoT. Também há a pretensão de conhecer os requisitos
que estas soluções atingem bem como os desa�os e oportunidades relatadas pelos pesqui-
sadores. Desta forma, o objetivo deste capítulo é conhecer as tendências que existem no
processo de desenvolvimento baseado em IoT, bem como o de explorar as soluções do
estado da arte que objetivam a simpli�cação do desenvolvimento de aplicações IoT.
A revisão a que este capítulo se propõe, foi conduzida de maneira exploratória, que
segundo Zanella (ZANELLA, 2006), trata-se de uma pesquisa que tem como �nalidade
acrescer o que se conhece de um determinado fenômeno. Desta maneira, a revisão utilizou
a pesquisa exploratória sistematizando alguns aspectos, de modo a ampliar a organização
do processo de pesquisa.
Este capítulo está organizado em 3 seções, a seção 3.1 trata da metodologia seguida
na revisão do estado da arte, e é subdividida em 4 subseções: O planejamento, a string de
busca, as fontes de pesquisa, a execução da revisão e o processo de seleção e a extração dos
resultados. A seção 3.2 buscará remontar as questões de pesquisa visando respondê-las
baseando-se nos resultados obtidos da execução da revisão, por �m, a seção 3.3 discutirá
tais resultados visando sintetizar e organizar o conhecimento obtido.
3.1 Metodologia
Esta seção descreverá todos os passos que foram seguidos para a realização da revisão
do estado da arte, passos estes que foram sistematicamente divididos em planejamento,
string de busca, fontes de dados, execução do protocolo, processo de seleção e por �m,
processo de extração dos resultados.
32
3.1.1 Planejamento
O processo de planejamento se propõe a de�nir a �nalidade da revisão do estado da
arte. Desta forma, baseado no seu objetivo foram de�nidas três questões de pesquisa (QP)
norteadoras:
• QP1 - Quais os tipos de soluções e abordagens existentes para simpli�cação do
desenvolvimento de aplicações IoT?
• QP2 - Quais requisitos são endereçados pelas soluções identi�cadas?
• QP3 - Quais são os desa�os e oportunidades para desenvolver soluções que simpli-
�quem o desenvolvimento de aplicações IoT?
3.1.2 String de Busca
A de�nição da string de busca foi baseada nos objetivos da revisão do estado da
arte e utilizou-se de termos constituintes que buscassem re�nar os resultados, tais termos
combinados resultaram na seguinte string:
("IoT � OR "Internet of Things") AND ("Framework � OR "API ") AND ("Develop-
ment� AND ("Easing� OR "Enabling� OR "Easy� OR "Enable")))
3.1.3 Fontes de Busca
Para a obtenção dos trabalhos realizados no estado da arte, uma busca foi realizada
no repositório Scopus da Elsevier, este é responsável por indexar os repositórios mais
importantes e relevantes da computação e engenharia (Vide Tabela 1). Devido a seu grau
de importância, os artigos retornados possuem alta probabilidade de relevância para a
revisão.
Tabela 1: Repositórios de BuscaFonte Endereço
IEEExplorer http://ieeexplorer.ieee.orgACM Digital http://dl.acm.orgScience Direct http://www.sciencedirect.comWeb of Science http://webofknowledge.comSpringer http://link.springer.com
33
3.1.4 Execução da Revisão
Uma vez de�nidos a string de busca e as fontes de pesquisa, o processo de execução
buscou utilizar tais elementos para retornar os trabalhos que pudessem ser relevantes para
as questões levantadas na fase de planejamento. Desta forma, a string foi executada no
repositório Scopus da Elsevier e todos os artigos que não estavam disponibilizados gratui-
tamente ou que não fossem escritos em inglês foram descartados. Trabalhos considerados
capítulos de livros e tutoriais também foram desconsiderados.
A execução desta fase resultou em um total de 163 artigos que foram dispostos em
uma planilha e indexados para um maior controle, destes, 17 foram desconsiderados por
tratarem-se de capítulos de livro, tutoriais, ou não possuíam relação com as questões
planejadas na seção 3.1.1. Sendo assim, apenas 146 artigos foram considerados para a fase
de seleção.
3.1.5 Processo de Seleção
O processo de seleção trata-se de um re�namento dos resultados primários obtidos na
execução da string nos repositórios de busca. Este processo visa descartar todos os artigos
que não respondem as questões de pesquisa propostas na fase de planejamento ou não se
enquadram de algum modo no objetivo da revisão.
O resultado da execução, assim como evidenciado na subseção anterior, retornou 146
trabalhos válidos que foram lidos pelo autor deste trabalho no período de dois meses,
entre Novembro e Dezembro. Essa etapa foi dividida em três iterações: A primeira foi a
leitura dos títulos, resumos e palavras chaves, os artigos que não foram excluídos nesta
fase passaram por uma segunda iteração de leitura que compreendia a introdução e a
conclusão dos mesmos, os aprovados, passaram por uma leitura completa, sendo esta a
última iteração. Os resultados deste processo são explicitados na Tabela 2.
Tabela 2: Iteração de LeiturasFase Leitura Qtd. de Artigos1o Fase Títulos, resumos e palavras-chave 1462a Fase Introdução e Conclusão 633a Fase Leitura Completa 30
34
3.1.6 Extração dos Resultados
O processo de extração foi realizado nos artigos que passaram da 3a fase (Leitura
Completa) na fase de seleção. Todos os artigos desta fase foram adicionados a uma planilha
do Google que foi preenchida com base nas leituras de cada artigo com dados que pudessem
facilitar uma análise mais detalhada dos resultados. A planilha está disponível através do
endereço: https://goo.gl/Koaykx
3.2 Resultados
Esta seção discute os resultados que foram extraídos da execução do protocolo da
revisão do estado da arte proposto nos capítulos anteriores visando responder as questões
de pesquisa que foram elaboradas na subseção 3.1.1.
Figura 7: Fontes de Dados
Assim como mencionado no processo de seleção, descrito na subseção 3.1.5, 30 artigos
foram analisados inteiramente e algumas informações pertinentes puderam ser quanti�-
cadas. Dentre elas, pode-se observar que 58,1% dos artigos de interesse foram publicados
em conferências, seguidos de 41,9% publicados em Journals (Vide Figura 8). Também é
possível perceber através da Figura 7 que a grande maioria dos artigos de interesse bus-
cados nas fontes de dados descritas na subseção 3.1.3 foram encontrados na IEEExplorer
(61,3%) seguidos da Springer (19,4%), e Elsevier (9,7%).
A Figura 9 ilustra que a área de pesquisa de interesse desta revisão encontra-se estável
quanto ao número de publicações que vinha crescente desde 2014(6) até 2016(8). O fato
de apenas 7 artigos serem selecionados como pertinentes à revisão no ano de 2017 não
35
Figura 8: Veículos de Publicação
representa qualquer queda no número de publicações gerais voltadas à área de pesquisa,
visto que os artigos foram buscados em Novembro, podendo haver novas publicações até
o �m do referido ano.
Figura 9: Número de publicações por ano
Após o levantamento prévio dos resultados obtidos do processo de execução, as ques-
tões elaboradas na fase de planejamento foram respondidas fundamentado-se nas leituras
consideradas na fase de seleção desta revisão.
3.2.1 Análise da QP1
A QP1 desta revisão, tem como objetivo encontrar no estado da arte, os tipos de
soluções e abordagens, ou metodologias que visem simpli�car ou facilitar o processo de
desenvolvimento de aplicações IoT.
36
Figura 10: Tipos de soluções encontradas
No sentido de atingir o objetivo desta questão, as leituras mostraram-se promissoras
e dos 30 trabalhos que foram analisados por completo, 28 retornaram soluções que visam
facilitar alguma especi�dade do desenvolvimento de aplicações IoT. Contudo, algumas
soluções visam cenários bem especí�cos e geralmente atingem requisitos isolados, sem
preocuparem-se com a totalidade do desenvolvimento.
A Figura 10 ilustra os tipos de soluções que foram retornadas pelos artigos lidos,
das soluções propostas, a maioria (50,0%) concentra-se em oferecer Frameworks com a
�nalidade de auxiliar o processo de desenvolvimento de ambientes IoT, seguidos de 23,3%
das propostas que objetivam oferecer Plataformas como solução, 13,3% voltadas à soluções
MDD (Model Driven Development), por �m, uma proposta de arquitetura (3,3%). Alguns
trabalhos não especi�caram a solução, ou simplesmente não ofereceram nenhuma solução
para os problemas abordados em suas pesquisas, eles foram categorizados na Figura 10
como "Não Especi�cados� e representam 10% das soluções, num total de 3 trabalhos.
Dentre os trabalhos destacados, foi possível observar que há uma tendência na adoção
das várias abordagens focadas na simpli�cação do desenvolvimento IoT, elas representam
as estratégias que foram adotadas pelos autores em suas soluções. As abordagens foram
categorizadas na Figura 11, demonstrando que as mais adotadas pelas soluções encontra-
das são as de Abstração (40%), API's de Serviços (13,3%) e Nuvem (10%). Uma boa
parte dos trabalhos revisados não especi�caram a abordagem (26,7%) que utilizaram em
suas soluções.
As abordagens consideradas como Abstração compreendem técnicas que buscam abs-
trair recursos dos cenários de IoT, virtualizando-os, tornando-os legíveis, padronizados,
e que podem ou não utilizar recursos de programação. Os exemplos considerados são:
37
Figura 11: Abordagens mais utilizadas
Anotações semânticas, geradores de código, representações grá�cas, etc. A abordagem
de�nida como API de Serviços compreendem as estratégias que utilizam padrões REST
e/ou CoAP em suas comunicações.
As demais abordagens categorizadas como Nuvem, Prototipação, e Integração Mobile
focam suas soluções respectivamente, buscando integrar suas estratégias com recursos
na nuvem através de plataformas especí�cas, utilizam recursos grá�cos e modelos para
prototipar cenários de IoT prévio ao desenvolvimento, visando um planejamento detalhado
e preciso, e por �m, estratégias voltadas a utilizarem os dispositivos móveis como recursos
de borda, ou dispositivos sensores pertencentes à aplicação.
3.2.2 Análise da QP2
A QP2 desta revisão tem como objetivo identi�car nas soluções propostas pelos au-
tores quais requisitos foram atingidos por suas propostas.
As leituras evidenciaram muitos requisitos que os autores destacaram como sendo
críticos no processo de desenvolvimento e implantação de aplicações IoT. Algumas soluções
atendem a mais de um requisito, contudo, a grande maioria concentra-se em requisitos
isolados, criando meio de solucioná-los e simpli�car o desenvolvimento que o afeta.
A Figura 12 representa os requisitos que foram abordados pelos trabalhos analisa-
dos. É possível observar que a grande maioria das propostas lidam com interoperabili-
dade (36,7%), tal requisito representa a capacidade dos dispositivos comunicarem-se de
maneira padronizada uns com os outros, o requisito é citado como sendo um dos mais
importantes da área de IoT, seguidos de heterogeneidade (13,3%), que está geralmente
38
Figura 12: Requisitos atingidos pelas propostas
associado ao massivo número de dispositivos com capacidades distintas de comunicação,
processamento, armazenamento, e de serviços. Como terceiro maior requisito atingido, es-
tão as propostas que focam em múltiplos requisitos, buscando atender a todos em alguma
escala, objetivando atingir uma maior facilidade de desenvolvimento (10%).
Os dados levantados fortalecem os apontamentos considerados por Tayur e Suchithra
(TAYUR; SUCHITHRA, 2017) que trata a interoperabilidade como sendo um dos desa�os
mais críticos do cenário IoT. As discussões centrais do trabalho de Tayur e Suchithra
(TAYUR; SUCHITHRA, 2017) direcionam-se à união das abordagens sugeridas no estado da
arte, pois o mesmo acredita que devido a grande variedade de protocolos existentes que
consequentemente conduziu alianças fornecedoras a buscarem soluções diversas para pro-
blemas similares, criou-se certa incompatibilidade entre as soluções desenvolvidas. Dentre
as soluções citadas pelo autor estão o AllJoyn e o oneM2M (M3 Framework).
O trabalho de Data e Bonnet (DATTA; BONNET, 2016), propõe um framework mo-
dularizado, denominado DataTweet, cujo objetivo é a simpli�cação do processo de de-
senvolvimento de aplicações IoT. Embora tenha voltado seu foco para o requisito de
produtividade, os autores também citam limitações, do ponto de vista dos requisitos,
que são muito comuns em aplicações descritas na literatura. Dentre os requisitos citados
destacam-se: interoperabilidade, modularização, segurança, dentre outras. O trabalho do
autor supracitado foi tratado como produtividade visto que os requisitos elencados pelo
mesmo são endereçados de maneira coletiva e integrados para se atingir a produtividade.
Um outro requisito pouco explorado pela literatura selecionada nesta revisão foi a
autonomia das "things", que na Figura 6 foi tratado apenas por Hernandez (HERNÁN-
DEZ; REIFF-MARGANIEC, 2016) junto ao requisito de interoperabilidade. Seu trabalho
39
centralizou sua proposta em que objetos inteligentes constituintes do cenário deveriam
ter embutidos em si, engenharia baseada em autonomia, ou seja, cada dispositivo deve
tomar decisões e modi�car lógicas de aplicação de acordo com as entradas capturadas.
Uma síntese das soluções exploradas nesta questão e os requisitos atingidos pelas
mesmas podem ser visualizadas no Apêndice A deste trabalho.
3.2.3 Análise da QP3
A QP3 desta revisão tem como objetivo identi�car as oportunidades e desa�os que
foram expostos nas leituras realizadas. Para tal, foram observados os trabalhos futuros e
limitações que foram expostos pelos autores.
Para esta questão, as leituras não foram tão promissoras, pois boa parte dos trabalhos
não apresentaram desa�os, limitações ou possíveis oportunidades de seus experimentos e
estudos (71% dos trabalhos). A maioria foca apenas nas características das soluções e nos
casos de uso. É importante salientar que os trabalhos revisados não especi�cam bem o
que são desa�os e oportunidades, visto que alguns desa�os são considerados potenciais
oportunidades que podem bene�ciar o contexto das aplicações IoT.
Dos casos que abordaram algum desa�o e/ou oportunidade no desenvolvimento de sua
pesquisa e nos experimentos abordados, destacam-se as propostas de Mehta (MEHTA et
al., 2017), Patel (PATEL; CASSOU, 2015) e Nastic (NASTIC; TRUONG; DUSTDAR, 2015) que
colocaram como características desa�adoras a adaptação e adição de recursos em tempo
real nos cenários (aplicações), sem a necessidade de atualização ou recompilação da apli-
cação, estas características são tratadas por Nastic (NASTIC; TRUONG; DUSTDAR, 2015)
como adaptabilidade, consideradas comuns nestes cenários. O trabalho de Patel (PATEL;
CASSOU, 2015) ainda enfatiza questões problemáticas voltadas à metodologias de teste
em aplicações IoT, que embora sejam necessárias, encontram-se escassas na literatura.
Os desa�os elencados por Venckauskas (VEN�KAUSKAS et al., 2016) e Paganelli (PA-
GANELLI; TURCHI; GIULI, 2016), são voltados especi�camente para as soluções propostas
pelos mesmos, visando otimizar o uso de suas linguagens modelo, estender seus experi-
mentos para lidarem com múltiplos domínios e diminuir a complexidade de automação
que suas soluções oferecem.
Em resumo, os desa�os e oportunidades que o cenário de desenvolvimento de aplica-
ções IoT oferece, partindo da análise da literatura retornada na execução desta revisão
foram os seguintes:
40
• Adaptabilidade: Capacidade das aplicações adicionarem novos recursos sem a ne-
cessidade de recompilação.
• Metodologias de Teste: Metodologias ou ferramentas capazes de diminuir as
potenciais falhas de aplicações IoT.
• Aplicações de múltiplos domínios: A literatura é forte em domínios especí�cos
e voltados à tecnologias isoladas, ocorrendo assim a necessidade de aplicações que
se adaptem à múltiplos domínios e tecnologias.
• Diminuição da complexidade: Devido à aplicações IoT demandarem múltiplos
conhecimentos (desenvolvimento de software, sensores, infraestrutura, etc), é desa-
�ador a existência de uma ferramenta que abstraia as complexidades voltadas aos
recursos de suas aplicações, tais como sensores, gerenciamento de energia, etc.
3.3 Discussões
Esta sessão tem como objetivo fazer uma análise dos resultados atingidos por esta
revisão, buscando sintetizar os conhecimentos e tendências observadas nas respostas das
QPs.
Figura 13: Objetivos das soluções encontradas
Foi possível observar através de uma análise mais geral, que a grande maioria dos
trabalhos, embora possuam abordagens facilitadoras, estão focados de maneira bem es-
pecí�ca em requisitos isolados. A Figura 13 ilustra que 83,3% dos trabalhos possuem essa
característica, em um total de 25 trabalhos. Sendo assim, eles não mencionam quaisquer
estratégias de integrar os desa�os do cenário de IoT. Desta forma, apenas 10,0% estão
41
focados em atingir os múltiplos requisitos das aplicações IoT, o termo "múltiplos� não
implica dizer que tratam de todos os requisitos desejáveis das aplicações IoT, mas que
objetivam atingir mais de um requisito e os integra em uma mesma aplicação.
Embora as estratégias isoladas apresentem soluções e�cazes para os requisitos que
estão endereçados, para que haja uma real contribuição no sentido de atingir a totalidade
das aplicações IoT, acreditamos que seja necessário buscar uma estratégia integradora
onde a maior parte dos requisitos necessários possam ser atingidos e integrem-se nas so-
luções propostas. A literatura tem demonstrado que tais soluções isoladas de requisitos
geralmente não são compatíveis com outras soluções também isoladas, e essa heterogenei-
dade não é algo interessante para o avanço no sentido de alcançar a plenitude de aplicações
IoT. Tais apontamentos são também evidenciados por Tayur (TAYUR; SUCHITHRA, 2017)
em suas análises mencionadas na seção 3.2.2.
Pode-se observar no trabalho de Carranza (CARRANZA-GARCÍA et al., 2016), uma
abordagem promissora voltada a tornar os serviços da aplicação IoT parte da nuvem,
embora a solução seja interessante, os aspectos voltados a escalabilidade e latência, que
são comuns em sistemas distribuídos desta natureza não são citados no trabalho. Já
a proposta de Datta (DATTA; BONNET, 2016) objetiva um framework muito promissor
no sentido de produtividade e simplicidade do desenvolvimento, o desacoplamento das
funções básicas de IoT com a lógica da aplicação possui um característica muito relevante
no sentido de tornar a aplicação modular, mas a descrição do framework é muito super�cial
quanto à aplicabilidade técnica efetiva, pois omite detalhes técnicos que são importantes,
tais como: A associação dos dispositivos/serviços físicos à CSE (Common Service Entity),
e todas estas questões fazem com que a proposta possua uma abordagem dotada de pouca
praticidade.
Algumas propostas apresentam soluções MDD bem interessantes do ponto de vista
prático, porém, acreditamos que tais abordagens di�cultam em alguns aspectos o de-
senvolvimento de tais soluções. Destacam-se as exploradas por Pal (PAL; MUKHERJEE;
BALAMURALIDHAR, 2015) que embora apresente um modelo arquiteturalmente rico, não
demonstra detalhes de como os dispositivos poderão trabalhar com os modelos, e Patel
(PATEL; CASSOU, 2015), que introduz uma linguagem própria para a criação dos modelos,
denominada "Srijan Vocabulary", que exigiria certa familiaridade do desenvolvedor com
tal linguagem, neste caso especí�co, acreditamos que o uso de linguagens mais populares
e aceitas pela comunidade sejam mais promissoras, tais como XML ou JSON.
É notável a escassez de ferramentas direcionadas à tecnologias que são fortemente
42
adotadas pela comunidade de desenvolvimento para aplicações IoT, os frameworks em sua
maioria não são direcionados à tecnologias especí�cas ou descrevem dialetos próprios para
o desenvolvimento, os trabalhos revisados apresentam mais detalhes de nível arquitetural
e �uxos de execução bem especí�cos, e geralmente os protótipos buscam poupar detalhes
técnicos que podiam ser relevantes para análises e validações mais precisas.
Acreditamos que exista a necessidade de uma ferramenta que utilize a expertise dos
desenvolvedores para lidar com aplicações voltadas a IoT. Além da própria popularidade
de certas tecnologias aceitas, o conhecimento do desenvolvedor aceleraria o processo de
desenvolvimento de maneira signi�cativa.
A literatura explorada pela revisão pouco abordou soluções voltadas à representa-
ção programática desses dispositivos, em outra palavras, sensores, atuadores, e quaisquer
componentes constituintes da aplicação poderem ser representados como classes e objetos.
Desta forma, a aplicação poderia utilizar-se de métodos próprios de linguagens conhecidas
para seu gerenciamento, de maneira que toda a semântica inerente a cada componente
pudesse ser abstraída por essas classes, e o desenvolvedor focasse apenas no conhecimento
que detém da linguagem ou tecnologias utilitárias utilizadas.
Tal abordagem considera a representação programática de dispositivos como uma das
etapas do desenvolvimento de aplicações desta natureza. Sendo assim, cada objeto repre-
sentando um dispositivo, conteria os serviços, descrições básicas, identi�cação e outras
informações que pudessem ser relevantes e acessíveis por métodos ou classes de gerencia-
mento.
Um dos trabalhos que buscaram tal abordagem foi o desenvolvido por Bocchino (BOC-
CHINO; FEDOR; PETRACCA, 2015), muito embora sua abordagem acabou omitindo deta-
lhes importantes tais como: o processo de associação dos dispositivos com o framework, e
também o fato da utilização de funções básicas dos dispositivos junto da lógica de aplica-
ção apresentar um forte acoplamento que pode ser visto como algo prejudicial do ponto
de vista da manutenabilidade e extensibilidade da aplicação.
Desta forma, acreditamos que soluções que abordam uma separação de responsabili-
dades, similar à exigida por Patel (PATEL; CASSOU, 2015), mas que abstraia de maneira
explícita os dispositivos que estão contidos na aplicação pode ser considerada promissora.
Tal abordagem não pouparia detalhes técnicos relevantes voltados ao funcionamento real
da solução. Tais soluções devem também buscar estratégias de resolução de requisitos
críticos de heterogeneidade e interoperabilidade, e utilizar-se de padrões e tecnologias que
aproveitem a expertise dos desenvolvedores, facilitando assim, o processo de desenvolvi-
43
mento.
44
4 Um framework para facilitar o
desenvolvimento de aplicações
baseadas em IoT
O processo de desenvolvimento de aplicações baseadas IoT é caracterizado por um
conjunto de múltiplas habilidades combinadas, que estão voltadas a domínios bem especí-
�cos, a citar: infraestrutura, programação, sistemas embarcados, protocolos de comunica-
ção, serviços especí�cos, etc (PATEL; CASSOU, 2015). Tal natureza multi-disciplinar e he-
terogênea desencadeia demasiada complexidade e demorado processo de desenvolvimento
para lidar em conjunto com todos estes aspectos, surgindo a necessidade de metodolo-
gias e ferramentas que possam sanar limitações que são consequentemente criadas destas
características (PATEL; CASSOU, 2015).
Desta forma, o desenvolvedor destas aplicações necessitará focar em múltiplos conhe-
cimentos para o processo de desenvolvimento, pois cada dispositivo pode adotar alguma
especi�dade técnica que exigirá do desenvolvedor técnicas complexas para lidar colaborati-
vamente com esse conjunto de dispositivos. Os aspectos heterogêneos observados incluem
suas capacidades (sensores de umidade, temperatura, luminosidade, etc.), comunicação
(Bluetooth, ZigBee, Wi-�), representação de dados (PERERA et al., 2014), ou qualquer
outra característica que possa ser exclusiva ao mesmo, exigindo demasiado esforço para
torná-los comunicáveis entre si e aptos a operarem um contexto de aplicação IoT.
O capítulo anterior apresentou uma revisão exploratória na qual pode-se ter conheci-
mento do atual estado da arte no tocante à ferramentas facilitadoras no desenvolvimento
de aplicações IoT. Desta forma, constatou-se como um dos grandes desa�os, a existência
de ferramentas que pudessem reduzir a complexidade de desenvolvimento inerente à apli-
cações IoT. Além disso, também foi possível identi�car que uma considerável parte das
soluções são frameworks que utilizam estratégias baseadas em abstração de dispositivos
para várias formas de representação (Modelos, Serviços, Grá�cos, etc.), sendo tais escolhas
consideradas, a partir da análise da revisão, ideiais para o problema em questão.
45
Sendo assim, a notável necessidade de ferramentas que possam reduzir a complexidade
do desenvolvimento destas aplicações, abstraindo a heterogeneidade comum supracitada,
motivou e direcionou a presente proposta. Nossa proposta poderá, nesse ínterim, realizar
etapas essenciais como descoberta dos dispositivos na rede e comunicação entre eles sem
necessidade de preocupar-se com especi�cidades funcionais de cada tipo de dispositivo.
O objetivo do framework proposto neste trabalho é de facilitar o processo de desen-
volvimento de aplicações baseadas em IoT. Ele buscará abstrair a heterogeneidade co-
mum dos dispositivos existentes, favorecendo um ambiente em que o desenvolvedor possa
apenas focar no desenvolvimento da lógica de aplicação, desconsiderando conhecimentos
especí�cos da cada tipo de dispositivo.
Como um passo importante para a realização dessa proposta, a virtualização dos dis-
positivos que estão envolvidos na solução IoT é essencial. Ela garantirá certa harmonização
e facilidade de comunicação entre as entidades, representando-as através de procedimentos
e abordagens uni�cadas e consequentemente mais simples (FERRERA et al., 2017). Através
desta abordagem, capacidades necessárias à proposta, voltadas à comunicação e gerenci-
amento de lógica de aplicação de forma simpli�cada tornam-se passos menos complexos.
Este capítulo está organizado em cinco sessões, a 4.1 discorre sobre o cenário motivador
em que nossa proposta poderia ser utilizada, a 4.2 discorre sobre a arquitetura proposta
para o framework, a 4.3 discorre sobre como os dispositivos se comunicarão com o auxílio
do framework proposto, a 4.4, trata de descrever como o framework �cará disposto de
maneira operacional em uma possível aplicação. Por �m, a 4.5 descreve como o framework
foi desenvolvido, os procedimentos utilizados para instanciá-lo e estendê-lo.
4.1 Cenário de Exemplo: Controle de temperatura
Para exempli�car a utilidade do framework que está sendo proposto por este traba-
lho, um cenário típico que pode ser utilizado é de um cômodo, que possua um controle
de temperatura. A sala seria composta por um sensor de temperatura que mediria a tem-
peratura, e um termostato que regularia a temperatura do ambiente. Ambos possuiriam
protocolos de comunicação distintos: O sensor é UPnP, e o termostato funcionaria à base
de Bluetooth.
Os componentes envolvidos nesse cenário possuem protocolos e capacidades diferentes
que di�cultam sua comunicação. Para lidar com o sensor UPnP, será necessário descobri-lo
na rede, conhecer seus serviços e ações, e enviar mensagens para suas variáveis de estado.
46
Figura 14: Aplicação IoT lidando com a heterogeneidade de Dispositivos.
Para o Bluetooth no entanto, será necessário consultar a rede, parear com o dispositivo
escolhido, e após obter a conexão, transmitir os dados necessários, encerrando em seguida
a conexão.
Para realizar tal operação, serão necessários dois módulos lógicos para lidar com cada
um dos protocolos e suas especi�cidades. Neste caso, cada módulo conterá o código ne-
cessário (que deverá ser escrito pelo desenvolvedor) para atender às características e ar-
quitetura de cada protocolo. O desenvolvedor precisará lidar com cada protocolo indivi-
dualmente para que a aplicação alcance efetividade.
A Figura 14 ilustra o cenário supracitado: A aplicação solicita ao módulo UPnP os
serviços disponíveis (1), esta por sua vez envia seus comandos de descoberta à pilha UPnP
(2), e recebe dela os serviços disponíveis para informar à aplicação cliente. De posse dos
serviços, a aplicação pode descobrir a temperatura (4), e receber do módulo um formato
JSON contendo seu valor (6).
Após a veri�cação do valor da temperatura, a aplicação identi�cou que a mesma está
acima do desejado, então inicia sua comunicação com o módulo Bluetooth (protocolo do
atuador) para modi�car o estado da temperatura. Para isso, é necessário obedecer os
passos exigidos do protocolo: Buscar o termostato (7), ao encontrá-lo na rede, parear com
o mesmo (9), de modo que o protocolo nos conceda uma conexão válida com o dispositivo
para a comunicação, e en�m enviarmos a temperatura adequada (11), que na solução
exemplo é 20oC.
As operações necessárias executadas no exemplo, exigiriam demasiado esforço do pro-
cesso de desenvolvimento, especialmente pela natureza heterogênea da aplicação. Desta
forma, há a necessidade de compreender como cada dispositivo opera e quais são as suas
capacidades de serviço, como são implementados, como podem ser acessados e con�gu-
47
rados remotamente, e tais questionamentos possuem respostas bem diferentes para cada
dispositivo. Tal di�culdade exige grande esforço de desenvolvimento para lidar com todos
os protocolos envolvidos.
Nossa proposta, cujo objetivo é tratar os dispositivos heterogêneos de maneira uni�-
cada e homogênea, buscará auxiliar a integração destes dispositivos heterogêneos, dimi-
nuindo o esforço de desenvolvimento da aplicação. O problema da Figura 14, utilizando
a nossa abordagem, é ilustrado na Figura 15.
Figura 15: Aplicação IoT utilizando o framework para simpli�car o desenvolvimento.
Os componentes da aplicação serão abstraídos como dispositivos virtuais na lógica
de aplicação, com propriedades e comportamentos de�nidos em um modelo virtualizado
único. Desta forma, os sensores de temperatura e o termostato serão considerados dispo-
sitivos virtuais dotados de métodos de interação com seus respectivos dispositivos reais,
de maneira que as especi�dades funcionais de cada um deles sejam abstraídas e tratadas
pelo framework.
As suas capacidades serão abstraídas a partir de drivers que estão incluídos no fra-
mework. Esses drivers, ao serem adicionados no framework, tornam-se Proxies que sabem
lidar com as capacidades individuais de cada protocolo, e consequentemente tornam o
framework capaz de realizar as operações necessárias nos dispositivos que eles atendem.
Neste caso especí�co, os Proxies UPnP e do Bluetooth necessitariam estar adicionados na
estrutura do framework.
Na Figura 15, podemos notar uma expressiva diminuição de passos para realizar o
objetivo da aplicação cliente, neste novo modelo de aplicação, o framework descobrirá(1)
e registrará nele(2) todos os dispositivos na rede (de acordo com os proxies que possui)
como tarefa inicial. Em seguida, todos os dispositivos encontrados se tornarão dispositivos
virtuais, possuindo métodos capazes de comunicarem-se com seus dispositivos reais e ocul-
48
tando suas características especí�cas do ponto de vista da aplicação cliente. Desta forma,
a aplicação cliente poderá descobri-los, independente do protocolo utilizado, solicitar da-
dos aos dispositivos que desejar (4 e 5); Este caso especí�co solicita a temperatura ao
sensor e envia a nova temperatura ao termostato, recebendo ao termino destas operações,
um formato JSON padronizado com as respostas das possíveis requisições.
4.2 Arquitetura Proposta
Está seção descreve detalhadamente a arquitetura para o framework proposto por
este trabalho, sendo assim, será exposto a visão geral da arquitetura proposta e como
seus componentes constituintes estão estruturados.
4.2.1 Visão Geral
A Figura 16 ilustra a visão geral da arquitetura proposta para o framework. A ar-
quitetura foi proposta de maneira centralizada e está considerando as operações básicas
e elementares de aplicações baseadas em princípios IoT de modo a haver uma interação
correta entre o framework e os dispositivos físicos presentes na aplicação. As operações
consideradas na arquitetura foram: Registro, atualização de status, e descoberta de dis-
positivos.
Figura 16: Visão geral da Arquitetura
A operação de registro torna o dispositivo conhecido ao framework, registrando-o
no Gerenciador de Dispositivos, de modo a considerá-lo, a partir do seu registro, como
entidade virtualizada a ser utilizada na lógica de aplicação. Este processo ocorre imedi-
atamente após a descoberta do dispositivo físico pelo Tradutor Proxy, tal processo será
49
descrito em maiores detalhes nas seções posteriores.
A operação de atualização de status ocorre periodicamente para evitar que algum
dispositivo inoperável possa estar sendo disponibilizado no framework, em casos de ino-
perabilidade, este será removido do Gerenciador de Dispositivos e desconsiderado pela
operação de descoberta do mesmo. Todo este processo é coordenado pelo Módulo Health
(Vide Seção 4.2.5).
A operação de descoberta de dispositivos ocorre em dois momentos: O primeiro durante
o processo de descoberta do Tradutor Proxy que encapsulará cada dispositivo descoberto
em uma instância de Dispositivo Virtual. O segundo momento ocorre quando é invocado
pela aplicação cliente através dos métodos de descoberta do Gerenciador de Dispositivos,
neste segundo, os dispositivos retornados no processo de descoberta já serão dispositivos
virtualizados.
A arquitetura é basicamente estruturada em três camadas: A camada de Dispositivos
Físicos, que concentra todos os dispositivos reais que estão contidos na solução baseada
em IoT, suas capacidades individuais de processamento e comunicação. Logo acima, está
a camada denominada Tradutor Proxy, nesta estão dispostos os drivers dos protocolos
de comunicação inerentes aos dispositivos existentes na infra-estrutura da solução, cada
driver implementa uma interface comum que o representará como um Proxy válido para
o framework. Esta camada é responsável por tornar os dispositivos comunicáveis e reco-
nhecidos no framework, buscando reduzir os impactos de protocolos heterogêneos.
Por �m, a camada mais alta da arquitetura concentra a ideia principal do framework.
É a camada responsável pela abstração dos dispositivos físicos e dos processos de comu-
nicação que os constituem. Esta camada é dividida em quatro componentes: Dispositivo
Virtual, Servidor CoAP, Gerenciador de Dispositivos e Modulo Health, tais componentes
serão explicados em maiores detalhes na seções seguintes.
4.2.2 Dispositivo Virtual
Uma dispositivo virtual é uma representação virtualizada do dispositivo físico pre-
sente no contexto da infra-estrutura da solução IoT. Este encapsulará as capacidades do
dispositivo físico de modo a que elas possam ser oferecidas à aplicação cliente através
de métodos padronizados. Virtualizar um dispositivo garantirá uniformidade na manipu-
lação dos mesmos durante o processo de desenvolvimento da lógica de aplicação, visto
que todos os dispositivos, independentemente de suas características individuais, serão
50
representados através desta virtualização.
Figura 17: Estrutura do dispositivo virtual.
A Figura 17 representa a estrutura interna de um Dispositivo Virtual, este é com-
posto por dois grupos de componentes: O primeiro grupo (Comunicação) representa os
componentes essenciais para comunicação do Dispositivo Virtual com seu Dispositivo real,
o segundo grupo (De�nição), representa os atributos que de�nem (identi�cam) o Dispo-
sitivo Virtual no framework.
4.2.2.1 Componentes de De�nição
Os componentes de de�nição estão concentrados em de�nir os atributos que identi-
�cam unicamente o dispositivo virtual no framework, armazenando os metados que os
de�nem no mundo físico. São compostos da seguinte forma:
• Identi�cação: Armazena no Dispositivo Virtual as informações que o identi�cam
unicamente no framework. As informações que podem ser consideradas como parte
da Identi�cação de um dispositivo incluem: ID único, tipo de dispositivo, descrição
nominal do dispositivo, fornecedor, versão, etc;
• Recursos: Representa uma descrição nominal de um grupo de tarefas que pode ser
realizada por um dispositivo, tais como: Controlar Temperatura, Controlar Energia,
etc. Um Recurso pode possuir uma ou várias ações.
• Ações: Representa uma descrição nominal de cada tarefa que pode ser realizada pelo
dispositivo, tais como: Desligar Luz, Ligar Luz, Veri�car Status da Temperatura,
etc. Cada ação pertence obrigatoriamente a um Recurso.
51
4.2.2.2 Componentes de Comunicação
Os componentes de comunicação são utilizados para estabelecerem a comunicação
entre a virtualização (Dispositivo Virtual) e o seu Dispositivo real. Estão dispostos da
seguinte forma:
• Recurso CoAP: Trata-se de uma representação de uma Ação através de uma
URL nos padrões exigidos pelo Protocolo CoAP, como exemplo: Se temos uma ação
nomeada como Veri�car Status Temperatura, teremos um Recurso CoAP nomeado
como coap://0.0.0.0/01/Veri�carStatusTemperatura. Onde 01 é o identi�cados do
dispositivo descoberto.
• Cliente CoAP: Um Cliente CoAP representa uma instância que consegue se co-
municar com os Recursos CoAP válidos no Servidor CoAP. Desta forma, quando
o dispositivo deseja requisitar alguma ação, ele utilizará o Cliente CoAP para isso,
passando para este o Recurso CoAP desejado.
• Proxy: Representa uma instância do Proxy que descobriu o seu dispositivo físico
no processo de descoberta realizado pelo Tradutor Proxy.
Todos os Recursos e Ações disponibilizados pelos dispositivos serão abstraídos e ge-
renciados utilizando o protocolo CoAP, que nos oferece uma estrutura cliente-servidor
habilitado para redes e dispositivos restritos. Desta forma, cada ação identi�cada no pro-
cesso de descoberta é transformada em um Recurso CoAP e adicionada no Servidor CoAP.
O Servidor CoAP gerenciado pelo framework, será responsável por intermediar toda
a comunicação entre os proxies e seus dispositivos virtualizados. Desta forma, cada cha-
mada à seus métodos de interação iniciará os endpoints responsáveis por cada Recurso no
Servidor CoAP. Um endpoint é um Recurso CoAP representado através da sua URL e os
métodos de interação citados representam procedimentos capazes de realizarem a comu-
nicação entre o dispositivo virtual e o dispositivo físico, estes são de�nidos na interface
comum exigida para um Dispositivo Virtual.
O uso do protocolo CoAP no processo de comunicação com os recursos dos dispo-
sitivos justi�ca-se devido à possibilidade de haver outras aplicações cliente que possam
necessitar usar dos serviços da solução IoT. Estas outras aplicações não necessitariam
obrigatoriamente do framework, desde que conheçam os endpoints que ele disponibilizará.
Tal abordagem diminuiria os impactos da limitação de recursos, pois toda a comunicação
com os recursos se daria através do CoAP.
52
4.2.3 Gerenciador de Dispositivos
O gerenciador de dispositivos é um componente responsável por registrar e manter
armazenados todos os dispositivos descobertos e virtualizados pela camada do Tradutor
Proxy. Ele é o ponto de acesso da aplicação cliente à todos os dispositivos que estão
virtualizados.
Ele possui mecanismos de descoberta dinâmica, onde a aplicação cliente poderá utilizar-
se de semânticas de busca mais abrangentes, tais como: buscar por nome ou parte do nome
do dispositivo, pelo seu identi�cador, pelo seu tipo, etc. Todo dispositivo que não está
registrado no Gerenciador é desconsiderado pelo framework.
4.2.4 Servidor CoAP
O Servidor CoAP, é uma estrutura interna que gerenciará todos os recursos e ações dos
dispositivos descobertos, estes que foram transformados em Recursos CoAP. Tais recursos
possuem uma URL própria de�nida no momento da virtualização e garantem que toda a
comunicação com os recursos do dispositivo se dê através do protocolo CoAP, evitando
situações inesperadas ao lidar com dispositivos e redes restritas.
Os recursos do Servidor CoAP, que representam os recursos e ações dos Dispositivos
da solução IoT podem também ser acessados através dos endpoints fornecidos no momento
da execução do framework, estes endpoints são as URL's acima citadas e podem tanto
retornar informações dos dispositivos quanto modi�car seu estado.
4.2.5 Módulo Health
O módulo Health trata-se de um módulo que veri�cará periodicamente o estado de
"saúde"dos dispositivos da aplicação. Ele será importante visto a necessidade dos dis-
positivos físicos envolvidos na infra-estrutura da solução IoT estarem sempre disponíveis
e em seu funcionamento pleno para que a lógica de aplicação não venha a falhar por
falta de disponibilidade de algum dispositivo. Desta forma, o módulo é responsável por
permanecer em estado de monitoramento de todos os dispositivos que estão registrados,
cancelando o registro daqueles que por ventura não apresentem condições viáveis ou fa-
lhem em responder a alguma solicitação do Módulo Health.
O monitoramento inicia a partir da primeira descoberta de Dispositivos efetuada pelo
Tradutor Proxy. Este monitoramento ocorre através da operação de atualização de status,
53
que periodicamente solicitará a descoberta dos dispositivos na rede, aguardando destes
alguma resposta. Nos casos de negação reincidente, isto é, quando o dispositivo deixa de
responder à solicitação por mais de três vezes, seu registro é cancelado no Gerenciador de
Aplicações, e consequentemente, �ca indisponível nas operações de descoberta. A operação
de atualização de status se repete, após a primeira veri�cação, a cada 30 segundos.
4.2.6 Tradutor Proxy
O Tradutor Proxy trata-se de um componente da arquitetura que estará responsável
por lidar diretamente com os dispositivos físicos pertencentes à aplicação. Ele conterá
os múltiplos drivers de protocolos de comunicação que possibilitarão a comunicação dos
dispositivos virtuais com os dispositivos reais. Proxies representam instâncias de drivers
que são implementados obedecendo a interface exigida pelo Tradutor Proxy. Este módulo
possibilitará o mapeamento entre o dispositivo virtual e o seu respectivo dispositivo físico
nas múltiplas atividades que o framework poderá realizar.
Figura 18: Funcionamento do Tradutor Proxy.
O �uxo de trabalho dessa camada é basicamente voltado aos mecanismos próprios de
cada proxy, de modo que funções tipicas de descoberta de dispositivos na rede, envio e
consulta de dados para cada dispositivo esteja obrigatoriamente implementada e disponí-
vel. Desta forma, o processo de descoberta dos dispositivos desta camada implica que cada
proxy irá realizar seus processos de descoberta e encapsulará por conseguinte os dispo-
sitivos encontrados em Dispositivos Virtuais, registrando em suas respectivas instâncias,
a instância do proxy responsável pela operação, seus recursos e ações que pode realizar.
Recursos e Ações foram explicados em maiores detalhes na seção 4.2.2.
Realizado o encapsulamento dos dispositivos virtuais, ocorre o registro dos Recursos
54
CoAP no Servidor CoAP que é disponibilizado pelo framework. Estes recursos são mape-
ados de acordo com os Recursos e Ações que foram de�nidos na instância do Dispositivo
Virtual no momento de sua descoberta, assim como mencionado na seção 4.2.2. Por �m, os
dispositivos virtualizados são registrados no Gerenciador de Dispositivos para tornarem-se
disponíveis.
Uma outra característica do tradutor proxy, é que novos proxys que podem ser pro-
venientes de novos protocolos ou de novas versões de protocolos ja existentes podem ser
posteriormente adicionados nesta camada, respeitando a interface comum disponibilizada
que exigirá implementação de descoberta, transmissão e envio de dados aos dispositivos,
bem como o registro dos recursos e ações de cada dispositivo virtual no servidor CoAP,
no momento de sua descoberta.
O fato de poder adicionar novos proxies ao tradutor proxy adiciona certa extensibili-
dade ao framework, contudo, para que o framework reconheça o novo proxy, características
voltadas à arquitetura precisam ser atendidas na implementação dos métodos exigidos,
especialmente no método de descoberta, que exigirá a de�nição da descrição do disposi-
tivo, recursos do dispositivo, ações de cada recurso que ele pode realizar, parâmetros das
ações que podem ser modi�cados, possíveis saídas de dados das ações, etc. Tal arquite-
tura foi baseada nos princípios arquiteturais do UPnP1, e são obrigatoriamente exigidas
na implementação dos métodos de descoberta existentes no Proxy.
É importante considerar que alguns protocolos de comunicação não possuem recursos
de alto nível nativos em sua estrutura, tais como a descoberta automática de dispositivos.
Desta forma, para que o proxy esteja em conformidade com a arquitetura, o desenvolvedor
precisará implementar estes recursos adicionais utilizando como base o que o protocolo
pode oferecer.
4.3 Comunicação entre Dispositivos Virtuais
A comunicação entre os dispositivos é representada na Figura 19, e ilustra a forma
como o framework lidará com os Dispositivos Virtuais no processo de execução da aplica-
ção cliente. A comunicação utilizará apenas métodos dos Dispositivos Virtuais, de�nidos
especi�camente para a �nalidade de interação com os Dispositivos reais, os métodos são:
getDataEvent(action) e sendEvent(action, params) e são de�nidos a seguir.
1https://openconnectivity.org/developer/speci�cations/upnp-resources/upnp
55
• getDataEvent(action): Este método é responsável por solicitar alguma informação
de uma determinada ação do dispositivo que invocou o método. A ação representa
o que o dispositivo pode realizar, elas são de�nidas no momento da descoberta dos
dispositivos realizada pela camada do Tradutor Proxy, este processo é descrito na
Seção 4.2.6. O Método getDataEvent sempre deve ser utilizado em ações que retor-
nam alguma informação dos dispositivos, por exemplo: Uma ação que é invocada
para descobrir a temperatura de um determinado sensor.
• sendEvent(action, params): Este método envia dados para o dispositivo. As ações
de�nidas neste caso, são ações que modi�cam o estado dos dispositivos que as invo-
cam, invocar este método não retornará nenhum valor, mas modi�cará o estado do
dispositivo que o invocou, por exemplo: Desligar uma luz de LED.
Figura 19: Estrutura de comunicação entre os dispositivos.
Os Dispositivos Virtuais envolvidos no processo de comunicação precisam ser desco-
bertos pela Aplicação Cliente através do Gerenciador de Dispositivos. Caso algum dis-
positivo solicitado não seja retornado pelo método de descoberta, então signi�ca que ele
não está operável, em outras palavras, disponível para utilização da Aplicação, ou não
foi identi�cado pelo Tradutor Proxy durante a execução dos métodos de descoberta dessa
camada.
Para os Dispositivos Virtuais comunicarem-se com seus Dispositivos reais, são utili-
zados como intermediadores, os Recursos CoAP que foram explicados na seção 4.2.2.2.
Desta forma, quando a aplicação invoca qualquer método de interação dos Dispositivos
Virtuais (getDataEvent ou sendEvent), o método é direcionado para o Recurso CoAP que
representa a ação desejada e por sua vez direciona a chamada do método ao seu Proxy
que também possui um método de interação similar (getData ou send) para que possa
56
executar as ações no Dispositivo real, podendo retornar, ou não, alguma informação para
a aplicação cliente que invocou a ação.
4.4 Operacionalização da Solução
Esta seção descreve como a solução proposta funcionará na prática, descrevendo como
os componentes descritos na seção anterior irão interagir para atingir o objetivo esperado
pelo framework deste trabalho.
A Figura 20 ilustra como o framework estará disposto no processo de desenvolvimento
de uma Aplicação Cliente que utilizará uma solução IoT. Inicialmente o framework irá
descobrir cada Dispositivo na rede, esse passo é desenvolvido pelo Tradutor Proxy des-
crito na seção 4.2.6, o processo de descoberta é especí�co e particular de cada protocolo
implementado como um Proxy. Sendo assim, o framework executará para cada proxy exis-
tente, o seu método de descoberta. Descobrir um dispositivo implicará em encapsulá-lo
em uma instância de Dispositivo Virtual, que consequentemente o fará ter um tratamento
padronizado e único, independente de suas especi�dades funcionais.
O passo de descoberta dos Dispositivos realizado pelo Tradutor Proxy fará com que
o framework tenha consciência da existência dos dispositivos presentes na infraestrutura
da solução IoT, registrando-os no Gerenciador de Dispositivos e dando condições neces-
sárias para o desenvolvimento da Aplicação Cliente, que lidará apenas com Dispositivos
Virtuais e seus métodos padronizados de interação mencionados na seção 4.2.4, tais virtu-
alizações serão acessíveis por métodos de descoberta que são fornecidos pelo Gerenciador
de Dispositivos.
Cada invocação que for feita aos métodos de interação do Dispositivo Virtual (Vide
seção 4.3) irá direcionar a requisição ao Proxy do seu protocolo, que por sua vez se comu-
nicará com seu Dispositivo Real, executando a operação neste e retornando o resultado
para a aplicação cliente. Nesta estrutura, o framework sempre estará apto a captar os
dados que os dispositivos sensores (ex.: temperatura, luminosidade, etc.) podem estar
emitindo ou poderão enviar comandos especí�cos aos dispositivos atuadores (ex.: termos-
tato, controladores de luz, etc.).
Durante o ciclo de funcionamento do framework haverá imediatamente após a desco-
berta dos dispositivos, uma veri�cação do estado operacional dos dispositivos descobertos
e registrados no Gerenciador de Dispositivos. Esta veri�cação é de�nida pelo Módulo He-
alth descrito na seção 4.2.5. Tal veri�cação garantirá que apenas dispositivos operáveis e
57
Figura 20: Estrutura operacional do Framework
disponíveis estejam sendo utilizados pela aplicação cliente.
Desta forma, será possível escrever a lógica da aplicação cliente, lidando apenas com
virtualizações dos dispositivos, de modo que todos sejam acessados através de um único
modelo (Dispositivo Virtual), independentemente de suas especi�dades funcionais (UPnP,
Bluetooth, ZigBee, etc.). O framework disponibilizará os Dispositivos Virtuais à aplicação
cliente a partir do Gerenciador de Dispositivos e toda a comunicação será feita a partir
destas virtualizações.
4.5 Desenvolvimento da Solução
Esta seção descreve como a solução foi projetada para atingir o objetivo proposto
neste trabalho. A solução buscará abstrair as complexidades inerentes à heterogeneidade
dos dispositivos e protocolos, fornecendo virtualizações dos dispositivos com métodos bem-
de�nidos para o uso da aplicação cliente. O protótipo foi projetado utilizando a Linguagem
Java.
4.5.1 Estrutura da Solução
A Figura 21 representa o diagrama de classes da estrutura geral do framework, nela
estão ilustradas as classes que irão compor o framework e como estas interagem para
atingir o objetivo proposto.
É possível perceber que todas as implementações de proxies existentes no framework
devem obedecer a interface IProxy e implementar os métodos essenciais para o funciona-
mento padrão do framework, os métodos exigidos são:
58
Figura 21: Diagrama de Classes da estrutura do Framework
• discoveryAll(): Este método deve realizar a busca dos dispositivos na rede utilizando-
se do proxy do protocolo implementado. Ao descobrir os dispositivos, deve encapsula-
lo em Dispositivos (VirtualDevice). Este processo também contempla a de�nição
dos recursos (Resource) e as ações (actions) que estão sendo disponibilizadas pelos
dispositivos encontrados pelo proxy. Ações e Recursos representam as capacidades
inerentes a cada dispositivo (Vide Seção 4.2.2.1), isto é, tarefas que o Dispositivo
consegue realizar. De�nidos os Resources e actions, seus respectivos Recursos CoAP
(AbstractCoapResource) também o serão, sendo posteriormente adicionados no Ser-
vidor CoAP para tornarem-se disponíveis.
• getData(device: VirtualDevice, action:String): Este método é capaz de solicitar ao
dispositivo físico, através de sua representação virtual (device) informações referen-
tes a uma determinada ação (action).
• send(device:VirtualDevice, action: String, params:Map<String, String>): É o mé-
todo responsável por enviar dados (params) para uma ação (action) de entrada do
dispositivo (device). Estes dados são capazes de modi�car o estado do dispositivo
de acordo com a ação passada por parâmetro. Para os dados enviados, é necessário
uma estrutura de mapeamento que identi�que os parâmetros (params) que recebe-
rão os novos valores, estes parâmetros geralmente são variáveis de estado próprias
de cada dispositivo. Este método é exclusivamente utilizado para modi�car o estado
dos dispositivos. Os parâmetros se tornam conhecidos no processo de descoberta
realizado pelo Proxy.
O Dispositivo Virtual (VirtualDevice) possui dois métodos básicos de interação: get-
DataEvent(action:String) e o sendEvent(action:String, params: Map<String, String>),
59
ambos estão diretamente relacionados com o proxy que o encapsulou. Desta forma, qual-
quer invocação destes métodos irá iniciar os respectivos métodos do proxy, neste caso, o
getDataEvent invocará o getData, e o sendEvent invocará o send de seu proxy.
Contudo, estas invocações serão intermediadas e gerenciadas pelo AbstractCoapRe-
source, que representa um Recurso CoAP no framework. Toda instância do VirtualDevice
encapsulará suas capacidades através de instâncias de Recursos (Resource), elas descre-
vem os serviços que cada dispositivo dispõe para a aplicação, nestes recursos podem estar
descritas as ações que eles são capazes de efetuar. Ações são atividades efetivas que são
realizadas pelo próprio dispositivo (Vide Seção 4.2.2.1), estas podem ser ações de entrada,
que recebem parâmetros e modi�cam seus estados ou ações de saída, que podem enviar
dados do próprio dispositivo a quem as invocou. Os recursos devem ser obrigatoriamente
tratados na implementação dos Proxies.
O VirtualDevice também armazenará instâncias de Recursos CoAP. O framework
abstrai essa característica através da classe abstrata AbstractCoapResource. Esta classe
pode ser especializada em duas outras classes: De entrada de dados (DefaultCoapInpu-
tResource) ou de saída de dados (DefaultCoapOutputResource), ambas são especi�cações
da classe CoapResource da API Californium2. Tal API foi projetada para dar suporte à
comunicações CoAP em Java e é utilizada pelo framework na manipulação do protocolo
CoAP.
Assim como descrito anteriormente, cada grupo de ações é abstraído e encapsulado
em sua respectiva instância de Recurso CoAP (DefaultCoapInputResource ou DefaultCo-
apOutputResource) no processo de descoberta (discoveryAll()) do proxy. Após abstraídos
nestas entidades, são por �m adicionadas no Servidor CoAP que é gerenciado pelo Fra-
mework. O Servidor CoAP é de�nido e iniciado também utilizando-se da API Californium.
Por �m, o Gerenciador de Dispositivos (DeviceManager) registra cada dispositivo
virtual encontrado no processo de descoberta do Proxy e disponibiliza-os através dos
métodos de descoberta dinâmica que ele de�ne em sua estrutura, tais métodos permitem
consultas por parte do nome, identi�cador único, característica (tais como temperatura,
luz, umidade, etc.) e provê também um método capaz de retornar todos os dispositivos
encontrados no processo de descoberta do framework (discoveryAll()).
2https://www.eclipse.org/californium/
60
4.5.2 Instanciação do Framework
Esta seção discorre sobre os passos necessários para a instanciação do framework no
processo de desenvolvimento de aplicações baseadas em IoT. O framework será disponibi-
lizado através de um arquivo compilado Java (.jar) que deve ser adicionado ao classpath da
aplicação IoT. Todo o processo de instanciação ocorrerá através da classe Core, ela é res-
ponsável por métodos que solucionam as dependências necessárias para o funcionamento
do framework.
O método base para a resolução destas dependências é denominado start(). Tal método
deve ser obrigatoriamente invocado antes da utilização dos outros recursos do Framework.
As dependências acima citadas basicamente resumem-se em buscar os proxies existentes na
camada do Tradutor Proxy e veri�car se existem proxies de�nidos por parte da aplicação
cliente.
Figura 22: Con�guração do con�g.properties para de�nir proxies externos ao framework.
Um arquivo deve ser criado no diretório raiz da aplicação cliente, o framework irá
processá-lo para de�nir suas diretrizes de execução, tais diretrizes são ilustradas na Fi-
gura 22. O arquivo citado é denominado con�g.properties e deve conter duas propriedades:
application.proxy.package e ignore.default. A primeira propriedade é responsável por in-
dicar o pacote que conterá os proxies adicionais que foram de�nidos de maneira externa
ao framework. Quando esta propriedade não é de�nida, o framework considerará apenas
os proxies de�nidos por ele mesmo.
A segunda propriedade pode assumir apenas dois valores, yes ou no. Esta propriedade
informará ao framework se ele deve ignorar seus proxies padrão ou deve considera-los
durante o processo de execução da aplicação cliente. Esta rotina foi de�nida para ocasiões
em que o dispositivo que executará a aplicação cliente apresente alguma incompatibilidade
com os proxies já de�nidos nativamente pelo framework, ignorando-os e evitando erros
inesperados. Todo o processo de instanciação do framework é demonstrado no diagrama
de atividade ilustrado na Figura 23.
A Listagem 4.1 demonstra o código necessário para iniciar o processo ilustrado na
Figura 23. Após o processo de resolução das dependências dos proxies, desencadeada
pela invocação do método start() (Linha 1), os dispositivos poderão ser buscados através
do DeviceManager e seus métodos de descoberta, na Listagem 4.1, a descoberta ocorre
61
Figura 23: Instanciação do Framework.
através de parte do nome do dispositivo (Linhas 2 e 3).
1 Core . s t a r t ( ) ;
2 VirtuaDevice s enso r = DeviceManager . d i s cove ry ( " Sensor " )
3 . get ( 0 ) ;
Listagem 4.1: Iniciação do framework e descoberta de dispositivos
1 St r ing rawData = senso r . getDataEvent ( ResourceManager
2 . S en so rSe rv i c e
3 .GET_DATA_SENSOR) ;
Listagem 4.2: Solicitando dados dos dispositivos virtuais
Realizado estas operações, é possível interagir com os dispositivos virtualizados atra-
vés de seus métodos de interação. A Listagem 4.2 demonstra como recuperar os dados
capturados pelo sensor virtualizado. ResourceManager é a classe que mapeia todos ser-
viços e ações de�nidas pelos proxies no processo descoberta do Tradutor Proxy. No caso
da listagem, o método getDataEvent solicita ao sensor a ação GET_DATA_SENSOR do
serviço SensorService e armazena seus dados na variável rawData, os dados são retornados
em formato JSON.
1 VirtuaDevice actuator = DeviceManager . d i s cove ry ( "Actuator " )
2 . get ( 0 ) ;
3
4 HashMap<Str ing , Str ing> newValues = new HashMap<>();
62
5 newValues . put ( ResourceManager . Actuato rSe rv i c e s
6 .NEW_VALUE, "OFF" ) ;
7
8 actuator . sendEvent ( ResourceManager
9 . Actuato rSe rv i c e s
10 .POWER_ACTION, newValues ) ;
Listagem 4.3: Enviando dados para os dispositivos virtuais
A Listagem 4.3 exempli�ca o envio de dados para modi�car o estado de um dispositivo
atuador. Na Listagem citada, é de�nido uma estrutura de mapeamento (Linhas 4 a 6)
na qual o parâmetros identi�cado como NEW_VALUE é modi�cado para "OFF". Em
seguida o método de interação sendEvent é invocado (Linhas 8 a 10), designando os
novos valores mapeados para a ação POWER_ACTION, modi�cando o valor do atuador
recuperado.
4.5.3 Núcleo e Pontos de Extensão
Para o framework proposto há apenas um ponto de extensão considerado, este é
responsável por adicionar novos proxies à camada de Tradutor Proxy do framework. Ele
garantirá que o framework considere além dos proxies que possui em sua estrutura, os
que a aplicação cliente possivelmente necessitará além dos já de�nidos.
4.5.3.1 Adicionando novos Proxies
Para esta característica extensível, o desenvolvedor precisará atentar para três con�-
gurações obrigatórias: A do con�g.properties, mencionada na seção anterior, a anotação
@ProxyTranslate e a implementação da interface IProxy. A anotação @ProxyTranslate é
a identi�cação de que a classe anotada representa um Proxy que deve ser considerado.
A interface IProxy, obriga à classe anotada a implementar os métodos obrigatórios que
serão utilizados no processo do start(). Tais métodos foram explicados na seção 4.5.1. A
forma de como utilizar tal anotação e a implementação da interface é exempli�cada na
Listagem 4.4.
1 @ProxyTranslate ( d e s c r i p t i o n = "UPnP" )
2 public class UPnpProxy implements IProxy
Listagem 4.4: Componentes necessários para a de�nição de um novo proxy na camada
63
Proxy Translate
O framework possui implementado nativamente um proxy capaz de dar suporte à
descoberta e comunicação com dispositivos UPnP. Neste caso, após o método start()
ser invocado por qualquer aplicação cliente, quando as con�gurações de instanciação são
favoráveis, o proxy UPnP é iniciado e virtualizará os dispositivos descobertos pelo mesmo.
Oferecendo após esse processo, meios da aplicação cliente acessá-lo através de métodos
especí�cos de descoberta no DeviceManager (Vide seção 4.5.1).
Figura 24: Sequência de funcionamento do Proxy UPnP.
Na Figura 24 é possível observar que o ProxyUPnP teve seu método de descoberta
(discoveryAll()) invocado pelo contexto do framework (método start()) e todos os dispo-
sitivos descobertos na pilha UPnP foram então encapsulados como VirtualDevices. Após
o processo de encapsulamento, eles foram devidamente registrados (register()) no Devi-
ceManager. Depois destas operações, a Aplicação Cliente terá condições de invocar os
métodos de descoberta disponibilizados pelo DeviceManager e recuperar os dispositivos
de acordo com os parâmetros informados. O retorno destes métodos já são os dispositivos
virtualizados (VirtualDevice).
A partir das virtualizações retornadas pelo DeviceManager é possível utilizar os seus
métodos de interação (getDataEvent(action)) para comunicar-se com os seus respecti-
vos dispositivos físicos. É importante lembrar que as chamadas dos métodos de intera-
ção dos dispositivos virtuais implicam em chamadas à métodos similares no ProxyUPnP
(getData(device, action)) que possuem condições de comunicarem-se com os dispositivos
físicos.
Alguns proxies, no entanto, podem requerer processos intermediários e possuir espe-
64
ci�cações próprias, como exemplo, um Proxy Bluetooth precisa de um processo de parea-
mento entre os dispositivos comunicantes antes de estabelecer-se uma comunicação entre
estes, bem como pode necessitar de API's de manipulações próprias de cada dispositivo
que hospeda o adaptador bluetooth (Android, iOS, etc.). Neste caso, para um dispositivo
Android por exemplo, uma extensão do framework seria necessária para lidar com a API
Bluetooth e as classes e regras de implementação que são próprias do Android.
Figura 25: Sequência de funcionamento do Proxy Bluetooth.
A Figura 25 demonstra como funcionará o Proxy Bluetooth seguindo a arquitetura
proposta pelo framework. O método de descoberta do Proxy será invocado (discoveryAll())
e ele então iniciará o processo de análise bluetooth, tal processo consiste em enviar uma
solicitação aos dispositivos bluetooth visíveis na rede e aguardar que eles respondam. Este
procedimento costuma demorar em torno de 12 segundos. Após a resposta, o proxy deve
identi�car qual dispositivo será utilizado na comunicação e aí então dá-se o processo
de pareamento. Pareados os dispositivos, o processo de virtualização inicia e logo em
seguida a de registro (register()). Toda a dinâmica de comunicação da aplicação cliente
ocorre de maneira similar à demonstrada na Figura 24. Só que nesta ilustração, o método
sendEvent() está enviando uma ação e aguardando que o proxy a execute, e retorne o
booleano evidenciando que o processo foi bem-sucedido.
4.5.3.2 O Núcleo
O núcleo do framework compreende o módulo que detém as funcionalidades que são
utilizadas pela aplicação cliente para a interação direta com o framework. Neste caso, as
classes pertencentes à esse módulo são a Core, responsável por inicializar a camada de
65
Tabela 3: Serviços utilitários fornecidos pelo núcleo do framework.Chamadas Descrição
SampleCoapServer.getInstance()Recupera o servidor CoAP em execuçãono framework.
SampleCoapServer.getInstance().add()Adiciona ao servidor CoAP algum recursoCoAP que possa ser de�nido por um Proxyda Aplicação Cliente.
DeviceManager.register()Registra uma instância de um VirtualDeviceno DeviceManager.
ManagerFile.createFileActionsDiscovery()
Cria um arquivo no diretório do projetodenominado actions_discovered contendotodos os ações descobertas e virtualizadaspelo proxy em seus VirtualDevices.
VirtualDevice.createInstance() Cria uma instância da classe VirtualDevice.
Tradutor Proxy, através do método start(), a classe VirtualDevice, que possui métodos de
interação com o dispositivo físico (sendEvent e getDataEvent) e por �m a classe Device-
Manager que é utilizada para descobrir (método discovery()) os dispositivos virtualizados
no contexto do framework.
Alguns outros serviços podem ser fornecidos pelo framework para auxiliar a de�nição
do ponto de extensão mencionados anteriormente nesta seção. Estes serviços incluem
algumas chamadas de métodos que são descritas na Tabela 3.
O próximo capítulo tratará de avaliar o framework planejado e estruturado no capítulo
4. Para tal, métricas foram utilizadas no sentido de validar aspectos voltados à facilidade
de desenvolvimento.
66
5 Avaliação do Framework
Este capítulo aborda o processo de avaliação do framework proposto no Capítulo 4.
Para tal, uma prova de conceito foi de�nida na seção 6.1 na qual foi apresentado o cenário
e sua avaliação sob o ponto de vista da facilidade de desenvolvimento.
5.1 Prova de Conceito
Esta seção descreve uma prova de conceito que baseia-se em um cenário de controle
básico de temperatura de um ambiente qualquer. Para tal, dispositivos de capacidades
heterogêneas foram envolvidos e a aplicação �nal utilizou-se do framework proposto por
este trabalho. Sendo assim, o objetivo desta prova de conceito é o de avaliar o esforço
de desenvolvimento de aplicações IoT utilizando o framework proposto. O planejamento
e organização foram baseados nas diretrizes estabelecidas por Aberdeen (ABERDEEN,
2013), Kitchenham(KITCHENHAM; PICKARD; PFLEEGER, 1995) e Runeson (RUNESON;
HÖST, 2009).
5.1.1 Planejamento
O planejamento envolve a de�nição das questões de pesquisa de interesse desta avali-
ação, os sujeitos envolvidos, o objeto utilizado, as unidades de análise e os procedimentos
de�nidos para a coleta dos dados. Os passos citados foram de�nidos nas seções seguintes.
5.1.1.1 Questões de Pesquisa
Para atingir os objetivos de�nidos para a prova de conceito, as seguintes questões de
pesquisa precisam ser respondidas:
1. Qual o impacto do uso do framework em uma aplicação IoT quanto à diminuição
do esforço de codi�cação de seu desenvolvimento?
67
2. Qual o impacto que pode haver no aumento da quantidade de dispositivos envol-
vidos na aplicação no tocante à complexidade de codi�cação da aplicação que utiliza o
framework?
Para responder tais questões, uma aplicação utilizando-se do framework proposto
como base foi implementado. A implementação considerou a existência de sensores e atu-
adores simulados com protocolos de comunicação heterogêneos. As aplicações tiveram os
dados de interesse da avaliação coletados (Vide seção 5.1.1.5) na qual aplicou-se métricas
de LOC e Complexidade Ciclomática para a análise e construção das respostas.
5.1.1.2 Sujeitos
O aplicação implementada, utilizando-se do framework proposto foi utilizada pelo
próprio pesquisador e autor deste trabalho. O mesmo possui experiência em desenvolvi-
mento de aplicações móveis e na linguagem Java. Desta forma, o sujeito envolvido nesta
prova de conceito é o criador do framework proposto.
5.1.1.3 Objeto
O objeto utilizado na prova de conceito é um cenário de controle de temperatura
através de sensores e termostatos de capacidades de comunicação heterogêneas. A escolha
de cenário se deu devido à simplicidade da estrutura, no entanto o foco principal é a di-
versidade de dispositivos de capacidades heterogêneas. Para tal, uma aplicação cliente foi
implementada utilizando-se do framework proposto para a manipulação dos dispositivos
presentes na infraestrutura IoT. A aplicação cliente poderá ler os dados que o senso-
res de temperatura possuírem e enviar um comando de modi�cação de estado (quando
necessário) ao termostato.
Figura 26: Cenário do experimento utilizado como objeto de estudo.
O framework destacado na aplicação cliente, assim como ilustrado na Figura 26 re-
68
presenta o foco da avaliação. Pois ele é o responsável por abstrair, do ponto de vista da
aplicação cliente, a heterogeneidade presente no cenário apresentado.
5.1.1.4 Unidades de análise
Duas unidades de análise foram de�nidas: A aplicação cliente desenvolvida com base
no framework proposto, que terá seu desenvolvimento analisado após a utilização do
framework e uma aplicação cliente desenvolvida com a mesma �nalidade da primeira,
mas sem o uso do framework, que também será analisada a �ns de comparação com a
primeira unidade. As análises compreendem avaliar os aspectos voltados à facilidade de
desenvolvimento utilizando o framework proposto.
5.1.1.5 Coleta de Dados
Os seguintes dados foram coletados neste estudo de caso:
1. As linhas de código da aplicação cliente desenvolvida com base no framework.
2. As linhas de código da aplicação cliente sem o auxílio do framework proposto.
A coleta considerou linhas de import, comentários e espaços em branco. Para as mé-
tricas utilizadas, Sharma (SHARMA et al., 2012) acredita ser importante considerar tais
linhas.
5.1.2 Execução
Esta seção descreve a execução do processo de avaliação da prova de conceito proposta
pelas seções anteriores. Nela está descrito como ocorreu o processo de desenvolvimento
da aplicação e como foram coletados os dados necessários evidenciados na Seção 6.1.1.5
para a análise dos aspectos de simpli�cação de desenvolvimento objetivados pela proposta
deste trabalho.
5.1.2.1 A aplicação
O caso de teste utilizou dois protocolos distintos, Bluetooth e UPnP. Para viabilizar
a construção da aplicação, utilizou-se a plataforma Android, já que a mesma possui uma
rica API voltada à manipulação de adaptadores Bluetooth.
Desta forma, uma aplicação Android foi criada para simular um termostato. Para tal,
69
a API Bluetooth1 foi utilizada na de�nição das rotinas do aplicativo, permitindo que a
temperatura pudesse ser de�nida a partir da própria aplicação ou através de um comando
remoto enviado por um canal de comunicação Bluetooth. A aplicação em sua versão �nal
é ilustrada na Figura 27. O sensor de temperatura utilizar-se-á do UPnP como protocolo
de comunicação, e foi simulado programaticamente através do Cling2.
Figura 27: Aplicativo Android representando um Termostato Bluetooth.
A aplicação cliente (Vide Figura 28), devido à necessidade da utilização de um adap-
tador bluetooth, também foi implementada na plataforma Android, seguindo as especi�ca-
ções do framework proposto por este trabalho. Desta forma, um proxy foi implementado
utilizando como referência a API Bluetooth do Android SDK e adicionado à aplicação
cliente. O proxy em questão foi referenciado como propriedade no con�g.properties para
o processo de instanciação do framework (Vide seção 4.5.2).
O funcionamento geral da aplicação cliente é demonstrado no diagrama de ativida-
des ilustrado na Figura 29, demonstrando como a aplicação cliente irá interagir com o
framework. É possível notar na �gura que após a iniciação da aplicação móvel (que re-
presentará a aplicação cliente IoT) o framework é iniciado invocando o método start()
da classe Core. Este procedimento iniciará a busca dos proxies que estão de�nidos nati-
vamente nele ou foram referenciados pela aplicação cliente para serem considerados. No
caso da aplicação, um proxy do Bluetooth foi de�nido pela aplicação cliente.1https://developer.android.com/guide/topics/connectivity/bluetooth?hl=pt-br2http://4thline.org/projects/cling/core/manual/cling-core-manual.xhtml
70
Figura 28: Aplicação cliente desenvolvida na plataforma Android.
Os proxies recuperados (Proxy UPnP e Proxy Bluetooth) irão executar seus métodos
de descoberta respeitando suas especi�cidades, e encapsularão os dispositivos descobertos
(os sensores de temperatura UPnP e o termostato Bluetooth) em Dispositivos Virtuais,
registrando-os em seguida no DeviceManager. A partir deste ponto, a aplicação cliente
poderá invocar os métodos de descoberta do DeviceManager e recuperar os dispositivos
virtualizados para utilizá-los em sua lógica.
Desta forma, a aplicação recuperou os sensores e o termostato virtualizados e ini-
ciou sua lógica, veri�cando se a temperatura capturada pelos sensores estava abaixo ou
igual a 25oC (através do método getDataEvent() do VirtualDevice). Este procedimento
desencadeia a iniciação do Recurso CoAP mantido pelo framework, que representa a ação
desejada e passada por parâmetro no método getDataEvent(). O Recurso, por sua vez,
envia a requisição para o proxy correto através do método getData(), que retornará à apli-
cação cliente a informação. Caso seu retorno seja superior à 25oC, a aplicação encerrará
a execução.
Nos casos em que os sensores retornarem uma temperatura igual ou inferior à 25o, a
aplicação invocará o método sendEvent() do VirtualDevice que representa o termostato,
enviando parâmetros capazes de modi�car seu estado para 30oC. Da mesma forma como
ocorreu no sensor, esta ação irá iniciar o Recurso CoAP responsável pela ação e o mesmo
redirecionará a requisição para o proxy correto, invocando o método send() do mesmo
71
Figura 29: Funcionamento geral da aplicação cliente com o framework.
para realizar a operação no dispositivo físico, e isso também encerrará a execução da
aplicação cliente.
O código implementado na aplicação cliente para a manipulação destes dispositivos
foi adicionado em um encadeamento separado do encadeamento principal da aplicação
Android. Neste caso, uma thread foi criada para ser executada após o aplicativo inciar
no dispositivo. O início da thread invocou o método start() do Core. E neste caso especí-
�co, passou por parâmetro o stream do arquivo de con�guração que, por ser um projeto
Android, �ca armazenado em um diretório especí�co, diferente do caminho raiz esperado
pelo método supracitado.
Figura 30: Código utilizado para a instanciação do framework e descoberta dos dispositivosna aplicação cliente.
Em seguida, os métodos de descoberta puderam ser invocados e os dispositivos virtua-
lizados recuperados para o uso da aplicação cliente. A Figura 30 ilustra o código necessário
para a realização destes passos. O método discovery() do DeviceManager na Figura citada
realizou uma consulta por parte do nome nos dispositivos virtualizados pelo framework,
este processo retorna uma lista dos possíveis dispositivos encontrados. No caso da aplica-
72
ção, apenas um dispositivo de cada foi encapsulado, por isto, apenas o primeiro dispositivo
da lista foi utilizado na aplicação.
Figura 31: Código necessário para a veri�cação do estado dos dispositivos e modi�caçãodo estado do termostato.
A Figura 31 representa o código necessário utilizado para a consulta dos dados gerados
pelo sensor de temperatura e para a modi�cação do estado do termostato. O código é
posicionado exatamente após as consultas dos dispositivos virtuais no DeviceManager,
como demonstrado na Figura 30. As linhas 44 a 46 da Figura 31 representam a de�nição
do mapeamento de parâmetros e novos valores que poderão ser assumidos pelo termostato.
A descrição correta dos parâmetros foram identi�cadas e adicionadas na classe estática
ResourceManager durante o processo de descoberta dos proxies. No caso ilustrado, um
objeto HashMap foi criado contendo um único registo, que informava que o parâmetro
NewValue do serviço Con�gureTemperature de�nidos para o termostato poderá assumir
o valor 30.
Em seguida, o método getDataEvent() do sensor foi invocado, de modo a aplicação
tomar conhecimento do estado atual do sensor de temperatura, ora virtualizado pelo
framework. A informação foi retornada em formato JSON, que foi tratada através de uma
classe utilitária do framework, denominada JsonExtractUtil, assim como exempli�cado nas
linhas 46 a 48. Após o método getDataEvent() do sensor ser invocado, o valor foi extraído
da mensagem JSON e veri�cado se poderia ser maior que 25oC, em caso positivo, o
método sendEvent() do termostato seria chamado (Linha 50), passando por parâmetro a
ação desejada (NewValueTemp) e a instância dos novos valores mapeados (mappedValues).
Figura 32: Log registrando a alteração bem-sucedida do estado do termostato.
O sensor de temperatura simulado foi con�gurado para retornar a temperatura 20oC,
favorecendo à condição implementada na aplicação (temperatura <= 25o) forçando-a a
modi�car o estado do termostato. Desta forma, uma noti�cação foi criada para o usuário
73
da aplicação, antes da operação de mudança de estado sobre o termostato. Em seguida, a
operação sendEvent() do termostato foi executada e o seu retorno registrado nos logs da
aplicação assim como ilustrado na Figura 32, demonstrando que a alteração do seu estado
foi bem-sucedida.
5.1.2.2 A coleta e análise dos dados
Após a implementação da aplicação cliente realizada em um dispositivo Android 4.1,
Samsumg Galaxy Note, Quad Core 1.9 Ghz e 3GB de RAM, uma aplicação similar,
com o mesmo objetivo foi desenvolvida no mesmo ambiente, sem o auxílio do framework
proposto. Tal medida foi realizada para auxiliar na avaliação dos aspectos de simpli�cação
de desenvolvimento objetivados pelo framework.
As linhas de código foram extraídas de ambos os projetos e as métricas utilizadas para
esta análise foram a LOC (Lines of Code) e a Complexidade Ciclomática. A primeira foca
na mensuração de uma aplicação pela quantidade de linhas de código implementadas, e
a segunda está focada em veri�car o nível de complexidade do projeto através da geração
de um grafo de �uxo (SHARMA et al., 2012).
As métricas utilizadas são evidenciadas no trabalho de Sharma (SHARMA et al., 2012)
como formas estáticas de mensurar os atributos de produtividade de um software. E como
tratam-se de métricas orientadas a objetos, considera-se que são bons índices de avaliação
do aspecto de facilidade de desenvolvimento.
As classes analisadas serão apenas duas:MainActivity.java e IotApplication.java.
A primeira trata-se da classe principal da aplicação, responsável por iniciar a aplicação
no dispositivo móvel e prover formas de interação do usuário com a mesma, a segunda é
responsável por conter a lógica que manipulará os dispositivos da infraestrutura IoT.
Tabela 4: Linhas de Código (LOC) extraídas das classes do caso de teste (um sensor eum termostato).
Classe LOC (Framework) LOC (sem o Framework)MainActivity.java 50 102IotApplication.java 68 183
TOTAL 118 285
Dois pares de aplicações foram construídos de maneira similar (i.e. mesma quantidade
de classes e regras de implementação). O primeiro par de aplicações considerou uma com
o uso do framework e a outra sem o uso do mesmo, utilizando-se de um sensor simulado
e um termostato. O segundo par também considerou uma aplicação com o uso e sem o
74
Tabela 5: Linhas de Código (LOC) extraídas das classes do caso de teste (dez sensores edois termostatos).
Classe LOC (Framework) LOC (sem o Framework)MainActivity.java 50 103IotApplication.java 82 203
TOTAL 132 306
uso do framework, no entanto, utilizou-se de dez sensores simulados e dois termostatos.
Os resultados são evidenciados nas Tabelas 4 e 5.
5.1.3 Respostas às questões de pesquisa
Assim como mencionado na seção 6.1.1, o sujeito que elaborou este estudo de caso,
o utilizou como �nalidade principal de responder às questões de pesquisa propostas em
seu planejamento. Desta forma, esta seção responde tais questões utilizando como base
de seus argumentos, os dados coletados na sua execução (Vide seção 6.1.2).
5.1.3.1 Qual o impacto do uso do framework em uma aplicação IoT quantoà diminuição do esforço de codi�cação de seu desenvolvimento?
O framework diminuiu de forma considerável a quantidade de linhas de código que
são necessárias para lidar com as especi�dades de cada dispositivo e protocolo de comu-
nicação para o experimento abordado no estudo de caso (um sensor de temperatura e um
termostato). Esta a�rmação pode ser melhor observada através da Figura 33, que eviden-
cia a quantidade de linhas de código necessárias para a implementação do experimento
explorado no Estudo de caso.
Figura 33: LOC por classe mensuradas no experimento do Estudo de Caso.
75
É importante lembrar que as linhas utilizadas no levantamento exposto na Figura
33 consideraram imports, comentários e espaços em brancos, e o experimento com o uso
do framework proposto considerou, para este levantamento, um sensor e um atuador na
infraestrutura IoT.
Figura 34: Comparativo da Complexidade Ciclomática das aplicações IoT.
Os índices de complexidade ciclomática também revelaram números expressivos e
que demonstram um crescimento considerável na complexidade da aplicação que não
utilizou o framework. Tais resultados são expressados na Figura 34. Os índices coletados
foram o WMC (Weighted Methods per Class) e o CCN (Cyclomatic Complexity Number).
O primeiro índice representa a complexidade média dos métodos ponderados por cada
classe analisada, o segundo representa o total calculado da complexidade ciclomática da
aplicação.
A aplicação com o auxílio do framework revelou um total de 12 para o WMC ,
já a aplicação sem o uso do framework elevou esse valor para um total de 30. Para o
CCN , a aplicação com o framework também alcançou um total de 12, e a aplicação
similar, sem o uso do framework alcançou para este índice, um total de 36. Tal amostra
demonstra indícios que para a aplicação demonstrada que não utiliza o framework há uma
complexidade bastante superior à aplicação que o utiliza.
Tal análise inicial resultou em uma diminuição aproximada de 58,60% de esforço total
de codi�cação a partir dos números apresentados nas métricas do LOC . Tal índice de-
monstra que a utilização do framework, para o estudo de caso proposto, apresenta indícios
relevantes para a diminuição do esforço de codi�cação no processo de desenvolvimento.
76
5.1.3.2 Questão de pesquisa 2: Qual o impacto que pode haver no aumentoda quantidade de dispositivos envolvidos na aplicação no tocante àcomplexidade de codi�cação da aplicação que utiliza o framework?
Para esta questão, duas aplicações similares foram desenvolvidas, uma utilizando o
framework proposto e outra, sem o uso do framework, mas considerando a existência de
10 sensores de temperatura e dois termostatos.
Figura 35: LOC para aplicação envolvendo 10 sensores e um atuador.
Neste caso, um aumento na quantidade de linhas de código (LOC) foi identi�cado
em ambas as aplicações (Vide Figura 35). Na aplicação que utilizou o framework, apenas
a classe IotApplication foi modi�cada, 14 novas linhas foram adicionadas para tratar os
dispositivos envolvidos. Na aplicação que não utilizou o framework, 21 novas linhas foram
adicionadas.
Com tais dados, o crescimento proporcional do número de linhas de código em um
contexto onde múltiplos dispositivos estão envolvidos (10 sensores de temperatura e dois
termostatos) apresentou uma diferença de 174 de linhas de código a menos na aplicação
que utilizou o framework. Tal diferença representa uma diminuição de esforço de codi�-
cação aproximada de 56,90%. Uma diferença de um pouco mais de 1% com relação ao
primeiro par de aplicações (com um sensor e um termostato envolvido).
No entanto, a complexidade ciclomática sofreu alterações mais visíveis e discrepantes.
Com o uso do framework, ambos os índices observados para esta métrica (WMC e CCN)
subiram apenas um ponto com relação ao experimento anterior (de 12 para 13). Mas a
aplicação que não utilizou o framework apresentou uma mudança mais crítica, alterando
seus índices de WMC para 33 e CCN para 43 (antes 30 e 36).
No caso demonstrado, do ponto de vista de esforço de desenvolvimento, é visível
77
Figura 36: Comparativo da complexidade ciclomática para a aplicação com 10 sensores edois termostatos.
que o aumento do número de sensores envolvidos não apresentou impactos negativos
quanto à simpli�cação. No entanto, sem o uso do framework, a aplicação poderá aumentar
sua complexidade e os possíveis riscos, mas com o uso do framework estas variações
apresentam indícios de valores pequenos e aceitáveis.
5.1.4 Ameaças à Validade
Para o estudo de caso realizado foram avaliados três tipos de validade:
1. Validade de construção: Características especí�cas voltadas à codi�cação e de con-
�gurações de máquina (dispositivos utilizados) poderiam comprometer os valores
coletados no estudo. No entanto, o processo de levantamento de dados quantita-
tivos para a análise dos fatores propostos por este estudo focou-se em uma única
linguagem de programação na construção das aplicações e estas foram implementa-
das em apenas um ambiente evitando que quaisquer alterações comprometessem os
resultados.
2. Validade interna: Fatores voltados à inexperiência de programadores no desenvol-
vimento de aplicações IoT, Java ou com o framework poderiam sair do controle e
comprometer os resultados. No entanto, o estudo de caso foi realizado pelo criador
do framework, o mesmo possui considerável experiência com a Linguagem Java, o
que diminui consideravelmente os riscos destes fatores afetarem os resultados.
3. Validade externa: o desenvolvimento do experimento proposto no estudo de caso foi
implementado pelo próprio criador do framework, o mesmo possui experiência e fa-
78
miliaridade com a linguagem Java. Sendo assim, programadores inexperientes ou que
não conhecessem a estrutura do framework poderiam elaborar aplicações com uma
quantidade de linhas de código superior ao evidenciado no estudo. O experimento
também foi elaborado em apenas um cenário exempli�cador, desta forma, cenários
mais complexos poderiam afetar consideravelmente a implementação e poderiam
acrescer o número de linhas de código para o desenvolvimento da aplicação.
79
6 Trabalhos Relacionados
Este capítulo trata de relatar os trabalhos no estado da arte que estão de alguma
maneira relacionados com a proposta deste trabalho. Tais trabalhos possuem abordagens
similares com as que são sugeridas pela presente proposta. O Capítulo está estruturado em
duas Seções: A 5.1 sintetiza todas as soluções relacionadas voltadas à modelos de repre-
sentação dos dispositivos, e a 5.2 trata de estratégias que visaram abstrair os dispositivos
como serviços.
6.1 Modelos de representação de Dispositivos
A proposta de Datta (DATTA; BONNET, 2016) introduz um framework, denominado
DataTweet, focado em vários domínios e utiliza Machine-to-Machine Measurement (M3)
Framework para solucionar questões de heterogeneidade. A proposta do autor é uma divi-
são entre os componentes da lógica da aplicação(AL), que abstraem todos os mecanismos
que os usuários estão interessados no aplicação, tais como: Interface do usuário, meca-
nismos de consulta e descoberta de recursos, entre outros, e o componente denominado
Entidade de Serviços Comum(CSE) que abstraem os serviços disponíveis oferecidos pela
aplicação neste módulo. Toda a dinâmica de registro, gerenciamento e interoperabilidade
devem ser tratados no CSE, e as funções voltadas à aplicação pertencem a AL. Tais
módulos são intermediados por uma interface comum.
A proposta acima citada baseia-se no trabalho de Patel e Cassou (PATEL; CASSOU,
2015) que por sua vez busca desenvolver um framework conceitual baseado na divisão de
habilidades presentes em uma infraestrutura IoT. Sua abordagem apresenta linguagens
descritivas denominadas "Srijan Vocabulary"que modelarão os dispositivos existentes e
poderão gerar códigos executáveis para as aplicações.
A proposta de Kum (KUM; KANG; PARK, 2016) destaca-se por prover um framework
que tem como objetivo tratar a heterogeneidade de protocolos de uma aplicação IoT.
IoTDelegate abstrai a aplicação em três camadas:Plug-In, Colaboração e Gerenciamento
80
de Serviços. A primeira camada irá remover quaisquer dependências voltadas ao protocolo
dos objetos inteligentes e as demais irão criar abstrações que permitem a comunicação
e colaboração dos dispositivos constituintes. Já Manione (MANIONE, 2017) relata um
framework diferente dos citados anteriormente, pois objetiva a simpli�cação do desenvol-
vimento através de uma abordagem centrada no usuário, diminuindo ou dispensando o
uso de programação de níveis mais próximos do hardware. A abordagem é baseada em
modelos e utiliza Task Script para tal �nalidade.
Um proposta voltada à abstração considerada neste trabalho foi a de Silva (SILVA et al.,
2016), que propõe uma API para acessar serviços baseados em IoT através de protocolos
REST e SOAP. A abordagem busca prover meios de facilitar a complexidade inerente à di-
versidade de dispositivos existentes em aplicações IoT. Basicamente, a proposta fornecerá
uma estrutura que irá prover acesso uniforme a recursos e operações através de mensagens
estruturadas em SOAP e REST. O autor utilizou o UPnP como padrão orientador de seu
experimento e avaliou aspectos voltados à performance, descartando a utilização de SOAP
devido aos resultados abaixo do esperado.
Foi levantado também por Ferrera (FERRERA et al., 2017), a necessidade de haver
um modelo que possa representar os dispositivos de maneira uniforme e o autor propôs
em seu trabalho, uma infraestrutura de plataforma de con�guração (IoT-PIC) tentando
considerar as muitas camadas de uma infra-estrutura IoT. A simpli�cação ocorre através
de uma abordagem baseada em modelos para a criação de novos serviços e aplicações
baseados em IoT. Para tal feito, o autor utilizou XMPP no processo de comunicação
das entidades e RAI (Resource Application Interface) para lidar com as virtualizações.
Porém, a solução virtualiza de acordo com driver disponível na camada RAI e retorna
uma instância virtualizada especí�ca de cada drive.
As abordagens acima relacionam-se com este trabalho devido a utilizarem modos de
abstrair os objetos através de propostas de modelos. Contudo, a maioria das propostas
omitem detalhes de como os dispositivos se relacionarão com os modelos na aplicação,
muito embora alguns evidenciem a necessidade de mecanismos de descoberta na rede, tais
como Datta (DATTA; BONNET, 2016), mas não relatam de maneira clara em que momento
esta operação ocorre. Nossa proposta acredita que uma virtualização globalizada e única
diminuiria a complexidade inerente ao desenvolvimento destas aplicações, facilitando a
codi�cação no tratamento dos vários dispositivos existentes.
Algumas das abordagens acima buscam um meio de virtualização voltado especi�ca-
mente para cada protocolo inserido na aplicação, distinguindo-os por suas especi�cações
81
individuais. A proposta desse trabalho irá abordar uma maneira simpli�cadora de vir-
tualizar unicamente os dispositivos, independente do protocolo especi�cado, bem como
proverá meios para os dispositivos associarem-se ao modelo utilizado.
6.2 Dispositivos abstraídos como Serviços
Algumas soluções destacaram-se por suas abordagens voltadas à nuvem, Kohdadadi
(KHODADADI; CALHEIROS; BUYYA, 2015) propõe um framework que devido a ser orientado
a nuvem, permite que o desenvolvedor preocupe-se apenas com a o desenvolvimento da
lógica, pois o framework estará focado em lidar com a manipulação de dados, conexões
com fontes de dados, consultas, �ltros, e escalonamento de recursos. O protótipo é baseado
em Aneka Cloud e toda a comunicação é baseada em MQTT .
Foi também abordada por Carranza (CARRANZA-GARCÍA et al., 2016), uma proposta
que apresenta um framework baseado na nuvem, ele utiliza-se de uma abordagem BaaS
(Back-end as Service) que trata-se de um modelo de computação na nuvem que conecta
aplicações a armazenamentos e processamentos em estruturas disponibilizadas na nuvem,
e toda a comunicação é intermediada por padrões REST/SOAP . A abordagem do autor
abstrai todos os dispositivos como serviços disponibilizados nessa estrutura.
O trabalho de Jara (JARA et al., 2014) no entanto, propõe uma arquitetura de desco-
berta de serviços heterogêneos IoT através da ciência de contexto ou geolocalização. Para
ser possível controlar as "things"através de browsers e smartphones. O autor utilizou como
estratégia uma representação de recursos semanticamente interoperáveis baseado na es-
tratégia Presto Mash-up Connectors. No entanto, a aplicação basicamente objetiva um
controle geral de dispositivos inteligentes a partir do smartphone.
As abordagens voltadas a abstração por serviço, na maioria dos casos orientadas à
nuvem, citadas acima, abstraem os dispositivos como modelos uni�cados de serviços.
Tais abordagens são realizadas visando a simpli�cação do desenvolvimento, e por esta
razão está relacionada com este trabalho. Porém, nossa proposta não está inicialmente
focada em uma abordagem orientada à nuvem, dispensando neste primeiro momento,
preocupações voltadas à latência, especialmente em aplicações que requerem um alto
nível de escalabilidade.
No entanto, a abordagem de representar os dispositivos através de serviços, favorece a
utilização de mecanismos de descoberta que são considerados por Datta (DATTA; BONNET,
2016) como um forte indicador de facilidade no processo de desenvolvimento de aplicações
82
IoT. E neste caso, nossa abordagem buscará utilizar-se dessa abstração para facilitar o
processo de associação dos dispositivos virtualizados com seus respectivos dispositivos
reais. No entanto, essa abstração não estará na nuvem e apenas utilizará essa abordagem
com um passo no processo de simpli�cação do desenvolvimento.
83
7 Considerações Finais
Este capítulo apresenta as considerações �nais da pesquisa realizada, organizando-se
da seguinte maneira: A Seção 6.1 apresenta a retrospectiva deste trabalho, a seção 6.2 as
suas principais contribuições e a 6.3 descreve os trabalhos futuros propostos pelo autor
desta pesquisa.
7.1 Retrospectiva e conclusões do trabalho
No Capítulo 1 foi mostrado que devido à massiva quantidade de dispositivos, padrões
e protocolos de comunicação heterogêneos, uma série de desa�os críticos que impactam no
processo de desenvolvimento destas aplicações foram inevitavelmente gerados, tornando o
processo de desenvolvimento destas aplicações algo complexo de realizar-se. Evidenciando-
se a notável necessidade da existência de soluções que objetivassem a simpli�cação do pro-
cesso de desenvolvimento de aplicações IoT, reduzindo de maneira signi�cativa o esforço
de produção através da abstração destes desa�os.
No Capítulo 2, foi possível compreender tecnicamente como funcionam os protocolos
de níveis de aplicação (CoAP) e comunicação (UPnP e Bluetooth), bem como entender em
um nível mais geral, o paradigma da Internet das Coisas, suas visões e seu modelo arquite-
tural genérico proposto pela literatura. A partir dele, foi possível obter uma compreensão
mais geral dos conceitos e fundamentos considerados importantes por esta pesquisa.
No Capítulo 3, foi possível constatar que as soluções propostas no estado da arte, com
o objetivo de simpli�car o processo de desenvolvimento de aplicações IoT, em sua grande
maioria, concentram-se em atingir requisitos e desa�os isolados. Embora as soluções apre-
sentem meios simpli�cadores, estão focadas apenas à requisitos especí�cos abordados em
suas propostas, ignorando os demais. Também foi possível notar que poucas propostas
objetivaram abordagens com um viés prático, e quase nenhuma proposta buscou abstrair
dispositivos das soluções IoT através de linguagens e/ou abordagens popularmente utili-
84
zadas. Levando-nos a concluir que existe uma notável necessidade de ferramentas práticas
que busquem atingir e integrar requisitos que são críticos para o desenvolvimento em uma
mesma solução baseada em IoT.
O Capítulo 4 apresentou a proposta central deste trabalho: um framework que possa
facilitar o desenvolvimento de aplicações baseadas em IoT. Neste foi possível conhecer a
arquitetura proposta e seus componentes constituintes, a estrutura da solução implemen-
tada utilizando-se da Linguagem Java, e meios de instanciá-lo e estendê-lo em projetos
de aplicações IoT.
No Capítulo 5, um levantamento dos trabalhos e propostas relacionadas à abordada
por esta pesquisa foi realizado. Neste, técnicas foram evidenciadas e consideradas impor-
tantes na de�nição do framework proposto por este trabalho.
No Capítulo 6, a avaliação do framework foi planejada e realizada através de uma
prova de conceito. Nesta, questões voltadas ao objetivo desta pesquisa foram levantadas e
respondidas com base em métricas especí�cas (LOC e CC) aplicadas à execução da prova
de conceito. A execução compreendeu a de�nição de uma aplicação cliente utilizando o
framework para um cenário típico de IoT (Controle de temperatura) e outra aplicação,
com o mesmo objetivo e implementação, mas sem o uso do framework. Com tais aplicações
implementadas e métricas aplicadas, foi possível observar e atestar indícios importantes
de que o framework proposto, pra o cenário apresentado, simpli�ca e reduz o esforço de
codi�cação no desenvolvimento de aplicações IoT.
Devido ainda à falta de um padrão universal que generalize os processos de comu-
nicação dos dispositivos envolvidos em infra-estruturas IoT, aplicações voltadas à estes
cenários continuarão cercadas de dispositivos heterogêneos. Essa característica exigirá do
processo de desenvolvimento, demasiado esforço para lidar com cada forma de comunica-
ção ou capacidade destes dispositivos.
O tipo de framework apresentado por este trabalho possui uma perspectiva facilita-
dora, pois ele propõe uma abordagem uni�cada para os dispositivos envolvidos através da
virtualização. Esta característica é capaz de absorver a complexidade voltada aos processos
de comunicação e capacidades individuais destes dispositivos nas camadas do framework,
de maneira oculta ao desenvolvedor da aplicação IoT.
Desta forma, este trabalho demonstrou que a construção de um framework capaz
de prover uniformidade, através da virtualização, no tratamento dos dispositivos de uma
infraestrutura IoT ocasiona uma diminuição considerável no esforço de codi�cação de uma
85
aplicação IoT. As especi�cidades de cada dispositivo heterogêneo, sejam funcionais ou de
comunicação, são abstraídas pelo modelo virtual oferecido pelo mesmo. Sendo assim, a
virtualização de dispositivos demonstrou um caminho facilitador, do ponto de vista da
codi�cação, eximindo a aplicação cliente de detalhes especí�cos e individuais.
7.2 Contribuições
Neste trabalho, destacam-se as seguintes contribuições:
1. A de�nição de um framework capaz de facilitar o processo de desenvolvimento de
aplicações baseadas em IoT através de uma abordagem voltada à virtualização de
dispositivos e proxies multi-protocolos. O framework já possui um proxy padrão
disponibilizado, mas a solução também permite extensões para outros protocolos
(proxies), devido à evolução constante e surgimento massivo dos protocolos de co-
municação voltadas à dispositivos geralmente presentes em infraestruturas IoT.
2. Implementação e publicação do framework proposto utilizando-se da linguagem Java
para ser utilizado em aplicações IoT que utilizam dispositivos UPnP, possibilitando
a implementação de novas extensões. O framework é disponibilizado através do link:
https://github.com/dannylo/easyiot.
3. Implementação de uma prova de conceito utilizando-se do framework implementado
para um cenário de controle de temperatura. A implementação utilizou-se do proxy
já fornecido pelo framework e pode ainda realizar uma extensão para o protocolo
Bluetooth.
4. Avaliação do framework através da realização de um estudo experimental cujo obje-
tivo foi o de avaliar aspectos voltados à facilidade no processo de desenvolvimento.
7.3 Trabalhos Futuros
Como trabalho futuro pretende-se criar uma DSL (Description Service Language)
voltada para a comunicação de dispositivos IoT. A linguagem utilizaria-se do framework
para realizar seus objetivos. Esta deverá prover uma sintaxe simples, própria para a de-
�nição de mecanismos de comunicação dos dispositivos, de�nição de rotinas de execução
86
envolvendo estes dispositivos, mecanismos de decisão, entre outros recursos que se fa-
çam necessários para um contexto IoT. Todos estes recursos deverão obedecer o modelo
arquitetural de�nido no framework proposto por este trabalho.
Também há a pretensão da evolução do módulo health da arquitetura do framework de
modo a lidar com aspectos de dependabilidade mais avançados, garantindo maior disponi-
bilidade dos dispositivos envolvidos e uma maior con�abilidade das aplicações construídas
com base no framework.
Além disso, pode haver a evolução do Gerenciador de Aplicações e do próprio Dis-
positivo Virtual de modo a lidar com comunicação assíncrona e streaming de dados, de
modo a lidar com sensores que possuam características voltadas à produção frenética de
dados ou assincronia de comunicação.
Por �m, outros estudos avaliativos também poderiam atestar resultados importantes,
validando o framework para cenários mais complexos com um maior número de disposi-
tivos ou envolvendo outros desenvolvedores para avaliarem aspectos de produtividade de
desenvolvimento.
87
Referências
ABERDEEN, T. Yin, rk (2009). case study research: Design and methods . thousandoaks, ca: Sage. The Canadian Journal of Action Research, v. 14, n. 1, p. 69�71, 2013.
ALLARD, J. et al. Jini meets upnp: an architecture for jini/upnp interoperability. In:IEEE. Applications and the Internet, 2003. Proceedings. 2003 Symposium on. [S.l.], 2003.p. 268�275.
AMARAL, L. A. et al. ecloudr�d�a mobile software framework architecture for pervasiver�d-based applications. Journal of Network and Computer Applications, Elsevier, v. 34,n. 3, p. 972�979, 2011.
ARUNACHALAM, K.; GANAPATHY, G. Research on upnp protocol stack forapplications on a home network. International Journal of Engineering and Technology(IJET), v. 8, n. 4, p. 1728�1736, 2016.
ASHRAF, Q. M. et al. Device discovery and con�guration scheme for internet of things.In: IEEE. Intelligent Systems Engineering (ICISE), 2016 International Conference on.[S.l.], 2016. p. 38�43.
ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Computernetworks, Elsevier, v. 54, n. 15, p. 2787�2805, 2010.
AVILES-LOPEZ, E.; GARCIA-MACIAS, J. A. Mashing up the internet of things: aframework for smart environments. EURASIP Journal on Wireless Communications andNetworking, Nature Publishing Group, v. 2012, n. 1, p. 79, 2012.
BANDYOPADHYAY, D.; SEN, J. Internet of things: Applications and challenges intechnology and standardization. Wireless Personal Communications, Springer, v. 58,n. 1, p. 49�69, 2011.
BOCCHINO, S.; FEDOR, S.; PETRACCA, M. Pyfuns: A python framework forubiquitous networked sensors. In: SPRINGER. European Conference on Wireless SensorNetworks. [S.l.], 2015. p. 1�18.
BORMANN, C.; CASTELLANI, A. P.; SHELBY, Z. Coap: An application protocol forbillions of tiny internet nodes. IEEE Internet Computing, IEEE, v. 16, n. 2, p. 62�67,2012.
BRÖRING, A. et al. Enabling iot ecosystems through platform interoperability. IEEEsoftware, v. 34, n. 1, p. 54�61, 2017.
CALCINA-CCORI, P. et al. Agile servient integration with the swarm: Automatic codegeneration for nodes in the internet of things. In: ACM. Proceedings of the InternationalConference on Future Networks and Distributed Systems. [S.l.], 2017. p. 22.
88
CARRANZA-GARCÍA, F. et al. Baas-4us: A framework to develop standardbackends as a service for ubiquitous applications. In: IEEE. Ubiquitous Computingand Communications and 2016 International Symposium on Cyberspace and Security(IUCC-CSS), International Conference on. [S.l.], 2016. p. 23�30.
CHERRIER, S. et al. D-lite: Distributed logic for internet of things services. In: IEEE.Internet of Things (iThings/CPSCom), 2011 International Conference on and 4thInternational Conference on Cyber, Physical and Social Computing. [S.l.], 2011. p. 16�24.
CHLAMTAC, I.; CONTI, M.; LIU, J. J.-N. Mobile ad hoc networking: imperatives andchallenges. Ad hoc networks, Elsevier, v. 1, n. 1, p. 13�64, 2003.
DATTA, S. K.; BONNET, C. Easing iot application development through datatweetframework. In: IEEE. Internet of Things (WF-IoT), 2016 IEEE 3rd World Forum on.[S.l.], 2016. p. 430�435.
DATTA, S. K.; COSTA, R. P. F. D.; BONNET, C. Resource discovery in internet ofthings: Current trends and future standardization aspects. In: IEEE. Internet of Things(WF-IoT), 2015 IEEE 2nd World Forum on. [S.l.], 2015. p. 542�547.
FERREIRA, H. G. C.; CANEDO, E. D.; SOUSA, R. T. de. Iot architecture to enableintercommunication through rest api and upnp using ip, zigbee and arduino. In: IEEE.Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE9th International Conference on. [S.l.], 2013. p. 53�60.
FERRERA, E. et al. Xmpp-based infrastructure for iot network management and rapidservices and applications development. Annals of Telecommunications, Springer, v. 72,n. 7-8, p. 443�457, 2017.
GUBBI, J. et al. Internet of things (iot): A vision, architectural elements, and futuredirections. Future generation computer systems, Elsevier, v. 29, n. 7, p. 1645�1660, 2013.
HERNÁNDEZ, M. E. P.; REIFF-MARGANIEC, S. Towards a software framework forthe autonomous internet of things. In: IEEE. Future Internet of Things and Cloud(FiCloud), 2016 IEEE 4th International Conference on. [S.l.], 2016. p. 220�227.
JANAK, J.; SCHULZRINNE, H. Framework for rapid prototyping of distributed iotapplications powered by webrtc. In: IEEE. Principles, Systems and Applications of IPTelecommunications (IPTComm), 2016. [S.l.], 2016. p. 1�7.
JARA, A. J. et al. Mobile digcovery: discovering and interacting with the world throughthe internet of things. Personal and ubiquitous computing, Springer, v. 18, n. 2, p.323�338, 2014.
KHAN, R. et al. Future internet: the internet of things architecture, possible applicationsand key challenges. In: IEEE. Frontiers of Information Technology (FIT), 2012 10thInternational Conference on. [S.l.], 2012. p. 257�260.
KHODADADI, F.; CALHEIROS, R. N.; BUYYA, R. A data-centric framework fordevelopment and deployment of internet of things applications in clouds. In: IEEE.Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), 2015 IEEETenth International Conference on. [S.l.], 2015. p. 1�6.
89
KITCHENHAM, B.; PICKARD, L.; PFLEEGER, S. L. Case studies for method andtool evaluation. IEEE software, IEEE, v. 12, n. 4, p. 52�62, 1995.
KUM, S. W.; KANG, M.; PARK, J.-I. Iot delegate: Smart home framework forheterogeneous iot service collaboration. KSII Transactions on Internet & InformationSystems, v. 10, n. 8, 2016.
LEE, C.; HELAL, S. Protocols for service discovery in dynamic and mobile networks.International Journal of Computer Research, v. 11, n. 1, p. 1�12, 2002.
LEE, I.; LEE, K. The internet of things (iot): Applications, investments, and challengesfor enterprises. Business Horizons, Elsevier, v. 58, n. 4, p. 431�440, 2015.
LEE, J.-S.; SU, Y.-W.; SHEN, C.-C. A comparative study of wireless protocols:Bluetooth, uwb, zigbee, and wi-�. In: IEEE. Industrial Electronics Society, 2007. IECON2007. 33rd Annual Conference of the IEEE. [S.l.], 2007. p. 46�51.
LI, S.; XU, L. D.; ZHAO, S. The internet of things: a survey. Information SystemsFrontiers, Springer, v. 17, n. 2, p. 243�259, 2015.
LU, Y.; PAPAGIANNIDIS, S.; ALAMANOS, E. Internet of things: A systematic reviewof the business literature from the user and organisational perspectives. TechnologicalForecasting and Social Change, Elsevier, 2018.
MANIONE, R. User centered integration of internet of things devices. In:INTERNATIONAL SOCIETY FOR OPTICS AND PHOTONICS. Smart Sensors,Actuators, and MEMS VIII. [S.l.], 2017. v. 10246, p. 102461K.
MEHTA, A. et al. Calvin constrained a framework for iot applications in heterogeneousenvironments. In: IEEE. Distributed Computing Systems (ICDCS), 2017 IEEE 37thInternational Conference on. [S.l.], 2017. p. 1063�1073.
MESHKOVA, E. et al. A survey on resource discovery mechanisms, peer-to-peer andservice discovery frameworks. Computer networks, Elsevier, v. 52, n. 11, p. 2097�2128,2008.
NASTIC, S.; TRUONG, H.-L.; DUSTDAR, S. Sdg-pro: a programming frameworkfor software-de�ned iot cloud gateways. Journal of Internet Services and Applications,Springer, v. 6, n. 1, p. 21, 2015.
PAGANELLI, F.; TURCHI, S.; GIULI, D. A web of things framework for restfulapplications and its experimentation in a smart city. IEEE Systems Journal, IEEE, v. 10,n. 4, p. 1412�1423, 2016.
PAL, A.; MUKHERJEE, A.; BALAMURALIDHAR, P. Model-driven development forinternet of things: Towards easing the concerns of application developers. In: Internet ofThings. User-Centric IoT. [S.l.]: Springer, 2015. p. 339�346.
PATEL, P.; CASSOU, D. Enabling high-level application development for the internetof things. Journal of Systems and Software, Elsevier, v. 103, p. 62�84, 2015.
90
PERERA, C. et al. Sensor discovery and con�guration framework for the internet ofthings paradigm. In: IEEE. Internet of Things (WF-IoT), 2014 IEEE World Forum on.[S.l.], 2014. p. 94�99.
PUIU, D. et al. Citypulse: Large scale data analytics framework for smart cities. IEEEAccess, IEEE, v. 4, p. 1086�1108, 2016.
RUNESON, P.; HÖST, M. Guidelines for conducting and reporting case study researchin software engineering. Empirical software engineering, Springer, v. 14, n. 2, p. 131,2009.
RUTA, M. et al. A coap-based framework for collaborative sensing in the semantic webof things. Procedia Computer Science, Elsevier, v. 109, p. 1047�1052, 2017.
SALEM, A.; NADEEM, T. Blink: Making the case for bluetooth open source stack. In:IEEE. Wireless Days (WD), 2018. [S.l.], 2018. p. 145�150.
SALMAN, T.; JAIN, R. Networking protocols and standards for internet of things.Internet of Things and Data Analytics Handbook (2015), p. 215�238, 2015.
SASIREKHA, S.; SWAMYNATHAN, S. Collaboration of iot devices using semanticallyenabled resource oriented middleware. In: ACM. Proceedings of the Third InternationalSymposium on Computer Vision and the Internet. [S.l.], 2016. p. 98�105.
SHARMA, M. et al. A comparative study of static object oriented metrics. InternationalJournal of Advancements in Technology, v. 3, n. 1, p. 25�34, 2012.
SHELBY, Z.; HARTKE, K.; BORMANN, C. The constrained application protocol(coap). 2014.
SILVA, C. C. de M. et al. Design and evaluation of a services interface for the internet ofthings. Wireless Personal Communications, Springer, v. 91, n. 4, p. 1711�1748, 2016.
SIVIERI, A.; MOTTOLA, L.; CUGOLA, G. Building internet of things software witheliot. Computer Communications, Elsevier, v. 89, p. 141�153, 2016.
TAYUR, V. M.; SUCHITHRA, R. Review of interoperability approaches in applicationlayer of internet of things. In: IEEE. Innovative Mechanisms for Industry Applications(ICIMIA), 2017 International Conference on. [S.l.], 2017. p. 322�326.
TIWARY, A. et al. Internet of things (iot): Research, architectures and applications.International Journal on Future Revolution in Computer Science & CommunicationEngineering, v. 4, n. 3, p. 23�27, 2018.
TOSCHI, G. M.; CAMPOS, L. B.; CUGNASCA, C. E. An upnp architecture forinteroperability in home area network. In: IEEE. Consumer Electronics (ISCE), 2016IEEE International Symposium on. [S.l.], 2016. p. 51�52.
TRAGOS, E. Z. et al. Enabling reliable and secure iot-based smart city applications. In:IEEE. Pervasive Computing and Communications Workshops (PERCOM Workshops),2014 IEEE International Conference on. [S.l.], 2014. p. 111�116.
91
VALLATI, C. et al. Betaas: A platform for development and execution of machine-to-machine applications in the internet of things. Wireless Personal Communications,Springer, v. 87, n. 3, p. 1071�1091, 2016.
VEN�KAUSKAS, A. et al. A model-driven framework to develop personalized healthmonitoring. Symmetry, Multidisciplinary Digital Publishing Institute, v. 8, n. 7, p. 65,2016.
XIAO, G. et al. User interoperability with heterogeneous iot devices throughtransformation. IEEE Trans. Industrial Informatics, v. 10, n. 2, p. 1486�1496, 2014.
YEN, I.-L. et al. A framework for iot-based monitoring and diagnosis of manufacturingsystems. In: IEEE. Service-Oriented System Engineering (SOSE), 2017 IEEE Symposiumon. [S.l.], 2017. p. 1�8.
ZANELLA, L. C. H. Metodologia da pesquisa. [S.l.]: SEAD/UFSC, 2006.
92
8 Apêndice A
Trabalho Solução proposta Requisitos
(CHERRIER et al.,2011)
Um framework universal para construção deaplicações IoT em ambientes heterogêneos.Abstraindo os dispositivos como nós da rede.
Interoperabilidade
(AMARAL et al.,2011)
Um framework para lidar com aplicaçõesIoT baseadas em identi�cação RFID. Identi�cação
(AVILES-LOPEZ;GARCIA-MACIAS, 2012)
Um framework de interação direta comusuário para acessar os dispositivos esuas capacidades através da internet.
Interoperabilidade
(FERREIRA; CA-NEDO; SOUSA,2013)
Uma arquitetura baseada em RESTFullpara lidar com a integração do UPnP,ZigBee e arduíno.
Interoperabilidade
(TRAGOS et al.,2014)
Um framework focado a habilitarsegurança em aplicações IoT. Segurança
(JARA et al.,2014)
Um framework focado na descobertade dispositivos em cidades inteligentesutilizando-se de uma arquitetura escalávelatravés de smartphones.
Escalabilidade
(XIAO et al.,2014)
Um framework para lidar com hetero-geneidade de dispositivos IoT atravésde técnicas de transformação.
Interoperabilidade
(KHODADADI;CALHEIROS;BUYYA, 2015)
Um framework para lidar com a integraçãode aplicações IoT de domínios especí�cos,focando na segurança da transição dosdados destes domínios.
Segurança
(PATEL; CAS-SOU, 2015)
Uma metodologia e um frameworkbaseado em MDD para facilitar a cons-trução de aplicações baseadas em IoT.
Produtividade
(PAL; MUKHER-JEE; BALAMU-RALIDHAR,2015)
Um framework baseado em MDD parafacilitar o desenvolvimento de aplicaçõesIoT voltado para o usuário �nal.
Interoperabilidade
93
(DATTA; COSTA;BONNET, 2015)
Um framework para desenvolvimento deambientes inteligentes voltados ao usuário�nal baseado em comunicações M2M.
Interoperabilidade
(BOCCHINO;FEDOR; PE-TRACCA, 2015)
Um framework baseado em Python parafacilitar a construção de aplicações IoTbaseado na construção de scripts básicos.Focado especi�camente em restrição derecursos.
Recursos Limitados
(NASTIC; TRU-ONG; DUSTDAR,2015)
Um framework que busca facilitar aconstrução de aplicações IoT através daabstração dos dispositivos como serviços naNúvem.
Produtividade
(VEN�KAUSKASet al., 2016)
Framework MDD voltado para aplicaçõesiHealth. Interoperabilidade
(PAGANELLI;TURCHI; GIULI,2016)
Um framework voltado paraa abstração de dispositivos utilizando-se derepresentação grá�ca para esta �nalidade.
Representação decoisas inteligentes
(VALLATI et al.,2016)
Apresenta uma plataforma paracomunicação M2M voltada para IoT. Interoperabilidade
(SIVIERI; MOT-TOLA; CUGOLA,2016)
Apresenta uma plataforma para facilitara construção de aplicações IoT através deAPI de serviços baseadas em CoAP eRESTFull.
Produtividade
(PUIU et al.,2016)
Uma plataforma voltada para cidadesinteligentes, visando diminuir asquestões tecnicas voltadas à heterogeneidade,comunicação interprocessos e latência.
Heterogeneidade
(JANAK;SCHULZRINNE,2016)
Um framework para facilitar o processo dedesenvolvimento de aplicações IoT através daprototipação de ambientes.
Heterogeneidade
(KUM; KANG;PARK, 2016)
Uma plataforma para lidar com a heteroge-neidade de dispositivos presentes em cidadesinteligentes. A proposta inclui o uso deWebServices.
Heterogeneidade
(HERNÁNDEZ;REIFF-MARGANIEC,2016)
Um framework conceitual voltado à aplicarautonomia às smart things de uma infra-estrutura IoT.
Heterogeneidade
94
(CALCINA-CCORI et al.,2017)
Um framework voltado para a geração decódigo dos nós IoT através de uma abor-dagem "Swarm".
Interoperabilidade
(CARRANZA-GARCÍA et al.,2016)
Uma plataforma voltada a tornar os serviçosde uma aplicação IoT orientados à núvem.De modo que a comunicação entre eles sejaintermediada pela própria plataforma.
Interoperabilidade
(MEHTA et al.,2017)
Uma abordagem voltada á extensão do frame-work Calvin para lidar com aplicações comlimitações de recursos.
Recursos Limitados
(DATTA; BON-NET, 2016)
Um framework conceitual baseado emoneM2M para simpli�car o processo dedesenvolvimento de aplicações IoT.
Múltiplos Domínios
(BRÖRING et al.,2017)
Uma plataforma para reduzir a heterogenei-dade de dispositivos em aplicações IoT, pro-pondo diversos modelos de dados e API'spara isso.
Interoperabilidade
