Uma Arquitetura para Cidades Inteligentes Baseada Na Internet Das Coisas

Universidade Federal de Pernambuco
Centro de Informtica
Ps-graduao em Cincia da Computao
Uma Arquitetura de Software para

Cidades Inteligentes baseada na Internet
das Coisas
Gustavo Henrique Rodrigues Pinto Tomas
Dissertao de Mestrado
RECIFE
Fevereiro de 2014
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Gustavo Henrique Rodrigues Pinto Tomas
Uma Arquitetura de Software para Cidades Inteligentes

baseada na Internet das Coisas
Dissertao apresentada como requisito parcial para a obteno do ttulo de Mestre em Cincias da Computao, rea
de concentrao em Engenharia de Software pelo Programa
de Ps-Graduao em Cincias da Computao do Centro
de Informtica da Universidade Federal de Pernambuco.
Orientador: Vinicius Cardoso Garcia

Coorientador: Alexandre Alvaro
RECIFE, Fevereiro de 2014
minha famlia, por sempre me proporcionar totais

condies para a realizao dos meus estudos.
Aos meus irmos, que esta dissertao sirva de inspirao
para suas futuras decises 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 condies

para a realizao deste trabalho e, principalmente, por ter colocado em meu caminho
pessoas muito especiais que me ajudaram nesta aventura. Algumas destas pessoas sero
brevemente citadas a seguir:
Agradeo ao meu orientador Vinicius Cardoso Garcia, pela orientao, pelo esprito
acolhedor, pelo incentivo e pelas cobranas, totalmente necessrias, para me manter
o tempo todo focado no objetivo final. No 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 experincia de outras reas foram de suma importncia
para a concretizao da proposta. A coragem em se aventurar em uma rea de pesquisa
recente, na qual ningum possua muita experincia, fatalmente separa os vencedores dos
medrosos. Alm disso, a confiana 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 experincias antes mesmo de iniciar o mestrado. Certamente daquele dia em
diante, voc comeou a ser observado com olhos de admirao. Agradeo tambm
por ter apresentado a rea de pesquisa e, principalmente, as oportunidades que estavam
envolvidas. Os feedbacks do trabalho sempre contriburam de forma muito positivamente,
assim como os bate-papos, por mais viajados que fossem.
Ao grande irmo de considerao Welington Manoel da Silva, pelo tempo de convivncia, pelos aprendizados deste perodo e, principalmente, pela pacincia e bom humor
para enfrentarmos juntos toda aquela situao. Em relao parte tcnica, 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 caractersticas: compaixo com o prximo.
Agradeo a minha famlia pela compreenso 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, agradeo ao suporte que, por mais que no seja o que eles
gostariam de proporcionar, foi muito mais do que o suficiente para a minha formao,
tanto como homem quanto profissional. Ainda em relao famlia, agradeo aos meus
irmos Larissa e Jnior, por aturarem o meu mau humor quando as coisas pareciam estar
desabando. Sinceramente, espero que este novo objetivo alcanado na minha vida sirva
de exemplo para que eles acreditem nos respectivos potenciais e, principalmente, na
vii
capacidade de atingir seus objetivos.

No poderia de deixar de fora a minha amiga, companheira, revisora de textos em
ingls e portugus: Crisley. A sua compaixo e o seu jeitinho singular foram as foras
que eu precisava nos momentos de maiores dificuldades. Olhando para trs, no consigo
enxergar outra forma de enfrentar os meus desafios sem o seu positivismo. A compreenso
e a pacincia para enfrentar 9 meses distncia certamente comprovaram que somos
iguais ao amanhecer: independente do que acontea, sempre estaremos juntos para
enfrentar qualquer tipo de escurido.
Ao Centro de Estudos e Sistemas Avanados do Recife (C.E.S.A.R) pela coragem
e confiana 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, compreenso e, principalmente,
por no aliviarem as minhas tarefas, o que contribuiu muito para a minha formao
acadmica e profissional. Espero que eles tenham a conscincia 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 atribuies. Considero a forma como a
situao foi conduzida um exemplo a ser seguido na minha vida.
Finalmente, gostaria de agradecer a todos que de alguma forma, direta ou indiretamente, contriburam para a realizao deste trabalho.
viii
Resumo
De acordo com recentes pesquisas, a populao mundial esta crescendo de forma desproporcional aos recursos necessrios para a vida humana. Cada vez mais a quantidade
de pessoas vivendo nas reas urbanas aumenta, devido diversos fatores, como as
oportunidades que so geradas nestes grandes centros.
Este desenfreado crescimento populacional, principalmente nas reas urbanas, alm de
outros fatores como m governana, 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, sade e educao, evidenciados, rotineiramente, pela
mdia em geral.
Neste contexto, o conceito de Cidade Inteligente (CI) visa mitigar estes problemas a
fim de aumentar a qualidade de vida dos cidados. Para tal, uma importante ferramenta
para a implementao de uma CI a Internet of Things (Internet das Coisas) (IoT), na
qual diversos objetos so combinados para atingir um objetivo em comum como, fornecer
informaes do fluxo de veculos de uma cidade.
Porm, para que este cenrio seja de fato consolidado, necessita-se de uma Arquitetura
de Software (AS) capaz de integrar e combinar as diferentes tecnologias e dados que
compem os servios urbanos.
Na literatura pode-se encontrar vrias Arquiteturas de Software (ASs) para CI, inclusive com apoio de grandes empresas. Porm, estas ASs visam atender apenas um
determinado servio urbano com uma aplicao especfica, o que no caracteriza de fato
uma implementao de CI.
Motivado por estes desafios, esta dissertao apresenta a especificao, o projeto
e a avaliao de uma AS para CI que permite a integrao com IoT, baseado no conjunto de requisitos extrados das solues existentes. Adicionalmente, so discutidos os
resultados obtidos, os problemas encontrados, e as direes 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
Sumrio
Lista de Figuras
xvii
Lista de Tabelas
xix
Lista de Acrnimos
xxi
Introduo
1.1
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . .
1.3
Viso Geral da Soluo Proposta . . . . . . . . . . . . . . . . . . . . .
1.3.1
Viso Geral da Arquitetura de Software (AS) . . . . . . . . . .
1.4
Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Principais Contribuies . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . .
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
Integrao de Cidade Inteligente (CI) com Internet of Things (Internet

das Coisas) (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .
15
2.4
3
Reviso da Literatura de Arquiteturas de Software para Cidades Inteligentes

17
3.1
Reviso Sistemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.1
Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . .
19
Estratgia de Busca e Fontes de Dados . . . . . . . . . . . . . .
19
Seleo das Abordagens . . . . . . . . . . . . . . . . . . . . .
21
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Abordagens Resultantes . . . . . . . . . . . . . . . . . . . . .
23
Reviso Exploratria . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1
Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . .
26
3.2.2
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3
Consolidao das Abordagens Encontradas . . . . . . . . . . . . . . .
30
3.4
Requisitos para uma Arquitetura de Software para Cidades Inteligentes .
32
3.1.2
3.2
xiii
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 Segurana dos dados . . . . . . . . . . . . . . . .
35
3.4.7
Geolocalizao dos sensores . . . . . . . . . . . . . . . . . . .
35
3.4.8
Composio de Dados Urbanos . . . . . . . . . . . . . . . . .
36
3.4.9
Histrico de dados . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4.10 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4.11 Sensoriamento e Processamento Distribudo . . . . . . . . . . .
37
3.4.12 Flexibilidade/Extensibilidade . . . . . . . . . . . . . . . . . .
38
3.5
Sumrio dos Requisitos para Cidades Inteligentes . . . . . . . . . . . .
38
3.6
Discusso do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.7
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
Viso Lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.3.1
Mdulo de Acesso e Comunicao (MAC) . . . . . . . . . . .
45
4.3.2
Mdulo de Gerenciamento de Recursos (MGR) . . . . . . . . .
46
4.3.3
Mdulo de Gerenciamento e Distribuio de Dados (MGDD) .
47
4.3.4
Mdulo de Persistncia de Dados (MPD) . . . . . . . . . . . .
48
4.3.5
Mapeamento Requisito x Mdulo . . . . . . . . . . . . . . . .
48
4.3.6
Operaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Consumidor: Recurso receber dados . . . . . . . . . . . . . . .
49
Produtor: Fornecer dado . . . . . . . . . . . . . . . . . . . . .
50
Compor um dado urbano . . . . . . . . . . . . . . . . . . . . .
50
Viso de Execuo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.4.1
Mdulo de Acesso e Comunicao (MAC) . . . . . . . . . . .
52
4.4.2
Mdulo de Gerenciamento de Recursos (MGR) . . . . . . . . .
53
4.4.3
Mdulo de Gerenciamento e Distribuio de Dados (MGDD) .
53
4.4.4
Mdulo de Persistncia de Dados (MPD) . . . . . . . . . . . .
54
Viso de Implementao . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.4
4.5
xiv
4.6
Viso Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.7
Viso Componente Conector . . . . . . . . . . . . . . . . . . . . . . .
57
4.8
Viso de Dependncias . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.9
Cenrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.9.1
Desenvolvimento de aplicaes mveis . . . . . . . . . . . . .
59
4.9.2
Emitir Alertas com Informaes de Trnsito . . . . . . . . . . .
59
4.9.3
Definio de Estratgia Efetiva de Investimento de Recursos . .
60
4.9.4
Predio de Catastrfes em reas de Riscos . . . . . . . . . . .
60
4.10 Discusso do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.11 Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .
61
Avaliao da Arquitetura de Software
63
5.1
Mtodos de Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.1.1
Mtodos Analisados . . . . . . . . . . . . . . . . . . . . . . .
64
5.1.2
Descrio dos mtodos restantes . . . . . . . . . . . . . . . . .
65
Adaptao dos mtodos de avaliao . . . . . . . . . . . . . . . . . . .
66
5.2.1
Definio do mtodo de avaliao . . . . . . . . . . . . . . . .
66
5.2.2
Equipe de Avaliao . . . . . . . . . . . . . . . . . . . . . . .
67
5.2.3
Descrio do Mtodo de Avaliao . . . . . . . . . . . . . . .
67
Processo de Avaliao Executado . . . . . . . . . . . . . . . . . . . . .
69
5.3.1
Primeira Reunio . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.3.2
Segunda Reunio . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.3.3
Terceira Reunio . . . . . . . . . . . . . . . . . . . . . . . . .
73
Resultados da Avaliao da Arquitetura . . . . . . . . . . . . . . . . .
74
5.4.1
Resultados da Avaliao dos Cenrios . . . . . . . . . . . . . .
75
5.4.2
Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5
Ameaas Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.6
78
5.2
5.3
5.4
Concluso
79
6.1
Principais Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.2
Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . .
80
6.3
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6.4
Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Referncias Bibliogrficas
84
xv
Apndice
93
A Repositrios de busca na Systematic Literature Review (Reviso Sistemtica

da Liteturatura) (SLR)
95
B Avaliao da Arquitetura de Software (AS)
xvi
97
Lista de Figuras
1.1
Arquitetura de Software (AS) da soluo proposta . . . . . . . . . . . .
3.1
3.2
Estratgia 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
Integrao das vises do modelo 4+1 com as vises definidas pelo SEI
Viso lgica da Arquitetura de Software (AS) proposta . . . . . . . . .
Abstrao da operao de um recurso receber dados . . . . . . . . . . .
Abstrao da operao de um recurso fornecer dado . . . . . . . . . . .
Abstrao da operao de um recurso fornecer um novo tipo de dado . .
Operao de composio de dados urbanos . . . . . . . . . . . . . . .
Viso de Implementao . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de Componente Conector . . . . . . . . . . . . . . . . . . .
Diagrama de Dependncias . . . . . . . . . . . . . . . . . . . . . . . .
44
45
49
50
51
52
55
57
58
5.1
Resultado da avaliao dos cenrios . . . . . . . . . . . . . . . . . . .
75
B.1 Printscreen do formulrio online utilizado pelos participantes para propor

os cenrios de uso da AS . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.2 Printscreen da Parte 1/3 do formulrio online para quantificar a adequao
da AS aos respectivos cenrios . . . . . . . . . . . . . . . . . . . . . . 98
xvii
Lista de Tabelas
3.1
3.2
3.3
3.4
Quantidade de abordagens por fonte de pesquisa

Abordagens resultantes por ordem cronolgica
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 Mdulo . . . . . . . . . . . . . . . . . .
Resumo da quantidade de processos e threads em tempo de execuo
Requisitos fsicos de utilizao da arquitetura . . . . . . . . . . . . .
.
.
.
.
42
49
53
57
5.1
5.2
5.3
5.4
5.5
5.6
Mtodos de Avaliao Vs Atributos de Qualidade

Mtodos de Avaliao Vs Objetivo . . . . . . . .
Etapas do mtodo adaptado . . . . . . . . . . . .
Expertises da equipe de avaliao . . . . . . . .
Priorizao dos Atributos de Qualidade . . . . .
Cenrios resultantes de acordo com a relevncia .
.
.
.
.
.
.
65
65
67
68
71
74
A.1 Repositrios de busca na SLR . . . . . . . . . . . . . . . . . . . . . .
95
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xix
Lista de Acrnimos
AS
Arquitetura de Software
DHT
Distributed Hash Table
IoT
Internet of Things (Internet das Coisas)
CI
Cidade Inteligente
SLR
Systematic Literature Review (Reviso Sistemtica da Liteturatura)
SOA
Arquitetura Orientada a Servios
TIC
Tecnologia da Informao e Comunicao
xxi
1
Introduo
Pequenas oportunidades so muitas vezes o comeo de grandes

empreendimentos.
DEMSTENES
1.1
Motivao
De acordo com relatrio divulgado pela UNESCO (Nations, 2007), por volta de 1950,
30% da populao 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%. Alm disso, 10% da populao mundial vive nas 30
principais metrpoles (Dobbs and Institute, 2011). No cenrio nacional, segundo a
pesquisa realizada pelo Instituto Brasileiro de Geografia e Estatstica (IBGE), publicada
no Dirio Oficial da Unio 1 , em julho de 2012 o Brasil chegou a 193.946.886 habitantes,
que representa um aumento de aproximadamente 1,65% em relao ao ano de 2010.
A expanso das cidades enfrenta uma srie de desafios. Embora as cidades ocupam
menos de 2% da massa terrestre, os residentes urbanos consomem mais de trs quartos
dos recursos naturais do mundo e so os principais responsveis pela emisso de gases
do efeito estufa (Marceau, 2008). Problemas decorrentes da rpida urbanizao indicam
uma perda de funcionalidades bsicas para ser um lugar habitvel: por exemplo, a
dificuldade na gesto de resduos, a escassez de recursos naturais, a poluio do ar, as
doenas humanas, o intenso trfego de veculos e deteriorao e envelhecimento das
infraestruturas (Krco, 2010).
1 http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=
2204
CAPTULO 1. INTRODUO
Algumas iniciativas isoladas esto sendo desenvolvidas para mitigar alguns dos
problemas urbanos (Nam and Pardo, 2011). As iniciativas vo de aplicativos como
Waze2 , um servio que combina geolocalizao no celular com indicaes do fluxo e
problemas de trnsito via smartphones, at governamentais, como o Centro de Operaes
da Prefeitura do Rio de Janeiro3 , sistema que integra informaes a respeito dos diferentes
servios pblicos oferecidos pela cidade.
Porm, para de fato estabelecer uma Cidade Inteligente (CI) necessrio que estas
iniciativas estejam integradas em uma mesma Arquitetura de Software (AS), seja para
compartilhar informaes, seja para facilitar a definio da estratgia de atuao (Filipponi
et al., 2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011;
Hernndez-Muoz et al., 2011). Da mesma forma, necessita-se de uma AS que permita a
criao de novas iniciativas para solucionar os problemas dos cidados (Filipponi et al.,
2010; Haubensak, 2011; Sanchez et al., 2011), como por exemplo, o monitoramento da
qualidade do transporte coletivo.
Alm disso, este trabalho motivado pela vasta gama de sensores, atuadores, pessoas,
sistemas, drivers e qualquer outro componente capaz de interagir com os servios urbanos.
Ao aplicar este conjunto de componentes nos contextos urbanos, vrios desafios so
gerados para integr-los e obter o melhor de cada componente.
Para este e outros cenrios semelhantes, uma AS para CI pode ajudar a integrar esses
diversos componentes. Para tal, a AS deve ser totalmente plugvel e expansvel, do ponto
de vista dos protocolos de comunicao implementados.
1.2
Estabelecimento do Problema
Motivado pelas questes apresentadas na Seo 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 solues com base em
Internet of Things (Internet das Coisas) (IoT), independente das especificaes de
cada tecnologia e caractersticas fsicas das cidades. Alm disto, este trabalho visa
prover uma implementao de referncia desta AS.
2 https://www.waze.com/
3 http://www.rio.rj.gov.br/web/corio
1.3. VISO GERAL DA SOLUO PROPOSTA
1.3
Viso Geral da Soluo Proposta
A fim de atingir os objetivos deste trabalho, estabelecidos na Seo anterior, foi realizado
um estudo das Arquiteturas de Software (ASs) para CI baseada em IoT tanto na academia
quanto na indstria, por meio de dois mtodos de reviso literria: Reviso Exploratria e
Reviso Sistemtica. Este estudo teve como finalidade identificar as tcnicas empregadas
nestas solues e se existia a necessidade da criao de um novo padro arquitetural para
este contexto.
A partir dos objetivos das abordagens encontradas nestes dois mtodos de reviso, um
conjunto de requisitos ao qual uma nova AS para CI deve atender foi estabelecido. Em
seguida, a AS da soluo foi proposta visando atingir um sub-conjunto destes requisitos,
que representa os requisitos fundamentais. Por fim, a AS foi submetida um processo
de avaliao formal adaptado do SAAM (Kazman et al., 1994) e ATAM (Kazman et al.,
1999, 2000).
1.3.1
Viso Geral da Arquitetura de Software (AS)
A AS consiste em mdulos que implementam um conjunto de requisitos fundamentais

para o contexto de CI. Estes requisitos so implementados a partir da utilizao de
padres arquiteturais j conhecidos e utilizados em outros tipos de ASs de software,
como publisher-subscriber. A Figura 1.1 ilustra a AS proposta.
Os mdulos da AS so: Mdulo de Acesso e Comunicao (MAC), Mdulo de
Gerenciamento de Recursos (MGR), Mdulo de Gerenciamento e Distribuio de Dados (MGDD) e Mdulo de Persistncia de Dados (MPD). Estes mdulos fornecem as
funcionalidades essenciais utilizadas pelos diferentes tipos de usurios do sistema.
O MAC representa o ponto de entrada dos usurios, aplicaes ou at mesmo servios
externos. O MAC prov todos os mecanismos necessrios para o acesso e a comunicao
com a AS, tanto para envio quanto para recebimento de informaes. Por sua vez, o
MGR visa gerenciar as informaes relativas aos diferentes tipos de recursos disponveis
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 computao
interna para os agentes externos. O ltimo mdulo (MPD), como o prprio nome j
identifica, possui a responsabilidade de armazenar os dados oriundos dos diferentes nveis
da AS. Estes dados, nos mais variados estgios da AS, so importantes para a predio
de acontecimentos futuros, a partir do histrico de dados.
Os detalhes da AS sero descritos no Captulo 4.
CAPTULO 1. INTRODUO
Mdulo de
Acesso e
Comunicao
(MAC)
REST
Mdulo de
Persistncia 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
Configurao de recursos
Mdulo de
Gerenciamento
de Recursos
(MGR)
DHT Canal
de
dados
...
...
...
....
Canal 2
Canal 1
...
...
...
Canal 3
Mdulo de
Gerenciamento
e Distribuio
de Dados
(MGDD)
...
Figura 1.1 Arquitetura de Software (AS) da soluo proposta
1.4
Escopo Negativo
Como a soluo proposta por esta dissertao faz parte de um contexto mais amplo, um
conjunto de aspectos relacionados no ser tratado no escopo deste trabalho.
Adicionalmente, os requisitos tratados na soluo no 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 construo e/ou adaptao de uma AS para CI que combine tecnologias de IoT, tanto
para coletar informaes quanto para atuar no ambiente.
Os seguintes aspectos no fazem parte do escopo deste trabalho:
Modelo de Negcio: Aspectos relacionados ao suporte a modelos de negcio e
estratgias de monetizao e cobrana desta proposta no sero tratados neste
trabalho;
Anlises de big data: Apesar da grande quantidade de dados trafegados na AS,
este trabalho no faz nenhum tipo de anlise de big data, apenas permite que um
servio que o faa seja criado;
Semntica dos Dados: Este trabalho no faz distino entre semntica dos dados,
uma vez que qualquer tipo de dado relacionado cidade pode trafegar na AS.
4
1.5. PRINCIPAIS CONTRIBUIES
1.5
Principais Contribuies
Como resultado do trabalho apresentado nesta dissertao, as seguintes contribuies

podem ser destacadas:
Estado de arte de AS para CI: A partir das revises da literatura executadas foi
possvel apresentar um resumo a respeito do estado da arte de CI no Brasil e no
mundo, a partir da descrio de algumas abordagens com ou sem apoio dos setores
estatais e privados;
Comparativo entre dois mtodos de reviso literria: A partir dos resultados
obtidos nas duas avaliaes executadas (Reviso Sistemtica e Reviso Exploratrio) foi possvel estabelecer um comparativo em relao a eficincia de cada mtodo,
principalmente relacionado questes de pesquisa com relevncia acadmica e
mercadolgica;
Requisitos de uma AS para CI: Um conjunto de requisitos essencias que uma AS
para CI deve atender foi estabelecido, a partir da anlise das solues 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;
Implementao inicial: Baseado na proposta desta dissertao, uma implementao inicial foi realizada e disponibilizado em domnio pblico. Esta implementao
serve de guia para a utilizao desta proposta em qualquer cidade;
Adaptao de dois mtodos de avaliao: No foi encontrado na literatura nenhum mtodo de avaliao que fosse totalmente compatvel com as peculiaridades
do contexto deste trabalho. Logo, foi proposta e utilizada uma adaptao de dois
mtodos de avaliao: SAAM e ATAM. Esta adaptao foi aplicada, na qual se
pde comprovar a sua utilidade. Este mtodo pode ser empregado em qualquer
contexto semelhante, principalmente se a equipe esta geograficamente distribuda.
Alm das contribuies finais listadas acima, alguns resultados intermedirios deste
trabalho esto 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.
CAPTULO 1. INTRODUO
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 Simpsio Brasileiro de Sistemas de Informao (SBSI), 2013,
Joo Pessoa. Anais do III Simpsio Brasileiro de Sistemas de Informao. Curitiba,
PR, novembro de 2006. Porto Alegre: Sociedade Brasileira de Computao, 2013.
v. 1. p. 511-516.
1.6
Organizao da Dissertao
O restante desta dissertao est organizado conforme se segue:

Captulo 2: contextualiza a temtica de CI e IoT, alm de esclarecer a interao
entre as duas reas de pesquisa;
Captulo 3: apresenta a reviso bibliogrfica sobre AS para CI que combinam
tecnologias IoT, com o objetivo de identificar as principais solues existentes na
academia e na indstria e estabelecer um conjunto de requisitos fundamentais que
uma nova AS deve atender;
6
1.6. ORGANIZAO DA DISSERTAO
Captulo 4: descreve em detalhes a proposta da AS, ressaltando, principalmente,

como cada requisito implementado;
Captulo 5: discute o processo de avaliao de AS realizado, totalmente remoto,
durante o desenvolvimento da soluo, e apresenta os principais resultados;
Captulo 6: conclui esta dissertao por meio de de um resumo das principais contribuies desta pesquisa e discusses a respeito de alguns trabalhos relacionados.
Por fim, so apresentadas algumas observaes finais e direes para pesquisas
futuras.
2
Cidades Inteligentes e Internet das Coisas
A alegria que se tem em pensar e aprender faz-nos pensar e aprender

ainda mais.
ARISTTELES
As cidades so sistemas complexos que concentram um grande conjunto de servios e

de infraestruturas e consomem um crescente volume de recursos e de energia, com um significativo impacto a nvel econmico, ambiental e de qualidade de vida (ComputerWorld,
2013).
A literatura apresenta diversas definies do termo Cidade, porm a mais aceita
descrita em Kuper (1995) como um povoado relativamente grande e permanente.
Geralmente, uma cidade possui alta densidade populacional e os cidados interagem
com indstrias, comrcios e servios. No quesito operacional, cidades so baseadas em
um conjunto de servios urbanos bsicos: energia, gua, transporte, infraestrutura de
informao e comunicao, mercado, sade pblica e saneamento pblico (Morvaj et al.,
2011).
Este conjunto de servios urbanos bsicos justamente onde se localizam os principais problemas das cidades (Morvaj et al., 2011). Alm disso, com o crescimento
populacional supracitado no Captulo anterior e o envelhecimento das infraestrturas,
surge a necessidade de aprimorar tcnicas para otimizar a utilizao destes servios (Krco,
2010). Simultaneamente, necessita-se de um sistema no qual os demais servios possam
ser criados e/ou otimizados para suprir as necessidades dos cidados.
Estes fatores demonstram os grandes desafios para os gestores das cidades. Problemas
relacionados ao trfego, segurana, consumo de gua e energia, dentre outros, tm sido
cada vez mais difceis de serem administrados. A saber:
CAPTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS
Segurana: Os altos ndices de criminalidade so grandes preocupaes da sociedade.

Assaltos, trfico de drogas e crime organizado so manchetes na TV e nos jornais todos
os dias e so uma dura realidade das cidades brasileiras. Catstrofes como enchentes
so um problema de defesa civil devido a ocupao desordenada de encostas e morros,
ameaando diversas comunidades em cidades por todo o Brasil. Segundo o Mapa das
Ocorrncias Registradas pelas Polcias Civis (Janeiro de 2004 a Dezembro de 2005)1 ,
desenvolvido pela Secretaria Nacional de Segurana Pblica, 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 eficincia questionveis
na maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e as
crescentes facilidades no financiamento de veculos, a quantidade de motocicletas e
automveis no pas cada vez maior. A infraestrutura viria no acompanha este
crescimento da frota nacional e o trnsito um problema em muitas cidades. Solues
paliativas, como rodzio de veculos, apenas atenuam o crescimento do problema do
trfego, quando, na verdade, uma otimizao no sistema de transportes coletivos fazse necessria. Dois exemplos da situao do transporte coletivo no Brasil podem ser
encontrados na Pesquisa de Mobilidade Da Regio Metropolitana de So Paulo2 : i) entre
2002 e 2012, a frota de veculos particulares cresceu 18%; ii) no mesmo perodo, a taxa
de motorizao passou de 184 para 212 automveis particulares por 1.000 habitantes;
Sade: No Brasil, a infraestrutura do sistema de sade insuficiente para atender
demanda. Vrios hospitais pblicos possuem atendimento deficitrio, forando pacientes
a aguardarem em longas filas de espera e o mesmo problema vem assolando pacientes do
sistema privado com planos de sade. De acordo com a pesquisa da Assistncia MdicoSanitria(AMS)3 realizada em 2002 pelo IBGE, houve uma variao na quantidade de
leitos disponveis no Brasil, de 3,65 leitos por 1 000 habitantes em 1992, para 2,70 em
2002, uma reduo de quase 25%;
Uso sustentvel de recursos: O aumento do poder aquisitivo das classes mais pobres
gerou uma elevao no consumo de energia eltrica, mas classes mdia e alta ainda
representam a maior fatia do consumo de energia eltrica, pelo padro de consumo e
conforto que envolve diversos tipos de eletroeletrnicos. Em Foz do Iguau, por exemplo,
7% das famlias correspondem a mais de 65% do consumo de energia eltrica 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);

