UNIVERSIDADE ESTADUAL DO NORTE DO PARANÁ

CAMPUS LUIZ MENEGHEL - CENTRO DE CIÊNCIAS TECNOLÓGICAS

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

RAFAEL FIGUEIRA GONÇALVES

DESENVOLVIMENTO DE FERRAMENTA PARA

GERAÇÃO DE CÓDIGO IOT DIRIGIDA A MODELO

BANDEIRANTES–PR
2019
 RAFAEL FIGUEIRA GONÇALVES

DESENVOLVIMENTO DE FERRAMENTA PARA

GERAÇÃO DE CÓDIGO IOT DIRIGIDA A MODELO

Trabalho de Conclusão de Curso apresentado

ao curso de Bacharelado em Ciência da Com-
putação da Universidade Estadual do Norte
do Paraná para obtenção do título de Bacha-
rel em Ciência da Computação.

Orientador: Prof. Dr. André Luís Andrade

Menolli

BANDEIRANTES–PR
2019
 RAFAEL FIGUEIRA GONÇALVES

DESENVOLVIMENTO DE FERRAMENTA PARA

GERAÇÃO DE CÓDIGO IOT DIRIGIDA A MODELO

Trabalho de Conclusão de Curso apresentado

ao curso de Bacharelado em Ciência da Com-
putação da Universidade Estadual do Norte
do Paraná para obtenção do título de Bacha-
rel em Ciência da Computação.

BANCA EXAMINADORA

Prof. Dr. André Luís Andrade Menolli

Universidade Estadual do Norte do Paraná
Orientador

Prof. M.e Fábio De Sordi Junior

Universidade Estadual do Norte do Paraná

Prof. Dr. Maurício Massaru Arimoto

Universidade Estadual do Norte do Paraná

Bandeirantes–PR, Novembro de 2019

GONCALVES, R. 2019. Desenvolvimento de Ferramenta para Geração de Código
IoT Dirigida a Modelo. 55 p. Trabalho de Conclusão de Curso (Bacharelado em Ciência
da Computação) – Universidade Estadual do Norte do Paraná, Bandeirantes–PR, 2019.

RESUMO

Com o passar dos anos, novas abordagens de desenvolvimento de software foram propostas
e implementadas com o intuito de melhorar o processo de desenvolvimento e o produto
final.Uma dessas abordagens é a dirigida a modelo (MDD), metodologia que permite a
geração de soluções de software por meio de modelos abstratos, que tem como objetivo
facilitar o desenvolvimento, aproximando a solução abstrata com a implementação do
problema. Outro conceito que vem tendo seu uso aumentado é a Internet das Coisas, que
permite a criação das mais diversas soluções, utilizando diferentes dispositivos conectados
por meio da internet. Contudo desenvolvedores com pouco conhecimento de domínio tem
dificuldades ao criar soluções adequadas, produzindo software com deficiências em alguns
requisitos de software, como manutenção e segurança.O trabalho propõe uma ferramenta
que auxilie na criação de novas soluções para Internet das Coisas utilizando a metodologia
dirigida a modelos. A ferramenta gera código para a plataforma Arduino a partir de
modelos editados graficamente. Espera-se que o uso da ferramenta resulte em uma maior
praticidade no desenvolvimento, até mesmo para desenvolvedores com pouco ou nenhum
conhecimento de domínio, e uma maior qualidade de software.

Palavras-chave: MDD. IoT. Geração de Codigo.

GONCALVES, R. 2019. Development of Tool for IoT code generation using Model
Driven Development. 55 p. Final Project (Bachelor of Science in Computer Science) –
State University Northern of Parana , Bandeirantes–PR, 2019.

ABSTRACT

Over the years, new software development approaches have been proposed and implemented
with the objective of improving the development process and the end product. One such
approach is the model-driven development (MDD), which enables the generation of software
solutions through models, which aims to facilitate development by bringing the abstract
solution closer to the implementation of the problem. Another concept that has been
increasing in use is the Internet of Things, which allows the creation of various solutions,
using different devices connected through the Internet. However developers with little
domain knowledge have found difficulties in creating appropriate solutions, producing
software with deficiencies in some software requirements such as maintenance and security.
The tool generates code for the Arduino platform from graphically edited models. Using
the tool is expected to result in greater development convenience, even for developers with
little or no domain knowledge, and higher software quality.

Keywords: MDD. IoT. Code Generation.

 LISTA DE ILUSTRAÇÕES

Figura 1 – Arduino UNO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figura 2 – Raspberry Pi Modelo B. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 3 – Diagrama do FRASAD para um meta-modelo de DSL (tecnologia
simples de transmissão de dados via linhas de telefone). (Fonte: [1, p. 3]) 32
Figura 4 – Exemplo de PIM fornecido pelo autor. (Fonte: [1, p. 4]) . . . . . . . . . 33
Figura 5 – Estrutura do trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 6 – Interface do UMLet com um modelo em etapa de edição, podendo notar
que os elementos customizados estão presente na paleta a direita superior) 37
Figura 7 – Metamodelo por nós sugerido para Internet das Coisas . . . . . . . . . 41
Figura 8 – Modelo originalmente utilizado para testes . . . . . . . . . . . . . . . . 43
Figura 9 – Modelo utilizado para testes . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 10 – Fluxograma arquitetural presente em versão anterior do gerador . . . . 44
Figura 11 – Fluxograma arquitetural presente na versão atual do gerador . . . . . . 44
Figura 12 – Arquivo XML proveniente do UMLet . . . . . . . . . . . . . . . . . . . 48
Figura 13 – Execução da ferramenta por meio da linha de comando . . . . . . . . . 48
Figura 14 – Amostra do código funcional da tomada de decisão, gerado pela ferramenta 48
LISTA DE TABELAS
 LISTA DE ABREVIATURAS E SIGLAS

IoT Internet of Things

WYSIWYG What You See Is What You Get

MDD Model Driven Development

QoS Quality of Service

GUI Graphical User Interface

UML Unified Modeling Language

IDE Integrated Development Environment

PIM Platform-Independent Model

PSM Platform-Specific Model

RISC Reduced Instruction Set Computer

OMG Object Management Group

MDA Model Driven Architecture

 SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Formulação do Problema . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 23
2.1 Desenvolvimento Dirigido a Modelos . . . . . . . . . . . . . . . . 23
2.1.1 Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Transformações de Modelos . . . . . . . . . . . . . . . . . . . . . 24
2.1.3 Geração de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Plataformas para IoT . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1.2 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 Sistemas de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.2.1 Estruturas Comunicantes . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1 FRASAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 MDE4IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Engenharia de Software Orientada a Modelos MDD . . . . . . 35
3.2 Seleção dos Parâmetros de Escopo do Trabalho . . . . . . . . . 36
3.3 Edição do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 UMLet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Seleção de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Desenvolvimento da ferramenta . . . . . . . . . . . . . . . . . . . 38
3.5.1 Linguagem de Programação . . . . . . . . . . . . . . . . . . . . . 38
3.5.2 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . 39

4 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Abordagem proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Desenvolvimento do Gerador . . . . . . . . . . . . . . . . . . . . . 44

5 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 CONCLUSÃO E DISCUSSÃO . . . . . . . . . . . . . . . . . . . 49
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Trabalhos Publicados pelo Autor . . . . . . . . . . . . . . . . . 55

1 INTRODUÇÃO

Neste capítulo introdutório são apresentados a contextualização e problematização

do projeto, e a seguir a justificativa, os objetivos e a organização do trabalho.

1.1 Contextualização

