Universidade Federal de Pernambuco

Centro de Informática

Pós-graduação em Ciência da Computação

Uma Arquitetura de Software para
Cidades Inteligentes baseada na Internet
das Coisas
Gustavo Henrique Rodrigues Pinto Tomas
Dissertação de Mestrado

RECIFE
Fevereiro de 2014

Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação

Gustavo Henrique Rodrigues Pinto Tomas

“Uma Arquitetura de Software para Cidades Inteligentes
baseada na Internet das Coisas”

Dissertação apresentada como requisito parcial para a obtenção do título de Mestre em Ciências da Computação, área
de concentração em Engenharia de Software pelo Programa
de Pós-Graduação em Ciências da Computação do Centro
de Informática da Universidade Federal de Pernambuco.

Orientador: Vinicius Cardoso Garcia
Coorientador: Alexandre Alvaro

RECIFE, Fevereiro de 2014

À minha família, por sempre me proporcionar totais
condições para a realização dos meus estudos.
Aos meus irmãos, que esta dissertação sirva de inspiração
para suas futuras decisões profissionais.
À Crisley, por sempre estar ao meu lado e me ajudar a ver o
lado bom de tudo.
Dedico.

Agradecimentos

Primeiramente gostaria de agradecer a Deus por me proporcionar todas as condições
para a realização deste trabalho e, principalmente, por ter colocado em meu caminho
pessoas muito especiais que me ajudaram nesta aventura. Algumas destas pessoas serão
brevemente citadas a seguir:
Agradeço ao meu orientador Vinicius Cardoso Garcia, pela orientação, pelo espírito
acolhedor, pelo incentivo e pelas cobranças, totalmente necessárias, para me manter
o tempo todo focado no objetivo final. Não poderia deixar de agradecer a liberdade e
abertura para discutir novas ideias e definir novas metas, sem deixar de lado a qualidade do
trabalho. Os questionamentos e a experiência de outras áreas foram de suma importância
para a concretização da proposta. A coragem em se aventurar em uma área de pesquisa
recente, na qual ninguém possuía muita experiência, fatalmente separa os vencedores dos
medrosos. Além disso, a confiança em permitir, que uma parte do mestrado seja realizada
remotamente, certamente foi uma atitude de uma pessoa grande, tanto profissionalmente
quanto espiritualmente.
Ao grande pesquisador e amigo Alexandre Alvaro pela ajuda e compartilhamento
de suas experiências antes mesmo de iniciar o mestrado. Certamente daquele dia em
diante, você começou a ser observado com olhos de admiração. Agradeço também
por ter apresentado a área de pesquisa e, principalmente, as oportunidades que estavam
envolvidas. Os feedbacks do trabalho sempre contribuíram de forma muito positivamente,
assim como os bate-papos, por mais “viajados” que fossem.
Ao grande irmão de consideração Welington Manoel da Silva, pelo tempo de convivência, pelos aprendizados deste período e, principalmente, pela paciência e bom humor
para enfrentarmos juntos toda aquela situação. Em relação à parte técnica, todos os questionamentos e palpites foram fundamentais para o aprimoramento da proposta. A forma
pelo qual Welington compartilhou seus conhecimentos comigo certamente evidencia uma
das suas principais características: compaixão com o próximo.
Agradeço a minha família pela compreensão nos dias em que fiquei trancado no
quarto e nos dias de indisponibilidade para conversar por telefone. Em especial aos
meus pais Érica e Elcio, agradeço ao suporte que, por mais que não seja o que eles
gostariam de proporcionar, foi muito mais do que o suficiente para a minha formação,
tanto como homem quanto profissional. Ainda em relação à família, agradeço aos meus
irmãos Larissa e Júnior, por aturarem o meu mau humor quando as coisas pareciam estar
desabando. Sinceramente, espero que este novo objetivo alcançado na minha vida sirva
de exemplo para que eles acreditem nos respectivos potenciais e, principalmente, na

vii

capacidade de atingir seus objetivos.
Não poderia de deixar de fora a minha amiga, companheira, revisora de textos em
inglês e português: Crisley. A sua compaixão e o seu jeitinho singular foram as forças
que eu precisava nos momentos de maiores dificuldades. Olhando para trás, não consigo
enxergar outra forma de enfrentar os meus desafios sem o seu positivismo. A compreensão
e a paciência para enfrentar 9 meses à distância certamente comprovaram que somos
iguais ao amanhecer: independente do que aconteça, sempre estaremos juntos para
enfrentar qualquer tipo de escuridão.
Ao Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) pela coragem
e confiança em aceitar o desafio de conciliar a rotina de trabalho de 40h semanais com
as disciplinas do mestrado. Nesse sentido, gostaria de agradecer imensamente os meus
gestores Paulo Urbano e Roberta Hazin pela coragem, compreensão e, principalmente,
por não aliviarem as minhas tarefas, o que contribuiu muito para a minha formação
acadêmica e profissional. Espero que eles tenham a consciência de que esse tipo de
atitude afetou, e muito, positivamente a vida de uma pessoa. Certamente gestores com
esse perfil deveriam ser supervalorizados nas suas atribuições. Considero a forma como a
situação foi conduzida um exemplo a ser seguido na minha vida.
Finalmente, gostaria de agradecer a todos que de alguma forma, direta ou indiretamente, contribuíram para a realização deste trabalho.

viii

Resumo

De acordo com recentes pesquisas, a população mundial esta crescendo de forma desproporcional aos recursos necessários para a vida humana. Cada vez mais a quantidade
de pessoas vivendo nas áreas urbanas aumenta, devido à diversos fatores, como as
oportunidades que são geradas nestes grandes centros.
Este desenfreado crescimento populacional, principalmente nas áreas urbanas, além de
outros fatores como má governança, ocasiona e/ou intensifica diversos problemas urbanos.
Para exemplificar este fato, pode-se citar os grandes problemas que as cidades brasileiras
enfrentam nas áreas de transporte, saúde e educação, evidenciados, rotineiramente, pela
mídia em geral.
Neste contexto, o conceito de Cidade Inteligente (CI) visa mitigar estes problemas a
fim de aumentar a qualidade de vida dos cidadãos. Para tal, uma importante ferramenta
para a implementação de uma CI é a Internet of Things (Internet das Coisas) (IoT), na
qual diversos objetos são combinados para atingir um objetivo em comum como, fornecer
informações do fluxo de veículos de uma cidade.
Porém, para que este cenário seja de fato consolidado, necessita-se de uma Arquitetura
de Software (AS) capaz de integrar e combinar as diferentes tecnologias e dados que
compõem os serviços urbanos.
Na literatura pode-se encontrar várias Arquiteturas de Software (AS’s) para CI, inclusive com apoio de grandes empresas. Porém, estas AS’s visam atender apenas um
determinado serviço urbano com uma aplicação específica, o que não caracteriza de fato
uma implementação de CI.
Motivado por estes desafios, esta dissertação apresenta a especificação, o projeto
e a avaliação de uma AS para CI que permite a integração com IoT, baseado no conjunto de requisitos extraídos das soluções existentes. Adicionalmente, são discutidos os
resultados obtidos, os problemas encontrados, e as direções futuras para pesquisa e o
desenvolvimento.
Palavras-chave: Cidades Inteligentes, Internet das Coisas, Arquitetura de Software

ix

Abstract

According to recent researches, global population is increasing disproportionally from the
essential resources for human life. More and more, the amount of people living in urban
areas is increased due to several factors, including the opportunities which are generated
in these locals.
This unbridled populational growth, mainly in urban areas, and other factors such as
poor governance, leads and/or enhances many urban problems. To illustrate this fact, we
can mention the major problems that Brazilian cities face in the areas of transport, health
and education, evidenced routinely by the media in general.
In this context, the Smart City (SC) concept attempts to mitigate these problems
in order to increase the citizens quality of life. For such an important tool for the
implementation of a SC is the Internet of Things (IoT), in which several objects are
combined to achieve a common goal, such as, details of the flow of vehicles in a city.
Nevertheless, in order to consolidate this scenario, a software architecture that is able
to integrate and combine different technologies and data that comprise the urban services
is required.
In literature we can find several architectures for SC, including support of large
companies. However, these architectures aim to meet only an urban service with specific
application, which features not in fact an implementation of SC.
Motivated by these challenges, this thesis presents the specification, the design and
evaluation of a SC architecture that allows integration of IoT technologies, based on a
set of requirements drawn from existing approaches. Additionally, we discuss the results
obtained, the problems found, and the future steps for research and development.
Keywords: Smart Cities, Internet of Things, Software Architecture

xi

Sumário

Lista de Figuras

xvii

Lista de Tabelas

xix

Lista de Acrônimos

xxi

1

2

Introdução

1

1.1

Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Visão Geral da Solução Proposta . . . . . . . . . . . . . . . . . . . . .

3

1.3.1

Visão Geral da Arquitetura de Software (AS) . . . . . . . . . .

3

1.4

Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.5

Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.6

Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . .

6

Cidades Inteligentes e Internet das Coisas
2.1

Conceito de Cidade Inteligente (CI) . . . . . . . . . . . . . . . . . . .

11

2.2

Conceito de Internet of Things (Internet das Coisas) (IoT) . . . . . . . .

14

2.3

Integração de Cidade Inteligente (CI) com Internet of Things (Internet
das Coisas) (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . .

15

2.4
3

9

Revisão da Literatura de Arquiteturas de Software para Cidades Inteligentes
17
3.1

Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.1.1

Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . .

19

Estratégia de Busca e Fontes de Dados . . . . . . . . . . . . . .

19

Seleção das Abordagens . . . . . . . . . . . . . . . . . . . . .

21

Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

Abordagens Resultantes . . . . . . . . . . . . . . . . . . . . .

23

Revisão Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2.1

Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . .

26

3.2.2

Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.3

Consolidação das Abordagens Encontradas . . . . . . . . . . . . . . .

30

3.4

Requisitos para uma Arquitetura de Software para Cidades Inteligentes .

32

3.1.2
3.2

xiii

4

3.4.1

Interoperabilidade de objetos . . . . . . . . . . . . . . . . . . .

32

3.4.2

Monitoramento em tempo real . . . . . . . . . . . . . . . . . .

33

3.4.3

Sustentabilidade . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.4.4

Aspectos sociais . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.4.5

Ubiquidade/Mobilidade . . . . . . . . . . . . . . . . . . . . .

34

3.4.6

Privacidade e Segurança dos dados . . . . . . . . . . . . . . . .

35

3.4.7

Geolocalização dos sensores . . . . . . . . . . . . . . . . . . .

35

3.4.8

Composição de Dados Urbanos . . . . . . . . . . . . . . . . .

36

3.4.9

Histórico de dados . . . . . . . . . . . . . . . . . . . . . . . .

36

3.4.10 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.4.11 Sensoriamento e Processamento Distribuído . . . . . . . . . . .

37

3.4.12 Flexibilidade/Extensibilidade . . . . . . . . . . . . . . . . . .

38

3.5

Sumário dos Requisitos para Cidades Inteligentes . . . . . . . . . . . .

38

3.6

Discussão do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.7

Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . .

40

Uma Arquitetura de Software para Cidades Inteligentes baseada na Internet
das Coisas
41
4.1

Requisitos abordados . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.2

Metodologia “4+1” . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.3

Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.3.1

Módulo de Acesso e Comunicação (MAC) . . . . . . . . . . .

45

4.3.2

Módulo de Gerenciamento de Recursos (MGR) . . . . . . . . .

46

4.3.3

Módulo de Gerenciamento e Distribuição de Dados (MGDD) .

47

4.3.4

Módulo de Persistência de Dados (MPD) . . . . . . . . . . . .

48

4.3.5

Mapeamento Requisito x Módulo . . . . . . . . . . . . . . . .

48

4.3.6

Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Consumidor: Recurso receber dados . . . . . . . . . . . . . . .

49

Produtor: Fornecer dado . . . . . . . . . . . . . . . . . . . . .

50

Compor um dado urbano . . . . . . . . . . . . . . . . . . . . .

50

Visão de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.4.1

Módulo de Acesso e Comunicação (MAC) . . . . . . . . . . .

52

4.4.2

Módulo de Gerenciamento de Recursos (MGR) . . . . . . . . .

53

4.4.3

Módulo de Gerenciamento e Distribuição de Dados (MGDD) .

53

4.4.4

Módulo de Persistência de Dados (MPD) . . . . . . . . . . . .

54

Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.4

4.5
xiv

5

4.6

Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

4.7

Visão Componente Conector . . . . . . . . . . . . . . . . . . . . . . .

57

4.8

Visão de Dependências . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.9

Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.9.1

Desenvolvimento de aplicações móveis . . . . . . . . . . . . .

59

4.9.2

Emitir Alertas com Informações de Trânsito . . . . . . . . . . .

59

4.9.3

Definição de Estratégia Efetiva de Investimento de Recursos . .

60

4.9.4

Predição de Catastrófes em Áreas de Riscos . . . . . . . . . . .

60

4.10 Discussão do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.11 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . .

61

Avaliação da Arquitetura de Software

63

5.1

Métodos de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

5.1.1

Métodos Analisados . . . . . . . . . . . . . . . . . . . . . . .

64

5.1.2

Descrição dos métodos restantes . . . . . . . . . . . . . . . . .

65

Adaptação dos métodos de avaliação . . . . . . . . . . . . . . . . . . .

66

5.2.1

Definição do método de avaliação . . . . . . . . . . . . . . . .

66

5.2.2

Equipe de Avaliação . . . . . . . . . . . . . . . . . . . . . . .

67

5.2.3

Descrição do Método de Avaliação . . . . . . . . . . . . . . .

67

Processo de Avaliação Executado . . . . . . . . . . . . . . . . . . . . .

69

5.3.1

Primeira Reunião . . . . . . . . . . . . . . . . . . . . . . . . .

69

5.3.2

Segunda Reunião . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.3.3

Terceira Reunião . . . . . . . . . . . . . . . . . . . . . . . . .

73

Resultados da Avaliação da Arquitetura . . . . . . . . . . . . . . . . .

74

5.4.1

Resultados da Avaliação dos Cenários . . . . . . . . . . . . . .

75

5.4.2

Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . .

76

5.5

Ameaças à Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

5.6

Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . .

78

5.2

5.3

5.4

6

Conclusão

79

6.1

Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

6.2

Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . .

80

6.3

Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

6.4

Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

Referências Bibliográficas

84

xv

Apêndice

93

A Repositórios de busca na Systematic Literature Review (Revisão Sistemática
da Liteturatura) (SLR)
95
B Avaliação da Arquitetura de Software (AS)

xvi

97

Lista de Figuras

1.1

Arquitetura de Software (AS) da solução proposta . . . . . . . . . . . .

4

3.1
3.2

Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultado da filtragem das abordagens . . . . . . . . . . . . . . . . . .

19
21

4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9

Integração das visões do modelo “4+1” com as visões definidas pelo SEI
Visão lógica da Arquitetura de Software (AS) proposta . . . . . . . . .
Abstração da operação de um recurso receber dados . . . . . . . . . . .
Abstração da operação de um recurso fornecer dado . . . . . . . . . . .
Abstração da operação de um recurso fornecer um novo tipo de dado . .
Operação de composição de dados urbanos . . . . . . . . . . . . . . .
Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de Componente Conector . . . . . . . . . . . . . . . . . . .
Diagrama de Dependências . . . . . . . . . . . . . . . . . . . . . . . .

44
45
49
50
51
52
55
57
58

5.1

Resultado da avaliação dos cenários . . . . . . . . . . . . . . . . . . .

75

B.1 Printscreen do formulário online utilizado pelos participantes para propor
os cenários de uso da AS . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.2 Printscreen da Parte 1/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . 98
B.3 Printscreen da Parte 2/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . 99
B.4 Printscreen da Parte 3/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . 100

xvii

Lista de Tabelas

3.1
3.2
3.3
3.4

Quantidade de abordagens por fonte de pesquisa
Abordagens resultantes por ordem cronológica
Resumo das abordagens descritas na literatura .
Mapeamento requisitos-arquiteturas . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

20
23
31
39

4.1
4.2
4.3
4.4

Requisitos abordados . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento Requisitos por Módulo . . . . . . . . . . . . . . . . . .
Resumo da quantidade de processos e threads em tempo de execução
Requisitos físicos de utilização da arquitetura . . . . . . . . . . . . .

.
.
.
.

42
49
53
57

5.1
5.2
5.3
5.4
5.5
5.6

Métodos de Avaliação Vs Atributos de Qualidade
Métodos de Avaliação Vs Objetivo . . . . . . . .
Etapas do método adaptado . . . . . . . . . . . .
Expertises da equipe de avaliação . . . . . . . .
Priorização dos Atributos de Qualidade . . . . .
Cenários resultantes de acordo com a relevância .

.
.
.
.
.
.

65
65
67
68
71
74

A.1 Repositórios de busca na SLR . . . . . . . . . . . . . . . . . . . . . .

95

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

xix

Lista de Acrônimos

AS

Arquitetura de Software

DHT

Distributed Hash Table

IoT

Internet of Things (Internet das Coisas)

CI

Cidade Inteligente

SLR

Systematic Literature Review (Revisão Sistemática da Liteturatura)

SOA

Arquitetura Orientada a Serviços

TIC

Tecnologia da Informação e Comunicação

xxi

1
Introdução

Pequenas oportunidades são muitas vezes o começo de grandes
empreendimentos.
—DEMÓSTENES

1.1

Motivação

De acordo com relatório divulgado pela UNESCO (Nations, 2007), por volta de 1950,
30% da população mundial vivia em áreas urbanas e em 2010 esta porcentagem subiu
para 50%. Estima-se que em 2050 a porcentagem de pessoas vivendo nos grandes
centros urbanos será de 70%. Além disso, 10% da população mundial vive nas 30
principais metrópoles (Dobbs and Institute, 2011). No cenário nacional, segundo a
pesquisa realizada pelo Instituto Brasileiro de Geografia e Estatística (IBGE), publicada
no Diário Oficial da União 1 , em julho de 2012 o Brasil chegou a 193.946.886 habitantes,
que representa um aumento de aproximadamente 1,65% em relação ao ano de 2010.
A expansão das cidades enfrenta uma série de desafios. Embora as cidades ocupam
menos de 2% da massa terrestre, os residentes urbanos consomem mais de três quartos
dos recursos naturais do mundo e são os principais responsáveis pela emissão de gases
do efeito estufa (Marceau, 2008). Problemas decorrentes da rápida urbanização indicam
uma perda de funcionalidades básicas para ser um lugar habitável: por exemplo, a
dificuldade na gestão de resíduos, a escassez de recursos naturais, a poluição do ar, as
doenças humanas, o intenso tráfego de veículos e deterioração e envelhecimento das
infraestruturas (Krco, 2010).
1 http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=

2204

1

CAPÍTULO 1. INTRODUÇÃO

Algumas iniciativas isoladas estão sendo desenvolvidas para mitigar alguns dos
problemas urbanos (Nam and Pardo, 2011). As iniciativas vão de aplicativos como
“Waze”2 , um serviço que combina geolocalização no celular com indicações do fluxo e
problemas de trânsito via smartphones, até governamentais, como o Centro de Operações
da Prefeitura do Rio de Janeiro3 , sistema que integra informações a respeito dos diferentes
serviços públicos oferecidos pela cidade.
Porém, para de fato estabelecer uma Cidade Inteligente (CI) é necessário que estas
iniciativas estejam integradas em uma mesma Arquitetura de Software (AS), seja para
compartilhar informações, seja para facilitar a definição da estratégia de atuação (Filipponi
et al., 2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011;
Hernández-Muñoz et al., 2011). Da mesma forma, necessita-se de uma AS que permita a
criação de novas iniciativas para solucionar os problemas dos cidadãos (Filipponi et al.,
2010; Haubensak, 2011; Sanchez et al., 2011), como por exemplo, o monitoramento da
qualidade do transporte coletivo.
Além disso, este trabalho é motivado pela vasta gama de sensores, atuadores, pessoas,
sistemas, drivers e qualquer outro componente capaz de interagir com os serviços urbanos.
Ao aplicar este conjunto de componentes nos contextos urbanos, vários desafios são
gerados para integrá-los e obter o melhor de cada componente.
Para este e outros cenários semelhantes, uma AS para CI pode ajudar a integrar esses
diversos componentes. Para tal, a AS deve ser totalmente plugável e expansível, do ponto
de vista dos protocolos de comunicação implementados.

1.2

Estabelecimento do Problema

Motivado pelas questões apresentadas na Seção anterior, o principal objetivo deste
trabalho é, em linhas gerais:
Especificar, projetar e implementar uma Arquitetura de Software (AS) para
Cidade Inteligente (CI) que permita o desenvolvimento de soluções com base em
Internet of Things (Internet das Coisas) (IoT), independente das especificações de
cada tecnologia e características físicas das cidades. Além disto, este trabalho visa
prover uma implementação de referência desta AS.
2 https://www.waze.com/
3 http://www.rio.rj.gov.br/web/corio

2

1.3. VISÃO GERAL DA SOLUÇÃO PROPOSTA

1.3

Visão Geral da Solução Proposta

A fim de atingir os objetivos deste trabalho, estabelecidos na Seção anterior, foi realizado
um estudo das Arquiteturas de Software (AS’s) para CI baseada em IoT tanto na academia
quanto na indústria, por meio de dois métodos de revisão literária: Revisão Exploratória e
Revisão Sistemática. Este estudo teve como finalidade identificar as técnicas empregadas
nestas soluções e se existia a necessidade da criação de um novo padrão arquitetural para
este contexto.
A partir dos objetivos das abordagens encontradas nestes dois métodos de revisão, um
conjunto de requisitos ao qual uma nova AS para CI deve atender foi estabelecido. Em
seguida, a AS da solução foi proposta visando atingir um sub-conjunto destes requisitos,
que representa os requisitos fundamentais. Por fim, a AS foi submetida à um processo
de avaliação formal adaptado do SAAM (Kazman et al., 1994) e ATAM (Kazman et al.,
1999, 2000).

1.3.1

Visão Geral da Arquitetura de Software (AS)

A AS consiste em módulos que implementam um conjunto de requisitos fundamentais
para o contexto de CI. Estes requisitos são implementados a partir da utilização de
padrões arquiteturais já conhecidos e utilizados em outros tipos de AS’s de software,
como publisher-subscriber. A Figura 1.1 ilustra a AS proposta.
Os módulos da AS são: Módulo de Acesso e Comunicação (MAC), Módulo de
Gerenciamento de Recursos (MGR), Módulo de Gerenciamento e Distribuição de Dados (MGDD) e Módulo de Persistência de Dados (MPD). Estes módulos fornecem as
funcionalidades essenciais utilizadas pelos diferentes tipos de usuários do sistema.
O MAC representa o ponto de entrada dos usuários, aplicações ou até mesmo serviços
externos. O MAC provê todos os mecanismos necessários para o acesso e a comunicação
com a AS, tanto para envio quanto para recebimento de informações. Por sua vez, o
MGR visa gerenciar as informações relativas aos diferentes tipos de recursos disponíveis
na AS. Já o MGDD possui a responsabilidade de disseminar os dados na AS, tanto os
dados de fora para dentro da AS quanto os dados obtidos a partir de alguma computação
interna para os agentes externos. O último módulo (MPD), como o próprio nome já
identifica, possui a responsabilidade de armazenar os dados oriundos dos diferentes níveis
da AS. Estes dados, nos mais variados estágios da AS, são importantes para a predição
de acontecimentos futuros, a partir do histórico de dados.
Os detalhes da AS serão descritos no Capítulo 4.

3

CAPÍTULO 1. INTRODUÇÃO
Módulo de
Acesso e
Comunicação
(MAC)

REST

Módulo de
Persistência de
Dados (MPD)

Interface: Protocolos de troca de mensagens

DHT-BD
Registro de recursos
Driver
BD1

BD1

Driver
BD3

BD3

Interface: Banco de Dados

Driver
BD2

BD2

Configuração de recursos

Módulo de
Gerenciamento
de Recursos
(MGR)

C

DHT Canal
de
dados

C

...

C

C

...

C

C

...

....
Canal 2

Canal 1

...

P

P

...

P

P

...

Canal 3

P

P

Módulo de
Gerenciamento
e Distribuição
de Dados
(MGDD)

...

Figura 1.1 Arquitetura de Software (AS) da solução proposta

1.4

Escopo Negativo

Como a solução proposta por esta dissertação faz parte de um contexto mais amplo, um
conjunto de aspectos relacionados não será tratado no escopo deste trabalho.
Adicionalmente, os requisitos tratados na solução não formam um conjunto completo
e fechado de funcionalidades que devem sempre estar presentes em qualquer AS para
CI. Contudo, acredita-se que os requisitos identificados podem servir como base para
a construção e/ou adaptação de uma AS para CI que combine tecnologias de IoT, tanto
para coletar informações quanto para atuar no ambiente.
Os seguintes aspectos não fazem parte do escopo deste trabalho:
• Modelo de Negócio: Aspectos relacionados ao suporte a modelos de negócio e
estratégias de monetização e cobrança desta proposta não serão tratados neste
trabalho;
• Análises de big data: Apesar da grande quantidade de dados trafegados na AS,
este trabalho não faz nenhum tipo de análise de big data, apenas permite que um
serviço que o faça seja criado;
• Semântica dos Dados: Este trabalho não faz distinção entre semântica dos dados,
uma vez que qualquer tipo de dado relacionado à cidade pode trafegar na AS.
4

1.5. PRINCIPAIS CONTRIBUIÇÕES

1.5

Principais Contribuições

Como resultado do trabalho apresentado nesta dissertação, as seguintes contribuições
podem ser destacadas:
• Estado de arte de AS para CI: A partir das revisões da literatura executadas foi
possível apresentar um resumo a respeito do estado da arte de CI no Brasil e no
mundo, a partir da descrição de algumas abordagens com ou sem apoio dos setores
estatais e privados;
• Comparativo entre dois métodos de revisão literária: A partir dos resultados
obtidos nas duas avaliações executadas (Revisão Sistemática e Revisão Exploratório) foi possível estabelecer um comparativo em relação a eficiência de cada método,
principalmente relacionado à questões de pesquisa com relevância acadêmica e
mercadológica;
• Requisitos de uma AS para CI: Um conjunto de requisitos essencias que uma AS
para CI deve atender foi estabelecido, a partir da análise das soluções existentes;
• Arquitetura de Software (AS) para CI e IoT: Uma AS que visa atender aos
principais requisitos de CI que combina conceitos de IoT foi especificada;
• Implementação inicial: Baseado na proposta desta dissertação, uma implementação inicial foi realizada e disponibilizado em domínio público. Esta implementação
serve de guia para a utilização desta proposta em qualquer cidade;
• Adaptação de dois métodos de avaliação: Não foi encontrado na literatura nenhum método de avaliação que fosse totalmente compatível com as peculiaridades
do contexto deste trabalho. Logo, foi proposta e utilizada uma adaptação de dois
métodos de avaliação: SAAM e ATAM. Esta adaptação foi aplicada, na qual se
pôde comprovar a sua utilidade. Este método pode ser empregado em qualquer
contexto semelhante, principalmente se a equipe esta geograficamente distribuída.
Além das contribuições finais listadas acima, alguns resultados intermediários deste
trabalho estão sendo reportados na literatura, como mostrado a seguir:
• TOMAS, G. H. R. P.; SILVA, W. M.; GARCIA, V. C. ; ALVARO, Alexandre, GAMA,
Kiev. Towards a Smart City Architecture based on Internet Of Things. Internet of
Things Technology and Applications in Information Sciences and Service Sciences,
2014.

5

CAPÍTULO 1. INTRODUÇÃO

• DA SILVA, WELINGTON M. ; ALVARO, Alexandre ; TOMAS, GUSTAVO H. R.
P. ; AFONSO, RICARDO A. ; DIAS, KELVIN L. ; Garcia, Vinicius C. . Smart
cities software architectures. In: the 28th Annual ACM Symposium, 2013, Coimbra.
Proceedings of the 28th Annual ACM Symposium on Applied Computing - SAC ’13.
New York: ACM Press. p. 1722-1727.
• TOMAS, G. H. R. P. ; SILVA, W. M. ; Garcia, Vinicius Cardoso ; ALVARO, Alexandre . Smart Cities Architectures: A Systematic Review. In: The 15th International
Conference on Enterprise Information Systems (ICEIS), 2013, Angers. Proceedings
of the 15th International Conference on Enterprise Information Systems (ICEIS).
Lisboa: SCITEPRESS Science and Technology Publications, 2013. p. 410-417.
• SILVA, W. M. ; TOMAS, G. H. R. P. ; Garcia, Vinicius Cardoso ; ALVARO, Alexandre . Synaptic City: An architectural approach using an OSGI Infrastructure
and GMaps API to build a City Simulator. In: The 15th International Conference
on Enterprise Information Systems (ICEIS), 2013, Angers. Proceedings of the
15th International Conference on Enterprise Information Systems (ICEIS). Lisboa:
SCITEPRESS Science and Technology Publications, 2013. p. 427-434.
• AFONSO, R. A. ; SILVA, W. M. ; TOMAS, G. H. R. P. ; ALVARO, Alexandre ; Garcia,
Vinicius Cardoso . Br-SCMM: Modelo Brasileiro de Maturidade para Cidades
Inteligentes. In: IX Simpósio Brasileiro de Sistemas de Informação (SBSI), 2013,
João Pessoa. Anais do III Simpósio Brasileiro de Sistemas de Informação. Curitiba,
PR, novembro de 2006. Porto Alegre: Sociedade Brasileira de Computação, 2013.
v. 1. p. 511-516.

1.6

Organização da Dissertação

O restante desta dissertação está organizado conforme se segue:
• Capítulo 2: contextualiza a temática de CI e IoT, além de esclarecer a interação
entre as duas áreas de pesquisa;
• Capítulo 3: apresenta a revisão bibliográfica sobre AS para CI que combinam
tecnologias IoT, com o objetivo de identificar as principais soluções existentes na
academia e na indústria e estabelecer um conjunto de requisitos fundamentais que
uma nova AS deve atender;
6

1.6. ORGANIZAÇÃO DA DISSERTAÇÃO

• Capítulo 4: descreve em detalhes a proposta da AS, ressaltando, principalmente,
como cada requisito é implementado;
• Capítulo 5: discute o processo de avaliação de AS realizado, totalmente remoto,
durante o desenvolvimento da solução, e apresenta os principais resultados;
• Capítulo 6: conclui esta dissertação por meio de de um resumo das principais contribuições desta pesquisa e discussões a respeito de alguns trabalhos relacionados.
Por fim, são apresentadas algumas observações finais e direções para pesquisas
futuras.

7

2
Cidades Inteligentes e Internet das Coisas

A alegria que se tem em pensar e aprender faz-nos pensar e aprender
ainda mais.
—ARISTÓTELES

As cidades são sistemas complexos que concentram um grande conjunto de serviços e
de infraestruturas e consomem um crescente volume de recursos e de energia, com um significativo impacto a nível econômico, ambiental e de qualidade de vida (ComputerWorld,
2013).
A literatura apresenta diversas definições do termo Cidade, porém a mais aceita
é descrita em Kuper (1995) como “um povoado relativamente grande e permanente”.
Geralmente, uma cidade possui alta densidade populacional e os cidadãos interagem
com indústrias, comércios e serviços. No quesito operacional, cidades são baseadas em
um conjunto de serviços urbanos básicos: energia, água, transporte, infraestrutura de
informação e comunicação, mercado, saúde pública e saneamento público (Morvaj et al.,
2011).
Este conjunto de serviços urbanos básicos é justamente onde se localizam os principais problemas das cidades (Morvaj et al., 2011). Além disso, com o crescimento
populacional supracitado no Capítulo anterior e o envelhecimento das infraestrturas,
surge a necessidade de aprimorar técnicas para otimizar a utilização destes serviços (Krco,
2010). Simultaneamente, necessita-se de um sistema no qual os demais serviços possam
ser criados e/ou otimizados para suprir as necessidades dos cidadãos.
Estes fatores demonstram os grandes desafios para os gestores das cidades. Problemas
relacionados ao tráfego, segurança, consumo de água e energia, dentre outros, têm sido
cada vez mais difíceis de serem administrados. A saber:

9

CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS

Segurança: Os altos índices de criminalidade são grandes preocupações da sociedade.
Assaltos, tráfico de drogas e crime organizado são manchetes na TV e nos jornais todos
os dias e são uma dura realidade das cidades brasileiras. Catástrofes como enchentes
são um problema de defesa civil devido a ocupação desordenada de encostas e morros,
ameaçando diversas comunidades em cidades por todo o Brasil. Segundo o Mapa das
Ocorrências Registradas pelas Polícias Civis (Janeiro de 2004 a Dezembro de 2005)1 ,
desenvolvido pela Secretaria Nacional de Segurança Pública, entre 2004 e 2005 a taxa de
roubo no Brasil por 100 mil habitantes aumentou de 516,7 para 519,4;
Transporte: O sistema de transporte coletivo é de qualidade e eficiência questionáveis
na maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e as
crescentes facilidades no financiamento de veículos, a quantidade de motocicletas e
automóveis no país é cada vez maior. A infraestrutura viária não acompanha este
crescimento da frota nacional e o trânsito é um problema em muitas cidades. Soluções
paliativas, como rodízio de veículos, apenas atenuam o crescimento do problema do
tráfego, quando, na verdade, uma otimização no sistema de transportes coletivos fazse necessária. Dois exemplos da situação do transporte coletivo no Brasil podem ser
encontrados na Pesquisa de Mobilidade Da Região Metropolitana de São Paulo2 : i) entre
2002 e 2012, a frota de veículos particulares cresceu 18%; ii) no mesmo período, a taxa
de motorização passou de 184 para 212 automóveis particulares por 1.000 habitantes;
Saúde: No Brasil, a infraestrutura do sistema de saúde é insuficiente para atender à
demanda. Vários hospitais públicos possuem atendimento deficitário, forçando pacientes
a aguardarem em longas filas de espera e o mesmo problema vem assolando pacientes do
sistema privado com planos de saúde. De acordo com a pesquisa da Assistência MédicoSanitária(AMS)3 realizada em 2002 pelo IBGE, houve uma variação na quantidade de
leitos disponíveis no Brasil, de 3,65 leitos por 1 000 habitantes em 1992, para 2,70 em
2002, uma redução de quase 25%;
Uso sustentável de recursos: O aumento do poder aquisitivo das classes mais pobres
gerou uma elevação no consumo de energia elétrica, mas classes média e alta ainda
representam a maior fatia do consumo de energia elétrica, pelo padrão de consumo e
conforto que envolve diversos tipos de eletroeletrônicos. Em Foz do Iguaçu, por exemplo,
7% das famílias correspondem a mais de 65% do consumo de energia elétrica da cidade
1 http://portal.mj.gov.br/services/DocumentManagement/FileDownload.EZTSvc.asp?DocumentID={42595482B0DD-4185-918E-80E4BAFAFC72}&ServiceInstUID={B78EA6CB-3FB8-4814-AEF631787003C745}
2 http://www.metro.sp.gov.br/pdf/mobilidade/pesquisa-mobilidade-2012.pdf
3 http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/ams/default.shtm