Gesto de resduos: O lixo tem se tornado um grande problema para cidades de
pases em desenvolvimento. Enquanto cidades de pases desenvolvidos pem em prtica
diversas solues de tratamento de lixo orgnico e de reaproveitamento de materiais
reciclveis, cidades de pases como o Brasil no conseguem definir ou executar prticas
de reciclagem, salvo raras excees. Por exemplo, de acordo com a Associao Brasileira
de Empresas de Limpeza Pblica e Resduos Especiais (ABRELPE)4 , em 2012 cerca
de 60% dos municpios registraram alguma iniciativa de coleta seletiva. Embora seja
expressiva a quantidade de municpios com iniciativas de coleta seletiva, muitas vezes
estas atividades resumem-se disponibilizao de pontos de entrega voluntria ou convnios com cooperativas de catadores, que no abrangem a totalidade do territrio ou da
populao do municpio.
Apesar da evidente necessidade de cidades cada vez mais inteligente e a ateno que
a academia tem destinado para o tema, ainda no h um consenso a respeito da definio
do conceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado para
empreg-lo (Giffinger and Pichler-Milanovic, 2007; Caragliu et al., 2009; Li et al., 2011).
Logo, a Seo 2.1 visa clarificar a definio de CI a ser utilizada durante este trabalho.
Um paradigma que vem sendo utilizado em diversas abordagens para CI a utilizao
de IoT como ferramenta para captar dados e atuar sobre os servios urbanos. Logo, a
Seo 2.2 visa contextualizar a IoT, a partir de alguns exemplos de aplicaes.
Por sua vez, a Seo 2.3 inicialmente pontua alguns dos principais desafios, principalmente, nas cidades brasileiras. Em seguida, apresenta-se a integrao existente entre
estas duas reas de pesquisa e alguns exemplos de utilizao desta integrao para mitigar
alguma deficincia urbana.
Por fim, a Seo 2.4 consolida as principais contribuies deste Captulo.
2.1
Conceito de Cidade Inteligente (CI)
A literatura apresenta algumas definies para o termo CI, porm ainda no h um

consenso a respeito deste conceito. A seguir, so apresentadas as principais definies
descritas na literatura e a definio que ser utilizada no decorrer deste trabalho.
Em Giffinger and Pichler-Milanovic (2007) ilustrada uma srie de diferentes ambientes na qual o termo foi utilizado. Por exemplo, a definio de CI, quando associada com
economia, uma cidade com indstria inteligente, na qual so empregadas tecnologias
de ltima gerao para aprimorar os aspectos financeiros e econmicos. No aspecto
4 http://a3p.jbrj.gov.br/pdf/ABRELPE%20%20Panorama2012.pdf
11
educao, Giffinger et. al. caracteriza CI como o nvel de escolaridade dos cidados.
Alm disso, de acordo com Giffinger et. al., uma CI tambm pode ser mensurada a partir
do relacionamento entre o governo e os cidados e a utilizao de modernas tecnologias,
no somente relacionada Tecnologia da Informao e Comunicao (TIC), mas tambm
outros domnios, como transporte e logstica.
Por fim, Giffinger et. al. define seis caractersticas 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
caractersticas, construda a partir da combinao inteligente de atividades independentes,
auto-decisivas e em prol dos cidados. Esta definio, oriunda dos resultados do projeto
European Smart Cities (Caragliu et al., 2009), a mais bem conhecida e com maior
aceitao na literatura (Hernndez-Muoz et al., 2011), pois permite quantificar o nvel
de inteligncia das cidades. Por exemplo, inovao faz parte do eixo smart economy e
calculado pela quantidade de patentes por habitantes (Haubensak, 2011).
Apesar dessa definio ser considerada a mais abrangente, cada trabalho adota uma
definio 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 informaes relevantes no ncleo
dos sistemas das cidades. Ao mesmo tempo, uma CI pode tomar decises inteligentes
para diferentes tipos de necessidades, incluindo aspectos dirios, proteo ambiental,
segurana pblica, servios 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 fsica, para prover convenincias aos cidados,
como: eficincia energtica; 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 decises e a utilizao de recursos de
forma eficiente. Logo, a CI no 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 fsicos em que
as TICs e os sistemas de sensoriamento so transparentes para os cidados, porm
desepenham papel fundamental para garantir o funcionamento operacional da cidade.
Uma CI tambm definida como um territrio no qual as TICs propiciam inovaes
em diversos segmentos, combinando a criatividade e o talento individual em prol da
populao da cidade, instituies locais e orgos governamentais (Komninos, 2002;
Schumpeter, 1934).
Em ComputerWorld (2013) defende-se que CI no um conceito tecnolgico, mas
12
2.1. CONCEITO DE Cidade Inteligente (CI)
um conceito sociotcnico. Integra-se trs vertentes essenciais: a tecnologia, as pessoas e

as instituies. Uma CI tem que centrar a sua atuao nos cidados e nas comunidades
onde vivem e trabalham.
Em relao aos aspectos governamentais, Toppeta (2010) acredita que uma CI deve
identificar e otimizar os processos governamentais, mitigando a burocracia que envolve o
processso de inovao de solues e gerenciamento de tcnicas sustentveis.
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 (Fundao
Mundial para Cidades Inteligentes)5 define que uma CI uma comunidade com avanos
significativos em TICs que transformam o cotidiano dos cidados, melhorando os aspectos
relacionados ao trabalho e ao lazer de forma incremental e transparente (Eger, 2011).
Alm da falta de consenso quanto ao termo CI, existem outros termos que so
comumente aplicados aos mesmos contextos, como cidades virtuais, cidades digitais,
cidade informatizada, cidade eletrnica (Komninos, 2006). Ao generalizar esse
conceito aos ambientes inteligentes que se relacionam com servios urbanos, vrios
sinnimos de CI so frequentemente empregados, como information city, wired city,
telecity, knowledge-based city, electronic communities, electronic community
spaces, flexicity, teletopia, cyberville (Droege, 1997).
Essa ausncia de consenso devido aos mltiplos movimentos cientficos, tecnolgicos e sociais que compem o contexto de uma cidade (Komninos, 2006). Em cada
disciplina, existe uma srie de problemas que afetam diretamente diversos servios
existentes, como transporte, segurana, proviso/consumo de energia eltrica e gua,
saneamento bsico, utilizao de recursos naturais, controle de catstrofes, principalmente no que tange a gesto individual e influncia mtua, at como planejar e otimizar a
utilizao em resposta a diferentes cenrios.
Neste trabalho, uma combinao destas principais definies com diferentes vieses
considerada:
Cidade Inteligente (CI) a combinao de Tecnologia da Informao e