Nos últimos anos as pesquisas e aplicações reais da Internet das Coisas cresceram
exponencialmente, com o intuito geral de aumentar o conforto pessoal, ao conectar as coisas
em nossa volta. O percentual da população mundial com acesso a internet aumentou em
1125% de 2000 a 2019 (World. . . [2]). De acordo com Howell[3] o numero de dispositivos
conectados (desconsiderando computadores e smartphones) vai de 27 bilhões em 2017 para
a projeção de atingir 125 bilhões até 2030. A Internet das Coisas prevê uma variedade de
novas aplicações, segundo Gubbi et al.[4] essas tecnologias são ideais para inovações, sendo
limitadas somente pela criatividade de seus realizadores. Essas aplicações são resultantes
da possibilidade de embarcar inteligência computacional nos mais diversos dispositivos,
e integrá-los por meio de redes de computadores a outros dispositivos, computadores e
pessoas. Essa nova tecnologia permite que sejam criadas as mais diversas aplicações, tais
como ambientes mais qualificados em quesitos de praticidade e utilidade, como casas e
escritórios inteligentes capazes de coletar e entregar dados para seus usuários, além de
cumprirem ações que os auxiliem.
Com essa recente amplificação do nível de acesso a essas tecnologias, alguns autores
como Schwab e Davis[5] trazem um apelo para que cada individuo faça parte desta
robotização do mundo e "humanização das coisas", porém apesar de seu ótimo nível de
disponibilidade não significa que a criação destas soluções seja algo simples; estas soluções
especificamente projetadas para Internet das Coisas normalmente necessitam da integração
e comunicação de sensores entre outros tipos de dispositivos a programas computacionais
complexos como o processamento de uma grande quantidade de dados. Outro obstáculo no
desenvolvimento para a Internet das Coisas se porta como os diversos desafios inexistentes
(com a mesma magnitude) em outras plataformas como Mobile e Desktop, um dos maiores
desafios é entregar os requerimentos constantes de fatores como segurança e disponibilidade,
apesar do baixo poder computacional e pouca energia disponível em dispositivos nós, o
que necessita de uma optimização extrema de eficiência.
Existem algumas plataformas que auxiliam o desenvolvimento destes tipos de
aplicações, tais como as soluções Arduino (Javed[6]) e Raspberry (Grimmett[7]), Arduino
é uma plataforma de código aberto, incluindo seu hardware enquanto o Raspberry trabalha
com sistemas operacionais abertos. Estas plataformas permitem a prototipagem eletrônica
16

de hardware a partir de uma placa de circuito integrado, projetada para fornecer um

microcontrolador com suporte de entradas/saídas embutidos, e que pode ser ligado a um
computador para programá-la. Plataformas como essas são utilizadas nos processos de
prototipação de soluções para Internet das Coisas, conectando sensores e dispositivos no
microcontrolador antes de produzir o projeto embarcado e/ou proprietário em massa,
assim reduzindo custos.
Como foi discutido, o desenvolvimento de aplicações para Internet das Coisas é
bastante complexo, por trazer novos desafios comparado a tecnologias de computação mais
tradicionais, e também pela grande quantidade de plataformas e diferentes fornecedores
existentes, fazendo com que essas implementações não tenham padronização.
Um conceito que pode auxiliar a minimizar estes problemas é o Model-Driven
Development (MDD), que é uma metodologia de desenvolvimento dirigida a modelos que
permite desenvolver códigos a partir de modelos de um alto nível de abstração, facilitando
o cumprimento com padrões. Sua função basicamente é transformar um modelo de software
em código executável e editável, seja integralmente ou parcialmente, variando de acordo
com as necessidades de seu modelo, diminuindo o conhecimento de domínio necessário
para o desenvolvimento por parte de toda equipe e evitando a produção de erros. Citamos
nas justificativas os motivos que nos levam a acreditar que esse tipo de metodologia é
especialmente adequada para o desenvolvimento da Internet das Coisas.
Com o advento da internet das coisas, surgiu também um conceito para a união
desses dispositivos conectados, os Sistemas de Sistemas, onde cada sistema como um único
eletrodoméstico inteligente se relaciona com outros para que todos juntos façam parte de
um sistema maior, como uma casa ou cidade inteligente, como exemplificado por Lea e
Blackstock[8]. Esse conceito vem tomando espaço no mercado, cada vez mais levando o
foco para uma visão geral e superficial do todo, possibilitando que as falhas presentes na
tecnologia atualmente continuem se multiplicando de forma silenciosa.

1.2 Formulação do Problema

Como citado no subseção anterior, o alcance das tecnologias relacionadas à Internet

das Coisas vem crescendo cada vez mais, porém o cumprimento das metas de qualidade
aplicadas não tem acompanhado o mesmo crescimento, em parte devido à união de alguns
fatores principais:

• A falta de conhecimento de domínio causada pela imaturidade de ambas partes,

tecnologias e desenvolvedores.

• Conforme mostrado por Humphrey[9] existe a tendencia no aumento do numero

de desenvolvedores individuais, o que dificulta entre outros fatores na adoção de
 17

métodos de melhoria de processos.

• O estado atual do mercado, onde soluções podem ser condenadas inviáveis em con-
sequência de não estar disponível o quanto antes possível, muitas vezes negligenciando
ou sacrificando fatores de qualidade para atender esses prazos mais curtos. Fitzgerald
e Stol[10] citam os eventuais problemas encontrados ao ignorar etapas importantes
na engenharia de software, como o planejamento e testes.

• Para sistemas já existentes existe o grande desafio de dar a manutenção adequada,

visto que como mencionado por ambos Zhu et al.[11] e Babar, Ramzan e Ghayyur[12]
as falhas no desenvolvimento vão se amplificando com o tempo, dificultando tarefas
de manutenção como a eliminação de bugs e refatoração, sem os devidos cuidados,
essas tarefas podem ate diminuir a qualidade do software.

Ray et al.[13] denotam alguns outros fatores bem conhecidos que podem influenciar na
qualidade de código, como tamanho do código, tamanho da equipe de desenvolvimento e
maturidade dos processos.
Em uma pesquisa sobre métodos específicos para Internet das Coisas (Imani et
al.[14]) determina 10 áreas problemáticas para Internet das Coisas:

1. Interoperabilidade de padrões:
Muitas tentativas de padronizações específicas para Internet das Coisas existem
atualmente, provenientes de empresas e comissões de todo o mundo como ETSI
(European Telecommunications Standards Institute), CEN (European Committee
for Standardization), ISO (International Organization for Standardization) e ITU
(Telecommunication Standardization Sector). Apesar desses esforços a padronização
continua um problema para a Internet of Things, segundo Atzori, Iera e Morabito[15]
isso é causado pela falta de um framework compreensivo e adequado capaz de
integrar os diferentes padrões, que possa ser utilizado sem causar resistências aos
desenvolvedores.

2. Suporte para mobilidade:

Um critério a ser usado em dispositivos conectados, para cumprir com o objetivo de
tornar a experiência do usuário com a Internet of Things transparente e contínua.

3. Endereçamento de objetos inteligentes:

Esquemas atuais de endereçamento como IP e URI são ineficientes para dispositivos
inteligentes, devido à demasiada complexidade, além do fator limitador de tamanho,
IPv4 tem um limite de 232 ( 4.29 bilhões) dispositivos, um dos padrões propostos é
o 6LoWPAN, que contem 2128 ( 340 undecilhões), um numero 79 octilhões maior,
garantindo que não teremos uma falta de endereços em um futuro próximo.
18

4. Protocolos de Transporte:
Protocolos existentes atualmente no mercado e implementados em outros contextos
não são ideais para uso com a Internet das Coisas, a despesa de recursos é inade-
quada e seus mecanismos de controle de congestionamento muitas vezes são inúteis
nessas aplicações. Protocolos específicos como 6LowPAN (IPv6 Low-power Wireless
Personal Area Network) são usados de uma maneira dispersa.

5. Suporte para QoS (Quality of Service):

Os padrões de QoS devem ser reestruturados especificamente para Internet of Things
visto que atualmente continua-se a usar as mesmas especificações de machine-to-
machine (Atzori, Iera e Morabito[15]).

6. Autentificação:
Existe uma falta de infraestrutura para autenticação em cenários de Internet of
Things, um dos desafios intensificados pelo menor número de recursos computacionais
e preocupação com o consumo de energia.

7. Integridade dos dados:

Devido a mesma falta de recursos, a integridade dos dados se torna comprometida por
motivos simples, como o menor tamanho alocado para senhas e chaves de segurança,
necessitando urgentemente de uma solução inovadora.

8. Privacidade:
Nas atuais soluções temos uma situação onde o usuário final não consegue, de uma
maneira viável, ter um controle sobre quais informações privativas (das muitas
coletadas) pelos dispositivos conectados, estão sendo compartilhadas ou não, um
desafio exagerado pela imaturidade das leis relacionadas.

9. Segurança: Um fator que afeta e é afetado por outros itens nessa lista como Auten-
tificação, Integridade dos dados e privacidade, dispositivos de Internet of Things
são por natureza extremamente suscetíveis a ataques man-in-the-middle onde um
intruso se coloca entre dispositivos e livremente coleta informações, nenhuma solução
ate o momento previne esse e outros tipos de ataque (Atzori, Iera e Morabito[15]).

10. Esquecimento Digital:

Essa informação privativa do usuário tem um grande valor para empresas, esse valor
atualmente é exponencialmente maior que o custo para mantê-las de forma indeter-
minada, esse é outro assunto atualmente em pauta com o intuito de regulamentações,
por conta de ser um problema inexistente na maioria dos casos a partir da década
passada.
 19