10

2.1. CONCEITO DE Cidade Inteligente (CI)

(Heberty H. Amaral and Fernandes, 2010);
Gestão de resíduos: O lixo tem se tornado um grande problema para cidades de
países em desenvolvimento. Enquanto cidades de países desenvolvidos põem em prática
diversas soluções de tratamento de lixo orgânico e de reaproveitamento de materiais
recicláveis, cidades de países como o Brasil não conseguem definir ou executar práticas
de reciclagem, salvo raras exceções. Por exemplo, de acordo com a Associação Brasileira
de Empresas de Limpeza Pública e Resíduos Especiais (ABRELPE)4 , em 2012 cerca
de 60% dos municípios registraram alguma iniciativa de coleta seletiva. Embora seja
expressiva a quantidade de municípios com iniciativas de coleta seletiva, muitas vezes
estas atividades resumem-se à disponibilização de pontos de entrega voluntária ou convênios com cooperativas de catadores, que não abrangem a totalidade do território ou da
população do município.
Apesar da evidente necessidade de cidades cada vez mais inteligente e a atenção que
a academia tem destinado para o tema, ainda não há um consenso a respeito da definição
do conceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado para
empregá-lo (Giffinger and Pichler-Milanovi´c, 2007; Caragliu et al., 2009; Li et al., 2011).
Logo, a Seção 2.1 visa clarificar a definição de CI a ser utilizada durante este trabalho.
Um paradigma que vem sendo utilizado em diversas abordagens para CI é a utilização
de IoT como ferramenta para captar dados e atuar sobre os serviços urbanos. Logo, a
Seção 2.2 visa contextualizar a IoT, a partir de alguns exemplos de aplicações.
Por sua vez, a Seção 2.3 inicialmente pontua alguns dos principais desafios, principalmente, nas cidades brasileiras. Em seguida, apresenta-se a integração existente entre
estas duas áreas de pesquisa e alguns exemplos de utilização desta integração para mitigar
alguma deficiência urbana.
Por fim, a Seção 2.4 consolida as principais contribuições deste Capítulo.

2.1

Conceito de Cidade Inteligente (CI)

A literatura apresenta algumas definições para o termo CI, porém ainda não há um
consenso a respeito deste conceito. A seguir, são apresentadas as principais definições
descritas na literatura e a definição que será utilizada no decorrer deste trabalho.
Em Giffinger and Pichler-Milanovi´c (2007) é ilustrada uma série de diferentes ambientes na qual o termo foi utilizado. Por exemplo, a definição de CI, quando associada com
economia, é uma cidade com indústria inteligente, na qual são empregadas tecnologias
de última geração para aprimorar os aspectos financeiros e econômicos. No aspecto
4 http://a3p.jbrj.gov.br/pdf/ABRELPE%20%20Panorama2012.pdf

11

CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS

educação, Giffinger et. al. caracteriza CI como o nível de escolaridade dos cidadãos.
Além disso, de acordo com Giffinger et. al., uma CI também pode ser mensurada a partir
do relacionamento entre o governo e os cidadãos e a utilização de modernas tecnologias,
não somente relacionada à Tecnologia da Informação e Comunicação (TIC), mas também
à outros domínios, como transporte e logística.
Por fim, Giffinger et. al. define seis características principais para cidades inteligentes:
smart economy, smart people, smart governance, smart mobility, smart environment e
smart living. A partir disso, uma CI é uma cidade com bom desempenho nestas seis
características, construída a partir da combinação inteligente de atividades independentes,
auto-decisivas e em prol dos cidadãos. Esta definição, oriunda dos resultados do projeto
European Smart Cities (Caragliu et al., 2009), é a mais bem conhecida e com maior
aceitação na literatura (Hernández-Muñoz et al., 2011), pois permite quantificar o nível
de inteligência das cidades. Por exemplo, inovação faz parte do eixo smart economy e é
calculado pela quantidade de patentes por habitantes (Haubensak, 2011).
Apesar dessa definição ser considerada a mais abrangente, cada trabalho adota uma
definição mais apropriada para o escopo do projeto. Em Su et al. (2011), a IBM define
CI como o uso de TIC para capturar, analisar e integrar informações relevantes no núcleo
dos sistemas das cidades. Ao mesmo tempo, uma CI pode tomar decisões inteligentes
para diferentes tipos de necessidades, incluindo aspectos diários, proteção ambiental,
segurança pública, serviços da cidade e atividades industriais e comerciais.
Analogamente, em Kanter et al. (2009) o termo CI é definido como uma cidade
que combina TICs com a infraestrutura física, para prover conveniências aos cidadãos,
como: eficiência energética; aumento da qualidade da água e do ar; identificar e resolver
rapidamente qualquer problema no funcionamento dos sistemas da cidades; mitigar
desastres; capturar dados para apurar a tomada de decisões e a utilização de recursos de
forma eficiente. Logo, a CI não pode ser vista como a soma de partes independentes, mas
uma rede de infraestrutura interconectada, na qual cada recurso é dependente do outro.
Em Steventon and Wright (2005), as CIs se referem aos ambientes físicos em que
as TICs e os sistemas de sensoriamento são transparentes para os cidadãos, porém
desepenham papel fundamental para garantir o funcionamento operacional da cidade.
Uma CI também é definida como um território no qual as TICs propiciam inovações
em diversos segmentos, combinando a criatividade e o talento individual em prol da
população da cidade, instituições locais e orgãos governamentais (Komninos, 2002;
Schumpeter, 1934).
Em ComputerWorld (2013) defende-se que CI não é um conceito tecnológico, mas
12

2.1. CONCEITO DE Cidade Inteligente (CI)

um conceito sociotécnico. Integra-se três vertentes essenciais: a tecnologia, as pessoas e
as instituições. Uma CI tem que centrar a sua atuação nos cidadãos e nas comunidades
onde vivem e trabalham.
Em relação aos aspectos governamentais, Toppeta (2010) acredita que uma CI deve
identificar e otimizar os processos governamentais, mitigando a burocracia que envolve o
processso de inovação de soluções e gerenciamento de técnicas sustentáveis.
Por fim, CI pode ser considerada um conjunto de comunidades inteligentes (Li et al.,
2011). A partir dessa perspectiva, a World Foundation for Smart Communities (Fundação
Mundial para Cidades Inteligentes)5 define que uma CI é uma comunidade com avanços
significativos em TICs que transformam o cotidiano dos cidadãos, melhorando os aspectos
relacionados ao trabalho e ao lazer de forma incremental e transparente (Eger, 2011).
Além da falta de consenso quanto ao termo CI, existem outros termos que são
comumente aplicados aos mesmos contextos, como “cidades virtuais”, “cidades digitais”,
“cidade informatizada”, “cidade eletrônica” (Komninos, 2006). Ao generalizar esse
conceito aos ambientes inteligentes que se relacionam com serviços urbanos, vários
sinônimos de CI são frequentemente empregados, como “information city”, “wired city”,
“telecity”, “knowledge-based city”, “electronic communities”, “electronic community
spaces”, “flexicity”, “teletopia”, “cyberville” (Droege, 1997).
Essa ausência de consenso é devido aos múltiplos movimentos científicos, tecnológicos e sociais que compõem o contexto de uma cidade (Komninos, 2006). Em cada
disciplina, existe uma série de problemas que afetam diretamente diversos serviços
existentes, como transporte, segurança, provisão/consumo de energia elétrica e água,
saneamento básico, utilização de recursos naturais, controle de catástrofes, principalmente no que tange a gestão individual e influência mútua, até como planejar e otimizar a
utilização em resposta a diferentes cenários.
Neste trabalho, uma combinação destas principais definições com diferentes vieses é
considerada:

“Cidade Inteligente (CI) é a combinação de Tecnologia da Informação e
Comunicação (TIC) com todos os aspectos que compõem uma cidade, desde aos
aspectos físicos até governamentais, combinados de forma a satisfazer às necessidades
dos cidadãos ”.

5 http://www.smartcommunities.org

13

CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS

2.2

Conceito de Internet of Things (Internet das Coisas)
(IoT)

De acordo com Giusto et al. (2010), a Internet of Things (Internet das Coisas) (IoT),
também conhecida como Internet dos Objetos, é um paradigma que vem crescendo no
cenário moderno de telecomunicações sem fio. A idéia básica deste conceito é a presença
de um conjunto de objetos (things) - como Radio-Frequency IDentification (RFID),
sensores, atuadores, telefones celulares - que, por meio de mecanismos de endereçamento
único (como a Internet), são capazes de interagir e cooperar uns com os outros para
alcançar objetivos em comum.
Sem dúvida, o principal impacto da IoT será sobre alguns aspectos do cotidiano e
comportamento das pessoas (Atzori et al., 2010). Por exemplo, já existem aplicações IoT
que permitem o monitoramento de atividades físicas6 e controle de medicamentos de uso
contínuo7 . Outro conjunto de aplicações que interferem no cotidiano das pessoas são as
voltadas para o ambiente doméstico. Por exemplo, ligar e desligar aparelhos domésticos
à distância8 , medir a temperatura da casa9 e até mesmo monitorar o jardim10 já são
realidades.
Ao considerar a diversidade de aplicações ilustradas acima, pode-se inferir o motivo
pelo qual IoT é incluída pelo Conselho Nacional de Inteligência dos EUA (NIC) na lista
das seis tecnologias civis “com impactos potenciais sobre o poder nacional dos EUA” (,
NIC). Além disso, o NIC prevê que até 2025 os “objetos” estarão presentes em todas as
coisas cotidianas, como documentos, embalagens de alimentos e móveis.
A partir da evidente gama de possibilidade oriundas da IoT, torna-se natural associálas ao contexto de CI. Em uma CI, para o funcionamento adequado dos serviços inteligentes é necessária a utilização de tecnologias que sejam capazes de captar e distribuir
estas informações (Li et al., 2011) para uma AS centralizada (Haubensak, 2011).

6 http://www.fitbit.com/
7 http://www.vitality.net/glowcaps.html
8 http://www.belkin.com/us/Products/home-automation/c/wemo-home-automation/
9 https://nest.com/
10 http://www.harvestgeek.com/

14

2.3. INTEGRAÇÃO DE Cidade Inteligente (CI) COM IOT! (IOT!)

2.3

Integração de Cidade Inteligente (CI) com Internet
of Things (Internet das Coisas) (IoT)

A partir dos problemas comumente enfrentado pelas cidades, surge o desafio de combinar
diferentes informações com TIC, a fim de mitigar estes problemas e promover melhores
condições de vida aos cidadãos. Neste sentido, as tecnologias IoT também podem ser
integradas como ferramentas para monitorar os eventos de um ambiente, atuar a fim de
conter uma situação emergencial ou, até mesmo, propagar uma informação relevante.
Os cenários da utilização de TICs e IoT para esta finalidade são os mais variados.
Um exemplo é o monitoramento do trânsito em estradas e rodovias. Este monitoramento,
a partir de sensores espalhados pelas vias, poderia alimentar sistemas de informação
capazes de gerar rotas em tempo real, redistribuindo os veículos, aumentando a fluidez
das vias. Esta redistribuição poderia ser feita ao enviar informações para os dispositivos
GPS dos veículos ou até mesmo por um conjunto de painéis indicativos para orientar
os motoristas sobre a melhor rota. A comunicação e a troca de informações entre estes
diferentes objetos constituem um cenário de uso clássico de IoT.
Outro exemplo da utilização maciça de TIC e IoT é o controle do consumo residencial
de energia elétrica a partir de eletrodomésticos habilitados a otimizar seu funcionamento
de acordo com os hábitos e necessidades de seus moradores. Além disso, estes eletrodomésticos, atuando em uma rede de objetos, podem trocar informações a fim de otimizar
tarefas rotineiras dos cidadãos, tais como, compras nos supermercados e manutenção do
lar.
Um caso real da eficiência em aplicar TICs baseada em IoT é a redução de 30%
das emissões de carbono em Londres, apenas com a mudança de comportamento dos
cidadãos, a partir do acompanhamento de todas as tarefas dia-a-dia (Tomordy, 2011).
Esta mudança de comportamento foi possível a partir de uma rede sensores que fornecia
informações do nível de carbono em tempo real .

2.4

Considerações Finais do Capítulo

Este Capítulo contextualizou as duas grandes áreas de pesquisa deste trabalho: Cidade
Inteligente (CI) e Internet of Things (Internet das Coisas) (IoT).
Como discutido previamente, ainda não há um consenso a respeito da definição
mais adequada para CI. Logo, a Seção 2.1 apresentou algumas definições disponíveis
na literatura. A partir destas, a definição a ser utilizada neste trabalho foi explicitada,

15

CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS

considerando os diferentes pontos de vistas dos demais autores.
Em seguida, a IoT foi definida e exemplificada na Seção 2.2. A partir desta, podese notar a evidente correlação entre estas duas áreas de pesquisa. Este fato pode ser
comprovado ao analisar as principais aplicações de IoT: a grande maioria visa otimizar
algum aspecto relacionado ao cotidiano das pessoas, tanto no ambiente profissional
quanto no doméstico (Atzori et al., 2010).
Por fim, a Seção 2.3, apresentou alguns exemplos de utilização de IoT e dos conceitos
de CI para mitigar estes problemas urbanos. Algumas destas iniciativas já estão sendo
desenvolvidas e validadas, porém, para de fato se estabelecer uma CI, é necessária a
integração destas iniciativas a partir de uma AS centralizada (Filipponi et al., 2010;
Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011; HernándezMuñoz et al., 2011).
Diversas abordagens já estão sendo desenvolvidas utilizando o paradigma: IoT como
ferramenta para captar e atuar sobre os serviços urbanos em prol da consolidação de
uma CI. Logo, o próximo Capítulo apresenta exemplos destas abordagens, encontradas a
partir de dois métodos de revisão da literatura.

16

3
Revisão da Literatura de Arquiteturas de
Software para Cidades Inteligentes

Cada dia sem treinar, estudar ou se dedicar a algo realmente
importante significa um dia mais distante da realização do seu sonho.
—BERNARDO ROCHA DE REZENDE, 2010 (Transformando Suor
em Ouro)

No contexto de uma Cidade Inteligente (CI), as Arquitetura de Software (AS) são de
suma importância por uma série de fatores. Primeiramente, uma AS pode permitir a troca
de informações entre diferentes serviços urbanos, a fim de fornecer serviços mais efetivos
para os cidadãos. Outro fator relevante é a possibilidade de criar aplicações Internet of
Things (Internet das Coisas) (IoT) que consumam ou forneçam algum tipo de dado para
uma determinada finalidade, como por exemplo, captar informações de pontos turísticos
da cidade para melhorar a experiência dos turistas. Esta integração das aplicações IoT
com a AS será independente da tecnologias utilizada, devido a vasta gama de sensores,
atuadores, pessoas, sistemas, drivers e qualquer outro componente capaz de interagir
com os serviços urbanos. Além disso, a AS pode permitir que governos adotem ações
estratégicas voltadas para as reais necessidades dos cidadãos.
Ao adotar um modelo como esse, na qual uma AS centralizada processa e distribuí
dos dados dos serviços urbanos, uma CI pode de fato ser implementada, uma vez que
existirá um meio pelo qual os serviços urbanos poderão ser integrados (Filipponi et al.,
2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011; HernándezMuñoz et al., 2011).
Nos ínicio dos anos 90, a AS era basicamente voltada para os sistemas cliente-servidor,

17

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