Comunicao (TIC) com todos os aspectos que compem uma cidade, desde aos
aspectos fsicos at governamentais, combinados de forma a satisfazer s necessidades
dos cidados .
5 http://www.smartcommunities.org
13
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),
tambm conhecida como Internet dos Objetos, um paradigma que vem crescendo no
cenrio moderno de telecomunicaes sem fio. A idia bsica deste conceito a presena
de um conjunto de objetos (things) - como Radio-Frequency IDentification (RFID),
sensores, atuadores, telefones celulares - que, por meio de mecanismos de endereamento
nico (como a Internet), so capazes de interagir e cooperar uns com os outros para
alcanar objetivos em comum.
Sem dvida, o principal impacto da IoT ser sobre alguns aspectos do cotidiano e
comportamento das pessoas (Atzori et al., 2010). Por exemplo, j existem aplicaes IoT
que permitem o monitoramento de atividades fsicas6 e controle de medicamentos de uso
contnuo7 . Outro conjunto de aplicaes que interferem no cotidiano das pessoas so as
voltadas para o ambiente domstico. Por exemplo, ligar e desligar aparelhos domsticos
distncia8 , medir a temperatura da casa9 e at mesmo monitorar o jardim10 j so
realidades.
Ao considerar a diversidade de aplicaes ilustradas acima, pode-se inferir o motivo
pelo qual IoT includa pelo Conselho Nacional de Inteligncia dos EUA (NIC) na lista
das seis tecnologias civis com impactos potenciais sobre o poder nacional dos EUA (,
NIC). Alm disso, o NIC prev que at 2025 os objetos estaro presentes em todas as
coisas cotidianas, como documentos, embalagens de alimentos e mveis.
A partir da evidente gama de possibilidade oriundas da IoT, torna-se natural associlas ao contexto de CI. Em uma CI, para o funcionamento adequado dos servios inteligentes necessria a utilizao de tecnologias que sejam capazes de captar e distribuir
estas informaes (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. INTEGRAO DE Cidade Inteligente (CI) COM IOT! (IOT!)
2.3
Integrao 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 informaes com TIC, a fim de mitigar estes problemas e promover melhores
condies de vida aos cidados. Neste sentido, as tecnologias IoT tambm podem ser
integradas como ferramentas para monitorar os eventos de um ambiente, atuar a fim de
conter uma situao emergencial ou, at mesmo, propagar uma informao relevante.
Os cenrios da utilizao de TICs e IoT para esta finalidade so os mais variados.
Um exemplo o monitoramento do trnsito em estradas e rodovias. Este monitoramento,
a partir de sensores espalhados pelas vias, poderia alimentar sistemas de informao
capazes de gerar rotas em tempo real, redistribuindo os veculos, aumentando a fluidez
das vias. Esta redistribuio poderia ser feita ao enviar informaes para os dispositivos
GPS dos veculos ou at mesmo por um conjunto de painis indicativos para orientar
os motoristas sobre a melhor rota. A comunicao e a troca de informaes entre estes
diferentes objetos constituem um cenrio de uso clssico de IoT.
Outro exemplo da utilizao macia de TIC e IoT o controle do consumo residencial
de energia eltrica a partir de eletrodomsticos habilitados a otimizar seu funcionamento
de acordo com os hbitos e necessidades de seus moradores. Alm disso, estes eletrodomsticos, atuando em uma rede de objetos, podem trocar informaes a fim de otimizar
tarefas rotineiras dos cidados, tais como, compras nos supermercados e manuteno do
lar.
Um caso real da eficincia em aplicar TICs baseada em IoT a reduo de 30%
das emisses de carbono em Londres, apenas com a mudana de comportamento dos
cidados, a partir do acompanhamento de todas as tarefas dia-a-dia (Tomordy, 2011).
Esta mudana de comportamento foi possvel a partir de uma rede sensores que fornecia
informaes do nvel de carbono em tempo real .
2.4
Consideraes Finais do Captulo
Este Captulo contextualizou as duas grandes reas de pesquisa deste trabalho: Cidade
Inteligente (CI) e Internet of Things (Internet das Coisas) (IoT).
Como discutido previamente, ainda no h um consenso a respeito da definio
mais adequada para CI. Logo, a Seo 2.1 apresentou algumas definies disponveis
na literatura. A partir destas, a definio a ser utilizada neste trabalho foi explicitada,
15
considerando os diferentes pontos de vistas dos demais autores.

Em seguida, a IoT foi definida e exemplificada na Seo 2.2. A partir desta, podese notar a evidente correlao entre estas duas reas de pesquisa. Este fato pode ser
comprovado ao analisar as principais aplicaes de IoT: a grande maioria visa otimizar
algum aspecto relacionado ao cotidiano das pessoas, tanto no ambiente profissional
quanto no domstico (Atzori et al., 2010).
Por fim, a Seo 2.3, apresentou alguns exemplos de utilizao de IoT e dos conceitos
de CI para mitigar estes problemas urbanos. Algumas destas iniciativas j esto sendo
desenvolvidas e validadas, porm, para de fato se estabelecer uma CI, necessria a
integrao destas iniciativas a partir de uma AS centralizada (Filipponi et al., 2010;
Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011; HernndezMuoz et al., 2011).
Diversas abordagens j esto sendo desenvolvidas utilizando o paradigma: IoT como
ferramenta para captar e atuar sobre os servios urbanos em prol da consolidao de
uma CI. Logo, o prximo Captulo apresenta exemplos destas abordagens, encontradas a
partir de dois mtodos de reviso da literatura.
16
3
Reviso 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 realizao do seu sonho.
BERNARDO ROCHA DE REZENDE, 2010 (Transformando Suor
em Ouro)
No contexto de uma Cidade Inteligente (CI), as Arquitetura de Software (AS) so de

suma importncia por uma srie de fatores. Primeiramente, uma AS pode permitir a troca
de informaes entre diferentes servios urbanos, a fim de fornecer servios mais efetivos
para os cidados. Outro fator relevante a possibilidade de criar aplicaes Internet of
Things (Internet das Coisas) (IoT) que consumam ou forneam algum tipo de dado para
uma determinada finalidade, como por exemplo, captar informaes de pontos tursticos
da cidade para melhorar a experincia dos turistas. Esta integrao das aplicaes 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 servios urbanos. Alm disso, a AS pode permitir que governos adotem aes
estratgicas voltadas para as reais necessidades dos cidados.
Ao adotar um modelo como esse, na qual uma AS centralizada processa e distribu
dos dados dos servios urbanos, uma CI pode de fato ser implementada, uma vez que
existir um meio pelo qual os servios urbanos podero ser integrados (Filipponi et al.,
2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011; HernndezMuoz et al., 2011).
Nos nicio dos anos 90, a AS era basicamente voltada para os sistemas cliente-servidor,
17
CAPTULO 3. REVISO DA LITERATURA DE ARQUITETURAS DE SOFTWARE

PARA CIDADES INTELIGENTES
na qual uma mquina exercia o papel de cliente requisitante e a outra mquina, o papel
de servidor com a responsabilidade de atender as requisies (Sommerville, 2007). Deste
modo, a arquitetura cliente-servidor tornou-se padro 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 dcada de 2000, nota-se que
as aquiteturas propostas so cada vez mais heterogneas, na qual estilos e tecnologias
diferenciadas se misturam para formar novas verses de representaes arquiteturais
(Bass et al., 1998).
Dessa forma, o que se almeja investigar neste Captulo o estado da arte de Arquiteturas de Software (ASs) para CI que empregam IoT na soluo de problemas urbanos.
Para aumentar a abrangncia desta investigao, duas revises da literatura foram
realizadas: Reviso Sistemtica (Seo 3.1) e Exploratria (Seo 3.2). As revises
sistemticas possibilitam a replicao do procedimento, pois possuem um processo
repetitvel. Porm, a temtica deste trabalho envolve aspectos mercadolgicos que podem
ser excludos dessas revises, por no serem publicados nos veculos convencionais.
Logo, as revises exploratrias so importantes, pois permitem incluir diversos trabalhos
de diferentes veculos de publicao, como por exemplo, relatrio tcnico de empresas.
Porm, esse tipo de reviso possui certa resistncia por ser baseado totalmente nas buscas
no-metdicas do pesquisador.
Estes dois mtodos de reviso literria tambm tm como objetivo identificar a
necessidade de criar ou adaptar um padro arquitetural especfico para este contexto de
CI e IoT.
Na Reviso Sistemtica, foram selecionadas 11 abordagens. J na Reviso Exploratria 16 abordagens foram selecionadas. Nestas duas revises, 7 abordagens foram
encontradas em ambas as revises. Estes trabalhos destacam-se por envolverem aspectos
acadmicos e mercadolgicos. Nestes casos, optou-se por descrev-los apenas na Reviso
Sistemtica. Por fim, ao todo, foram encontrados 20 abordagens condizentes com o
objetivo deste trabalho.
Aps a descrio das abordagens encontradas nas duas revises, a Seo 3.3 visa
consolidar as caractersticas mais relevantes de cada abordagem. Em seguida, pretende-se
estabelecer um conjunto de requisitos que uma AS para CI deve atender (Seo 3.4).
Este conjunto de requisitos e os demais resultados da Reviso Exploratria foram
publicados em da Silva et al. (2013). J os resultados da Reviso Sistemtica foram
publicados em Tomas et al. (2013).
Por fim, a Seo 3.6 dicute os pontos mais relevantes deste Captulo e a Seo 3.7
18
3.1. REVISO SISTEMTICA
finaliza o Captulo.
3.1
Reviso Sistemtica
Conforme brevemente introduzido na Seo anterior, de acordo com Kitchenham and

Charters (2007) o objetivo de uma SLR fornecer indcios para o desenvolvimento
de pesquisas baseadas em evidncias, a partir da seleo e sntese das pesquisas mais
relevantes. Alm disso, a SLR deve identificar, avaliar, interpretar e comparar todas as
fontes relevantes para uma determinada questo de pesquisa.
Diversas abordagens arquiteturais tm sido propostas na literatura, mas essa reviso
foca-se somente nas ASs que utilizam o paradigma de combinar IoT como ferramenta
para a implementao de uma CI.
3.1.1
Metodologia de Pesquisa
O objetivo desta subseo descrever a estratgia de busca e todos os passos utilizados

para filtrar e extrair as informaes relevantes de cada pesquisa. Essa estratga segue as
recomendaes descritas por Kitchenham and Charters (2007).
Estratgia de Busca e Fontes de Dados
A estratgia empregada para a construo das strings de buscas segue a mesma metodologia emprega por Kitchenham and Charters (2007), Chen et al. (2009) e Khurum and
Gorschek (2009). Esta estratgia ilustrada na Figura 3.1.
Figura 3.1 Estratgia de Busca
Seguindo esta estratgia, 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

Devido variao dos resultados de cada motor de busca das principais fontes digitais
da literatura (como IEEExplore, Springer Link e ACM Digital Library), no possvel
utilizar a mesma string de busca em todas as fontes digitais (Chen et al., 2009). Logo,
foi necessrio um esforo para garantir que as strings utilizadas sejam logicamente e
semanticamente equivalentes.
Aps definir a string de busca, realizou-se a busca nos seguintes repositrios digitais (1.
IEEExplore; 2. Science Direct; 3. ACM Digital Library; 4. Springer Link; 5. CiteSeerX;
6.Academia.edu; e 7. ISI Web of Science). Alm disso, considerando que CI uma linha
de pesquisa que envolve diversos aspectos de negcio e mercado, realizou-se a busca por
patentes no banco de patentes World Intellectual Property Organization(WIPO)1 .
Em relao 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
identificadas como primrios, conforme discutido em Chen et al. (2009). Dessa forma,
algumas abordagens podem no ter sido includas, caso os autores tenham usado outros
termos alm dos mencionados acima.
Seleo das Abordagens
Nesta SLR foram selecionadas somente abordagens que propem 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 seleo e classificao
Aps 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
Excluso de estudos que no

foram publicados entre 20082012
4310
Filtro 3
Excluso de estudos baseada

no ttulo
71
Filtro 4
Remoo de duplicaes
61
Filtro 5

nos resumos.
33
Filtro 6

na relevncia.
11
Figura 3.2 Resultado da filtragem das abordagens
O objetivo destes filtros selecionar as principais abordagens que descrevem ASs

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 no foram publicadas
entre 2008-2012. Este intervalo foi escolhido aps analisar e verificar que as abordagens
propostas antes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens foram
propostas para solucionar problemas especficos de um contexto usando apenas uma
tecnologia, sem analizar a conexo entre os diferentes contextos urbanos.
21

Para realizar a terceira filtragem, todos os ttulos das abordagens foram lidos e
resultaram apenas 71. Esta alta discrepncia com o valor resultante do filtro anterior est
relacionada a falta de eficincia das engines de busca, como discutido em Kitchenham
et al. (2009).
O quarto filtro corresponde elimio 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 relao aos critrios de incluso, as abordagens foram includas se:
Propem uma AS para centralizar a informao de diferentes contextos urbanos
OU
Descreve uma AS IoT na qual seu design permite a combinao de uma ou mais
tecnologias diferentes e/ou contextos urbanos E
Abordagens que ainda no foram selecionadas.
Durante esta reviso, foram encontradas diversas abordagens que descrevem a mesma
AS. Neste caso, somente o trabalho mais completo foi considerado. Aps essa etapa,
restaram 11 abordagens para serem analisadas.
Existem diversas razes para esta alta discrepncia entre a quantidade inicial de
trabalhos com a quantidade resultante. A principal razo a alta quantidade de estudos
duplicados com resultados semelhantes. Estas razes so discutidas e explicadas em
Kitchenham et al. (2009).
Em relao s patentes, no foi encontrada nenhuma patente relacionada. Geralmente,
as patentes mais prxima temtica dessa reviso sistemtica descrevem um algoritmo
especfico ou a otimizao de uma tcnica empregada em um ambiente controlado.
3.1.2
Resultados
Aps realizar as buscas nas principais fontes de pesquisa, filtrar as abordagens de acordo
com os critrios descritos na Seo anterior, restaram 11 abordagens. Estas abordagens
foram lidas e discutidas entre os 5 pesquisadores supracitados, com o objetivo de realar
os tpicos relacionados s questes de pesquisa. Esta seo visa discutir estas abordagens,
iniciando por uma descrio inicial de cada abordagem.
22
Caso uma abordagem tenha algum nome, este ser utilizado para referir-se a ela. Caso
contrrio, ser dado um nome usando o sobrenome do primeiro autor seguido pelo ano
de publicao. A Tabela 3.2 lista as 11 abordagens analisadas, organizadas em ordem
cronolgica.
Tabela 3.2 Abordagens resultantes por ordem cronolgica
ID
1
2
3
4
5
6
7
8
9
10
11
Abordagem
Al-Hader2009
Anthopoulos2010
SOFIA
EcoCity/ISMP-UC
CPAF
SmartSantander
IMS
USN
Wu2011
Fazio2012
S3 OiA
Ano
2009
2010
2010
2011
2011
2011
2011
2011
2011
2012
2012
Referncia
(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)
(Hernndez-Muoz 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 Seo visa fornecer uma descrio alto-nvel das ASs
encontradas, ordenadas em ordem cronolgica, ressaltando os principais objetivos e
caractersticas de cada abordagem.
Iniciando por Al-Hader2009 (Al-Hader et al., 2009), no qual proposto uma AS
baseada em quatro princpios: aplicaes, negcios, gerenciamento de processos e
infraestrutura de redes. O primeiro princpio corresponde s aplicaes 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 aplicaes atendem as demandas
operacionais das cidades, porm, ao utilizar as regras definidas no segundo princpio negcios - elas podem agregar solues economicamente viveis. O terceiro princpio o
gerenciamento de processos na qual relacionamentos, regras, estratgias e polticas entre
as aplicaes e as unidades de negcios so definidas. Finalmente, o ltimo princpio
corresponde a toda a infraestrutura de rede, responsvel por conectar os outros trs
princpios.
Anthopoulos and Fitsilis (2010) propem uma AS baseada na anlise de diferentes
iniciativas j implementadas, modelada a partir dos princpios das Enterprise Architec-
23

tures (Booch, 2010). Anthopoulos and Fitsilis (2010) enfatizam que a construo de
uma CI deve ser guiada pela integrao de sistemas legados com as novas infraestruturas,
migrao e reuso de dados existentes, simplificao dos processos urbanos, otimizao
da utilizao de recursos naturais, interoperabilidade de sistemas e equipamentos e prover
ferramentas para monitoramento, gerenciamento e anlises.
A integrao 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 interao de objetos, como sensores, dispositivos e sistemas embarcados
em geral. A AS SOFIA baseada em eventos, na qual cada evento corresponde
mudana de estado de qualquer sistema de TIC. Estes eventos podem ser iniciados a
partir de eventos do mundo real (como deteco de presena) ou ao trmino de algum
processamento.
O monitoramento e gerenciamento de sensores tambm so objetivos definidos pela
abordagem denomida EcoCity/ISMP-UC (Lee et al., 2011). A AS EcoCity/ISMP-UC
constituda de trs camadas. A camada inferior consiste de diferentes tipos de sensores,
atuadores e outros dispositivos distribudos pela cidade. J a camada superior representa
um conjunto de servios U-eco City. Entre essas duas camadas existe um middleware
responsvel por coletar e processar informaes contextuatilizadas. Esta AS orientada
servios possibilita o desenvolvimento de servios independentes e que sejam consumidos
via interfaces padronizadas, como web services.
Por sua vez, Mostashari et al. (2011) propem um framework denominado Cognitive
Process Architecture Framework (CPAF), o qual permite o desenvolvimento de diferentes
servios urbanos com habilidades cognitivas. Nesse contexto, cognio a habilidade do
sistema aprender a partir das experincias anteriores e adaptar seu comportamento a partir
destas concluses. Um sistema cognitivo capaz de perceber e responder s mudanas
no ambiente, portanto, pode melhorar a performance dos servios urbanos.
Outra abordagem na qual utiliza vrios 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 refncia para sistemas IoT; ii) um
escalvel e heterogneo laboratrio para prototipao de aplicaes IoT; iii) um conjunto
representativo de casos de uso implementados para facilidades de experimentao 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) prope uma AS que combina IoT com os cidados das
cidades. Shao (2011) acreditam que o desenvolvimento de TIC esta relacionado
24
proximidade com os moradores das cidades. Para isso, IMS baseada em trs camadas:
acesso, sesso e aplicaes. 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
sesso prov o gerenciamento de sesses entre a camada inferior (Acesso) e a superior
(Aplicaes). Finalmente, a camada de aplicao permite o desenvolvimento de diversas
aplicaes.
A interoperabilidade de objetos tambm explorada por Hernndez-Muoz et al.
(2011), que propem uma AS denominada Ubiquitous Sensor Network (USN). O objetivo
prover uma infraestrutura que seja capaz de integrar sensores heterogneos e distantes
geograficamente em um base centralizadora, na qual servios podem ser facilmente
desenvolvidos. Adicionalmente, a AS inclui um mdulo conhecido como USN-Gateway
que possibilita a interoperabilidade entre redes de sensores e redes IP.
Da mesma forma que USN, Wu2011 (Wu et al., 2011) propem um middleware para
gerenciamento de informaes dispersas oriundas de mltiplas fontes, com diferentes
formatos e estruturas. Esta abordagem construda seguindo os princpios de Arquitetura
Orientada a Servios (SOA), baseada em duas principais componentes: modelo ContractFirst e agente de troca de mensagens.
Em Fazio2012 (Fazio et al., 2012) proposto uma AS que permite a agregao
de diferentes tipos de informaes oriundas de diferentes sensores distribudos 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 interaes sob-demanda com os clientes, aplicaes
e outros servios; II) Sensor Observation Service Agent (SOS Agent) que suporta todas
as funcionalidades para a descrio 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 vrios diferentes sensores.
Finalmente, a abordagem conhecida como S3 OiA (Vega-Barbas et al., 2012) tambm
permite o gerenciamento de diferentes tipos de informao. A AS S3 OiA sinttica
e semntica aos princpios do SOA, que permitem a integrao de qualquer tipo de
dispositivo IoT. Com essa estratgia, a AS suporta a composio de aplicaes ad hoc.
Para tal, foi definido dentro do projeto da AS um conjunto de mdulos de dependncia
semntica de gesto que controlam servios e recursos, permitindo que os aplicativos j
criados possam continuar a execuo, apesar das mudanas do contexto.
25

3.2
Reviso Exploratria
As abordagens e iniciativas em CI que se baseiam na adoo de IoT podem ser desenvolvidas tanto no ambiente acadmico quanto no empresarial. Por exemplo, pode-se
ressaltar o interesse das organizaes governamentais e/ou privadas, como Microsoft
(PlanIT, 2012), alm das iniciativas nos modelos de Startup, como Libelium 2 e Every 3 .
Alm disso, pode-se encontrar diversas iniciativas em formato Web/HTML ou relatrio tcnico disponibilizados pela prpria organizao, como HP (Hoover et al., 2010) e
IBM (Dirks and Keeling, 2009).
Desta forma, para aumentar a eficcia e a abrangncia da reviso literria faz-se
necessrio realizao de uma reviso exploratria. Uma reviso exploratria consiste
em um mecanismo que no possui nenhum processo pr-definido para encontrar as fontes
de informaes.
Nesse tipo de reviso, todas as fontes relacionadas com o tema so analisadas, independente do tipo e do veculo de publicao do contedo. Em algumas situaes, essas
revises podem ser consideradas mais abrangentes, por no possurem nenhum processo
de classificao. Porm, em outras situaes, so consideradas tendenciosas, j que o
processo de reviso dificilmente pode ser repetido.
Logo, essa reviso exploratria visa discutir e analisar as principais abordagens que
propem uma AS para CI baseada em IoT, encontradas nos mais diversos veculos
de comunicao. Dentre eles, destacam-se websites, blogs, relatrios tcnicos no
publicados e eventos.
3.2.1
Metodologia de Pesquisa
Nas revises exploratrias no h um processo ou guideline definido (Pollitt, 2007).

Geralmente, o procedimento consiste em levantar diversas fontes com a informao
desejada e ento separ-las a partir de mtodos especficos.
No caso dessa reviso, inicialmente algumas buscas foram realizadas em trs repositrios 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 especfica foi definida.
2 http://www.libelium.com
3 http://www.evrythng.com
26
3.2. REVISO EXPLORATRIA
A partir dos resultados dessas buscas, alguns trabalhos foram classificados como
relevantes de acordo com o ttulo e uma rpida leitura do contedo. Em seguida, todos os
trabalhos restantes foram lidos e discutidos, com o mesmo grupo da Reviso Sistemtica,
do ponto de vista arquitetural e do emprego das tecnologias IoT para resolver a problemtica de CI. A partir destas fontes, as principais referncias destes trabalhos tambm
foram analisadas, repetindo a abordagem at no restar nenhum trabalho potencialmente
interessante.
As revises exploratrios possuem alguns riscos eminentes. No contexto deste
trabalho, a principal ameaa de no encontrar abordagens maduras e com os mesmos
objetivos desta proposta, uma vez que a metodologia de pesquisa no abrangente o
suficiente. Alm disso, ao realizar uma reviso exploratrio aps a SLR pode-se encontrar
vrias abordagens repetidas.
3.2.2
Resultados
Em Klein and Kaefer (2008) relatada uma perspectiva de CI voltada para negcio, especificamente de provedores de infraestruturas e solues dentro do contexto de utilizao
eficiente de energia eltrica para infraestruturas inteligente e data centers. O objetivo
do trabalho aderir eficincia energtica dos equipamentos, reduzindo os custos com
energia e criando mecanismos para que softwares e servios tornem-se autoconscientes
de seu consumo de energia. De acordo com os autores, esta caracterstica essencial na
implementao de uma AS de CI, permitindo desenvolvimento e operao sustentveis.
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 construo de aplicaes de IoT, o MB2 esta sendo adaptado para o contexto
de CI. Para tal, alm de prover a API para consultas, a plataforma prov abstraes
fundamentais, como: eventos, estado, servios e gerenciamento de contedo.
O MB2 consiste de uma evoluo do MB original (Erbad et al., 2008), na qual
foram inseridas diversas caractersticas para a construo de aplicaes ubquas, como a
incluso de um middleware responsvel por tratar as informaes oriundas dos diferentes
dispositivos. Para tal, foram acoplados diversos protocolos de comunicao como HTTP e
XML. Cada implementao desses protocolos foi implementada usando servios OSGi4 .
Seguindo o princpio de ser um laboratrio para validao de tecnologias com foco
em CI, em Lisboa/Portugal foi construda uma cidade com 1700 hectares de extenso.
4 http://www.osgi.org
27

Conhecida como PlanIT Valley5 , a cidade deve produzir 150% da energia necessria,
gerenciar os resduos slidos e reciclar toda a gua consumida. Empresas privadas, como
a Microsoft, Cisco, Massachusetts Institute of Techonology e McLaren Eletronic System
esto apoiando esse projeto (PlanIT, 2012).
A estratgia desse projeto implementar um Sistema Operacional Urbano(UOS).
Esse sistema operacional uma plataforma com o intuito de integrar cada domnio que
compem uma cidade. O sistema ser alimentado por uma vasta rede de sensores e todos
esses dados sero capturados por tempo indeterminado, para auxiliar na tomada e na
predio de decises. Alm de prever catstrofes, caso ocorra, o sistema pode antever os
possveis 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 mnimo de impacto
ambiental. Toda a cidade livre de combustveis fsseis, na qual toda a energia oriunda
de fontes renovveis, sem nenhum tipo de resduo. Alm disso, 80% da gua consumida
ser tratada. No quesito transporte, os veculos privados so proibidos e os meios de
transporte so veculos eltricos e bicicletas. As estaes de transportes eltricos sero
separadas por uma distncia de no mximo 200 metros. A primeira fase do contm
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 instituies na concepo de CI. O trabalho destaca especificamente
que a inteligncia refere-se comumente s mudanas inovadoras trazidas por novas
tecnologias. Em relao ao aspecto tecnologia, os autores afirmam que essencial que a
cidade possua alta adaptabilidade s necessidades de seus cidados, independente de suas
limitaes, com capacidade de autoconfigurao, proteo, otimizao e recuperao
de falhas, garantindo disponibilidade de servios a qualquer tempo. Para isso, faz-se
necessrio uma infraestrutura de computao ubqua, sobre a qual os servios sero
disponibilizados.
De acordo com Andreini et al. (2011), SOA considerada uma investida promissora
na construo de CI atravs da implementao da IoT. Assim, objetos conectados rede
publicariam seus servios, que por sua vez seriam acessados a partir de clientes mveis,
permitindo interaes humano-mquina e mquina-mquina (M2M) mais flexveis. Isso
seria construdo a partir de uma abordagem semelhante ao Domain Name System (DNS),
5 http://living-planit.com
28
3.2. REVISO EXPLORATRIA
no qual um objeto seria identificado atravs de um nome, usado para acess-lo e consultar
servios. Os autores prope uma implementao usando Distributed Hash Table (DHT),
que atribui o nvel de escalabilidade desejado para a abordagem adotada, permitindo a
recuperao eficiente de servios no contexto de aplicaes para CI.
Outro aspecto muito relevante para qualquer centro urbano a predio, preveno e
correo de situaes catastrficas, nas quais medidas urgentes devem ser tomadas no
menor tempo, com a mxima eficcia possvel. Em Asimakopoulou and Bessis (2011),
proposto uma AS de gerenciamento de desastres, baseada na coleta de informaes de
diversas entidades - incluindo pessoas, residncias, veculos - imersas em um ambiente
totalmente conectado, que monitoram o meio sua volta. No processo de gerao de
respostas a situaes de emergncia necessrio que se tenha conhecimento histrico
e em tempo real, das entidades e do ambiente no domnio em questo, para que a
soluo encontrada seja eficaz. Para isso utilizou-se da abordagem crowdsourcing, na
qual os prprios cidados, habilitados por algum tipo de aplicao e/ou dispositivo,
contribuem com o fornecimento de dados sobre determinado cenrio crtico, auxiliando
os stakeholders no processo de tomada de deciso com dados precisos e atualizados.
J em relao segurana, 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 dinmica proposta pela AS so consideradas
recursos, e sua alocao envolve uma negociao baseada em conjuntos de polticas. Isso
garante que a utilizao dos recursos ser sempre priorizada de acordo com a gravidade da
situao corrente. Mecanismos especficos foram criados para permitir alocao dinmica
e gerao parametrizada de alertas, assegurando a disponibilidade dos recursos.
Concomitantemente, em Attwood et al. (2011) proposta uma AS para infraestruturas
crticas 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 decises
em situaes crticas. O funcionamento bsico da AS consiste em um mecanismo de
anotao e agregao, no qual uma rede de sensores distribuda pela cidade estaria
conectada e cujos dados estariam mapeados para um servio especfico (Ex.: falha no
sistema de distribuio de energia eltrica). Quando algum tipo de falha fosse detectado,
os dados coletados seriam fornecidos a uma instncia de raciocnio, responsvel por
sugerir as medidas a serem tomadas para normalizar a situao. Para o caso de falha
em algum n da rede de sensores, outra rede seria criada a partir dos ns ainda em
funcionamento, permitindo a preservao e distribuio dos dados. Para que esta AS seja
implementada requerida uma infraestrutura de hardware distribuda, com capacidade de
29