A utilização de modelos no desenvolvimento da Internet of Things poderia amenizar todas

essas 10 áreas problemáticas determinadas, visto que elas possuem o tema comum de falha
de adoção a tecnologias e padrões, o que poderia ser remediado com os seguintes pontos:

• A imposição de padrões e protocolos já previstos no modelo:

Reduziria os custos de implementação, removendo a necessidade de conhecimento de
domínio por parte do time de desenvolvedores, removendo totalmente o incentivo da
utilização de uma tecnologia inadequada pelo profissional ter uma maior intimidade
com a mesma.

• Delegação de parte do trabalho humano para a ferramenta:

A automatização na geração de códigos e tomada de decisões sobre qual protocolo
usar por exemplo, causa uma menor produção de erros, impondo também que o
desenvolvedor aplique boas práticas de desenvolvimento sem mesmo se perceber.

Diante das possíveis vantagens citadas, portadas pela metodologia dirigida a

modelos, esse trabalho propõe a adesão da metodologia por meio de uma ferramenta
adequada, que providencie um framework de trabalho com o intuito de auxiliar na criação
de soluções para Internet das Coisas, simplificando e reduzindo os custos relacionados ao
desenvolvimento.

1.3 Justificativas

Como foi visto, segundo Nguyen et al.[1] o desenvolvimento dirigido em modelos se

apresenta como uma ótima maneira de reduzir a complexidade das soluções especificamente
Internet das Coisas, principal razão para qual ser um desenvolvimento intrinsecamente
modular e extremamente susceptível a reusabilidade, visto que muitas vezes uma mesma
solução pode conter múltiplos componentes e subcomponentes semelhantes se não idênticos,
tais soluções sofreriam uma redução de custos de desenvolvimento de forma descomunal.
Justificamos a busca da produção de uma abordagem adequada ao desenvolvimento
para Internet das Coisas pela carência de tal. O trabalho de Kapteijns et al.[16] que tinha
como objetivo comparar técnicas de desenvolvimento tradicionais com o MDD, conclui
que o MDD atualmente ainda não entrega aquilo que promete (aumento em produtividade
em desenvolvimento e manutenção devido ao reuso e alto nível de abstração), atribuindo
essa falha a dificuldade na utilização das ferramentas presentes no momento, e que os
resultados devem ser utilizados para a produção de soluções melhores no futuro.
A ferramenta proposta tomaria de um desenvolvedor, responsabilidade por parte
do trabalho de desenvolvimento, produzindo de uma forma rápida e automática além
de estar eliminando a produção de erros nas tarefas delegadas. Muitos desenvolvedores
20

estão preocupados em conectar e fazer funcionar seus dispositivos, seguindo uma forma
de pensar próxima ao MVP (Minimum Viable Product, Produto Mínimo Viável, termo
muito utilizado em meios empresariais, onde o objetivo é a produção de um protótipo/uma
amostra do produto final teórico), essas aplicações frequentemente sofrem na falta de
consideração dos impactos que a solução proposta acarretará no futuro.
No caso de protótipos, os mesmos deveriam sofrer reformulações severas no momento
que saem da fases de teste e antes de entrar em uma escala de produção em massa, o
que tende a não ser feito devido aos custos e falta de retorno imediato. Essas decisões
de projetos tomadas visando benefícios em curto prazo, geralmente levam a sistemas de
difícil manutenibilidade e portabilidade, características fundamentais de aplicações para
Internet das Coisas. Além disso, muitas vezes é difícil fazer com que os dispositivos e
sensores funcionem adequadamente na plataforma desejada, principalmente por virem de
fornecedores distintos.
A metodologia dirigida a modelos é uma estrutura de engenharia de software que
por trabalhar com um nível de abstração mais alto e o reuso de código, consegue simplificar
o desenvolvimento desses projetos, sem que os mesmos sofram por isso. O único obstáculo
previsto após a analise da literatura é a dificuldade de adoção da ferramenta por parte
dos desenvolvedores, por isso a ferramenta deve ser extremamente intuitiva.
As amostras de código resultante da produção com a ferramenta e da etapa de
pesquisa serão analisadas individualmente e comparadas através de métricas de software,
McDonald e Goggins[17] defende a validade da utilização de métricas para mensurar a
qualidade de software ou a performance do mesmo, assim como referencia diversos estudos
de sucesso que demonstram a validade da abordagem às métricas. Além disso, Xenos et
al.[18], apresenta em seu estudo, que é bem conceituado, a validade de cada uma das
métricas, viabilizando a utilização de sua pesquisa para os fins deste trabalho.

1.4 Objetivos

1.4.1 Objetivo Geral

Este trabalho tem como objetivo geral desenvolver uma ferramenta para geração
de soluções para Internet of Things baseada no desenvolvimento dirigido à modelo.

1.4.2 Objetivos Específicos

Podemos dividir o objetivo geral nos seguintes itens:

• Selecionar plataformas e linguagens de escopo para o trabalho

• Pesquisar e selecionar códigos para amostra, utilizados na comparação com o código

gerado
 21

• Gerar meta modelo

• Criar ferramenta

• Pesquisar e selecionar critérios e métricas

• Gerar diversas soluções Internet of Things rela

• Comparar código gerado com amostra

• Avaliação do trabalho

1.5 Estrutura do Trabalho

Neste capítulo, foi abordada a contextualização, a formulação do problema, e as

justificativas e objetivos. O capítulo 2 aborda toda a fundamentação teórica utilizado
como base para o trabalho. O capítulo 3, demonstra e esclarece o método abordado no
trabalho.Em seguida, no capítulo 4, é apresentado o que foi desenvolvido.
2 FUNDAMENTAÇÃO TEÓRICA

Esse capitulo apresenta uma introdução dos conceitos utilizados neste trabalho.

2.1 Desenvolvimento Dirigido a Modelos

Model-Driven Development é uma abordagem que permite desenvolver códigos a

partir de modelos de aplicações com um alto nível de abstração que a represente, resultando
em implementações concretas, e diminuindo a distancia entre a solução e implementação.
Stahl, Voelter e Czarnecki[19] compila uma lista de objetivos para o desenvolvimento
de software dirigido a modelos:

• Aumento da velocidade de desenvolvimento, devido à automação, código executável

pode ser extraído de modelos formais através de transformações.

• O uso destas transformações permite a melhoria da qualidade de software, visto que

após sua definição, uma arquitetura vai ser aplicada de forma uniforme em toda a
solução.

• Implementações Cross-cutting (aspectos de um software que são referenciados em

outros lugares) podem ser editados em um só lugar, assim como a correção de erros
no código gerado.

• Arquiteturas uma vez definidas podem ser utilizadas como parte de uma linha de
produção para outros sistemas de software, aumentando a reusabilidade.

• Transforma a complexidade mais gerenciável através do nível de abstração, a edição

dos modelos de alto nível pode substituir parte da programação.

• Oferece um ambiente que incentiva boas práticas nos campos de tecnologia, enge-
nharia e gerência.

2.1.1 Modelos

Segundo Mellor, Clark e Futagami[20] um modelo no contexto de desenvolvimento

dirigido a modelo deve ser composto de um conjunto coerente de elementos formais que
descrevem o objeto, e que seja favorável para algum tipo de análise. Quanto mais alto o
nível de abstração desse modelo, mais próximo o modelo está da solução em uma linguagem
menos técnica, facilitando a leitura para usuários e desenvolvedores.
Um modelo, como descrito por Stahl, Voelter e Czarnecki[19] é uma representação
abstrata da estrutura de um sistema, função ou comportamento, esses modelos normalmente
24

são definidos utilizando UML. Diagramas UML não são automaticamente modelos, o
que os distingue são as semânticas utilizadas nos modelos, a serem interpretadas pela
linguagem de modelagem correspondente, responsável de seguir suas regras para aplicar as
transformações,
Metamodelo segundo Stahl, Voelter e Czarnecki[19] é um dos aspectos principais
do MDD, pois auxilia nos seguintes desafios:

• Na construção das linguagens de modelagem específica a modelos (DSLs), descrevendo

suas sintaxes abstratas.

• Na variação de modelos: os modelos são validados com as restrições previstas no

metamodelo.

• Transformações de modelos para modelos, são especificadas em metamodelos.

• Geração de código; a ferramenta de geração referencia o metamodelo da linguagem

para a geração de código.

• Integração com ferramenta, ferramentas podem ser adaptadas para domínios especí-
ficos a partir do metamodelo.

Metamodelo são modelos com declarações sobre a modelagem, ele descreve as