na qual uma máquina exercia o papel de cliente requisitante e a outra máquina, o papel
de servidor com a responsabilidade de atender as requisições (Sommerville, 2007). Deste
modo, a arquitetura cliente-servidor tornou-se padrão no desenvolvimento de software,
sendo em nossa atualidade ainda explorada e, sobretudo, mesclada a outras AS para
atender ao objetivo de um software (Fowler, 2012). Já na década de 2000, nota-se que
as aquiteturas propostas são cada vez mais heterogêneas, na qual estilos e tecnologias
diferenciadas se misturam para formar novas versões de representações arquiteturais
(Bass et al., 1998).
Dessa forma, o que se almeja investigar neste Capítulo é o estado da arte de Arquiteturas de Software (AS’s) para CI que empregam IoT na solução de problemas urbanos.
Para aumentar a abrangência desta investigação, duas revisões da literatura foram
realizadas: Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). As revisões
sistemáticas possibilitam a replicação do procedimento, pois possuem um processo
repetitível. Porém, a temática deste trabalho envolve aspectos mercadológicos que podem
ser excluídos dessas revisões, por não serem publicados nos veículos convencionais.
Logo, as revisões exploratórias são importantes, pois permitem incluir diversos trabalhos
de diferentes veículos de publicação, como por exemplo, relatório técnico de empresas.
Porém, esse tipo de revisão possui certa resistência por ser baseado totalmente nas buscas
não-metódicas do pesquisador.
Estes dois métodos de revisão literária também têm como objetivo identificar a
necessidade de criar ou adaptar um padrão arquitetural específico para este contexto de
CI e IoT.
Na Revisão Sistemática, foram selecionadas 11 abordagens. Já na Revisão Exploratória 16 abordagens foram selecionadas. Nestas duas revisões, 7 abordagens foram
encontradas em ambas as revisões. Estes trabalhos destacam-se por envolverem aspectos
acadêmicos e mercadológicos. Nestes casos, optou-se por descrevê-los apenas na Revisão
Sistemática. Por fim, ao todo, foram encontrados 20 abordagens condizentes com o
objetivo deste trabalho.
Após a descrição das abordagens encontradas nas duas revisões, a Seção 3.3 visa
consolidar as características mais relevantes de cada abordagem. Em seguida, pretende-se
estabelecer um conjunto de requisitos que uma AS para CI deve atender (Seção 3.4).
Este conjunto de requisitos e os demais resultados da Revisão Exploratória foram
publicados em da Silva et al. (2013). Já os resultados da Revisão Sistemática foram
publicados em Tomas et al. (2013).
Por fim, a Seção 3.6 dicute os pontos mais relevantes deste Capítulo e a Seção 3.7
18

3.1. REVISÃO SISTEMÁTICA

finaliza o Capítulo.

3.1

Revisão Sistemática

Conforme brevemente introduzido na Seção anterior, de acordo com Kitchenham and
Charters (2007) o objetivo de uma SLR é fornecer indícios para o desenvolvimento
de pesquisas baseadas em evidências, a partir da seleção e síntese das pesquisas mais
relevantes. Além disso, a SLR deve identificar, avaliar, interpretar e comparar todas as
fontes relevantes para uma determinada questão de pesquisa.
Diversas abordagens arquiteturais têm sido propostas na literatura, mas essa revisão
foca-se somente nas AS’s que utilizam o paradigma de combinar IoT como ferramenta
para a implementação de uma CI.

3.1.1

Metodologia de Pesquisa

O objetivo desta subseção é descrever a estratégia de busca e todos os passos utilizados
para filtrar e extrair as informações relevantes de cada pesquisa. Essa estratégía segue as
recomendações descritas por Kitchenham and Charters (2007).
Estratégia de Busca e Fontes de Dados
A estratégia empregada para a construção das strings de buscas segue a mesma metodologia emprega por Kitchenham and Charters (2007), Chen et al. (2009) e Khurum and
Gorschek (2009). Esta estratégia é ilustrada na Figura 3.1.

Figura 3.1 Estratégia de Busca

Seguindo esta estratégia, a seguinte string de busca foi definida:

(smart city OR intelligent city OR digital city OR urban environment) AND (internet of
things OR heterogeneous sensors) AND (architecture OR middleware OR platform)

19

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

Devido à variação dos resultados de cada motor de busca das principais fontes digitais
da literatura (como IEEExplore, Springer Link e ACM Digital Library), não é possível
utilizar a mesma string de busca em todas as fontes digitais (Chen et al., 2009). Logo,
foi necessário um esforço para garantir que as strings utilizadas sejam logicamente e
semanticamente equivalentes.
Após definir a string de busca, realizou-se a busca nos seguintes repositórios digitais (1.
IEEExplore; 2. Science Direct; 3. ACM Digital Library; 4. Springer Link; 5. CiteSeerX;
6.Academia.edu; e 7. ISI Web of Science). Além disso, considerando que CI é uma linha
de pesquisa que envolve diversos aspectos de negócio e mercado, realizou-se a busca por
patentes no banco de patentes World Intellectual Property Organization(WIPO)1 .
Em relação à busca manual, foi realizada nos seguintes anais (1. International Conference on Computational Intelligence, Modeling and Simulation (IJCCI); 2. International
Conference on Intelligent Environments (IE); 3. Multimedia Information Networking and
Security (MINES); 4. Emerging Technologies for a Smarter World (CEWIT); 5. International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing
(IMIS)).
A Tabela 3.1 ilustra a quantidade de abordagens encontradas de acordo com as fontes
de pesquisa.
Tabela 3.1 Quantidade de abordagens por fonte de pesquisa

Fonte de Dados
1. IEEExplore
2. Science Direct
3. ACM Digital Library
4. Springer Link
5. CiteSeerX
6. Academia.edu
7. ISI Web of Science
8. WIPO
9. IJCCI
10. IE
11. MINES
12. CEWIT
13. IMIS
Total

#
24
1291
1933
1484
399
42
4
1233
4
8
3
3
7
6435

A qualidade dos motores de busca podem influenciar a integridade das abordagens
1 http://www.wipo.int

20

3.1. REVISÃO SISTEMÁTICA

identificadas como primários, conforme discutido em Chen et al. (2009). Dessa forma,
algumas abordagens podem não ter sido incluídas, caso os autores tenham usado outros
termos além dos mencionados acima.
Seleção das Abordagens
Nesta SLR foram selecionadas somente abordagens que propõem uma AS e/ou framework
que centralize os diversos contextos e tecnologias que envolvem o ambiente urbano. Para
tal, 5 pesquisadores, sendo 2 mestrandos, 2 PhD e 1 doutorando, foram envolvidos no
processo de seleção e classificação
Após definir a string de busca e as fontes, foram definidos filtros para classificar as
abordagens encontradas. A Figura 3.2 ilustra os resultados de cada filtro, baseado na
quantidade de abordagens resultantes.

Filtro 1

Estudos encontrados nas
fontes de pesquisa

6435

Filtro 2

Exclusão de estudos que não
foram publicados entre 20082012

4310

Filtro 3

Exclusão de estudos baseada
no título

71

Filtro 4

Remoção de duplicações

61

Filtro 5

Exclusão de estudos baseada
nos resumos.

33

Filtro 6

Exclusão de estudos baseada
na relevância.

11

Figura 3.2 Resultado da filtragem das abordagens

O objetivo destes filtros é selecionar as principais abordagens que descrevem AS’s
para CI baseadas em IoT. O primeiro filtro corresponde a todas as abordagens encontradas
nas fontes de pesquisa, descritas anteriormente, a partir da string de busca.
O segundo filtro foi aplicado para excluir as abordagens que não foram publicadas
entre 2008-2012. Este intervalo foi escolhido após analisar e verificar que as abordagens
propostas antes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens foram
propostas para solucionar problemas específicos de um contexto usando apenas uma
tecnologia, sem analizar a conexão entre os diferentes contextos urbanos.

21

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

Para realizar a terceira filtragem, todos os títulos das abordagens foram lidos e
resultaram apenas 71. Esta alta discrepância com o valor resultante do filtro anterior está
relacionada a falta de eficiência das engines de busca, como discutido em Kitchenham
et al. (2009).
O quarto filtro corresponde à elimição de abordagens duplicadas. Já, para realizar o
quinto filtro, todos os resumos foram lidos e discutidos entre a equipe.
Cada uma das 33 abordagens resultantes foram lidas e discutidas entre a equipe desta
SLR. Em seguida, apenas 11 abordagens resultaram como relevantes para a proposta
deste trabalho.
Em relação aos critérios de inclusão, as abordagens foram incluídas se:
• Propõem uma AS para centralizar a informação de diferentes contextos urbanos
OU
• Descreve uma AS IoT na qual seu design permite a combinação de uma ou mais
tecnologias diferentes e/ou contextos urbanos E
• Abordagens que ainda não foram selecionadas.
Durante esta revisão, foram encontradas diversas abordagens que descrevem a mesma
AS. Neste caso, somente o trabalho mais completo foi considerado. Após essa etapa,
restaram 11 abordagens para serem analisadas.
Existem diversas razões para esta alta discrepância entre a quantidade inicial de
trabalhos com a quantidade resultante. A principal razão é a alta quantidade de estudos
duplicados com resultados semelhantes. Estas razões são discutidas e explicadas em
Kitchenham et al. (2009).
Em relação às patentes, não foi encontrada nenhuma patente relacionada. Geralmente,
as patentes mais próxima à temática dessa revisão sistemática descrevem um algoritmo
específico ou a otimização de uma técnica empregada em um ambiente controlado.

3.1.2

Resultados

Após realizar as buscas nas principais fontes de pesquisa, filtrar as abordagens de acordo
com os critérios descritos na Seção anterior, restaram 11 abordagens. Estas abordagens
foram lidas e discutidas entre os 5 pesquisadores supracitados, com o objetivo de realçar
os tópicos relacionados às questões de pesquisa. Esta seção visa discutir estas abordagens,
iniciando por uma descrição inicial de cada abordagem.
22

3.1. REVISÃO SISTEMÁTICA

Caso uma abordagem tenha algum nome, este será utilizado para referir-se a ela. Caso
contrário, será dado um nome usando o sobrenome do primeiro autor seguido pelo ano
de publicação. A Tabela 3.2 lista as 11 abordagens analisadas, organizadas em ordem
cronológica.
Tabela 3.2 Abordagens resultantes por ordem cronológica

ID
1
2
3
4
5
6
7
8
9
10
11

Abordagem
Al-Hader’2009
Anthopoulos’2010
SOFIA
EcoCity/ISMP-UC
CPAF
SmartSantander
IMS
USN
Wu’2011
Fazio’2012
S3 OiA

Ano
2009
2010
2010
2011
2011
2011
2011
2011
2011
2012
2012

Referência
(Al-Hader et al., 2009)
(Anthopoulos and Fitsilis, 2010)
(Filipponi et al., 2010)
(Lee et al., 2011)
(Mostashari et al., 2011)
(Sanchez et al., 2011)
(Shao, 2011)
(Hernández-Muñoz et al., 2011)
(Wu et al., 2011)
(Fazio et al., 2012)
(Vega-Barbas et al., 2012)

Abordagens Resultantes
Arquitetura de Software (AS) para CI podem ser desenvolvidas a partir de diferentes
áreas do conhecimento. Esta Seção visa fornecer uma descrição alto-nível das AS’s
encontradas, ordenadas em ordem cronológica, ressaltando os principais objetivos e
características de cada abordagem.
Iniciando por Al-Hader’2009 (Al-Hader et al., 2009), no qual é proposto uma AS
baseada em quatro princípios: aplicações, negócios, gerenciamento de processos e
infraestrutura de redes. O primeiro princípio corresponde às aplicações que fazem uso de
diferentes tecnologias para monitorar sensores, como Global Positioning System (GPS).
De acordo com (Al-Hader et al., 2009), a maioria destas aplicações atendem as demandas
operacionais das cidades, porém, ao utilizar as regras definidas no segundo princípio negócios - elas podem agregar soluções economicamente viáveis. O terceiro princípio é o
gerenciamento de processos na qual relacionamentos, regras, estratégias e políticas entre
as aplicações e as unidades de negócios são definidas. Finalmente, o último princípio
corresponde a toda a infraestrutura de rede, responsável por conectar os outros três
princípios.
Anthopoulos and Fitsilis (2010) propõem uma AS baseada na análise de diferentes
iniciativas já implementadas, modelada a partir dos princípios das Enterprise Architec-

23

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

tures (Booch, 2010). Anthopoulos and Fitsilis (2010) enfatizam que a construção de
uma CI deve ser guiada pela integração de sistemas legados com as novas infraestruturas,
migração e reuso de dados existentes, simplificação dos processos urbanos, otimização
da utilização de recursos naturais, interoperabilidade de sistemas e equipamentos e prover
ferramentas para monitoramento, gerenciamento e análises.
A integração de sensores é um dos objetivos da AS conhecida como SOFIA (Filipponi
et al., 2010), centrada no conceito de Smart Environment (Ambiente inteligente) como um
ecossistema de interação de objetos, como sensores, dispositivos e sistemas embarcados
em geral. A AS SOFIA é baseada em eventos, na qual cada evento corresponde à
mudança de estado de qualquer sistema de TIC. Estes eventos podem ser iniciados a
partir de eventos do mundo real (como detecção de presença) ou ao término de algum
processamento.
O monitoramento e gerenciamento de sensores também são objetivos definidos pela
abordagem denomida EcoCity/ISMP-UC (Lee et al., 2011). A AS EcoCity/ISMP-UC é
constituída de três camadas. A camada inferior consiste de diferentes tipos de sensores,
atuadores e outros dispositivos distribuídos pela cidade. Já a camada superior representa
um conjunto de serviços U-eco City. Entre essas duas camadas existe um middleware
responsável por coletar e processar informações contextuatilizadas. Esta AS orientada à
serviços possibilita o desenvolvimento de serviços independentes e que sejam consumidos
via interfaces padronizadas, como web services.
Por sua vez, Mostashari et al. (2011) propõem um framework denominado Cognitive
Process Architecture Framework (CPAF), o qual permite o desenvolvimento de diferentes
serviços urbanos com habilidades cognitivas. Nesse contexto, cognição é a habilidade do
sistema aprender a partir das experiências anteriores e adaptar seu comportamento a partir
destas conclusões. Um sistema cognitivo é capaz de perceber e responder às mudanças
no ambiente, portanto, pode melhorar a performance dos serviços urbanos.
Outra abordagem na qual utiliza vários sensores embarcados nos contextos urbanos é
SmartSantander Sanchez et al. (2011). A quantidade de dispositivos configurados na AS é
superior à 12.000. O SmartSantander provê: i) uma AS refência para sistemas IoT; ii) um
escalável e heterogêneo laboratório para prototipação de aplicações IoT; iii) um conjunto
representativo de casos de uso implementados para facilidades de experimentação e iv)
um grande conjunto de experimentos relacionados à Internet do Futuro.
Com o mesmo objetivo de interoperabilidade de objetos abordado em Smart Santander,
a abordagem IMS (Shao, 2011) propõe uma AS que combina IoT com os cidadãos das
cidades. Shao (2011) acreditam que o desenvolvimento de TIC esta relacionado à
24

3.1. REVISÃO SISTEMÁTICA

proximidade com os moradores das cidades. Para isso, IMS é baseada em três camadas:
acesso, sessão e aplicações. A camada de acesso é a camada mais baixa e provê toda
a infraestrutura para acessar a rede IMS a partir de diferentes terminais. A camada de
sessão provê o gerenciamento de sessões entre a camada inferior (Acesso) e a superior
(Aplicações). Finalmente, a camada de aplicação permite o desenvolvimento de diversas
aplicações.
A interoperabilidade de objetos também é explorada por Hernández-Muñoz et al.
(2011), que propõem uma AS denominada Ubiquitous Sensor Network (USN). O objetivo
é prover uma infraestrutura que seja capaz de integrar sensores heterogêneos e distantes
geograficamente em um base centralizadora, na qual serviços podem ser facilmente
desenvolvidos. Adicionalmente, a AS inclui um módulo conhecido como USN-Gateway
que possibilita a interoperabilidade entre redes de sensores e redes IP.
Da mesma forma que USN, Wu’2011 (Wu et al., 2011) propõem um middleware para
gerenciamento de informações dispersas oriundas de múltiplas fontes, com diferentes
formatos e estruturas. Esta abordagem é construída seguindo os princípios de Arquitetura
Orientada a Serviços (SOA), baseada em duas principais componentes: modelo ContractFirst e agente de troca de mensagens.
Em Fazio’2012 (Fazio et al., 2012) é proposto uma AS que permite a agregação
de diferentes tipos de informações oriundas de diferentes sensores distribuídos pelos
contextos urbanos. O principal objetivo dessa abordagem é de prover dados contextualizados, combinando diferentes fontes de dados. Para isso, a AS consiste de quatro
camadas: I) REST que permitem interações sob-demanda com os clientes, aplicações
e outros serviços; II) Sensor Observation Service Agent (SOS Agent) que suporta todas
as funcionalidades para a descrição de sensores; III) Sensor Manager capaz de interagir
com sensores, coordenar suas atividades e coletar dados para as demais camadas; IV)
Sensing Infrastructure é composto de vários diferentes sensores.
Finalmente, a abordagem conhecida como S3 OiA (Vega-Barbas et al., 2012) também
permite o gerenciamento de diferentes tipos de informação. A AS S3 OiA é sintática
e semântica aos princípios do SOA, que permitem a integração de qualquer tipo de
dispositivo IoT. Com essa estratégia, a AS suporta a composição de aplicações ad hoc.
Para tal, foi definido dentro do projeto da AS um conjunto de módulos de dependência
semântica de gestão que controlam serviços e recursos, permitindo que os aplicativos já
criados possam continuar a execução, apesar das mudanças do contexto.

25

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

3.2

Revisão Exploratória

As abordagens e iniciativas em CI que se baseiam na adoção de IoT podem ser desenvolvidas tanto no ambiente acadêmico quanto no empresarial. Por exemplo, pode-se
ressaltar o interesse das organizações governamentais e/ou privadas, como Microsoft
(PlanIT, 2012), além das iniciativas nos modelos de Startup, como Libelium 2 e Every 3 .
Além disso, pode-se encontrar diversas iniciativas em formato Web/HTML ou relatório técnico disponibilizados pela própria organização, como HP (Hoover et al., 2010) e
IBM (Dirks and Keeling, 2009).
Desta forma, para aumentar a eficácia e a abrangência da revisão literária faz-se
necessário à realização de uma revisão exploratória. Uma revisão exploratória consiste
em um mecanismo que não possui nenhum processo pré-definido para encontrar as fontes
de informações.
Nesse tipo de revisão, todas as fontes relacionadas com o tema são analisadas, independente do tipo e do veículo de publicação do conteúdo. Em algumas situações, essas
revisões podem ser consideradas mais abrangentes, por não possuírem nenhum processo
de classificação. Porém, em outras situações, são consideradas tendenciosas, já que o
processo de revisão dificilmente pode ser repetido.
Logo, essa revisão exploratória visa discutir e analisar as principais abordagens que
propõem uma AS para CI baseada em IoT, encontradas nos mais diversos veículos
de comunicação. Dentre eles, destacam-se websites, blogs, relatórios técnicos não
publicados e eventos.

3.2.1

Metodologia de Pesquisa

Nas revisões exploratórias não há um processo ou guideline definido (Pollitt, 2007).
Geralmente, o procedimento consiste em levantar diversas fontes com a informação
desejada e então separá-las a partir de métodos específicos.
No caso dessa revisão, inicialmente algumas buscas foram realizadas em três repositórios de buscas: IEEE Xplore, Mendeley e ACM Digital Library. As principais
palavras-chaves utilizadas foram: Smart Cities, Internet of Things, Architecture, Smart
Enviroment, Digital City, Smart Cities Survey. Apesar de empregar estas palavras-chaves,
nenhuma string de busca específica foi definida.
2 http://www.libelium.com
3 http://www.evrythng.com

26

3.2. REVISÃO EXPLORATÓRIA

A partir dos resultados dessas buscas, alguns trabalhos foram classificados como
relevantes de acordo com o título e uma rápida leitura do conteúdo. Em seguida, todos os
trabalhos restantes foram lidos e discutidos, com o mesmo grupo da Revisão Sistemática,
do ponto de vista arquitetural e do emprego das tecnologias IoT para resolver a problemática de CI. A partir destas fontes, as principais referências destes trabalhos também
foram analisadas, repetindo a abordagem até não restar nenhum trabalho potencialmente
interessante.
As revisões exploratórios possuem alguns riscos eminentes. No contexto deste
trabalho, a principal ameaça é de não encontrar abordagens maduras e com os mesmos
objetivos desta proposta, uma vez que a metodologia de pesquisa não é abrangente o
suficiente. Além disso, ao realizar uma revisão exploratório após a SLR pode-se encontrar
várias abordagens repetidas.

3.2.2

Resultados

Em Klein and Kaefer (2008) é relatada uma perspectiva de CI voltada para negócio, especificamente de provedores de infraestruturas e soluções dentro do contexto de utilização
eficiente de energia elétrica para infraestruturas inteligente e data centers. O objetivo
do trabalho é aderir eficiência energética dos equipamentos, reduzindo os custos com
energia e criando mecanismos para que softwares e serviços tornem-se autoconscientes
de seu consumo de energia. De acordo com os autores, esta característica é essencial na
implementação de uma AS de CI, permitindo desenvolvimento e operação sustentáveis.
Em Blackstock et al. (2010) é proposta uma plataforma chamada Magic Broker
(MB2), a qual possui o objetivo de permitir a interoperabilidade de objetos. Inicialmente
desenvolvida com o objetivo de prover um modelo consistente e padronizar as interfaces
para a construção de aplicações de IoT, o MB2 esta sendo adaptado para o contexto
de CI. Para tal, além de prover a API para consultas, a plataforma provê abstrações
fundamentais, como: eventos, estado, serviços e gerenciamento de conteúdo.
O MB2 consiste de uma evolução do MB original (Erbad et al., 2008), na qual
foram inseridas diversas características para a construção de aplicações ubíquas, como a
inclusão de um middleware responsável por tratar as informações oriundas dos diferentes
dispositivos. Para tal, foram acoplados diversos protocolos de comunicação como HTTP e
XML. Cada implementação desses protocolos foi implementada usando serviços OSGi4 .
Seguindo o princípio de ser um laboratório para validação de tecnologias com foco
em CI, em Lisboa/Portugal foi construída uma cidade com 1700 hectares de extensão.
4 http://www.osgi.org

27

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

Conhecida como PlanIT Valley5 , a cidade deve produzir 150% da energia necessária,
gerenciar os resíduos sólidos e reciclar toda a água consumida. Empresas privadas, como
a Microsoft, Cisco, Massachusetts Institute of Techonology e McLaren Eletronic System
estão apoiando esse projeto (PlanIT, 2012).
A estratégia desse projeto é implementar um Sistema Operacional Urbano(UOS).
Esse sistema operacional é uma plataforma com o intuito de integrar cada domínio que
compõem uma cidade. O sistema será alimentado por uma vasta rede de sensores e todos
esses dados serão capturados por tempo indeterminado, para auxiliar na tomada e na
predição de decisões. Além de prever catástrofes, caso ocorra, o sistema pode antever os
possíveis impactos na cidade.
A sustentabilidade é um fator relevante que foi abordado em outras abordagens, como
em Masdar City (Haubensak, 2011). A cidade de Masdar City foi desenvolvida no deserto
de Abu Dhabi com 6 km quadrados, 50.000 habitantes, 1500 empresas e universidades.
O objetivo do projeto é desenvolver projetos auto-suficientes com o mínimo de impacto
ambiental. Toda a cidade é livre de combustíveis fósseis, na qual toda a energia é oriunda
de fontes renováveis, sem nenhum tipo de resíduo. Além disso, 80% da água consumida
será tratada. No quesito transporte, os veículos privados são proibidos e os meios de
transporte são veículos elétricos e bicicletas. As estações de transportes elétricos serão
separadas por uma distância de no máximo 200 metros. A primeira fase do contém
aparelhos ecologicamente corretos desenvolvidos pela General Eletric (GE).
Em Nam and Pardo (2011) é descrita a teoria da sinergia que deve existir entre
tecnologia, pessoas e instituições na concepção de CI. O trabalho destaca especificamente
que a inteligência refere-se comumente às mudanças inovadoras trazidas por novas
tecnologias. Em relação ao aspecto tecnologia, os autores afirmam que é essencial que a
cidade possua alta adaptabilidade às necessidades de seus cidadãos, independente de suas
limitações, com capacidade de autoconfiguração, proteção, otimização e recuperação
de falhas, garantindo disponibilidade de serviços a qualquer tempo. Para isso, faz-se
necessário uma infraestrutura de computação ubíqua, sobre a qual os serviços serão
disponibilizados.
De acordo com Andreini et al. (2011), SOA é considerada uma investida promissora
na construção de CI através da implementação da IoT. Assim, objetos conectados à rede
publicariam seus serviços, que por sua vez seriam acessados a partir de clientes móveis,
permitindo interações humano-máquina e máquina-máquina (M2M) mais flexíveis. Isso
seria construído a partir de uma abordagem semelhante ao Domain Name System (DNS),
5 http://living-planit.com

28

3.2. REVISÃO EXPLORATÓRIA