processamento em tempo real, de alta disponibilidade, preparada para demandas variveis,

tolerante a falhas e energeticamente eficiente.
Por fim, a sustentabilidade tambm 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 sustentveis, especificamente na segunda camada, conhecida como Green City. Essa camada sustentada
pela camada responsvel pela infraestrutura da cidade e contm todas as polticas ambientais, por exemplo, o nvel de CO2 permitido pelas residncias. As demais camadas
correspondem, respectivamente: inovao, aplicao, integrao, sincronizao e interconexo entre diferentes redes. Para validar o objetivo proposto, este modelo foi utilizado
nas cidades de Barcelona, Amsterd e Edimburgo.
3.3
Consolidao das Abordagens Encontradas
As Sees anteriores descrevem vrias abordagens obtidas de dois mtodos distintos:

Reviso Sistemtica (Seo 3.1) e Exploratria (Seo 3.2). Na Reviso Sistemtica,
foram selecionadas 11 abordagens. J na Reviso Exploratria 16 abordagens foram
selecionadas e 7 abordagens foram encontradas em ambas as revises. No total, 20
abordagens foram encontradas a partir destes dois mtodos.
A partir da descrio dessas abordagens, pode-se notar a relevncia da temtica de CI,
devido, dentre outros fatores, ao interesse de grandes empresas como Microsoft e Cisco.
A Tabela 3.3 resume as principais caractersticas dessas abordagens. Para abordagens
publicadas em peridicos, a coluna Ano refere-se ao ano de publicao. J para as
demais, a mesma refere-se ao ano de criao. Por sua vez, a coluna Incentivo categoriza
as abordagens que recebem incentivos dos governos (Pblico), iniciativa privada (Privada)
ou de ambos (Ambos).
Ao anlisar a Tabela 3.3 percebe-se que a maioria das abordagens no esto amplamente validadas em diversos contextos, o que ratifica o carter inovador deste trabalho.
Alm disto, nota-se que das 20 abordagens, 11 no possuem nenhum tipo de validao
prtica. Este fato deve-se alguns fatores, como:
Imaturidade da implementao das abordagens;
Falta de dados reais para simulaes;
Pouqussimas APIs pblicas para acessos aos servios de interesse do cidado;
30
Ano
2008
2009
2010
2010
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2012
2012
2012
2012
Aborgagem
Klein2008
Al-Hader2009
Anthopoulos2010
MB2
Andreini2011
Asimakopoulou2011
Attwood2011
IMS
CPAF
SOFIA
Wu2011
Masdar City
USN
EcoCity/ISMP-UC
Nam2011
SmartSantander
Zygiaris2012
S3 OiA
Living PlanIT
Fazio2012
Prover dados combinados
Integrao de dispositivos via SOA

Criao de Sistema Operacional Urbano
Modelo para gerenciamento inteligente de qualquer cidade
Criao de plataforma ubqua

Plataforma para a criao de solues urbanas inteligentes
Gerenciamento eficiente de informaes dispersas oriundas de

mltiplas fontes, com diferentes formatos e estruturas
Implementar sustentabilidade nos servios urbanos
Interoperabilidade de objetos
O monitoramento e gerenciamento de sensores remotamente
Plataforma para situaes crticas

Criao de servios urbanos com habilidades cognitivas
Integrao de sensores
Plataforma escvel que permite a interoperabilidade de objetos a

partir de SOA
Predio, preveno e correo de situaes catastrficas
Objetivo
Aumentar a eficincia energtica de dispositivos conectados ao
ambiente urbano
Permitir a criao de solues inteligentes
Integrao dos sistemas legados com as novas infraestruturas,
migrao e reuso de dados existentes
Permitir a interoperabilidade de objetos
Em andamento
Sem validao prtica
Validada em ambiente controlado
Sem validao prtica
Validado nas cidades de Barcelona, Amsterd e Edimburgo
Sem validao prtica
Em andamento em Lisboa,
Portugal

Sem validao prtica
Sem validao prtica
Sem validao prtica
Sem validao prtica

Sem validao prtica
Sem validao prtica

Sem validao prtica
Validao
Sem validao prtica
Privada
Privada
Privada
Ambos
Privada
Privada
Ambos
Privada
Ambos
Privada
Privada
Privada
Privada
Privada
Privada
Privada
Privada
Ambos
Privada
Incentivo
Privada
3.3. CONSOLIDAO DAS ABORDAGENS ENCONTRADAS
Tabela 3.3 Resumo das abordagens descritas na literatura
31

Falta alta de apoio governamental para a realizao de experimentos prticos nos

ambientes reais.
Esta falta de suporte governamental comprovada na coluna Incentivo, na qual
apenas 4 abordagens contm esse tipo de suporte.
A partir dessas abordagens, a prxima Seo visa elencar um conjunto de requisitos
mnimos 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 no se aplique a todos os cenrios. Principalmente
pelo fato de que no se pode generalizar restries locais, aspectos financeiros, sociais
e ambientais, ou mesmo garantir a adequao dinmica do cotidiano das diferentes
localidades. A partir do levantamento das arquiteturas realizado, a proposta desta Seo
discutir um conjunto de requisitos fundamentais que devem ser atendidos na implantao
de uma AS para CI.
3.4.1
Um dos requisitos mais discutidos e estudados em projetos IoT a interoperabilidade

de objetos, na qual cada objeto uma abstrao de um sensor, atuador ou qualquer outro
dispositivo capaz de realizar algum tipo de computao (Atzori et al., 2010). De fato,
este um requisito crtico para a consolidao de qualquer plataforma que utilize uma
vasta gama de objetos com diferentes especificaes tcnicas.
No contexto de CI este requisito tambm fundamental, visto que os dados so
oriundos de diversos objetos, com tecnologias e protocolos variados.
As ASs designam um mdulo ou camada para atender esse requisito, como em
SOFIA (Filipponi et al., 2010), USN (Hernndez-Muoz et al., 2011), EcoCity/ISMPUC (Lee et al., 2011), Living PlanIT (PlanIT, 2012), Zygiaris2012 (Zygiaris, 2012),
Wu2011 (Wu et al., 2011) e S3 OiA (Vega-Barbas et al., 2012). Em particular, no caso da
USN (Hernndez-Muoz et al., 2011) este mdulo, conhecido como USN-Gateway, alm
de ser responsvel pela interoperabilidade dos objetos em relao a plataforma, tambm
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 importncia para manter todos os servios da cidade
constantemente atualizados.
Alm disso, o monitoramento em tempo real a ferramenta mais importante para
fornecer as informaes mais relevantes para a predio e tomada de decises de eventos
futuros e prever fenmenos. Um exemplo disso o monitoramento do nvel dos rios
durante as temporadas de chuva. Nessa situao, a partir de um monitoramento efetivo
possvel tomar medidas para mitigar possveis transtornos aos cidados, como enchentes
e a transmisso de doenas.
Logo, este requisito pode ser considerado como fundamental. Neste contexto, as
ASs que visam atender esse requisito so Al-Hader2009 (Al-Hader et al., 2009), SOFIA
(Filipponi et al., 2010), SmartSantander (Sanchez et al., 2011), USN (Hernndez-Muoz
et al., 2011), Asimakopoulou2011 (Asimakopoulou and Bessis, 2011), Attwood2011
(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. Alm disso, vrios problemas de poluio, seja poluio sonora, visual,
atmosfrica, da gua ou do solo, prejudicam a qualidade de vida dos cidados de vrias
cidades, principalmente as metrpoles.
Neste sentido, uma AS para CI deve permitir que polticas sustentveis (sustentabilidade) sejam implementadas com base em estatsticas relacionadas ao dia-a-dia
dos cidados. Por exemplo, iniciativas de consumo consciente de alimentos podem ser
implementadas ao mapear os hbitos dos cidados durante um dia.
Desta forma, estas polticas sustentveis devem otimizar a utilizao de recursos
naturais, a partir de iniciativas relacionadas ao meio ambiente e economia (Fels, 2010).
Para tal importante ressaltar que polticas devem ser propostas nos diversos domnios
que compem uma cidade, como Transporte e Educao.
As ASs que integram sustentabilidade so Klein2008 (Klein and Kaefer, 2008),
EcoCity/ISMP-UC (Lee et al., 2011), SmartSantander (Sanchez et al., 2011), Masdar
City (Haubensak, 2011) e Zygiaris2012 (Zygiaris, 2012).
33

3.4.4
Aspectos sociais
Na implantao de CI a importncia de alocar recursos, mais escassos, de forma otimizada

no pode significar a eroso da qualidade de vida das pessoas. At porque, para de fato
estabelecer uma CI necessrio envolver as pessoas, procurando a sua participao para
lhes proporcionar maior qualidade de vida, mas protegendo a dimenso humana das urbes
cada vez mais em risco (ComputerWorld, 2013).
Uma AS para CI no pode ser sustentada somente com tecnologia. O propsito
principal na concepo de uma CI o aumento na qualidade de vida de seus cidados,
atravs de aspectos sociais.
Apesar do aparato tecnolgico fazer parte dos elementos necessrios para a implementao de uma soluo mais robusta, as pessoas precisam participar e ser beneficiadas
pelo processo, caso contrrio, todo investimento ser em vo. Um exemplo disso, a
Cidade Digital de Trikala, Grcia, que aps cinco milhes de euros gastos em manuteno de infraestrutura e 6 anos de funcionamento, a populao no utilizava ou no tinha
conhecimento dos servios digitais disponveis (Anthopoulos and Fitsilis, 2010).
De qualquer forma, CI so construdas por pessoas, para pessoas, e essa deve ser
uma premissa contemplada em todas os aspectos supridos pela AS. Uma CI feita de,
sobretudo, uma mudana no comportamento de seus cidados. As pessoas precisam sentirse inclusas como parte fundamental na implantao de uma CI, sentir-se estimuladas a
fazer parte da soluo. 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 mudana de hbitos.
Alm disso, os servios devem estar disponveis para todos os cidados independente
de quaisquer restries social, fsica, econmica ou financeira, a tecnologia deve ser
aplicada a fim de trazer benefcios coletivos, e no alienar ou elitizar uma pequena parte
da populao.
Apesar da evidente importncia deste requisito fundamental, apenas as ASs que
explicitamente contm aspectos sociais so Klein2008 (Klein and Kaefer, 2008), IMS
(Shao, 2011) e Asimakopoulou2011 (Asimakopoulou and Bessis, 2011).
3.4.5
Ubiquidade/Mobilidade
A proximidade dos dispositivos com as pessoas/cidados, geralmente a partir da internet,

origina o termo ubiquidade (Spnola and Travassos, 2012). Neste sentido, este termo
6 http://www.thefuntheory.com/
34

INTELIGENTES
corresponde a qualquer tecnologia mvel capaz de capturar informao sobre o ambiente

ou atuar sobre o mesmo (Sanchez et al., 2011).
Ao considerar que 4 bilhes de cidados j possuem smartphones (Hall, 2012),
natural associar ubiquidade ao uso destes dispositivos. Porm outros dispositivos devem
ser utilizados, como ZigBee e RFID (Radio-frequency identification).
Logo, uma AS para CI deve permitir a comunicao efetiva com os mais diversos
dispositivos oriundos da temtica de ubiquidade, uma vez que estes estaro fisicamente
prximos aos cidados. Neste contexto, as ASs que j empregam alguns destes princpios
so SmartSantander (Sanchez et al., 2011), USN (Hernndez-Muoz et al., 2011), MB2
(Blackstock et al., 2010) e Zygiaris2012 (Zygiaris, 2012).
3.4.6
Privacidade e Segurana dos dados
O ambiente de uma cidade pode ser considerado ubquo j que diversos sensores so
instalados em diferentes locais e coletam diferentes tipos de informao (Sanchez et al.,
2011). Todo esse volume de dados deve ser protegido fazendo uso das polticas de
privacidade e segurana dos dados, tanto em relao disponibilidade quanto ao
armazenamento.
Certamente a consolidao destes polticas um desafio que pode impedir os cidados, instituies e o governo de fornecerem determinados dados crticos. Este fato
pode ser comprovado a partir dos recentes casos de violao de privacidade dos dados
governamentais amplamente divulgados pela imprensa, como os documentos vazados da
National Security Agency (NSA) (Bird, 2013).
Devido a alta relevncia deste requisito, no admissvel que uma AS no o satisfaa.
Apesar disso, apenas as ASs SmartSantander (Sanchez et al., 2011), Living PlanIT
(PlanIT, 2012) e Fazio2012 (Fazio et al., 2012) abordam este requisito.
3.4.7
Geolocalizao dos sensores
De acordo com Shao (2011); Hernndez-Muoz et al. (2011); Vega-Barbas et al. (2012),
a geolocalizao dos sensores fundametal para o refinamento do processo de anlise
de dados. Neste sentido, um sensor corresponde uma abstrao de qualquer dispositivo
capaz de fornecer informaes sobre determinado contexto.
A partir destas informaes geogrficas dos sensores possvel realizar aes especficas para cada ambiente (Jauregui-Ortiz et al., 2012). Esta caracterstica pode ser
notada nas abordagens IMS (Shao, 2011), USN (Hernndez-Muoz et al., 2011) e S3 OiA
35

(Vega-Barbas et al., 2012). No caso da abordagem IMS, a geolocalizao dos sensores

importante para a investigao do comportamento dos cidados; na USN, a localizao
considerada um requisito diferenciador; por fim, em S3 OiA a localizao utilizada para
unificar as aes realizadas sobre um determinado conjunto de sensores.
3.4.8
Composio de Dados Urbanos
Em uma viso sistmica, ambientes urbanos so essencialmente um conjunto de domnios

complexos (como transporte, gua, energia eltrica, saneamento bsico, etc.) disponibilizados para suprir as necessidades de seus cidados. ASs que se dispe a dar suporte
esses sistemas devem consider-los como complementares na busca de um gerenciamento
urbano efetivo, ao invs de trat-los de forma isolada.
Pelo fato de que CI pode ser considerada um sistema de sistemas, a composio 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 viso holstica e contextualizada da cidade
na qual a AS foi implementada (Anthopoulos and Fitsilis, 2010; Nam and Pardo, 2011;
PlanIT, 2012).
Para atender essa composio de dados urbanos as ASs Nam2011 (Nam and Pardo,
2011), CPAF (Mostashari et al., 2011), IMS (Shao, 2011), Anthopoulos2010 (Anthopoulos and Fitsilis, 2010), Fazio2012 (Fazio et al., 2012) e Living PlanIT (PlanIT, 2012)
implementam explicitamente algum mdulo que visa atender este requisito fundamental.
3.4.9
Histrico de dados
No contexto de CI, todos os componentes que compem cada domnio de uma cidade
esto constantemente sendo modificados, seja por eventos humanos, naturais ou tecnolgicos. Dessa forma, todo dado captado tem potencial para se tornar uma informao
relevante, desde que seja agregado a outros dados.
Estes dados histricos podem ser empregados na predio de eventos futuros, principalmente quando houver um grande perodo sem dados em tempo real. Por exemplo,
a partir de informaes meterolgicas dos anos anteriores possvel prever os meses
que podero ter tempestades. Com informao nessa granularidade possvel adotar
providncias preventivas para evitar catstrofres.
Logo, torna-se substancial que as ASs contemplem mecanismos eficientes de armazenamento e consulta desses dados. Como citado em MB2 (Blackstock et al., 2010),
36

INTELIGENTES
SmartSantander (Sanchez et al., 2011), EcoCity/ISMP-UC (Lee et al., 2011) e Living

PlanIT (PlanIT, 2012), estas informaes historicamente armazenadas potencializaro os
resultados obtidos a partir de um algoritmo de contexto e minerao de dados.
3.4.10
Disponibilidade
Para permitir a captao de dados em tempo real e o fornecimento de informaes

contextualizadas, a AS deve ser altamente disponvel, em qualquer dia e horrio.
Na literatura existem diversas iniciativas que propem 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, coliso e redundncia devem ser inerentes soluo.
Nas ASs SmartSantander (Sanchez et al., 2011), USN (Hernndez-Muoz et al.,
2011) e Nam2011 (Nam and Pardo, 2011), estas situaes so tratadas utilizando diversos
mecanismos de modularidade em relao a cloud.
3.4.11
Sensoriamento e Processamento Distribudo
Para que sejam propostas solues para o aumento da eficcia em servios urbanos
necessrio que se faam aferies das caractersticas qualitativas ou quantitativas
que permeiam esses servios, bem como do resultado que produzem. atravs de
sensoriamento que se obtm a viso computacional do ambiente urbano; quanto maior o
nmero 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 extrados de cada cenrio monitorado, sendo possvel
obter resultados mais precisos. Por exemplo, reports de trnsito em determinada via
podem ser melhor analisados se complementados com imagens obtidas atravs de cmeras
instaladas nas redondezas.
Em situaes que exigem que medidas preventivas ou corretivas sejam tomadas
instantaneamente exige-se processamento em tempo real, com tempo de resposta rpido
o suficiente para fornecer embasamento para aes que devem ser executadas assim
que determinada situao identificada. Considerando quantidades massivas de dados
coletados, o suporte esse tipo de contexto sugere a necessidade de processamento
distribudo, explorando a capacidade da infraestrutura existente.
Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerar
37

informaes e conhecimento, permite execuo de seus servios de forma otimizada e

um gerenciamento urbano eficiente.
As ASs que visam atender esse requisito so USN (Hernndez-Muoz et al., 2011),
SOFIA (Filipponi et al., 2010), Andreini2011 (Andreini et al., 2011) e EcoCity/ ISMPUC (Lee et al., 2011).
3.4.12
Flexibilidade/Extensibilidade
Este requisito corresponde capacidade da AS adaptar-se mudanas e extenses. Alm

da insero de novos servios, a AS deve ser capaz de adaptar-se novos requisitos
inerentes ao contexto de implementao. Por exemplo, a AS deve ser independente de
padres especficos de hardware.
Apesar da evidente relevncia deste requisito, apenas trs ASs exploram este requisito:
Klein2008 (Klein and Kaefer, 2008), MB2 Blackstock et al. (2010) e EcoCity/ISMP-UC
(Lee et al., 2011).
3.5
Sumrio dos Requisitos para Cidades Inteligentes
A Tabela 3.4 ilustra um resumo dos requisitos que foram implementados nas ASs
abordadas nesse Captulo. Nesta tabela, a coluna # representa a quantidade de abordagens
encontradas que visam atender ao determinado requisito.
Ao analisar essas informaes, pode-se perceber que nenhuma dessas ASs implementam minimamente todos os requisitos levantados.
Isto deve-se ao fato de que as ASs geralmente so projetadas para propsitos especficos e cada uma prope uma soluo focada especificamente no problema que pretende
resolver.
Alm disso, percebe-se que os requisitos de Interoperabilidade de Objetos e Monitoramento em Tempo Real so os mais abordados pelas ASs. Esta observao confirma
a importncia em monitorar constantemente todos os aspectos que envolvem a cidade,
processar e disponibilizar os dados coletados rapidamente, a fim de fornecer uma viso
de estado do ambiente urbano mais precisa e atualizada para dar suporte s tomadas de
deciso em tempo real.
A AS descrita em (PlanIT, 2012) atende o maior nmero de requisitos considerados
essenciais no contexto desse trabalho. A abordagem de estruturao da AS, cujas camadas
apresentam os mesmos princpios de abstrao encontrados em sistemas operacionais,
garante as mesmas vantagens aos mesmos atribudas - como abstrao e gerenciamento
38
3.6. DISCUSSO DO CAPTULO
de dispositivos fsicos - que aliada conectividade expande a abrangncia de atuao

dentro do ambiente urbano, criando um ambiente pervasivo favorvel a uma gesto urbana
efetiva.
Tabela 3.4 Mapeamento requisitos-arquiteturas
Requisito
Monitoramento em tempo
real
Sustentabilidade
Aspectos sociais
Privacidade e Segurana dos
dados
Geolocalizao dos Sensores
Composio de Dados Urbanos
Histrico de dados
Disponibilidade
3.6
Abordagens
SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygiaris2012, Wu2011 e S3 OiA
Al-Hader2009, SOFIA, SmartSantander, USN, Asimakopoulou2011, Attwood2011 e Living PlanIT
Klein2008, EcoCity/ISMP-UC, SmartSantander, Masdar
City e Zygiaris2012
Klein2008, IMS e Asimakopoulou2011
SmartSantander, USN, MB2 e Zygiaris2012
SmartSantander, Living PlanIT e Fazio2012
#
7
IMS, USN e S3 OiA

Nam2011, CPAF, IMS, Anthopoulos2010, Fazio2012 e
Living PlanIT
MB2, SmartSantander, EcoCity/ISMP-UC e Living PlanIT
SmartSantander, USN e Nam2011
USN, SOFIA, Andreini2011 e EcoCity/ISMP-UC
3
6
Klein2008, MB2 e EcoCity/ISMP-UC
7
5
3
4
3
4
3
4
Discusso do Captulo
Neste Captulo foram apresentadas 20 abordagens, em diferentes estgios de validao,

oriundas de dois tipos de reviso: Reviso Sistemtica e ad hoc. A partir da reviso
exploratria foram encontrados trabalhos com investimentos da iniciativa privada e que
j se encontram em estgio de prototipao.
Ao trmino desse Captulo, pode-se perceber que no h a necessidade da criao de
um novo padro arquitetural ou adaptao de um padro j existente para o contexto de CI
e IoT. Ainda em relao aos padres arquiteturais, nota-se que o modelo de arquiteturas
em camadas o mais utilizado, pois permitem o escalonamento de uma AS. Outro padro
bastante empregado pelas ASs foi o publisher-subscriber, devido, principalmente, as
vantagens em utiliz-lo para modelar o ambiente real.
Alm disso, pode-se perceber que algumas ASs foram propostas para finalidades
especficas, como gerenciamento de catastrfes. Apesar disso, essas ASs possuem mecanismos interessantes de tratamento de eventos em tempo real que devem ser considerados
39

no desenvolvimento de qualquer AS para CI.

Apesar dos objetivos comuns destas abordagens, uma coisa fato: ainda no 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 princpios definidos para
uma CI.
Ao analisar esse conjunto de requisitos, nota-se que nenhuma AS atendeu todos os
requisitos. Geralmente, as ASs so propostas com propsitos especficos e ignoram
alguns requisitos essenciais.
Dessa forma, ao propor uma nova AS para CI de suma importncia que ela atenda a
maior quantidade desses requisitos, para que uma cidade possa ser de fato considerada
inteligente. Esses requisitos serviro como pilares para a elaborao da AS para CI que
combine as tecnologias de IoT que ser descrita nos prximos Captulos.
3.7
Este Captulo apresentou algumas abordagens arquiteturais encontradas na litetura. Para

tal, dois mtodos de reviso da literatura foram utilizados: Reviso Sistemtica e ad-hoc.
A Seo 3.1 apresentou a metodologia utilizada durante o processo de reviso sistemtica. Posteriormente, os resultados foram apresentados em ordem cronolgica.
Por sua vez, a Seo 3.2 apresentou a reviso ad-hoc e os respectivos resultados,
ressaltando, principalmente, o estgio de validao das abordagens encontradas.
Na Seo 3.3 foi realizado uma consolidao das caractersticas mais relevantes de
cada abordagem. Por fim, a Seo 3.4 apresentou um conjunto de requisitos, extrados a
partir da anlise das abordagens, que uma AS para CI deve atender.
Estes requisitos foram utilizados para guiar o desenvolvimento da proposta deste
trabalho. Logo, o prximo Captulo apresenta esta proposta, utilizando um mtodo de
descrio arquitetural amplamente discutido na literatura (Kruchten, 1995).
40
4
Uma Arquitetura de Software para
Cidades Inteligentes baseada na Internet
das Coisas
Os verdadeiros analfabetos so os que aprenderam a ler e no lem.
MARIO QUINTANA, 2006 (Caderno H)
Baseado nas demandas de uma AS para Cidade Inteligente (CI) que possibilite a
integrao de tecnologias IoT e no conjunto de requisitos que foi definido no Captulo
anterior, este Captulo visa propor uma AS para CI que permita a combinao com
tecnologias IoT. O foco da soluo 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 includos, de acordo com o contexto de cada
cidade.
Dessa forma, a Seo 4.1 apresenta este sub-conjunto de requisitos que sero abordados nesta proposta. J para descrever a proposta detalhadamente utilizado um mtodo
de descrio de ASs baseado em vises, conhecido como 4+1, na Seo 4.2.
Em seguida, cada viso abordar aspectos especficos da AS. A Seo 4.3 apresentar
a Viso Lgica, a partir de um ponto de vista funcional, relacionando os principais
mdulos e as operaes realizadas com mais frequncia. Por sua vez, a Seo 4.4
apresentar a Viso de Execuo, com o mapeamento dos componentes lgicos em
processos e threads. A Seo 4.5 apresentar a Viso de Implementao, seguido da
Seo 4.6 explicitando a Viso Fsica. Alm das vises deste mtodo, duas outras
vises definidas pelo SEI (Clements, 2003) foram utilizadas para facilitar a compreenso
41
CAPTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES

INTELIGENTES BASEADA NA INTERNET DAS COISAS
pelos stakeholders: Viso Componente Conector (Seo 4.7) e Viso de Dependncias

(Seo 4.8).
Por fim, a Seo 4.9 apresentar alguns dos principais cenrios de utilizao desta
AS, do ponto de vista de orgos governamentais e no-governamentais, cidados e
desenvolvedores.
Finalmente, a Seo 4.10 consolida as principais caractersticas da AS proposta
discutidas neste Captulo e a Seo 4.11 finaliza o Captulo.
4.1
Requisitos abordados
A partir da descrio dos requisitos realizada no Captulo 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
Composio de Dados urbanos
Sustentabilidade
Histrico de dados
Privacidade e Segurana dos dados
Aspectos sociais
Disponibilidade
Abordado
Sim
Sim
Sim
No
Sim
Sim
Sim
Sim
No
No
No
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 no foram includos
nesta proposta e 8 foram includos. Para realizar essa priorizao, dois fatores foram
ponderados: i) a importncia/relevncia 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 includo nesta proposta so os requisitos
mnimos que toda AS de software para CI deve atender.
Os demais requisitos que, mesmo considerados importantes/relevantes, no foram
abordados nesta proposta, dificilmente podem ser abordados nesta proposta no estgio
atual. A saber:
42
4.2. METODOLOGIA 4+1
Sustentabilidade: A proposta atual no possui nenhuma parceria com instituies