possíveis estruturas dos modelos, seus relacionamentos, restrições e regras de modelagem,
mas não a sintaxe concreta da linguagem. Ele define a sintaxe abstrata e as semânticas
estáticas da linguagem de modelagem. Modelos e metamodelos têm relações de herança,
sendo modelos instâncias de metamodelos.

2.1.2 Transformações de Modelos

Dentro dessa metodologia á diversos níveis de modelos, e esses passam por trans-
formações para chegarem uma representação abstrata até uma implementação concreta.
PIM(Plataform-Independent Model) é o modelo independente de plataforma, que
segundo Ayed, Delanote e Berbers[21] se distingue por não ter algum detalhe técnico,
enquanto o PSM(Plataform Specific Model) é uma representação do mesmo sistema,
porém contendo todos os detalhes técnicos necessários para implementar esse modelo em
uma plataforma concreta. A separação destes dois modelos é um conceito chave para a
arquitetura orientada a modelos da OMG (Object Management Groups), pois trabalham
com o fato de conceitos serem mais estáveis que tecnologias e que modelos formais são mais
úteis para transformações automáticas (Stahl, Voelter e Czarnecki[19]). O mapeamento
de PIM para PSM é feito por meio de uma transformação automática, produzida com o
auxílio de alguma ferramenta específica para MDD, transformações são possíveis entre
modelos e de modelos para código-fonte.
 25

É importante recordar como notado por Stahl, Voelter e Czarnecki[19], que a

definição destes modelos são conceitos relativos para cada plataforma e que estas não
possuem um nível de abstração definido.

2.1.3 Geração de Código

Stahl, Voelter e Czarnecki[19] apresentam alguns motivos para a geração de códigos

executáveis por meio do MDD:

1. Performance: segundo os autores o principal incentivo na geração de códigos con-

tinua sendo o desejo de manter uma performance alta junto com um bom nível
de flexibilidade, o que dificilmente é tangível com metodologias tradicionais como
frameworks e polimorfismo.

2. Volume de código: o tamanho do código pode ser facilmente otimizado com a geração
de código, visto que no momento da compilação o gerador pode incluir somente
aquilo que será necessário em momento de execução

3. Analisabilidade: frameworks complexos e genéricos tendem relocar complexidade

atribuída a linguagem de programação para sua configuração proprietária, o que é
um obstáculo na interpretação desta solução, código gerado pode ser analisado como
se tivesse sido programado manualmente.

4. Detecção antecipada de erros: sistemas flexíveis tem a opção de utilizar linguagens

fracamente tipificadas, habilitando a escolha de tipos em tempo de execução, o que
normalmente é considerado má pratica por dificuldades de manutenção, o que pode
ser aliviado pela geração de código.

5. Compatibilidade de plataforma: pelo fato da lógica ser programada em um nível

distinto da plataforma de implementação, isso deixa mais fácil a transição para
plataformas diferentes ou mais novas.

6. Restrições de Linguagem: com a geração de códigos é possível contornar limitações

causadas por limitações da linguagem, como até implementar soluções orientada a
objetos a linguagens não-orientadas.

7. Aspectos: propriedades de cross-cutting como persistência pode ser implementado

em um lugar único na solução gerada.

8. Introspeção: o acesso de leitura do software a si mesmo, com a geração de códigos,

essa estrutura pode ser gerada em tempo de geração, antes da execução e acesso.
26

2.2 Internet of Things

Segundo Asghar, Negi e Mohammadzadeh[22] a Internet das Coisas é uma extensão

da internet no mundo real por meio de objetos conectados. No survey de Atzori, Iera
e Morabito[15], onde expõe os principais desafios da tecnologia, o autor define a ideia
da forma mais básica possível: o conceito que ele define como presença penetrante ou
universal, visto que esses objetos tem como principal objetivo cumprir suas funções de
forma abstrusa.
Internet das Coisas é um conceito que está deixando de fazer parte da "Internet
do Futuro" como descrito originalmente por Tan e Wang[23] em 2010, o qual a Internet
das Coisas se define por objetos inteligentes que se conectam e trocam informação entre
si, fugindo da conexão convencional "humano-humano". O autor considera uma série
de tecnologias específicas para Internet das Coisas, como o RFID (Identificação por
Frequência de Radio), tal tecnologia já está presente em algumas áreas como comércio e
saúde. O amadurecendo dessa tecnologia traz grande potencial para a Internet das Coisas,
diminuindo a distância entre o mundo físico e o da informação.
Tan e Wang[23] define as tendências da Internet das coisas em 3 categorias:

• Inteligência embarcada: se trata de ações executadas de maneira automática com

base em alguma informação obtida pelo sistema, normalmente estas informações são
produzidas por mais de um objeto na rede.

• Conectividade: para que o sistema funcione todos o dispositivos devem estar co-
nectados, a conectividade é uma possibilidade para a Internet das Coisas. Além
de estarem conectados, as ’coisas’ devem poder se comunicar livremente entre elas.
Arquiteturas como os protocolos usados hoje, tais como TCP/IP, foram suficientes
até o momento, porém para a internet das coisas necessitamos de uma quantidade
de banda e endereçamento muitas vezes maior. O autor realça a necessidade de uma
nova arquitetura, que contenha itens como QoS (Quality of Service), segurança e
privacidade, esse é um dos itens tratados na Formulação do Problema 1.2.

• Interação: também definida aqui como interoperabilidade, o qual sistemas de In-

ternet das Coisas já existentes, como hospitais inteligentes, acabam trabalhando
sozinhos. A falta de padronização da comunicação entre esses dispositivos dificulta as
relações coisa-coisa. O autor propõe a adição de uma camada de coordenação para a
arquitetura, visando reestruturar os pacotes das aplicações de maneira unificada.

Coetzee e Eksteen[24] também cita a Internet das Coisas como parte da "Internet
do Futuro", o autor cita alguns fenômenos como:

• a rápida adoção da internet, e após disso, das redes sociais.

 27

• a tendência em países em desenvolvimento como a África, de ter dispositivos móveis

como contato primário de acesso, ao contrário de computadores de mesa.

• o fato de cada vez mais ’coisas’ serem equipadas com diversas tecnologias como tags
de RFID ou QR-codes

Segundo Coetzee e Eksteen[24], todos esses fenômenos contribuem para uma progressão
natural, que nos leva a Internet das Coisas.
O autor referencia o trabalho de Fleisch et al.[25] o qual identifica sete principais
aplicações de propostas de valor, o qual as quatro primeiras são baseadas em relações
coisa-coisa e as tres últimas criam valor com a integração coisa-usuário:

• Gatilho simples e manual de proximidade: são coisas que comunicam quando algo
se move dentro do seu espaço de leitura, comunicando sua identidade, podendo
acarretar em uma ação.

• Gatilho automático de proximidade: sensor de proximidade entre dois objetos, pas-

sando informação de distância e identificador dos objetos.

• Gatinho automático de sensores: coletor de dados por meio de sensores como tem-
peratura, velocidade, orientação e umidade, essa informação é comunicada com o
objetivo de tomada de decisões, muitas vezes também automatizadas.

• Segurança de produto automática: um objeto pode conter informações de segurança

a ser utilizado em momentos específicos.

• Feedback de usuário direto e simples: mecanismos simples implementados em objetos

que podem oferecer informações de feedback ao usuário presente naquele ambiente,
muitas vezes por meio de sinais visuais ou audíveis.

• Feedback de usuário extenso: providenciam um nível mais de informação, normalmente

o objeto serve de portal para um serviço conectado.

• Feedback para mudança de mente: combina o mundo físico com o virtual para gerar
um novo nível de alterações em comportamentos humanos.

Coetzee e Eksteen[24] identificam também os desafios da tecnologia, desde a

carência de políticas até a parte técnica, ele os classifica em 3 áreas chaves:

• Da parte social, a Internet das Coisas acaba possibilitando que os direitos de

privacidade e segurança do usuário final sejam comprometidos

• Padronização para alcançar a interoperabilidade de objetos provenientes de fontes

diversas.
28

• Excesso de dados, a quantidade de dados em grande escala gera um desafio ao

nível de infraestrutura, o autor se questiona se esses dados devem ser processados,
armazenados para futuras gerações, etc.

No trabalho de Truong e Dustdar[26] são reportados os princípios a serem adotados