no qual um objeto seria identificado através de um nome, usado para acessá-lo e consultar
serviços. Os autores propõe uma implementação usando Distributed Hash Table (DHT),
que atribui o nível de escalabilidade desejado para a abordagem adotada, permitindo a
recuperação eficiente de serviços no contexto de aplicações para CI.
Outro aspecto muito relevante para qualquer centro urbano é a predição, prevenção e
correção de situações catastróficas, nas quais medidas urgentes devem ser tomadas no
menor tempo, com a máxima eficácia possível. Em Asimakopoulou and Bessis (2011), é
proposto uma AS de gerenciamento de desastres, baseada na coleta de informações de
diversas entidades - incluindo pessoas, residências, veículos - imersas em um ambiente
totalmente conectado, que monitoram o meio à sua volta. No processo de geração de
respostas a situações de emergência é necessário que se tenha conhecimento histórico
e em tempo real, das entidades e do ambiente no domínio em questão, para que a
solução encontrada seja eficaz. Para isso utilizou-se da abordagem crowdsourcing, na
qual os próprios cidadãos, habilitados por algum tipo de aplicação e/ou dispositivo,
contribuem com o fornecimento de dados sobre determinado cenário crítico, auxiliando
os stakeholders no processo de tomada de decisão com dados precisos e atualizados.
Já em relação à segurança, ainda na abordagem de Asimakopoulou and Bessis (2011)
é discutido que os consumidores e fornecedores de dados devem ser devidamente autenticados. Todas as entidades envolvidas na dinâmica proposta pela AS são consideradas
recursos, e sua alocação envolve uma negociação baseada em conjuntos de políticas. Isso
garante que a utilização dos recursos será sempre priorizada de acordo com a gravidade da
situação corrente. Mecanismos específicos foram criados para permitir alocação dinâmica
e geração parametrizada de alertas, assegurando a disponibilidade dos recursos.
Concomitantemente, em Attwood et al. (2011) é proposta uma AS para infraestruturas
críticas em CI, que destaca a necessidade de coleta de dados tempo real de diversos
aspectos dentro do ambiente urbano, servindo como substratos para tomada de decisões
em situações críticas. O funcionamento básico da AS consiste em um mecanismo de
anotação e agregação, no qual uma rede de sensores distribuída pela cidade estaria
conectada e cujos dados estariam mapeados para um serviço específico (Ex.: falha no
sistema de distribuição de energia elétrica). Quando algum tipo de falha fosse detectado,
os dados coletados seriam fornecidos a uma instância de raciocínio, responsável por
sugerir as medidas a serem tomadas para normalizar a situação. Para o caso de falha
em algum nó da rede de sensores, outra rede seria criada a partir dos nós ainda em
funcionamento, permitindo a preservação e distribuição dos dados. Para que esta AS seja
implementada é requerida uma infraestrutura de hardware distribuída, com capacidade de

29

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

processamento em tempo real, de alta disponibilidade, preparada para demandas variáveis,
tolerante a falhas e energeticamente eficiente.
Por fim, a sustentabilidade também é explorada na AS proposta por Zygiaris (2012).
O principal objetivo desta AS é propor um modelo que possa ser empregado em qualquer
planejamento urbano inteligente. Este modelo contempla os conceitos sustentáveis, especificamente na segunda camada, conhecida como Green City. Essa camada é sustentada
pela camada responsável pela infraestrutura da cidade e contém todas as políticas ambientais, por exemplo, o nível de CO2 permitido pelas residências. As demais camadas
correspondem, respectivamente: inovação, aplicação, integração, sincronização e interconexão entre diferentes redes. Para validar o objetivo proposto, este modelo foi utilizado
nas cidades de Barcelona, Amsterdã e Edimburgo.

3.3

Consolidação das Abordagens Encontradas

As Seções anteriores descrevem várias abordagens obtidas de dois métodos distintos:
Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). Na Revisão Sistemática,
foram selecionadas 11 abordagens. Já na Revisão Exploratória 16 abordagens foram
selecionadas e 7 abordagens foram encontradas em ambas as revisões. No total, 20
abordagens foram encontradas a partir destes dois métodos.
A partir da descrição dessas abordagens, pode-se notar a relevância da temática de CI,
devido, dentre outros fatores, ao interesse de grandes empresas como Microsoft e Cisco.
A Tabela 3.3 resume as principais características dessas abordagens. Para abordagens
publicadas em periódicos, a coluna “Ano” refere-se ao ano de publicação. Já para as
demais, a mesma refere-se ao ano de criação. Por sua vez, a coluna “Incentivo” categoriza
as abordagens que recebem incentivos dos governos (Público), iniciativa privada (Privada)
ou de ambos (Ambos).
Ao análisar a Tabela 3.3 percebe-se que a maioria das abordagens não estão amplamente validadas em diversos contextos, o que ratifica o caráter inovador deste trabalho.
Além disto, nota-se que das 20 abordagens, 11 não possuem nenhum tipo de validação
prática. Este fato deve-se à alguns fatores, como:
• Imaturidade da implementação das abordagens;
• Falta de dados reais para simulações;
• Pouquíssimas APIs públicas para acessos aos serviços de interesse do cidadão;
30

Ano
2008

2009
2010

2010

2011

2011

2011
2011
2011
2011

2011

2011
2011
2011

2011
2011

2012

2012
2012

2012

Aborgagem
Klein’2008

Al-Hader’2009
Anthopoulos’2010

MB2

Andreini’2011

Asimakopoulou’2011

Attwood’2011
IMS
CPAF
SOFIA

Wu’2011

Masdar City
USN
EcoCity/ISMP-UC

Nam’2011
SmartSantander

Zygiaris’2012

S3 OiA
Living PlanIT

Fazio’2012

Prover dados combinados

Integração de dispositivos via SOA
Criação de Sistema Operacional Urbano

Modelo para gerenciamento inteligente de qualquer cidade

Criação de plataforma ubíqua
Plataforma para a criação de soluções urbanas inteligentes

Gerenciamento eficiente de informações dispersas oriundas de
múltiplas fontes, com diferentes formatos e estruturas
Implementar sustentabilidade nos serviços urbanos
Interoperabilidade de objetos
O monitoramento e gerenciamento de sensores remotamente

Plataforma para situações críticas
Interoperabilidade de objetos
Criação de serviços urbanos com habilidades cognitivas
Integração de sensores

Plataforma escável que permite a interoperabilidade de objetos a
partir de SOA
Predição, prevenção e correção de situações catastróficas

Objetivo
Aumentar a eficiência energética de dispositivos conectados ao
ambiente urbano
Permitir a criação de soluções inteligentes
Integração dos sistemas legados com as novas infraestruturas,
migração e reuso de dados existentes
Permitir a interoperabilidade de objetos

Em andamento
Sem validação prática
Validada em ambiente controlado
Sem validação prática
Validada em ambiente controlado
Validado nas cidades de Barcelona, Amsterdã e Edimburgo
Sem validação prática
Em andamento em Lisboa,
Portugal
Validada em ambiente controlado

Validada em ambiente controlado
Sem validação prática
Sem validação prática
Sem validação prática
Validada em ambiente controlado
Sem validação prática

Validada em ambiente controlado
Sem validação prática

Sem validação prática
Sem validação prática

Validação
Sem validação prática

Privada

Privada
Privada

Ambos

Privada
Privada

Ambos
Privada
Ambos

Privada

Privada
Privada
Privada
Privada

Privada

Privada

Privada

Ambos
Privada

Incentivo
Privada

3.3. CONSOLIDAÇÃO DAS ABORDAGENS ENCONTRADAS

Tabela 3.3 Resumo das abordagens descritas na literatura

31

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

• Falta alta de apoio governamental para a realização de experimentos práticos nos
ambientes reais.
Esta falta de suporte governamental é comprovada na coluna “Incentivo”, na qual
apenas 4 abordagens contém esse tipo de suporte.
A partir dessas abordagens, a próxima Seção visa elencar um conjunto de requisitos
mínimos que uma nova AS para CI que combine IoT deve atender.

3.4

Requisitos para uma Arquitetura de Software para
Cidades Inteligentes

Considerando as diferentes realidades de CI nos mais diversos lugares do planeta, é
natural imaginar que uma mesma AS não se aplique a todos os cenários. Principalmente
pelo fato de que não se pode generalizar restrições locais, aspectos financeiros, sociais
e ambientais, ou mesmo garantir a adequação à dinâmica do cotidiano das diferentes
localidades. A partir do levantamento das arquiteturas realizado, a proposta desta Seção é
discutir um conjunto de requisitos fundamentais que devem ser atendidos na implantação
de uma AS para CI.

3.4.1

Interoperabilidade de objetos

Um dos requisitos mais discutidos e estudados em projetos IoT é a interoperabilidade
de objetos, na qual cada objeto é uma abstração de um sensor, atuador ou qualquer outro
dispositivo capaz de realizar algum tipo de computação (Atzori et al., 2010). De fato,
este é um requisito crítico para a consolidação de qualquer plataforma que utilize uma
vasta gama de objetos com diferentes especificações técnicas.
No contexto de CI este requisito também é fundamental, visto que os dados são
oriundos de diversos objetos, com tecnologias e protocolos variados.
As AS’s designam um módulo ou camada para atender esse requisito, como em
SOFIA (Filipponi et al., 2010), USN (Hernández-Muñoz et al., 2011), EcoCity/ISMPUC (Lee et al., 2011), Living PlanIT (PlanIT, 2012), Zygiaris’2012 (Zygiaris, 2012),
Wu’2011 (Wu et al., 2011) e S3 OiA (Vega-Barbas et al., 2012). Em particular, no caso da
USN (Hernández-Muñoz et al., 2011) este módulo, conhecido como USN-Gateway, além
de ser responsável pela interoperabilidade dos objetos em relação a plataforma, também
implementa mecanismos que permitem a interoperabilidade entre redes de sensores e a
rede IP.
32

3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES

3.4.2

Monitoramento em tempo real

Outro importante requisito inerente ao contexto de CI é o monitoramento em tempo
real. Este requisito é de suma importância para manter todos os serviços da cidade
constantemente atualizados.
Além disso, o monitoramento em tempo real é a ferramenta mais importante para
fornecer as informações mais relevantes para a predição e tomada de decisões de eventos
futuros e prever fenômenos. Um exemplo disso é o monitoramento do nível dos rios
durante as temporadas de chuva. Nessa situação, a partir de um monitoramento efetivo é
possível tomar medidas para mitigar possíveis transtornos aos cidadãos, como enchentes
e a transmissão de doenças.
Logo, este requisito pode ser considerado como fundamental. Neste contexto, as
AS’s que visam atender esse requisito são Al-Hader’2009 (Al-Hader et al., 2009), SOFIA
(Filipponi et al., 2010), SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñoz
et al., 2011), Asimakopoulou’2011 (Asimakopoulou and Bessis, 2011), Attwood’2011
(Attwood et al., 2011) e Living PlanIT (PlanIT, 2012).

3.4.3

Sustentabilidade

As cidades concentram altos índices de consumo de recursos naturais, como água e
alimentos. Além disso, vários problemas de poluição, seja poluição sonora, visual,
atmosférica, da água ou do solo, prejudicam a qualidade de vida dos cidadãos de várias
cidades, principalmente as metrópoles.
Neste sentido, uma AS para CI deve permitir que políticas sustentáveis (sustentabilidade) sejam implementadas com base em estatísticas relacionadas ao dia-a-dia
dos cidadãos. Por exemplo, iniciativas de consumo consciente de alimentos podem ser
implementadas ao mapear os hábitos dos cidadãos durante um dia.
Desta forma, estas políticas sustentáveis devem otimizar a utilização de recursos
naturais, a partir de iniciativas relacionadas ao meio ambiente e economia (Fels, 2010).
Para tal é importante ressaltar que políticas devem ser propostas nos diversos domínios
que compõem uma cidade, como Transporte e Educação.
As AS’s que integram sustentabilidade são Klein’2008 (Klein and Kaefer, 2008),
EcoCity/ISMP-UC (Lee et al., 2011), SmartSantander (Sanchez et al., 2011), Masdar
City (Haubensak, 2011) e Zygiaris’2012 (Zygiaris, 2012).

33

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

3.4.4

Aspectos sociais

Na implantação de CI a importância de alocar recursos, mais escassos, de forma otimizada
não pode significar a erosão da qualidade de vida das pessoas. Até porque, para de fato
estabelecer uma CI é necessário envolver as pessoas, procurando a sua participação para
lhes proporcionar maior qualidade de vida, mas protegendo a dimensão humana das urbes
cada vez mais em risco (ComputerWorld, 2013).
Uma AS para CI não pode ser sustentada somente com tecnologia. O propósito
principal na concepção de uma CI é o aumento na qualidade de vida de seus cidadãos,
através de aspectos sociais.
Apesar do aparato tecnológico fazer parte dos elementos necessários para a implementação de uma solução mais robusta, as pessoas precisam participar e ser beneficiadas
pelo processo, caso contrário, todo investimento será em vão. Um exemplo disso, é a
Cidade Digital de Trikala, Grécia, que após cinco milhões de euros gastos em manutenção de infraestrutura e 6 anos de funcionamento, a população não utilizava ou não tinha
conhecimento dos serviços digitais disponíveis (Anthopoulos and Fitsilis, 2010).
De qualquer forma, CI são construídas por pessoas, para pessoas, e essa deve ser
uma premissa contemplada em todas os aspectos supridos pela AS. Uma CI é feita de,
sobretudo, uma mudança no comportamento de seus cidadãos. As pessoas precisam sentirse inclusas como parte fundamental na implantação de uma CI, sentir-se estimuladas a
fazer parte da solução. Para isso podem ser criadas formas de estimular e/ou retribuir
esse interesse, como é caso da iniciativa Fun Theory6 , da Volkswagen, na qual mudam-se
as maneiras de fazer as coisas, a fim de estimular a mudança de hábitos.
Além disso, os serviços devem estar disponíveis para todos os cidadãos independente
de quaisquer restrições social, física, econômica ou financeira, a tecnologia deve ser
aplicada a fim de trazer benefícios coletivos, e não alienar ou elitizar uma pequena parte
da população.
Apesar da evidente importância deste requisito fundamental, apenas as AS’s que
explicitamente contém aspectos sociais são Klein’2008 (Klein and Kaefer, 2008), IMS
(Shao, 2011) e Asimakopoulou’2011 (Asimakopoulou and Bessis, 2011).

3.4.5

Ubiquidade/Mobilidade

A proximidade dos dispositivos com as pessoas/cidadãos, geralmente a partir da internet,
origina o termo ubiquidade (Spínola and Travassos, 2012). Neste sentido, este termo
6 http://www.thefuntheory.com/

34

3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES

corresponde a qualquer tecnologia móvel capaz de capturar informação sobre o ambiente
ou atuar sobre o mesmo (Sanchez et al., 2011).
Ao considerar que 4 bilhões de cidadãos já possuem smartphones (Hall, 2012), é
natural associar ubiquidade ao uso destes dispositivos. Porém outros dispositivos devem
ser utilizados, como ZigBee e RFID (Radio-frequency identification).
Logo, uma AS para CI deve permitir a comunicação efetiva com os mais diversos
dispositivos oriundos da temática de ubiquidade, uma vez que estes estarão fisicamente
próximos aos cidadãos. Neste contexto, as AS’s que já empregam alguns destes princípios
são SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñoz et al., 2011), MB2
(Blackstock et al., 2010) e Zygiaris’2012 (Zygiaris, 2012).

3.4.6

Privacidade e Segurança dos dados

O ambiente de uma cidade pode ser considerado ubíquo já que diversos sensores são
instalados em diferentes locais e coletam diferentes tipos de informação (Sanchez et al.,
2011). Todo esse volume de dados deve ser protegido fazendo uso das políticas de
privacidade e segurança dos dados, tanto em relação à disponibilidade quanto ao
armazenamento.
Certamente a consolidação destes políticas é um desafio que pode impedir os cidadãos, instituições e o governo de fornecerem determinados dados críticos. Este fato
pode ser comprovado a partir dos recentes casos de violação de privacidade dos dados
governamentais amplamente divulgados pela imprensa, como os documentos vazados da
National Security Agency (NSA) (Bird, 2013).
Devido a alta relevância deste requisito, não é admissível que uma AS não o satisfaça.
Apesar disso, apenas as AS’s SmartSantander (Sanchez et al., 2011), Living PlanIT
(PlanIT, 2012) e Fazio’2012 (Fazio et al., 2012) abordam este requisito.

3.4.7

Geolocalização dos sensores

De acordo com Shao (2011); Hernández-Muñoz et al. (2011); Vega-Barbas et al. (2012),
a geolocalização dos sensores é fundametal para o refinamento do processo de análise
de dados. Neste sentido, um sensor corresponde à uma abstração de qualquer dispositivo
capaz de fornecer informações sobre determinado contexto.
A partir destas informações geográficas dos sensores é possível realizar ações específicas para cada ambiente (Jauregui-Ortiz et al., 2012). Esta característica pode ser
notada nas abordagens IMS (Shao, 2011), USN (Hernández-Muñoz et al., 2011) e S3 OiA

35

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

(Vega-Barbas et al., 2012). No caso da abordagem IMS, a geolocalização dos sensores é
importante para a investigação do comportamento dos cidadãos; na USN, a localização é
considerada um requisito diferenciador; por fim, em S3 OiA a localização é utilizada para
unificar as ações realizadas sobre um determinado conjunto de sensores.

3.4.8

Composição de Dados Urbanos

Em uma visão sistêmica, ambientes urbanos são essencialmente um conjunto de domínios
complexos (como transporte, água, energia elétrica, saneamento básico, etc.) disponibilizados para suprir as necessidades de seus cidadãos. AS’s que se dispõe a dar suporte à
esses sistemas devem considerá-los como complementares na busca de um gerenciamento
urbano efetivo, ao invés de tratá-los de forma isolada.
Pelo fato de que CI pode ser considerada um sistema de sistemas, a composição dos
dados oriundos destes ambientes urbanos deve ser considerada um requisito fundamental.
Estes dados de cada ambiente urbano deve ser disponibilizado de forma que possam
ser reutilizados e agrupados para criar uma visão holística e contextualizada da cidade
na qual a AS foi implementada (Anthopoulos and Fitsilis, 2010; Nam and Pardo, 2011;
PlanIT, 2012).
Para atender essa composição de dados urbanos as AS’s Nam’2011 (Nam and Pardo,
2011), CPAF (Mostashari et al., 2011), IMS (Shao, 2011), Anthopoulos’2010 (Anthopoulos and Fitsilis, 2010), Fazio’2012 (Fazio et al., 2012) e Living PlanIT (PlanIT, 2012)
implementam explicitamente algum módulo que visa atender este requisito fundamental.

3.4.9

Histórico de dados

No contexto de CI, todos os componentes que compõem cada domínio de uma cidade
estão constantemente sendo modificados, seja por eventos humanos, naturais ou tecnológicos. Dessa forma, todo dado captado tem potencial para se tornar uma informação
relevante, desde que seja agregado a outros dados.
Estes dados históricos podem ser empregados na predição de eventos futuros, principalmente quando houver um grande período sem dados em tempo real. Por exemplo,
a partir de informações meterológicas dos anos anteriores é possível prever os meses
que poderão ter tempestades. Com informação nessa granularidade é possível adotar
providências preventivas para evitar catóstrofres.
Logo, torna-se substancial que as AS’s contemplem mecanismos eficientes de armazenamento e consulta desses dados. Como é citado em MB2 (Blackstock et al., 2010),
36

3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES

SmartSantander (Sanchez et al., 2011), EcoCity/ISMP-UC (Lee et al., 2011) e Living
PlanIT (PlanIT, 2012), estas informações historicamente armazenadas potencializarão os
resultados obtidos a partir de um algoritmo de contexto e mineração de dados.

3.4.10

Disponibilidade

Para permitir a captação de dados em tempo real e o fornecimento de informações
contextualizadas, a AS deve ser altamente disponível, em qualquer dia e horário.
Na literatura existem diversas iniciativas que propõem mecanismos para garantir
a disponibilidade da AS. Dentra elas, a mais discutida e utilizada é relacionada à
Cloud Computing. Desta forma, caso a infraestrutura de cloud computing seja utilizada,
mecanismos de controle de fluxo, colisão e redundância devem ser inerentes à solução.
Nas AS’s SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñoz et al.,
2011) e Nam’2011 (Nam and Pardo, 2011), estas situações são tratadas utilizando diversos
mecanismos de modularidade em relação a cloud.

3.4.11

Sensoriamento e Processamento Distribuído

Para que sejam propostas soluções para o aumento da eficácia em serviços urbanos
é necessário que se façam aferições das características qualitativas ou quantitativas
que permeiam esses serviços, bem como do resultado que produzem. É através de
sensoriamento que se obtêm a visão computacional do ambiente urbano; quanto maior o
número de sensores e mais disperso eles estiverem, maior será o escopo abrangido pela
AS.
A heterogeneidade dos sensores utilizados influencia na riqueza de detalhes e na
quantidade de dados que podem ser extraídos de cada cenário monitorado, sendo possível
obter resultados mais precisos. Por exemplo, reports de trânsito em determinada via
podem ser melhor analisados se complementados com imagens obtidas através de câmeras
instaladas nas redondezas.
Em situações que exigem que medidas preventivas ou corretivas sejam tomadas
instantaneamente exige-se processamento em tempo real, com tempo de resposta rápido
o suficiente para fornecer embasamento para ações que devem ser executadas assim
que determinada situação é identificada. Considerando quantidades massivas de dados
coletados, o suporte à esse tipo de contexto sugere a necessidade de processamento
distribuído, explorando a capacidade da infraestrutura existente.
Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerar

37

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

informações e conhecimento, permite execução de seus serviços de forma otimizada e
um gerenciamento urbano eficiente.
As AS’s que visam atender esse requisito são USN (Hernández-Muñoz et al., 2011),
SOFIA (Filipponi et al., 2010), Andreini’2011 (Andreini et al., 2011) e EcoCity/ ISMPUC (Lee et al., 2011).

3.4.12

Flexibilidade/Extensibilidade

Este requisito corresponde à capacidade da AS adaptar-se à mudanças e extensões. Além
da inserção de novos serviços, a AS deve ser capaz de adaptar-se à novos requisitos
inerentes ao contexto de implementação. Por exemplo, a AS deve ser independente de
padrões específicos de hardware.
Apesar da evidente relevância deste requisito, apenas três AS’s exploram este requisito:
Klein’2008 (Klein and Kaefer, 2008), MB2 Blackstock et al. (2010) e EcoCity/ISMP-UC
(Lee et al., 2011).

3.5

Sumário dos Requisitos para Cidades Inteligentes

A Tabela 3.4 ilustra um resumo dos requisitos que foram implementados nas AS’s
abordadas nesse Capítulo. Nesta tabela, a coluna # representa a quantidade de abordagens
encontradas que visam atender ao determinado requisito.
Ao analisar essas informações, pode-se perceber que nenhuma dessas AS’s implementam minimamente todos os requisitos levantados.
Isto deve-se ao fato de que as AS’s geralmente são projetadas para propósitos específicos e cada uma propõe uma solução focada especificamente no problema que pretende
resolver.
Além disso, percebe-se que os requisitos de Interoperabilidade de Objetos e Monitoramento em Tempo Real são os mais abordados pelas AS’s. Esta observação confirma
a importância em monitorar constantemente todos os aspectos que envolvem a cidade,
processar e disponibilizar os dados coletados rapidamente, a fim de fornecer uma visão
de estado do ambiente urbano mais precisa e atualizada para dar suporte às tomadas de
decisão em tempo real.
A AS descrita em (PlanIT, 2012) atende o maior número de requisitos considerados
essenciais no contexto desse trabalho. A abordagem de estruturação da AS, cujas camadas
apresentam os mesmos princípios de abstração encontrados em sistemas operacionais,
garante as mesmas vantagens aos mesmos atribuídas - como abstração e gerenciamento
38

3.6. DISCUSSÃO DO CAPÍTULO

de dispositivos físicos - que aliada à conectividade expande a abrangência de atuação
dentro do ambiente urbano, criando um ambiente pervasivo favorável a uma gestão urbana
efetiva.
Tabela 3.4 Mapeamento requisitos-arquiteturas
Requisito
Interoperabilidade de objetos
Monitoramento em tempo
real
Sustentabilidade
Aspectos sociais
Ubiquidade/Mobilidade
Privacidade e Segurança dos
dados
Geolocalização dos Sensores
Composição de Dados Urbanos
Histórico de dados
Disponibilidade
Sensoriamento e Processamento Distribuído
Flexibilidade/Extensibilidade

3.6

Abordagens
SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygiaris’2012, Wu’2011 e S3 OiA
Al-Hader’2009, SOFIA, SmartSantander, USN, Asimakopoulou’2011, Attwood’2011 e Living PlanIT
Klein’2008, EcoCity/ISMP-UC, SmartSantander, Masdar
City e Zygiaris’2012
Klein’2008, IMS e Asimakopoulou’2011
SmartSantander, USN, MB2 e Zygiaris’2012
SmartSantander, Living PlanIT e Fazio’2012

#
7

IMS, USN e S3 OiA
Nam’2011, CPAF, IMS, Anthopoulos’2010, Fazio’2012 e
Living PlanIT
MB2, SmartSantander, EcoCity/ISMP-UC e Living PlanIT
SmartSantander, USN e Nam’2011
USN, SOFIA, Andreini’2011 e EcoCity/ISMP-UC

3
6

Klein’2008, MB2 e EcoCity/ISMP-UC

2

7
5
3
4
3

4
3
4

Discussão do Capítulo

Neste Capítulo foram apresentadas 20 abordagens, em diferentes estágios de validação,
oriundas de dois tipos de revisão: Revisão Sistemática e ad hoc. A partir da revisão
exploratória foram encontrados trabalhos com investimentos da iniciativa privada e que
já se encontram em estágio de prototipação.
Ao término desse Capítulo, pode-se perceber que não há a necessidade da criação de
um novo padrão arquitetural ou adaptação de um padrão já existente para o contexto de CI
e IoT. Ainda em relação aos padrões arquiteturais, nota-se que o modelo de arquiteturas
em camadas é o mais utilizado, pois permitem o escalonamento de uma AS. Outro padrão
bastante empregado pelas AS’s foi o publisher-subscriber, devido, principalmente, as
vantagens em utilizá-lo para modelar o ambiente real.
Além disso, pode-se perceber que algumas AS’s foram propostas para finalidades
específicas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem mecanismos interessantes de tratamento de eventos em tempo real que devem ser considerados

39

CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES

no desenvolvimento de qualquer AS para CI.
Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há um
consenso amplamente aceito na literatura sobre quais os requisitos que uma AS deve
atender para ser considerada efetiva, independente da forma como foi implementada. A
partir das abordagens estudadas, pode-se estabelecer um conjunto de requisitos essenciais
ao analisar os principais objetivos das abordagens previamente descritas. Esses requisitos
constituem a base para qualquer AS para CI, pois abrangem os princípios definidos para
uma CI.
Ao analisar esse conjunto de requisitos, nota-se que nenhuma AS atendeu todos os
requisitos. Geralmente, as AS’s são propostas com propósitos específicos e ignoram
alguns requisitos essenciais.
Dessa forma, ao propor uma nova AS para CI é de suma importância que ela atenda a
maior quantidade desses requisitos, para que uma cidade possa ser de fato considerada
inteligente. Esses requisitos servirão como pilares para a elaboração da AS para CI que
combine as tecnologias de IoT que será descrita nos próximos Capítulos.

3.7

Considerações Finais do Capítulo

Este Capítulo apresentou algumas abordagens arquiteturais encontradas na litetura. Para
tal, dois métodos de revisão da literatura foram utilizados: Revisão Sistemática e ad-hoc.
A Seção 3.1 apresentou a metodologia utilizada durante o processo de revisão sistemática. Posteriormente, os resultados foram apresentados em ordem cronológica.
Por sua vez, a Seção 3.2 apresentou a revisão ad-hoc e os respectivos resultados,
ressaltando, principalmente, o estágio de validação das abordagens encontradas.
Na Seção 3.3 foi realizado uma consolidação das características mais relevantes de
cada abordagem. Por fim, a Seção 3.4 apresentou um conjunto de requisitos, extraídos a
partir da análise das abordagens, que uma AS para CI deve atender.
Estes requisitos foram utilizados para guiar o desenvolvimento da proposta deste
trabalho. Logo, o próximo Capítulo apresenta esta proposta, utilizando um método de
descrição arquitetural amplamente discutido na literatura (Kruchten, 1995).

40

4
Uma Arquitetura de Software para
Cidades Inteligentes baseada na Internet
das Coisas
Os verdadeiros analfabetos são os que aprenderam a ler e não lêem.
—MARIO QUINTANA, 2006 (Caderno H)

Baseado nas demandas de uma AS para Cidade Inteligente (CI) que possibilite a
integração de tecnologias IoT e no conjunto de requisitos que foi definido no Capítulo
anterior, este Capítulo visa propor uma AS para CI que permita a combinação com
tecnologias IoT. O foco da solução proposta consiste em atender um sub-conjunto destes
requisitos, bem como prover mecanismos, do ponto de vista de infraestrutura, para que
novos requisitos possam ser futuramente incluídos, de acordo com o contexto de cada
cidade.
Dessa forma, a Seção 4.1 apresenta este sub-conjunto de requisitos que serão abordados nesta proposta. Já para descrever a proposta detalhadamente é utilizado um método
de descrição de AS’s baseado em visões, conhecido como “4+1”, na Seção 4.2.
Em seguida, cada visão abordará aspectos específicos da AS. A Seção 4.3 apresentará
a Visão Lógica, a partir de um ponto de vista funcional, relacionando os principais
módulos e as operações realizadas com mais frequência. Por sua vez, a Seção 4.4
apresentará a Visão de Execução, com o mapeamento dos componentes lógicos em
processos e threads. A Seção 4.5 apresentará a Visão de Implementação, seguido da
Seção 4.6 explicitando a Visão Física. Além das visões deste método, duas outras
visões definidas pelo SEI (Clements, 2003) foram utilizadas para facilitar a compreensão

41

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

pelos stakeholders: Visão Componente Conector (Seção 4.7) e Visão de Dependências
(Seção 4.8).
Por fim, a Seção 4.9 apresentará alguns dos principais cenários de utilização desta
AS, do ponto de vista de orgãos governamentais e não-governamentais, cidadãos e
desenvolvedores.
Finalmente, a Seção 4.10 consolida as principais características da AS proposta
discutidas neste Capítulo e a Seção 4.11 finaliza o Capítulo.

4.1

Requisitos abordados

A partir da descrição dos requisitos realizada no Capítulo anterior, um sub-conjunto de
requisitos foi selecionado para ser abordado nesta proposta de AS. A Tabela 4.1 exibe
todos os requisitos e indica quais destes foram abordados nesta proposta, ordenados
pela quantidade de abordagens encontradas que visam atender o determinado requisito,
conforme ilustrado na coluna #.
Tabela 4.1 Requisitos abordados
Requisito
Interoperabilidade de objetos
Monitoramento em tempo real
Composição de Dados urbanos
Sustentabilidade
Histórico de dados
Ubiquidade/Mobilidade
Sensoriamento e Processamento Distribuído
Geolocalização dos Sensores
Privacidade e Segurança dos dados
Aspectos sociais
Disponibilidade
Flexibilidade/Extensibilidade

Abordado
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Não
Não
Não
Sim

#
7
7
6
5
4
4
4
3
3
3
3
2

Ao analisar a Tabela 4.1, percebe-se que do total de 12, apenas 4 não foram incluídos
nesta proposta e 8 foram incluídos. Para realizar essa priorização, dois fatores foram
ponderados: i) a importância/relevância do requisito, inferida a partir da quantidade de
abordagens na literatura que visam satisfazer esse requisito, conforme pode ser observado
na coluna “#”; e ii) este conjunto de requisitos foi incluído nesta proposta são os requisitos
mínimos que toda AS de software para CI deve atender.
Os demais requisitos que, mesmo considerados importantes/relevantes, não foram
abordados nesta proposta, dificilmente podem ser abordados nesta proposta no estágio
atual. A saber:
42

4.2. METODOLOGIA “4+1”

• Sustentabilidade: A proposta atual não possui nenhuma parceria com instituições
governamentais. Logo, nas 5 abordagens na qual esta requisito foi encontrado,
todas possuíam uma parceria com as prefeituras locais, que criavam campanhas
para incentivar o consumo consciente dos cidadãos.
• Privacidade e Segurança dos dados: De fato, esta necessidade foi identificada no
começo desta pesquisa, porém um outro trabalho de mestrado está sendo desenvolvido com este escopo. Este trabalho de privacidade será acoplado à esta proposta
assim que finalizado. Para isso, as definições de interfaces e padrões de mensagens
estão sendo definidas em conjunto. O escopo deste trabalho de privacidade é criar
um mecanismo em que, a partir das interações anteriores, os cidadãos possam
“negociar” o quão seus dados estarão disponíveis para um determinado provedor de
serviço urbano.
• Aspectos sociais: Da mesma forma que o requisito de Sustenabilidade, para que
a AS atenda ao requisito de Aspectos Sociais é necessário o estabelecimento de
parcerias com as instituições governamentais para de fato incluir os cidadãos como
parte do sistema de uma CI.
• Disponibilidade: O requisito de Disponibilidade está relacionado à infraestrutura
na qual esta proposta estará sendo executada.

4.2

Metodologia “4+1”

A Arquitetura de Software (AS) tem desempenhado um papel fundamental no desenvolvimento de sistemas de software. Ela oferece um maior entendimento da aplicação por
dividi-la em um conjunto de componentes que interagem entre si para realizar parte de
uma ou várias funcionalidades do sistema (Garlan and Shaw, 1994).
Porém, diversos autores relatam a falta de eficiência em documentar essas AS’s para
que sejam legíveis para os mais variados stakeholders (Garlan and Shaw, 1994; Clements,
2003). Visando atender essa ineficiência, em Kruchten (1995) é proposto um método de
descrição de AS’s baseado em visões chamado “4+1”. Para facilitar a compreensão pelos
stakeholders, duas outras visões definidas pelo SEI (Clements, 2003) foram utilizadas:
Visão Componente Conector e Visão de Dependências. A integração dessas visões é
ilustrada na Figura 4.1.
Este uso de múltiplas visões permite abordar separadamente as preocupações de vários
stakeholders da AS: usuários finais, desenvolvedores, engenheiros de sistemas, gerentes

43

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

Visão Lógica

Visão
Componente
Conector

Visão Execução

Cenários

Visão Implementação

Visão
Dependência

Visão Física

Figura 4.1 Integração das visões do modelo “4+1” com as visões definidas pelo SEI

de projetos, entre outros; e permite avaliar separadamente os requisitos funcionais e não
funcionais. Estas visões abordam aspectos de relevância arquiteturais sob diferentes
perspectivas:
• A visão lógica aborda os elementos significativos do projeto para a AS adotada e a
relação entre eles. Entre os principais elementos estão os módulos, os componentes,
os pacotes e as classes principais de aplicação;
• A visão de execução relata os aspectos de concorrência e sincronização do sistema,
mapeando os elementos da visão lógica de processos, threads e tarefas de execução;
• A visão de implementação centra-se em aspectos relacionados com a organização
do código-fonte do sistema, padrões de AS utilizada e as orientações e as normas
para o desenvolvimento do sistema;
• A visão física demonstra as configurações de hardware e o mapeamento dos
elementos de software para os elementos de hardware no ambiente do sistema;
• A visão componente conector se refere ao comportamento dos componentes em
tempo de execução e seus conectores, que são responsáveis pela comunicação entre
estes;
• A visão dependências ilustra as dependências existentes entre os módulos da AS ;
• Os cenários mostram um subconjunto dos casos de uso significativo da AS.
44

4.3. VISÃO LÓGICA

No contexto de CI, diferentes stakeholders são envolvidos no processo de criação
de uma solução eficiente, por exemplo, prefeito, secretarias públicas, desenvolvedores
e cidadãos. Logo, o método “4+1” foi escolhido e duas visões foram adicionadas para
descrever esta proposta arquitetural justamente para contribuir no entendimento por estes
diferentes stakeholders.

4.3

Visão Lógica

Esta Seção demonstra a organização da AS a partir de um ponto de vista funcional. Os
principais elementos, como módulos e componentes principais são especificados. A
interface entre estes elementos também é especificada. A Figura 4.2 ilustra a arquitetura
do ponto de vista lógico.
Módulo de
Acesso e
Comunicação
(MAC)

REST

Módulo de
Persistência de
Dados (MPD)

Interface: Protocolos de troca de mensagens

DHT-BD
Registro de recursos

Interface: Banco de Dados

Driver
BD3

BD3

Driver
BD2

BD2

Driver
BD1

BD1

Configuração de recursos

Módulo de
Gerenciamento
de Recursos
(MGR)

C

DHT Canal
de
dados

C

...

C

C

...

C

C

...

....
Canal 2

Canal 1

...

P

P

...

P

P

...

Canal 3

P

P

Módulo de
Gerenciamento
e Distribuição
de Dados
(MGDD)

...

Figura 4.2 Visão lógica da Arquitetura de Software (AS) proposta

As subseções seguintes explicitarão cada módulo, ressaltando sua responsabilidade e
os requisitos funcionais atendidos.

4.3.1

Módulo de Acesso e Comunicação (MAC)

O Módulo de Acesso e Comunicação (MAC) representa o ponto de entrada para as
aplicações e serviços externos. O MAC provê os mecanismos necessários para o acesso e

45

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

a comunicação com a AS, a partir da interface REST (Representational state transfer).
De acordo com Blackstock et al. (2010) e Hernández-Muñoz et al. (2011), utilizar
uma interface padronizada, como REST, é uma das técnicas empregadas para tornar a
AS compatível com as tecnologias móveis, como totens, smartphones e tablets. Esta
decisão arquitetural permite que a AS torna-se compatível com o requisito de ubiquidade/mobilidade.
Além disso, de acordo com Blackstock et al. (2010) e Filipponi et al. (2010), a
principal estratégia para que uma AS contemple a interoperabilidade de objetos é permitir
a comunicação com dispositivos e sistemas através de diferentes protocolos de troca de
mensagens. Para tal, o MAC contém uma interface padronizada que permite a inserção
de novos adaptadores que implementam os diferentes protocolos de troca de mensagem
sob demanda.
O funcionamento do MAC consiste em receber cada requisição dos diferentes recursos
e encaminhá-las para os demais módulos. Para isso, o MAC oferece todos os operações
para interagir com a AS, por exemplo, operações responsáveis pelo Registro de Recursos,
como será detalhado na seção a seguir. De acordo com a operação do método, este delega
ação para o respectivo módulo.

4.3.2

Módulo de Gerenciamento de Recursos (MGR)

Do ponto de vista de uma AS para CI, um recurso pode ser considerado sensores espalhados pela cidade, um cidadão portando um dispositivo móvel ou até mesmo um sistema
externo (como um perfil em qualquer rede social), dentre outros tipos de fornecedores de
dados (Sanchez et al., 2011; Klein and Kaefer, 2008; Asimakopoulou and Bessis, 2011).
Desta forma, o Módulo de Gerenciamento de Recursos (MGR) visa gerenciar as
informações relativas a estes fornecedores de dados. Dentre essas informações, a geolocalização dos sensores deve ser mantida a fim de aumentar a eficiência e a confiabilidade do
dado fornecido (Hernández-Muñoz et al., 2011; Shao, 2011; Vega-Barbas et al., 2012).
Para tal, o MGR contém dois sub-módulos: Registro e Configuração de recursos. O
Registro de Recursos contém operações, acessíveis a partir do MAC, que permitem o
registro de um recurso. Além disso, a partir da existênca deste recurso, este sub-módulo
disponibiliza todas as informações de um recurso por toda a AS. Já o sub-módulo de
Configuração de Recursos possui operações para gerenciar as configurações do recurso,
por exemplo, a frequência de tempo em que os dados são disponibilizados.
46

4.3. VISÃO LÓGICA

4.3.3

Módulo de Gerenciamento e Distribuição de Dados (MGDD)

O Módulo de Gerenciamento e Distribuição de Dados (MGDD) possui a responsabilidade
de disseminar os dados por toda AS. Logo, pode ser considerado o core da AS, por (i)
atender a maior quantidade de requisitos; (ii) implementar os principais mecanismos
que diferenciam esta AS das demais abordagens semelhantes e (iii) implementar toda a
infraestrutura de distribuição de dados.
Um dos padrões mais utilizados no design de AS é o publisher-subscriber, na qual a
principal vantagem é o desacoplamento entre os produtos e fornecedores de dados (Buschmann et al., 1996). O MGDD contém uma implementação deste padrão, representados
na Figura 4.2 pelas caixas com a letra ’P’ e ’C’, respectivamente.
No MGDD, os fornecedores (publisher) fornecem dados em um canal específico de
dados; por sua vez, os consumidores (subscriber) devem ser inscreverem nestes canais de
dados para que assim que um novo dado seja disponibilizado, este possa ser recebido e
processado. Este comportamento é classificado como uma das técnicas para modelar-se
eventos do mundo real em AS, pois permite disparar eventos simultâneamente, na qual
pode-se ativar um ou mais eventos possivelmente encadeados (Filipponi et al., 2010;
Hernández-Muñoz et al., 2011; Sanchez et al., 2011; Wu et al., 2011; Fazio et al., 2012).
A implementação do padrão publisher-subscriber no MGDD também possibilita a
adequação à um dos mais importantes requisitos de uma AS para CI: a Composição de
Dados Urbanos (PlanIT, 2012; Nam and Pardo, 2011; Mostashari et al., 2011). Para
tal, um mesmo componente consumidor (subscriber) pode se inscrever em dois ou
mais canais, obter estes diferentes dados e compô-los de alguma forma. A Seção 4.3.6
exemplificará esse cenário.
Além disso, o MGDD permite que novos canais de dados sejam criados sob demanda.
Esta peculiaridade proporciona certa flexibilidade para a AS, visto que não há restrições
do limite para a criação de canais nas quais dados possam ser trafegados.
Assim que um novo canal de dados é criado, este deve registrar-se na “Distributed
Hash Table (DHT) Canais de Dados”. Esta DHT permite que os canais de dados sejam
acessíveis para todos os consumidores, através de consultas pelo tipo de dado que é
disponibilizado. Da mesma forma, DHT é utilizada para os fornecedores obterem a
referências para os canais mais apropriados para fornecerem seus dados. A Seção 4.3.6
exemplificará este cenário com um caso prático.
Além disso, a utilização de uma DHT é importante para prover escalabilidade e
processamento distribuído. A escalabilidade é obtida a partir da criação de novos canais
de dados, a medida que o sistema se expande. Da mesma forma, como não há limite de

47

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

consumidores e fornecedores no mesmo canal de dado, a DHT permite a escalabilidade
em termos de recursos de dados.
Já em relação ao processamento distribuído, a DHT permite que os canais de dados estejam distribuídos em diferentes hosts, desde previamente registrado no MGR.
Logo, assim que uma consulta por um respectivo canal de dado é realizado na DHT,
esta se encarregará de encontrar as informações deste canal, a partir das informações
do MGR. Desta forma, uma camada de abstração é criada entre o canal e os consumidores e fornecedores, a fim de proporcionar maior desacoplamento, extensibilidade e
flexibilidade.

4.3.4

Módulo de Persistência de Dados (MPD)

O Módulo de Persistência de Dados (MPD) possui a responsabilidade de armazenar os
dados oriundos dos diferentes níveis da AS. Estes dados, em todos os níveis da AS, são
importantes para a predição de acontecimentos futuros, a partir do histórico de dados.
Para tal, o módulo deve realizar consultas e inserções rápidas e fornecer uma interface
transparente para quem a utiliza sobre o respectivo banco de dados. Esta interface é
importante para permitir o desacoplamento entre o respectivo banco de dados com os
componentes que o utilizam.
Antes de algum recurso realizar uma consulta em um banco de dados específico,
este pode ser encontrado a partir da “DHT Banco de Dados”. Por sua vez, essa DHT
tem a responsabilidade de gerenciar todos os drivers de banco de dados disponíveis no
momento da transação, além de permitir que os bancos de dados estejam distribuídos em
diferentes hosts.
Estudos futuros devem ser realizados para avaliar o banco de dados mais adequado de
acordo com o tipo e formato do dado.

4.3.5

Mapeamento Requisito x Módulo

A Tabela 4.2 ilustra o módulo no qual cada requisito é contemplado. Como nota-se,
geralmente um requisito é implementado a partir da combinação de dois ou mais módulos
da AS.

4.3.6

Operações

Esta Seção apresenta as principais operações a serem realizadas na AS, a partir de
Diagramas de Sequência.
48

4.3. VISÃO LÓGICA

Tabela 4.2 Mapeamento Requisitos por Módulo
Requisito
Interoperabilidade de objetos
Monitoramento em tempo real
Composição de Dados urbanos
Histórico de dados
Ubiquidade/Mobilidade
Sensoriamento e Processamento Distribuído
Geolocalização dos Sensores
Flexibilidade/Extensibilidade

MAC
X
X
X

MGR
X
X
X

X
X
X

MGDD
X
X
X
X
X
X
X

MPD

X
X
X
X

Consumidor: Recurso receber dados
A Figura 4.3 ilustra uma abstração de um diagrama de fluxo referente as atividades a
serem realizadas para que um recurso obtenha um dado. Este diagrama abstrai algumas peculiaridades, como a implementação da interface padronizada exigida para o
funcionamento correto do padrão publisher-subscriber.
Inicialmente, este recurso deve solicitar a referência do canal que contém o dado em
questão, a partir do mapeamento existente na DHT. Caso a DHT encontre este canal, a
referência é retornada. De posse da referência, o recurso pode se inscrever no respectivo
canal. Assim que um novo dado for fornecido por qualquer recurso fornecedor, o dado
será imediatamente sentregue aos recursos que se inscreveram nesse canal.

MGDD

Recurso

DHT Canais
de dados

X’

Alguém fornece o dado X?
Referência ao Canal X’

Subscriber

Novo dado
fornecido?
Envio de dados

Figura 4.3 Abstração da operação de um recurso receber dados

49

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

Produtor: Fornecer dado
Por sua vez, o mecanismo para fornecer um dado é bem parecido ao recebimento de um
dado. Existem dois cenários específicos para o fornecimento de dado: (i) quando já existe
um canal no qual o dado é disponibilizado, ou seja, existe pelo menos mais um recurso
fornecedor que já fornece esse dado; ou (ii) quando é o primeiro recurso fornecedor a
fornecer o dado.
Em ambos os casos, primeiramente, o recurso deve verificar na DHT se já existe um
canal no qual este dado é fornecido. Caso exista, a DHT retornará a referência desse
canal que corresponde ao primeiro cenário, como ilustrado na Figura 4.4.
Recurso

MGDD
DHT Canais
de dados

X’

Alguém fornece o dado X?
Referência ao Canal X’

Envio de dados

Figura 4.4 Abstração da operação de um recurso fornecer dado

Caso contrário, a DHT retornará uma resposta de que o canal requisitado não existe,
como ilustrado na Figura 4.5. A partir desta resposta, o recurso fornecedor deve solicitar
uma nova referência de canal para fornecer este tipo de dado, fornecendo as informações
necessárias. Feito isso, a DHT retornará a referência ao novo canal.
De posse da referência ao canal que será fornecido o dado, em ambos os casos, basta
o recurso fornecedor enviar os respectivos dados assim que eles estiverem disponíveis.
Compor um dado urbano
A operação de compor um dado urbano pode ser considerada uma combinação entre as
operações de Receber e Fornecer um dado. Como ilustrado na Figura 4.6, esta operação
é dividida em 3 fases: Setup, Consumo de Dados e Criação de dados.
A primeira fase, Setup, corresponde aos passos necessários para iniciar uma composição de dados urbanos. Inicialmente, o recurso deve consultar se o canal com o dado
50

4.3. VISÃO LÓGICA

Recurso

MGDD
DHT Canais
de dados

X’

Alguém fornece o dado X?
Canal não existente

Quero novo canal para fornecer dado X
Referência ao Canal X’

Envio de dados

Figura 4.5 Abstração da operação de um recurso fornecer um novo tipo de dado

que será combinado já existe. Caso não exista, o recurso deve solicitar a disponibilização
deste canal e a devida referência deve ser retornada.
De posse da referência do canal na qual será disponibilizada o dado combinado,
inicia-se a segunda fase, conhecida como Consumo de Dados. Nesta fase, o recurso deve
consultar a DHT para adquirir a referência de todos os canais que já fornecem os dados
que serão utilizados para a combinação. Após obter a referência de todos os canais, o
recurso deve se inscrever para receber os dados oriundos destes canais.
Não há nenhuma restrição na quantidade de dados que podem ser utilizados para
combinação, ou seja, o recurso pode se inscrever em vários canais para utilizar estes
dados na combinação.
Feito isso, inicia-se a terceira fase, Criação de Dados. Esta fase corresponde ao
mecanismo de receber os dados dos vários canais inscritos, combiná-los de alguma forma
utilizando algum tipo de regra de negócio e disponibilizá-lo no canal obtido na fase de
Setup.
Vale ressaltar que a fase de Criação de Dados é a única que continua sendo executada
em background por tempo indeterminado. Além disso, ressalta-se que o momento em
que a nova informação combinada é disponibilizada no canal resultante depende da regra
de negócio implementada. Por exemplo, um recurso de combinação de dados que gera
um relatório das unidades de emergência por regiões de uma cidade pode consumir os

51

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS
MDMD

Recurso

DHT Canal
de Dado

X’

Y’

XY’

Alguém fornece do dado XY?
Canal não existente

Setup

Quero novo canal para fornecer o dado XY
Referência ao novo Canal XY’

Alguém provê o dado X?
Referência do Canal X’
Alguém provê o dado Y?

Consumo de
Dados

Referência do Canal Y

.
.
.
Subscribe
Subscribe

.
.
.

Dado X
Dado Y

Criação de
Dados

Combina X
e Y
Informação Combinada XY

Figura 4.6 Operação de composição de dados urbanos

dados de cada unidade e gerar esse relatório uma vez por dia.

4.4

Visão de Execução

Esta Seção apresenta o mapeamento dos componentes lógicos da AS em processos e
threads em tempo de execução, resumidos na Tabela 4.3.

4.4.1

Módulo de Acesso e Comunicação (MAC)

O MAC possui um processo principal responsável por receber as requisições oriundas
dos mais variados tipos de clientes. Além disto, este processo é responsável por conter a
interface que sera implementada por cada adaptador.
Por sua vez, cada adaptador pode ser executado em um outro processo independente,
visto que o único recurso compartilhado é a interface do processo principal. Já em
52

4.4. VISÃO DE EXECUÇÃO

Tabela 4.3 Resumo da quantidade de processos e threads em tempo de execução

Módulo
MAC
MGR
MGDD

MPD

Processos
1 por adaptador + 1 principal
1 por sub-módulo + 1 principal
4 processos principais

Threads
1 por requisição
1 por operação

1 por consumidor de dados +
1 por fornecedor de dados + 1
por canal de dado
1 principal + 1 DHT + 1 por 0
Banco de Dados

relação as requisições, uma thread é criada para cada requisição, já que as requisições
são gerenciadas de forma independente.

4.4.2

Módulo de Gerenciamento de Recursos (MGR)

O MGR possui um processo principal que é responsável por conter todas as interfaces das
operações visíveis aos demais módulos. Além disto, cada cada sub-módulo é executado
em processo separado para que técnicas de cache possam ser futuramente desenvolvidas
de forma eficiente.
As operações que serão realizadas nos sub-módulos devem ser eficientes a ponto de
não comprometer a computação do recurso requisitante. Logo, para cada operação, uma
thread é iniciada para tratar está requisição. A sincronização das informações será feita
utilizando técnicas de sincronização por transação.

4.4.3

Módulo de Gerenciamento e Distribuição de Dados (MGDD)

O MGDD possui quatro processos principais: (i) o primeiro corresponde ao processo
responsável pela implementação dos canais de dados; na mesma linha, um processo é necessário para controlar os (ii) consumidores e (iii) outro para os fornecedores; finalmente,
(iv) o último processo é responsável por gerenciar a DHT.
Como cada recurso, seja este consumidor ou fornecedor de dado, é independente dos
demais e contém as suas próprias dependências para realizar a computação, uma thread é
criada para cada recurso. Da mesma forma, uma thread é criada para cada canal de dado.
Esta thread pode ser executada em outro host.

53

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