governamentais. Logo, nas 5 abordagens na qual esta requisito foi encontrado,
todas possuam uma parceria com as prefeituras locais, que criavam campanhas
para incentivar o consumo consciente dos cidados.
Privacidade e Segurana dos dados: De fato, esta necessidade foi identificada no
comeo desta pesquisa, porm 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 definies de interfaces e padres de mensagens
esto sendo definidas em conjunto. O escopo deste trabalho de privacidade criar
um mecanismo em que, a partir das interaes anteriores, os cidados possam
negociar o quo seus dados estaro disponveis para um determinado provedor de
servio urbano.
Aspectos sociais: Da mesma forma que o requisito de Sustenabilidade, para que
a AS atenda ao requisito de Aspectos Sociais necessrio o estabelecimento de
parcerias com as instituies governamentais para de fato incluir os cidados 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 aplicao por
dividi-la em um conjunto de componentes que interagem entre si para realizar parte de
uma ou vrias funcionalidades do sistema (Garlan and Shaw, 1994).
Porm, diversos autores relatam a falta de eficincia em documentar essas ASs para
que sejam legveis para os mais variados stakeholders (Garlan and Shaw, 1994; Clements,
2003). Visando atender essa ineficincia, em Kruchten (1995) proposto um mtodo de
descrio de ASs baseado em vises chamado 4+1. Para facilitar a compreenso pelos
stakeholders, duas outras vises definidas pelo SEI (Clements, 2003) foram utilizadas:
Viso Componente Conector e Viso de Dependncias. A integrao dessas vises
ilustrada na Figura 4.1.
Este uso de mltiplas vises permite abordar separadamente as preocupaes de vrios
stakeholders da AS: usurios finais, desenvolvedores, engenheiros de sistemas, gerentes
43

Viso Lgica
Viso
Componente
Conector
Viso Execuo
Cenrios
Viso Implementao
Viso
Dependncia
Viso Fsica
Figura 4.1 Integrao das vises do modelo 4+1 com as vises definidas pelo SEI
de projetos, entre outros; e permite avaliar separadamente os requisitos funcionais e no

funcionais. Estas vises abordam aspectos de relevncia arquiteturais sob diferentes
perspectivas:
A viso lgica aborda os elementos significativos do projeto para a AS adotada e a
relao entre eles. Entre os principais elementos esto os mdulos, os componentes,
os pacotes e as classes principais de aplicao;
A viso de execuo relata os aspectos de concorrncia e sincronizao do sistema,
mapeando os elementos da viso lgica de processos, threads e tarefas de execuo;
A viso de implementao centra-se em aspectos relacionados com a organizao
do cdigo-fonte do sistema, padres de AS utilizada e as orientaes e as normas
para o desenvolvimento do sistema;
A viso fsica demonstra as configuraes de hardware e o mapeamento dos
elementos de software para os elementos de hardware no ambiente do sistema;
A viso componente conector se refere ao comportamento dos componentes em
tempo de execuo e seus conectores, que so responsveis pela comunicao entre
estes;
A viso dependncias ilustra as dependncias existentes entre os mdulos da AS ;
Os cenrios mostram um subconjunto dos casos de uso significativo da AS.
44
4.3. VISO LGICA
No contexto de CI, diferentes stakeholders so envolvidos no processo de criao

de uma soluo eficiente, por exemplo, prefeito, secretarias pblicas, desenvolvedores
e cidados. Logo, o mtodo 4+1 foi escolhido e duas vises foram adicionadas para
descrever esta proposta arquitetural justamente para contribuir no entendimento por estes
diferentes stakeholders.
4.3
Viso Lgica
Esta Seo demonstra a organizao da AS a partir de um ponto de vista funcional. Os

principais elementos, como mdulos e componentes principais so especificados. A
interface entre estes elementos tambm especificada. A Figura 4.2 ilustra a arquitetura
do ponto de vista lgico.
Mdulo de
Acesso e
Comunicao
(MAC)
REST
Mdulo de
Persistncia 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
Configurao de recursos
Mdulo de
Gerenciamento
de Recursos
(MGR)
DHT Canal
de
dados
...
...
...
....
Canal 2
Canal 1
...
...
...
Canal 3
Mdulo de
Gerenciamento
e Distribuio
de Dados
(MGDD)
...
Figura 4.2 Viso lgica da Arquitetura de Software (AS) proposta
As subsees seguintes explicitaro cada mdulo, ressaltando sua responsabilidade e

os requisitos funcionais atendidos.
4.3.1
Mdulo de Acesso e Comunicao (MAC)
O Mdulo de Acesso e Comunicao (MAC) representa o ponto de entrada para as

aplicaes e servios externos. O MAC prov os mecanismos necessrios para o acesso e
45

a comunicao com a AS, a partir da interface REST (Representational state transfer).

De acordo com Blackstock et al. (2010) e Hernndez-Muoz et al. (2011), utilizar
uma interface padronizada, como REST, uma das tcnicas empregadas para tornar a
AS compatvel com as tecnologias mveis, como totens, smartphones e tablets. Esta
deciso arquitetural permite que a AS torna-se compatvel com o requisito de ubiquidade/mobilidade.
Alm disso, de acordo com Blackstock et al. (2010) e Filipponi et al. (2010), a
principal estratgia para que uma AS contemple a interoperabilidade de objetos permitir
a comunicao com dispositivos e sistemas atravs de diferentes protocolos de troca de
mensagens. Para tal, o MAC contm uma interface padronizada que permite a insero
de novos adaptadores que implementam os diferentes protocolos de troca de mensagem
sob demanda.
O funcionamento do MAC consiste em receber cada requisio dos diferentes recursos
e encaminh-las para os demais mdulos. Para isso, o MAC oferece todos os operaes
para interagir com a AS, por exemplo, operaes responsveis pelo Registro de Recursos,
como ser detalhado na seo a seguir. De acordo com a operao do mtodo, este delega
ao para o respectivo mdulo.
4.3.2
Mdulo de Gerenciamento de Recursos (MGR)
Do ponto de vista de uma AS para CI, um recurso pode ser considerado sensores espalhados pela cidade, um cidado portando um dispositivo mvel 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 Mdulo de Gerenciamento de Recursos (MGR) visa gerenciar as
informaes relativas a estes fornecedores de dados. Dentre essas informaes, a geolocalizao dos sensores deve ser mantida a fim de aumentar a eficincia e a confiabilidade do
dado fornecido (Hernndez-Muoz et al., 2011; Shao, 2011; Vega-Barbas et al., 2012).
Para tal, o MGR contm dois sub-mdulos: Registro e Configurao de recursos. O
Registro de Recursos contm operaes, acessveis a partir do MAC, que permitem o
registro de um recurso. Alm disso, a partir da existnca deste recurso, este sub-mdulo
disponibiliza todas as informaes de um recurso por toda a AS. J o sub-mdulo de
Configurao de Recursos possui operaes para gerenciar as configuraes do recurso,
por exemplo, a frequncia de tempo em que os dados so disponibilizados.
46
4.3. VISO LGICA
4.3.3
Mdulo de Gerenciamento e Distribuio de Dados (MGDD)
O Mdulo de Gerenciamento e Distribuio 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 distribuio de dados.
Um dos padres 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 contm uma implementao deste padro, representados
na Figura 4.2 pelas caixas com a letra P e C, respectivamente.
No MGDD, os fornecedores (publisher) fornecem dados em um canal especfico 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 tcnicas para modelar-se
eventos do mundo real em AS, pois permite disparar eventos simultneamente, na qual
pode-se ativar um ou mais eventos possivelmente encadeados (Filipponi et al., 2010;
Hernndez-Muoz et al., 2011; Sanchez et al., 2011; Wu et al., 2011; Fazio et al., 2012).
A implementao do padro publisher-subscriber no MGDD tambm possibilita a
adequao um dos mais importantes requisitos de uma AS para CI: a Composio 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 Seo 4.3.6
exemplificar esse cenrio.
Alm disso, o MGDD permite que novos canais de dados sejam criados sob demanda.
Esta peculiaridade proporciona certa flexibilidade para a AS, visto que no h restries
do limite para a criao 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
acessveis para todos os consumidores, atravs de consultas pelo tipo de dado que
disponibilizado. Da mesma forma, DHT utilizada para os fornecedores obterem a
referncias para os canais mais apropriados para fornecerem seus dados. A Seo 4.3.6
exemplificar este cenrio com um caso prtico.
Alm disso, a utilizao de uma DHT importante para prover escalabilidade e
processamento distribudo. A escalabilidade obtida a partir da criao de novos canais
de dados, a medida que o sistema se expande. Da mesma forma, como no h limite de
47

consumidores e fornecedores no mesmo canal de dado, a DHT permite a escalabilidade

em termos de recursos de dados.
J em relao ao processamento distribudo, a DHT permite que os canais de dados estejam distribudos 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 informaes deste canal, a partir das informaes
do MGR. Desta forma, uma camada de abstrao criada entre o canal e os consumidores e fornecedores, a fim de proporcionar maior desacoplamento, extensibilidade e
flexibilidade.
4.3.4
Mdulo de Persistncia de Dados (MPD)
O Mdulo de Persistncia de Dados (MPD) possui a responsabilidade de armazenar os

dados oriundos dos diferentes nveis da AS. Estes dados, em todos os nveis da AS, so
importantes para a predio de acontecimentos futuros, a partir do histrico de dados.
Para tal, o mdulo deve realizar consultas e inseres rpidas 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 especfico,
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 disponveis no
momento da transao, alm de permitir que os bancos de dados estejam distribudos 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 Mdulo
A Tabela 4.2 ilustra o mdulo no qual cada requisito contemplado. Como nota-se,
geralmente um requisito implementado a partir da combinao de dois ou mais mdulos
da AS.
4.3.6
Operaes
Esta Seo apresenta as principais operaes a serem realizadas na AS, a partir de

Diagramas de Sequncia.
48
4.3. VISO LGICA
Tabela 4.2 Mapeamento Requisitos por Mdulo

Requisito
Composio de Dados urbanos
Histrico de dados
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 abstrao 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 implementao da interface padronizada exigida para o
funcionamento correto do padro publisher-subscriber.
Inicialmente, este recurso deve solicitar a referncia do canal que contm o dado em
questo, a partir do mapeamento existente na DHT. Caso a DHT encontre este canal, a
referncia retornada. De posse da referncia, 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
Algum fornece o dado X?

Referncia ao Canal X
Subscriber
Novo dado
fornecido?
Envio de dados
Figura 4.3 Abstrao da operao de um recurso receber dados
49

Produtor: Fornecer dado

Por sua vez, o mecanismo para fornecer um dado bem parecido ao recebimento de um
dado. Existem dois cenrios especficos 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 referncia desse
canal que corresponde ao primeiro cenrio, como ilustrado na Figura 4.4.
Recurso
MGDD
DHT Canais
de dados

Envio de dados
Figura 4.4 Abstrao da operao de um recurso fornecer dado
Caso contrrio, a DHT retornar uma resposta de que o canal requisitado no existe,
como ilustrado na Figura 4.5. A partir desta resposta, o recurso fornecedor deve solicitar
uma nova referncia de canal para fornecer este tipo de dado, fornecendo as informaes
necessrias. Feito isso, a DHT retornar a referncia ao novo canal.
De posse da referncia ao canal que ser fornecido o dado, em ambos os casos, basta
o recurso fornecedor enviar os respectivos dados assim que eles estiverem disponveis.
Compor um dado urbano
A operao de compor um dado urbano pode ser considerada uma combinao entre as
operaes de Receber e Fornecer um dado. Como ilustrado na Figura 4.6, esta operao
dividida em 3 fases: Setup, Consumo de Dados e Criao de dados.
A primeira fase, Setup, corresponde aos passos necessrios para iniciar uma composio de dados urbanos. Inicialmente, o recurso deve consultar se o canal com o dado
50
4.3. VISO LGICA
Recurso
MGDD
DHT Canais
de dados

Canal no existente
Quero novo canal para fornecer dado X

Envio de dados
Figura 4.5 Abstrao da operao de um recurso fornecer um novo tipo de dado
que ser combinado j existe. Caso no exista, o recurso deve solicitar a disponibilizao
deste canal e a devida referncia deve ser retornada.
De posse da referncia 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 referncia de todos os canais que j fornecem os dados
que sero utilizados para a combinao. Aps obter a referncia de todos os canais, o
recurso deve se inscrever para receber os dados oriundos destes canais.
No h nenhuma restrio na quantidade de dados que podem ser utilizados para
combinao, ou seja, o recurso pode se inscrever em vrios canais para utilizar estes
dados na combinao.
Feito isso, inicia-se a terceira fase, Criao de Dados. Esta fase corresponde ao
mecanismo de receber os dados dos vrios canais inscritos, combin-los de alguma forma
utilizando algum tipo de regra de negcio e disponibiliz-lo no canal obtido na fase de
Setup.
Vale ressaltar que a fase de Criao de Dados a nica que continua sendo executada
em background por tempo indeterminado. Alm disso, ressalta-se que o momento em
que a nova informao combinada disponibilizada no canal resultante depende da regra
de negcio implementada. Por exemplo, um recurso de combinao de dados que gera
um relatrio das unidades de emergncia por regies de uma cidade pode consumir os
51

MDMD
Recurso
DHT Canal
de Dado
XY
Algum fornece do dado XY?