em implementações para Internet das Coisas, a motivação do trabalho é a vasta adoção da
tecnologia em diversas subáreas de atuação como Cidades Inteligentes, e sistemas de saúde.
Ainda no trabalho de Atzori, Iera e Morabito[15] é concluído que da mesma maneira que
a Internet vem moldando drasticamente a maneira que vivemos em diversos contextos,
a Internet das Coisas tem o grande potencial de adicionar uma nova dimensão por meio
de objetos inteligentes que comunicam-se entre si, habilitando uma dinâmica inédita de
computação distribuída e disponível em escalas ainda não vistas.
A Internet das Coisas traz diversos desafios de desenvolvimento não presentes em
outras áreas como Desktop e Mobile, por exemplo o justo acoplamento entre Software e
Hardware, restrições menores de consumo de energia, requerimento maior de disponibilidade
e performance e a mais fácil exposição a ataques de rede.

2.2.1 Plataformas para IoT

Como vimos anteriormente, não existe uma padronização oficial para a classificação
de Internet das Coisas para um dispositivo, a partir deste principio, qualquer computador
que tenha alguma entrada ou saída para usuários ou sensores e que esteja conectado a
rede pode ser definido como tal. Contudo, existem plataformas mais adequadas para tal
tarefas, como o Arduino e o Raspberry Pi.
O mais próximo de padronização atualmente é devido ao monopólio de mercado
da plataforma Arduino, os fabricantes de componentes de fácil acesso para prototipação,
como módulos e sensores com conversores analógico-digital embutidos, ou os fabricam
especificamente para o Arduino ou pelo menos a suportam. A plataforma Raspberry Pi
tem um suporte nativo aos módulos e bibliotecas para Arduino.

2.2.1.1 Arduino

Arduino é um projeto de código aberto, suas placas únicas normalmente contém

micro-controladores de 8 bits provenientes da Atmel, com arquitetura AVR (Alf and
Vegard’s RISC processor), porém alguns modelos mais avançados com processadores 32
bits ARM e x86. São placas extremamente populares na comunidade de "makers", presente
em projetos caseiros e prototipações de produtos comerciais, isso tudo devido ao sua
facilidade de uso e baixo custo Javed[6].
Arduinos podem ser programados em qualquer linguagem compilada que produza
o código binário para a plataforma alvo, porém as linguagens mais populares são C e C++
 29

por serem suportadas pela IDE oficial. O Arduino Uno (figura 1) é o modelo mais popular
por ter uma quantidade alta de conexões e processamento com um custo baixo, comparado
com outros modelos.

Figura 1 – Arduino UNO.

2.2.1.2 Raspberry Pi

Raspberry Pi é uma plataforma de desenvolvimento que também apesar de não ser

criada exclusiva para Internet das Coisas, é muito competente para este fim. O modelo "B"
(figura 2) é o mais novo e mais potente no momento.

Figura 2 – Raspberry Pi Modelo B.

Severance[27], o criador da Fundação Raspberry Pi, descreve a criação do mini

computador com o intuito de ser vendido por menos de 25 dólares e com seus componentes
expostos ao usuário.
Diferente dos micro-controladores da Atmel presentes na maioria da linha Arduino,
as placas Raspberry Pi apresentam processadores da arquitetura ARM (prevalente em
smartphones e tablets) produzidos pela Broadcom, são capazes de executar sistemas
operacionais como:
30

• Windows 10 IoT Core, sucessor do Windows Embedded Compact, uma versão do

Windows 10 gratuita disponível para dispositivos de baixo custo

• RISC OS, sistema desenvolvido para a arquitetura ARM, suportando a arquitetura

RISC (Computador com um conjunto reduzido de instruções), desenvolvido em um
kernel para tarefas únicas

• Inúmeras distribuições do Linux (alteradas para funcionamento no arquitetura ARM,

ao invés de x86 convencionalmente encontrado em computadores pessoais), algumas
com funcionalidades especificas embutidas para usuários finais com fins de por
exemplo emuladores de jogos e centro de mídia.

• Outros sistemas como micro-kernels (para o desenvolvimento de sistemas unix ou

não) e OpenWrt (projeto aberto para sistemas embarcados em roteadores)

Além de suportar sistemas operacionais, enquanto comparamos com a plataforma

Arduino, as placas Raspberry Pi tem um custo maior, uma performance de processamento
superior, com um consumo mais elevado de energia.
A vasta galeria de módulos desenvolvidos especificamente para Arduinos também
são suportadas em placas Raspberry Pi

2.2.2 Sistemas de Sistemas

A Internet das Coisas sendo definida como a reinvenção de um único objeto, a

união de múltiplos dispositivos conectados formam o conceito de Sistemas de Sistemas,
onde cada objeto/sistema, como por exemplo um único eletrodoméstico inteligente pode se
relacionar com outros, para que todos juntos façam parte de um sistema maior como uma
casa ou cidade inteligente, como exemplificado por Lea e Blackstock[8]. Este conceito de
computação distribuída ainda não tem uma padronização, mas em geral espera-se que o
sistema total entregue mais funcionalidades que simplesmente a soma de seus sub-sistemas.
Kotov[28][p.2] nos traz exemplos de alguns Sistemas de Sistemas já presentes em 1997
como:

• servidores e clusters de multiprocessadores;

• intranets empresariais de suporte a processos de negócio;

• sistemas globais e distribuídos para aplicações de missões criticas;

• sistemas distribuídos de controle;

• sistemas distribuídos de design e produção;

• World-Wide Web;
 31

O autor também considera a combinação de qualquer um dos sistemas citados como um

novo Sistema de Sistemas, cada um destes devendo satisfazer requerimentos rigorosos e
específicos como tempo de resposta, alto limite de banda, escalabilidade, flexibilidade,
disponibilidade, manutenibilidade, confiabilidade, tolerância a erros e recuperabilidade.
Um dos maiores desafios atuais para os Sistemas de Sistemas se encontra no fato de ter que
satisfazer estes requerimentos com a menor quantidade de recursos financeiros possíveis,
devido a peculiaridade normalmente apresentada nestes sistemas.

2.2.2.1 Estruturas Comunicantes

Kotov[28] propõe uma forma de visualizar sistemas de informação como Estruturas

Comunicantes, de uma maneira uniforme e sistemática. Essa modelagem são relacionadas
entre si de acordo com o tráfego e posicionamento dos dados, com o objetivo de:

• Avaliar vários critérios de performance de um sistema.

• Identificar congestionamentos ou comportamento não previsto.

Denominado como Communicating Structures Library (CSL), é apresentado como

uma implementação orientada a objetos para a modelagem de Sistemas de Sistemas,
apresentando uma estrutura hierárquica de nós conectados por links, onde dados podem
trafegar de um nó ao outro por esses links.

2.3 Métricas

A aplicação das métricas de software é uma forma de quantificar qualidade de

acordo com os critérios selecionados Nuñez-Varela et al.[29]. Segundo Xenos et al.[18] a
seleção de quais métricas seriam utilizadas deve ser feita de acordo com o projeto em
questão, visto que as métricas inadequadas vão gerar um resultado igual, porém o mesmo
pode ser irrelevante para a análise.
Segundo Martin[30] a metodologia de programação orientada a objetos por si só
não é suficiente para melhorar soluções de software, deixando-as com estruturas mais
robustas, de mais fácil manutenção e reusabilidade, que para realmente aferir esses critérios
é necessária a análise do código por meio de métricas especificas para examinar as
dependências entre objetos.

2.4 Trabalhos Relacionados

Devido ao grande número de vantagens do desenvolvimento dirigido a modelos,

quando aplicado a Internet a Coisas conforme apresentado na Seção 1.3, existe também
um grande número de propostas de abordagens que utilizam a mesma metodologia para
32

o desenvolvimento Internet das Coisas. Essas propostas são recentes e a cada ano mais
abundantes. Nesta seção vão ser analisadas algumas destas com o intuito de contrastar
com a abordagem proposta neste trabalho.

2.4.1 FRASAD

Framework for Sensor Application Development foi proposto por Nguyen et al.[1]
com o intuito de criar um framework capaz de lidar com a heterogeneidade e a complexidade
dos sensores e sistemas para a Internet das Coisas
Podemos reparar uma das principais diferenças de implementação em seu diagrama
3, ele não contem as afirmações necessárias para a tomada de decisões, o autor explica
que as condições lógicas são configuradas com flags específicas e proprietárias

Figura 3 – Diagrama do FRASAD para um meta-modelo de DSL (tecnologia simples de

transmissão de dados via linhas de telefone). (Fonte: [1, p. 3])

Na sua interface gráfica (Figura 4) nota-se que a edição de tomada de decisões não
somente é mais escrita do que visual mas como também se torna bastante prolixa por
haver código boilerplate e o usuário final acaba tendo que digitar os métodos previstos no
modelo. Atualmente o framework suporta somente modelos a partir do meta-modelo de
 33

Figura 4 – Exemplo de PIM fornecido pelo autor. (Fonte: [1, p. 4])