4.4.4

Módulo de Persistência de Dados (MPD)

Por sua vez, o MPD constitui-se de dois processos: gerenciador de instâncias de banco
de dados e a DHT. Este gerenciador é responsável por obter os dados dos diferentes
módulos e armazenar no respectivo banco de dados para a predição de eventos futuros.
Da mesma forma que o MGDD, cada instância de banco de dados constitui uma novo
processo. Estes novos processos também podem ser executadas em um host diferente.

4.5

Visão de Implementação

Esta Seção descreve as estratégias utilizadas para a implementação de referência do
sistema de acordo com a AS estabelecida. Esta implementação está disponível em
domínio público1 .
A AS proposta visa atender alguns requisitos considerados como não funcionais,
porém não menos importante, como escalabilidade e flexibilidade. Logo, a infraestrutura
a ser utilizada para implementação deve ser robusta para atender os diversos sistemas
que a utilizarão, além da maciça quantidade de dados. Além disto, como a AS proposta
contém vários componentes independentes, a infraestrutura deve proporcionar o deploy de
componentes/adaptadores sem que os demais sejam afetados, conhecido como hot-deploy
(Touseau et al., 2008; Martín et al., 2009).
Neste contexto, a plataforma OSGi consolida-se como uma das mais indicadas para
aplicações na qual hot-deploy é de suma importância (Touseau et al., 2008; Martín et al.,
2009). Conforme definido por Gama and Donsez (2010) :
A plataforma de serviço OSGi2 é um middleware universal para desenvolvimento de
aplicações modulares, usando princípios de SOA para implementar o desacoplamento
entre componentes. A tecnologia OSGi aproveita a modularização na plataforma Java,
que permite instalar, atualizar, para iniciar, parar e desinstalar componentes em tempo
de execução sem a necessidade de reinicialização do sistema. A plataforma OSGi é
composta por um conjunto de especificações, conduzido por um consórcio de empresas.
As especificações são realizadas por diferentes implementações como o Apache Felix3 ,
Equinox4 e Knopflerfish5 (Gama and Donsez, 2010).
1 https://github.com/gustahrodrigues/Synaptic
2 http://www.osgi.org
3 http://felix.apache.org
4 http://www.eclipse.org/equinox
5 http://www.knopflerfish.org

54

4.5. VISÃO DE IMPLEMENTAÇÃO

No contexto deste trabalho, a plataforma OSGi foi utilizada para proporcionar maior
modularidade, escalabilidade e facilitar a manutenção de componentes. Dentre as implementações de OSGi, foi escolhida o Equinox, pela familiariade com o arcabouço Eclipse6 .
Cada componente da AS foi implementada utilizando um bundle, que representa um
conjunto de classes Java, geralmente empacotados como “jar”. A Figura 4.7 ilustra a
organização dos bundles que representam a implementação dos respectivos componentes,
do ponto de vista de implementação sobre o Equinox.

RestLet

GSON

Rest

Interface
Mensagem

C
Registro
de
Recursos

Configura
-ção de
Recursos

F

Event
Admin

DHT
Canal de
Dados

DHT
Banco de
Dados

Mongo
DB

EQUINOX
MAC

MGR

MGDD

MPD

Figura 4.7 Visão de Implementação

Ao análisar a imagem 4.7, nota-se que o bundle responsável pela MAC contém um
adaptador com a implementação inicial de JSON7 utilizando a bibilioteca fornecida pelo
Google Inc. conhecida como GSON8 . Este bundle comunica-se ativamente com o bundle
responsável pela comunicação via REST. Por sua vez, o módulo REST implementa
utilizando o framework Restlet9 .
Em relação ao módulo MGR, percebe-se que ele se resume em dois bundles: Registro
6 https://www.eclipse.org/
7 http://www.json.org/
8 https://code.google.com/p/google-gson/
9 http://restlet.org/

55

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

de Recursos e Configuração de Recursos. Estes dois bunddles representam os processo
descritos previamente.
Já no módulo MGDD, a implementação do padrão publisher-subscriber foi realizada
utilizando o serviço oferecido pelo próprio OSGi Equinox denominado EventAdmin.
O EventAdmin corresponde à um serviço que contém a implementação de canais de
distribuição de dados, na qual consumidores de dados podem se inscrever nos respectivos
tópicos de interesse e os fornecedores de dados podem fornecer os dados nestes canais.
Na Figura 4.7 as caixas “C” e “P” representam os consumidores e fornecedores de
dados. Como pode ser observado, a DHT Canal de Dados comunica-se ativamente com o
EventAdmin para gerenciar os canais de dados.
Por fim, a ilustração correspondente ao módulo MPD exemplifica a utilização de um
banco de dados específico, conhecido como MongoDB10 . Similarmente à DHT Canal
de Dados, a DHT Banco de Dados utiliza as informações de cada bundle referente a um
banco de dados para gerenciá-lo e oferecê-lo aos demais componentes da AS. Caso um
novo banco de dados seja inserido, basta plugar o respectivo bundle sobre a plataforma
OSGi Equinox e registrá-lo na DHT de Banco de Dados.

4.6

Visão Física

Esta Seção visa descrever os requisitos físicos mínimos para utilização da AS proposta.
Por se tratar de um ambiente distribuído, com vários acessos exigindo o máximo de
escalabilidade, é de suma importância a utilização de um ambiente Cloud.
Para propósitos de testes e validações, foi utilizada uma infraestrutura mínima do
serviço Amazon AWS11 . A Tabela 4.4 resume as principais características de hardware e
software dessa infraestrutura.
Para a utilização em um ambiente real de produção é evidente que esta configuração
não é suficiente. Nesse contexto, deve-se analisar as soluções de Cloud oferecidas pelos
provedores para obter melhor desempenho da AS, como por exemplo, Amazon Dynamo
DB12 e Amazon Elastic Map Reduce13 .
10 http://www.mongodb.org/
11 http://aws.amazon.com/
12 http://aws.amazon.com/dynamodb/
13 http://aws.amazon.com/elasticmapreduce/

56

4.7. VISÃO COMPONENTE CONECTOR

Tabela 4.4 Requisitos físicos de utilização da arquitetura

Requisito

Configuração
Hardware

Plano Amazon AWS
Memória RAM

Amazon EC2 - Free Tier
613Mb

Software
Amazon Machine Image (AMI) amzn-ami-pv-2012.09.0.x86_64-ebs
Sistema Operacional
Linux Amazon (Red Hat)
Restlet
Versão 2.4.1
GSON
Versão 2.2.4
MongoDB
Versão 2.4.6
Servidor Web
Jetty 7

4.7

Visão Componente Conector

Esta seção se refere ao comportamento dos componentes em tempo de execução e seus
conectores, que são responsáveis pela comunicação entre estes. A Figura 4.8 ilustra o
diagrama de componente conector desta proposta.

Figura 4.8 Diagrama de Componente Conector

Como pode ser observado na Figura 4.8, os componentes principais são Recurso
e Dado. Apesar destes dois componentes fazerem parte logicamente do MGR, eles
são utilizados pelos demais módulos da AS. No próprio MGR, estes componentes são
utilizados pelos módulos de Configuração e Gerenciamento de Recurso. Os dados que
trafegam na AS são representados pelo componente Dado. Toda vez que um determinado

57

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

recurso fornecer ou consumir um dado, este deve usar o conector existente entre os
componentes Recurso e Dado.
No caso do MAC, o componente Recurso é utilizado pois representa a entidade que
fornece e recebe dados da arquitetura. Esta comunicação é realizada a partir do outro
componente REST.
O MGDD contém uma porta para cada canal de dado. Esta porta é uma abstração
para a comunicação realizada com os diversos Recursos consumidores ou fornecedores
de dados. Além disto, o MGDD contém um componente denominado DHT com as
responsabilidades já descritas na Seção Visão Lógica. Como pode ser observado, o
MGDD possui um conector para cada recurso associado à um canal.
Por sua vez, o MPDD possui conectores associados aos módulos MGR e MGDD
para que as informações trafegadas nestes dois módulos possam ser armazenadas para a
predição de eventos futuros. Além disto, uma porta é associada à cada instância de banco
de dados.

4.8

Visão de Dependências

Esta seção visa ilustrar as dependências existentes entre os módulos da AS. A Figura 4.9
ilustra o diagrama de dependências entre os módulos desta proposta.

Figura 4.9 Diagrama de Dependências

Como pode ser observado na Figura 4.8, apesar do MGDD ser o core da AS, o módulo
que é mais utilizado pelos demais é o MGR. Este fato deve-se ao fato dos componentes
Recurso e Dado estar logicamente declarados no MGR. Logo, o MGDD depende do MGR
para interagir com os recursos inscritos em cada canal, além de gerenciar os respectivos
dados.
Por sua vez, o MGR contém dependência apenas do MAC. Esta dependência deve-se
ao fato do MAC ser a porta de entrada e saída dos sistemas externos com a AS. Logo,
para que um recurso consiga receber de fato os dados é necessário utilizar os mecanismos
providos pelo MAC.
58

4.9. CENÁRIOS

Assim como no diagrama de Componentes Conectados, o MPDD possui dependência
com os módulos MGR e MGDD para que as informações trafegadas nestes dois módulos
possam ser armazenadas para a predição de eventos futuros.

4.9

Cenários

Esta Seção visa apresentar alguns dos principais cenários de utilização da AS proposta.

4.9.1

Desenvolvimento de aplicações móveis

Um desenvolvedor pode criar aplicações móveis que consumam informações das cidades
e mantenham seus usuários atualizados sobre os acontecimentos. Por exemplo, uma
aplicação que identifique os pontos de alagamento em uma avenida ou registre regiões
afetadas pela falta de energia.
Do ponto de vista da arquitetura proposta, esta proposta deveria ser implementada
da seguinte forma. Um recurso, correspondendo à aplicação, deve realizar todas as
interações com a arquitetura através da interface REST, disponível do MAC. O primeiro
passo é registrar à aplicação como um recurso no MGR. Para isto, a aplicação deve
invocar o respectivo método oferecido pelo MAC, provendo as devidas informações do
recurso.
Em seguida, este recurso deve consultar a “DHT Canais de Dados” para obter as
referências para todos os canais que oferecem as informações relevantes da respectiva
cidade. Após se inscrever nestes canais, assim que um novo dado é disponibilizado, a
aplicação deve recebê-los a partir de consultas REST. De posse destes dados, a aplicação
pode exibi-los da maneira mais adequada.

4.9.2

Emitir Alertas com Informações de Trânsito

As companhias de gerenciamento de trânsito das cidades podem utilizar esta arquitetura
para emitir informações de trânsito da cidade. Para isso, basta registrar cada sensor como
um recurso fornecedor de dado na arquitetura. Estes sensores podem ser as câmeras de
trânsito, informações de veículos em radares e quantidade de veículos nas cabines de
pedágio por minuto.
Além disso, será necessário registrar um recurso consumidor no MGR responsável
por se inscrever nos canais nas quais estão informações serão fornecidades. A partir disto,

59

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

este recurso deve interpretar estas informações e gerar os alertas de acordo com a situação
do trânsito.

4.9.3

Definição de Estratégia Efetiva de Investimento de Recursos

As secretarias das prefeituras podem definir estratégias para aplicação dos recursos
específicos para as reais demandas da cidade. Para isso, uma vez que os dados dos
problemas da cidade estejam trafegando pelos diferentes canais do MGDD, basta um
recurso, representando o sistema da secretaria se inscrever nestes canais.
A medida que um dado é disponibilizado, este recurso pode consolidar estas informações em forma de gráfico ou até mesmo notificar os respectivos responsáveis, além de
estimar o custo para resolver aquele problema.

4.9.4

Predição de Catastrófes em Áreas de Riscos

Um sistema pode ser desenvolvido para predizer catastrófes em áreas de riscos. Para
isto, este sistema deve se registrar no MGR como um recurso consumidor de dados. Em
seguida, este recurso pode solicitar ao MPD informações anteriores associadas à área,
por exemplo, informações da quantidade de chuva nos últimos verões.
De posse destas diferentes informações, o recurso pode implementar uma lógica que
permite inferir conhecimentos a partir destas informações, por exemplo, usando uma
técnica de Rede Neural. Estas informações contextualizadas devem ser fornecidades em
outro canal para que outros recursos possam utilizá-las para alguma outra finalidade.
Em seguida, um recurso consumidor de dado deve se inscrever neste canal que está
fornecendo essas informações contextualizadas e consolidá-las no sistema de predição de
catastrófes.

4.10

Discussão do Capítulo

O conjunto de cenários descrito constitui exemplos de utilização da AS. Por ser uma AS
para propósito genérico, esta pode ser facilmente adaptada para os contextos locais de
cada região. Pode-se imaginar diversos cenários de utilização, desde uma região litorânea
utilizar a AS para executar programas de balneabilidade até o controle de obesidade dos
idosos de uma região.
Além desta flexibilidade em relação ao propósito da AS, pode-se facilmente identificar
que esta proposta é flexível em termos de aplicabilidade. Por exemplo, inicialmente
60

4.11. CONSIDERAÇÕES FINAIS DO CAPÍTULO

concebida para ser aplicada em uma cidade, esta AS pode ser implementada em diversas
escalas, como um prédio (Smart Build) e residências (Smart Home).
A partir desta flexibilidade, governos e instituições podem usar esta AS para criar
várias instâncias federativas, como por exemplo, uma instância para região de Sorocaba,
outra para Campinas e uma última para a região metropolitana de São Paulo. A partir
dessa configuração, essas 3 instâncias podem interagir para as estratégias de atuação.
Por fim, é necessário ressaltar que os requisitos de hardware discutidos foram suficientes para testes em pequena escala, porém não serão suficientes no ambiente de
produção real. Esta fato se deve principalmente a fatores relacionados a concorrência,
acessos simultâneos e performance.
Logo, esse quesito prático não pode ser considerado suficiente para a avaliação da
proposta. Dessa forma, o Capítulo seguinte descreve um método para avaliação da AS
proposta, ressaltando os resultados obtidos ao aplicá-lo.

4.11

Considerações Finais do Capítulo

Este Capítulo iniciou-se apresentando o sub-conjunto de requisitos abordados nesta
proposta na Seção 4.1. Para guiar a descrição desta proposta, a Seção 4.2 apresentou o
método de descrição de AS’s utilizado, conhecido como “4+1”, que, quando combinado
com duas outras visões definidas pelo SEI, se mostrou ser bastante efetivo para o contexto
deste trabalho.
Em seguida, a AS proposta foi apresentada, de acordo com as visões do método:
Lógica (Seção 4.3), Execução (Seção 4.4), Implementação (Seção 4.5), Física (Seção 4.6),
Visão Componente Conector (Seção 4.7) e Visão de Dependências (Seção 4.8). A Visão
Lógica apresentou, a partir de um ponto de vista funcional, os principais módulos e as
operações frequentemente realizadas. Por sua vez, a visão de Execução mostrou o mapeamento dos componentes lógicos em processos e threads. A Visão de Implementação
apresentou a implementação de referência que foi realizada e está disponível ém domínio
público14 . A Visão Física relatou algumas características de hardware utilizadas para está
implementação de referência. Por fim, as duas visões definidas pelo SEI foram descritas
para facilitar a compreensão pelos stakeholders.
Ao término das descrições das Visões, pode-se compreender as responsabilidades
e a comunicação entre os seis módulos da AS proposta. O módulo MCA corresponde
ao ponto de comunicação da AS com os sistemas externos. Já o MGR corresponde à
14 https://github.com/gustahrodrigues/Synaptic

61

CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES BASEADA NA INTERNET DAS COISAS

manutenção dos recursos na AS, principalmente ao cadastro e configuração dos mesmos.
Por sua vez, o módulo MGDD é responsável por difundir os dados de/para os recursos
na AS. Finalmente, o módulo MPD é responsável por armazenar todas as informações
relevantes, em qualquer ponto da AS, para consultas posteriores.
Esse conjunto de módulos compõe a proposta que visa agregar valores para os
cidadãos das cidades do Brasil. Alguns desses cenários foram discutidos neste Capítulo
(Seção 4.9), ressaltando principalmente o ponto de vista das entidades que podem propor
estratégias em prol do cidadão.
Finalmente, a Seção 4.10 abordou algumas características importantes da AS proposta.
A partir da descrição da AS reaizada neste Capítulo, o próximo Capítulo descreve um
método para avaliação, baseado em dois métodos: SAAM e ATAM.

62

5
Avaliação da Arquitetura de Software

Obstáculo é aquilo que você enxerga quando tira os olhos do seu
objetivo.
—JUSTIN HERALD, 2006 ˙It’s All a Matter of Attitude

A disciplina de avaliação de Arquitetura de Software (AS) tem se mostrado uma
importante ferramenta para quantificar a qualidade de um software a partir da sua descrição AS (Kazman et al., 1994). De fato, alguns experimentos industriais mostraram
que a aplicação de métodos de avaliação de AS gera ganhos consideráveis durante o
desenvolvimento de software. Em Maranzano et al. (2005) são relatados vários exemplos
da utilização do processo de valiação de AS em grandes empresas, como AT&T 1 e Lucent
Technologies2 . Maranzano et al. (2005) demonstram que o uso de tal abordagem nestas
empresas gerou um ganho de cerca de 1 milhão de dólares em cada projeto que teve seus
problemas identificados e resolvidos previamente.
Sendo assim, podemos concluir que tão importante quanto definir a arquitetura de um
sistema de software é tentar realizar uma avaliação do que foi definido, com o objetivo
de identificar as falhas antes que se tornem grandes problemas no futuro. Logo, a partir
da descrição de módulos realizada no Capítulo anterior, este Capítulo visa avaliar a AS
proposta.
Para tal, inicialmente, serão apresentados alguns métodos de avaliações de AS’s
disponíveis na literatura (Seção 5.1). Ao analisar esses métodos, foi concluído que
nenhum deles atendia o contexto deste trabalho. Logo, a Seção 5.2 propõe uma adaptação
de dois métodos de avaliação de AS’s amplamente aceitos e validados na literatura
1 http://www.att.com/
2 http://www.lucent.com/

63

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

(Roy and Graham, 2008): SAAM (Kazman et al., 1994) e ATAM (Kazman et al., 1999,
2000). Posteriormente, será discutido o processo adotado durante a avaliação desta AS
(Seção 5.3).
Em seguida, a Seção 5.4 discute alguns resultados e comentários a respeito das
principais questões que surgiram durante a avaliação desta AS. Além disso, a Seção 5.5
discute as principais ameaças à avaliação realizada.
Por fim, a Seção 5.6 consolida as principais características do método proposto e dos
resultados obtidos a partir do processo de avaliação utizado.

5.1

Métodos de Avaliação

As arquiteturas de software visam estruturar os componentes de software da melhor
maneira para garantir a qualidade do produto final (Clements, 2003). Dessa forma, é de
suma importância que a avaliação da qualidade do software seja iniciada antes mesmo da
implementação, para que possíveis erros arquiteturais sejam identificados e corrigidos a
fim de minimizar custos.
Para realizar tal procedimento, um método de avaliação é utilizado para guiar os
procedimentos de execução e auxiliar na interpretação dos resultados. Embora os métodos
de avaliação de AS possam variar quanto às técnicas que utilizam, pode-se dizer que, de
uma maneira geral, os métodos possuem um propósito em comum (Kazman et al., 2005).
Este propósito é: investigar se uma determinada AS satisfaz os objetivos de negócio do
sistema para o qual foi projetada.
Logo, a seguir é apresentada uma breve descrição de alguns métodos baseados em
cenários que serviram de base para a adaptação utilizada na avaliação da AS proposta.

5.1.1

Métodos Analisados

A literatura apresenta vários métodos de avaliação, com diferentes objetivos e contextos de
execução, como pode-se constatar nos relatos de Roy and Graham (2008), Shanmugapriya
and Suresh (2012); Bass and Nord (2012).
A partir dessas referências, um conjunto de métodos candidatos a ser utilizado foi
estabelecido. Para filtrar esse conjunto de métodos, a primeira condição a ser utilizada
foi os atributos de qualidade (QA) que o método visa avaliar. Como a AS proposta não
possui uma única finalidade, que possa ser avaliada por um único atributo de qualidade,
optou-se por adotar métodos que compreendem vários atributos de qualidade. A Tabela
5.1 apresenta os métodos encontrados, nas referências relatadas anteriormente, que
satisfazem esse pré-requisito.
64

5.1. MÉTODOS DE AVALIAÇÃO

Tabela 5.1 Métodos de Avaliação Vs Atributos de Qualidade

Método
SAAM
ATAM
SBAR
SACAM
DoSAM

Atributo de Qualidade
Modificabilidade e funcionalidade, mas pode ser adaptado para outros
Vários Atributos de Qualidade
Vários Atributos de Qualidade
Vários Atributos de Qualidade
Vários Atributos de Qualidade

Um outro fator que deve ser levado em consideração no momento de escolher qual
método de avaliação utilizar é o objetivo do método (Clements, 2003). Logo, a Tabela
5.2 apresenta o objetivo de cada método resultante do pré-requisito anterior.
Tabela 5.2 Métodos de Avaliação Vs Objetivo

Método
SAAM
ATAM
SBAR
SACAM
DoSAM

Objetivo
Adequação arquitetural e identificação de riscos
Foco em sensibilidade da arquitetura e análise trade-off
Avaliar arquiteturas legadas a partir de reengenharia, utilizando Domain
Specific Software Architecture, para criar uma base reutilizável e flexível
Comparação com outras arquiteturas de software descritas na literatura
Comparação com outras arquiteturas de software descritas na literatura

A partir destas duas pré-condições, nota-se que o método SBAR não pode ser utilizado
pois a AS proposta não é uma legada. Por sua vez, SACAM e DoSAM não devem ser utilizados, pois não há nenhuma outra AS, disponível e amplamente aceita na literatura, que
possa ser comparada com a AS proposta, devido a falta de especificação e detalhamento
arquitetural.
Por fim, restaram apenas dois métodos que satisfazem o contexto da AS proposta: (1)
SAAM (Kazman et al., 1994) e (2) ATAM (Kazman et al., 1999, 2000). A seguir uma
breve descrição de cada um desses métodos é apresentada.

5.1.2

Descrição dos métodos restantes

• SAAM (Software Architecture Analysis Method) é um método de avaliação simples que pode ser adaptado à diferentes contextos. Inicialmente proposto para ser
utilizado para analisar modificabilidade e funcionalidade, o SAAM é amplamente
utilizado nos demais atributos de qualidade, tais como portabilidade, extensibilidade e integrabilidade (Qun-li and jie, 2008).

65

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

O método SAAM inclui 6 atividades: (i) desenvolvimento dos cenários; (ii) descrição da AS avaliada; (iii) classificação e priorização dos cenários; (iv) avaliação dos
cenários individual e indireta; (v) interação entre os cenários; (vi) avaliação global
dos cenários (Kazman et al., 1994).
Algumas das principais vantagems do SAAM são a melhoria na documentação da
AS e a identificação de riscos (Kazman et al., 1994).
• ATAM (Architecture Tradeoff Analysis Method) é um método baseado em cenários, porém, é mais complexo se comparado ao SAAM. A aplicação do ATAM
revela quão bem uma AS satisfaz os requisitos de qualidade desejados, além de identificar os riscos arquiteturais e os conflitos (trade-offs) existentes para se alcançar
tais requisitos (Qun-li and jie, 2008).
O ATAM inclui 4 atividades principais: (i) Descrição: apresentação do ATAM, dos
objetivos de negócios e da AS; (ii) Investigação e Análise: geração dos atritos de
qualidade utilizando utility tree; análise das abordagens arquiteturais; brainstorm e
priorização dos cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentação
dos Resultados (Kazman et al., 1999, 2000).

5.2
5.2.1

Adaptação dos métodos de avaliação
Definição do método de avaliação

Apesar dos dois métodos restantes serem os mais adequados para a AS proposta, o
contexto de aplicação do método não condizia com o contexto deste trabalho, devido as
seguintes peculiaridades:
• A equipe de avaliação estava distribuída geograficamente, com rotinas e compromissos diferentes. Logo, a avaliação deveria ser totalmente remota;
• Na equipe de avaliação, não há nenhum stakeholder com domínio em ambos os
temas de pesquisa que envolvem esta proposta (CI e IoT);
• Não foi encontrada nenhum método de avaliação para o contexto de equipes
distribuída geograficamente;
• Como as reuniões seriam realizadas por Skype, as reuniões deveriam ser curtas
para manter a equipe concentrada.
66

5.2. ADAPTAÇÃO DOS MÉTODOS DE AVALIAÇÃO

Logo, surgiu a necessidade de propor uma adaptação dos dois métodos a fim de sanar
essas peculiaridades. Esta adaptação é baseada no SAAM e ATAM, porém as atividades
são específicas para o contexto remoto. Apesar disto, nenhuma nova etapa foi criada,
pelo contrário, as etapas recomendadas pelo SAAM e ATAM foram apenas combinadas
e adaptadas para o respectivo contexto. A Tabela 5.3 apresenta as 10 etapas do método
adaptado.
Tabela 5.3 Etapas do método adaptado










10º

5.2.2

Apresentação do Processo de avaliação
Apresentação dos Objetivos de Negócios
Apresentação da AS
Priorização dos QAs
Contextualização sobre cenários
Apresentação dos cenários
Priorização dos cenários
Avaliação dos cenários propostos
Avaliação das interações entre Cenários e QAs
Consolidação dos Resultados

Equipe de Avaliação