Canal no existente
Setup
Quero novo canal para fornecer o dado XY

Referncia ao novo Canal XY
Algum prov o dado X?

Referncia do Canal X
Algum prov o dado Y?
Consumo de
Dados
Referncia do Canal Y
.
.
.
Subscribe
Subscribe
.
.
.
Dado X
Dado Y
Criao de
Dados
Combina X
e Y
Informao Combinada XY
Figura 4.6 Operao de composio de dados urbanos
dados de cada unidade e gerar esse relatrio uma vez por dia.
4.4
Viso de Execuo
Esta Seo apresenta o mapeamento dos componentes lgicos da AS em processos e

threads em tempo de execuo, resumidos na Tabela 4.3.
4.4.1
Mdulo de Acesso e Comunicao (MAC)
O MAC possui um processo principal responsvel por receber as requisies oriundas

dos mais variados tipos de clientes. Alm disto, este processo responsvel 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. VISO DE EXECUO
Tabela 4.3 Resumo da quantidade de processos e threads em tempo de execuo
Mdulo
MAC
MGR
MGDD
MPD
Processos
1 por adaptador + 1 principal
1 por sub-mdulo + 1 principal
4 processos principais
Threads
1 por requisio
1 por operao
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
relao as requisies, uma thread criada para cada requisio, j que as requisies
so gerenciadas de forma independente.
4.4.2
Mdulo de Gerenciamento de Recursos (MGR)
O MGR possui um processo principal que responsvel por conter todas as interfaces das
operaes visveis aos demais mdulos. Alm disto, cada cada sub-mdulo executado
em processo separado para que tcnicas de cache possam ser futuramente desenvolvidas
de forma eficiente.
As operaes que sero realizadas nos sub-mdulos devem ser eficientes a ponto de
no comprometer a computao do recurso requisitante. Logo, para cada operao, uma
thread iniciada para tratar est requisio. A sincronizao das informaes ser feita
utilizando tcnicas de sincronizao por transao.
4.4.3
Mdulo de Gerenciamento e Distribuio de Dados (MGDD)
O MGDD possui quatro processos principais: (i) o primeiro corresponde ao processo

responsvel pela implementao dos canais de dados; na mesma linha, um processo necessrio para controlar os (ii) consumidores e (iii) outro para os fornecedores; finalmente,
(iv) o ltimo processo responsvel por gerenciar a DHT.
Como cada recurso, seja este consumidor ou fornecedor de dado, independente dos
demais e contm as suas prprias dependncias para realizar a computao, 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

4.4.4
Mdulo de Persistncia de Dados (MPD)
Por sua vez, o MPD constitui-se de dois processos: gerenciador de instncias de banco
de dados e a DHT. Este gerenciador responsvel por obter os dados dos diferentes
mdulos e armazenar no respectivo banco de dados para a predio de eventos futuros.
Da mesma forma que o MGDD, cada instncia de banco de dados constitui uma novo
processo. Estes novos processos tambm podem ser executadas em um host diferente.
4.5
Viso de Implementao
Esta Seo descreve as estratgias utilizadas para a implementao de referncia do

sistema de acordo com a AS estabelecida. Esta implementao est disponvel em
domnio pblico1 .
A AS proposta visa atender alguns requisitos considerados como no funcionais,
porm no menos importante, como escalabilidade e flexibilidade. Logo, a infraestrutura
a ser utilizada para implementao deve ser robusta para atender os diversos sistemas
que a utilizaro, alm da macia quantidade de dados. Alm disto, como a AS proposta
contm vrios 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; Martn et al., 2009).
Neste contexto, a plataforma OSGi consolida-se como uma das mais indicadas para
aplicaes na qual hot-deploy de suma importncia (Touseau et al., 2008; Martn et al.,
2009). Conforme definido por Gama and Donsez (2010) :
A plataforma de servio OSGi2 um middleware universal para desenvolvimento de
aplicaes modulares, usando princpios de SOA para implementar o desacoplamento
entre componentes. A tecnologia OSGi aproveita a modularizao na plataforma Java,
que permite instalar, atualizar, para iniciar, parar e desinstalar componentes em tempo
de execuo sem a necessidade de reinicializao do sistema. A plataforma OSGi
composta por um conjunto de especificaes, conduzido por um consrcio de empresas.
As especificaes so realizadas por diferentes implementaes 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. VISO DE IMPLEMENTAO
No contexto deste trabalho, a plataforma OSGi foi utilizada para proporcionar maior
modularidade, escalabilidade e facilitar a manuteno de componentes. Dentre as implementaes de OSGi, foi escolhida o Equinox, pela familiariade com o arcabouo 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
organizao dos bundles que representam a implementao dos respectivos componentes,
do ponto de vista de implementao sobre o Equinox.
RestLet
GSON
Rest
Interface
Mensagem
C
Registro
de
Recursos
Configura
-o de
Recursos
Event
Admin
DHT
Canal de
Dados
DHT
Banco de
Dados
Mongo
DB
EQUINOX
MAC
MGR
MGDD
MPD
Figura 4.7 Viso de Implementao
Ao anlisar a imagem 4.7, nota-se que o bundle responsvel pela MAC contm um
adaptador com a implementao inicial de JSON7 utilizando a bibilioteca fornecida pelo
Google Inc. conhecida como GSON8 . Este bundle comunica-se ativamente com o bundle
responsvel pela comunicao via REST. Por sua vez, o mdulo REST implementa
utilizando o framework Restlet9 .
Em relao ao mdulo 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

de Recursos e Configurao de Recursos. Estes dois bunddles representam os processo

descritos previamente.
J no mdulo MGDD, a implementao do padro publisher-subscriber foi realizada
utilizando o servio oferecido pelo prprio OSGi Equinox denominado EventAdmin.
O EventAdmin corresponde um servio que contm a implementao de canais de
distribuio de dados, na qual consumidores de dados podem se inscrever nos respectivos
tpicos 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 ilustrao correspondente ao mdulo MPD exemplifica a utilizao de um
banco de dados especfico, conhecido como MongoDB10 . Similarmente DHT Canal
de Dados, a DHT Banco de Dados utiliza as informaes 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
Viso Fsica
Esta Seo visa descrever os requisitos fsicos mnimos para utilizao da AS proposta.
Por se tratar de um ambiente distribudo, com vrios acessos exigindo o mximo de
escalabilidade, de suma importncia a utilizao de um ambiente Cloud.
Para propsitos de testes e validaes, foi utilizada uma infraestrutura mnima do
servio Amazon AWS11 . A Tabela 4.4 resume as principais caractersticas de hardware e
software dessa infraestrutura.
Para a utilizao em um ambiente real de produo evidente que esta configurao
no suficiente. Nesse contexto, deve-se analisar as solues 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. VISO COMPONENTE CONECTOR
Tabela 4.4 Requisitos fsicos de utilizao da arquitetura
Requisito
Configurao
Hardware
Plano Amazon AWS

Memria 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
Verso 2.4.1
GSON
Verso 2.2.4
MongoDB
Verso 2.4.6
Servidor Web
Jetty 7
4.7
Viso Componente Conector
Esta seo se refere ao comportamento dos componentes em tempo de execuo e seus

conectores, que so responsveis pela comunicao 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 so Recurso

e Dado. Apesar destes dois componentes fazerem parte logicamente do MGR, eles
so utilizados pelos demais mdulos da AS. No prprio MGR, estes componentes so
utilizados pelos mdulos de Configurao e Gerenciamento de Recurso. Os dados que
trafegam na AS so representados pelo componente Dado. Toda vez que um determinado
57

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 comunicao realizada a partir do outro
componente REST.
O MGDD contm uma porta para cada canal de dado. Esta porta uma abstrao
para a comunicao realizada com os diversos Recursos consumidores ou fornecedores
de dados. Alm disto, o MGDD contm um componente denominado DHT com as
responsabilidades j descritas na Seo Viso Lgica. Como pode ser observado, o
MGDD possui um conector para cada recurso associado um canal.
Por sua vez, o MPDD possui conectores associados aos mdulos MGR e MGDD
para que as informaes trafegadas nestes dois mdulos possam ser armazenadas para a
predio de eventos futuros. Alm disto, uma porta associada cada instncia de banco
de dados.
4.8
Viso de Dependncias
Esta seo visa ilustrar as dependncias existentes entre os mdulos da AS. A Figura 4.9
ilustra o diagrama de dependncias entre os mdulos desta proposta.
Figura 4.9 Diagrama de Dependncias
Como pode ser observado na Figura 4.8, apesar do MGDD ser o core da AS, o mdulo
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, alm de gerenciar os respectivos
dados.
Por sua vez, o MGR contm dependncia apenas do MAC. Esta dependncia deve-se
ao fato do MAC ser a porta de entrada e sada dos sistemas externos com a AS. Logo,
para que um recurso consiga receber de fato os dados necessrio utilizar os mecanismos
providos pelo MAC.
58
4.9. CENRIOS
Assim como no diagrama de Componentes Conectados, o MPDD possui dependncia

com os mdulos MGR e MGDD para que as informaes trafegadas nestes dois mdulos
possam ser armazenadas para a predio de eventos futuros.
4.9
Cenrios
Esta Seo visa apresentar alguns dos principais cenrios de utilizao da AS proposta.
4.9.1
Desenvolvimento de aplicaes mveis
Um desenvolvedor pode criar aplicaes mveis que consumam informaes das cidades
e mantenham seus usurios atualizados sobre os acontecimentos. Por exemplo, uma
aplicao que identifique os pontos de alagamento em uma avenida ou registre regies
afetadas pela falta de energia.
Do ponto de vista da arquitetura proposta, esta proposta deveria ser implementada
da seguinte forma. Um recurso, correspondendo aplicao, deve realizar todas as
interaes com a arquitetura atravs da interface REST, disponvel do MAC. O primeiro
passo registrar aplicao como um recurso no MGR. Para isto, a aplicao deve
invocar o respectivo mtodo oferecido pelo MAC, provendo as devidas informaes do
recurso.
Em seguida, este recurso deve consultar a DHT Canais de Dados para obter as
referncias para todos os canais que oferecem as informaes relevantes da respectiva
cidade. Aps se inscrever nestes canais, assim que um novo dado disponibilizado, a
aplicao deve receb-los a partir de consultas REST. De posse destes dados, a aplicao
pode exibi-los da maneira mais adequada.
4.9.2
Emitir Alertas com Informaes de Trnsito
As companhias de gerenciamento de trnsito das cidades podem utilizar esta arquitetura

para emitir informaes de trnsito da cidade. Para isso, basta registrar cada sensor como
um recurso fornecedor de dado na arquitetura. Estes sensores podem ser as cmeras de
trnsito, informaes de veculos em radares e quantidade de veculos nas cabines de
pedgio por minuto.
Alm disso, ser necessrio registrar um recurso consumidor no MGR responsvel
por se inscrever nos canais nas quais esto informaes sero fornecidades. A partir disto,
59

este recurso deve interpretar estas informaes e gerar os alertas de acordo com a situao
do trnsito.
4.9.3
Definio de Estratgia Efetiva de Investimento de Recursos
As secretarias das prefeituras podem definir estratgias para aplicao dos recursos
especficos 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 informaes em forma de grfico ou at mesmo notificar os respectivos responsveis, alm de
estimar o custo para resolver aquele problema.
4.9.4
Predio de Catastrfes em reas de Riscos
Um sistema pode ser desenvolvido para predizer catastrfes 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 informaes anteriores associadas rea,
por exemplo, informaes da quantidade de chuva nos ltimos veres.
De posse destas diferentes informaes, o recurso pode implementar uma lgica que
permite inferir conhecimentos a partir destas informaes, por exemplo, usando uma
tcnica de Rede Neural. Estas informaes 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 informaes contextualizadas e consolid-las no sistema de predio de
catastrfes.
4.10
Discusso do Captulo
O conjunto de cenrios descrito constitui exemplos de utilizao da AS. Por ser uma AS
para propsito genrico, esta pode ser facilmente adaptada para os contextos locais de
cada regio. Pode-se imaginar diversos cenrios de utilizao, desde uma regio litornea
utilizar a AS para executar programas de balneabilidade at o controle de obesidade dos
idosos de uma regio.
Alm desta flexibilidade em relao ao propsito da AS, pode-se facilmente identificar
que esta proposta flexvel em termos de aplicabilidade. Por exemplo, inicialmente
60
4.11. CONSIDERAES FINAIS DO CAPTULO
concebida para ser aplicada em uma cidade, esta AS pode ser implementada em diversas
escalas, como um prdio (Smart Build) e residncias (Smart Home).
A partir desta flexibilidade, governos e instituies podem usar esta AS para criar
vrias instncias federativas, como por exemplo, uma instncia para regio de Sorocaba,
outra para Campinas e uma ltima para a regio metropolitana de So Paulo. A partir
dessa configurao, essas 3 instncias podem interagir para as estratgias de atuao.
Por fim, necessrio ressaltar que os requisitos de hardware discutidos foram suficientes para testes em pequena escala, porm no sero suficientes no ambiente de
produo real. Esta fato se deve principalmente a fatores relacionados a concorrncia,
acessos simultneos e performance.
Logo, esse quesito prtico no pode ser considerado suficiente para a avaliao da
proposta. Dessa forma, o Captulo seguinte descreve um mtodo para avaliao da AS
proposta, ressaltando os resultados obtidos ao aplic-lo.
4.11
Este Captulo iniciou-se apresentando o sub-conjunto de requisitos abordados nesta

proposta na Seo 4.1. Para guiar a descrio desta proposta, a Seo 4.2 apresentou o
mtodo de descrio de ASs utilizado, conhecido como 4+1, que, quando combinado
com duas outras vises definidas pelo SEI, se mostrou ser bastante efetivo para o contexto
deste trabalho.
Em seguida, a AS proposta foi apresentada, de acordo com as vises do mtodo:
Lgica (Seo 4.3), Execuo (Seo 4.4), Implementao (Seo 4.5), Fsica (Seo 4.6),
Viso Componente Conector (Seo 4.7) e Viso de Dependncias (Seo 4.8). A Viso
Lgica apresentou, a partir de um ponto de vista funcional, os principais mdulos e as
operaes frequentemente realizadas. Por sua vez, a viso de Execuo mostrou o mapeamento dos componentes lgicos em processos e threads. A Viso de Implementao
apresentou a implementao de referncia que foi realizada e est disponvel m domnio
pblico14 . A Viso Fsica relatou algumas caractersticas de hardware utilizadas para est
implementao de referncia. Por fim, as duas vises definidas pelo SEI foram descritas
para facilitar a compreenso pelos stakeholders.
Ao trmino das descries das Vises, pode-se compreender as responsabilidades
e a comunicao entre os seis mdulos da AS proposta. O mdulo MCA corresponde
ao ponto de comunicao da AS com os sistemas externos. J o MGR corresponde
14 https://github.com/gustahrodrigues/Synaptic
61

manuteno dos recursos na AS, principalmente ao cadastro e configurao dos mesmos.

Por sua vez, o mdulo MGDD responsvel por difundir os dados de/para os recursos
na AS. Finalmente, o mdulo MPD responsvel por armazenar todas as informaes
relevantes, em qualquer ponto da AS, para consultas posteriores.
Esse conjunto de mdulos compe a proposta que visa agregar valores para os
cidados das cidades do Brasil. Alguns desses cenrios foram discutidos neste Captulo
(Seo 4.9), ressaltando principalmente o ponto de vista das entidades que podem propor
estratgias em prol do cidado.
Finalmente, a Seo 4.10 abordou algumas caractersticas importantes da AS proposta.
A partir da descrio da AS reaizada neste Captulo, o prximo Captulo descreve um
mtodo para avaliao, baseado em dois mtodos: SAAM e ATAM.
62
5
Avaliao da Arquitetura de Software
Obstculo aquilo que voc enxerga quando tira os olhos do seu

objetivo.
JUSTIN HERALD, 2006 Its All a Matter of Attitude
A disciplina de avaliao de Arquitetura de Software (AS) tem se mostrado uma

importante ferramenta para quantificar a qualidade de um software a partir da sua descrio AS (Kazman et al., 1994). De fato, alguns experimentos industriais mostraram
que a aplicao de mtodos de avaliao de AS gera ganhos considerveis durante o
desenvolvimento de software. Em Maranzano et al. (2005) so relatados vrios exemplos
da utilizao do processo de valiao 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 milho de dlares em cada projeto que teve seus
problemas identificados e resolvidos previamente.
Sendo assim, podemos concluir que to importante quanto definir a arquitetura de um
sistema de software tentar realizar uma avaliao do que foi definido, com o objetivo
de identificar as falhas antes que se tornem grandes problemas no futuro. Logo, a partir
da descrio de mdulos realizada no Captulo anterior, este Captulo visa avaliar a AS
proposta.
Para tal, inicialmente, sero apresentados alguns mtodos de avaliaes de ASs
disponveis na literatura (Seo 5.1). Ao analisar esses mtodos, foi concludo que
nenhum deles atendia o contexto deste trabalho. Logo, a Seo 5.2 prope uma adaptao
de dois mtodos de avaliao de ASs amplamente aceitos e validados na literatura
1 http://www.att.com/
2 http://www.lucent.com/
63
CAPTULO 5. AVALIAO 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 avaliao desta AS
(Seo 5.3).
Em seguida, a Seo 5.4 discute alguns resultados e comentrios a respeito das
principais questes que surgiram durante a avaliao desta AS. Alm disso, a Seo 5.5
discute as principais ameaas avaliao realizada.
Por fim, a Seo 5.6 consolida as principais caractersticas do mtodo proposto e dos
resultados obtidos a partir do processo de avaliao utizado.
5.1
Mtodos de Avaliao
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 importncia que a avaliao da qualidade do software seja iniciada antes mesmo da
implementao, para que possveis erros arquiteturais sejam identificados e corrigidos a
fim de minimizar custos.
Para realizar tal procedimento, um mtodo de avaliao utilizado para guiar os
procedimentos de execuo e auxiliar na interpretao dos resultados. Embora os mtodos
de avaliao de AS possam variar quanto s tcnicas que utilizam, pode-se dizer que, de
uma maneira geral, os mtodos possuem um propsito em comum (Kazman et al., 2005).
Este propsito : investigar se uma determinada AS satisfaz os objetivos de negcio do
sistema para o qual foi projetada.
Logo, a seguir apresentada uma breve descrio de alguns mtodos baseados em
cenrios que serviram de base para a adaptao utilizada na avaliao da AS proposta.
5.1.1
Mtodos Analisados
A literatura apresenta vrios mtodos de avaliao, com diferentes objetivos e contextos de

execuo, como pode-se constatar nos relatos de Roy and Graham (2008), Shanmugapriya
and Suresh (2012); Bass and Nord (2012).
A partir dessas referncias, um conjunto de mtodos candidatos a ser utilizado foi
estabelecido. Para filtrar esse conjunto de mtodos, a primeira condio a ser utilizada
foi os atributos de qualidade (QA) que o mtodo visa avaliar. Como a AS proposta no
possui uma nica finalidade, que possa ser avaliada por um nico atributo de qualidade,
optou-se por adotar mtodos que compreendem vrios atributos de qualidade. A Tabela
5.1 apresenta os mtodos encontrados, nas referncias relatadas anteriormente, que
satisfazem esse pr-requisito.
64
5.1. MTODOS DE AVALIAO
Tabela 5.1 Mtodos de Avaliao Vs Atributos de Qualidade
Mtodo
SAAM
ATAM
SBAR
SACAM
DoSAM
Atributo de Qualidade
Modificabilidade e funcionalidade, mas pode ser adaptado para outros
Vrios Atributos de Qualidade
Um outro fator que deve ser levado em considerao no momento de escolher qual
mtodo de avaliao utilizar o objetivo do mtodo (Clements, 2003). Logo, a Tabela
5.2 apresenta o objetivo de cada mtodo resultante do pr-requisito anterior.
Tabela 5.2 Mtodos de Avaliao Vs Objetivo
Mtodo
SAAM
ATAM
SBAR
SACAM
DoSAM
Objetivo
Adequao arquitetural e identificao de riscos
Foco em sensibilidade da arquitetura e anlise trade-off
Avaliar arquiteturas legadas a partir de reengenharia, utilizando Domain
Specific Software Architecture, para criar uma base reutilizvel e flexvel
Comparao com outras arquiteturas de software descritas na literatura
Comparao com outras arquiteturas de software descritas na literatura
A partir destas duas pr-condies, nota-se que o mtodo SBAR no pode ser utilizado
pois a AS proposta no uma legada. Por sua vez, SACAM e DoSAM no devem ser utilizados, pois no h nenhuma outra AS, disponvel e amplamente aceita na literatura, que
possa ser comparada com a AS proposta, devido a falta de especificao e detalhamento
arquitetural.
Por fim, restaram apenas dois mtodos 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 descrio de cada um desses mtodos apresentada.
5.1.2
Descrio dos mtodos restantes
SAAM (Software Architecture Analysis Method) um mtodo de avaliao 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
O mtodo SAAM inclui 6 atividades: (i) desenvolvimento dos cenrios; (ii) descrio da AS avaliada; (iii) classificao e priorizao dos cenrios; (iv) avaliao dos
cenrios individual e indireta; (v) interao entre os cenrios; (vi) avaliao global
dos cenrios (Kazman et al., 1994).
Algumas das principais vantagems do SAAM so a melhoria na documentao da
AS e a identificao de riscos (Kazman et al., 1994).
ATAM (Architecture Tradeoff Analysis Method) um mtodo baseado em cenrios, porm, mais complexo se comparado ao SAAM. A aplicao do ATAM
revela quo bem uma AS satisfaz os requisitos de qualidade desejados, alm de identificar os riscos arquiteturais e os conflitos (trade-offs) existentes para se alcanar
tais requisitos (Qun-li and jie, 2008).
O ATAM inclui 4 atividades principais: (i) Descrio: apresentao do ATAM, dos
objetivos de negcios e da AS; (ii) Investigao e Anlise: gerao dos atritos de
qualidade utilizando utility tree; anlise das abordagens arquiteturais; brainstorm e
priorizao dos cenrios; (iii) Testes: Anlise da AS proposta; (iv) Apresentao
dos Resultados (Kazman et al., 1999, 2000).
5.2
5.2.1
Adaptao dos mtodos de avaliao