DSL, o autor cita que seu framework estaria disponível no formato de um plug-in para a
IDE Eclipse, porém até a data desta publicação o framework não foi encontrado.

2.4.2 MDE4IoT

Ciccozzi et al.[31] Define MDE (Model Driven Engineering) como um facilitador

chave quando o assunto é Internet das Coisas, o autor propõe uma abordagem que ele
chama MDE4IoT e foca na auto-adaptação de sistemas/dispositivos para Internet das
Coisas.
A abordagem foi validada usando o caso conhecido como "Semáforos Inteligentes",
onde todos os subsistemas do cenário estão conectados entre si por uma rede, ao ocorrer
uma falha em um dos semáforos, o modelo do MDE4IoT trata o caso (em tempo de
execução, pois tal caso foi previsto no meta-modelo). A abordagem seria aplicável dentro
de uma ferramenta para implementação, no momento porém existe somente como um
estudo metodológico, sem uma ferramenta para implementação.
3 METODOLOGIA

Nesse capítulo são descritos os materiais e métodos utilizados no desenvolvimento

do trabalho de pesquisa, assim como no desenvolvimento da ferramenta em si.

3.1 Engenharia de Software Orientada a Modelos MDD

Segundo o objetivo é uma pesquisa aplicada, que se define por tem um objetivo na
geração de conhecimento e aplicação prática, cuja finalidade é a criação de uma ferramenta
para a edição e transformação de modelos em soluções de software IoT. Para isso deve ser
efetuada a criação de modelos independentes de plataforma para uma abordagem baseada
em modelos. Pretende-se criar uma abordagem que permita criar soluções IoT de forma
mais rápida, simples e padronizadas, utilizando as melhores práticas da Engenharia de
Software.
Uma representação visual dos planos de trabalho estão presentes na Figura 5, a
partir da Revisão Bibliográfica é feita a Seleção do Escopo do Trabalho, que pode necessitar
em mais Pesquisa, após essas duas etapas o desenvolvimento é partido em duas Seções:

1. Após a Geração dos Modelos avançamos para o Desenvolvimento do Gerador, Inter-

face gráfica e a Analise do Código Gerado

2. Depois da coleta de Amostra de Código Fonte passamos para a Analise do Código

Coletado

Depois destas duas seções avaliamos a comparação dos códigos.

36

Seleção dos Parâmetros Revisão

de Escopo do Trabalho Bibliográfica

Geração Modelos

Desenvolvimento Coleta de Amostra

Gerador de Código Fonte

Desenvolvimento
Interface Gráfica

Análise de Código Gerado Análise de Código Coletado

Comparação Conclusões
e Avaliação Finais

Figura 5 – Estrutura do trabalho.

3.2 Seleção dos Parâmetros de Escopo do Trabalho

Nessa etapa foi feita a seleção das plataformas que foram analisadas, assim como
quais linguagens e paradigmas de programação, com o intuito de delimitar o contexto de
todo o trabalho selecionando a amostra que representaria Internet of Things visto que
essa tecnologia como um todo, como alvo da pesquisa, se tornaria excessiva.

3.3 Edição do Modelo

O modelo devera ser editado pelo desenvolvedor alvo, de maneira textual, eventual-
mente a ferramenta substituiria a edição textual por uma edição visual WYSIWYG (What
You See Is What You Get), basicamente um editor gráfico com alguns poucos elementos
dos editores UML (Unified Modeling Language). No momento optamos por usar o UMLet
(versão 14.3), a ferramenta geradora de códigos efetua a leitura dos arquivos XML da
edição, futuramente desenvolveremos a nossa própria ferramenta para edição, substituindo
o UMLet de uma maneira pratica e modular.
 37

3.3.1 UMLet

UMLet é uma ferramenta open-source para a edição de diagramas UML de forma

simples e extremamente rápida, o seu diferencial nesse quesito é a possibilidade de editar os
componentes dos modelos tanto em sua forma gráfica como também por uma representação
textual, enquanto soluções concorrentes para edição UML abririam para edição um Pop-up
por meio de uma edição obrigatoriamente gráfica.
A ferramenta foi criada e descrita por/em Auer, Tschurtschenthaler e Biffl[32], o
autor possui outros 2 artigos descrevendo os objetivos da ferramenta e seus elementos
customizáveis. Em Auer, Tschurtschenthaler e Biffl[32] o autor conclui que os editores
convencionais por melhor que sejam, comparados ao UMLet, carecem de:

• Providenciar uma versão do programa que seja leve e facilmente distribuído

• Providenciar uma interface intuitiva e pratica para a criação de diagramas UML

• Providenciar métodos flexíveis de compartilhar os e reusar os diagramas

UMLet se distingue de outros editores UML por permitir criar elementos customi-
záveis via texto, além disso ele permite montar uma paleta customizada para conter esses
elementos. Nossa ferramenta geradora de código criaria também esses elementos antes da
edição do usuário final, sua interface gráfica esta representada na Figura 6.

Figura 6 – Interface do UMLet com um modelo em etapa de edição, podendo notar que
os elementos customizados estão presente na paleta a direita superior)

Por ser open-source, futuramente possibilitando editar a ferramenta com o intuito

de melhor adequá-la ao uso, além de estar disponibilizando as alterações para a comunidade
38

do movimento código aberto. A ferramenta possui também uma versão online que não
necessita de nenhuma instalação localizada em http://www.umletino.com/, única diferença
para a versão executável multiplataforma é o suporte parcial a elementos customizados.

3.4 Seleção de Código

Foi feita uma seleção dos códigos a serem comparados com os gerados pela ferra-
menta, as comparações serão feitas utilizando projetos mais próximos dentro do possível,
exemplo: comparação entre duas soluções Arduino que se comunicam com o chipset do
ESP8266 (uma placa de rede wireless para soluções IoT).
As soluções serão provenientes de repositórios públicos no GitHub.com, além do
contexto do código para comparação, a popularidade do repositório também será levada
em consideração, dando preferencia a repositórios com mais observadores e/ou estrelas
(sistema de favoritos), tendo também uma quantidade de corte para seleção dos repositórios
(valor a ser definido), o intuito é de obter código que mais represente as soluções utilizadas
no momento.

3.5 Desenvolvimento da ferramenta

3.5.1 Linguagem de Programação

Para o desenvolvimento da ferramenta foi utilizada a linguagem interpretada de

programação Python (versão 3.7.4), inicialmente criada em 1990 por Guido van Rossum,
se trata de uma linguagem de alto nível, segundo o próprio criador em Rossum et al.[33] é
uma ótima linguagem para desenvolvedores iniciantes sem ser uma linguagem feita com
esse objetivo em mente, visto que é completa e utilizada também por profissionais, isso
devido ao seu foco em ser facilmente legível.
A linguagem foi escolhida pelo seu alto nível de abstração, ideal para trabalharmos
com geração de código, sua vantagem principal é a facilidade no desenvolvimento. Sua
principal desvantagem, quando comparada a linguagens de baixo nível de abstração,
é a performance e optimização no tempo de execução. Contudo, no projeto atual não
consideramos como um fator crítico, pois mesmo que o usuário da ferramenta tenha um
computador com baixo poder computacional, o custo vai ser a espera de alguns instantes
extra para a geração dos códigos (gerados em C++). Assim, não haverá algum impacto
na velocidade de compilação e execução nos dispositivos que executarão o código gerado,
se houvesse seria um problema que levaria à reconsideração da linguagem escolhida.
Outro fator na escolha da linguagem é a disponibilidade de bibliotecas (chamada
de módulos em Python) prontas, completas e compatíveis com o objetivo da ferramenta.
Algo que crítico em vários momentos no desenvolvimento da ferramenta foi o comum
 39

desafio onde funcionalidades necessárias não são de suporte nativo da linguagem, como
a manipulação de arquivos de texto para a leitura dos diagramas e geração dos códigos,
assim como com o tratamento de imagens para futuras ilustrações gráficas.
Python é uma linguagem muito utilizada em protótipos, não somente devido à sua
facilidade de escrita e leitura mas também com a praticidade de ser utilizado como um
comunicador entre outros programas de computador. Ele é facilmente integrado em scripts
Bash, o que se enquadra bem ao nosso uso pois futuramente planejamos implementar uma
interface gráfica.

3.5.2 Ambiente de Desenvolvimento

Utilizamos o VScode, um editor de texto da Microsoft tão capaz quanto um IDE

convencional como VisualStudio, uma vez que adicionado suas extensões para realce de
sintaxe, compilação, execução e debbuging de código, para Python em especifico, além dos
citados acima, utilizamos também extensões para suporte de linting, formatação de código
e refatoração.
4 DESENVOLVIMENTO