A primeira etapa para a definição do método de avaliação a ser utilizado foi a escolha
da equipe de avaliação. Devido ao fato de que CI pode ser considerado um sistema de
sistemas heterogêneos, as pessoas escolhidas para participar da equipe são de diferentes
áreas de pesquisa, com diferentes experiências e visões. Além disso, a heterogeneidade
da equipe enriquece as discussões, pois cada um avalia o mesmo quesito por diferentes
pontos de vista, baseado nos respectivos backgrounds (Clements, 2003).
Esta equipe foi composta por desenvolvedores e arquitetos provenientes do C.E.S.A.R,
professores do CIN-UFPE e da UFSCar Sorocaba. Ao total, 5 pessoas foram envolvidas
no processo de avaliação. A Tabela 5.4 ilustra as expertises dos envolvidos, na qual
a coluna “#” ilustra a quantidade dos envolvidos com a determinada expertise. Vale
ressaltar que um mesmo envolvido pode ter mais de uma expertise.

5.2.3

Descrição do Método de Avaliação

Inicialmente o processo de avaliação deve ser descrito, ressaltando principalmente quais
os artefatos esperados de cada etapa. Em seguida, como recomenda o SAAM, um

67

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

Tabela 5.4 Expertises da equipe de avaliação

Expertise
Doutores ou Doutorandos
Mestres ou Mestrandos
Engenheiros de Sistemas
Especialistas em Cloud Computing
Especialistas em IoT
Especialistas em Arquiteturas escaláveis
Especialistas em Arquiteturas de propósito geral
Especialistas em Negócios

#
3
2
4
1
2
2
2
2

participante da equipe de avaliação com a visão de negócio deve apresentar as expectativas
de uma AS para CI que combine IoT. Esta etapa é de suma importância, pois estas
expectativas serão utilizadas para quantificar o quão a AS proposta atende aos objetivos
estabelecidos.
A próxima etapa consiste na apresentação da AS propriamente dita. Nesta etapa, o
arquiteto pode utilizar o método de descrição arquitetural que lhe interesse. Entretanto,
este método deve fornecer subsídios suficientes para o completo entendimento da AS por
parte dos demais participantes, incluindo interações entre os módulos, regras de negócios
e o ciclo de vida dos componentes (Kruchten, 1995).
Em seguida, deve-se realizar a etapa de priorização dos atributos de qualidade com
base nos objetivos de negócios, previamente discutidos. Para tal, recomenda-se que o
arquiteto sugira um conjunto de atributos de qualidade pré-selecionados que possam
ser empregados. A literatura apresenta alguns métodos de priorização dos atributos
de qualidade, porém o mais usual é estabelecer que cada participante possui 3 votos
que deve ser distribuído dentre os atributos de qualidade. Após todos os participantes
votarem, os atributos de qualidade que receberem mais votos devem ser considerados
mais prioritários.
A contexualização sobre o que são cenários para toda a equipe de avaliação deve
ser realizada a seguir. Um cenário, neste contexto, ilustra os tipos de atividades que um
sistema deve suportar. Um exemplo de cenário pode ser: “Qual o impacto na arquitetura
caso ocorra uma mudança no modelo de troca de mensagens entre os componentes”. Vale
ressaltar que o desenvolvimento desses cenários é crucial para capturar os principais usos
do sistema, seus usuários, antecipar mudanças no sistema, e qualidades que o sistema deve
satisfazer agora e no futuro. Estes cenários devem ser elicitados por todos os stakeholders
do sistema a partir dos objetivos de negócios, logo, representam questões sob diferentes
68

5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

pontos de vista e, na maioria das vezes, trazem informações bem específicas do sistema
avaliado.
Antes da próxima etapa deste processo de avaliação é importante criar algum mecanismo para que os participantes possam propor os possíveis cenários. Uma técnica que
pode ser utilizada é o compartilhamento de uma planilha online entre cada participante e
o arquiteto.
Após todos os membros da equipe de avaliação escrevem os possíveis cenários, o
arquiteto deve consolidar os cenários propostos. Esta consolidação resume-se em filtrar os
cenários duplicados e reescrever alguns com outras palavras para facilitar a compreensão.
No início da próxima etapa, todos os cenários propostos pelos participantes devem ser
apresentados, para que os demais participantes conheçam os diferentes pontos de vista.
Em seguida, todos devem priorizar os cenários de acordo com a relevância para a AS
proposta. Esta priorização pode ser feita da mesma forma que a priorização dos QAs.
Para a próxima etapa, de avaliação dos cenários propostos, também é interessante
criar um mecanismo para que seja realizada remotamente. Um exemplo é a criação de um
formulário online na qual cada participante deve dar uma nota para o quão cada cenário
está contemplado pela AS.
Feito isso, na etapa seguinte o arquiteto deve conduzir uma discussão a respeito das
interferências dos atributos de qualidades nos cenários priorizados, como descrito pelo
ATAM. Geralmente estas discussões geram conclusões de que, para atender a um cenário
específico, mas muito relevante, deve-se deixar de implementar totalmente um atributo
de qualidade.
Por fim, o arquiteto deve apresentar os resultados finais do processo de avaliação.
Nesta etapa é importante apresentar todos os artefatos gerados em cada etapa do processo
de avaliação. Além disso, devem ser apresentados os pontos positivos e os pontos de
melhoria que, a partir do processo executado, foram identificados.

5.3

Processo de Avaliação Executado

A partir da descrição do processo de avaliação na Seção anterior, o processo foi executado
remotamente via Skype e as etapas foram divididas em 3 reuniões:

5.3.1

Primeira Reunião

O objetivo da primeira reunião foi apresentar os objetivos de negócios da AS proposta e
contextualizar todos os envolvidos no processo de avaliação em relação à temática de CI.

69

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

As etapas da reunião foram as seguintes:
1. Apresentação do Processo de Avaliação (Duração 30min): Inicialmente, foi
descrito a origem da adaptação dos métodos, ressaltando as principais diferenças
com os métodos disponíveis na literatura. Consequentemente, o processo de
avaliação a ser utilizado foi descrito. O objetivo desta etapa foi situar todos os
envolvidos em relação ao objetivo do processo e aos próximos passos;
2. Objetivos de Negócios (Duração 30min): A segunda etapa da reunião teve a
intenção de definir e apresentar os objetivos de negócios da AS proposta. Este
passo foi importante para que os participantes da avaliação entendessem o contexto
do sistema e também as limitações técnicas, econômicas e de cronograma existentes
para a execução do projeto. Todos esses aspectos foram apresentados para ajudar na
definição dos atributos de qualidade a serem considerados no processo de avaliação;
3. Apresentação da AS (Duração 1hora): Neste passo, a AS proposta foi detalhada
pelo arquiteto através de uma visão de módulos. Para tal, foi utilizado o framework
de descrição AS conhecido como “4+1” (Kruchten, 1995). Cada módulo foi detalhado, ressaltando, principalmente, o requisito arquitetural que este visa atender.
Além da visão de módulos, foi apresentada a comunicação entre os módulos. Esta
apresentação foi de suma importância para os participantes perceberem como os
requisitos foram implementados para avaliar se de fato eles satisfazem as necessidades dos contextos de CI. Além disso, por meio desta descrição detalhada é
possível identificar possíveis falhas e/ou pontos de melhoria na AS proposta;
4. Priorização dos Atributos de Qualidade (Duração 1hora): Como alguns participantes não estavam acostumados ao conceito de Atributos de Qualidade, inicialmente foi descrito o que são e quais os objetivos dos mesmos. Em seguida,
o arquiteto apresentou os atributos de qualidade definidos pela ISO/IEC 9126
(ISO/IEC, 2001) e pelo CMU/SEI-95-TR-021 (Barbacci et al., 1995), com o objetivo de exemplificar possíveis atributos de qualidade aplicáveis à AS proposta.
Ao término dessa etapa, os participantes sugeriram alguns atributos de qualidade,
com base nos objetivos de negócios. Em seguida, foi realizado uma votação para
priorizar quais os atributos melhor expressam os objetivos de negócios, apresentados anteriormente. Nesta votação, cada participante poderia distribuir 3 votos
entre os atributos de qualidade. Cada voto foi computado individualmente a partir
de um formulário online disponibilizado para cada envolvido. A Tabela 5.5 exibe
70

5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

o resultado desta votação. A coluna “fonte”, refere-se à origem do atributo de
qualidade, na qual “participante” são os atributos propostos pelos participantes da
avaliação.
Tabela 5.5 Priorização dos Atributos de Qualidade

#









10º
11º

QA
Confiabilidade
Funcionalidade
Escalabilidade
Portabilidade
Disponibilidade
Segurança
Performance
Eficiência
Usabilidade
Acoplamento
Manutenabilidade

Fonte
ISO/IEC 9126 e CMU/SEI-95-TR-021
ISO/IEC 9126
Participantes
ISO/IEC 9126
Participantes
CMU/SEI-95-TR-021
CMU/SEI-95-TR-021
ISO/IEC 9126
ISO/IEC 9126
CMU/SEI-95-TR-021
ISO/IEC 9126

Votos
4
3
2
1
1
1
1
1
1
0
0

As definições consideradas para os atributos foram:
• Confiabilidade: visa avaliar se a arquitetura estará disponível quando necessário;
• Funcionalidade: conjunto de atributos que evidenciam a existência de um
conjunto de funções e suas propriedades especificadas. As funções são as que
satisfazem as necessidades explícitas ou implícitas;
• Escalabilidade: capacidade que um sistema possui de se expandir, de forma
a permitir o atendimento das necessidades pelo crescimento do número de
usuários do sistema, ou também pelo aumento das informações a serem
processadas;
• Portabilidade: capacidade do sistema ser transferido de um ambiente para
outro;
• Disponibilidade: refere-se ao conjunto de atributos que interferem na probabilidade de que um sistema esteja funcionando e pronto para uso em um dado
instante de tempo;
• Segurança: refere-se ao conjunto de propriedades da arquitetura que interferem diretamente na garantia da integridade dos dados da aplicação e no
acesso aos mesmos;

71

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

• Performance: visa quantificar se a arquitetura computará os dados em tempo
hábil, coerente com o contexto da requisição;
• Eficiência: conjunto de atributos que interferem diretamente nos tempos de
resposta de um sistema;
• Usabilidade: conjunto de atributos que evidenciam o esforço necessário para
se poder utilizar o software, bem como o julgamento individual desse uso,
por um conjunto explícito ou implícito de usuários;
• Acoplamento: refere-se ao grau de dependência entre os componentes de
software;
• Manutenabilidade: atributos do software que evidenciam o esforço necessário para modificá-lo, remover seus defeitos ou adaptá-lo a mudanças.
5. Contextualização sobre Cenários (Duração 20min): O último passo dessa primeira reunião, foi a contextualização sobre cenários. Da mesma forma como os
atributos de qualidade, inicialmente foi realizada uma breve apresentação sobre
o que são e quais as necessidades dos cenários. Em seguida, alguns cenários
foram exemplificados, como “Disponibilizar um novo tipo de dado” e “Combinar
informações de duas ou mais fontes de dados”.
Por fim, uma planilha foi compartilhada com cada participante para que eles
pudessem detalhar os cenários de utilização da AS com base nos objetivos de negócios. Para isso, um prazo de 4 dias foi estipulado para que todos os participantes
descrevessem os possíveis cenários.

5.3.2

Segunda Reunião

A Segunda Reunião foi marcada uma semana depois da primeira reunião, para mitigar o
risco dos participantes esquecerem algum tópico abordado.
Após os 4 dias estipulados para que todos os participantes descrevessem os cenários,
o arquiteto consolidou todos os cenários. Esta consolidação resumiu-se em, basicamente,
filtrar os cenários duplicados e reescrever alguns com outras palavras para facilitar a
compreensão dos demais participantes. Apenas 2 cenários foram considerados duplicados
e 1 precisou ser reescrito.
1. Apresentação dos Cenários (Duração 30min): Nessa primeira etapa da segunda
reunião, foram apresentados todos os cenários propostos pelos participantes da
72

5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

avaliação no prazo estipulado. Como vários participantes possuem diferentes
visões e experiências, foram identificados diferentes nichos de aplicabilidade da
AS proposta, por exemplo, em contextos totalmente distribuídos ou, até mesmo,
em contextos federados.
2. Priorização dos Cenários (Duração 1hora): A segunda etapa foi uma discussão
conduzida pelo arquiteto na qual o objetivo era a priorização dos cenários. Essa
discussão foi guiada pelo arquiteto, na qual cada cenário foi discutido e um peso de
relevância foi atribuído para cada cenario. Essa priorização levou em consideração
os cenários mais aplicáveis, coerentes e factíveis na AS proposta.
3. Avaliação dos Cenários propostos (Duração 1hora): Em seguida, os cenários
priorizados foram avaliados e discutidos sobre a AS proposta. O principal objetivo
foi avaliar o quão os cenários levantados condizem com a natureza da AS proposta.
Ao término desta reunião, os cenários resultantes são exibidos na Tabela 5.6, ordenados de acordo com a priorização.

5.3.3

Terceira Reunião

Da mesma forma que a Segunda Reunião, a Terceira e última reunião foi marcada uma
semana depois. O objetivo primordial dessa reunião foi consolidar os resultados e definir
as possíveis ações a serem tomadas para aprimorar a proposta.
Para tal, foi criado um formulário online com todos os cenários, ordenados por ordem
de priorização. O objetivo deste formulário foi de mensurar quantitativamente o quão a
AS contempla cada cenário.
1. Avaliação das interações entre Cenários e Atributos de Qualidade (Duração
1hora): Nesta primeira etapa da reunião, os participantes discutiram o quão os
cenários priorizados conflitavam com os atributos de qualidade.
2. Consolidação dos Resultados (Duração 1hora): Nesta etapa os resultados foram
apresentados. Primeiramente, um overview sobre cada artefato gerado durante o
processo foi apresentado, principalmente a priorização dos atributos de qualidade e
os cenários. A próxima Seção detalhará esses resultados.
A Seção a seguir resume os resultados obtidos com o processo de avaliação de AS
realizado.

73

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

Tabela 5.6 Cenários resultantes de acordo com a relevância

ID
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14

5.4

Cenário
Armazenar dados fornecidos por diferentes contextos e provedores,
independente do formato e da natureza do dado
Consultar dados oriundos de um provedor de dado, independente de
quando esse dado foi gerado
Permitir que novos tipos de informações sejam fornecidas, a partir da
combinação de uma ou mais fontes de dados
Permitir a inclusão de novos provedores de dados
A AS deve auxiliar a interoperabilidade entre sistemas, na qual um
evento gerado externamente pode disparar ações
A AS deve auxiliar a fusão de dados, na qual um evento produzido
internamente com base na análise de dados/histórico pode gerar ações
externas
A AS deve permitir a comunicação via API
A AS deve permitir a recuperação de grandes massas de dados
históricas de diversas fontes, a fim de obter previsões que dizem respeito
à prestação de serviços urbanos
Fornecer algum mecanismo para tolerância a falhas (redundância)
Permitir a criação e comunicação de instâncias federativas, baseada em
serviços
Possuir mecanismo para a inclusão de novos protocolos de comunicação
na AS
Plugar novas soluções para diferentes contextos utilizando a mesma
infraestrutura
Suporte a serviços em Cloud Computing já existentes (Ex.: Google
Analytics e cloud storage)
Gerenciar os dados do usuário de acordo com as políticas de privacidade
governamentais

Resultados da Avaliação da Arquitetura

Um dos benefícios de se realizar qualquer avaliação de Arquitetura de Software (AS) é a
melhoria de comunicação entre os stakeholders, resultando em um melhor entendimento
dos requisitos.
Logo, conforme descrito na Seção anterior, para mensurar quantitativamente o quão
a AS contempla cada cenário, foi criado um formulário online com todos os cenários,
ordenados por ordem de priorização. Neste formulário, cada participante deveria atribuir
uma nota para a adequação de cada cenário, na qual 5 representa que a AS ATENDE
TOTALMENTE e 0 significa que NÃO ATENDE ao cenário em questão.
74

5.4. RESULTADOS DA AVALIAÇÃO DA ARQUITETURA

A partir deste formulário, foram obtidas algumas conclusões, que serão exemplificadas
nas posteriores subseções.

5.4.1

Resultados da Avaliação dos Cenários

Cada participante respondeu o formulário online independentemente. A partir disso, o
arquiteto consolidou todas as respostas anonimamente. A figura 5.1 ilustra a média e o
desvio padrão das respostas, além de 3 faixas de satisfatoriedade, definidas pelos próprios
participantes da avaliação.

Figura 5.1 Resultado da avaliação dos cenários

Para analisar os resultados na Figura 5.1, deve ser considerada a relevância dos
cenários propostos, priorizados durante o processo de avaliação.
Como é possível notar, na opinião dos participantes, a AS atende à três cenários
de maneira EXCELENTE. O primeiro cenário (C2) é relacionado aos mecanismos
de distribuição de dados implementados no MGDD (Seção 4.3.3), principalmente a
utilização da DHT de dados. Conforme discutido, a utilização da DHT permitiu que os
recursos fornecedores e consumidores e os canais de dados estejam distribuídos em uma
infraestrutura de cloud.
Já o segundo cenário categorizado como EXCELENTE (C4) foi obtido a partir da
implementação do padrão publisher-subscriber também no MGDD. Esta implementação
permite que um dado seja disponibilizado para todos os recursos consumidores assim
que é produzido. No contexto de CI, esta característica básica é de suma importância se
todos os consumidores receberam os dados simultâneamente e está contemplada nesta
proposta. Além disso, o desacoplamento entre fornecedores e consumidores de dados
oriundos a partir do padrão publisher-subscriber também é de suma importância para

75

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

futuras expansões da AS.
O último cenário avaliado positivamente (C7) é oriundo do modelo de abstração e da
flexibilidade implementada no MAC (Seção 4.3.1). Esta abstração permite que novos
protocolos de troca de mensagens sejam inseridos sob demanda. Já a flexibilidade está
relacionada à capacidade de trocar a interface REST ou, até mesmo, incluir outro padrão
em paralelo.
A maioria dos cenários foram considerados SATISFATÓRIOS pelos participantes da
avaliação. Embora este resultado indique que a AS, em uma primeira instância, atende a
um conjunto de contextos de utilização, ela deve ser aprimorada para atender de maneira
segura e eficiente aos demais contextos.
Além disso, dois cenários foram classificados como PÉSSIMO. O primeiro (C9) está
relacionado à inserção de algum mecanismo de tolerância a falhas. Não foi encontrado
nenhum mecanismo semelhante nas abordagens encontradas na literatura. Porém, no
contexto de uma CI é inadmissível que todo o sistema da cidade deixe de funcionar devido
à um problema em algum módulo ou componente de software. A literatura apresenta
diversas técnicas de redundância, tanto de dados como de componentes de software, que
devem ser inseridas na proposta. Além disso, estratégias de backup, controle de acesso e
demais aspectos relacionados à confiabilidade da proposta devem ser investigadas.
O outro cenário que foi classificado como PÉSSIMO (C14) corresponde às políticas
de privacidade de dados utilizadas pela AS. Conforme pôde ser verificado, este requisito
não faz parte desta AS. Além disso, esta necessidade foi identificada no começo desta
pesquisa, porém um outro trabalho de mestrado está sendo desenvolvido com este escopo.
Este trabalho de privacidade será acoplado à esta proposta assim que finalizado. Para isso,
as definições de interfaces e padrões de mensagens estão sendo definidas em conjunto. O
escopo deste trabalho de privacidade é criar um mecanismo em que, a partir das interações
anteriores, os cidadãos possam “negociar” o quão seus dados estarão disponíveis para um
determinado provedor de serviço urbano.

5.4.2

Resultados Gerais

Esta sub-seção visa elencar os resultados gerais obtidos a partir do processo de avaliação
executado. Estes resultados foram extraídos a partir das discussões com os participantes
e não necessariamente são observados nos artefatos do processo.
Primeiramente, o fato de dois de três cenários categorizados como EXCELENTE
estarem diretamente relacionado ao MGDD era esperado. O MGDD pode ser considerado
o core da proposta, principalmente devido ao módulo de distribuição de dados utilizado.
76

5.5. AMEAÇAS À AVALIAÇÃO

Este modelo, utilizando o padrão publisher-subscriber foi encontrado em outros contextos
e adaptado para esta proposta. Além disso, a alta quantidade de requisitos que o MGDD
visa satisfazer representa os principais diferenciais desta proposta com as demais.
Este fato alerta para possíveis problemas relacionados ao acoplamento do MGDD
com o restante da AS. Por exemplo, deve-se prever e criar mecanismos para mitigar os
possíveis problemas no MGDD relacionados à indisponibilidade da DHT Canais de Dados. Caso isso aconteça, os demais módulos devem continuar funcionando corretamente
a partir de mecanismos de redundância.
Além disso, de acordo com os participantes, não é necessário descrever um novo
padrão arquitetural para o contexto de CI e IoT. Esta conclusão foi obtida a partir da
avaliação de que a proposta atual contempla alguns padrões arquiteturais e já atende
diversos cenários de utilização.
De maneira geral, estes resultados mostram que a AS pode e deve ser utilizada em um
contexto real, para, de fato, verificar a adequação da AS ao contexto de CI e IoT. Logo,
como trabalho futuro, a proposta atual será implantada em um ambiente real por meio de
parcerias com orgãos interessados.

5.5

Ameaças à Avaliação

Na avaliação da arquitetura descrita previamente, algumas ameaças foram identificadas.
Estas ameaças não afetam diretamente o resultado final desta avaliação, porém devem ser
analisadas para trabalhos futuros.
A primeira ameaça está relacionada à quantidade de pessoas envolvidas no processo
de avaliação. Por mais que a equipe tenha várias expertises diferentes englobando várias
áreas de uma cidade, como recomendado por Clements (2003), se mais pessoas tivessem
participado da avaliação outros pontos de vistas poderiam ser levantados. Infelizmente,
este pequeno número de participantes foi devido à disponibilidade do grupo de pesquisa
para a realização das três reuniões mencionadas.
A outra ameaça está relacionada com a ordem das etapas do método de avaliação.
Como apresentação da arquitetura foi realizada antes da definição e priorização dos
atributos de qualidade e dos cenários, a opinião dos participantes pode ter sido enviesada.
Apesar disto, no inicio das etapas de definição e priorização dos atributos de qualidade
e dos cenários foi ressaltado que as opiniões deveriam ser a partir da apresentação dos
objetivos de negócios. Logo, uma melhoria no método de avaliação é alterar a ordem
destas etapas.

77

CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE

5.6

Considerações Finais do Capítulo

Este Capítulo iniciou-se apresentando os filtros aplicados nos métodos de avaliação
disponíveis na literatura Seção 5.1. Estes filtros foram aplicados de acordo com o
contexto da avaliação a ser executada.
Após estes filtros, os métodos SAAM e ATAM foram considerados os mais indicados.
Porém, a versão original destes métodos não condiz com o contexto desta avaliação. Logo,
a Seção 5.2 propôs uma adaptação destes dois métodos de avaliação de AS’s amplamente
aceitos e validados na literatura.
Finalmente, a Seção 5.3 apresentou todas as etapas do processo de avaliação executado.
Por fim, a Seção 5.4 discutiu os principais resultados da avaliação.
A partir da avaliação realizada, pode-se mensurar o quão a AS está apta para ser
implantada em um contexto real. Dessa forma, o próximo Capítulo finaliza o trabalho
descrevendo as principais conclusões e as atividades futuras, como implantar a AS em
um ambiente real e controlado.

78

6
Conclusão
Feliz aquele que transfere o que sabe e aprende o que ensina.
—CORA CORALINA, 2007 (Vintém de cobre: meias confissões de
Aninha. 9. ed . São Paulo: Global.)

Uma vez que a AS para Cidade Inteligente (CI) foi especificada e projetada, algumas
conclusões e direções para trabalhos futuros podem ser apontadas.
Desta forma, este Capítulo apresenta as conclusões finais deste trabalho e está organizado da seguinte maneira: a Seção 6.1 apresenta um resumo das principais conclusões
deste trabalho. A Seção 6.2 relata alguns trabalhos relacionados. A Seção 6.3 aponta
um conjunto de trabalhos futuros, e finalmente, a Seção 6.4 contém a conclusão final da
dissertação.

6.1

Principais Conclusões

Esta Seção resume as principais conclusões deste trabalho, enumeradas abaixo:
• O crescimento populacional desenfreado, combinado com outras questões de má
governança, tem potencializado os problemas urbanos. Estes problemas estão
relacionados aos diversos serviços de uma cidade, como saúde, transporte e lazer.
Consequentemente, estes problemas afetam diretamente o dia-a-dia dos cidadãos e
dificultam o gerenciamento das cidades pelos gestores (Seção 1.1).
• Apesar da evidente necessidade de cidades cada vez mais inteligentes, ainda não
há um consenso sobre a definição mais adequada para o termo CI. Mesmo assim,
várias abordagens estão sendo desenvolvidas com o paradigma de utilizar IoT
como ferramenta para a implementação, de fato, de uma CI. Neste contexto, as

79

CAPÍTULO 6. CONCLUSÃO

tecnologias IoT são utilizadas, principalmente, para monitorar, controlar e atuar
sobre os diversos serviços urbanos (Capítulo 2).
• Na literatura, várias abordagens estão sendo desenvolvidas com este paradigma.
Porém, a maioria destas abordagens focam em apenas um conjunto muito restrito
de serviços urbanos e não consideram a integração entre estes serviços (Capítulo
3).
• A AS proposta por esta dissertação permite que os dados entre os diferentes
serviços urbanos sejam difundidos para todos os recursos interessados. Para tal, a
AS implementa um padrão arquitetural bastante conhecido na literatura chamado
de publisher-subscriber (Capítulo 4).
• Para avaliar a AS proposta, dois métodos de avaliação arquitetural foram adaptados
para o contexto deste trabalho. Esta adaptação mostrou-se bastante útil, uma vez
que os principais benefícios citados na teoria, tais como composição de dados
urbanos, foram confirmados (Seção 5.4).