Definio do mtodo de avaliao
Apesar dos dois mtodos restantes serem os mais adequados para a AS proposta, o
contexto de aplicao do mtodo no condizia com o contexto deste trabalho, devido as
seguintes peculiaridades:
A equipe de avaliao estava distribuda geograficamente, com rotinas e compromissos diferentes. Logo, a avaliao deveria ser totalmente remota;
Na equipe de avaliao, no h nenhum stakeholder com domnio em ambos os
temas de pesquisa que envolvem esta proposta (CI e IoT);
No foi encontrada nenhum mtodo de avaliao para o contexto de equipes
distribuda geograficamente;
Como as reunies seriam realizadas por Skype, as reunies deveriam ser curtas
para manter a equipe concentrada.
66
5.2. ADAPTAO DOS MTODOS DE AVALIAO
Logo, surgiu a necessidade de propor uma adaptao dos dois mtodos a fim de sanar
essas peculiaridades. Esta adaptao baseada no SAAM e ATAM, porm as atividades
so especficas para o contexto remoto. Apesar disto, nenhuma nova etapa foi criada,
pelo contrrio, 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 mtodo
adaptado.
Tabela 5.3 Etapas do mtodo adaptado
1
2
3
4
5
6
7
8
9
10
5.2.2
Apresentao do Processo de avaliao

Apresentao dos Objetivos de Negcios
Apresentao da AS
Priorizao dos QAs
Contextualizao sobre cenrios
Apresentao dos cenrios
Priorizao dos cenrios
Avaliao dos cenrios propostos
Avaliao das interaes entre Cenrios e QAs
Consolidao dos Resultados
Equipe de Avaliao
A primeira etapa para a definio do mtodo de avaliao a ser utilizado foi a escolha
da equipe de avaliao. Devido ao fato de que CI pode ser considerado um sistema de
sistemas heterogneos, as pessoas escolhidas para participar da equipe so de diferentes
reas de pesquisa, com diferentes experincias e vises. Alm disso, a heterogeneidade
da equipe enriquece as discusses, 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 avaliao. 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
Descrio do Mtodo de Avaliao
Inicialmente o processo de avaliao deve ser descrito, ressaltando principalmente quais

os artefatos esperados de cada etapa. Em seguida, como recomenda o SAAM, um
67
Tabela 5.4 Expertises da equipe de avaliao
Expertise
Doutores ou Doutorandos
Mestres ou Mestrandos
Engenheiros de Sistemas
Especialistas em Cloud Computing
Especialistas em IoT
Especialistas em Arquiteturas escalveis
Especialistas em Arquiteturas de propsito geral
Especialistas em Negcios
#
3
2
4
1
2
2
2
2
participante da equipe de avaliao com a viso de negcio deve apresentar as expectativas

de uma AS para CI que combine IoT. Esta etapa de suma importncia, pois estas
expectativas sero utilizadas para quantificar o quo a AS proposta atende aos objetivos
estabelecidos.
A prxima etapa consiste na apresentao da AS propriamente dita. Nesta etapa, o
arquiteto pode utilizar o mtodo de descrio arquitetural que lhe interesse. Entretanto,
este mtodo deve fornecer subsdios suficientes para o completo entendimento da AS por
parte dos demais participantes, incluindo interaes entre os mdulos, regras de negcios
e o ciclo de vida dos componentes (Kruchten, 1995).
Em seguida, deve-se realizar a etapa de priorizao dos atributos de qualidade com
base nos objetivos de negcios, 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 mtodos de priorizao dos atributos
de qualidade, porm o mais usual estabelecer que cada participante possui 3 votos
que deve ser distribudo dentre os atributos de qualidade. Aps todos os participantes
votarem, os atributos de qualidade que receberem mais votos devem ser considerados
mais prioritrios.
A contexualizao sobre o que so cenrios para toda a equipe de avaliao deve
ser realizada a seguir. Um cenrio, neste contexto, ilustra os tipos de atividades que um
sistema deve suportar. Um exemplo de cenrio pode ser: Qual o impacto na arquitetura
caso ocorra uma mudana no modelo de troca de mensagens entre os componentes. Vale
ressaltar que o desenvolvimento desses cenrios crucial para capturar os principais usos
do sistema, seus usurios, antecipar mudanas no sistema, e qualidades que o sistema deve
satisfazer agora e no futuro. Estes cenrios devem ser elicitados por todos os stakeholders
do sistema a partir dos objetivos de negcios, logo, representam questes sob diferentes
68
5.3. PROCESSO DE AVALIAO EXECUTADO
pontos de vista e, na maioria das vezes, trazem informaes bem especficas do sistema
avaliado.
Antes da prxima etapa deste processo de avaliao importante criar algum mecanismo para que os participantes possam propor os possveis cenrios. Uma tcnica que
pode ser utilizada o compartilhamento de uma planilha online entre cada participante e
o arquiteto.
Aps todos os membros da equipe de avaliao escrevem os possveis cenrios, o
arquiteto deve consolidar os cenrios propostos. Esta consolidao resume-se em filtrar os
cenrios duplicados e reescrever alguns com outras palavras para facilitar a compreenso.
No incio da prxima etapa, todos os cenrios propostos pelos participantes devem ser
apresentados, para que os demais participantes conheam os diferentes pontos de vista.
Em seguida, todos devem priorizar os cenrios de acordo com a relevncia para a AS
proposta. Esta priorizao pode ser feita da mesma forma que a priorizao dos QAs.
Para a prxima etapa, de avaliao dos cenrios propostos, tambm interessante
criar um mecanismo para que seja realizada remotamente. Um exemplo a criao de um
formulrio online na qual cada participante deve dar uma nota para o quo cada cenrio
est contemplado pela AS.
Feito isso, na etapa seguinte o arquiteto deve conduzir uma discusso a respeito das
interferncias dos atributos de qualidades nos cenrios priorizados, como descrito pelo
ATAM. Geralmente estas discusses geram concluses de que, para atender a um cenrio
especfico, 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 avaliao.
Nesta etapa importante apresentar todos os artefatos gerados em cada etapa do processo
de avaliao. Alm disso, devem ser apresentados os pontos positivos e os pontos de
melhoria que, a partir do processo executado, foram identificados.
5.3
Processo de Avaliao Executado
A partir da descrio do processo de avaliao na Seo anterior, o processo foi executado

remotamente via Skype e as etapas foram divididas em 3 reunies:
5.3.1
Primeira Reunio
O objetivo da primeira reunio foi apresentar os objetivos de negcios da AS proposta e

contextualizar todos os envolvidos no processo de avaliao em relao temtica de CI.
69
As etapas da reunio foram as seguintes:

1. Apresentao do Processo de Avaliao (Durao 30min): Inicialmente, foi
descrito a origem da adaptao dos mtodos, ressaltando as principais diferenas
com os mtodos disponveis na literatura. Consequentemente, o processo de
avaliao a ser utilizado foi descrito. O objetivo desta etapa foi situar todos os
envolvidos em relao ao objetivo do processo e aos prximos passos;
2. Objetivos de Negcios (Durao 30min): A segunda etapa da reunio teve a
inteno de definir e apresentar os objetivos de negcios da AS proposta. Este
passo foi importante para que os participantes da avaliao entendessem o contexto
do sistema e tambm as limitaes tcnicas, econmicas e de cronograma existentes
para a execuo do projeto. Todos esses aspectos foram apresentados para ajudar na
definio dos atributos de qualidade a serem considerados no processo de avaliao;
3. Apresentao da AS (Durao 1hora): Neste passo, a AS proposta foi detalhada
pelo arquiteto atravs de uma viso de mdulos. Para tal, foi utilizado o framework
de descrio AS conhecido como 4+1 (Kruchten, 1995). Cada mdulo foi detalhado, ressaltando, principalmente, o requisito arquitetural que este visa atender.
Alm da viso de mdulos, foi apresentada a comunicao entre os mdulos. Esta
apresentao foi de suma importncia para os participantes perceberem como os
requisitos foram implementados para avaliar se de fato eles satisfazem as necessidades dos contextos de CI. Alm disso, por meio desta descrio detalhada
possvel identificar possveis falhas e/ou pontos de melhoria na AS proposta;
4. Priorizao dos Atributos de Qualidade (Durao 1hora): Como alguns participantes no estavam acostumados ao conceito de Atributos de Qualidade, inicialmente foi descrito o que so 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 possveis atributos de qualidade aplicveis AS proposta.
Ao trmino dessa etapa, os participantes sugeriram alguns atributos de qualidade,
com base nos objetivos de negcios. Em seguida, foi realizado uma votao para
priorizar quais os atributos melhor expressam os objetivos de negcios, apresentados anteriormente. Nesta votao, cada participante poderia distribuir 3 votos
entre os atributos de qualidade. Cada voto foi computado individualmente a partir
de um formulrio online disponibilizado para cada envolvido. A Tabela 5.5 exibe
70
o resultado desta votao. A coluna fonte, refere-se origem do atributo de

qualidade, na qual participante so os atributos propostos pelos participantes da
avaliao.
Tabela 5.5 Priorizao dos Atributos de Qualidade
#
1
2
3
4
5
6
7
8
9
10
11
QA
Confiabilidade
Funcionalidade
Escalabilidade
Portabilidade
Disponibilidade
Segurana
Performance
Eficincia
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 definies consideradas para os atributos foram:

Confiabilidade: visa avaliar se a arquitetura estar disponvel quando necessrio;
Funcionalidade: conjunto de atributos que evidenciam a existncia de um
conjunto de funes e suas propriedades especificadas. As funes so as que
satisfazem as necessidades explcitas ou implcitas;
Escalabilidade: capacidade que um sistema possui de se expandir, de forma
a permitir o atendimento das necessidades pelo crescimento do nmero de
usurios do sistema, ou tambm pelo aumento das informaes 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;
Segurana: refere-se ao conjunto de propriedades da arquitetura que interferem diretamente na garantia da integridade dos dados da aplicao e no
acesso aos mesmos;
71
Performance: visa quantificar se a arquitetura computar os dados em tempo

hbil, coerente com o contexto da requisio;
Eficincia: conjunto de atributos que interferem diretamente nos tempos de
resposta de um sistema;
Usabilidade: conjunto de atributos que evidenciam o esforo necessrio para
se poder utilizar o software, bem como o julgamento individual desse uso,
por um conjunto explcito ou implcito de usurios;
Acoplamento: refere-se ao grau de dependncia entre os componentes de
software;
Manutenabilidade: atributos do software que evidenciam o esforo necessrio para modific-lo, remover seus defeitos ou adapt-lo a mudanas.
5. Contextualizao sobre Cenrios (Durao 20min): O ltimo passo dessa primeira reunio, foi a contextualizao sobre cenrios. Da mesma forma como os
atributos de qualidade, inicialmente foi realizada uma breve apresentao sobre
o que so e quais as necessidades dos cenrios. Em seguida, alguns cenrios
foram exemplificados, como Disponibilizar um novo tipo de dado e Combinar
informaes de duas ou mais fontes de dados.
Por fim, uma planilha foi compartilhada com cada participante para que eles
pudessem detalhar os cenrios de utilizao da AS com base nos objetivos de negcios. Para isso, um prazo de 4 dias foi estipulado para que todos os participantes
descrevessem os possveis cenrios.
5.3.2
Segunda Reunio
A Segunda Reunio foi marcada uma semana depois da primeira reunio, para mitigar o
risco dos participantes esquecerem algum tpico abordado.
Aps os 4 dias estipulados para que todos os participantes descrevessem os cenrios,
o arquiteto consolidou todos os cenrios. Esta consolidao resumiu-se em, basicamente,
filtrar os cenrios duplicados e reescrever alguns com outras palavras para facilitar a
compreenso dos demais participantes. Apenas 2 cenrios foram considerados duplicados
e 1 precisou ser reescrito.
1. Apresentao dos Cenrios (Durao 30min): Nessa primeira etapa da segunda
reunio, foram apresentados todos os cenrios propostos pelos participantes da
72
avaliao no prazo estipulado. Como vrios participantes possuem diferentes

vises e experincias, foram identificados diferentes nichos de aplicabilidade da
AS proposta, por exemplo, em contextos totalmente distribudos ou, at mesmo,
em contextos federados.
2. Priorizao dos Cenrios (Durao 1hora): A segunda etapa foi uma discusso
conduzida pelo arquiteto na qual o objetivo era a priorizao dos cenrios. Essa
discusso foi guiada pelo arquiteto, na qual cada cenrio foi discutido e um peso de
relevncia foi atribudo para cada cenario. Essa priorizao levou em considerao
os cenrios mais aplicveis, coerentes e factveis na AS proposta.
3. Avaliao dos Cenrios propostos (Durao 1hora): Em seguida, os cenrios
priorizados foram avaliados e discutidos sobre a AS proposta. O principal objetivo
foi avaliar o quo os cenrios levantados condizem com a natureza da AS proposta.
Ao trmino desta reunio, os cenrios resultantes so exibidos na Tabela 5.6, ordenados de acordo com a priorizao.
5.3.3
Terceira Reunio
Da mesma forma que a Segunda Reunio, a Terceira e ltima reunio foi marcada uma
semana depois. O objetivo primordial dessa reunio foi consolidar os resultados e definir
as possveis aes a serem tomadas para aprimorar a proposta.
Para tal, foi criado um formulrio online com todos os cenrios, ordenados por ordem
de priorizao. O objetivo deste formulrio foi de mensurar quantitativamente o quo a
AS contempla cada cenrio.
1. Avaliao das interaes entre Cenrios e Atributos de Qualidade (Durao
1hora): Nesta primeira etapa da reunio, os participantes discutiram o quo os
cenrios priorizados conflitavam com os atributos de qualidade.
2. Consolidao dos Resultados (Durao 1hora): Nesta etapa os resultados foram
apresentados. Primeiramente, um overview sobre cada artefato gerado durante o
processo foi apresentado, principalmente a priorizao dos atributos de qualidade e
os cenrios. A prxima Seo detalhar esses resultados.
A Seo a seguir resume os resultados obtidos com o processo de avaliao de AS
realizado.
73
Tabela 5.6 Cenrios resultantes de acordo com a relevncia
ID
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
5.4
Cenrio
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 informaes sejam fornecidas, a partir da
combinao de uma ou mais fontes de dados
Permitir a incluso de novos provedores de dados
A AS deve auxiliar a interoperabilidade entre sistemas, na qual um
evento gerado externamente pode disparar aes
A AS deve auxiliar a fuso de dados, na qual um evento produzido
internamente com base na anlise de dados/histrico pode gerar aes
externas
A AS deve permitir a comunicao via API
A AS deve permitir a recuperao de grandes massas de dados
histricas de diversas fontes, a fim de obter previses que dizem respeito
prestao de servios urbanos
Fornecer algum mecanismo para tolerncia a falhas (redundncia)
Permitir a criao e comunicao de instncias federativas, baseada em
servios
Possuir mecanismo para a incluso de novos protocolos de comunicao
na AS
Plugar novas solues para diferentes contextos utilizando a mesma
infraestrutura
Suporte a servios em Cloud Computing j existentes (Ex.: Google
Analytics e cloud storage)
Gerenciar os dados do usurio de acordo com as polticas de privacidade
governamentais
Resultados da Avaliao da Arquitetura
Um dos benefcios de se realizar qualquer avaliao de Arquitetura de Software (AS) a

melhoria de comunicao entre os stakeholders, resultando em um melhor entendimento
dos requisitos.
Logo, conforme descrito na Seo anterior, para mensurar quantitativamente o quo
a AS contempla cada cenrio, foi criado um formulrio online com todos os cenrios,
ordenados por ordem de priorizao. Neste formulrio, cada participante deveria atribuir
uma nota para a adequao de cada cenrio, na qual 5 representa que a AS ATENDE
TOTALMENTE e 0 significa que NO ATENDE ao cenrio em questo.
74
5.4. RESULTADOS DA AVALIAO DA ARQUITETURA
A partir deste formulrio, foram obtidas algumas concluses, que sero exemplificadas
nas posteriores subsees.
5.4.1
Resultados da Avaliao dos Cenrios
Cada participante respondeu o formulrio online independentemente. A partir disso, o

arquiteto consolidou todas as respostas anonimamente. A figura 5.1 ilustra a mdia e o
desvio padro das respostas, alm de 3 faixas de satisfatoriedade, definidas pelos prprios
participantes da avaliao.
Figura 5.1 Resultado da avaliao dos cenrios
Para analisar os resultados na Figura 5.1, deve ser considerada a relevncia dos
cenrios propostos, priorizados durante o processo de avaliao.
Como possvel notar, na opinio dos participantes, a AS atende trs cenrios
de maneira EXCELENTE. O primeiro cenrio (C2) relacionado aos mecanismos
de distribuio de dados implementados no MGDD (Seo 4.3.3), principalmente a
utilizao da DHT de dados. Conforme discutido, a utilizao da DHT permitiu que os
recursos fornecedores e consumidores e os canais de dados estejam distribudos em uma
infraestrutura de cloud.
J o segundo cenrio categorizado como EXCELENTE (C4) foi obtido a partir da
implementao do padro publisher-subscriber tambm no MGDD. Esta implementao
permite que um dado seja disponibilizado para todos os recursos consumidores assim
que produzido. No contexto de CI, esta caracterstica bsica de suma importncia se
todos os consumidores receberam os dados simultneamente e est contemplada nesta
proposta. Alm disso, o desacoplamento entre fornecedores e consumidores de dados
oriundos a partir do padro publisher-subscriber tambm de suma importncia para
75
futuras expanses da AS.

O ltimo cenrio avaliado positivamente (C7) oriundo do modelo de abstrao e da
flexibilidade implementada no MAC (Seo 4.3.1). Esta abstrao 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 padro
em paralelo.
A maioria dos cenrios foram considerados SATISFATRIOS pelos participantes da
avaliao. Embora este resultado indique que a AS, em uma primeira instncia, atende a
um conjunto de contextos de utilizao, ela deve ser aprimorada para atender de maneira
segura e eficiente aos demais contextos.
Alm disso, dois cenrios foram classificados como PSSIMO. O primeiro (C9) est
relacionado insero de algum mecanismo de tolerncia a falhas. No foi encontrado
nenhum mecanismo semelhante nas abordagens encontradas na literatura. Porm, no
contexto de uma CI inadmissvel que todo o sistema da cidade deixe de funcionar devido
um problema em algum mdulo ou componente de software. A literatura apresenta
diversas tcnicas de redundncia, tanto de dados como de componentes de software, que
devem ser inseridas na proposta. Alm disso, estratgias de backup, controle de acesso e
demais aspectos relacionados confiabilidade da proposta devem ser investigadas.
O outro cenrio que foi classificado como PSSIMO (C14) corresponde s polticas
de privacidade de dados utilizadas pela AS. Conforme pde ser verificado, este requisito
no faz parte desta AS. Alm disso, esta necessidade foi identificada no comeo desta
pesquisa, porm 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 definies de interfaces e padres de mensagens esto sendo definidas em conjunto. O
escopo deste trabalho de privacidade criar um mecanismo em que, a partir das interaes
anteriores, os cidados possam negociar o quo seus dados estaro disponveis para um
determinado provedor de servio urbano.
5.4.2
Resultados Gerais
Esta sub-seo visa elencar os resultados gerais obtidos a partir do processo de avaliao
executado. Estes resultados foram extrados a partir das discusses com os participantes
e no necessariamente so observados nos artefatos do processo.
Primeiramente, o fato de dois de trs cenrios categorizados como EXCELENTE
estarem diretamente relacionado ao MGDD era esperado. O MGDD pode ser considerado
o core da proposta, principalmente devido ao mdulo de distribuio de dados utilizado.
76
5.5. AMEAAS AVALIAO
Este modelo, utilizando o padro publisher-subscriber foi encontrado em outros contextos