Nesse capítulo vamos explorar a abordagem proposta e acompanhar como as

metodologias apresentadas foram colocadas em prática.

4.1 Pesquisa

A etapa inicial deste trabalho foi a de pesquisa, que extraímos o embasamento

teórico necessário para o desenvolvimento do projeto.

4.2 Abordagem proposta

Neste seção é apresentada a abordagem desenvolvida durante o trabalho.

4.2.1 Metamodelo

O modelo inicial da proposta é o metamodelo, por ser classe base de todos os outros
modelos (derivado) editáveis. O modelo apresentado na Figura 7 pode ter aparência sim-
plista por ter sido desenvolvido não somente com o intuito de englobar muitas plataformas
mas também graças as sua genericidade conseguimos manter um alto nível de flexibilidade
quanto aos modelos.
O objetivo na sua criação foi que fosse genérico o suficiente para suportar não
somente os modelos inicialmente desenvolvidos mas também os futuramente desenvolvidos
pelos usuários da ferramenta.

Figura 7 – Metamodelo por nós sugerido para Internet das Coisas

O metamodelo se define como um PIM (Plataform Independent Model) por não

conter especificações tecnicas de plataformas específicas. Ele consiste de uma classe
42

Microcontrolador sendo utilizada para representar as placas únicas de desenvolvimento

de protótipo, como por exemplo Arduino ou Raspberry. Seus atributos e métodos base
podem variar de acordo com o modelo utilizado, podendo especificar o seguinte:

• atributo; int PortasAnalógicas

• atributo; int PortasDigitais

• método; void setup()

• método; void loop()

Ambos os atributos são do tipo inteiro e se referem ao número de portas disponíveis para
comunicações entre componentes. A distinção entre analógico e digital deve ser feita, pois
estas estão presentes em quantidades diferentes e são endereçadas de maneiras diferentes.
O método setup é algo presente em Arduinos. Um método principal de inicialização do
script, ocorrendo somente uma vez por execução. Enquanto o loop se trata de um método
síncrono executado uma vez para cada ciclo do microcontrolador, idealmente utilizado
para checagens como as derivadas do padrão de projetos Observer.
Somente uma instância de Microcontrolador pode ocorrer por projeto, mas esse
Microcontrolador é um agregado de componente. Um componente representa todos os
módulos complexos com suas próprias bibliotecas como placas eletrônicas Wi-Fi e Blue-
tooth até componentes elétricos como botões ou LEDs que não possuem bibliotecas de
funcionamento. Esses Componentes podem conter atributos e métodos a serem também
estipulados pelos modelos.

4.2.2 Modelo

Um dos desafios no desenvolvimento da abordagem foi a materialização de uma

nova linguagem de modelagem através dos diagramas, devido a falta de padronização
presente no mercado atual. Decidimos por um diagrama baseado não-UML, porém com
elementos UML, sendo uma mescla de diagrama de classes, por conter atributos, métodos
e relações, com um diagrama de atividades, por conter também a tomada de decisões no
mesmo diagrama.
Outro desafio foi a determinação da ferramenta ideal para a manipulação destes
diagramas. A seleção final foi o UMLet por motivos já discutidos na Metodologia 3, pois
ela nos permite uma dinâmica de edição não presente em outras ferramentas. Pode-se
claramente notar as alterações destes dois modelos, o modelo apresentado na Figura 8
é uma versão de experimentação, enquanto o apresentado na Figura 9 possui o mesmo
conteúdo com uma legibilidade muito maior, isso graças ao agrupamento de objetos dentro
da interface do UMLet.
 43

Figura 8 – Modelo originalmente utilizado para testes

Figura 9 – Modelo utilizado para testes

44

4.3 Desenvolvimento do Gerador

Após a etapa de pesquisa e planejamento, foi dado inicio ao desenvolvimento da

ferramenta geradora de códigos. O gerador passou por várias iterações até chegar na etapa
presente. Abaixo são descritos algumas:
Um dos nossos designs anteriores (Figura 10) consistia de uma única etapa de
geração de código, que tem como entrada as especificações das bibliotecas, o metamodelo
e o modelo editado pelo desenvolvedor. Pelo gerador possuir múltiplas dependências e o
metamodelo estar sendo interpretado em 2 estágios diferentes (para que o gerador aplique
as regras de negocio e para que o modelo as respeite) acabou acarretando em um atraso
no desenvolvimento, necessitando de uma nova arquitetura.

Figura 10 – Fluxograma arquitetural presente em versão anterior do gerador

Agora com as responsabilidades melhor distribuídas como na Figura 11 o desen-

volvimento não tem tantos deadlocks, tendo um desempenho melhor na produção. Essa
mudança se resume na adição de uma nova etapa de produção automática, o qual o gerador
de modelo recebe o metamodelo e a biblioteca para a geração do modelo, esse modelo após
editado será a única entrada do gerador de código, produzindo o código final executável.

Figura 11 – Fluxograma arquitetural presente na versão atual do gerador

A geração do codigo partindo dos modelos editados ocorre da seguinte maneira:

1. É feita uma varredura de todos os elementos XML do arquivo, ocorrendo uma

desserialização, transformando elementos correspondentes a componentes em objetos
 45

do tipo componente em Python, criando o objeto Arduino e as seguintes listas de

objetos: Componentes, Bibliotecas, Relações

2. Cada objeto contem as informações extraídas do modelo, como o nome da biblioteca,

numero de portas digitais/analógicas, métodos e seu endereço no espaço visual do
diagrama.

3. É feito um processamento para interpretar as coordenadas das relações, descobrindo

assim quais dois outros elementos estão conectadas por elas, podendo atribuir então
a cada objeto do tipo relação o endereço dos seus dois elementos, de origem e destino.

4. Por ultimo é feita uma varredura na lista de objetos Componentes, é produzido uma
nova lista de todas as bibliotecas utilizadas no projeto, removendo as duplicações
e inserindo com a sintaxe correta no arquivo de destino. Da mesma maneira é
interpretada a relação entre os componentes e adicionado dentro do loop(), todo
componente do modelo é instanciado dentro do setup().
5 RESULTADOS

Neste capítulo são apresentados os resultados obtidos com a conclusão do projeto,

ao tentar utilizar a ferramenta como um de seus usuários finais. Foi produzido um modelo,
respeitando as restrições do metamodelo apresentado no capitulo de Desenvolvimento 4.
O modelo contém os seguintes componentes:

• Placa Controladora Arduino UNO

• Botão

• Motor

• Sensor de Temperatura

• LED

Além dos componentes, existe também um nó para tomada de decisão, no caso se