6.2

Trabalhos Relacionados

Em PlanIT (2012) foi adotada uma estratégia de implementar um Sistema Operacional
Urbano (UOS). Este sistema operacional consiste em uma plataforma que visa integrar
cada domínio que compõe a cidade. O sistema é alimentado por uma vasta rede de
sensores e todos esses dados são capturados por tempo indeterminado, para auxiliar na
tomada e na predição de decisões. Além de prever catástrofes, caso ocorra, o sistema pode
antever todos os possíveis impactos na cidade. As principais diferenças da abordagem de
PlanIT (2012) e esta proposta são a parceria com setor privado (PlanIT (2012) possui uma
parceria com Cisco e Microsoft) e o modelo de distribuição de dados, uma vez que no
modelo adotado em PlanIT (2012) a disponibilização de um novo tipo de dado é custosa,
do ponto de vista arquitetural.
Outra abordagem em que se utilizam vários sensores embarcados nos contextos urbanos é SmartSantander (Sanchez et al., 2011). A quantidade de dispositivos configurados
na AS é superior à 12.000. O SmartSantander provê: i) um modelo de refência de arquitetura para sistemas IoT do mundo real; ii) um escalável, heterogêneo e confiável facilitador
de experimentos; iii) um conjunto representativo de casos de uso implementados para
facilidades de experimentação e iv) um grande conjunto de experimentos e resultados
sobre o futuro da internet. A principal diferença da abordagem descrita por Sanchez et al.
80

6.2. TRABALHOS RELACIONADOS

(2011) com esta proposta, além da parceria com o setor privado, são os mecanismos que
permitem a composição de dados urbanos. Na proposta deste trabalho, assim que um
dado novo é disponilizado, permite-se a criação de um novo canal para este dado. Além
disto, esta proposta contempla mecanismos de gereção de histórico, que é fundamental
para a tomada de decisões futuras.
Por sua vez, em Filipponi et al. (2010) a integração de sensores é abordada a partir
de uma AS baseada em eventos, na qual cada evento corresponde à mudança de estado
de qualquer sistema de TIC. Estes eventos podem ser iniciados a partir de eventos do
mundo real (como detecção de presença) ou ao término de algum processamento. A
abordagem de Filipponi et al. (2010) é bastante similar com esta proposta no quesito de
modelagem do ambiente real. Porém, a principal diferença é a existência nesta proposta
de um mecanismo para geração de histórico para a previsão de futuros eventos. Além
disto, as informações de cada sensor que está fornecendo os dados pode ser utilizada
para otimizar o desempenho dos algoritmos (Shao, 2011; Hernández-Muñoz et al., 2011;
Vega-Barbas et al., 2012).
Neste sentido, em Hernández-Muñoz et al. (2011) é proposta uma AS (USN), com o
objetivo de prover uma infraestrutura que seja capaz de integrar sensores heterogêneos
e dispersos geograficamente em um base centralizadora, na qual serviços podem ser
facilmente desenvolvidos. Esta abordagem de Hernández-Muñoz et al. (2011) é similar a
esta proposta nas técnicas adotadas para permitir a integração de sensores heterogêneos.
A principal diferença é que nesta proposta novos protocolos de troca de mensagens podem
ser facilmente inseridos. Além disto, o custo para integrar diferentes fornecedores de
dados nesta proposta é muito baixo para otimizar o desempenho em larga escala.
Finalmente, em Al-Hader et al. (2009) é proposta uma AS baseada em quatro princípios: aplicações, negócios, gerenciamento de processos e infraestrutura de redes. O
primeiro princípio corresponde às aplicações que fazem uso de diferentes tecnologias
para monitorar sensores, como GPS. A maioria dessas aplicações atendem as demandas
operacionais das cidades, porém, ao utilizar as regras definidas no segundo princípio negócios - elas podem agregar soluções economicamente viáveis. O terceiro princípio é o
gerenciamento de processos no qual relacionamentos, regras, estratégias e políticas entre
as aplicações e as unidades de negócios são definidos. O último princípio corresponde a
toda a infraestrutura de rede, responsável por conectar os outros três princípios. A principal diferença da abordagem de Al-Hader et al. (2009) para esta proposta é a criação de
um componente específico para modelos de negócio. Este diferencial pode ser facilmente
incorporado nesta proposta, uma vez que este componente poderia ser um consumidor de

81

CAPÍTULO 6. CONCLUSÃO

dado que, a partir dos dados que estão trafegando na arquitetura, inferir um modelo de
negócios eficaz com estas informações.
Ao analisar os principais trabalhos relacionados, pôde-se observar que todos visam
mitigar apenas uma deficiência tecnológica relacionada à CI. Apenas a abordagem de
PlanIT (2012) visa integrar as informações provenientes de diferentes domínios de uma
cidade, o que pode contribuir para tornar uma cidade de fato inteligente.
Além disto, o conjunto de requisitos que esta proposta contempla é superior à todos os
trabalhos relacionados. Apesart deste conjunto de requisitos ter sido definido juntamente
com esta proposta, este refleta uma série de características que qualquer Arquitetura de
Software (AS) para Cidade Inteligente (CI) deveria atender.
Os resultados desta dissertação estão baseados em um trabalho de pesquisa que
analisou o estado da arte e da prática no tocante as AS’s de software para CI que
combinam tecnologias IoT. Estes resultados envolvem, entre outras coisas: (i) um
levantamento das soluções existentes, (ii) a extração de um conjunto de requisitos que
uma AS para CI deve atender, (iii) o projeto da AS, (iv) a avaliação preliminar da AS e
(v) uma implementação de referência.

6.3

Trabalhos Futuros

A versão inicial desta AS não contempla algumas características, principalmente as
questões relatadas na Seção 1.4, e os resultados da avaliação da AS:
• Utilização em Ambiente Real: A proposta atual será implantada em um ambiente
real a partir de parcerias com empresas e prefeituras. Certamente essa etapa vai
contribuir com a proposta e avaliar, de fato, à adequação ao contexto deste trabalho.
• Mecanismo de tolerância à falhas: Estratégias de redundância devem ser implementadas para que os serviços urbanos não sejam afetados devido a uma eventual
falha em algum ponto da AS;
• Políticas de privacidade: Já que vários dados pessoais dos cidadãos trafegarão
pela AS, torna-se indispensável a adequação de políticas de privacidade, principalmente relacionadas ao armazenamento, utilização e descarte dos dados;
• Modelo de Negócio: Modelos de negócios devem ser discutidos para suprir os
custos envolvendo a implementação, manutenção e expansão desta AS no ambiente
real. Uma estratégia que deve ser discutida é a parceria com governos e empresas
para a utilização desta AS;
82

6.4. CONCLUSÃO

• Análises de big data: Com o alto volume de dados potencialmente gerado a partir
da utilização desta AS, análises de big data devem ser feitas para otimizar o
desempenho dos serviços urbanos;
• Semântica dos Dados: Futuras pesquisas podem investigar a melhor estratégia de
semântica dos dados a ser implementada nesta proposta.

6.4

Conclusão

A necessidade de cidades cada vez mais inteligentes é notoriamente crescente. Vários
dados publicados pela mídia em geral comprova que o crescimento populacional não está
alinhado com o desenvolvimento das infraestruturas e dos principais serviços urbanos.
A precariedade destes serviços urbanos afeta negativamente a qualidade de vida dos
cidadãos.
Logo, torna-se fundamental o investimento em estratégias que visam mitigar estes
problemas urbanos para otimizar a vida dos cidadãos. Estas iniciativas devem ser desenvolvidas considerando as partes envolvidas: governo e cidadãos. Além disso, torna-se
importante que os cidadãos estejam conscientes do seu papel em prol de uma cidade
melhor para todos.
Neste sentido, esta dissertação apresentou a especificação e o projeto de uma AS para
CI que permite a integração de tecnologias IoT para mitigar estes problemas urbanos.
Esta AS foi proposta a partir de um conjunto de requisitos mais importante extraído das
principais abordagens disponíveis na literatura.

83

Referências Bibliográficas

Al-Hader, M., Rodzi, A., Sharif, A., and Ahmad, N. (2009). Smart city components
architicture. In Computational Intelligence, Modelling and Simulation, pages 93–97.
Andreini, F., Crisciani, F., Cicconetti, C., and Mambrini, R. (2011). A scalable architecture for geo-localized service access in smart cities. In Future Network & Mobile
Summit, pages 1–8. IEEE.
Anthopoulos, L. and Fitsilis, P. (2010). From digital to ubiquitous cities: Defining a
common architecture for urban development. In Proceedings of the 6th International
Conference on Intelligent Environments, pages 19–21.
Asimakopoulou, E. and Bessis, N. (2011). Buildings and crowds: Forming smart cities
for more effective disaster management. In Innovative Mobile and Internet Services in
Ubiquitous Computing (IMIS), 15th International Conference, pages 229–234. IEEE.
Attwood, A., Merabti, M., Fergus, P., and Abuelmaatti, O. (2011). Sccir: Smart cities
critical infrastructure response framework. In Developments in E-systems Engineering
(DeSE), 2011, pages 460–464. IEEE.
Atzori, L., Iera, A., and Morabito, G. (’2010’). The internet of things: A survey. Comput.
Netw., 54(15), 2787–2805.
Barbacci, M., Klein, M. H., Longstaff, T. A., and Weinstock, C. B. (1995). Quality
attributes. Technical report, Software Engineering Institute.
Bass, L. and Nord, R. (2012). Understanding the context of architecture evaluation
methods. In Joint Working IEEE/IFIP Conference on Software Architecture (WICSA)
and European Conference o n Software Architecture (ECSA), pages 277–281.
Bass, L., Clements, P., and Kazman, R. (1998). Software Architecture in Practice.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
Bird, S. (2013). Security and privacy: Why privacy matters. Science and Engineering
Ethics, 19(3), 669–671.
Blackstock, M., Kaviani, N., Lea, R., and Friday, A. (2010). Magic broker 2: An open
and extensible platform for the internet of things. In Internet of Things (IOT), 2010,
pages 1–8.

85

REFERÊNCIAS BIBLIOGRÁFICAS

Booch, G. (2010). Enterprise architecture and technical architecture. Software, IEEE,
27(2), 96–96.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996). Patternoriented software architecture: a system of patterns, vol.1. Wiley.
Caragliu, A., Del Bo, C., and Nijkamp, P. (2009). Smart cities in europe. Serie Research Memoranda 0048, VU University Amsterdam, Faculty of Economics, Business
Administration and Econometrics.
Chen, L., Ali Babar, M., and Ali, N. (2009). Variability management in software product
lines: a systematic review. In Proceedings of the 13th International Software Product
Line Conference, SPLC ’09, pages 81–90, Pittsburgh, PA, USA. Carnegie Mellon
University.
Clements, P. (2003). Documenting Software Architectures: Views and Beyond. SEI series
in software engineering. Addison-Wesley.
ComputerWorld (2013). Smart cities. http://www.computerworld.com.pt/
2013/07/04/dossier-smart-cities/. "[Online] Acessado em 05-Agosto2013".
da Silva, W. M., Alvaro, A., Tomas, G. H. R. P., Afonso, R. A., Dias, K. L., and Garcia,
V. C. (2013). Smart cities software architectures: A survey. In Proceedings of the 28th
Annual ACM Symposium on Applied Computing, SAC ’13, pages 1722–1727, New
York, NY, USA. ACM.
Dirks, S. and Keeling, M. (2009). A Vision of Smarter Cities. Centre for Economic
Development, Dublin, Ireland.
Dobbs, R. and Institute, M. G. (2011). Urban World: Mapping the Economic Power of
Cities. McKinsey Global Institute.
Droege, P. (1997). Intelligent Environments: Spatial Aspects of the Information Revolution. Elsevier Science.
Eger, J. M. (2011). Ten steps to becoming a smart community. Technical report, California
Institute for Smart Communities. "[Online] Acessado em 16-Outubro-2012".
Erbad, A., Blackstock, M., Friday, A., Lea, R., and Al-Muhtadi, J. (2008). Magic
broker: A middleware toolkit for interactive public displays. In 6th Annual IEEE
86

REFERÊNCIAS BIBLIOGRÁFICAS

International Conference on Pervasive Computing and Communications, PERCOM
’08, pages 509–514, Washington, DC, USA. IEEE Computer Society.
Fazio, M., Paone, M., Puliafito, A., and Villari, M. (2012). Heterogeneous sensors
become homogeneous things in smart cities. In Sixth International Conference on
Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), pages 775
–780.
Fels, S. (2010). Sustainable communities: where does communication fit in? In First
Interdisciplinary Workshop on Communication for Sustainable Communities, IWCSC
’10, pages 1:1–1:2, New York, NY, USA. ACM.
Filipponi, L., Vitaletti, A., Landi, G., Memeo, V., Laura, G., and Pucci, P. (2010). Smart
city: An event driven architecture for monitoring public spaces with heterogeneous
sensors. In 4th International Conference on Sensor Technologies and Applications,
pages 281–286, Washington, DC, USA. IEEE Computer Society.
Fowler, M. (2012). Patterns of Enterprise Application Architecture. Addison-Wesley
Signature Series (Fowler). Pearson Education.
Gama, K. and Donsez, D. (2010). A survey on approaches for addressing dependability
attributes in the osgi service platform. SIGSOFT Softw. Eng. Notes, 35(3), 1–8.
Garlan, D. and Shaw, M. (1994). An introduction to software architecture. Technical
report, School of Computer Science Carnegie Mellon University Pittsburgh, Pittsburgh,
PA, USA.
Giffinger, R. and Pichler-Milanovi´c, N. (2007). Smart Cities: Ranking of European
Medium-sized Cities. Centre of Regional Science, Vienna University of Technology.
Giusto, D., Iera, A., Morabito, G., and Atzori, L. (2010). The Internet of Things: 20th
Tyrrhenian Workshop on Digital Communications. Springer.
Hall, N. (2012). Are there really more mobile phones than toothbrushes?
//bit.ly/RInZMi. "[Online] Available: 1-August-2012".

http:

Haubensak, O. (2011). Smart cities and internet of things. Business Aspects of the
Internet of Things, page 33.
Heberty H. Amaral, D. C. C. and Fernandes, D. M. (2010). Estudo da relação entre as
classes sociais e o consumo de energia elétrica residencial do município de foz do

87

REFERÊNCIAS BIBLIOGRÁFICAS

iguaçu do estado do paraná. 8º congresso internacional sobre geração distribuída de
energia no meio rural.
Hernández-Muñoz, J. M., Vercher, J. B., Muñoz, L., Galache, J. A., Presser, M., Gómez,
L. A. H., and Pettersson, J. (2011). Smart cities at the forefront of the future internet.
In J. Domingue, A. Galis, A. Gavras, T. Zahariadis, and D. Lambert, editors, The future
internet, pages 447–462. Springer-Verlag, Berlin, Heidelberg.
Hoover, C. E., Sharma, R. K., Watson, B. J., Charles, S. K., Shah, A. J., Patel, C. D.,
Marwah, M., Christian, T. W., and Bash, C. E. (2010). Sustainable it ecosystems:
Enabling next-generation cities. Technical report, Hewlett-Packard Development
Company.
ISO/IEC (2001). ISO/IEC 9126. Software engineering – Product quality. ISO/IEC.
Jauregui-Ortiz, S., Siller, M., Ramos, F., and Scalabrin, E. (2012). Smart environmental architecture for node localization in a wireless sensor network. In Intelligent
Environments (IE), 2012 8th International Conference on, pages 222 –227.
Kanter, R., Litow, S., and School, H. B. (2009). Informed and Interconnected: A
Manifesto for Smarter Cities. Harvard Business School.
Kazman, R., Bass, L., Webb, M., and Abowd, G. (1994). Saam: a method for analyzing
the properties of software architectures. In Proceedings of the 16th international
conference on Software engineering, ICSE ’94, pages 81–90, Los Alamitos, CA, USA.
IEEE Computer Society Press.
Kazman, R., Barbacci, M., Klein, M., Jeromy Carriere, S., and Woods, S. (1999).
Experience with performing architecture tradeoff analysis. In Software Engineering,
1999. Proceedings of the 1999 International Conference on, pages 54–63.
Kazman, R., Kazman, R., Klein, M., Klein, M., Clements, P., Clements, P., Compton,
N. L., and Col, L. (2000). Atam: Method for architecture evaluation.
Kazman, R., Bass, L., Klein, M., Lattanze, T., and Northrop, L. (2005). A basis for
analyzing software architecture analysis methods. Software Quality Control, 13(4),
329–355.
Khurum, M. and Gorschek, T. (2009). A systematic review of domain analysis solutions
for product lines. Journal of Systems and Software, 82(12), 1982 – 2003.
88

REFERÊNCIAS BIBLIOGRÁFICAS

Kitchenham, B. and Charters, S. (2007). Guidelines for performing systematic literature
reviews in software engineering. Technical Report EBSE 2007-001, Keele University
and Durham University Joint Report.
Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., and Linkman, S.
(2009). Systematic literature reviews in software engineering - a systematic literature
review. Inf. Softw. Technol., 51(1), 7–15.
Klein, C. and Kaefer, G. (2008). From smart homes to smart cities: Opportunities
and challenges from an industrial perspective. In 8th Int. Conf. NEW2AN and 1st
Russian Conference on Smart Spaces, ruSMART on Next Generation Teletraffic and
Wired/Wireless Advanced Networking, pages 260–260, Berlin, Heidelberg. SpringerVerlag.
Komninos, N. (2002). Intelligent Cities: Innovation, Knowledge Systems and Digital
Spaces. Taylor & Francis.
Komninos, N. (2006). The architecture of intelligent clities: Integrating human, collective and artificial intelligence to enhance knowledge and innovation. In 2nd IET
International Conference on Intelligent Environments, volume 1, pages 13–20.
Krco, S. (2010). Smartsantander - a smart city example. ICT event 2010.
Kruchten, P. (1995). The 4+1 view model of architecture. IEEE Softw., 12(6), 42–50.
Kuper, A. (1995). The Social Science Encyclopedia. Routledge world reference series.
Taylor & Francis.
Lee, J., Baik, S., and Choonhwa Lee, C. (2011). Building an integrated service management platform for ubiquitous cities. Computer, 44, 56–63.
Li, X., Lu, R., Liang, X., Shen, X., Chen, J., and Lin, X. (2011). Smart community: an
internet of things application. IEEE Communications Magazine, 49(11), 68–75.
Maranzano, J., Rozsypal, S., Zimmerman, G., Warnken, G., Wirth, P., and Weiss, D. M.
(2005). Architecture reviews: practice and experience. Software, IEEE, 22(2), 34–43.
Marceau, J. (2008). Introduction: Innovation in the city and innovative cities. Innovation:
Management, Policy & Practice, 10(2-3), 136–145.

89

REFERÊNCIAS BIBLIOGRÁFICAS

Martín, J., Seepold, R., Madrid, N., Álvarez, J., Fernández-Montes, A., and Ortega, J.
(2009). A home e-health system for dependent people based on osgi. In N. Martínez Madrid and R. Seepold, editors, Intelligent Technical Systems, volume 38 of
Lecture Notes in Electrical Engineering, pages 117–130. Springer Netherlands.
Morvaj, B., Lugaric, L., and Krajcar, S. (2011). Demonstrating smart buildings and smart
grid features in a smart energy city. In Energetics (IYCE), 3rd International Youth
Conference, pages 1–8. IEEE.
Mostashari, A., Arnold, F., Maurer, M., and Wade, J. (2011). Citizens as sensors: The
cognitive city paradigm. In Emerging Technologies for a Smarter World (CEWIT),
2011 8th International Conference & Expo on, pages 1–5. IEEE.
Nam, T. and Pardo, T. (2011). Conceptualizing smart city with dimensions of technology,
people, and institutions. In Proceedings of the 12th Annual International Digital
Government Research Conference: Digital Government Innovation in Challenging
Times, pages 282–291. ACM.
Nations, U. (2007). World population prospects: The 2006 revision and world urbanization prospects. Technical report, United Nations, New York.
(NIC), N. I. C. (2008). Disruptive civil technologies - six technologies with potential
impacts on us interests out to 2025.
PlanIT, L. (2012). Cities in the cloud, a living planit introduction to future city technologies. In Living PlanIT. Living PlanIT.
Pollitt, M. M. (2007). An ad hoc review of digital forensic models. In Systematic
Approaches to Digital Forensic Engineering, 2007. SADFE 2007. Second International
Workshop on, pages 43–54.
Qun-li, S. and jie, L. (2008). Two software architecture evaluation methods based on
scenario. In Control and Decision Conference, 2008. CCDC 2008. Chinese, pages
2001–2004.
Roy, B. and Graham, T. N. (2008). Methods for evaluating software architecture: A
survey. School of Computing TR, 545, 82.
Sanchez, L., Galache, J., Gutierrez, V., Hernandez, J., Bernat, J., Gluhak, A., and
Garcia, T. (2011). Smartsantander: The meeting point between future internet research
90

REFERÊNCIAS BIBLIOGRÁFICAS

and experimentation and the smart cities. In Future Network & Mobile Summit
(FutureNetw), pages 1–8. IEEE.
Schumpeter, J. A. (1934). The Theory of Economic Development: An Inquiry Into
Profits, Capital, Credit, Interest, and the Business Cycle. Harvard Economic Studies.
Transaction Books.
Shanmugapriya, P. and Suresh, R. M. (2012). Software architecture evaluation methods a survey. International Journal of Computer Applications, 49(16), 19–26. Published
by Foundation of Computer Science, New York, USA.
Shao, C. (2011). An internet of things application with location perception based on
ims. In Third International Conference on Multimedia Information Networking and
Security (MINES), pages 163–166.
Sommerville, I. (2007). Software Engineering. Addison Wesley, 8 edition.
Spínola, R. O. and Travassos, G. H. (2012). Towards a framework to characterize
ubiquitous software projects. Inf. Softw. Technol., 54(7), 759–785.
Steventon, A. and Wright, S. (2005). Intelligent Spaces: The Application of Pervasive
ICT. Computer Communications and Networks. Springer.
Su, K., Li, J., and Fu, H. (2011). Smart city and the applications. In Electronics,
Communications and Control (ICECC), 2011 International Conference on, pages
1028–1031.
Tomas, G. H. R. P., da Silva, W. M., da Mota Silveira Neto, P. A., Garcia, V. C., Alvaro,
A., and Gama, K. (2013). Smart cities architectures - a systematic review. In ICEIS
(2), pages 410–417.
Tomordy, M. (2011). Smart cities - transforming the 21st century city via the creative use
of technology. Technical report, ARUPCorp.
Toppeta, D. (2010). The smart city vision: How innovation and ict can build
smart,“livable”, sustainable cities.
Touseau, L., Donsez, D., and Rudametkin, W. (2008). Towards a sla-based approach to
handle service disruptions. In Proceedings of the 2008 IEEE International Conference
on Services Computing - Volume 1, SCC ’08, pages 415–422, Washington, DC, USA.
IEEE Computer Society.

91

REFERÊNCIAS BIBLIOGRÁFICAS

Vega-Barbas, M., Casado-Mansilla, D., Valero, M., Lopez-de Ipina, D., Bravo, J., and
Florez, F. (2012). Smart spaces and smart objects interoperability architecture (s3oia).
In Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012
Sixth International Conference on, pages 725–730.
Wu, H., He, C., Liao, A., and Peng, S. (2011). A framework for integrating heterogeneous
spatial information and applications adaptively based on multi-agent and web service.
In Multimedia Information Networking and Security (MINES), 2011 Third International
Conference on, pages 253 –257.
Zygiaris, S. (2012). Smart city reference model: Assisting planners to conceptualize the
building of smart city innovation ecosystems. Journal of the Knowledge Economy,
pages 1–15.

92

Apêndice

93

A
Repositórios de busca na SLR

Tabela A.1 Repositórios de busca na SLR

Nome
IEEExplore
Science Direct
ACM Digital Library
Springer Link
CiteSeerX
Academia.edu
ISI Web of Science & Digital
World Intellectual Property
Organization (WIPO)
International Conference on
Computational Intelligence,
Modeling and Simulation
(IJCCI)
International Conference on
Intelligent Environments (IE)
Multimedia
Information
Networking and Security
(MINES)
Emerging Technologies for a
Smarter World (CEWIT)
International Conference on
Innovative Mobile and Internet Services in Ubiquitous
Computing (IMIS))

Tipo
Digital
Digital
Digital
Digital
Digital
Digital
Digital
Patente
Digital
Manual

URL
http://ieeexplore.ieee.org/
http://www.sciencedirect.com/
http://dl.acm.org/
http://link.springer.com/
http://citeseerx.ist.psu.edu/
http://www.academia.edu/
http://wokinfo.com/
http://www.wipo.int

Manual

http://www.intenv.org/

Manual

http://www.ieee-mines.org/

Manual

http://www.cewit.org/

Manual

http://voyager.ce.fit.ac.jp/conf/imis/2013/

http://www.ijcci.org/

95

B
Avaliação da Arquitetura de
Software (AS)

Figura B.1 Printscreen do formulário online utilizado pelos participantes para propor os cenários
de uso da AS

97

APÊNDICE B. AVALIAÇÃO DA Arquitetura de Software (AS)

Figura B.2 Printscreen da Parte 1/3 do formulário online para quantificar a adequação da AS
aos respectivos cenários

98

Figura B.3 Printscreen da Parte 2/3 do formulário online para quantificar a adequação da AS
aos respectivos cenários

99

APÊNDICE B. AVALIAÇÃO DA Arquitetura de Software (AS)

Figura B.4 Printscreen da Parte 3/3 do formulário online para quantificar a adequação da AS
aos respectivos cenários

100

Sign up to vote on this title
UsefulNot useful