e adaptado para esta proposta. Alm disso, a alta quantidade de requisitos que o MGDD
visa satisfazer representa os principais diferenciais desta proposta com as demais.
Este fato alerta para possveis problemas relacionados ao acoplamento do MGDD
com o restante da AS. Por exemplo, deve-se prever e criar mecanismos para mitigar os
possveis problemas no MGDD relacionados indisponibilidade da DHT Canais de Dados. Caso isso acontea, os demais mdulos devem continuar funcionando corretamente
a partir de mecanismos de redundncia.
Alm disso, de acordo com os participantes, no necessrio descrever um novo
padro arquitetural para o contexto de CI e IoT. Esta concluso foi obtida a partir da
avaliao de que a proposta atual contempla alguns padres arquiteturais e j atende
diversos cenrios de utilizao.
De maneira geral, estes resultados mostram que a AS pode e deve ser utilizada em um
contexto real, para, de fato, verificar a adequao 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 orgos interessados.
5.5
Ameaas Avaliao
Na avaliao da arquitetura descrita previamente, algumas ameaas foram identificadas.

Estas ameaas no afetam diretamente o resultado final desta avaliao, porm devem ser
analisadas para trabalhos futuros.
A primeira ameaa est relacionada quantidade de pessoas envolvidas no processo
de avaliao. Por mais que a equipe tenha vrias expertises diferentes englobando vrias
reas de uma cidade, como recomendado por Clements (2003), se mais pessoas tivessem
participado da avaliao outros pontos de vistas poderiam ser levantados. Infelizmente,
este pequeno nmero de participantes foi devido disponibilidade do grupo de pesquisa
para a realizao das trs reunies mencionadas.
A outra ameaa est relacionada com a ordem das etapas do mtodo de avaliao.
Como apresentao da arquitetura foi realizada antes da definio e priorizao dos
atributos de qualidade e dos cenrios, a opinio dos participantes pode ter sido enviesada.
Apesar disto, no inicio das etapas de definio e priorizao dos atributos de qualidade
e dos cenrios foi ressaltado que as opinies deveriam ser a partir da apresentao dos
objetivos de negcios. Logo, uma melhoria no mtodo de avaliao alterar a ordem
destas etapas.
77
5.6
Este Captulo iniciou-se apresentando os filtros aplicados nos mtodos de avaliao

disponveis na literatura Seo 5.1. Estes filtros foram aplicados de acordo com o
contexto da avaliao a ser executada.
Aps estes filtros, os mtodos SAAM e ATAM foram considerados os mais indicados.
Porm, a verso original destes mtodos no condiz com o contexto desta avaliao. Logo,
a Seo 5.2 props uma adaptao destes dois mtodos de avaliao de ASs amplamente
aceitos e validados na literatura.
Finalmente, a Seo 5.3 apresentou todas as etapas do processo de avaliao executado.
Por fim, a Seo 5.4 discutiu os principais resultados da avaliao.
A partir da avaliao realizada, pode-se mensurar o quo a AS est apta para ser
implantada em um contexto real. Dessa forma, o prximo Captulo finaliza o trabalho
descrevendo as principais concluses e as atividades futuras, como implantar a AS em
um ambiente real e controlado.
78
6
Concluso
Feliz aquele que transfere o que sabe e aprende o que ensina.
CORA CORALINA, 2007 (Vintm de cobre: meias confisses de
Aninha. 9. ed . So Paulo: Global.)
Uma vez que a AS para Cidade Inteligente (CI) foi especificada e projetada, algumas
concluses e direes para trabalhos futuros podem ser apontadas.
Desta forma, este Captulo apresenta as concluses finais deste trabalho e est organizado da seguinte maneira: a Seo 6.1 apresenta um resumo das principais concluses
deste trabalho. A Seo 6.2 relata alguns trabalhos relacionados. A Seo 6.3 aponta
um conjunto de trabalhos futuros, e finalmente, a Seo 6.4 contm a concluso final da
dissertao.
6.1
Principais Concluses
Esta Seo resume as principais concluses deste trabalho, enumeradas abaixo:

O crescimento populacional desenfreado, combinado com outras questes de m
governana, tem potencializado os problemas urbanos. Estes problemas esto
relacionados aos diversos servios de uma cidade, como sade, transporte e lazer.
Consequentemente, estes problemas afetam diretamente o dia-a-dia dos cidados e
dificultam o gerenciamento das cidades pelos gestores (Seo 1.1).
Apesar da evidente necessidade de cidades cada vez mais inteligentes, ainda no
h um consenso sobre a definio mais adequada para o termo CI. Mesmo assim,
vrias abordagens esto sendo desenvolvidas com o paradigma de utilizar IoT
como ferramenta para a implementao, de fato, de uma CI. Neste contexto, as
79
CAPTULO 6. CONCLUSO
tecnologias IoT so utilizadas, principalmente, para monitorar, controlar e atuar

sobre os diversos servios urbanos (Captulo 2).
Na literatura, vrias abordagens esto sendo desenvolvidas com este paradigma.
Porm, a maioria destas abordagens focam em apenas um conjunto muito restrito
de servios urbanos e no consideram a integrao entre estes servios (Captulo
3).
A AS proposta por esta dissertao permite que os dados entre os diferentes
servios urbanos sejam difundidos para todos os recursos interessados. Para tal, a
AS implementa um padro arquitetural bastante conhecido na literatura chamado
de publisher-subscriber (Captulo 4).
Para avaliar a AS proposta, dois mtodos de avaliao arquitetural foram adaptados
para o contexto deste trabalho. Esta adaptao mostrou-se bastante til, uma vez
que os principais benefcios citados na teoria, tais como composio de dados
urbanos, foram confirmados (Seo 5.4).
6.2
Trabalhos Relacionados
Em PlanIT (2012) foi adotada uma estratgia de implementar um Sistema Operacional

Urbano (UOS). Este sistema operacional consiste em uma plataforma que visa integrar
cada domnio que compe a cidade. O sistema alimentado por uma vasta rede de
sensores e todos esses dados so capturados por tempo indeterminado, para auxiliar na
tomada e na predio de decises. Alm de prever catstrofes, caso ocorra, o sistema pode
antever todos os possveis impactos na cidade. As principais diferenas da abordagem de
PlanIT (2012) e esta proposta so a parceria com setor privado (PlanIT (2012) possui uma
parceria com Cisco e Microsoft) e o modelo de distribuio de dados, uma vez que no
modelo adotado em PlanIT (2012) a disponibilizao de um novo tipo de dado custosa,
do ponto de vista arquitetural.
Outra abordagem em que se utilizam vrios 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 refncia de arquitetura para sistemas IoT do mundo real; ii) um escalvel, heterogneo e confivel facilitador
de experimentos; iii) um conjunto representativo de casos de uso implementados para
facilidades de experimentao e iv) um grande conjunto de experimentos e resultados
sobre o futuro da internet. A principal diferena da abordagem descrita por Sanchez et al.
80
6.2. TRABALHOS RELACIONADOS
(2011) com esta proposta, alm da parceria com o setor privado, so os mecanismos que
permitem a composio de dados urbanos. Na proposta deste trabalho, assim que um
dado novo disponilizado, permite-se a criao de um novo canal para este dado. Alm
disto, esta proposta contempla mecanismos de gereo de histrico, que fundamental
para a tomada de decises futuras.
Por sua vez, em Filipponi et al. (2010) a integrao de sensores abordada a partir
de uma AS baseada em eventos, na qual cada evento corresponde mudana de estado
de qualquer sistema de TIC. Estes eventos podem ser iniciados a partir de eventos do
mundo real (como deteco de presena) ou ao trmino de algum processamento. A
abordagem de Filipponi et al. (2010) bastante similar com esta proposta no quesito de
modelagem do ambiente real. Porm, a principal diferena a existncia nesta proposta
de um mecanismo para gerao de histrico para a previso de futuros eventos. Alm
disto, as informaes de cada sensor que est fornecendo os dados pode ser utilizada
para otimizar o desempenho dos algoritmos (Shao, 2011; Hernndez-Muoz et al., 2011;
Vega-Barbas et al., 2012).
Neste sentido, em Hernndez-Muoz et al. (2011) proposta uma AS (USN), com o
objetivo de prover uma infraestrutura que seja capaz de integrar sensores heterogneos
e dispersos geograficamente em um base centralizadora, na qual servios podem ser
facilmente desenvolvidos. Esta abordagem de Hernndez-Muoz et al. (2011) similar a
esta proposta nas tcnicas adotadas para permitir a integrao de sensores heterogneos.
A principal diferena que nesta proposta novos protocolos de troca de mensagens podem
ser facilmente inseridos. Alm 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 princpios: aplicaes, negcios, gerenciamento de processos e infraestrutura de redes. O
primeiro princpio corresponde s aplicaes que fazem uso de diferentes tecnologias
para monitorar sensores, como GPS. A maioria dessas aplicaes atendem as demandas
operacionais das cidades, porm, ao utilizar as regras definidas no segundo princpio negcios - elas podem agregar solues economicamente viveis. O terceiro princpio o
gerenciamento de processos no qual relacionamentos, regras, estratgias e polticas entre
as aplicaes e as unidades de negcios so definidos. O ltimo princpio corresponde a
toda a infraestrutura de rede, responsvel por conectar os outros trs princpios. A principal diferena da abordagem de Al-Hader et al. (2009) para esta proposta a criao de
um componente especfico para modelos de negcio. Este diferencial pode ser facilmente
incorporado nesta proposta, uma vez que este componente poderia ser um consumidor de
81
CAPTULO 6. CONCLUSO
dado que, a partir dos dados que esto trafegando na arquitetura, inferir um modelo de
negcios eficaz com estas informaes.
Ao analisar os principais trabalhos relacionados, pde-se observar que todos visam
mitigar apenas uma deficincia tecnolgica relacionada CI. Apenas a abordagem de
PlanIT (2012) visa integrar as informaes provenientes de diferentes domnios de uma
cidade, o que pode contribuir para tornar uma cidade de fato inteligente.
Alm 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 srie de caractersticas que qualquer Arquitetura de
Software (AS) para Cidade Inteligente (CI) deveria atender.
Os resultados desta dissertao esto baseados em um trabalho de pesquisa que
analisou o estado da arte e da prtica no tocante as ASs de software para CI que
combinam tecnologias IoT. Estes resultados envolvem, entre outras coisas: (i) um
levantamento das solues existentes, (ii) a extrao de um conjunto de requisitos que
uma AS para CI deve atender, (iii) o projeto da AS, (iv) a avaliao preliminar da AS e
(v) uma implementao de referncia.
6.3
Trabalhos Futuros
A verso inicial desta AS no contempla algumas caractersticas, principalmente as

questes relatadas na Seo 1.4, e os resultados da avaliao da AS:
Utilizao 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, adequao ao contexto deste trabalho.
Mecanismo de tolerncia falhas: Estratgias de redundncia devem ser implementadas para que os servios urbanos no sejam afetados devido a uma eventual
falha em algum ponto da AS;
Polticas de privacidade: J que vrios dados pessoais dos cidados trafegaro
pela AS, torna-se indispensvel a adequao de polticas de privacidade, principalmente relacionadas ao armazenamento, utilizao e descarte dos dados;
Modelo de Negcio: Modelos de negcios devem ser discutidos para suprir os
custos envolvendo a implementao, manuteno e expanso desta AS no ambiente
real. Uma estratgia que deve ser discutida a parceria com governos e empresas
para a utilizao desta AS;
82
6.4. CONCLUSO
Anlises de big data: Com o alto volume de dados potencialmente gerado a partir
da utilizao desta AS, anlises de big data devem ser feitas para otimizar o
desempenho dos servios urbanos;
Semntica dos Dados: Futuras pesquisas podem investigar a melhor estratgia de
semntica dos dados a ser implementada nesta proposta.
6.4
Concluso
A necessidade de cidades cada vez mais inteligentes notoriamente crescente. Vrios

dados publicados pela mdia em geral comprova que o crescimento populacional no est
alinhado com o desenvolvimento das infraestruturas e dos principais servios urbanos.
A precariedade destes servios urbanos afeta negativamente a qualidade de vida dos
cidados.
Logo, torna-se fundamental o investimento em estratgias que visam mitigar estes
problemas urbanos para otimizar a vida dos cidados. Estas iniciativas devem ser desenvolvidas considerando as partes envolvidas: governo e cidados. Alm disso, torna-se
importante que os cidados estejam conscientes do seu papel em prol de uma cidade
melhor para todos.
Neste sentido, esta dissertao apresentou a especificao e o projeto de uma AS para
CI que permite a integrao de tecnologias IoT para mitigar estes problemas urbanos.
Esta AS foi proposta a partir de um conjunto de requisitos mais importante extrado das
principais abordagens disponveis na literatura.
83
Referncias Bibliogrficas
Al-Hader, M., Rodzi, A., Sharif, A., and Ahmad, N. (2009). Smart city components
architicture. In Computational Intelligence, Modelling and Simulation, pages 9397.
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 18. 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 1921.
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 229234. 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 460464. IEEE.
Atzori, L., Iera, A., and Morabito, G. (2010). The internet of things: A survey. Comput.
Netw., 54(15), 27872805.
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 277281.
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), 669671.
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 18.
85
REFERNCIAS BIBLIOGRFICAS
Booch, G. (2010). Enterprise architecture and technical architecture. Software, IEEE,

27(2), 9696.
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 8190, 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 17221727, 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
International Conference on Pervasive Computing and Communications, PERCOM

08, pages 509514, 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:11: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 281286, 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), 18.
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-Milanovic, 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 relao entre as
classes sociais e o consumo de energia eltrica residencial do municpio de foz do
87
iguau do estado do paran. 8 congresso internacional sobre gerao distribuda de

energia no meio rural.
Hernndez-Muoz, J. M., Vercher, J. B., Muoz, L., Galache, J. A., Presser, M., Gmez,
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 447462. 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 8190, 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 5463.
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),
329355.
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
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), 715.
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 260260, 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 1320.
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), 4250.
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, 5663.
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), 6875.
Maranzano, J., Rozsypal, S., Zimmerman, G., Warnken, G., Wirth, P., and Weiss, D. M.
(2005). Architecture reviews: practice and experience. Software, IEEE, 22(2), 3443.
Marceau, J. (2008). Introduction: Innovation in the city and innovative cities. Innovation:
Management, Policy & Practice, 10(2-3), 136145.
89
Martn, J., Seepold, R., Madrid, N., lvarez, J., Fernndez-Montes, A., and Ortega, J.
(2009). A home e-health system for dependent people based on osgi. In N. Martnez Madrid and R. Seepold, editors, Intelligent Technical Systems, volume 38 of
Lecture Notes in Electrical Engineering, pages 117130. 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 18. 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 15. 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 282291. 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 4354.
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
20012004.
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
and experimentation and the smart cities. In Future Network & Mobile Summit
(FutureNetw), pages 18. 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), 1926. 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 163166.
Sommerville, I. (2007). Software Engineering. Addison Wesley, 8 edition.
Spnola, R. O. and Travassos, G. H. (2012). Towards a framework to characterize
ubiquitous software projects. Inf. Softw. Technol., 54(7), 759785.
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
10281031.
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 410417.
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 415422, Washington, DC, USA.
IEEE Computer Society.
91
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 725730.
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 115.
92
Apndice
93
A
Repositrios de busca na SLR
Tabela A.1 Repositrios 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)
Intelligent Environments (IE)
Multimedia
Information
Networking and Security
(MINES)
Emerging Technologies for a
Smarter World (CEWIT)
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
Avaliao da Arquitetura de
Software (AS)
Figura B.1 Printscreen do formulrio online utilizado pelos participantes para propor os cenrios
de uso da AS
97
APNDICE B. AVALIAO DA Arquitetura de Software (AS)
Figura B.2 Printscreen da Parte 1/3 do formulrio online para quantificar a adequao da AS
aos respectivos cenrios
98
99
APNDICE B. AVALIAO DA Arquitetura de Software (AS)
100

Uma Arquitetura para Cidades Inteligentes Baseada Na Internet Das Coisas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uma Arquitetura para Cidades Inteligentes Baseada Na Internet Das Coisas

Uploaded by

Copyright:

Available Formats

Universidade Federal de Pernambuco

Ps-graduao em Cincia da Computao

Uma Arquitetura de Software para

Universidade Federal de Pernambuco

Gustavo Henrique Rodrigues Pinto Tomas

Uma Arquitetura de Software para Cidades Inteligentes

Orientador: Vinicius Cardoso Garcia

RECIFE, Fevereiro de 2014

minha famlia, por sempre me proporcionar totais

Primeiramente gostaria de agradecer a Deus por me proporcionar todas as condies

capacidade de atingir seus objetivos.

According to recent researches, global population is increasing disproportionally from the

Viso Geral da Soluo Proposta . . . . . . . . . . . . . . . . . . . . .

Viso Geral da Arquitetura de Software (AS) . . . . . . . . . .

Cidades Inteligentes e Internet das Coisas

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

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

Integrao de Cidade Inteligente (CI) com Internet of Things (Internet

Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .

Reviso da Literatura de Arquiteturas de Software para Cidades Inteligentes

Estratgia de Busca e Fontes de Dados . . . . . . . . . . . . . .

Seleo das Abordagens . . . . . . . . . . . . . . . . . . . . .

Consolidao das Abordagens Encontradas . . . . . . . . . . . . . . .

Requisitos para uma Arquitetura de Software para Cidades Inteligentes .

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

Privacidade e Segurana dos dados . . . . . . . . . . . . . . . .

Geolocalizao dos sensores . . . . . . . . . . . . . . . . . . .

Composio de Dados Urbanos . . . . . . . . . . . . . . . . .

3.4.11 Sensoriamento e Processamento Distribudo . . . . . . . . . . .

Sumrio dos Requisitos para Cidades Inteligentes . . . . . . . . . . . .

Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .

Uma Arquitetura de Software para Cidades Inteligentes baseada na Internet

Mdulo de Acesso e Comunicao (MAC) . . . . . . . . . . .

Mdulo de Gerenciamento de Recursos (MGR) . . . . . . . . .

Mdulo de Gerenciamento e Distribuio de Dados (MGDD) .

Mdulo de Persistncia de Dados (MPD) . . . . . . . . . . . .

Mapeamento Requisito x Mdulo . . . . . . . . . . . . . . . .

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

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

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

Mdulo de Acesso e Comunicao (MAC) . . . . . . . . . . .

Mdulo de Gerenciamento de Recursos (MGR) . . . . . . . . .

Mdulo de Gerenciamento e Distribuio de Dados (MGDD) .

Mdulo de Persistncia de Dados (MPD) . . . . . . . . . . . .

Viso Componente Conector . . . . . . . . . . . . . . . . . . . . . . .

Desenvolvimento de aplicaes mveis . . . . . . . . . . . . .

Emitir Alertas com Informaes de Trnsito . . . . . . . . . . .

Definio de Estratgia Efetiva de Investimento de Recursos . .

Predio de Catastrfes em reas de Riscos . . . . . . . . . . .

4.10 Discusso do Captulo . . . . . . . . . . . . . . . . . . . . . . . . . .

4.11 Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .

Avaliao da Arquitetura de Software

Descrio dos mtodos restantes . . . . . . . . . . . . . . . . .

Adaptao dos mtodos de avaliao . . . . . . . . . . . . . . . . . . .

Definio do mtodo de avaliao . . . . . . . . . . . . . . . .

Descrio do Mtodo de Avaliao . . . . . . . . . . . . . . .

Processo de Avaliao Executado . . . . . . . . . . . . . . . . . . . . .

Resultados da Avaliao da Arquitetura . . . . . . . . . . . . . . . . .

Resultados da Avaliao dos Cenrios . . . . . . . . . . . . . .

Consideraes Finais do Captulo . . . . . . . . . . . . . . . . . . . .

A Repositrios de busca na Systematic Literature Review (Reviso Sistemtica

Arquitetura de Software (AS) da soluo proposta . . . . . . . . . . . .

Resultado da avaliao dos cenrios . . . . . . . . . . . . . . . . . . .