o valor do inteiro de retorno do método getTemp() for maior ou igual a 20 ele executa
o método turn(x) (valor de x ainda não esta sendo tratado), caso for menor que 20 ele
executa setOn().
O modelo foi produzido utilizando a função de paleta de componentes do UMLet,
podendo arrastar os componentes do metamodelo para o diagrama atual, e fazendo as
edições necessárias nos mesmos.
Podemos visualizar a representação textual criada pela edição gráfica do modelo na
Figura 12. O arquivo do UMLet é então passado como parâmetro para o gerador por meio
de linha de comando, o segundo parâmetro é o arquivo de destino para o código, como
representado na Figura 13. No momento o acesso à ferramenta esta sendo feito somente
pela interface de linha de comando, funcionando universalmente em terminais de sistemas
Unix e Windows, o terminal deve estar aberto no diretório dos arquivos utilizados, o
comando consiste do arquivo da ferramenta gerado, arquivo .xml de origem e o arquivo
.cpp de destino, após executar o comando, o código será gerado no arquivo determinado.
O código-fonte gerado (exemplo na Figura 14 pode ser copiado e colado em uma
IDE de desenvolvimento para execução em simuladores ou placas físicas da plataforma
Arduino.
48

Figura 12 – Arquivo XML proveniente do UMLet

Figura 13 – Execução da ferramenta por meio da linha de comando

Figura 14 – Amostra do código funcional da tomada de decisão, gerado pela ferramenta

6 CONCLUSÃO E DISCUSSÃO

Neste trabalho foram exploradas as possíveis lacunas no desenvolvimento de software

para soluções de Internet das Coisas, concluímos com o estudo bibliográfico que existe a
ausência de uma ferramenta de Desenvolvimento Dirigido a Modelos para essa tecnologia.
Concluímos também que uma vez produzida uma ferramenta adequada teríamos uma
melhoria na qualidade de software, maior interoperabilidade de padrões, maior flexibilidade
e custos menores de tempo e recursos.
Neste trabalho foi proposto uma ferramenta inicial de Desenvolvimento Dirigido
a Modelos para soluções de Internet das Coisas, os resultados iniciais são promissores,
incentivando uma continuação evolutiva deste mesmo trabalho, o adaptando para compre-
ensão de modelos mais complexos, além da interpretação completamente automatizada
das bibliotecas.
A ferramenta em seu atual estado se provou capaz de gerar código-fonte para a
plataforma Arduino, o processo demonstrado no Capítulo 5 se mostra de fácil manuseio,
adequado para desenvolvedores iniciantes, sem conhecimento de domínio. Com o uso da
ferramenta o desenvolvedor é capaz de produzir código-fonte cujo ele não conseguiria
escrever manualmente.

6.1 Trabalhos Futuros

A análise das soluções poderá ser feita com o auxilio da ferramenta Analizo,
desenvolvida por Terceiro et al.[34] para a análise de códigos por meio de métricas de
software como a contagem de atributos públicos e métodos.
A abordagem ainda tem espaço para crescimento, este trabalho será dado sua
devida continuação por meio do programa de mestrado na UEL (Universidade Estadual
de Londrina) com a orientação do Prof. Dr. André Luís Andrade Menolli.
 REFERÊNCIAS

[1] NGUYEN, X. T. et al. Frasad: A framework for model-driven iot application

development. In: IEEE. 2015 IEEE 2nd World Forum on Internet of Things
(WF-IoT). [S.l.], 2015. p. 387–392.

[2] WORLD Internet Users Statistics and 2019 World Population Stats. Disponível em:
<https://www.internetworldstats.com/stats.htm>.

[3] HOWELL, J. Number of Connected IoT Devices Will Surge to 125 Billion by
2030, IHS Markit Says. Disponível em: <https://technology.ihs.com/596542/
number-of-connected-iot-devices-will-surge-to-125-billion-by-2030-ihs-markit-says>.

[4] GUBBI, J. et al. Internet of things (iot): A vision, architectural elements, and future
directions. Future generation computer systems, Elsevier, v. 29, n. 7, p. 1645–1660,
2013.

[5] SCHWAB, K.; DAVIS, N. Aplicando a quarta revolução industrial. [S.l.]: EDIPRO,
2019.

[6] JAVED, A. Building Arduino projects for the Internet of Things: experiments with
real-world applications. [S.l.]: Apress, 2016.

[7] GRIMMETT, R. Raspberry Pi robotics projects. [S.l.]: Packt Publishing Ltd, 2015.

[8] LEA, R.; BLACKSTOCK, M. City hub: A cloud-based iot platform for smart cities.
In: IEEE. 2014 IEEE 6th international conference on cloud computing technology
and science. [S.l.], 2014. p. 799–804.

[9] HUMPHREY, W. S. Guest editor’s introduction: The personal software process-status

and trends. IEEE Software, IEEE Computer Society, v. 17, n. 6, p. 71, 2000.

[10] FITZGERALD, B.; STOL, K.-J. Continuous software engineering and beyond: trends
and challenges. In: ACM. Proceedings of the 1st International Workshop on Rapid
Continuous Software Engineering. [S.l.], 2014. p. 1–9.

[11] ZHU, T. et al. Monitoring software quality evolution by analyzing deviation trends of
modularity views. In: IEEE. 2011 18th Working Conference on Reverse Engineering.
[S.l.], 2011. p. 229–238.

[12] BABAR, M. I.; RAMZAN, M.; GHAYYUR, S. A. Challenges and future trends in
software requirements prioritization. In: IEEE. International conference on computer
networks and information technology. [S.l.], 2011. p. 319–324.

[13] RAY, B. et al. A large scale study of programming languages and code quality in
github. In: ACM. Proceedings of the 22nd ACM SIGSOFT International Symposium
on Foundations of Software Engineering. [S.l.], 2014. p. 155–165.

[14] IMANI, M. et al. A comprehensive survey on addressing methods in the internet of

things. arXiv preprint arXiv:1807.02173, 2018.
52

[15] ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Computer
networks, Elsevier, v. 54, n. 15, p. 2787–2805, 2010.

[16] KAPTEIJNS, T. et al. A comparative case study of model driven development vs

traditional development: The tortoise or the hare. From code centric to model centric
software engineering: Practices, Implications and ROI, v. 22, 2009.

[17] MCDONALD, N.; GOGGINS, S. Performance and participation in open source

software on github. In: ACM. CHI’13 Extended Abstracts on Human Factors in
Computing Systems. [S.l.], 2013. p. 139–144.

[18] XENOS, M. et al. Object-oriented metrics-a survey. In: Proceedings of the FESMA.
[S.l.: s.n.], 2000. p. 1–10.

[19] STAHL, T.; VOELTER, M.; CZARNECKI, K. Model-driven software development:

technology, engineering, management. [S.l.]: John Wiley & Sons, Inc., 2006.

[20] MELLOR, S. J.; CLARK, T.; FUTAGAMI, T. Model-driven development: guest

editors’ introduction. IEEE software, IEEE Computer Society, v. 20, n. 5, p. 14–18,
2003.

[21] AYED, D.; DELANOTE, D.; BERBERS, Y. Mdd approach for the development
of context-aware applications. In: SPRINGER. International and Interdisciplinary
Conference on Modeling and Using Context. [S.l.], 2007. p. 15–28.

[22] ASGHAR, M. H.; NEGI, A.; MOHAMMADZADEH, N. Principle application and

vision in internet of things (iot). In: IEEE. International Conference on Computing,
Communication & Automation. [S.l.], 2015. p. 427–431.

[23] TAN, L.; WANG, N. Future internet: The internet of things. In: IEEE. 2010 3rd
international conference on advanced computer theory and engineering (ICACTE).
[S.l.], 2010. v. 5, p. V5–376.

[24] COETZEE, L.; EKSTEEN, J. Internet of things–promise for the future? an

introduction. 2011.

[25] FLEISCH, E. et al. What is the internet of things? an economic perspective.

Economics, Management, and Financial Markets, Addleton Academic Publishers,
v. 5, n. 2, p. 125–157, 2010.

[26] TRUONG, H.-L.; DUSTDAR, S. Principles for engineering iot cloud systems. IEEE
Cloud Computing, IEEE, v. 2, n. 2, p. 68–76, 2015.

[27] SEVERANCE, C. Eben upton: Raspberry pi. Computer, IEEE, v. 46, n. 10, p. 14–16,
2013.

[28] KOTOV, V. Systems of systems as communicating structures. [S.l.]: Hewlett Packard

Laboratories, 1997. v. 119.

[29] NUÑEZ-VARELA, A. S. et al. Source code metrics: A systematic mapping study.

Journal of Systems and Software, Elsevier, v. 128, p. 164–197, 2017.

[30] MARTIN, R. Oo design quality metrics. An analysis of dependencies, v. 12, p.

151–170, 1994.
 53

[31] CICCOZZI, F. et al. Model-driven engineering for mission-critical iot systems. IEEE
software, IEEE, v. 34, n. 1, p. 46–53, 2017.

[32] AUER, M.; TSCHURTSCHENTHALER, T.; BIFFL, S. A flyweight uml modelling

tool for software development in heterogeneous environments. [S.l.]: IEEE, 2003.

[33] ROSSUM, G. V. et al. Computer programming for everybody. Proposal to the

Corporation for National Research initiatives, 1999.

[34] TERCEIRO, A. et al. Analizo: an extensible multi-language source code analysis

and visualization toolkit. In: Brazilian Conference on Software: Theory and Practice
(CBSoft) – Tools. Salvador-Brazil: [s.n.], 2010.
 TRABALHOS PUBLICADOS PELO AUTOR

Trabalhos publicados pelo autor durante o programa.

1. Rafael Figueira Goncalves, José Maria Clementino Júnior, Erikson Júlio de Aguiar, Fe-
lipe Chiarotti Giron, André Luis Andrade Menolli, Configuração de Dispositivos
IoT Utilizando Protocolo MQTT Para Arduino, Bandeirantes, Outubro/2017,
SEMINÁRIO DE INFORMÁTICA E TECNOLOGIA, (SECAPEE 4345)

2. Erikson Julio de Aguiar, Yuri Lucas Luz da Silva, Rafael Figueira Goncalves, André
Luis Andrade Menolli, Implantação de Uma Abordagem Baseada no De-
senvolvimento Dirigido a Modelos Para Persistência de Dados em Java
Utilizando o Acceleo, Bandeirantes, Outubro/2017, SEMINÁRIO DE INFOR-
MÁTICA E TECNOLOGIA, (SECAPEE 4245)