Gustavo Henrique Rodrigues Pinto Tomas
UMA ARQUITETURA PARA CIDADES INTELIGENTES BASEADA
NA INTERNET DAS COISAS
Dissertação de Mestrado
Universidade Federal de Pernambuco
[email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE
2014
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Gustavo Henrique Rodrigues Pinto Tomas
UMA ARQUITETURA PARA CIDADES INTELIGENTES BASEADA
NA INTERNET DAS COISAS
Trabalho apresentado ao Programa de Pós-graduação em
Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para
obtenção do grau de Mestre em Ciência da Computação.
Orientador: Vinicius Cardoso Garcia
Coorientador: Alexandre Alvaro
RECIFE
2014
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno, CRB 4-1758
Tomas, Gustavo Henrique Rodrigues Pinto.
Uma arquitetura para cidades inteligentes
baseada na internet das coisas. – Recife: O Autor,
2014.
109f. : fig.
Orientadora: Vinícius Cardoso Garcia.
Dissertação (Mestrado) - Universidade Federal de
Pernambuco. Cin. Ciência da computação , 2014.
Inclui referências e apêndice.
1. Engenharia de software . 2. Internet das coisas. I.
Garcia, Vinícius Cardoso. (orientador). II. Título.
005.1
(22. ed.)
MEI 2014-56
Dissertação de Mestrado apresentada por Gustavo Henrique Rodrigues Pinto Tomas à
Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade
Federal de Pernambuco, sob o título “Uma Arquitetura para Cidades Inteligentes
Baseada na Internet das Coisas” orientada pelo Prof. Vinicius Cardoso Garcia e
aprovada pela Banca Examinadora formada pelos professores:
______________________________________________
Prof. Kiev Santos da Gama
Centro de Informática / UFPE
______________________________________________
Prof. Gibeon Soares de Aquino Junior
Departamento de Informática e Matemática Aplicada/UFRN
_______________________________________________
Prof. Vinícius Cardoso Garcia
Centro de Informática / UFPE
Visto e permitida a impressão.
Recife, 26 de fevereiro de 2014.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
À minha família, por sempre me proporcionar totais
condições para a realização dos meus estudos.
Aos meus irmãos, que esta dissertação sirva de inspiração
para suas futuras decisões profissionais.
À Crisley, por sempre estar ao meu lado e me ajudar a ver o
lado bom de tudo.
Dedico.
Agradecimentos
Primeiramente gostaria de agradecer a Deus por me proporcionar todas as condições
para a realização deste trabalho e, principalmente, por ter colocado em meu caminho pessoas
muito especiais que me ajudaram nesta aventura. Algumas destas pessoas serão brevemente
citadas a seguir:
Agradeço ao meu orientador Vinicius Cardoso Garcia, pela orientação, pelo espírito
acolhedor, pelo incentivo e pelas cobranças, totalmente necessárias, para me manter o tempo
todo focado no objetivo final. Não poderia deixar de agradecer a liberdade e abertura para
discutir novas ideias e definir novas metas, sem deixar de lado a qualidade do trabalho. Os
questionamentos e a experiência de outras áreas foram de suma importância para a concretização
da proposta. A coragem em se aventurar em uma área de pesquisa recente, na qual ninguém
possuía muita experiência, fatalmente separa os vencedores dos medrosos. Além disso, a
confiança em permitir, que uma parte do mestrado seja realizada remotamente, certamente foi
uma atitude de uma pessoa grande, tanto profissionalmente quanto espiritualmente.
Ao grande pesquisador e amigo Alexandre Alvaro pela ajuda e compartilhamento de
suas experiências antes mesmo de iniciar o mestrado. Certamente daquele dia em diante, você
começou a ser observado com olhos de admiração. Agradeço também por ter apresentado a
área de pesquisa e, principalmente, as oportunidades que estavam envolvidas. Os feedbacks do
trabalho sempre contribuíram de forma muito positivamente, assim como os bate-papos, por
mais “viajados” que fossem.
Ao grande irmão de consideração Welington Manoel da Silva, pelo tempo de convivência, pelos aprendizados deste período e, principalmente, pela paciência e bom humor para
enfrentarmos juntos toda aquela situação. Em relação à parte técnica, todos os questionamentos
e palpites foram fundamentais para o aprimoramento da proposta. A forma pelo qual Welington compartilhou seus conhecimentos comigo certamente evidencia uma das suas principais
características: compaixão com o próximo.
Agradeço a minha família pela compreensão nos dias em que fiquei trancado no quarto e
nos dias de indisponibilidade para conversar por telefone. Em especial aos meus pais Érica e
Elcio, agradeço ao suporte que, por mais que não seja o que eles gostariam de proporcionar, foi
muito mais do que o suficiente para a minha formação, tanto como homem quanto profissional.
Ainda em relação à família, agradeço aos meus irmãos Larissa e Júnior, por aturarem o meu mau
humor quando as coisas pareciam estar desabando. Sinceramente, espero que este novo objetivo
alcançado na minha vida sirva de exemplo para que eles acreditem nos respectivos potenciais e,
principalmente, na capacidade de atingir seus objetivos.
Não poderia de deixar de fora a minha amiga, companheira, revisora de textos em inglês
e português: Crisley. A sua compaixão e o seu jeitinho singular foram as forças que eu precisava
nos momentos de maiores dificuldades. Olhando para trás, não consigo enxergar outra forma de
enfrentar os meus desafios sem o seu positivismo. A compreensão e a paciência para enfrentar 9
meses à distância certamente comprovaram que somos iguais ao amanhecer: independente do
que aconteça, sempre estaremos juntos para enfrentar qualquer tipo de escuridão.
Ao Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) pela coragem e
confiança em aceitar o desafio de conciliar a rotina de trabalho de 40h semanais com as disciplinas
do mestrado. Nesse sentido, gostaria de agradecer imensamente os meus gestores Paulo Urbano
e Roberta Hazin pela coragem, compreensão e, principalmente, por não aliviarem as minhas
tarefas, o que contribuiu muito para a minha formação acadêmica e profissional. Espero que eles
tenham a consciência de que esse tipo de atitude afetou, e muito, positivamente a vida de uma
pessoa. Certamente gestores com esse perfil deveriam ser supervalorizados nas suas atribuições.
Considero a forma como a situação foi conduzida um exemplo a ser seguido na minha vida.
Finalmente, gostaria de agradecer a todos que de alguma forma, direta ou indiretamente,
contribuíram para a realização deste trabalho.
Resumo
De acordo com recentes pesquisas, a população mundial esta crescendo de forma desproporcional aos recursos necessários para a vida humana. Cada vez mais a quantidade de pessoas
vivendo nas áreas urbanas aumenta, devido à diversos fatores, como as oportunidades que são
geradas nestes grandes centros.
Este desenfreado crescimento populacional, principalmente nas áreas urbanas, além de
outros fatores como má governança, ocasiona e/ou intensifica diversos problemas urbanos. Para
exemplificar este fato, pode-se citar os grandes problemas que as cidades brasileiras enfrentam
nas áreas de transporte, saúde e educação, evidenciados, rotineiramente, pela mídia em geral.
Neste contexto, o conceito de Cidade Inteligente (CI) visa mitigar estes problemas a
fim de aumentar a qualidade de vida dos cidadãos. Para tal, uma importante ferramenta para a
implementação de uma CI é a Internet of Things (Internet das Coisas) (IoT), na qual diversos
objetos são combinados para atingir um objetivo em comum como, fornecer informações do
fluxo de veículos de uma cidade.
Porém, para que este cenário seja de fato consolidado, necessita-se de uma Arquitetura
de Software (AS) capaz de integrar e combinar as diferentes tecnologias e dados que compõem
os serviços urbanos.
Na literatura pode-se encontrar várias Arquiteturas de Software (AS’s) para CI, inclusive
com apoio de grandes empresas. Porém, estas AS’s visam atender apenas um determinado
serviço urbano com uma aplicação específica, o que não caracteriza de fato uma implementação
de CI.
Motivado por estes desafios, esta dissertação apresenta a especificação, o projeto e
a avaliação de uma AS para CI que permite a integração com IoT, baseado no conjunto de
requisitos extraídos das soluções existentes. Adicionalmente, são discutidos os resultados
obtidos, os problemas encontrados, e as direções futuras para pesquisa e o desenvolvimento.
Palavras-chave: Cidades Inteligentes, Internet das Coisas, Arquitetura de Software
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
Lista de Figuras
1.1
Arquitetura de Software (AS) da solução proposta . . . . . . . . . . . . . . . .
25
3.1
3.2
Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultado da filtragem das abordagens . . . . . . . . . . . . . . . . . . . . . .
39
40
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Integração das visões do modelo “4+1” com as visões definidas pelo SEI
Visão lógica da Arquitetura de Software (AS) proposta . . . . . . . . .
Abstração da operação de um recurso receber dados . . . . . . . . . . .
Abstração da operação de um recurso fornecer dado . . . . . . . . . . .
Abstração da operação de um recurso fornecer um novo tipo de dado . .
Operação de composição de dados urbanos . . . . . . . . . . . . . . .
Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de Componente Conector . . . . . . . . . . . . . . . . . . .
Diagrama de Dependências . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
61
63
66
66
66
67
70
71
72
5.1
Resultado da avaliação dos cenários . . . . . . . . . . . . . . . . . . . . . . .
88
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.1 Printscreen do formulário online utilizado pelos participantes para propor os
cenários de uso da AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Printscreen da Parte 1/3 do formulário online para quantificar a adequação da
AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Printscreen da Parte 2/3 do formulário online para quantificar a adequação da
AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4 Printscreen da Parte 3/3 do formulário online para quantificar a adequação da
AS aos respectivos cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
107
107
107
Lista de Tabelas
3.1
3.2
3.3
3.4
Quantidade de abordagens por fonte de pesquisa
Abordagens resultantes por ordem cronológica
Resumo das abordagens descritas na literatura .
Mapeamento requisitos-arquiteturas . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
42
49
56
4.1
4.2
4.3
4.4
Requisitos abordados . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapeamento Requisitos por Módulo . . . . . . . . . . . . . . . . . .
Resumo da quantidade de processos e threads em tempo de execução
Requisitos físicos de utilização da arquitetura . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
65
68
71
5.1
5.2
5.3
5.4
5.5
5.6
Métodos de Avaliação Vs Atributos de Qualidade
Métodos de Avaliação Vs Objetivo . . . . . . . .
Etapas do método adaptado . . . . . . . . . . . .
Expertises da equipe de avaliação . . . . . . . .
Priorização dos Atributos de Qualidade . . . . .
Cenários resultantes de acordo com a relevância .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
80
81
84
87
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A.1 Repositórios de busca na Systematic Literature Review (Revisão Sistemática da
Liteturatura) (SLR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Lista de Acrônimos
AS
Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
DHT
Distributed Hash Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
IoT
Internet of Things (Internet das Coisas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CI
Cidade Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
SLR
Systematic Literature Review (Revisão Sistemática da Liteturatura) . . . . . . . . . . 38
SOA
Arquitetura Orientada a Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TIC
Tecnologia da Informação e Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Sumário
1
2
Introdução
23
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.2
Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.3
Visão Geral da Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.3.1
Visão Geral da Arquitetura de Software (AS) . . . . . . . . . . . . . .
25
1.4
Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.5
Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.6
Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Cidades Inteligentes e Internet das Coisas
29
2.1
Conceito de Cidade Inteligente (CI) . . . . . . . . . . . . . . . . . . . . . . .
31
2.2
Conceito de Internet of Things (Internet das Coisas) (IoT) . . . . . . . . . . . .
33
2.3
Integração de Cidade Inteligente (CI) com Internet of Things (Internet das
Coisas) (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . . . . .
34
2.4
3
Revisão da Literatura de Arquiteturas de Software para Cidades Inteligentes
37
3.1
Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.1.1
Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.1.1.1
Estratégia de Busca e Fontes de Dados . . . . . . . . . . . .
39
3.1.1.2
Seleção das Abordagens . . . . . . . . . . . . . . . . . . . .
40
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.1.2.1
Abordagens Resultantes . . . . . . . . . . . . . . . . . . . .
42
Revisão Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.1
Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.2.2
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.3
Consolidação das Abordagens Encontradas . . . . . . . . . . . . . . . . . . .
48
3.4
Requisitos para uma Arquitetura de Software para Cidades Inteligentes . . . . .
48
3.4.1
Interoperabilidade de objetos . . . . . . . . . . . . . . . . . . . . . . .
50
3.4.2
Monitoramento em tempo real . . . . . . . . . . . . . . . . . . . . . .
50
3.4.3
Sustentabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.4.4
Aspectos sociais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.4.5
Ubiquidade/Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.4.6
Privacidade e Segurança dos dados . . . . . . . . . . . . . . . . . . . .
52
3.4.7
Geolocalização dos sensores . . . . . . . . . . . . . . . . . . . . . . .
52
3.1.2
3.2
4
3.4.8
Composição de Dados Urbanos . . . . . . . . . . . . . . . . . . . . .
53
3.4.9
Histórico de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.4.10 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.4.11 Sensoriamento e Processamento Distribuído . . . . . . . . . . . . . . .
54
3.4.12 Flexibilidade/Extensibilidade . . . . . . . . . . . . . . . . . . . . . .
55
3.5
Sumário dos Requisitos para Cidades Inteligentes . . . . . . . . . . . . . . . .
55
3.6
Discussão do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.7
Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . . . . .
57
Uma Arquitetura de Software para Cidades Inteligentes baseada na Internet das
Coisas
59
4.1
Requisitos abordados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.2
Metodologia “4+1” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.3
Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.1
Módulo de Acesso e Comunicação (MAC) . . . . . . . . . . . . . . .
62
4.3.2
Módulo de Gerenciamento de Recursos (MGR) . . . . . . . . . . . . .
63
4.3.3
Módulo de Gerenciamento e Distribuição de Dados (MGDD) . . . . .
64
4.3.4
Módulo de Persistência de Dados (MPD) . . . . . . . . . . . . . . . .
65
4.3.5
Mapeamento Requisito x Módulo . . . . . . . . . . . . . . . . . . . .
65
4.3.6
Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.3.6.1
Consumidor: Recurso receber dados . . . . . . . . . . . . .
66
4.3.6.2
Produtor: Fornecer dado . . . . . . . . . . . . . . . . . . . .
66
4.3.6.3
Compor um dado urbano . . . . . . . . . . . . . . . . . . .
67
Visão de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.4.1
Módulo de Acesso e Comunicação (MAC) . . . . . . . . . . . . . . .
67
4.4.2
Módulo de Gerenciamento de Recursos (MGR) . . . . . . . . . . . . .
68
4.4.3
Módulo de Gerenciamento e Distribuição de Dados (MGDD) . . . . .
68
4.4.4
Módulo de Persistência de Dados (MPD) . . . . . . . . . . . . . . . .
69
4.5
Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.6
Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.7
Visão Componente Conector . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.8
Visão de Dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.9
Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.9.1
Desenvolvimento de aplicações móveis . . . . . . . . . . . . . . . . .
72
4.9.2
Emitir Alertas com Informações de Trânsito . . . . . . . . . . . . . . .
73
4.9.3
Definição de Estratégia Efetiva de Investimento de Recursos . . . . . .
73
4.9.4
Predição de Catastrófes em Áreas de Riscos . . . . . . . . . . . . . . .
73
4.10 Discussão do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.11 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . . . . .
74
4.4
21
5
6
Avaliação da Arquitetura de Software
5.1 Métodos de Avaliação . . . . . . . . . . . . .
5.1.1 Métodos Analisados . . . . . . . . .
5.1.2 Descrição dos métodos restantes . . .
5.2 Adaptação dos métodos de avaliação . . . . .
5.2.1 Definição do método de avaliação . .
5.2.2 Equipe de Avaliação . . . . . . . . .
5.2.3 Descrição do Método de Avaliação .
5.3 Processo de Avaliação Executado . . . . . . .
5.3.1 Primeira Reunião . . . . . . . . . . .
5.3.2 Segunda Reunião . . . . . . . . . . .
5.3.3 Terceira Reunião . . . . . . . . . . .
5.4 Resultados da Avaliação da Arquitetura . . .
5.4.1 Resultados da Avaliação dos Cenários
5.4.2 Resultados Gerais . . . . . . . . . . .
5.5 Ameaças à Avaliação . . . . . . . . . . . . .
5.6 Considerações Finais do Capítulo . . . . . .
Conclusão
6.1 Principais Conclusões .
6.2 Trabalhos Relacionados
6.3 Trabalhos Futuros . . .
6.4 Conclusão . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
References
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
78
78
79
80
80
81
81
83
83
85
86
86
87
89
89
90
.
.
.
.
91
91
92
94
94
97
Apêndice
103
A Repositórios de busca na SLR
105
B Avaliação da Arquitetura de Software (AS)
107
23
1
Introdução
Pequenas oportunidades são muitas vezes o começo de grandes
empreendimentos.
—DEMÓSTENES
1.1
Motivação
De acordo com relatório divulgado pela UNESCO NATIONS (2007), por volta de 1950,
30% da população mundial vivia em áreas urbanas e em 2010 esta porcentagem subiu para 50%.
Estima-se que em 2050 a porcentagem de pessoas vivendo nos grandes centros urbanos será
de 70%. Além disso, 10% da população mundial vive nas 30 principais metrópoles DOBBS;
INSTITUTE (2011). No cenário nacional, segundo a pesquisa realizada pelo Instituto Brasileiro
de Geografia e Estatística (IBGE), publicada no Diário Oficial da União 1 , em julho de 2012 o
Brasil chegou a 193.946.886 habitantes, que representa um aumento de aproximadamente 1,65%
em relação ao ano de 2010.
A expansão das cidades enfrenta uma série de desafios. Embora as cidades ocupam
menos de 2% da massa terrestre, os residentes urbanos consomem mais de três quartos dos
recursos naturais do mundo e são os principais responsáveis pela emissão de gases do efeito
estufa MARCEAU (2008). Problemas decorrentes da rápida urbanização indicam uma perda
de funcionalidades básicas para ser um lugar habitável: por exemplo, a dificuldade na gestão
de resíduos, a escassez de recursos naturais, a poluição do ar, as doenças humanas, o intenso
tráfego de veículos e deterioração e envelhecimento das infraestruturas KRCO (2010).
Algumas iniciativas isoladas estão sendo desenvolvidas para mitigar alguns dos problemas urbanos NAM; PARDO (2011). As iniciativas vão de aplicativos como “Waze”2 , um
serviço que combina geolocalização no celular com indicações do fluxo e problemas de trânsito
via smartphones, até governamentais, como o Centro de Operações da Prefeitura do Rio de
1 http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=2204
2 https://www.waze.com/
24
CAPÍTULO 1. INTRODUÇÃO
Janeiro3 , sistema que integra informações a respeito dos diferentes serviços públicos oferecidos
pela cidade.
Porém, para de fato estabelecer uma Cidade Inteligente (CI) é necessário que estas
iniciativas estejam integradas em uma mesma Arquitetura de Software (AS), seja para compartilhar informações, seja para facilitar a definição da estratégia de atuação FILIPPONI et al.
(2010); ANTHOPOULOS; FITSILIS (2010); HAUBENSAK (2011); SANCHEZ et al. (2011);
HERNáNDEZ-MUñOZ et al. (2011). Da mesma forma, necessita-se de uma AS que permita
a criação de novas iniciativas para solucionar os problemas dos cidadãos FILIPPONI et al.
(2010); HAUBENSAK (2011); SANCHEZ et al. (2011), como por exemplo, o monitoramento
da qualidade do transporte coletivo.
Além disso, este trabalho é motivado pela vasta gama de sensores, atuadores, pessoas,
sistemas, drivers e qualquer outro componente capaz de interagir com os serviços urbanos. Ao
aplicar este conjunto de componentes nos contextos urbanos, vários desafios são gerados para
integrá-los e obter o melhor de cada componente.
Para este e outros cenários semelhantes, uma AS para CI pode ajudar a integrar esses
diversos componentes. Para tal, a AS deve ser totalmente plugável e expansível, do ponto de
vista dos protocolos de comunicação implementados.
1.2
Estabelecimento do Problema
Motivado pelas questões apresentadas na Seção anterior, o principal objetivo deste
trabalho é, em linhas gerais:
Especificar, projetar e implementar uma Arquitetura de Software (AS) para Cidade Inteligente (CI) que permita o desenvolvimento de soluções com base em Internet of
Things (Internet das Coisas) (IoT), independente das especificações de cada tecnologia e
características físicas das cidades. Além disto, este trabalho visa prover uma implementação de referência desta AS.
1.3
Visão Geral da Solução Proposta
A fim de atingir os objetivos deste trabalho, estabelecidos na Seção anterior, foi realizado
um estudo das Arquiteturas de Software (AS’s) para CI baseada em IoT tanto na academia quanto
na indústria, por meio de dois métodos de revisão literária: Revisão Exploratória e Revisão
Sistemática. Este estudo teve como finalidade identificar as técnicas empregadas nestas soluções
e se existia a necessidade da criação de um novo padrão arquitetural para este contexto.
A partir dos objetivos das abordagens encontradas nestes dois métodos de revisão, um
conjunto de requisitos ao qual uma nova AS para CI deve atender foi estabelecido. Em seguida,
3 http://www.rio.rj.gov.br/web/corio
25
1.3. VISÃO GERAL DA SOLUÇÃO PROPOSTA
a AS da solução foi proposta visando atingir um sub-conjunto destes requisitos, que representa
os requisitos fundamentais. Por fim, a AS foi submetida à um processo de avaliação formal
adaptado do SAAM KAZMAN et al. (1994) e ATAM KAZMAN et al. (1999, 2000).
1.3.1
Visão Geral da Arquitetura de Software (AS)
A AS consiste em módulos que implementam um conjunto de requisitos fundamentais
para o contexto de CI. Estes requisitos são implementados a partir da utilização de padrões
arquiteturais já conhecidos e utilizados em outros tipos de AS’s de software, como publishersubscriber. A Figura 1.1 ilustra a AS proposta.
Módulo de
Acesso e
Comunicação
(MAC)
REST
Módulo de
Persistência de
Dados (MPD)
Interface: Protocolos de troca de mensagens
DHT-BD
Registro de recursos
Interface: Banco de Dados
Driver
BD3
BD3
Driver
BD2
BD2
Driver
BD1
BD1
Configuração de recursos
Módulo de
Gerenciamento
de Recursos
(MGR)
C
DHT Canal
de
dados
C
...
C
C
...
C
C
...
....
Canal 2
Canal 1
...
P
P
...
P
P
...
Canal 3
P
P
Módulo de
Gerenciamento
e Distribuição
de Dados
(MGDD)
...
Figura 1.1: Arquitetura de Software (AS) da solução proposta
Os módulos da AS são: Módulo de Acesso e Comunicação (MAC), Módulo de Gerenciamento de Recursos (MGR), Módulo de Gerenciamento e Distribuição de Dados (MGDD) e
Módulo de Persistência de Dados (MPD). Estes módulos fornecem as funcionalidades essenciais
utilizadas pelos diferentes tipos de usuários do sistema.
O MAC representa o ponto de entrada dos usuários, aplicações ou até mesmo serviços
externos. O MAC provê todos os mecanismos necessários para o acesso e a comunicação com
a AS, tanto para envio quanto para recebimento de informações. Por sua vez, o MGR visa
gerenciar as informações relativas aos diferentes tipos de recursos disponíveis na AS. Já o
MGDD possui a responsabilidade de disseminar os dados na AS, tanto os dados de fora para
dentro da AS quanto os dados obtidos a partir de alguma computação interna para os agentes
externos. O último módulo (MPD), como o próprio nome já identifica, possui a responsabilidade
de armazenar os dados oriundos dos diferentes níveis da AS. Estes dados, nos mais variados
estágios da AS, são importantes para a predição de acontecimentos futuros, a partir do histórico
26
CAPÍTULO 1. INTRODUÇÃO
de dados.
Os detalhes da AS serão descritos no Capítulo 4.
1.4
Escopo Negativo
Como a solução proposta por esta dissertação faz parte de um contexto mais amplo, um
conjunto de aspectos relacionados não será tratado no escopo deste trabalho.
Adicionalmente, os requisitos tratados na solução não formam um conjunto completo e
fechado de funcionalidades que devem sempre estar presentes em qualquer AS para CI. Contudo,
acredita-se que os requisitos identificados podem servir como base para a construção e/ou
adaptação de uma AS para CI que combine tecnologias de IoT, tanto para coletar informações
quanto para atuar no ambiente.
Os seguintes aspectos não fazem parte do escopo deste trabalho:
1.5
Modelo de Negócio: Aspectos relacionados ao suporte a modelos de negócio e estratégias de monetização e cobrança desta proposta não serão tratados neste trabalho;
Análises de big data: Apesar da grande quantidade de dados trafegados na AS, este
trabalho não faz nenhum tipo de análise de big data, apenas permite que um serviço
que o faça seja criado;
Semântica dos Dados: Este trabalho não faz distinção entre semântica dos dados,
uma vez que qualquer tipo de dado relacionado à cidade pode trafegar na AS.
Principais Contribuições
Como resultado do trabalho apresentado nesta dissertação, as seguintes contribuições
podem ser destacadas:
Estado de arte de AS para CI: A partir das revisões da literatura executadas foi
possível apresentar um resumo a respeito do estado da arte de CI no Brasil e no
mundo, a partir da descrição de algumas abordagens com ou sem apoio dos setores
estatais e privados;
Comparativo entre dois métodos de revisão literária: A partir dos resultados
obtidos nas duas avaliações executadas (Revisão Sistemática e Revisão Exploratório)
foi possível estabelecer um comparativo em relação a eficiência de cada método,
principalmente relacionado à questões de pesquisa com relevância acadêmica e
mercadológica;
Requisitos de uma AS para CI: Um conjunto de requisitos essencias que uma AS
para CI deve atender foi estabelecido, a partir da análise das soluções existentes;
27
1.5. PRINCIPAIS CONTRIBUIÇÕES
Arquitetura de Software (AS) para CI e IoT: Uma AS que visa atender aos
principais requisitos de CI que combina conceitos de IoT foi especificada;
Implementação inicial: Baseado na proposta desta dissertação, uma implementação
inicial foi realizada e disponibilizado em domínio público. Esta implementação serve
de guia para a utilização desta proposta em qualquer cidade;
Adaptação de dois métodos de avaliação: Não foi encontrado na literatura nenhum
método de avaliação que fosse totalmente compatível com as peculiaridades do
contexto deste trabalho. Logo, foi proposta e utilizada uma adaptação de dois
métodos de avaliação: SAAM e ATAM. Esta adaptação foi aplicada, na qual se pôde
comprovar a sua utilidade. Este método pode ser empregado em qualquer contexto
semelhante, principalmente se a equipe esta geograficamente distribuída.
Além das contribuições finais listadas acima, alguns resultados intermediários deste
trabalho estão sendo reportados na literatura, como mostrado a seguir:
TOMAS, G. H. R. P.; SILVA, W. M.; GARCIA, V. C. ; ALVARO, Alexandre, GAMA,
Kiev. Towards a Smart City Architecture based on Internet Of Things. Internet of
Things Technology and Applications in Information Sciences and Service Sciences,
2014.
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
28
CAPÍTULO 1. INTRODUÇÃO
Inteligentes. In: IX Simpósio Brasileiro de Sistemas de Informação (SBSI), 2013,
João Pessoa. Anais do III Simpósio Brasileiro de Sistemas de Informação. Curitiba,
PR, novembro de 2006. Porto Alegre: Sociedade Brasileira de Computação, 2013. v.
1. p. 511-516.
1.6
Organização da Dissertação
O restante desta dissertação está organizado conforme se segue:
Capítulo 2: contextualiza a temática de CI e IoT, além de esclarecer a interação
entre as duas áreas de pesquisa;
Capítulo 3: apresenta a revisão bibliográfica sobre AS para CI que combinam
tecnologias IoT, com o objetivo de identificar as principais soluções existentes na
academia e na indústria e estabelecer um conjunto de requisitos fundamentais que
uma nova AS deve atender;
Capítulo 4: descreve em detalhes a proposta da AS, ressaltando, principalmente,
como cada requisito é implementado;
Capítulo 5: discute o processo de avaliação de AS realizado, totalmente remoto,
durante o desenvolvimento da solução, e apresenta os principais resultados;
Capítulo 6: conclui esta dissertação por meio de de um resumo das principais
contribuições desta pesquisa e discussões a respeito de alguns trabalhos relacionados.
Por fim, são apresentadas algumas observações finais e direções para pesquisas
futuras.
29
2
Cidades Inteligentes e Internet das Coisas
A alegria que se tem em pensar e aprender faz-nos pensar e aprender ainda
mais.
—ARISTÓTELES
As cidades são sistemas complexos que concentram um grande conjunto de serviços e de
infraestruturas e consomem um crescente volume de recursos e de energia, com um significativo
impacto a nível econômico, ambiental e de qualidade de vida COMPUTERWORLD (2013).
A literatura apresenta diversas definições do termo Cidade, porém a mais aceita é descrita
em kuper1995social como “um povoado relativamente grande e permanente”. Geralmente, uma
cidade possui alta densidade populacional e os cidadãos interagem com indústrias, comércios
e serviços. No quesito operacional, cidades são baseadas em um conjunto de serviços urbanos
básicos: energia, água, transporte, infraestrutura de informação e comunicação, mercado, saúde
pública e saneamento público MORVAJ; LUGARIC; KRAJCAR (2011).
Este conjunto de serviços urbanos básicos é justamente onde se localizam os principais
problemas das cidades MORVAJ; LUGARIC; KRAJCAR (2011). Além disso, com o crescimento
populacional supracitado no Capítulo anterior e o envelhecimento das infraestrturas, surge a
necessidade de aprimorar técnicas para otimizar a utilização destes serviços KRCO (2010).
Simultaneamente, necessita-se de um sistema no qual os demais serviços possam ser criados
e/ou otimizados para suprir as necessidades dos cidadãos.
Estes fatores demonstram os grandes desafios para os gestores das cidades. Problemas
relacionados ao tráfego, segurança, consumo de água e energia, dentre outros, têm sido cada vez
mais difíceis de serem administrados. A saber:
Segurança: Os altos índices de criminalidade são grandes preocupações da sociedade.
Assaltos, tráfico de drogas e crime organizado são manchetes na TV e nos jornais todos os dias e
são uma dura realidade das cidades brasileiras. Catástrofes como enchentes são um problema
de defesa civil devido a ocupação desordenada de encostas e morros, ameaçando diversas
comunidades em cidades por todo o Brasil. Segundo o Mapa das Ocorrências Registradas pelas
30
CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS
Polícias Civis (Janeiro de 2004 a Dezembro de 2005)1 , desenvolvido pela Secretaria Nacional de
Segurança Pública, entre 2004 e 2005 a taxa de roubo no Brasil por 100 mil habitantes aumentou
de 516,7 para 519,4;
Transporte: O sistema de transporte coletivo é de qualidade e eficiência questionáveis
na maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e as crescentes
facilidades no financiamento de veículos, a quantidade de motocicletas e automóveis no país é
cada vez maior. A infraestrutura viária não acompanha este crescimento da frota nacional e o
trânsito é um problema em muitas cidades. Soluções paliativas, como rodízio de veículos, apenas
atenuam o crescimento do problema do tráfego, quando, na verdade, uma otimização no sistema
de transportes coletivos faz-se necessária. Dois exemplos da situação do transporte coletivo
no Brasil podem ser encontrados na Pesquisa de Mobilidade Da Região Metropolitana de São
Paulo2 : i) entre 2002 e 2012, a frota de veículos particulares cresceu 18%; ii) no mesmo período,
a taxa de motorização passou de 184 para 212 automóveis particulares por 1.000 habitantes;
Saúde: No Brasil, a infraestrutura do sistema de saúde é insuficiente para atender à
demanda. Vários hospitais públicos possuem atendimento deficitário, forçando pacientes a
aguardarem em longas filas de espera e o mesmo problema vem assolando pacientes do sistema
privado com planos de saúde. De acordo com a pesquisa da Assistência Médico-Sanitária(AMS)3
realizada em 2002 pelo IBGE, houve uma variação na quantidade de leitos disponíveis no Brasil,
de 3,65 leitos por 1 000 habitantes em 1992, para 2,70 em 2002, uma redução de quase 25%;
Uso sustentável de recursos: O aumento do poder aquisitivo das classes mais pobres
gerou uma elevação no consumo de energia elétrica, mas classes média e alta ainda representam
a maior fatia do consumo de energia elétrica, pelo padrão de consumo e conforto que envolve
diversos tipos de eletroeletrônicos. Em Foz do Iguaçu, por exemplo, 7% das famílias correspondem a mais de 65% do consumo de energia elétrica da cidade HEBERTY H. AMARAL;
FERNANDES (2010);
Gestão de resíduos: O lixo tem se tornado um grande problema para cidades de países
em desenvolvimento. Enquanto cidades de países desenvolvidos põem em prática diversas
soluções de tratamento de lixo orgânico e de reaproveitamento de materiais recicláveis, cidades
de países como o Brasil não conseguem definir ou executar práticas de reciclagem, salvo raras
exceções. Por exemplo, de acordo com a Associação Brasileira de Empresas de Limpeza Pública
e Resíduos Especiais (ABRELPE)4 , em 2012 cerca de 60% dos municípios registraram alguma
iniciativa de coleta seletiva. Embora seja expressiva a quantidade de municípios com iniciativas
de coleta seletiva, muitas vezes estas atividades resumem-se à disponibilização de pontos de
entrega voluntária ou convênios com cooperativas de catadores, que não abrangem a totalidade
do território ou da população do município.
1 http://portal.mj.gov.br/services/DocumentManagement/FileDownload.EZTSvc.asp?DocumentID={42595482-
B0DD-4185-918E-80E4BAFAFC72}&ServiceInstUID={B78EA6CB-3FB8-4814-AEF6-31787003C745}
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
4 http://a3p.jbrj.gov.br/pdf/ABRELPE%20%20Panorama2012.pdf
31
2.1. CONCEITO DE Cidade Inteligente (CI)
Apesar da evidente necessidade de cidades cada vez mais inteligente e a atenção que
a academia tem destinado para o tema, ainda não há um consenso a respeito da definição do
conceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado para empregá-lo
GIFFINGER; PICHLER-MILANOVIĆ (2007); CARAGLIU; DEL BO; NIJKAMP (2009); LI
et al. (2011). Logo, a Seção 2.1 visa clarificar a definição de CI a ser utilizada durante este
trabalho.
Um paradigma que vem sendo utilizado em diversas abordagens para CI é a utilização
de IoT como ferramenta para captar dados e atuar sobre os serviços urbanos. Logo, a Seção 2.2
visa contextualizar a IoT, a partir de alguns exemplos de aplicações.
Por sua vez, a Seção 2.3 inicialmente pontua alguns dos principais desafios, principalmente, nas cidades brasileiras. Em seguida, apresenta-se a integração existente entre estas
duas áreas de pesquisa e alguns exemplos de utilização desta integração para mitigar alguma
deficiência urbana.
Por fim, a Seção 2.4 consolida as principais contribuições deste Capítulo.
2.1
Conceito de Cidade Inteligente (CI)
A literatura apresenta algumas definições para o termo CI, porém ainda não há um
consenso a respeito deste conceito. A seguir, são apresentadas as principais definições descritas
na literatura e a definição que será utilizada no decorrer deste trabalho.
Em Giffinger-2007 é ilustrada uma série de diferentes ambientes na qual o termo foi
utilizado. Por exemplo, a definição de CI, quando associada com economia, é uma cidade com
indústria inteligente, na qual são empregadas tecnologias de última geração para aprimorar
os aspectos financeiros e econômicos. No aspecto educação, Giffinger et. al. caracteriza CI
como o nível de escolaridade dos cidadãos. Além disso, de acordo com Giffinger et. al., uma
CI também pode ser mensurada a partir do relacionamento entre o governo e os cidadãos e a
utilização de modernas tecnologias, não somente relacionada à Tecnologia da Informação e
Comunicação (TIC), mas também à outros domínios, como transporte e logística.
Por fim, Giffinger et. al. define seis características principais para cidades inteligentes:
smart economy, smart people, smart governance, smart mobility, smart environment e smart
living. A partir disso, uma CI é uma cidade com bom desempenho nestas seis características,
construída a partir da combinação inteligente de atividades independentes, auto-decisivas e em
prol dos cidadãos. Esta definição, oriunda dos resultados do projeto European Smart Cities
CARAGLIU; DEL BO; NIJKAMP (2009), é a mais bem conhecida e com maior aceitação na
literatura HERNáNDEZ-MUñOZ et al. (2011), pois permite quantificar o nível de inteligência das
cidades. Por exemplo, inovação faz parte do eixo smart economy e é calculado pela quantidade
de patentes por habitantes HAUBENSAK (2011).
Apesar dessa definição ser considerada a mais abrangente, cada trabalho adota uma
definição mais apropriada para o escopo do projeto. Em Kehua-2011, a IBM define CI como
o uso de TIC para capturar, analisar e integrar informações relevantes no núcleo dos sistemas
32
CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS
das cidades. Ao mesmo tempo, uma CI pode tomar decisões inteligentes para diferentes tipos
de necessidades, incluindo aspectos diários, proteção ambiental, segurança pública, serviços da
cidade e atividades industriais e comerciais.
Analogamente, em moss2009informed o termo CI é definido como uma cidade que combina TICs com a infraestrutura física, para prover conveniências aos cidadãos, como: eficiência
energética; aumento da qualidade da água e do ar; identificar e resolver rapidamente qualquer
problema no funcionamento dos sistemas da cidades; mitigar desastres; capturar dados para
apurar a tomada de decisões e a utilização de recursos de forma eficiente. Logo, a CI não pode
ser vista como a soma de partes independentes, mas uma rede de infraestrutura interconectada,
na qual cada recurso é dependente do outro.
Em Steventon-2005, as CIs se referem aos ambientes físicos em que as TICs e os sistemas
de sensoriamento são transparentes para os cidadãos, porém desepenham papel fundamental para
garantir o funcionamento operacional da cidade.
Uma CI também é definida como um território no qual as TICs propiciam inovações
em diversos segmentos, combinando a criatividade e o talento individual em prol da população
da cidade, instituições locais e orgãos governamentais KOMNINOS (2002); SCHUMPETER
(1934).
Em Dossier-2013 defende-se que CI não é um conceito tecnológico, mas um conceito
sociotécnico. Integra-se três vertentes essenciais: a tecnologia, as pessoas e as instituições. Uma
CI tem que centrar a sua atuação nos cidadãos e nas comunidades onde vivem e trabalham.
Em relação aos aspectos governamentais, toppeta2010smart acredita que uma CI deve
identificar e otimizar os processos governamentais, mitigando a burocracia que envolve o
processso de inovação de soluções e gerenciamento de técnicas sustentáveis.
Por fim, CI pode ser considerada um conjunto de comunidades inteligentes LI et al.
(2011). A partir dessa perspectiva, a World Foundation for Smart Communities (Fundação Mundial para Cidades Inteligentes)5 define que uma CI é uma comunidade com avanços significativos
em TICs que transformam o cotidiano dos cidadãos, melhorando os aspectos relacionados ao
trabalho e ao lazer de forma incremental e transparente EGER (2011).
Além da falta de consenso quanto ao termo CI, existem outros termos que são comumente aplicados aos mesmos contextos, como “cidades virtuais”, “cidades digitais”, “cidade
informatizada”, “cidade eletrônica” KOMNINOS (2006). Ao generalizar esse conceito aos
ambientes inteligentes que se relacionam com serviços urbanos, vários sinônimos de CI são
frequentemente empregados, como “information city”, “wired city”, “telecity”, “knowledgebased city”, “electronic communities”, “electronic community spaces”, “flexicity”, “teletopia”,
“cyberville” DROEGE (1997).
Essa ausência de consenso é devido aos múltiplos movimentos científicos, tecnológicos e
sociais que compõem o contexto de uma cidade KOMNINOS (2006). Em cada disciplina, existe
uma série de problemas que afetam diretamente diversos serviços existentes, como transporte,
5 http://www.smartcommunities.org
2.2. CONCEITO DE IOT! (IOT!)
33
segurança, provisão/consumo de energia elétrica e água, saneamento básico, utilização de
recursos naturais, controle de catástrofes, principalmente no que tange a gestão individual e
influência mútua, até como planejar e otimizar a utilização em resposta a diferentes cenários.
Neste trabalho, uma combinação destas principais definições com diferentes vieses é
considerada:
“Cidade Inteligente (CI) é a combinação de Tecnologia da Informação e Comunicação (TIC)
com todos os aspectos que compõem uma cidade, desde aos aspectos físicos até governamentais,
combinados de forma a satisfazer às necessidades dos cidadãos ”.
2.2
Conceito de Internet of Things (Internet das Coisas) (IoT)
De acordo com giusto2010internet, a Internet of Things (Internet das Coisas) (IoT),
também conhecida como Internet dos Objetos, é um paradigma que vem crescendo no cenário
moderno de telecomunicações sem fio. A idéia básica deste conceito é a presença de um conjunto
de objetos (things) - como Radio-Frequency IDentification (RFID), sensores, atuadores, telefones
celulares - que, por meio de mecanismos de endereçamento único (como a Internet), são capazes
de interagir e cooperar uns com os outros para alcançar objetivos em comum.
Sem dúvida, o principal impacto da IoT será sobre alguns aspectos do cotidiano e
comportamento das pessoas ATZORI; IERA; MORABITO (’2010’). Por exemplo, já existem
aplicações IoT que permitem o monitoramento de atividades físicas6 e controle de medicamentos
de uso contínuo7 . Outro conjunto de aplicações que interferem no cotidiano das pessoas são
as voltadas para o ambiente doméstico. Por exemplo, ligar e desligar aparelhos domésticos à
distância8 , medir a temperatura da casa9 e até mesmo monitorar o jardim10 já são realidades.
Ao considerar a diversidade de aplicações ilustradas acima, pode-se inferir o motivo
pelo qual IoT é incluída pelo Conselho Nacional de Inteligência dos EUA (NIC) na lista das
seis tecnologias civis “com impactos potenciais sobre o poder nacional dos EUA” (NIC). Além
disso, o NIC prevê que até 2025 os “objetos” estarão presentes em todas as coisas cotidianas,
como documentos, embalagens de alimentos e móveis.
A partir da evidente gama de possibilidade oriundas da IoT, torna-se natural associá-las
ao contexto de CI. Em uma CI, para o funcionamento adequado dos serviços inteligentes é
necessária a utilização de tecnologias que sejam capazes de captar e distribuir estas informações
LI et al. (2011) para uma AS centralizada HAUBENSAK (2011).
6 http://www.fitbit.com/
7 http://www.vitality.net/glowcaps.html
8 http://www.belkin.com/us/Products/home-automation/c/wemo-home-automation/
9 https://nest.com/
10 http://www.harvestgeek.com/
34
2.3
CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS
Integração de Cidade Inteligente (CI) com Internet of Things
(Internet das Coisas) (IoT)
A partir dos problemas comumente enfrentado pelas cidades, surge o desafio de combinar diferentes informações com TIC, a fim de mitigar estes problemas e promover melhores
condições de vida aos cidadãos. Neste sentido, as tecnologias IoT também podem ser integradas
como ferramentas para monitorar os eventos de um ambiente, atuar a fim de conter uma situação
emergencial ou, até mesmo, propagar uma informação relevante.
Os cenários da utilização de TICs e IoT para esta finalidade são os mais variados. Um
exemplo é o monitoramento do trânsito em estradas e rodovias. Este monitoramento, a partir de
sensores espalhados pelas vias, poderia alimentar sistemas de informação capazes de gerar rotas
em tempo real, redistribuindo os veículos, aumentando a fluidez das vias. Esta redistribuição
poderia ser feita ao enviar informações para os dispositivos GPS dos veículos ou até mesmo
por um conjunto de painéis indicativos para orientar os motoristas sobre a melhor rota. A
comunicação e a troca de informações entre estes diferentes objetos constituem um cenário de
uso clássico de IoT.
Outro exemplo da utilização maciça de TIC e IoT é o controle do consumo residencial
de energia elétrica a partir de eletrodomésticos habilitados a otimizar seu funcionamento de
acordo com os hábitos e necessidades de seus moradores. Além disso, estes eletrodomésticos,
atuando em uma rede de objetos, podem trocar informações a fim de otimizar tarefas rotineiras
dos cidadãos, tais como, compras nos supermercados e manutenção do lar.
Um caso real da eficiência em aplicar TICs baseada em IoT é a redução de 30% das
emissões de carbono em Londres, apenas com a mudança de comportamento dos cidadãos, a
partir do acompanhamento de todas as tarefas dia-a-dia TOMORDY (2011). Esta mudança de
comportamento foi possível a partir de uma rede sensores que fornecia informações do nível de
carbono em tempo real .
2.4
Considerações Finais do Capítulo
Este Capítulo contextualizou as duas grandes áreas de pesquisa deste trabalho: Cidade
Inteligente (CI) e Internet of Things (Internet das Coisas) (IoT).
Como discutido previamente, ainda não há um consenso a respeito da definição mais
adequada para CI. Logo, a Seção 2.1 apresentou algumas definições disponíveis na literatura. A
partir destas, a definição a ser utilizada neste trabalho foi explicitada, considerando os diferentes
pontos de vistas dos demais autores.
Em seguida, a IoT foi definida e exemplificada na Seção 2.2. A partir desta, pode-se
notar a evidente correlação entre estas duas áreas de pesquisa. Este fato pode ser comprovado
ao analisar as principais aplicações de IoT: a grande maioria visa otimizar algum aspecto
35
2.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO
relacionado ao cotidiano das pessoas, tanto no ambiente profissional quanto no doméstico
ATZORI; IERA; MORABITO (’2010’).
Por fim, a Seção 2.3, apresentou alguns exemplos de utilização de IoT e dos conceitos de
CI para mitigar estes problemas urbanos. Algumas destas iniciativas já estão sendo desenvolvidas
e validadas, porém, para de fato se estabelecer uma CI, é necessária a integração destas iniciativas
a partir de uma AS centralizada FILIPPONI et al. (2010); ANTHOPOULOS; FITSILIS (2010);
HAUBENSAK (2011); SANCHEZ et al. (2011); HERNáNDEZ-MUñOZ et al. (2011).
Diversas abordagens já estão sendo desenvolvidas utilizando o paradigma: IoT como
ferramenta para captar e atuar sobre os serviços urbanos em prol da consolidação de uma CI.
Logo, o próximo Capítulo apresenta exemplos destas abordagens, encontradas a partir de dois
métodos de revisão da literatura.
37
3
Revisão da Literatura de Arquiteturas de
Software para Cidades Inteligentes
Cada dia sem treinar, estudar ou se dedicar a algo realmente importante
significa um dia mais distante da realização do seu sonho.
—BERNARDO ROCHA DE REZENDE, 2010 (Transformando Suor em
Ouro)
No contexto de uma Cidade Inteligente (CI), as Arquitetura de Software (AS) são de
suma importância por uma série de fatores. Primeiramente, uma AS pode permitir a troca de
informações entre diferentes serviços urbanos, a fim de fornecer serviços mais efetivos para os
cidadãos. Outro fator relevante é a possibilidade de criar aplicações Internet of Things (Internet
das Coisas) (IoT) que consumam ou forneçam algum tipo de dado para uma determinada
finalidade, como por exemplo, captar informações de pontos turísticos da cidade para melhorar
a experiência dos turistas. Esta integração das aplicações IoT com a AS será independente da
tecnologias utilizada, devido a vasta gama de sensores, atuadores, pessoas, sistemas, drivers
e qualquer outro componente capaz de interagir com os serviços urbanos. Além disso, a AS
pode permitir que governos adotem ações estratégicas voltadas para as reais necessidades dos
cidadãos.
Ao adotar um modelo como esse, na qual uma AS centralizada processa e distribuí dos
dados dos serviços urbanos, uma CI pode de fato ser implementada, uma vez que existirá um meio
pelo qual os serviços urbanos poderão ser integrados FILIPPONI et al. (2010); ANTHOPOULOS;
FITSILIS (2010); HAUBENSAK (2011); SANCHEZ et al. (2011); HERNáNDEZ-MUñOZ et al.
(2011).
Nos ínicio dos anos 90, a AS era basicamente voltada para os sistemas cliente-servidor,
na qual uma máquina exercia o papel de cliente requisitante e a outra máquina, o papel de
servidor com a responsabilidade de atender as requisições SOMMERVILLE (2007). Deste modo,
a arquitetura cliente-servidor tornou-se padrão no desenvolvimento de software, sendo em nossa
38
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
atualidade ainda explorada e, sobretudo, mesclada a outras AS para atender ao objetivo de um
software FOWLER (2012). Já na década de 2000, nota-se que as aquiteturas propostas são cada
vez mais heterogêneas, na qual estilos e tecnologias diferenciadas se misturam para formar novas
versões de representações arquiteturais BASS; CLEMENTS; KAZMAN (1998).
Dessa forma, o que se almeja investigar neste Capítulo é o estado da arte de Arquiteturas
de Software (AS’s) para CI que empregam IoT na solução de problemas urbanos.
Para aumentar a abrangência desta investigação, duas revisões da literatura foram realizadas: Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). As revisões sistemáticas
possibilitam a replicação do procedimento, pois possuem um processo repetitível. Porém, a
temática deste trabalho envolve aspectos mercadológicos que podem ser excluídos dessas revisões, por não serem publicados nos veículos convencionais. Logo, as revisões exploratórias são
importantes, pois permitem incluir diversos trabalhos de diferentes veículos de publicação, como
por exemplo, relatório técnico de empresas. Porém, esse tipo de revisão possui certa resistência
por ser baseado totalmente nas buscas não-metódicas do pesquisador.
Estes dois métodos de revisão literária também têm como objetivo identificar a necessidade de criar ou adaptar um padrão arquitetural específico para este contexto de CI e IoT.
Na Revisão Sistemática, foram selecionadas 11 abordagens. Já na Revisão Exploratória
16 abordagens foram selecionadas. Nestas duas revisões, 7 abordagens foram encontradas
em ambas as revisões. Estes trabalhos destacam-se por envolverem aspectos acadêmicos e
mercadológicos. Nestes casos, optou-se por descrevê-los apenas na Revisão Sistemática. Por
fim, ao todo, foram encontrados 20 abordagens condizentes com o objetivo deste trabalho.
Após a descrição das abordagens encontradas nas duas revisões, a Seção 3.3 visa consolidar as características mais relevantes de cada abordagem. Em seguida, pretende-se estabelecer
um conjunto de requisitos que uma AS para CI deve atender (Seção 3.4).
Este conjunto de requisitos e os demais resultados da Revisão Exploratória foram publicados em SAC:2013. Já os resultados da Revisão Sistemática foram publicados em ICEIS-2013.
Por fim, a Seção 3.6 dicute os pontos mais relevantes deste Capítulo e a Seção 3.7 finaliza
o Capítulo.
3.1
Revisão Sistemática
Conforme brevemente introduzido na Seção anterior, de acordo com Kitchenham-2007
o objetivo de uma Systematic Literature Review (Revisão Sistemática da Liteturatura) (SLR)
é fornecer indícios para o desenvolvimento de pesquisas baseadas em evidências, a partir da
seleção e síntese das pesquisas mais relevantes. Além disso, a SLR deve identificar, avaliar,
interpretar e comparar todas as fontes relevantes para uma determinada questão de pesquisa.
Diversas abordagens arquiteturais têm sido propostas na literatura, mas essa revisão
foca-se somente nas AS’s que utilizam o paradigma de combinar IoT como ferramenta para a
implementação de uma CI.
39
3.1. REVISÃO SISTEMÁTICA
3.1.1
Metodologia de Pesquisa
O objetivo desta subseção é descrever a estratégia de busca e todos os passos utilizados
para filtrar e extrair as informações relevantes de cada pesquisa. Essa estratégía segue as
recomendações descritas por Kitchenham-2007.
3.1.1.1
Estratégia de Busca e Fontes de Dados
A estratégia empregada para a construção das strings de buscas segue a mesma metodologia emprega por Kitchenham-2007, Chen-2009 e Khurum20091982. Esta estratégia é ilustrada
na Figura ??.
file = images/string p rocess.eps, width = 10cm
Figura 3.1: Estratégia de Busca
Seguindo esta estratégia, a seguinte string de busca foi definida:
(smart city OR intelligent city OR digital city OR urban environment) AND (internet of things
OR heterogeneous sensors) AND (architecture OR middleware OR platform)
Devido à variação dos resultados de cada motor de busca das principais fontes digitais
da literatura (como IEEExplore, Springer Link e ACM Digital Library), não é possível utilizar a
mesma string de busca em todas as fontes digitais CHEN; ALI BABAR; ALI (2009). Logo, foi
necessário um esforço para garantir que as strings utilizadas sejam logicamente e semanticamente
equivalentes.
Após definir a string de busca, realizou-se a busca nos seguintes repositórios digitais
(1. IEEExplore; 2. Science Direct; 3. ACM Digital Library; 4. Springer Link; 5. CiteSeerX;
6.Academia.edu; e 7. ISI Web of Science). Além disso, considerando que CI é uma linha de
pesquisa que envolve diversos aspectos de negócio e mercado, realizou-se a busca por patentes
no banco de patentes World Intellectual Property Organization(WIPO)1 .
Em relação à busca manual, foi realizada nos seguintes anais (1. International Conference
on Computational Intelligence, Modeling and Simulation (IJCCI); 2. International Conference
on Intelligent Environments (IE); 3. Multimedia Information Networking and Security (MINES);
4. Emerging Technologies for a Smarter World (CEWIT); 5. International Conference on
Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS)).
A Tabela 3.1 ilustra a quantidade de abordagens encontradas de acordo com as fontes de
pesquisa.
1 http://www.wipo.int
40
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
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 identificadas como primários, conforme discutido em Chen-2009. Dessa forma, algumas abordagens
podem não ter sido incluídas, caso os autores tenham usado outros termos além dos mencionados
acima.
3.1.1.2
Seleção das Abordagens
Nesta SLR foram selecionadas somente abordagens que propõem uma AS e/ou framework que centralize os diversos contextos e tecnologias que envolvem o ambiente urbano.
Para tal, 5 pesquisadores, sendo 2 mestrandos, 2 PhD e 1 doutorando, foram envolvidos no
processo de seleção e classificação
Após definir a string de busca e as fontes, foram definidos filtros para classificar as
abordagens encontradas. A Figura ?? ilustra os resultados de cada filtro, baseado na quantidade
de abordagens resultantes.
file = images/step f ilters.pd f , width = 10cm
Figura 3.2: Resultado da filtragem das abordagens
O objetivo destes filtros é selecionar as principais abordagens que descrevem AS’s para
CI baseadas em IoT. O primeiro filtro corresponde a todas as abordagens encontradas nas fontes
de pesquisa, descritas anteriormente, a partir da string de busca.
O segundo filtro foi aplicado para excluir as abordagens que não foram publicadas entre
2008-2012. Este intervalo foi escolhido após analisar e verificar que as abordagens propostas
antes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens foram propostas para
solucionar problemas específicos de um contexto usando apenas uma tecnologia, sem analizar a
41
3.1. REVISÃO SISTEMÁTICA
conexão entre os diferentes contextos urbanos.
Para realizar a terceira filtragem, todos os títulos das abordagens foram lidos e resultaram
apenas 71. Esta alta discrepância com o valor resultante do filtro anterior está relacionada a falta
de eficiência das engines de busca, como discutido em Kitchenham:2009:SLR:1465742.1466091.
O quarto filtro corresponde à elimição de abordagens duplicadas. Já, para realizar o
quinto filtro, todos os resumos foram lidos e discutidos entre a equipe.
Cada uma das 33 abordagens resultantes foram lidas e discutidas entre a equipe desta
SLR. Em seguida, apenas 11 abordagens resultaram como relevantes para a proposta deste
trabalho.
Em relação aos critérios de inclusão, as abordagens foram incluídas se:
Propõem uma AS para centralizar a informação de diferentes contextos urbanos OU
Descreve uma AS IoT na qual seu design permite a combinação de uma ou mais
tecnologias diferentes e/ou contextos urbanos E
Abordagens que ainda não foram selecionadas.
Durante esta revisão, foram encontradas diversas abordagens que descrevem a mesma
AS. Neste caso, somente o trabalho mais completo foi considerado. Após essa etapa, restaram
11 abordagens para serem analisadas.
Existem diversas razões para esta alta discrepância entre a quantidade inicial de trabalhos com a quantidade resultante. A principal razão é a alta quantidade de estudos duplicados com resultados semelhantes. Estas razões são discutidas e explicadas em Kitchenham:2009:SLR:1465742.1466091.
Em relação às patentes, não foi encontrada nenhuma patente relacionada. Geralmente, as
patentes mais próxima à temática dessa revisão sistemática descrevem um algoritmo específico
ou a otimização de uma técnica empregada em um ambiente controlado.
3.1.2
Resultados
Após realizar as buscas nas principais fontes de pesquisa, filtrar as abordagens de acordo
com os critérios descritos na Seção anterior, restaram 11 abordagens. Estas abordagens foram
lidas e discutidas entre os 5 pesquisadores supracitados, com o objetivo de realçar os tópicos
relacionados às questões de pesquisa. Esta seção visa discutir estas abordagens, iniciando por
uma descrição inicial de cada abordagem.
Caso uma abordagem tenha algum nome, este será utilizado para referir-se a ela. Caso
contrário, será dado um nome usando o sobrenome do primeiro autor seguido pelo ano de
publicação. A Tabela 3.2 lista as 11 abordagens analisadas, organizadas em ordem cronológica.
42
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
Tabela 3.2: Abordagens resultantes por ordem cronológica
ID
1
2
3
4
5
6
7
8
9
10
11
3.1.2.1
Abordagem
Al-Hader’2009
Anthopoulos’2010
SOFIA
EcoCity/ISMP-UC
CPAF
SmartSantander
IMS
USN
Wu’2011
Fazio’2012
S3 OiA
Ano
2009
2010
2010
2011
2011
2011
2011
2011
2011
2012
2012
Referência
AL-HADER et al. (2009)
ANTHOPOULOS; FITSILIS (2010)
FILIPPONI et al. (2010)
LEE; BAIK; CHOONHWA LEE (2011)
MOSTASHARI et al. (2011)
SANCHEZ et al. (2011)
SHAO (2011)
HERNáNDEZ-MUñOZ et al. (2011)
WU et al. (2011)
FAZIO et al. (2012)
VEGA-BARBAS et al. (2012)
Abordagens Resultantes
Arquitetura de Software (AS) para CI podem ser desenvolvidas a partir de diferentes
áreas do conhecimento. Esta Seção visa fornecer uma descrição alto-nível das AS’s encontradas,
ordenadas em ordem cronológica, ressaltando os principais objetivos e características de cada
abordagem.
Iniciando por Al-Hader’2009 AL-HADER et al. (2009), no qual é proposto uma AS
baseada em quatro princípios: aplicações, negócios, gerenciamento de processos e infraestrutura
de redes. O primeiro princípio corresponde às aplicações que fazem uso de diferentes tecnologias
para monitorar sensores, como Global Positioning System (GPS). De acordo com AL-HADER
et al. (2009), a maioria destas aplicações atendem as demandas operacionais das cidades,
porém, ao utilizar as regras definidas no segundo princípio - negócios - elas podem agregar
soluções economicamente viáveis. O terceiro princípio é o gerenciamento de processos na qual
relacionamentos, regras, estratégias e políticas entre as aplicações e as unidades de negócios são
definidas. Finalmente, o último princípio corresponde a toda a infraestrutura de rede, responsável
por conectar os outros três princípios.
anthopoulos2010digital propõem uma AS baseada na análise de diferentes iniciativas já
implementadas, modelada a partir dos princípios das Enterprise Architectures BOOCH (2010).
anthopoulos2010digital enfatizam que a construção de uma CI deve ser guiada pela integração
de sistemas legados com as novas infraestruturas, migração e reuso de dados existentes, simplificação dos processos urbanos, otimização da utilização de recursos naturais, interoperabilidade
de sistemas e equipamentos e prover ferramentas para monitoramento, gerenciamento e análises.
A integração de sensores é um dos objetivos da AS conhecida como SOFIA FILIPPONI
et al. (2010), centrada no conceito de Smart Environment (Ambiente inteligente) como um
ecossistema de interação de objetos, como sensores, dispositivos e sistemas embarcados em
geral. A AS SOFIA é baseada em eventos, na qual cada evento corresponde à mudança de estado
de qualquer sistema de TIC. Estes eventos podem ser iniciados a partir de eventos do mundo
43
3.1. REVISÃO SISTEMÁTICA
real (como detecção de presença) ou ao término de algum processamento.
O monitoramento e gerenciamento de sensores também são objetivos definidos pela
abordagem denomida EcoCity/ISMP-UC LEE; BAIK; CHOONHWA LEE (2011). A AS
EcoCity/ISMP-UC é constituída de três camadas. A camada inferior consiste de diferentes
tipos de sensores, atuadores e outros dispositivos distribuídos pela cidade. Já a camada superior
representa um conjunto de serviços U-eco City. Entre essas duas camadas existe um middleware
responsável por coletar e processar informações contextuatilizadas. Esta AS orientada à serviços
possibilita o desenvolvimento de serviços independentes e que sejam consumidos via interfaces
padronizadas, como web services.
Por sua vez, mostashari2011citizens propõem um framework denominado Cognitive
Process Architecture Framework (CPAF), o qual permite o desenvolvimento de diferentes
serviços urbanos com habilidades cognitivas. Nesse contexto, cognição é a habilidade do
sistema aprender a partir das experiências anteriores e adaptar seu comportamento a partir destas
conclusões. Um sistema cognitivo é capaz de perceber e responder às mudanças no ambiente,
portanto, pode melhorar a performance dos serviços urbanos.
Outra abordagem na qual utiliza vários sensores embarcados nos contextos urbanos
é SmartSantander SmartSantander-2011. A quantidade de dispositivos configurados na AS
é superior à 12.000. O SmartSantander provê: i) uma AS refência para sistemas IoT; ii)
um escalável e heterogêneo laboratório para prototipação de aplicações IoT; iii) um conjunto
representativo de casos de uso implementados para facilidades de experimentação e iv) um
grande conjunto de experimentos relacionados à Internet do Futuro.
Com o mesmo objetivo de interoperabilidade de objetos abordado em Smart Santander, a
abordagem IMS SHAO (2011) propõe uma AS que combina IoT com os cidadãos das cidades.
Changheng-2011 acreditam que o desenvolvimento de TIC esta relacionado à proximidade com
os moradores das cidades. Para isso, IMS é baseada em três camadas: acesso, sessão e aplicações.
A camada de acesso é a camada mais baixa e provê toda a infraestrutura para acessar a rede IMS
a partir de diferentes terminais. A camada de sessão provê o gerenciamento de sessões entre a
camada inferior (Acesso) e a superior (Aplicações). Finalmente, a camada de aplicação permite
o desenvolvimento de diversas aplicações.
A interoperabilidade de objetos também é explorada por Hernandez-2011, que propõem
uma AS denominada Ubiquitous Sensor Network (USN). O objetivo é prover uma infraestrutura
que seja capaz de integrar sensores heterogêneos e distantes geograficamente em um base
centralizadora, na qual serviços podem ser facilmente desenvolvidos. Adicionalmente, a AS
inclui um módulo conhecido como USN-Gateway que possibilita a interoperabilidade entre redes
de sensores e redes IP.
Da mesma forma que USN, Wu’2011 WU et al. (2011) propõem um middleware para
gerenciamento de informações dispersas oriundas de múltiplas fontes, com diferentes formatos
e estruturas. Esta abordagem é construída seguindo os princípios de Arquitetura Orientada a
Serviços (SOA), baseada em duas principais componentes: modelo Contract-First e agente de
44
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
troca de mensagens.
Em Fazio’2012 FAZIO et al. (2012) é proposto uma AS que permite a agregação de
diferentes tipos de informações oriundas de diferentes sensores distribuídos pelos contextos
urbanos. O principal objetivo dessa abordagem é de prover dados contextualizados, combinando
diferentes fontes de dados. Para isso, a AS consiste de quatro camadas: I) REST que permitem
interações sob-demanda com os clientes, aplicações e outros serviços; II) Sensor Observation
Service Agent (SOS Agent) que suporta todas as funcionalidades para a descrição de sensores;
III) Sensor Manager capaz de interagir com sensores, coordenar suas atividades e coletar dados
para as demais camadas; IV) Sensing Infrastructure é composto de vários diferentes sensores.
Finalmente, a abordagem conhecida como S3 OiA VEGA-BARBAS et al. (2012) também
permite o gerenciamento de diferentes tipos de informação. A AS S3 OiA é sintática e semântica
aos princípios do SOA, que permitem a integração de qualquer tipo de dispositivo IoT. Com
essa estratégia, a AS suporta a composição de aplicações ad hoc. Para tal, foi definido dentro
do projeto da AS um conjunto de módulos de dependência semântica de gestão que controlam
serviços e recursos, permitindo que os aplicativos já criados possam continuar a execução, apesar
das mudanças do contexto.
3.2
Revisão Exploratória
As abordagens e iniciativas em CI que se baseiam na adoção de IoT podem ser desenvolvidas tanto no ambiente acadêmico quanto no empresarial. Por exemplo, pode-se ressaltar o
interesse das organizações governamentais e/ou privadas, como Microsoft PLANIT (2012), além
das iniciativas nos modelos de Startup, como Libelium 2 e Every 3 .
Além disso, pode-se encontrar diversas iniciativas em formato Web/HTML ou relatório
técnico disponibilizados pela própria organização, como HP HOOVER et al. (2010) e IBM
DIRKS; KEELING (2009).
Desta forma, para aumentar a eficácia e a abrangência da revisão literária faz-se necessário
à realização de uma revisão exploratória. Uma revisão exploratória consiste em um mecanismo
que não possui nenhum processo pré-definido para encontrar as fontes de informações.
Nesse tipo de revisão, todas as fontes relacionadas com o tema são analisadas, independente do tipo e do veículo de publicação do conteúdo. Em algumas situações, essas revisões
podem ser consideradas mais abrangentes, por não possuírem nenhum processo de classificação. Porém, em outras situações, são consideradas tendenciosas, já que o processo de revisão
dificilmente pode ser repetido.
Logo, essa revisão exploratória visa discutir e analisar as principais abordagens que propõem uma AS para CI baseada em IoT, encontradas nos mais diversos veículos de comunicação.
Dentre eles, destacam-se websites, blogs, relatórios técnicos não publicados e eventos.
2 http://www.libelium.com
3 http://www.evrythng.com
45
3.2.1
3.2. REVISÃO EXPLORATÓRIA
Metodologia de Pesquisa
Nas revisões exploratórias não há um processo ou guideline definido POLLITT (2007).
Geralmente, o procedimento consiste em levantar diversas fontes com a informação desejada e
então separá-las a partir de métodos específicos.
No caso dessa revisão, inicialmente algumas buscas foram realizadas em três repositórios
de buscas: IEEE Xplore, Mendeley e ACM Digital Library. As principais palavras-chaves
utilizadas foram: Smart Cities, Internet of Things, Architecture, Smart Enviroment, Digital
City, Smart Cities Survey. Apesar de empregar estas palavras-chaves, nenhuma string de busca
específica foi definida.
A partir dos resultados dessas buscas, alguns trabalhos foram classificados como relevantes de acordo com o título e uma rápida leitura do conteúdo. Em seguida, todos os trabalhos
restantes foram lidos e discutidos, com o mesmo grupo da Revisão Sistemática, do ponto de
vista arquitetural e do emprego das tecnologias IoT para resolver a problemática de CI. A partir
destas fontes, as principais referências destes trabalhos também foram analisadas, repetindo a
abordagem até não restar nenhum trabalho potencialmente interessante.
As revisões exploratórios possuem alguns riscos eminentes. No contexto deste trabalho,
a principal ameaça é de não encontrar abordagens maduras e com os mesmos objetivos desta
proposta, uma vez que a metodologia de pesquisa não é abrangente o suficiente. Além disso, ao
realizar uma revisão exploratório após a SLR pode-se encontrar várias abordagens repetidas.
3.2.2
Resultados
Em klein2008industrial é relatada uma perspectiva de CI voltada para negócio, especificamente de provedores de infraestruturas e soluções dentro do contexto de utilização eficiente de
energia elétrica para infraestruturas inteligente e data centers. O objetivo do trabalho é aderir
eficiência energética dos equipamentos, reduzindo os custos com energia e criando mecanismos
para que softwares e serviços tornem-se autoconscientes de seu consumo de energia. De acordo
com os autores, esta característica é essencial na implementação de uma AS de CI, permitindo
desenvolvimento e operação sustentáveis.
Em MB2-2010 é proposta uma plataforma chamada Magic Broker (MB2), a qual possui
o objetivo de permitir a interoperabilidade de objetos. Inicialmente desenvolvida com o objetivo
de prover um modelo consistente e padronizar as interfaces para a construção de aplicações
de IoT, o MB2 esta sendo adaptado para o contexto de CI. Para tal, além de prover a API
para consultas, a plataforma provê abstrações fundamentais, como: eventos, estado, serviços e
gerenciamento de conteúdo.
O MB2 consiste de uma evolução do MB original ERBAD et al. (2008), na qual foram
inseridas diversas características para a construção de aplicações ubíquas, como a inclusão de um
middleware responsável por tratar as informações oriundas dos diferentes dispositivos. Para tal,
foram acoplados diversos protocolos de comunicação como HTTP e XML. Cada implementação
46
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
desses protocolos foi implementada usando serviços OSGi4 .
Seguindo o princípio de ser um laboratório para validação de tecnologias com foco em CI,
em Lisboa/Portugal foi construída uma cidade com 1700 hectares de extensão. Conhecida como
PlanIT Valley5 , a cidade deve produzir 150% da energia necessária, gerenciar os resíduos sólidos
e reciclar toda a água consumida. Empresas privadas, como a Microsoft, Cisco, Massachusetts
Institute of Techonology e McLaren Eletronic System estão apoiando esse projeto PLANIT
(2012).
A estratégia desse projeto é implementar um Sistema Operacional Urbano(UOS). Esse
sistema operacional é uma plataforma com o intuito de integrar cada domínio que compõem
uma cidade. O sistema será alimentado por uma vasta rede de sensores e todos esses dados serão
capturados por tempo indeterminado, para auxiliar na tomada e na predição de decisões. Além
de prever catástrofes, caso ocorra, o sistema pode antever os possíveis impactos na cidade.
A sustentabilidade é um fator relevante que foi abordado em outras abordagens, como
em Masdar City HAUBENSAK (2011). A cidade de Masdar City foi desenvolvida no deserto de
Abu Dhabi com 6 km quadrados, 50.000 habitantes, 1500 empresas e universidades. O objetivo
do projeto é desenvolver projetos auto-suficientes com o mínimo de impacto ambiental. Toda
a cidade é livre de combustíveis fósseis, na qual toda a energia é oriunda de fontes renováveis,
sem nenhum tipo de resíduo. Além disso, 80% da água consumida será tratada. No quesito
transporte, os veículos privados são proibidos e os meios de transporte são veículos elétricos e
bicicletas. As estações de transportes elétricos serão separadas por uma distância de no máximo
200 metros. A primeira fase do contém aparelhos ecologicamente corretos desenvolvidos pela
General Eletric (GE).
Em nam2011conceptualizing é descrita a teoria da sinergia que deve existir entre tecnologia, pessoas e instituições na concepção de CI. O trabalho destaca especificamente que a
inteligência refere-se comumente às mudanças inovadoras trazidas por novas tecnologias. Em
relação ao aspecto tecnologia, os autores afirmam que é essencial que a cidade possua alta adaptabilidade às necessidades de seus cidadãos, independente de suas limitações, com capacidade
de autoconfiguração, proteção, otimização e recuperação de falhas, garantindo disponibilidade
de serviços a qualquer tempo. Para isso, faz-se necessário uma infraestrutura de computação
ubíqua, sobre a qual os serviços serão disponibilizados.
De acordo com andreini2011scalable, SOA é considerada uma investida promissora na
construção de CI através da implementação da IoT. Assim, objetos conectados à rede publicariam
seus serviços, que por sua vez seriam acessados a partir de clientes móveis, permitindo interações
humano-máquina e máquina-máquina (M2M) mais flexíveis. Isso seria construído a partir
de uma abordagem semelhante ao Domain Name System (DNS), no qual um objeto seria
identificado através de um nome, usado para acessá-lo e consultar serviços. Os autores propõe
uma implementação usando Distributed Hash Table (DHT), que atribui o nível de escalabilidade
4 http://www.osgi.org
5 http://living-planit.com
47
3.2. REVISÃO EXPLORATÓRIA
desejado para a abordagem adotada, permitindo a recuperação eficiente de serviços no contexto
de aplicações para CI.
Outro aspecto muito relevante para qualquer centro urbano é a predição, prevenção e
correção de situações catastróficas, nas quais medidas urgentes devem ser tomadas no menor
tempo, com a máxima eficácia possível. Em asimakopoulou2011buildings, é proposto uma
AS de gerenciamento de desastres, baseada na coleta de informações de diversas entidades incluindo pessoas, residências, veículos - imersas em um ambiente totalmente conectado, que
monitoram o meio à sua volta. No processo de geração de respostas a situações de emergência é
necessário que se tenha conhecimento histórico e em tempo real, das entidades e do ambiente
no domínio em questão, para que a solução encontrada seja eficaz. Para isso utilizou-se da
abordagem crowdsourcing, na qual os próprios cidadãos, habilitados por algum tipo de aplicação
e/ou dispositivo, contribuem com o fornecimento de dados sobre determinado cenário crítico,
auxiliando os stakeholders no processo de tomada de decisão com dados precisos e atualizados.
Já em relação à segurança, ainda na abordagem de asimakopoulou2011buildings é
discutido que os consumidores e fornecedores de dados devem ser devidamente autenticados.
Todas as entidades envolvidas na dinâmica proposta pela AS são consideradas recursos, e
sua alocação envolve uma negociação baseada em conjuntos de políticas. Isso garante que a
utilização dos recursos será sempre priorizada de acordo com a gravidade da situação corrente.
Mecanismos específicos foram criados para permitir alocação dinâmica e geração parametrizada
de alertas, assegurando a disponibilidade dos recursos.
Concomitantemente, em attwood2011sccir é proposta uma AS para infraestruturas críticas em CI, que destaca a necessidade de coleta de dados tempo real de diversos aspectos dentro
do ambiente urbano, servindo como substratos para tomada de decisões em situações críticas.
O funcionamento básico da AS consiste em um mecanismo de anotação e agregação, no qual
uma rede de sensores distribuída pela cidade estaria conectada e cujos dados estariam mapeados
para um serviço específico (Ex.: falha no sistema de distribuição de energia elétrica). Quando
algum tipo de falha fosse detectado, os dados coletados seriam fornecidos a uma instância de
raciocínio, responsável por sugerir as medidas a serem tomadas para normalizar a situação.
Para o caso de falha em algum nó da rede de sensores, outra rede seria criada a partir dos nós
ainda em funcionamento, permitindo a preservação e distribuição dos dados. Para que esta AS
seja implementada é requerida uma infraestrutura de hardware distribuída, com capacidade
de processamento em tempo real, de alta disponibilidade, preparada para demandas variáveis,
tolerante a falhas e energeticamente eficiente.
Por fim, a sustentabilidade também é explorada na AS proposta por Zygiaris-2012. O
principal objetivo desta AS é propor um modelo que possa ser empregado em qualquer planejamento urbano inteligente. Este modelo contempla os conceitos sustentáveis, especificamente
na segunda camada, conhecida como Green City. Essa camada é sustentada pela camada responsável pela infraestrutura da cidade e contém todas as políticas ambientais, por exemplo, o
nível de CO2 permitido pelas residências. As demais camadas correspondem, respectivamente:
48
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
inovação, aplicação, integração, sincronização e interconexão entre diferentes redes. Para validar
o objetivo proposto, este modelo foi utilizado nas cidades de Barcelona, Amsterdã e Edimburgo.
3.3
Consolidação das Abordagens Encontradas
As Seções anteriores descrevem várias abordagens obtidas de dois métodos distintos:
Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). Na Revisão Sistemática, foram
selecionadas 11 abordagens. Já na Revisão Exploratória 16 abordagens foram selecionadas e 7
abordagens foram encontradas em ambas as revisões. No total, 20 abordagens foram encontradas
a partir destes dois métodos.
A partir da descrição dessas abordagens, pode-se notar a relevância da temática de CI,
devido, dentre outros fatores, ao interesse de grandes empresas como Microsoft e Cisco.
A Tabela 3.3 resume as principais características dessas abordagens. Para abordagens
publicadas em periódicos, a coluna “Ano” refere-se ao ano de publicação. Já para as demais,
a mesma refere-se ao ano de criação. Por sua vez, a coluna “Incentivo” categoriza as abordagens que recebem incentivos dos governos (Público), iniciativa privada (Privada) ou de ambos
(Ambos).
Ao análisar a Tabela 3.3 percebe-se que a maioria das abordagens não estão amplamente
validadas em diversos contextos, o que ratifica o caráter inovador deste trabalho.
Além disto, nota-se que das 20 abordagens, 11 não possuem nenhum tipo de validação
prática. Este fato deve-se à alguns fatores, como:
Imaturidade da implementação das abordagens;
Falta de dados reais para simulações;
Pouquíssimas APIs públicas para acessos aos serviços de interesse do cidadão;
Falta alta de apoio governamental para a realização de experimentos práticos nos
ambientes reais.
Esta falta de suporte governamental é comprovada na coluna “Incentivo”, na qual apenas
4 abordagens contém esse tipo de suporte.
A partir dessas abordagens, a próxima Seção visa elencar um conjunto de requisitos
mínimos que uma nova AS para CI que combine IoT deve atender.
3.4
Requisitos para uma Arquitetura de Software para Cidades Inteligentes
Considerando as diferentes realidades de CI nos mais diversos lugares do planeta, é
natural imaginar que uma mesma AS não se aplique a todos os cenários. Principalmente pelo
Ano
2008
2009
2010
2010
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2012
2012
2012
2012
Aborgagem
Klein’2008
Al-Hader’2009
Anthopoulos’2010
MB2
Andreini’2011
Asimakopoulou’2011
Attwood’2011
IMS
CPAF
SOFIA
Wu’2011
Masdar City
USN
EcoCity/ISMP-UC
Nam’2011
SmartSantander
Zygiaris’2012
S3 OiA
Living PlanIT
Fazio’2012
Prover dados combinados
Integração de dispositivos via SOA
Criação de Sistema Operacional Urbano
Modelo para gerenciamento inteligente de qualquer cidade
Criação de plataforma ubíqua
Plataforma para a criação de soluções urbanas inteligentes
Gerenciamento eficiente de informações dispersas oriundas de
múltiplas fontes, com diferentes formatos e estruturas
Implementar sustentabilidade nos serviços urbanos
Interoperabilidade de objetos
O monitoramento e gerenciamento de sensores remotamente
Plataforma para situações críticas
Interoperabilidade de objetos
Criação de serviços urbanos com habilidades cognitivas
Integração de sensores
Plataforma escável que permite a interoperabilidade de objetos a
partir de SOA
Predição, prevenção e correção de situações catastróficas
Objetivo
Aumentar a eficiência energética de dispositivos conectados ao
ambiente urbano
Permitir a criação de soluções inteligentes
Integração dos sistemas legados com as novas infraestruturas,
migração e reuso de dados existentes
Permitir a interoperabilidade de objetos
Em andamento
Sem validação prática
Validada em ambiente controlado
Sem validação prática
Validada em ambiente controlado
Validado nas cidades de Barcelona, Amsterdã e Edimburgo
Sem validação prática
Em andamento em Lisboa,
Portugal
Validada em ambiente controlado
Validada em ambiente controlado
Sem validação prática
Sem validação prática
Sem validação prática
Validada em ambiente controlado
Sem validação prática
Validada em ambiente controlado
Sem validação prática
Sem validação prática
Sem validação prática
Validação
Sem validação prática
Privada
Privada
Privada
Ambos
Privada
Privada
Ambos
Privada
Ambos
Privada
Privada
Privada
Privada
Privada
Privada
Privada
Privada
Ambos
Privada
Incentivo
Privada
49
3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES
Tabela 3.3: Resumo das abordagens descritas na literatura
fato de que não se pode generalizar restrições locais, aspectos financeiros, sociais e ambientais,
ou mesmo garantir a adequação à dinâmica do cotidiano das diferentes localidades. A partir
do levantamento das arquiteturas realizado, a proposta desta Seção é discutir um conjunto de
requisitos fundamentais que devem ser atendidos na implantação de uma AS para CI.
50
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
3.4.1
Interoperabilidade de objetos
Um dos requisitos mais discutidos e estudados em projetos IoT é a interoperabilidade
de objetos, na qual cada objeto é uma abstração de um sensor, atuador ou qualquer outro
dispositivo capaz de realizar algum tipo de computação ATZORI; IERA; MORABITO (’2010’).
De fato, este é um requisito crítico para a consolidação de qualquer plataforma que utilize uma
vasta gama de objetos com diferentes especificações técnicas.
No contexto de CI este requisito também é fundamental, visto que os dados são oriundos
de diversos objetos, com tecnologias e protocolos variados.
As AS’s designam um módulo ou camada para atender esse requisito, como em SOFIA
FILIPPONI et al. (2010), USN HERNáNDEZ-MUñOZ et al. (2011), EcoCity/ISMP-UC LEE;
BAIK; CHOONHWA LEE (2011), Living PlanIT PLANIT (2012), Zygiaris’2012 ZYGIARIS
(2012), Wu’2011 WU et al. (2011) e S3 OiA VEGA-BARBAS et al. (2012). Em particular, no
caso da USN HERNáNDEZ-MUñOZ et al. (2011) este módulo, conhecido como USN-Gateway,
além de ser responsável pela interoperabilidade dos objetos em relação a plataforma, também
implementa mecanismos que permitem a interoperabilidade entre redes de sensores e a rede IP.
3.4.2
Monitoramento em tempo real
Outro importante requisito inerente ao contexto de CI é o monitoramento em tempo
real. Este requisito é de suma importância para manter todos os serviços da cidade constantemente atualizados.
Além disso, o monitoramento em tempo real é a ferramenta mais importante para fornecer
as informações mais relevantes para a predição e tomada de decisões de eventos futuros e prever
fenômenos. Um exemplo disso é o monitoramento do nível dos rios durante as temporadas de
chuva. Nessa situação, a partir de um monitoramento efetivo é possível tomar medidas para
mitigar possíveis transtornos aos cidadãos, como enchentes e a transmissão de doenças.
Logo, este requisito pode ser considerado como fundamental. Neste contexto, as AS’s que
visam atender esse requisito são Al-Hader’2009 AL-HADER et al. (2009), SOFIA FILIPPONI
et al. (2010), SmartSantander SANCHEZ et al. (2011), USN HERNáNDEZ-MUñOZ et al. (2011),
Asimakopoulou’2011 ASIMAKOPOULOU; BESSIS (2011), Attwood’2011 ATTWOOD et al.
(2011) e Living PlanIT PLANIT (2012).
3.4.3
Sustentabilidade
As cidades concentram altos índices de consumo de recursos naturais, como água e
alimentos. Além disso, vários problemas de poluição, seja poluição sonora, visual, atmosférica,
da água ou do solo, prejudicam a qualidade de vida dos cidadãos de várias cidades, principalmente
as metrópoles.
51
3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES
Neste sentido, uma AS para CI deve permitir que políticas sustentáveis (sustentabilidade) sejam implementadas com base em estatísticas relacionadas ao dia-a-dia dos cidadãos. Por
exemplo, iniciativas de consumo consciente de alimentos podem ser implementadas ao mapear
os hábitos dos cidadãos durante um dia.
Desta forma, estas políticas sustentáveis devem otimizar a utilização de recursos naturais,
a partir de iniciativas relacionadas ao meio ambiente e economia FELS (2010). Para tal é
importante ressaltar que políticas devem ser propostas nos diversos domínios que compõem uma
cidade, como Transporte e Educação.
As AS’s que integram sustentabilidade são Klein’2008 KLEIN; KAEFER (2008),
EcoCity/ISMP-UC LEE; BAIK; CHOONHWA LEE (2011), SmartSantander SANCHEZ et al.
(2011), Masdar City HAUBENSAK (2011) e Zygiaris’2012 ZYGIARIS (2012).
3.4.4
Aspectos sociais
Na implantação de CI a importância de alocar recursos, mais escassos, de forma otimizada
não pode significar a erosão da qualidade de vida das pessoas. Até porque, para de fato estabelecer
uma CI é necessário envolver as pessoas, procurando a sua participação para lhes proporcionar
maior qualidade de vida, mas protegendo a dimensão humana das urbes cada vez mais em risco
COMPUTERWORLD (2013).
Uma AS para CI não pode ser sustentada somente com tecnologia. O propósito principal
na concepção de uma CI é o aumento na qualidade de vida de seus cidadãos, através de aspectos
sociais.
Apesar do aparato tecnológico fazer parte dos elementos necessários para a implementação de uma solução mais robusta, as pessoas precisam participar e ser beneficiadas pelo processo,
caso contrário, todo investimento será em vão. Um exemplo disso, é a Cidade Digital de Trikala,
Grécia, que após cinco milhões de euros gastos em manutenção de infraestrutura e 6 anos
de funcionamento, a população não utilizava ou não tinha conhecimento dos serviços digitais
disponíveis ANTHOPOULOS; FITSILIS (2010).
De qualquer forma, CI são construídas por pessoas, para pessoas, e essa deve ser uma
premissa contemplada em todas os aspectos supridos pela AS. Uma CI é feita de, sobretudo,
uma mudança no comportamento de seus cidadãos. As pessoas precisam sentir-se inclusas como
parte fundamental na implantação de uma CI, sentir-se estimuladas a fazer parte da solução.
Para isso podem ser criadas formas de estimular e/ou retribuir esse interesse, como é caso da
iniciativa Fun Theory6 , da Volkswagen, na qual mudam-se as maneiras de fazer as coisas, a fim
de estimular a mudança de hábitos.
Além disso, os serviços devem estar disponíveis para todos os cidadãos independente de
quaisquer restrições social, física, econômica ou financeira, a tecnologia deve ser aplicada a fim
de trazer benefícios coletivos, e não alienar ou elitizar uma pequena parte da população.
6 http://www.thefuntheory.com/
52
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
Apesar da evidente importância deste requisito fundamental, apenas as AS’s que explicitamente contém aspectos sociais são Klein’2008 KLEIN; KAEFER (2008), IMS SHAO (2011) e
Asimakopoulou’2011 ASIMAKOPOULOU; BESSIS (2011).
3.4.5
Ubiquidade/Mobilidade
A proximidade dos dispositivos com as pessoas/cidadãos, geralmente a partir da internet,
origina o termo ubiquidade SPÍNOLA; TRAVASSOS (2012). Neste sentido, este termo corresponde a qualquer tecnologia móvel capaz de capturar informação sobre o ambiente ou atuar
sobre o mesmo SANCHEZ et al. (2011).
Ao considerar que 4 bilhões de cidadãos já possuem smartphones HALL (2012), é
natural associar ubiquidade ao uso destes dispositivos. Porém outros dispositivos devem ser
utilizados, como ZigBee e RFID (Radio-frequency identification).
Logo, uma AS para CI deve permitir a comunicação efetiva com os mais diversos dispositivos oriundos da temática de ubiquidade, uma vez que estes estarão fisicamente próximos aos
cidadãos. Neste contexto, as AS’s que já empregam alguns destes princípios são SmartSantander
SANCHEZ et al. (2011), USN HERNáNDEZ-MUñOZ et al. (2011), MB2 BLACKSTOCK et al.
(2010) e Zygiaris’2012 ZYGIARIS (2012).
3.4.6
Privacidade e Segurança dos dados
O ambiente de uma cidade pode ser considerado ubíquo já que diversos sensores são
instalados em diferentes locais e coletam diferentes tipos de informação SANCHEZ et al. (2011).
Todo esse volume de dados deve ser protegido fazendo uso das políticas de privacidade e
segurança dos dados, tanto em relação à disponibilidade quanto ao armazenamento.
Certamente a consolidação destes políticas é um desafio que pode impedir os cidadãos, instituições e o governo de fornecerem determinados dados críticos. Este fato pode ser
comprovado a partir dos recentes casos de violação de privacidade dos dados governamentais
amplamente divulgados pela imprensa, como os documentos vazados da National Security
Agency (NSA) BIRD (2013).
Devido a alta relevância deste requisito, não é admissível que uma AS não o satisfaça.
Apesar disso, apenas as AS’s SmartSantander SANCHEZ et al. (2011), Living PlanIT PLANIT
(2012) e Fazio’2012 FAZIO et al. (2012) abordam este requisito.
3.4.7
Geolocalização dos sensores
De acordo com Changheng-2011, Hernandez-2011, Barbas-2012, a geolocalização dos
sensores é fundametal para o refinamento do processo de análise de dados. Neste sentido, um
sensor corresponde à uma abstração de qualquer dispositivo capaz de fornecer informações sobre
determinado contexto.
53
3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES
A partir destas informações geográficas dos sensores é possível realizar ações específicas
para cada ambiente JAUREGUI-ORTIZ et al. (2012). Esta característica pode ser notada nas
abordagens IMS SHAO (2011), USN HERNáNDEZ-MUñOZ et al. (2011) e S3 OiA VEGABARBAS et al. (2012). No caso da abordagem IMS, a geolocalização dos sensores é importante
para a investigação do comportamento dos cidadãos; na USN, a localização é considerada um
requisito diferenciador; por fim, em S3 OiA a localização é utilizada para unificar as ações
realizadas sobre um determinado conjunto de sensores.
3.4.8
Composição de Dados Urbanos
Em uma visão sistêmica, ambientes urbanos são essencialmente um conjunto de domínios
complexos (como transporte, água, energia elétrica, saneamento básico, etc.) disponibilizados
para suprir as necessidades de seus cidadãos. AS’s que se dispõe a dar suporte à esses sistemas
devem considerá-los como complementares na busca de um gerenciamento urbano efetivo, ao
invés de tratá-los de forma isolada.
Pelo fato de que CI pode ser considerada um sistema de sistemas, a composição dos
dados oriundos destes ambientes urbanos deve ser considerada um requisito fundamental.
Estes dados de cada ambiente urbano deve ser disponibilizado de forma que possam ser
reutilizados e agrupados para criar uma visão holística e contextualizada da cidade na qual a AS
foi implementada ANTHOPOULOS; FITSILIS (2010); NAM; PARDO (2011); PLANIT (2012).
Para atender essa composição de dados urbanos as AS’s Nam’2011 NAM; PARDO
(2011), CPAF MOSTASHARI et al. (2011), IMS SHAO (2011), Anthopoulos’2010 ANTHOPOULOS; FITSILIS (2010), Fazio’2012 FAZIO et al. (2012) e Living PlanIT PLANIT (2012)
implementam explicitamente algum módulo que visa atender este requisito fundamental.
3.4.9
Histórico de dados
No contexto de CI, todos os componentes que compõem cada domínio de uma cidade
estão constantemente sendo modificados, seja por eventos humanos, naturais ou tecnológicos.
Dessa forma, todo dado captado tem potencial para se tornar uma informação relevante, desde
que seja agregado a outros dados.
Estes dados históricos podem ser empregados na predição de eventos futuros, principalmente quando houver um grande período sem dados em tempo real. Por exemplo, a partir
de informações meterológicas dos anos anteriores é possível prever os meses que poderão ter
tempestades. Com informação nessa granularidade é possível adotar providências preventivas
para evitar catóstrofres.
Logo, torna-se substancial que as AS’s contemplem mecanismos eficientes de armazenamento e consulta desses dados. Como é citado em MB2 BLACKSTOCK et al. (2010),
SmartSantander SANCHEZ et al. (2011), EcoCity/ISMP-UC LEE; BAIK; CHOONHWA LEE
54
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
(2011) e Living PlanIT PLANIT (2012), estas informações historicamente armazenadas potencializarão os resultados obtidos a partir de um algoritmo de contexto e mineração de dados.
3.4.10
Disponibilidade
Para permitir a captação de dados em tempo real e o fornecimento de informações
contextualizadas, a AS deve ser altamente disponível, em qualquer dia e horário.
Na literatura existem diversas iniciativas que propõem mecanismos para garantir a disponibilidade da AS. Dentra elas, a mais discutida e utilizada é relacionada à Cloud Computing.
Desta forma, caso a infraestrutura de cloud computing seja utilizada, mecanismos de controle de
fluxo, colisão e redundância devem ser inerentes à solução.
Nas AS’s SmartSantander SANCHEZ et al. (2011), USN HERNáNDEZ-MUñOZ et al.
(2011) e Nam’2011 NAM; PARDO (2011), estas situações são tratadas utilizando diversos
mecanismos de modularidade em relação a cloud.
3.4.11
Sensoriamento e Processamento Distribuído
Para que sejam propostas soluções para o aumento da eficácia em serviços urbanos é
necessário que se façam aferições das características qualitativas ou quantitativas que permeiam
esses serviços, bem como do resultado que produzem. É através de sensoriamento que se obtêm
a visão computacional do ambiente urbano; quanto maior o número de sensores e mais disperso
eles estiverem, maior será o escopo abrangido pela AS.
A heterogeneidade dos sensores utilizados influencia na riqueza de detalhes e na quantidade de dados que podem ser extraídos de cada cenário monitorado, sendo possível obter
resultados mais precisos. Por exemplo, reports de trânsito em determinada via podem ser
melhor analisados se complementados com imagens obtidas através de câmeras instaladas nas
redondezas.
Em situações que exigem que medidas preventivas ou corretivas sejam tomadas instantaneamente exige-se processamento em tempo real, com tempo de resposta rápido o suficiente para
fornecer embasamento para ações que devem ser executadas assim que determinada situação
é identificada. Considerando quantidades massivas de dados coletados, o suporte à esse tipo
de contexto sugere a necessidade de processamento distribuído, explorando a capacidade da
infraestrutura existente.
Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerar
informações e conhecimento, permite execução de seus serviços de forma otimizada e um
gerenciamento urbano eficiente.
As AS’s que visam atender esse requisito são USN HERNáNDEZ-MUñOZ et al. (2011),
SOFIA FILIPPONI et al. (2010), Andreini’2011 ANDREINI et al. (2011) e EcoCity/ ISMP-UC
LEE; BAIK; CHOONHWA LEE (2011).
55
3.4.12
3.5. SUMÁRIO DOS REQUISITOS PARA CIDADES INTELIGENTES
Flexibilidade/Extensibilidade
Este requisito corresponde à capacidade da AS adaptar-se à mudanças e extensões. Além
da inserção de novos serviços, a AS deve ser capaz de adaptar-se à novos requisitos inerentes ao
contexto de implementação. Por exemplo, a AS deve ser independente de padrões específicos de
hardware.
Apesar da evidente relevância deste requisito, apenas três AS’s exploram este requisito:
Klein’2008 KLEIN; KAEFER (2008), MB2 BLACKSTOCK et al. (2010) e EcoCity/ISMP-UC
LEE; BAIK; CHOONHWA LEE (2011).
3.5
Sumário dos Requisitos para Cidades Inteligentes
A Tabela 3.4 ilustra um resumo dos requisitos que foram implementados nas AS’s
abordadas nesse Capítulo. Nesta tabela, a coluna # representa a quantidade de abordagens
encontradas que visam atender ao determinado requisito.
Ao analisar essas informações, pode-se perceber que nenhuma dessas AS’s implementam
minimamente todos os requisitos levantados.
Isto deve-se ao fato de que as AS’s geralmente são projetadas para propósitos específicos
e cada uma propõe uma solução focada especificamente no problema que pretende resolver.
Além disso, percebe-se que os requisitos de Interoperabilidade de Objetos e Monitoramento em Tempo Real são os mais abordados pelas AS’s. Esta observação confirma a
importância em monitorar constantemente todos os aspectos que envolvem a cidade, processar
e disponibilizar os dados coletados rapidamente, a fim de fornecer uma visão de estado do
ambiente urbano mais precisa e atualizada para dar suporte às tomadas de decisão em tempo real.
A AS descrita em PLANIT (2012) atende o maior número de requisitos considerados
essenciais no contexto desse trabalho. A abordagem de estruturação da AS, cujas camadas
apresentam os mesmos princípios de abstração encontrados em sistemas operacionais, garante
as mesmas vantagens aos mesmos atribuídas - como abstração e gerenciamento de dispositivos
físicos - que aliada à conectividade expande a abrangência de atuação dentro do ambiente urbano,
criando um ambiente pervasivo favorável a uma gestão urbana efetiva.
3.6
Discussão do Capítulo
Neste Capítulo foram apresentadas 20 abordagens, em diferentes estágios de validação,
oriundas de dois tipos de revisão: Revisão Sistemática e ad hoc. A partir da revisão exploratória
foram encontrados trabalhos com investimentos da iniciativa privada e que já se encontram em
estágio de prototipação.
Ao término desse Capítulo, pode-se perceber que não há a necessidade da criação de um
novo padrão arquitetural ou adaptação de um padrão já existente para o contexto de CI e IoT.
56
CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
Tabela 3.4: Mapeamento requisitos-arquiteturas
Requisito
Interoperabilidade de objetos
Monitoramento em tempo
real
Sustentabilidade
Aspectos sociais
Ubiquidade/Mobilidade
Privacidade e Segurança dos
dados
Geolocalização dos Sensores
Composição de Dados Urbanos
Histórico de dados
Disponibilidade
Sensoriamento e Processamento Distribuído
Flexibilidade/Extensibilidade
Abordagens
SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygiaris’2012, Wu’2011 e S3 OiA
Al-Hader’2009, SOFIA, SmartSantander, USN, Asimakopoulou’2011, Attwood’2011 e Living PlanIT
Klein’2008, EcoCity/ISMP-UC, SmartSantander, Masdar
City e Zygiaris’2012
Klein’2008, IMS e Asimakopoulou’2011
SmartSantander, USN, MB2 e Zygiaris’2012
SmartSantander, Living PlanIT e Fazio’2012
#
7
IMS, USN e S3 OiA
Nam’2011, CPAF, IMS, Anthopoulos’2010, Fazio’2012 e
Living PlanIT
MB2, SmartSantander, EcoCity/ISMP-UC e Living PlanIT
SmartSantander, USN e Nam’2011
USN, SOFIA, Andreini’2011 e EcoCity/ISMP-UC
3
6
Klein’2008, MB2 e EcoCity/ISMP-UC
2
7
5
3
4
3
4
3
4
Ainda em relação aos padrões arquiteturais, nota-se que o modelo de arquiteturas em camadas é
o mais utilizado, pois permitem o escalonamento de uma AS. Outro padrão bastante empregado
pelas AS’s foi o publisher-subscriber, devido, principalmente, as vantagens em utilizá-lo para
modelar o ambiente real.
Além disso, pode-se perceber que algumas AS’s foram propostas para finalidades específicas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem mecanismos
interessantes de tratamento de eventos em tempo real que devem ser considerados no desenvolvimento de qualquer AS para CI.
Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há um
consenso amplamente aceito na literatura sobre quais os requisitos que uma AS deve atender para
ser considerada efetiva, independente da forma como foi implementada. A partir das abordagens
estudadas, pode-se estabelecer um conjunto de requisitos essenciais ao analisar os principais
objetivos das abordagens previamente descritas. Esses requisitos constituem a base para qualquer
AS para CI, pois abrangem os princípios definidos para uma CI.
Ao analisar esse conjunto de requisitos, nota-se que nenhuma AS atendeu todos os
requisitos. Geralmente, as AS’s são propostas com propósitos específicos e ignoram alguns
requisitos essenciais.
Dessa forma, ao propor uma nova AS para CI é de suma importância que ela atenda a
maior quantidade desses requisitos, para que uma cidade possa ser de fato considerada inteligente. Esses requisitos servirão como pilares para a elaboração da AS para CI que combine as
tecnologias de IoT que será descrita nos próximos Capítulos.
57
3.7
3.7. CONSIDERAÇÕES FINAIS DO CAPÍTULO
Considerações Finais do Capítulo
Este Capítulo apresentou algumas abordagens arquiteturais encontradas na litetura. Para
tal, dois métodos de revisão da literatura foram utilizados: Revisão Sistemática e ad-hoc.
A Seção 3.1 apresentou a metodologia utilizada durante o processo de revisão sistemática.
Posteriormente, os resultados foram apresentados em ordem cronológica.
Por sua vez, a Seção 3.2 apresentou a revisão ad-hoc e os respectivos resultados, ressaltando, principalmente, o estágio de validação das abordagens encontradas.
Na Seção 3.3 foi realizado uma consolidação das características mais relevantes de cada
abordagem. Por fim, a Seção 3.4 apresentou um conjunto de requisitos, extraídos a partir da
análise das abordagens, que uma AS para CI deve atender.
Estes requisitos foram utilizados para guiar o desenvolvimento da proposta deste trabalho.
Logo, o próximo Capítulo apresenta esta proposta, utilizando um método de descrição arquitetural
amplamente discutido na literatura KRUCHTEN (1995).
59
4
Uma Arquitetura de Software para Cidades
Inteligentes baseada na Internet das Coisas
Os verdadeiros analfabetos são os que aprenderam a ler e não lêem.
—MARIO QUINTANA, 2006 (Caderno H)
Baseado nas demandas de uma AS para Cidade Inteligente (CI) que possibilite a integração de tecnologias IoT e no conjunto de requisitos que foi definido no Capítulo anterior,
este Capítulo visa propor uma AS para CI que permita a combinação com tecnologias IoT. O
foco da solução proposta consiste em atender um sub-conjunto destes requisitos, bem como
prover mecanismos, do ponto de vista de infraestrutura, para que novos requisitos possam ser
futuramente incluídos, de acordo com o contexto de cada cidade.
Dessa forma, a Seção 4.1 apresenta este sub-conjunto de requisitos que serão abordados
nesta proposta. Já para descrever a proposta detalhadamente é utilizado um método de descrição
de AS’s baseado em visões, conhecido como “4+1”, na Seção 4.2.
Em seguida, cada visão abordará aspectos específicos da AS. A Seção 4.3 apresentará
a Visão Lógica, a partir de um ponto de vista funcional, relacionando os principais módulos e
as operações realizadas com mais frequência. Por sua vez, a Seção 4.4 apresentará a Visão de
Execução, com o mapeamento dos componentes lógicos em processos e threads. A Seção 4.5
apresentará a Visão de Implementação, seguido da Seção 4.6 explicitando a Visão Física. Além
das visões deste método, duas outras visões definidas pelo SEI CLEMENTS (2003) foram utilizadas para facilitar a compreensão pelos stakeholders: Visão Componente Conector (Seção 4.7)
e Visão de Dependências (Seção 4.8).
Por fim, a Seção 4.9 apresentará alguns dos principais cenários de utilização desta AS,
do ponto de vista de orgãos governamentais e não-governamentais, cidadãos e desenvolvedores.
Finalmente, a Seção 4.10 consolida as principais características da AS proposta discutidas
60CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
neste Capítulo e a Seção 4.11 finaliza o Capítulo.
4.1
Requisitos abordados
A partir da descrição dos requisitos realizada no Capítulo anterior, um sub-conjunto de
requisitos foi selecionado para ser abordado nesta proposta de AS. A Tabela 4.1 exibe todos
os requisitos e indica quais destes foram abordados nesta proposta, ordenados pela quantidade
de abordagens encontradas que visam atender o determinado requisito, conforme ilustrado na
coluna #.
Tabela 4.1: Requisitos abordados
Requisito
Interoperabilidade de objetos
Monitoramento em tempo real
Composição de Dados urbanos
Sustentabilidade
Histórico de dados
Ubiquidade/Mobilidade
Sensoriamento e Processamento Distribuído
Geolocalização dos Sensores
Privacidade e Segurança dos dados
Aspectos sociais
Disponibilidade
Flexibilidade/Extensibilidade
Abordado
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Não
Não
Não
Sim
#
7
7
6
5
4
4
4
3
3
3
3
2
Ao analisar a Tabela 4.1, percebe-se que do total de 12, apenas 4 não foram incluídos
nesta proposta e 8 foram incluídos. Para realizar essa priorização, dois fatores foram ponderados:
i) a importância/relevância do requisito, inferida a partir da quantidade de abordagens na literatura
que visam satisfazer esse requisito, conforme pode ser observado na coluna “#”; e ii) este conjunto
de requisitos foi incluído nesta proposta são os requisitos mínimos que toda AS de software para
CI deve atender.
Os demais requisitos que, mesmo considerados importantes/relevantes, não foram abordados nesta proposta, dificilmente podem ser abordados nesta proposta no estágio atual. A
saber:
Sustentabilidade: A proposta atual não possui nenhuma parceria com instituições
governamentais. Logo, nas 5 abordagens na qual esta requisito foi encontrado,
todas possuíam uma parceria com as prefeituras locais, que criavam campanhas para
incentivar o consumo consciente dos cidadãos.
Privacidade e Segurança dos dados: De fato, esta necessidade foi identificada no
começo desta pesquisa, porém um outro trabalho de mestrado está sendo desenvolvido
com este escopo. Este trabalho de privacidade será acoplado à esta proposta assim
que finalizado. Para isso, as definições de interfaces e padrões de mensagens estão
sendo definidas em conjunto. O escopo deste trabalho de privacidade é criar um
61
4.2. METODOLOGIA “4+1”
mecanismo em que, a partir das interações anteriores, os cidadãos possam “negociar”
o quão seus dados estarão disponíveis para um determinado provedor de serviço
urbano.
4.2
Aspectos sociais: Da mesma forma que o requisito de Sustenabilidade, para que
a AS atenda ao requisito de Aspectos Sociais é necessário o estabelecimento de
parcerias com as instituições governamentais para de fato incluir os cidadãos como
parte do sistema de uma CI.
Disponibilidade: O requisito de Disponibilidade está relacionado à infraestrutura na
qual esta proposta estará sendo executada.
Metodologia “4+1”
A Arquitetura de Software (AS) tem desempenhado um papel fundamental no desenvolvimento de sistemas de software. Ela oferece um maior entendimento da aplicação por dividi-la
em um conjunto de componentes que interagem entre si para realizar parte de uma ou várias
funcionalidades do sistema GARLAN; SHAW (1994).
Porém, diversos autores relatam a falta de eficiência em documentar essas AS’s para
que sejam legíveis para os mais variados stakeholders GARLAN; SHAW (1994); CLEMENTS
(2003). Visando atender essa ineficiência, em Kruchten:1995:VMA:624610.625529 é proposto
um método de descrição de AS’s baseado em visões chamado “4+1”. Para facilitar a compreensão
pelos stakeholders, duas outras visões definidas pelo SEI CLEMENTS (2003) foram utilizadas:
Visão Componente Conector e Visão de Dependências. A integração dessas visões é ilustrada na
Figura ??.
file = images/prom odelo.pd f , width = 10cm
Figura 4.1: Integração das visões do modelo “4+1” com as visões definidas pelo SEI
Este uso de múltiplas visões permite abordar separadamente as preocupações de vários
stakeholders da AS: usuários finais, desenvolvedores, engenheiros de sistemas, gerentes de
projetos, entre outros; e permite avaliar separadamente os requisitos funcionais e não funcionais.
Estas visões abordam aspectos de relevância arquiteturais sob diferentes perspectivas:
A visão lógica aborda os elementos significativos do projeto para a AS adotada e a
relação entre eles. Entre os principais elementos estão os módulos, os componentes,
os pacotes e as classes principais de aplicação;
A visão de execução relata os aspectos de concorrência e sincronização do sistema,
mapeando os elementos da visão lógica de processos, threads e tarefas de execução;
62CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
A visão de implementação centra-se em aspectos relacionados com a organização
do código-fonte do sistema, padrões de AS utilizada e as orientações e as normas
para o desenvolvimento do sistema;
A visão física demonstra as configurações de hardware e o mapeamento dos elementos de software para os elementos de hardware no ambiente do sistema;
A visão componente conector se refere ao comportamento dos componentes em
tempo de execução e seus conectores, que são responsáveis pela comunicação entre
estes;
A visão dependências ilustra as dependências existentes entre os módulos da AS ;
Os cenários mostram um subconjunto dos casos de uso significativo da AS.
No contexto de CI, diferentes stakeholders são envolvidos no processo de criação de uma
solução eficiente, por exemplo, prefeito, secretarias públicas, desenvolvedores e cidadãos. Logo,
o método “4+1” foi escolhido e duas visões foram adicionadas para descrever esta proposta
arquitetural justamente para contribuir no entendimento por estes diferentes stakeholders.
4.3
Visão Lógica
Esta Seção demonstra a organização da AS a partir de um ponto de vista funcional. Os
principais elementos, como módulos e componentes principais são especificados. A interface
entre estes elementos também é especificada. A Figura 4.2 ilustra a arquitetura do ponto de vista
lógico.
As subseções seguintes explicitarão cada módulo, ressaltando sua responsabilidade e os
requisitos funcionais atendidos.
4.3.1
Módulo de Acesso e Comunicação (MAC)
O Módulo de Acesso e Comunicação (MAC) representa o ponto de entrada para as
aplicações e serviços externos. O MAC provê os mecanismos necessários para o acesso e a
comunicação com a AS, a partir da interface REST (Representational state transfer).
De acordo com MB2-2010 e Hernandez-2011, utilizar uma interface padronizada, como
REST, é uma das técnicas empregadas para tornar a AS compatível com as tecnologias móveis, como totens, smartphones e tablets. Esta decisão arquitetural permite que a AS torna-se
compatível com o requisito de ubiquidade/mobilidade.
Além disso, de acordo com MB2-2010 e Filipponi-2010, a principal estratégia para que
uma AS contemple a interoperabilidade de objetos é permitir a comunicação com dispositivos
e sistemas através de diferentes protocolos de troca de mensagens. Para tal, o MAC contém
63
4.3. VISÃO LÓGICA
Módulo de
Acesso e
Comunicação
(MAC)
REST
Módulo de
Persistência de
Dados (MPD)
Interface: Protocolos de troca de mensagens
DHT-BD
Registro de recursos
Interface: Banco de Dados
Driver
BD3
BD3
Driver
BD2
BD2
Driver
BD1
BD1
Configuração de recursos
Módulo de
Gerenciamento
de Recursos
(MGR)
C
DHT Canal
de
dados
C
...
C
C
...
C
C
...
....
Canal 2
Canal 1
...
P
P
...
P
P
...
Canal 3
P
P
Módulo de
Gerenciamento
e Distribuição
de Dados
(MGDD)
...
Figura 4.2: Visão lógica da Arquitetura de Software (AS) proposta
uma interface padronizada que permite a inserção de novos adaptadores que implementam os
diferentes protocolos de troca de mensagem sob demanda.
O funcionamento do MAC consiste em receber cada requisição dos diferentes recursos
e encaminhá-las para os demais módulos. Para isso, o MAC oferece todos os operações para
interagir com a AS, por exemplo, operações responsáveis pelo Registro de Recursos, como será
detalhado na seção a seguir. De acordo com a operação do método, este delega ação para o
respectivo módulo.
4.3.2
Módulo de Gerenciamento de Recursos (MGR)
Do ponto de vista de uma AS para CI, um recurso pode ser considerado sensores
espalhados pela cidade, um cidadão portando um dispositivo móvel ou até mesmo um sistema
externo (como um perfil em qualquer rede social), dentre outros tipos de fornecedores de dados
SANCHEZ et al. (2011); KLEIN; KAEFER (2008); ASIMAKOPOULOU; BESSIS (2011).
Desta forma, o Módulo de Gerenciamento de Recursos (MGR) visa gerenciar as informações relativas a estes fornecedores de dados. Dentre essas informações, a geolocalização dos
sensores deve ser mantida a fim de aumentar a eficiência e a confiabilidade do dado fornecido
HERNáNDEZ-MUñOZ et al. (2011); SHAO (2011); VEGA-BARBAS et al. (2012).
Para tal, o MGR contém dois sub-módulos: Registro e Configuração de recursos. O
Registro de Recursos contém operações, acessíveis a partir do MAC, que permitem o registro de
um recurso. Além disso, a partir da existênca deste recurso, este sub-módulo disponibiliza todas
as informações de um recurso por toda a AS. Já o sub-módulo de Configuração de Recursos
possui operações para gerenciar as configurações do recurso, por exemplo, a frequência de tempo
64CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
em que os dados são disponibilizados.
4.3.3
Módulo de Gerenciamento e Distribuição de Dados (MGDD)
O Módulo de Gerenciamento e Distribuição de Dados (MGDD) possui a responsabilidade
de disseminar os dados por toda AS. Logo, pode ser considerado o core da AS, por (i) atender a
maior quantidade de requisitos; (ii) implementar os principais mecanismos que diferenciam esta
AS das demais abordagens semelhantes e (iii) implementar toda a infraestrutura de distribuição
de dados.
Um dos padrões mais utilizados no design de AS é o publisher-subscriber, na qual a principal vantagem é o desacoplamento entre os produtos e fornecedores de dados BUSCHMANN
et al. (1996). O MGDD contém uma implementação deste padrão, representados na Figura 4.2
pelas caixas com a letra ’P’ e ’C’, respectivamente.
No MGDD, os fornecedores (publisher) fornecem dados em um canal específico de
dados; por sua vez, os consumidores (subscriber) devem ser inscreverem nestes canais de dados
para que assim que um novo dado seja disponibilizado, este possa ser recebido e processado.
Este comportamento é classificado como uma das técnicas para modelar-se eventos do mundo
real em AS, pois permite disparar eventos simultâneamente, na qual pode-se ativar um ou
mais eventos possivelmente encadeados FILIPPONI et al. (2010); HERNáNDEZ-MUñOZ et al.
(2011); SANCHEZ et al. (2011); WU et al. (2011); FAZIO et al. (2012).
A implementação do padrão publisher-subscriber no MGDD também possibilita a
adequação à um dos mais importantes requisitos de uma AS para CI: a Composição de Dados
Urbanos PLANIT (2012); NAM; PARDO (2011); MOSTASHARI et al. (2011). Para tal, um
mesmo componente consumidor (subscriber) pode se inscrever em dois ou mais canais, obter
estes diferentes dados e compô-los de alguma forma. A Seção 4.3.6 exemplificará esse cenário.
Além disso, o MGDD permite que novos canais de dados sejam criados sob demanda.
Esta peculiaridade proporciona certa flexibilidade para a AS, visto que não há restrições do
limite para a criação de canais nas quais dados possam ser trafegados.
Assim que um novo canal de dados é criado, este deve registrar-se na “Distributed Hash
Table (DHT) Canais de Dados”. Esta DHT permite que os canais de dados sejam acessíveis
para todos os consumidores, através de consultas pelo tipo de dado que é disponibilizado. Da
mesma forma, DHT é utilizada para os fornecedores obterem a referências para os canais mais
apropriados para fornecerem seus dados. A Seção 4.3.6 exemplificará este cenário com um caso
prático.
Além disso, a utilização de uma DHT é importante para prover escalabilidade e processamento distribuído. A escalabilidade é obtida a partir da criação de novos canais de dados, a
medida que o sistema se expande. Da mesma forma, como não há limite de consumidores e
fornecedores no mesmo canal de dado, a DHT permite a escalabilidade em termos de recursos
de dados.
65
4.3. VISÃO LÓGICA
Já em relação ao processamento distribuído, a DHT permite que os canais de dados
estejam distribuídos em diferentes hosts, desde previamente registrado no MGR. Logo, assim
que uma consulta por um respectivo canal de dado é realizado na DHT, esta se encarregará
de encontrar as informações deste canal, a partir das informações do MGR. Desta forma,
uma camada de abstração é criada entre o canal e os consumidores e fornecedores, a fim de
proporcionar maior desacoplamento, extensibilidade e flexibilidade.
4.3.4
Módulo de Persistência de Dados (MPD)
O Módulo de Persistência de Dados (MPD) possui a responsabilidade de armazenar
os dados oriundos dos diferentes níveis da AS. Estes dados, em todos os níveis da AS, são
importantes para a predição de acontecimentos futuros, a partir do histórico de dados.
Para tal, o módulo deve realizar consultas e inserções rápidas e fornecer uma interface
transparente para quem a utiliza sobre o respectivo banco de dados. Esta interface é importante
para permitir o desacoplamento entre o respectivo banco de dados com os componentes que o
utilizam.
Antes de algum recurso realizar uma consulta em um banco de dados específico, este pode
ser encontrado a partir da “DHT Banco de Dados”. Por sua vez, essa DHT tem a responsabilidade
de gerenciar todos os drivers de banco de dados disponíveis no momento da transação, além de
permitir que os bancos de dados estejam distribuídos em diferentes hosts.
Estudos futuros devem ser realizados para avaliar o banco de dados mais adequado de
acordo com o tipo e formato do dado.
4.3.5
Mapeamento Requisito x Módulo
A Tabela 4.2 ilustra o módulo no qual cada requisito é contemplado. Como nota-se,
geralmente um requisito é implementado a partir da combinação de dois ou mais módulos da
AS.
Tabela 4.2: Mapeamento Requisitos por Módulo
Requisito
Interoperabilidade de objetos
Monitoramento em tempo real
Composição de Dados urbanos
Histórico de dados
Ubiquidade/Mobilidade
Sensoriamento e Processamento Distribuído
Geolocalização dos Sensores
Flexibilidade/Extensibilidade
MAC
X
X
X
MGR
X
X
X
X
X
X
MGDD
X
X
X
X
X
X
X
MPD
X
X
X
X
66CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
4.3.6
Operações
Esta Seção apresenta as principais operações a serem realizadas na AS, a partir de
Diagramas de Sequência.
4.3.6.1
Consumidor: Recurso receber dados
A Figura ?? ilustra uma abstração de um diagrama de fluxo referente as atividades
a serem realizadas para que um recurso obtenha um dado. Este diagrama abstrai algumas
peculiaridades, como a implementação da interface padronizada exigida para o funcionamento
correto do padrão publisher-subscriber.
Inicialmente, este recurso deve solicitar a referência do canal que contém o dado em
questão, a partir do mapeamento existente na DHT. Caso a DHT encontre este canal, a referência
é retornada. De posse da referência, o recurso pode se inscrever no respectivo canal. Assim
que um novo dado for fornecido por qualquer recurso fornecedor, o dado será imediatamente
sentregue aos recursos que se inscreveram nesse canal.
file = images/receberd ado.pd f , width = 10cm
Figura 4.3: Abstração da operação de um recurso receber dados
4.3.6.2
Produtor: Fornecer dado
Por sua vez, o mecanismo para fornecer um dado é bem parecido ao recebimento de um
dado. Existem dois cenários específicos para o fornecimento de dado: (i) quando já existe um
canal no qual o dado é disponibilizado, ou seja, existe pelo menos mais um recurso fornecedor
que já fornece esse dado; ou (ii) quando é o primeiro recurso fornecedor a fornecer o dado.
Em ambos os casos, primeiramente, o recurso deve verificar na DHT se já existe um
canal no qual este dado é fornecido. Caso exista, a DHT retornará a referência desse canal que
corresponde ao primeiro cenário, como ilustrado na Figura ??.
file = images/fornecerd ado.pd f , width = 10cm
Figura 4.4: Abstração da operação de um recurso fornecer dado
Caso contrário, a DHT retornará uma resposta de que o canal requisitado não existe,
como ilustrado na Figura ??. A partir desta resposta, o recurso fornecedor deve solicitar uma
nova referência de canal para fornecer este tipo de dado, fornecendo as informações necessárias.
Feito isso, a DHT retornará a referência ao novo canal.
file = images/fornecern ovod ado.pd f , width = 10cm
Figura 4.5: Abstração da operação de um recurso fornecer um novo tipo de dado
De posse da referência ao canal que será fornecido o dado, em ambos os casos, basta o
recurso fornecedor enviar os respectivos dados assim que eles estiverem disponíveis.
67
4.3.6.3
4.4. VISÃO DE EXECUÇÃO
Compor um dado urbano
A operação de compor um dado urbano pode ser considerada uma combinação entre
as operações de Receber e Fornecer um dado. Como ilustrado na Figura ??, esta operação é
dividida em 3 fases: Setup, Consumo de Dados e Criação de dados.
A primeira fase, Setup, corresponde aos passos necessários para iniciar uma composição
de dados urbanos. Inicialmente, o recurso deve consultar se o canal com o dado que será
combinado já existe. Caso não exista, o recurso deve solicitar a disponibilização deste canal e a
devida referência deve ser retornada.
De posse da referência do canal na qual será disponibilizada o dado combinado, inicia-se
a segunda fase, conhecida como Consumo de Dados. Nesta fase, o recurso deve consultar a DHT
para adquirir a referência de todos os canais que já fornecem os dados que serão utilizados para a
combinação. Após obter a referência de todos os canais, o recurso deve se inscrever para receber
os dados oriundos destes canais.
file = images/compord ado.pd f , width = 14cm
Figura 4.6: Operação de composição de dados urbanos
Não há nenhuma restrição na quantidade de dados que podem ser utilizados para combinação, ou seja, o recurso pode se inscrever em vários canais para utilizar estes dados na
combinação.
Feito isso, inicia-se a terceira fase, Criação de Dados. Esta fase corresponde ao mecanismo de receber os dados dos vários canais inscritos, combiná-los de alguma forma utilizando
algum tipo de regra de negócio e disponibilizá-lo no canal obtido na fase de Setup.
Vale ressaltar que a fase de Criação de Dados é a única que continua sendo executada
em background por tempo indeterminado. Além disso, ressalta-se que o momento em que a
nova informação combinada é disponibilizada no canal resultante depende da regra de negócio
implementada. Por exemplo, um recurso de combinação de dados que gera um relatório das
unidades de emergência por regiões de uma cidade pode consumir os dados de cada unidade e
gerar esse relatório uma vez por dia.
4.4
Visão de Execução
Esta Seção apresenta o mapeamento dos componentes lógicos da AS em processos e
threads em tempo de execução, resumidos na Tabela 4.3.
4.4.1
Módulo de Acesso e Comunicação (MAC)
O MAC possui um processo principal responsável por receber as requisições oriundas
dos mais variados tipos de clientes. Além disto, este processo é responsável por conter a interface
que sera implementada por cada adaptador.
68CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
Tabela 4.3: Resumo da quantidade de processos e threads em tempo de execução
Módulo
MAC
MGR
MGDD
MPD
Processos
1 por adaptador + 1 principal
1 por sub-módulo + 1 principal
4 processos principais
Threads
1 por requisição
1 por operação
1 por consumidor de dados +
1 por fornecedor de dados + 1
por canal de dado
1 principal + 1 DHT + 1 por 0
Banco de Dados
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 relação as
requisições, uma thread é criada para cada requisição, já que as requisições são gerenciadas de
forma independente.
4.4.2
Módulo de Gerenciamento de Recursos (MGR)
O MGR possui um processo principal que é responsável por conter todas as interfaces
das operações visíveis aos demais módulos. Além disto, cada cada sub-módulo é executado em
processo separado para que técnicas de cache possam ser futuramente desenvolvidas de forma
eficiente.
As operações que serão realizadas nos sub-módulos devem ser eficientes a ponto de
não comprometer a computação do recurso requisitante. Logo, para cada operação, uma thread
é iniciada para tratar está requisição. A sincronização das informações será feita utilizando
técnicas de sincronização por transação.
4.4.3
Módulo de Gerenciamento e Distribuição de Dados (MGDD)
O MGDD possui quatro processos principais: (i) o primeiro corresponde ao processo
responsável pela implementação dos canais de dados; na mesma linha, um processo é necessário
para controlar os (ii) consumidores e (iii) outro para os fornecedores; finalmente, (iv) o último
processo é responsável por gerenciar a DHT.
Como cada recurso, seja este consumidor ou fornecedor de dado, é independente dos
demais e contém as suas próprias dependências para realizar a computação, uma thread é criada
para cada recurso. Da mesma forma, uma thread é criada para cada canal de dado. Esta thread
pode ser executada em outro host.
69
4.5. VISÃO DE IMPLEMENTAÇÃO
4.4.4
Módulo de Persistência de Dados (MPD)
Por sua vez, o MPD constitui-se de dois processos: gerenciador de instâncias de banco
de dados e a DHT. Este gerenciador é responsável por obter os dados dos diferentes módulos e
armazenar no respectivo banco de dados para a predição de eventos futuros.
Da mesma forma que o MGDD, cada instância de banco de dados constitui uma novo
processo. Estes novos processos também podem ser executadas em um host diferente.
4.5
Visão de Implementação
Esta Seção descreve as estratégias utilizadas para a implementação de referência do
sistema de acordo com a AS estabelecida. Esta implementação está disponível em domínio
público1 .
A AS proposta visa atender alguns requisitos considerados como não funcionais, porém
não menos importante, como escalabilidade e flexibilidade. Logo, a infraestrutura a ser utilizada
para implementação deve ser robusta para atender os diversos sistemas que a utilizarão, além
da maciça quantidade de dados. Além disto, como a AS proposta contém vários componentes
independentes, a infraestrutura deve proporcionar o deploy de componentes/adaptadores sem que
os demais sejam afetados, conhecido como hot-deploy TOUSEAU; DONSEZ; RUDAMETKIN
(2008); MARTíN et al. (2009).
Neste contexto, a plataforma OSGi consolida-se como uma das mais indicadas para
aplicações na qual hot-deploy é de suma importância TOUSEAU; DONSEZ; RUDAMETKIN
(2008); MARTíN et al. (2009). Conforme definido por Gama:2010:SAA:1764810.1764818 :
A plataforma de serviço OSGi2 é um middleware universal para desenvolvimento de
aplicações modulares, usando princípios de SOA para implementar o desacoplamento entre
componentes. A tecnologia OSGi aproveita a modularização na plataforma Java, que permite
instalar, atualizar, para iniciar, parar e desinstalar componentes em tempo de execução sem a
necessidade de reinicialização do sistema. A plataforma OSGi é composta por um conjunto de
especificações, conduzido por um consórcio de empresas. As especificações são realizadas por
diferentes implementações como o Apache Felix3 , Equinox4 e Knopflerfish5 GAMA; DONSEZ
(2010).
No contexto deste trabalho, a plataforma OSGi foi utilizada para proporcionar maior modularidade, escalabilidade e facilitar a manutenção de componentes. Dentre as implementações
de OSGi, foi escolhida o Equinox, pela familiariade com o arcabouço Eclipse6 . Cada componente da AS foi implementada utilizando um bundle, que representa um conjunto de classes
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
6 https://www.eclipse.org/
70CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
Java, geralmente empacotados como “jar”. A Figura 4.7 ilustra a organização dos bundles que
representam a implementação dos respectivos componentes, do ponto de vista de implementação
sobre o Equinox.
file = images/implementation.pdf, width = 14cm
Figura 4.7: Visão de Implementação
Ao análisar a imagem 4.7, nota-se que o bundle responsável pela MAC contém um
adaptador com a implementação inicial de JSON7 utilizando a bibilioteca fornecida pelo Google
Inc. conhecida como GSON8 . Este bundle comunica-se ativamente com o bundle responsável
pela comunicação via REST. Por sua vez, o módulo REST implementa utilizando o framework
Restlet9 .
Em relação ao módulo MGR, percebe-se que ele se resume em dois bundles: Registro de
Recursos e Configuração de Recursos. Estes dois bunddles representam os processo descritos
previamente.
Já no módulo MGDD, a implementação do padrão publisher-subscriber foi realizada
utilizando o serviço oferecido pelo próprio OSGi Equinox denominado EventAdmin. O EventAdmin corresponde à um serviço que contém a implementação de canais de distribuição de dados,
na qual consumidores de dados podem se inscrever nos respectivos tópicos de interesse e os
fornecedores de dados podem fornecer os dados nestes canais. Na Figura 4.7 as caixas “C” e “P”
representam os consumidores e fornecedores de dados. Como pode ser observado, a DHT Canal
de Dados comunica-se ativamente com o EventAdmin para gerenciar os canais de dados.
Por fim, a ilustração correspondente ao módulo MPD exemplifica a utilização de um
banco de dados específico, conhecido como MongoDB10 . Similarmente à DHT Canal de Dados,
a DHT Banco de Dados utiliza as informações de cada bundle referente a um banco de dados
para gerenciá-lo e oferecê-lo aos demais componentes da AS. Caso um novo banco de dados
seja inserido, basta plugar o respectivo bundle sobre a plataforma OSGi Equinox e registrá-lo na
DHT de Banco de Dados.
4.6
Visão Física
Esta Seção visa descrever os requisitos físicos mínimos para utilização da AS proposta.
Por se tratar de um ambiente distribuído, com vários acessos exigindo o máximo de
escalabilidade, é de suma importância a utilização de um ambiente Cloud.
Para propósitos de testes e validações, foi utilizada uma infraestrutura mínima do serviço
Amazon AWS11 . A Tabela 4.4 resume as principais características de hardware e software dessa
7 http://www.json.org/
8 https://code.google.com/p/google-gson/
9 http://restlet.org/
10 http://www.mongodb.org/
11 http://aws.amazon.com/
71
4.7. VISÃO COMPONENTE CONECTOR
infraestrutura.
Tabela 4.4: Requisitos físicos de utilização da arquitetura
Requisito
Configuração
Hardware
Plano Amazon AWS
Memória RAM
Amazon EC2 - Free Tier
613Mb
Software
Amazon Machine Image (AMI) amzn-ami-pv-2012.09.0.x86_64-ebs
Sistema Operacional
Linux Amazon (Red Hat)
Restlet
Versão 2.4.1
GSON
Versão 2.2.4
MongoDB
Versão 2.4.6
Servidor Web
Jetty 7
Para a utilização em um ambiente real de produção é evidente que esta configuração não
é suficiente. Nesse contexto, deve-se analisar as soluções de Cloud oferecidas pelos provedores
para obter melhor desempenho da AS, como por exemplo, Amazon Dynamo DB12 e Amazon
Elastic Map Reduce13 .
4.7
Visão Componente Conector
Esta seção se refere ao comportamento dos componentes em tempo de execução e seus
conectores, que são responsáveis pela comunicação entre estes. A Figura 4.8 ilustra o diagrama
de componente conector desta proposta.
file = images/cc.eps, width = 10cm
Figura 4.8: Diagrama de Componente Conector
Como pode ser observado na Figura 4.8, os componentes principais são Recurso e Dado.
Apesar destes dois componentes fazerem parte logicamente do MGR, eles são utilizados pelos
demais módulos da AS. No próprio MGR, estes componentes são utilizados pelos módulos de
Configuração e Gerenciamento de Recurso. Os dados que trafegam na AS são representados
pelo componente Dado. Toda vez que um determinado recurso fornecer ou consumir um dado,
este deve usar o conector existente entre os componentes Recurso e Dado.
No caso do MAC, o componente Recurso é utilizado pois representa a entidade que
fornece e recebe dados da arquitetura. Esta comunicação é realizada a partir do outro componente
REST.
O MGDD contém uma porta para cada canal de dado. Esta porta é uma abstração para
a comunicação realizada com os diversos Recursos consumidores ou fornecedores de dados.
12 http://aws.amazon.com/dynamodb/
13 http://aws.amazon.com/elasticmapreduce/
72CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
Além disto, o MGDD contém um componente denominado DHT com as responsabilidades já
descritas na Seção Visão Lógica. Como pode ser observado, o MGDD possui um conector para
cada recurso associado à um canal.
Por sua vez, o MPDD possui conectores associados aos módulos MGR e MGDD para
que as informações trafegadas nestes dois módulos possam ser armazenadas para a predição de
eventos futuros. Além disto, uma porta é associada à cada instância de banco de dados.
4.8
Visão de Dependências
Esta seção visa ilustrar as dependências existentes entre os módulos da AS. A Figura 4.9
ilustra o diagrama de dependências entre os módulos desta proposta.
file = images/dependency.eps, width = 10cm
Figura 4.9: Diagrama de Dependências
Como pode ser observado na Figura 4.8, apesar do MGDD ser o core da AS, o módulo
que é mais utilizado pelos demais é o MGR. Este fato deve-se ao fato dos componentes Recurso
e Dado estar logicamente declarados no MGR. Logo, o MGDD depende do MGR para interagir
com os recursos inscritos em cada canal, além de gerenciar os respectivos dados.
Por sua vez, o MGR contém dependência apenas do MAC. Esta dependência deve-se
ao fato do MAC ser a porta de entrada e saída dos sistemas externos com a AS. Logo, para que
um recurso consiga receber de fato os dados é necessário utilizar os mecanismos providos pelo
MAC.
Assim como no diagrama de Componentes Conectados, o MPDD possui dependência
com os módulos MGR e MGDD para que as informações trafegadas nestes dois módulos possam
ser armazenadas para a predição de eventos futuros.
4.9
Cenários
Esta Seção visa apresentar alguns dos principais cenários de utilização da AS proposta.
4.9.1
Desenvolvimento de aplicações móveis
Um desenvolvedor pode criar aplicações móveis que consumam informações das cidades
e mantenham seus usuários atualizados sobre os acontecimentos. Por exemplo, uma aplicação
que identifique os pontos de alagamento em uma avenida ou registre regiões afetadas pela falta
de energia.
Do ponto de vista da arquitetura proposta, esta proposta deveria ser implementada da
seguinte forma. Um recurso, correspondendo à aplicação, deve realizar todas as interações com
a arquitetura através da interface REST, disponível do MAC. O primeiro passo é registrar à
73
4.9. CENÁRIOS
aplicação como um recurso no MGR. Para isto, a aplicação deve invocar o respectivo método
oferecido pelo MAC, provendo as devidas informações do recurso.
Em seguida, este recurso deve consultar a “DHT Canais de Dados” para obter as referências para todos os canais que oferecem as informações relevantes da respectiva cidade. Após se
inscrever nestes canais, assim que um novo dado é disponibilizado, a aplicação deve recebê-los a
partir de consultas REST. De posse destes dados, a aplicação pode exibi-los da maneira mais
adequada.
4.9.2
Emitir Alertas com Informações de Trânsito
As companhias de gerenciamento de trânsito das cidades podem utilizar esta arquitetura
para emitir informações de trânsito da cidade. Para isso, basta registrar cada sensor como um
recurso fornecedor de dado na arquitetura. Estes sensores podem ser as câmeras de trânsito,
informações de veículos em radares e quantidade de veículos nas cabines de pedágio por minuto.
Além disso, será necessário registrar um recurso consumidor no MGR responsável por se
inscrever nos canais nas quais estão informações serão fornecidades. A partir disto, este recurso
deve interpretar estas informações e gerar os alertas de acordo com a situação do trânsito.
4.9.3
Definição de Estratégia Efetiva de Investimento de Recursos
As secretarias das prefeituras podem definir estratégias para aplicação dos recursos
específicos para as reais demandas da cidade. Para isso, uma vez que os dados dos problemas da
cidade estejam trafegando pelos diferentes canais do MGDD, basta um recurso, representando o
sistema da secretaria se inscrever nestes canais.
A medida que um dado é disponibilizado, este recurso pode consolidar estas informações
em forma de gráfico ou até mesmo notificar os respectivos responsáveis, além de estimar o custo
para resolver aquele problema.
4.9.4
Predição de Catastrófes em Áreas de Riscos
Um sistema pode ser desenvolvido para predizer catastrófes em áreas de riscos. Para
isto, este sistema deve se registrar no MGR como um recurso consumidor de dados. Em seguida,
este recurso pode solicitar ao MPD informações anteriores associadas à área, por exemplo,
informações da quantidade de chuva nos últimos verões.
De posse destas diferentes informações, o recurso pode implementar uma lógica que
permite inferir conhecimentos a partir destas informações, por exemplo, usando uma técnica de
Rede Neural. Estas informações contextualizadas devem ser fornecidades em outro canal para
que outros recursos possam utilizá-las para alguma outra finalidade.
Em seguida, um recurso consumidor de dado deve se inscrever neste canal que está fornecendo essas informações contextualizadas e consolidá-las no sistema de predição de catastrófes.
74CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
4.10
Discussão do Capítulo
O conjunto de cenários descrito constitui exemplos de utilização da AS. Por ser uma
AS para propósito genérico, esta pode ser facilmente adaptada para os contextos locais de cada
região. Pode-se imaginar diversos cenários de utilização, desde uma região litorânea utilizar a
AS para executar programas de balneabilidade até o controle de obesidade dos idosos de uma
região.
Além desta flexibilidade em relação ao propósito da AS, pode-se facilmente identificar
que esta proposta é flexível em termos de aplicabilidade. Por exemplo, inicialmente concebida
para ser aplicada em uma cidade, esta AS pode ser implementada em diversas escalas, como um
prédio (Smart Build) e residências (Smart Home).
A partir desta flexibilidade, governos e instituições podem usar esta AS para criar várias
instâncias federativas, como por exemplo, uma instância para região de Sorocaba, outra para
Campinas e uma última para a região metropolitana de São Paulo. A partir dessa configuração,
essas 3 instâncias podem interagir para as estratégias de atuação.
Por fim, é necessário ressaltar que os requisitos de hardware discutidos foram suficientes
para testes em pequena escala, porém não serão suficientes no ambiente de produção real.
Esta fato se deve principalmente a fatores relacionados a concorrência, acessos simultâneos e
performance.
Logo, esse quesito prático não pode ser considerado suficiente para a avaliação da
proposta. Dessa forma, o Capítulo seguinte descreve um método para avaliação da AS proposta,
ressaltando os resultados obtidos ao aplicá-lo.
4.11
Considerações Finais do Capítulo
Este Capítulo iniciou-se apresentando o sub-conjunto de requisitos abordados nesta
proposta na Seção 4.1. Para guiar a descrição desta proposta, a Seção 4.2 apresentou o método
de descrição de AS’s utilizado, conhecido como “4+1”, que, quando combinado com duas outras
visões definidas pelo SEI, se mostrou ser bastante efetivo para o contexto deste trabalho.
Em seguida, a AS proposta foi apresentada, de acordo com as visões do método: Lógica
(Seção 4.3), Execução (Seção 4.4), Implementação (Seção 4.5), Física (Seção 4.6), Visão Componente Conector (Seção 4.7) e Visão de Dependências (Seção 4.8). A Visão Lógica apresentou,
a partir de um ponto de vista funcional, os principais módulos e as operações frequentemente
realizadas. Por sua vez, a visão de Execução mostrou o mapeamento dos componentes lógicos
em processos e threads. A Visão de Implementação apresentou a implementação de referência
que foi realizada e está disponível ém domínio público14 . A Visão Física relatou algumas
características de hardware utilizadas para está implementação de referência. Por fim, as duas
visões definidas pelo SEI foram descritas para facilitar a compreensão pelos stakeholders.
14 https://github.com/gustahrodrigues/Synaptic
75
4.11. CONSIDERAÇÕES FINAIS DO CAPÍTULO
Ao término das descrições das Visões, pode-se compreender as responsabilidades e a
comunicação entre os seis módulos da AS proposta. O módulo MCA corresponde ao ponto
de comunicação da AS com os sistemas externos. Já o MGR corresponde à manutenção dos
recursos na AS, principalmente ao cadastro e configuração dos mesmos. Por sua vez, o módulo
MGDD é responsável por difundir os dados de/para os recursos na AS. Finalmente, o módulo
MPD é responsável por armazenar todas as informações relevantes, em qualquer ponto da AS,
para consultas posteriores.
Esse conjunto de módulos compõe a proposta que visa agregar valores para os cidadãos
das cidades do Brasil. Alguns desses cenários foram discutidos neste Capítulo (Seção 4.9),
ressaltando principalmente o ponto de vista das entidades que podem propor estratégias em prol
do cidadão.
Finalmente, a Seção 4.10 abordou algumas características importantes da AS proposta.
A partir da descrição da AS reaizada neste Capítulo, o próximo Capítulo descreve um
método para avaliação, baseado em dois métodos: SAAM e ATAM.
77
5
Avaliação da Arquitetura de Software
Obstáculo é aquilo que você enxerga quando tira os olhos do seu objetivo.
—JUSTIN HERALD, 2006 ˙It’s All a Matter of Attitude
A disciplina de avaliação de Arquitetura de Software (AS) tem se mostrado uma importante ferramenta para quantificar a qualidade de um software a partir da sua descrição AS
KAZMAN et al. (1994). De fato, alguns experimentos industriais mostraram que a aplicação de
métodos de avaliação de AS gera ganhos consideráveis durante o desenvolvimento de software.
Em Maranzano2005 são relatados vários exemplos da utilização do processo de valiação de AS
em grandes empresas, como AT&T 1 e Lucent Technologies2 . Maranzano2005 demonstram que o
uso de tal abordagem nestas empresas gerou um ganho de cerca de 1 milhão de dólares em cada
projeto que teve seus problemas identificados e resolvidos previamente.
Sendo assim, podemos concluir que tão importante quanto definir a arquitetura de um
sistema de software é tentar realizar uma avaliação do que foi definido, com o objetivo de
identificar as falhas antes que se tornem grandes problemas no futuro. Logo, a partir da descrição
de módulos realizada no Capítulo anterior, este Capítulo visa avaliar a AS proposta.
Para tal, inicialmente, serão apresentados alguns métodos de avaliações de AS’s disponíveis na literatura (Seção 5.1). Ao analisar esses métodos, foi concluído que nenhum deles
atendia o contexto deste trabalho. Logo, a Seção 5.2 propõe uma adaptação de dois métodos de
avaliação de AS’s amplamente aceitos e validados na literatura ROY; GRAHAM (2008): SAAM
KAZMAN et al. (1994) e ATAM KAZMAN et al. (1999, 2000). Posteriormente, será discutido
o processo adotado durante a avaliação desta AS (Seção 5.3).
Em seguida, a Seção 5.4 discute alguns resultados e comentários a respeito das principais
questões que surgiram durante a avaliação desta AS. Além disso, a Seção 5.5 discute as principais
ameaças à avaliação realizada.
1 http://www.att.com/
2 http://www.lucent.com/
78
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
Por fim, a Seção 5.6 consolida as principais características do método proposto e dos
resultados obtidos a partir do processo de avaliação utizado.
5.1
Métodos de Avaliação
As arquiteturas de software visam estruturar os componentes de software da melhor
maneira para garantir a qualidade do produto final CLEMENTS (2003). Dessa forma, é de
suma importância que a avaliação da qualidade do software seja iniciada antes mesmo da
implementação, para que possíveis erros arquiteturais sejam identificados e corrigidos a fim de
minimizar custos.
Para realizar tal procedimento, um método de avaliação é utilizado para guiar os procedimentos de execução e auxiliar na interpretação dos resultados. Embora os métodos de avaliação
de AS possam variar quanto às técnicas que utilizam, pode-se dizer que, de uma maneira geral, os
métodos possuem um propósito em comum KAZMAN et al. (2005). Este propósito é: investigar
se uma determinada AS satisfaz os objetivos de negócio do sistema para o qual foi projetada.
Logo, a seguir é apresentada uma breve descrição de alguns métodos baseados em
cenários que serviram de base para a adaptação utilizada na avaliação da AS proposta.
5.1.1
Métodos Analisados
A literatura apresenta vários métodos de avaliação, com diferentes objetivos e contextos
de execução, como pode-se constatar nos relatos de roy2008methods, Shanmugapriya-2012;
bass-2012.
A partir dessas referências, um conjunto de métodos candidatos a ser utilizado foi
estabelecido. Para filtrar esse conjunto de métodos, a primeira condição a ser utilizada foi os
atributos de qualidade (QA) que o método visa avaliar. Como a AS proposta não possui uma
única finalidade, que possa ser avaliada por um único atributo de qualidade, optou-se por adotar
métodos que compreendem vários atributos de qualidade. A Tabela 5.1 apresenta os métodos
encontrados, nas referências relatadas anteriormente, que satisfazem esse pré-requisito.
Tabela 5.1: Métodos de Avaliação Vs Atributos de Qualidade
Método
SAAM
ATAM
SBAR
SACAM
DoSAM
Atributo de Qualidade
Modificabilidade e funcionalidade, mas pode ser adaptado para outros
Vários Atributos de Qualidade
Vários Atributos de Qualidade
Vários Atributos de Qualidade
Vários Atributos de Qualidade
Um outro fator que deve ser levado em consideração no momento de escolher qual
método de avaliação utilizar é o objetivo do método CLEMENTS (2003). Logo, a Tabela 5.2
apresenta o objetivo de cada método resultante do pré-requisito anterior.
79
5.1. MÉTODOS DE AVALIAÇÃO
Tabela 5.2: Métodos de Avaliação Vs Objetivo
Método
SAAM
ATAM
SBAR
SACAM
DoSAM
Objetivo
Adequação arquitetural e identificação de riscos
Foco em sensibilidade da arquitetura e análise trade-off
Avaliar arquiteturas legadas a partir de reengenharia, utilizando Domain
Specific Software Architecture, para criar uma base reutilizável e flexível
Comparação com outras arquiteturas de software descritas na literatura
Comparação com outras arquiteturas de software descritas na literatura
A partir destas duas pré-condições, nota-se que o método SBAR não pode ser utilizado
pois a AS proposta não é uma legada. Por sua vez, SACAM e DoSAM não devem ser utilizados,
pois não há nenhuma outra AS, disponível e amplamente aceita na literatura, que possa ser
comparada com a AS proposta, devido a falta de especificação e detalhamento arquitetural.
Por fim, restaram apenas dois métodos que satisfazem o contexto da AS proposta: (1)
SAAM KAZMAN et al. (1994) e (2) ATAM KAZMAN et al. (1999, 2000). A seguir uma breve
descrição de cada um desses métodos é apresentada.
5.1.2
Descrição dos métodos restantes
SAAM (Software Architecture Analysis Method) é um método de avaliação simples que pode ser adaptado à diferentes contextos. Inicialmente proposto para ser
utilizado para analisar modificabilidade e funcionalidade, o SAAM é amplamente
utilizado nos demais atributos de qualidade, tais como portabilidade, extensibilidade
e integrabilidade QUN-LI; JIE (2008).
O método SAAM inclui 6 atividades: (i) desenvolvimento dos cenários; (ii) descrição
da AS avaliada; (iii) classificação e priorização dos cenários; (iv) avaliação dos
cenários individual e indireta; (v) interação entre os cenários; (vi) avaliação global
dos cenários KAZMAN et al. (1994).
Algumas das principais vantagems do SAAM são a melhoria na documentação da
AS e a identificação de riscos KAZMAN et al. (1994).
ATAM (Architecture Tradeoff Analysis Method) é um método baseado em cenários,
porém, é mais complexo se comparado ao SAAM. A aplicação do ATAM revela quão
bem uma AS satisfaz os requisitos de qualidade desejados, além de identificar os
riscos arquiteturais e os conflitos (trade-offs) existentes para se alcançar tais requisitos
QUN-LI; JIE (2008).
O ATAM inclui 4 atividades principais: (i) Descrição: apresentação do ATAM, dos
objetivos de negócios e da AS; (ii) Investigação e Análise: geração dos atritos de
qualidade utilizando utility tree; análise das abordagens arquiteturais; brainstorm e
80
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
priorização dos cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentação dos
Resultados KAZMAN et al. (1999, 2000).
5.2
5.2.1
Adaptação dos métodos de avaliação
Definição do método de avaliação
Apesar dos dois métodos restantes serem os mais adequados para a AS proposta, o
contexto de aplicação do método não condizia com o contexto deste trabalho, devido as seguintes
peculiaridades:
A equipe de avaliação estava distribuída geograficamente, com rotinas e compromissos diferentes. Logo, a avaliação deveria ser totalmente remota;
Na equipe de avaliação, não há nenhum stakeholder com domínio em ambos os temas
de pesquisa que envolvem esta proposta (CI e IoT);
Não foi encontrada nenhum método de avaliação para o contexto de equipes distribuída geograficamente;
Como as reuniões seriam realizadas por Skype, as reuniões deveriam ser curtas para
manter a equipe concentrada.
Logo, surgiu a necessidade de propor uma adaptação dos dois métodos a fim de sanar
essas peculiaridades. Esta adaptação é baseada no SAAM e ATAM, porém as atividades são
específicas para o contexto remoto. Apesar disto, nenhuma nova etapa foi criada, pelo contrário,
as etapas recomendadas pelo SAAM e ATAM foram apenas combinadas e adaptadas para o
respectivo contexto. A Tabela 5.3 apresenta as 10 etapas do método adaptado.
Tabela 5.3: Etapas do método adaptado
1º
2º
3º
4º
5º
6º
7º
8º
9º
10º
Apresentação do Processo de avaliação
Apresentação dos Objetivos de Negócios
Apresentação da AS
Priorização dos QAs
Contextualização sobre cenários
Apresentação dos cenários
Priorização dos cenários
Avaliação dos cenários propostos
Avaliação das interações entre Cenários e QAs
Consolidação dos Resultados
81
5.2.2
5.2. ADAPTAÇÃO DOS MÉTODOS DE AVALIAÇÃO
Equipe de Avaliação
A primeira etapa para a definição do método de avaliação a ser utilizado foi a escolha
da equipe de avaliação. Devido ao fato de que CI pode ser considerado um sistema de sistemas
heterogêneos, as pessoas escolhidas para participar da equipe são de diferentes áreas de pesquisa,
com diferentes experiências e visões. Além disso, a heterogeneidade da equipe enriquece as
discussões, pois cada um avalia o mesmo quesito por diferentes pontos de vista, baseado nos
respectivos backgrounds CLEMENTS (2003).
Esta equipe foi composta por desenvolvedores e arquitetos provenientes do C.E.S.A.R,
professores do CIN-UFPE e da UFSCar Sorocaba. Ao total, 5 pessoas foram envolvidas no
processo de avaliação. A Tabela 5.4 ilustra as expertises dos envolvidos, na qual a coluna “#”
ilustra a quantidade dos envolvidos com a determinada expertise. Vale ressaltar que um mesmo
envolvido pode ter mais de uma expertise.
Tabela 5.4: Expertises da equipe de avaliação
Expertise
Doutores ou Doutorandos
Mestres ou Mestrandos
Engenheiros de Sistemas
Especialistas em Cloud Computing
Especialistas em IoT
Especialistas em Arquiteturas escaláveis
Especialistas em Arquiteturas de propósito geral
Especialistas em Negócios
5.2.3
#
3
2
4
1
2
2
2
2
Descrição do Método de Avaliação
Inicialmente o processo de avaliação deve ser descrito, ressaltando principalmente quais
os artefatos esperados de cada etapa. Em seguida, como recomenda o SAAM, um participante
da equipe de avaliação com a visão de negócio deve apresentar as expectativas de uma AS para
CI que combine IoT. Esta etapa é de suma importância, pois estas expectativas serão utilizadas
para quantificar o quão a AS proposta atende aos objetivos estabelecidos.
A próxima etapa consiste na apresentação da AS propriamente dita. Nesta etapa, o
arquiteto pode utilizar o método de descrição arquitetural que lhe interesse. Entretanto, este
método deve fornecer subsídios suficientes para o completo entendimento da AS por parte dos
demais participantes, incluindo interações entre os módulos, regras de negócios e o ciclo de vida
dos componentes KRUCHTEN (1995).
Em seguida, deve-se realizar a etapa de priorização dos atributos de qualidade com base
nos objetivos de negócios, previamente discutidos. Para tal, recomenda-se que o arquiteto sugira
um conjunto de atributos de qualidade pré-selecionados que possam ser empregados. A literatura
82
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
apresenta alguns métodos de priorização dos atributos de qualidade, porém o mais usual é
estabelecer que cada participante possui 3 votos que deve ser distribuído dentre os atributos de
qualidade. Após todos os participantes votarem, os atributos de qualidade que receberem mais
votos devem ser considerados mais prioritários.
A contexualização sobre o que são cenários para toda a equipe de avaliação deve ser
realizada a seguir. Um cenário, neste contexto, ilustra os tipos de atividades que um sistema
deve suportar. Um exemplo de cenário pode ser: “Qual o impacto na arquitetura caso ocorra
uma mudança no modelo de troca de mensagens entre os componentes”. Vale ressaltar que
o desenvolvimento desses cenários é crucial para capturar os principais usos do sistema, seus
usuários, antecipar mudanças no sistema, e qualidades que o sistema deve satisfazer agora e no
futuro. Estes cenários devem ser elicitados por todos os stakeholders do sistema a partir dos
objetivos de negócios, logo, representam questões sob diferentes pontos de vista e, na maioria
das vezes, trazem informações bem específicas do sistema avaliado.
Antes da próxima etapa deste processo de avaliação é importante criar algum mecanismo
para que os participantes possam propor os possíveis cenários. Uma técnica que pode ser
utilizada é o compartilhamento de uma planilha online entre cada participante e o arquiteto.
Após todos os membros da equipe de avaliação escrevem os possíveis cenários, o
arquiteto deve consolidar os cenários propostos. Esta consolidação resume-se em filtrar os
cenários duplicados e reescrever alguns com outras palavras para facilitar a compreensão.
No início da próxima etapa, todos os cenários propostos pelos participantes devem ser
apresentados, para que os demais participantes conheçam os diferentes pontos de vista. Em
seguida, todos devem priorizar os cenários de acordo com a relevância para a AS proposta. Esta
priorização pode ser feita da mesma forma que a priorização dos QAs.
Para a próxima etapa, de avaliação dos cenários propostos, também é interessante criar
um mecanismo para que seja realizada remotamente. Um exemplo é a criação de um formulário
online na qual cada participante deve dar uma nota para o quão cada cenário está contemplado
pela AS.
Feito isso, na etapa seguinte o arquiteto deve conduzir uma discussão a respeito das
interferências dos atributos de qualidades nos cenários priorizados, como descrito pelo ATAM.
Geralmente estas discussões geram conclusões de que, para atender a um cenário específico, mas
muito relevante, deve-se deixar de implementar totalmente um atributo de qualidade.
Por fim, o arquiteto deve apresentar os resultados finais do processo de avaliação. Nesta
etapa é importante apresentar todos os artefatos gerados em cada etapa do processo de avaliação.
Além disso, devem ser apresentados os pontos positivos e os pontos de melhoria que, a partir do
processo executado, foram identificados.
83
5.3
5.3. PROCESSO DE AVALIAÇÃO EXECUTADO
Processo de Avaliação Executado
A partir da descrição do processo de avaliação na Seção anterior, o processo foi executado
remotamente via Skype e as etapas foram divididas em 3 reuniões:
5.3.1
Primeira Reunião
O objetivo da primeira reunião foi apresentar os objetivos de negócios da AS proposta e
contextualizar todos os envolvidos no processo de avaliação em relação à temática de CI.
As etapas da reunião foram as seguintes:
a) Apresentação do Processo de Avaliação (Duração 30min): Inicialmente, foi descrito a origem da adaptação dos métodos, ressaltando as principais diferenças com
os métodos disponíveis na literatura. Consequentemente, o processo de avaliação a
ser utilizado foi descrito. O objetivo desta etapa foi situar todos os envolvidos em
relação ao objetivo do processo e aos próximos passos;
b) Objetivos de Negócios (Duração 30min): A segunda etapa da reunião teve a intenção de definir e apresentar os objetivos de negócios da AS proposta. Este passo
foi importante para que os participantes da avaliação entendessem o contexto do
sistema e também as limitações técnicas, econômicas e de cronograma existentes
para a execução do projeto. Todos esses aspectos foram apresentados para ajudar na
definição dos atributos de qualidade a serem considerados no processo de avaliação;
c) Apresentação da AS (Duração 1hora): Neste passo, a AS proposta foi detalhada
pelo arquiteto através de uma visão de módulos. Para tal, foi utilizado o framework
de descrição AS conhecido como “4+1” KRUCHTEN (1995). Cada módulo foi
detalhado, ressaltando, principalmente, o requisito arquitetural que este visa atender.
Além da visão de módulos, foi apresentada a comunicação entre os módulos. Esta
apresentação foi de suma importância para os participantes perceberem como os
requisitos foram implementados para avaliar se de fato eles satisfazem as necessidades
dos contextos de CI. Além disso, por meio desta descrição detalhada é possível
identificar possíveis falhas e/ou pontos de melhoria na AS proposta;
d) Priorização dos Atributos de Qualidade (Duração 1hora): Como alguns participantes não estavam acostumados ao conceito de Atributos de Qualidade, inicialmente
foi descrito o que são e quais os objetivos dos mesmos. Em seguida, o arquiteto
apresentou os atributos de qualidade definidos pela ISO/IEC 9126 ISO/IEC (2001) e
pelo CMU/SEI-95-TR-021 BARBACCI et al. (1995), com o objetivo de exemplificar
possíveis atributos de qualidade aplicáveis à AS proposta.
84
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
Ao término dessa etapa, os participantes sugeriram alguns atributos de qualidade,
com base nos objetivos de negócios. Em seguida, foi realizado uma votação para
priorizar quais os atributos melhor expressam os objetivos de negócios, apresentados
anteriormente. Nesta votação, cada participante poderia distribuir 3 votos entre os
atributos de qualidade. Cada voto foi computado individualmente a partir de um
formulário online disponibilizado para cada envolvido. A Tabela 5.5 exibe o resultado
desta votação. A coluna “fonte”, refere-se à origem do atributo de qualidade, na qual
“participante” são os atributos propostos pelos participantes da avaliação.
Tabela 5.5: Priorização dos Atributos de Qualidade
#
1º
2º
3º
4º
5º
6º
7º
8º
9º
10º
11º
QA
Confiabilidade
Funcionalidade
Escalabilidade
Portabilidade
Disponibilidade
Segurança
Performance
Eficiência
Usabilidade
Acoplamento
Manutenabilidade
Fonte
ISO/IEC 9126 e CMU/SEI-95-TR-021
ISO/IEC 9126
Participantes
ISO/IEC 9126
Participantes
CMU/SEI-95-TR-021
CMU/SEI-95-TR-021
ISO/IEC 9126
ISO/IEC 9126
CMU/SEI-95-TR-021
ISO/IEC 9126
Votos
4
3
2
1
1
1
1
1
1
0
0
As definições consideradas para os atributos foram:
Confiabilidade: visa avaliar se a arquitetura estará disponível quando
necessário;
Funcionalidade: conjunto de atributos que evidenciam a existência de
um conjunto de funções e suas propriedades especificadas. As funções são
as que satisfazem as necessidades explícitas ou implícitas;
Escalabilidade: capacidade que um sistema possui de se expandir, de
forma a permitir o atendimento das necessidades pelo crescimento do
número de usuários do sistema, ou também pelo aumento das informações
a serem processadas;
Portabilidade: capacidade do sistema ser transferido de um ambiente
para outro;
Disponibilidade: refere-se ao conjunto de atributos que interferem na
probabilidade de que um sistema esteja funcionando e pronto para uso em
um dado instante de tempo;
85
5.3. PROCESSO DE AVALIAÇÃO EXECUTADO
Segurança: refere-se ao conjunto de propriedades da arquitetura que
interferem diretamente na garantia da integridade dos dados da aplicação
e no acesso aos mesmos;
Performance: visa quantificar se a arquitetura computará os dados em
tempo hábil, coerente com o contexto da requisição;
Eficiência: conjunto de atributos que interferem diretamente nos tempos
de resposta de um sistema;
Usabilidade: conjunto de atributos que evidenciam o esforço necessário
para se poder utilizar o software, bem como o julgamento individual desse
uso, por um conjunto explícito ou implícito de usuários;
Acoplamento: refere-se ao grau de dependência entre os componentes de
software;
Manutenabilidade: atributos do software que evidenciam o esforço necessário para modificá-lo, remover seus defeitos ou adaptá-lo a mudanças.
e) Contextualização sobre Cenários (Duração 20min): O último passo dessa primeira
reunião, foi a contextualização sobre cenários. Da mesma forma como os atributos de
qualidade, inicialmente foi realizada uma breve apresentação sobre o que são e quais
as necessidades dos cenários. Em seguida, alguns cenários foram exemplificados,
como “Disponibilizar um novo tipo de dado” e “Combinar informações de duas ou
mais fontes de dados”.
Por fim, uma planilha foi compartilhada com cada participante para que eles pudessem
detalhar os cenários de utilização da AS com base nos objetivos de negócios. Para
isso, um prazo de 4 dias foi estipulado para que todos os participantes descrevessem
os possíveis cenários.
5.3.2
Segunda Reunião
A Segunda Reunião foi marcada uma semana depois da primeira reunião, para mitigar o
risco dos participantes esquecerem algum tópico abordado.
Após os 4 dias estipulados para que todos os participantes descrevessem os cenários, o
arquiteto consolidou todos os cenários. Esta consolidação resumiu-se em, basicamente, filtrar
os cenários duplicados e reescrever alguns com outras palavras para facilitar a compreensão
dos demais participantes. Apenas 2 cenários foram considerados duplicados e 1 precisou ser
reescrito.
a) Apresentação dos Cenários (Duração 30min): Nessa primeira etapa da segunda
reunião, foram apresentados todos os cenários propostos pelos participantes da
avaliação no prazo estipulado. Como vários participantes possuem diferentes visões e
86
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
experiências, foram identificados diferentes nichos de aplicabilidade da AS proposta,
por exemplo, em contextos totalmente distribuídos ou, até mesmo, em contextos
federados.
b) Priorização dos Cenários (Duração 1hora): A segunda etapa foi uma discussão
conduzida pelo arquiteto na qual o objetivo era a priorização dos cenários. Essa
discussão foi guiada pelo arquiteto, na qual cada cenário foi discutido e um peso de
relevância foi atribuído para cada cenario. Essa priorização levou em consideração
os cenários mais aplicáveis, coerentes e factíveis na AS proposta.
c) Avaliação dos Cenários propostos (Duração 1hora): Em seguida, os cenários priorizados foram avaliados e discutidos sobre a AS proposta. O principal objetivo foi
avaliar o quão os cenários levantados condizem com a natureza da AS proposta.
Ao término desta reunião, os cenários resultantes são exibidos na Tabela 5.6, ordenados
de acordo com a priorização.
5.3.3
Terceira Reunião
Da mesma forma que a Segunda Reunião, a Terceira e última reunião foi marcada uma
semana depois. O objetivo primordial dessa reunião foi consolidar os resultados e definir as
possíveis ações a serem tomadas para aprimorar a proposta.
Para tal, foi criado um formulário online com todos os cenários, ordenados por ordem
de priorização. O objetivo deste formulário foi de mensurar quantitativamente o quão a AS
contempla cada cenário.
a) Avaliação das interações entre Cenários e Atributos de Qualidade (Duração
1hora): Nesta primeira etapa da reunião, os participantes discutiram o quão os
cenários priorizados conflitavam com os atributos de qualidade.
b) Consolidação dos Resultados (Duração 1hora): Nesta etapa os resultados foram
apresentados. Primeiramente, um overview sobre cada artefato gerado durante o
processo foi apresentado, principalmente a priorização dos atributos de qualidade e
os cenários. A próxima Seção detalhará esses resultados.
A Seção a seguir resume os resultados obtidos com o processo de avaliação de AS
realizado.
5.4
Resultados da Avaliação da Arquitetura
Um dos benefícios de se realizar qualquer avaliação de Arquitetura de Software (AS) é a
melhoria de comunicação entre os stakeholders, resultando em um melhor entendimento dos
requisitos.
87
5.4. RESULTADOS DA AVALIAÇÃO DA ARQUITETURA
Tabela 5.6: Cenários resultantes de acordo com a relevância
ID
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
Cenário
Armazenar dados fornecidos por diferentes contextos e provedores,
independente do formato e da natureza do dado
Consultar dados oriundos de um provedor de dado, independente de
quando esse dado foi gerado
Permitir que novos tipos de informações sejam fornecidas, a partir da
combinação de uma ou mais fontes de dados
Permitir a inclusão de novos provedores de dados
A AS deve auxiliar a interoperabilidade entre sistemas, na qual um
evento gerado externamente pode disparar ações
A AS deve auxiliar a fusão de dados, na qual um evento produzido
internamente com base na análise de dados/histórico pode gerar ações
externas
A AS deve permitir a comunicação via API
A AS deve permitir a recuperação de grandes massas de dados
históricas de diversas fontes, a fim de obter previsões que dizem respeito
à prestação de serviços urbanos
Fornecer algum mecanismo para tolerância a falhas (redundância)
Permitir a criação e comunicação de instâncias federativas, baseada em
serviços
Possuir mecanismo para a inclusão de novos protocolos de comunicação
na AS
Plugar novas soluções para diferentes contextos utilizando a mesma
infraestrutura
Suporte a serviços em Cloud Computing já existentes (Ex.: Google
Analytics e cloud storage)
Gerenciar os dados do usuário de acordo com as políticas de privacidade
governamentais
Logo, conforme descrito na Seção anterior, para mensurar quantitativamente o quão a
AS contempla cada cenário, foi criado um formulário online com todos os cenários, ordenados
por ordem de priorização. Neste formulário, cada participante deveria atribuir uma nota para
a adequação de cada cenário, na qual 5 representa que a AS ATENDE TOTALMENTE e 0
significa que NÃO ATENDE ao cenário em questão.
A partir deste formulário, foram obtidas algumas conclusões, que serão exemplificadas
nas posteriores subseções.
5.4.1
Resultados da Avaliação dos Cenários
Cada participante respondeu o formulário online independentemente. A partir disso, o
arquiteto consolidou todas as respostas anonimamente. A figura 5.1 ilustra a média e o desvio
padrão das respostas, além de 3 faixas de satisfatoriedade, definidas pelos próprios participantes
da avaliação.
88
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
file = images/cenarios.eps, width = 10cm
Figura 5.1: Resultado da avaliação dos cenários
Para analisar os resultados na Figura 5.1, deve ser considerada a relevância dos cenários
propostos, priorizados durante o processo de avaliação.
Como é possível notar, na opinião dos participantes, a AS atende à três cenários de
maneira EXCELENTE. O primeiro cenário (C2) é relacionado aos mecanismos de distribuição
de dados implementados no MGDD (Seção 4.3.3), principalmente a utilização da DHT de dados.
Conforme discutido, a utilização da DHT permitiu que os recursos fornecedores e consumidores
e os canais de dados estejam distribuídos em uma infraestrutura de cloud.
Já o segundo cenário categorizado como EXCELENTE (C4) foi obtido a partir da implementação do padrão publisher-subscriber também no MGDD. Esta implementação permite que
um dado seja disponibilizado para todos os recursos consumidores assim que é produzido. No
contexto de CI, esta característica básica é de suma importância se todos os consumidores receberam os dados simultâneamente e está contemplada nesta proposta. Além disso, o desacoplamento
entre fornecedores e consumidores de dados oriundos a partir do padrão publisher-subscriber
também é de suma importância para futuras expansões da AS.
O último cenário avaliado positivamente (C7) é oriundo do modelo de abstração e da
flexibilidade implementada no MAC (Seção 4.3.1). Esta abstração permite que novos protocolos
de troca de mensagens sejam inseridos sob demanda. Já a flexibilidade está relacionada à
capacidade de trocar a interface REST ou, até mesmo, incluir outro padrão em paralelo.
A maioria dos cenários foram considerados SATISFATÓRIOS pelos participantes da
avaliação. Embora este resultado indique que a AS, em uma primeira instância, atende a um
conjunto de contextos de utilização, ela deve ser aprimorada para atender de maneira segura e
eficiente aos demais contextos.
Além disso, dois cenários foram classificados como PÉSSIMO. O primeiro (C9) está
relacionado à inserção de algum mecanismo de tolerância a falhas. Não foi encontrado nenhum
mecanismo semelhante nas abordagens encontradas na literatura. Porém, no contexto de uma CI
é inadmissível que todo o sistema da cidade deixe de funcionar devido à um problema em algum
módulo ou componente de software. A literatura apresenta diversas técnicas de redundância,
tanto de dados como de componentes de software, que devem ser inseridas na proposta. Além
disso, estratégias de backup, controle de acesso e demais aspectos relacionados à confiabilidade
da proposta devem ser investigadas.
O outro cenário que foi classificado como PÉSSIMO (C14) corresponde às políticas
de privacidade de dados utilizadas pela AS. Conforme pôde ser verificado, este requisito não
faz parte desta AS. Além disso, esta necessidade foi identificada no começo desta pesquisa,
porém um outro trabalho de mestrado está sendo desenvolvido com este escopo. Este trabalho
de privacidade será acoplado à esta proposta assim que finalizado. Para isso, as definições de
interfaces e padrões de mensagens estão sendo definidas em conjunto. O escopo deste trabalho
89
5.5. AMEAÇAS À AVALIAÇÃO
de privacidade é criar um mecanismo em que, a partir das interações anteriores, os cidadãos
possam “negociar” o quão seus dados estarão disponíveis para um determinado provedor de
serviço urbano.
5.4.2
Resultados Gerais
Esta sub-seção visa elencar os resultados gerais obtidos a partir do processo de avaliação
executado. Estes resultados foram extraídos a partir das discussões com os participantes e não
necessariamente são observados nos artefatos do processo.
Primeiramente, o fato de dois de três cenários categorizados como EXCELENTE estarem
diretamente relacionado ao MGDD era esperado. O MGDD pode ser considerado o core da
proposta, principalmente devido ao módulo de distribuição de dados utilizado. Este modelo,
utilizando o padrão publisher-subscriber foi encontrado em outros contextos e adaptado para
esta proposta. Além disso, a alta quantidade de requisitos que o MGDD visa satisfazer representa
os principais diferenciais desta proposta com as demais.
Este fato alerta para possíveis problemas relacionados ao acoplamento do MGDD com
o restante da AS. Por exemplo, deve-se prever e criar mecanismos para mitigar os possíveis
problemas no MGDD relacionados à indisponibilidade da DHT Canais de Dados. Caso isso
aconteça, os demais módulos devem continuar funcionando corretamente a partir de mecanismos
de redundância.
Além disso, de acordo com os participantes, não é necessário descrever um novo padrão
arquitetural para o contexto de CI e IoT. Esta conclusão foi obtida a partir da avaliação de que a
proposta atual contempla alguns padrões arquiteturais e já atende diversos cenários de utilização.
De maneira geral, estes resultados mostram que a AS pode e deve ser utilizada em um
contexto real, para, de fato, verificar a adequação da AS ao contexto de CI e IoT. Logo, como
trabalho futuro, a proposta atual será implantada em um ambiente real por meio de parcerias
com orgãos interessados.
5.5
Ameaças à Avaliação
Na avaliação da arquitetura descrita previamente, algumas ameaças foram identificadas.
Estas ameaças não afetam diretamente o resultado final desta avaliação, porém devem ser
analisadas para trabalhos futuros.
A primeira ameaça está relacionada à quantidade de pessoas envolvidas no processo
de avaliação. Por mais que a equipe tenha várias expertises diferentes englobando várias áreas
de uma cidade, como recomendado por clements2003documenting, se mais pessoas tivessem
participado da avaliação outros pontos de vistas poderiam ser levantados. Infelizmente, este
pequeno número de participantes foi devido à disponibilidade do grupo de pesquisa para a
realização das três reuniões mencionadas.
90
CAPÍTULO 5. AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
A outra ameaça está relacionada com a ordem das etapas do método de avaliação.
Como apresentação da arquitetura foi realizada antes da definição e priorização dos atributos
de qualidade e dos cenários, a opinião dos participantes pode ter sido enviesada. Apesar disto,
no inicio das etapas de definição e priorização dos atributos de qualidade e dos cenários foi
ressaltado que as opiniões deveriam ser a partir da apresentação dos objetivos de negócios. Logo,
uma melhoria no método de avaliação é alterar a ordem destas etapas.
5.6
Considerações Finais do Capítulo
Este Capítulo iniciou-se apresentando os filtros aplicados nos métodos de avaliação
disponíveis na literatura Seção 5.1. Estes filtros foram aplicados de acordo com o contexto da
avaliação a ser executada.
Após estes filtros, os métodos SAAM e ATAM foram considerados os mais indicados.
Porém, a versão original destes métodos não condiz com o contexto desta avaliação. Logo, a
Seção 5.2 propôs uma adaptação destes dois métodos de avaliação de AS’s amplamente aceitos e
validados na literatura.
Finalmente, a Seção 5.3 apresentou todas as etapas do processo de avaliação executado.
Por fim, a Seção 5.4 discutiu os principais resultados da avaliação.
A partir da avaliação realizada, pode-se mensurar o quão a AS está apta para ser implantada em um contexto real. Dessa forma, o próximo Capítulo finaliza o trabalho descrevendo
as principais conclusões e as atividades futuras, como implantar a AS em um ambiente real e
controlado.
91
6
Conclusão
Feliz aquele que transfere o que sabe e aprende o que ensina.
—CORA CORALINA, 2007 (Vintém de cobre: meias confissões de Aninha.
9. ed . São Paulo: Global.)
Uma vez que a AS para Cidade Inteligente (CI) foi especificada e projetada, algumas
conclusões e direções para trabalhos futuros podem ser apontadas.
Desta forma, este Capítulo apresenta as conclusões finais deste trabalho e está organizado
da seguinte maneira: a Seção 6.1 apresenta um resumo das principais conclusões deste trabalho.
A Seção 6.2 relata alguns trabalhos relacionados. A Seção 6.3 aponta um conjunto de trabalhos
futuros, e finalmente, a Seção 6.4 contém a conclusão final da dissertação.
6.1
Principais Conclusões
Esta Seção resume as principais conclusões deste trabalho, enumeradas abaixo:
O crescimento populacional desenfreado, combinado com outras questões de má
governança, tem potencializado os problemas urbanos. Estes problemas estão relacionados aos diversos serviços de uma cidade, como saúde, transporte e lazer.
Consequentemente, estes problemas afetam diretamente o dia-a-dia dos cidadãos e
dificultam o gerenciamento das cidades pelos gestores (Seção 1.1).
Apesar da evidente necessidade de cidades cada vez mais inteligentes, ainda não
há um consenso sobre a definição mais adequada para o termo CI. Mesmo assim,
várias abordagens estão sendo desenvolvidas com o paradigma de utilizar IoT como
ferramenta para a implementação, de fato, de uma CI. Neste contexto, as tecnologias
IoT são utilizadas, principalmente, para monitorar, controlar e atuar sobre os diversos
serviços urbanos (Capítulo 2).
92
CAPÍTULO 6. CONCLUSÃO
6.2
Na literatura, várias abordagens estão sendo desenvolvidas com este paradigma.
Porém, a maioria destas abordagens focam em apenas um conjunto muito restrito de
serviços urbanos e não consideram a integração entre estes serviços (Capítulo 3).
A AS proposta por esta dissertação permite que os dados entre os diferentes serviços urbanos sejam difundidos para todos os recursos interessados. Para tal, a AS
implementa um padrão arquitetural bastante conhecido na literatura chamado de
publisher-subscriber (Capítulo 4).
Para avaliar a AS proposta, dois métodos de avaliação arquitetural foram adaptados
para o contexto deste trabalho. Esta adaptação mostrou-se bastante útil, uma vez que
os principais benefícios citados na teoria, tais como composição de dados urbanos,
foram confirmados (Seção 5.4).
Trabalhos Relacionados
Em livingPlanIT foi adotada uma estratégia de implementar um Sistema Operacional
Urbano (UOS). Este sistema operacional consiste em uma plataforma que visa integrar cada
domínio que compõe a cidade. O sistema é alimentado por uma vasta rede de sensores e todos
esses dados são capturados por tempo indeterminado, para auxiliar na tomada e na predição de
decisões. Além de prever catástrofes, caso ocorra, o sistema pode antever todos os possíveis
impactos na cidade. As principais diferenças da abordagem de livingPlanIT e esta proposta são a
parceria com setor privado (livingPlanIT possui uma parceria com Cisco e Microsoft) e o modelo
de distribuição de dados, uma vez que no modelo adotado em livingPlanIT a disponibilização de
um novo tipo de dado é custosa, do ponto de vista arquitetural.
Outra abordagem em que se utilizam vários sensores embarcados nos contextos urbanos
é SmartSantander SANCHEZ et al. (2011). A quantidade de dispositivos configurados na
AS é superior à 12.000. O SmartSantander provê: i) um modelo de refência de arquitetura
para sistemas IoT do mundo real; ii) um escalável, heterogêneo e confiável facilitador de
experimentos; iii) um conjunto representativo de casos de uso implementados para facilidades de
experimentação e iv) um grande conjunto de experimentos e resultados sobre o futuro da internet.
A principal diferença da abordagem descrita por SmartSantander-2011 com esta proposta, além
da parceria com o setor privado, são os mecanismos que permitem a composição de dados
urbanos. Na proposta deste trabalho, assim que um dado novo é disponilizado, permite-se a
criação de um novo canal para este dado. Além disto, esta proposta contempla mecanismos de
gereção de histórico, que é fundamental para a tomada de decisões futuras.
Por sua vez, em Filipponi-2010 a integração de sensores é abordada a partir de uma
AS baseada em eventos, na qual cada evento corresponde à mudança de estado de qualquer
sistema de TIC. Estes eventos podem ser iniciados a partir de eventos do mundo real (como
detecção de presença) ou ao término de algum processamento. A abordagem de Filipponi-2010 é
93
6.2. TRABALHOS RELACIONADOS
bastante similar com esta proposta no quesito de modelagem do ambiente real. Porém, a principal
diferença é a existência nesta proposta de um mecanismo para geração de histórico para a previsão
de futuros eventos. Além disto, as informações de cada sensor que está fornecendo os dados pode
ser utilizada para otimizar o desempenho dos algoritmos SHAO (2011); HERNáNDEZ-MUñOZ
et al. (2011); VEGA-BARBAS et al. (2012).
Neste sentido, em Hernandez-2011 é proposta uma AS (USN), com o objetivo de prover
uma infraestrutura que seja capaz de integrar sensores heterogêneos e dispersos geograficamente
em um base centralizadora, na qual serviços podem ser facilmente desenvolvidos. Esta abordagem de Hernandez-2011 é similar a esta proposta nas técnicas adotadas para permitir a integração
de sensores heterogêneos. A principal diferença é que nesta proposta novos protocolos de troca
de mensagens podem ser facilmente inseridos. Além disto, o custo para integrar diferentes
fornecedores de dados nesta proposta é muito baixo para otimizar o desempenho em larga escala.
Finalmente, em Components-2009 é proposta uma AS baseada em quatro princípios:
aplicações, negócios, gerenciamento de processos e infraestrutura de redes. O primeiro princípio
corresponde às aplicações que fazem uso de diferentes tecnologias para monitorar sensores,
como GPS. A maioria dessas aplicações atendem as demandas operacionais das cidades, porém,
ao utilizar as regras definidas no segundo princípio - negócios - elas podem agregar soluções
economicamente viáveis. O terceiro princípio é o gerenciamento de processos no qual relacionamentos, regras, estratégias e políticas entre as aplicações e as unidades de negócios são definidos.
O último princípio corresponde a toda a infraestrutura de rede, responsável por conectar os
outros três princípios. A principal diferença da abordagem de Components-2009 para esta
proposta é a criação de um componente específico para modelos de negócio. Este diferencial
pode ser facilmente incorporado nesta proposta, uma vez que este componente poderia ser um
consumidor de dado que, a partir dos dados que estão trafegando na arquitetura, inferir um
modelo de negócios eficaz com estas informações.
Ao analisar os principais trabalhos relacionados, pôde-se observar que todos visam mitigar apenas uma deficiência tecnológica relacionada à CI. Apenas a abordagem de livingPlanIT
visa integrar as informações provenientes de diferentes domínios de uma cidade, o que pode
contribuir para tornar uma cidade de fato inteligente.
Além disto, o conjunto de requisitos que esta proposta contempla é superior à todos os
trabalhos relacionados. Apesart deste conjunto de requisitos ter sido definido juntamente com
esta proposta, este refleta uma série de características que qualquer Arquitetura de Software (AS)
para Cidade Inteligente (CI) deveria atender.
Os resultados desta dissertação estão baseados em um trabalho de pesquisa que analisou
o estado da arte e da prática no tocante as AS’s de software para CI que combinam tecnologias
IoT. Estes resultados envolvem, entre outras coisas: (i) um levantamento das soluções existentes,
(ii) a extração de um conjunto de requisitos que uma AS para CI deve atender, (iii) o projeto da
AS, (iv) a avaliação preliminar da AS e (v) uma implementação de referência.
94
6.3
CAPÍTULO 6. CONCLUSÃO
Trabalhos Futuros
A versão inicial desta AS não contempla algumas características, principalmente as
questões relatadas na Seção 1.4, e os resultados da avaliação da AS:
6.4
Utilização em Ambiente Real: A proposta atual será implantada em um ambiente
real a partir de parcerias com empresas e prefeituras. Certamente essa etapa vai
contribuir com a proposta e avaliar, de fato, à adequação ao contexto deste trabalho.
Mecanismo de tolerância à falhas: Estratégias de redundância devem ser implementadas para que os serviços urbanos não sejam afetados devido a uma eventual
falha em algum ponto da AS;
Políticas de privacidade: Já que vários dados pessoais dos cidadãos trafegarão pela
AS, torna-se indispensável a adequação de políticas de privacidade, principalmente
relacionadas ao armazenamento, utilização e descarte dos dados;
Modelo de Negócio: Modelos de negócios devem ser discutidos para suprir os custos
envolvendo a implementação, manutenção e expansão desta AS no ambiente real.
Uma estratégia que deve ser discutida é a parceria com governos e empresas para a
utilização desta AS;
Análises de big data: Com o alto volume de dados potencialmente gerado a partir da
utilização desta AS, análises de big data devem ser feitas para otimizar o desempenho
dos serviços urbanos;
Semântica dos Dados: Futuras pesquisas podem investigar a melhor estratégia de
semântica dos dados a ser implementada nesta proposta.
Conclusão
A necessidade de cidades cada vez mais inteligentes é notoriamente crescente. Vários
dados publicados pela mídia em geral comprova que o crescimento populacional não está alinhado
com o desenvolvimento das infraestruturas e dos principais serviços urbanos. A precariedade
destes serviços urbanos afeta negativamente a qualidade de vida dos cidadãos.
Logo, torna-se fundamental o investimento em estratégias que visam mitigar estes
problemas urbanos para otimizar a vida dos cidadãos. Estas iniciativas devem ser desenvolvidas
considerando as partes envolvidas: governo e cidadãos. Além disso, torna-se importante que os
cidadãos estejam conscientes do seu papel em prol de uma cidade melhor para todos.
Neste sentido, esta dissertação apresentou a especificação e o projeto de uma AS para
CI que permite a integração de tecnologias IoT para mitigar estes problemas urbanos. Esta
95
6.4. CONCLUSÃO
AS foi proposta a partir de um conjunto de requisitos mais importante extraído das principais
abordagens disponíveis na literatura.
97
References
AL-HADER, M. et al. Smart City Components Architicture. In: COMPUTATIONAL
INTELLIGENCE, MODELLING AND SIMULATION. Anais. . . [S.l.: s.n.], 2009. p.93–97.
ANDREINI, F. et al. A scalable architecture for geo-localized service access in smart cities. In:
FUTURE NETWORK & MOBILE SUMMIT. Anais. . . [S.l.: s.n.], 2011. p.1–8.
ANTHOPOULOS, L.; FITSILIS, P. From digital to ubiquitous cities: defining a common
architecture for urban development. In: INTERNATIONAL CONFERENCE ON
INTELLIGENT ENVIRONMENTS, 6. Proceedings. . . [S.l.: s.n.], 2010. p.19–21.
ASIMAKOPOULOU, E.; BESSIS, N. Buildings and Crowds: forming smart cities for more
effective disaster management. In: INNOVATIVE MOBILE AND INTERNET SERVICES IN
UBIQUITOUS COMPUTING (IMIS), 15TH INTERNATIONAL CONFERENCE. Anais. . .
[S.l.: s.n.], 2011. p.229–234.
ATTWOOD, A. et al. SCCIR: smart cities critical infrastructure response framework. In:
DEVELOPMENTS IN E-SYSTEMS ENGINEERING (DESE), 2011. Anais. . . [S.l.: s.n.],
2011. p.460–464.
ATZORI, L.; IERA, A.; MORABITO, G. The Internet of Things: a survey. Comput. Netw.,
New York, NY, USA, v.54, n.15, p.2787–2805, ’2010’.
BARBACCI, M. et al. Quality Attributes. [S.l.]: Software Engineering Institute, 1995.
Technical report.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. Boston, MA,
USA: Addison-Wesley Longman Publishing Co., Inc., 1998.
BIRD, S. Security and Privacy: why privacy matters. Science and Engineering Ethics, [S.l.],
v.19, n.3, p.669–671, 2013.
BLACKSTOCK, M. et al. MAGIC Broker 2: an open and extensible platform for the internet of
things. In: INTERNET OF THINGS (IOT), 2010. Anais. . . [S.l.: s.n.], 2010. p.1–8.
BOOCH, G. Enterprise Architecture and Technical Architecture. Software, IEEE, [S.l.], v.27,
n.2, p.96–96, 2010.
BUSCHMANN, F. et al. Pattern-oriented software architecture: a system of patterns, vol.1.
[S.l.]: Wiley, 1996.
CARAGLIU, A.; DEL BO, C.; NIJKAMP, P. Smart cities in Europe. [S.l.]: VU University
Amsterdam, Faculty of Economics, Business Administration and Econometrics, 2009. Serie
Research Memoranda. (0048).
CHEN, L.; ALI BABAR, M.; ALI, N. Variability management in software product lines: a
systematic review. In: INTERNATIONAL SOFTWARE PRODUCT LINE CONFERENCE, 13.,
Pittsburgh, PA, USA. Proceedings. . . Carnegie Mellon University, 2009. p.81–90. (SPLC ’09).
CLEMENTS, P. Documenting Software Architectures: views and beyond. [S.l.]:
Addison-Wesley, 2003. (SEI series in software engineering).
98
REFERENCES
COMPUTERWORLD. Smart Cities. "[Online] Acessado em 05-Agosto-2013", http:
//www.computerworld.com.pt/2013/07/04/dossier-smart-cities/.
DIRKS, S.; KEELING, M. A Vision of Smarter Cities. Centre for Economic Development,
Dublin, Ireland, [S.l.], 2009.
DOBBS, R.; INSTITUTE, M. G. Urban World: mapping the economic power of cities. [S.l.]:
McKinsey Global Institute, 2011.
DROEGE, P. Intelligent Environments: spatial aspects of the information revolution. [S.l.]:
Elsevier Science, 1997.
EGER, J. M. Ten Steps to Becoming a Smart Community. [S.l.]: California Institute for
Smart Communities, 2011. "[Online] Acessado em 16-Outubro-2012".
ERBAD, A. et al. MAGIC Broker: a middleware toolkit for interactive public displays. In:
ANNUAL IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS, 6., Washington, DC, USA. Anais. . . IEEE Computer Society, 2008.
p.509–514. (PERCOM ’08).
FAZIO, M. et al. Heterogeneous Sensors Become Homogeneous Things in Smart Cities. In:
SIXTH INTERNATIONAL CONFERENCE ON INNOVATIVE MOBILE AND INTERNET
SERVICES IN UBIQUITOUS COMPUTING (IMIS). Anais. . . [S.l.: s.n.], 2012. p.775 –780.
FELS, S. Sustainable communities: where does communication fit in? In: FIRST
INTERDISCIPLINARY WORKSHOP ON COMMUNICATION FOR SUSTAINABLE
COMMUNITIES, New York, NY, USA. Anais. . . ACM, 2010. p.1:1–1:2. (IWCSC ’10).
FILIPPONI, L. et al. Smart City: an event driven architecture for monitoring public spaces with
heterogeneous sensors. In: INTERNATIONAL CONFERENCE ON SENSOR
TECHNOLOGIES AND APPLICATIONS, 4., Washington, DC, USA. Anais. . . IEEE
Computer Society, 2010. p.281–286.
FOWLER, M. Patterns of Enterprise Application Architecture. [S.l.]: Pearson Education,
2012. (Addison-Wesley Signature Series (Fowler)).
GAMA, K.; DONSEZ, D. A survey on approaches for addressing dependability attributes in the
OSGi service platform. SIGSOFT Softw. Eng. Notes, New York, NY, USA, v.35, n.3, p.1–8,
May 2010.
GARLAN, D.; SHAW, M. An Introduction to Software Architecture. Pittsburgh, PA, USA:
School of Computer Science Carnegie Mellon University Pittsburgh, 1994.
GIFFINGER, R.; PICHLER-MILANOVIĆ, N. Smart Cities: ranking of european
medium-sized cities. [S.l.]: Centre of Regional Science, Vienna University of Technology, 2007.
HALL, N. Are There Really More Mobile Phones Than Toothbrushes? "[Online] Available:
1-August-2012", http://bit.ly/RInZMi.
HAUBENSAK, O. Smart Cities and Internet of Things. Business Aspects of the Internet of
Things, [S.l.], p.33, 2011.
99
REFERENCES
HEBERTY H. AMARAL, D. C. C.; FERNANDES, D. M. Estudo da relação entre as classes
sociais e o consumo de energia elétrica residencial do município de Foz do Iguaçu do estado do
Paraná. 8º congresso internacional sobre geração distribuída de energia no meio rural,
[S.l.], 2010.
HERNáNDEZ-MUñOZ, J. M. et al. Smart cities at the forefront of the future internet. In:
DOMINGUE, J. et al. (Ed.). The future internet. Berlin, Heidelberg: Springer-Verlag, 2011.
p.447–462.
HOOVER, C. E. et al. Sustainable IT Ecosystems: enabling next-generation cities. [S.l.]:
Hewlett-Packard Development Company, 2010.
ISO/IEC. ISO/IEC 9126. Software engineering – Product quality. [S.l.]: ISO/IEC, 2001.
JAUREGUI-ORTIZ, S. et al. Smart Environmental Architecture for Node Localization in a
Wireless Sensor Network. In: INTELLIGENT ENVIRONMENTS (IE), 2012 8TH
INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2012. p.222 –227.
KAZMAN, R. et al. SAAM: a method for analyzing the properties of software architectures. In:
SOFTWARE ENGINEERING, 16., Los Alamitos, CA, USA. Proceedings. . . IEEE Computer
Society Press, 1994. p.81–90. (ICSE ’94).
KAZMAN, R. et al. Experience with performing architecture tradeoff analysis. In: SOFTWARE
ENGINEERING, 1999. PROCEEDINGS OF THE 1999 INTERNATIONAL CONFERENCE
ON. Anais. . . [S.l.: s.n.], 1999. p.54–63.
KAZMAN, R. et al. ATAM: method for architecture evaluation. 2000.
KAZMAN, R. et al. A Basis for Analyzing Software Architecture Analysis Methods. Software
Quality Control, Hingham, MA, USA, v.13, n.4, p.329–355, Dec. 2005.
KLEIN, C.; KAEFER, G. From Smart Homes to Smart Cities: opportunities and challenges
from an industrial perspective. In: INT. CONF. NEW2AN AND 1ST RUSSIAN
CONFERENCE ON SMART SPACES, RUSMART ON NEXT GENERATION
TELETRAFFIC AND WIRED/WIRELESS ADVANCED NETWORKING, 8., Berlin,
Heidelberg. Anais. . . Springer-Verlag, 2008. p.260–260.
KOMNINOS, N. Intelligent Cities: innovation, knowledge systems and digital spaces. [S.l.]:
Taylor & Francis, 2002.
KOMNINOS, N. The architecture of intelligent clities: integrating human, collective and
artificial intelligence to enhance knowledge and innovation. In: IET INTERNATIONAL
CONFERENCE ON INTELLIGENT ENVIRONMENTS, 2. Anais. . . [S.l.: s.n.], 2006. v.1,
p.13–20.
KRCO, S. SmartSantander - A smart city example. ICT event 2010, [S.l.], 2010.
KRUCHTEN, P. The 4+1 View Model of Architecture. IEEE Softw., Los Alamitos, CA, USA,
v.12, n.6, p.42–50, Nov. 1995.
LEE, J.; BAIK, S.; CHOONHWA LEE, C. Building an integrated service management platform
for ubiquitous cities. Computer, Los Alamitos, CA, USA, v.44, p.56–63, 2011.
100
REFERENCES
LI, X. et al. Smart community: an internet of things application. IEEE Communications
Magazine, [S.l.], v.49, n.11, p.68–75, 2011.
MARCEAU, J. Introduction: innovation in the city and innovative cities. Innovation:
Management, Policy & Practice, [S.l.], v.10, n.2-3, p.136–145, 2008.
MARTíN, J. et al. A Home E-Health System for Dependent People Based on OSGI. In:
MARTíNEZ MADRID, N.; SEEPOLD, R. (Ed.). Intelligent Technical Systems. [S.l.]:
Springer Netherlands, 2009. p.117–130. (Lecture Notes in Electrical Engineering, v.38).
MORVAJ, B.; LUGARIC, L.; KRAJCAR, S. Demonstrating smart buildings and smart grid
features in a smart energy city. In: ENERGETICS (IYCE), 3RD INTERNATIONAL YOUTH
CONFERENCE. Anais. . . [S.l.: s.n.], 2011. p.1–8.
MOSTASHARI, A. et al. Citizens as sensors: the cognitive city paradigm. In: EMERGING
TECHNOLOGIES FOR A SMARTER WORLD (CEWIT), 2011 8TH INTERNATIONAL
CONFERENCE & EXPO ON. Anais. . . [S.l.: s.n.], 2011. p.1–5.
NAM, T.; PARDO, T. Conceptualizing smart city with dimensions of technology, people, and
institutions. In: ANNUAL INTERNATIONAL DIGITAL GOVERNMENT RESEARCH
CONFERENCE: DIGITAL GOVERNMENT INNOVATION IN CHALLENGING TIMES, 12.
Proceedings. . . [S.l.: s.n.], 2011. p.282–291.
NATIONS, U. World Population Prospects: the 2006 revision and world urbanization
prospects. New York: United Nations, 2007.
(NIC), N. I. C. Disruptive Civil Technologies - Six Technologies with Potential Impacts on
US Interests Out to 2025. [S.l.]: National Intelligence Council (NIC), 2008.
PLANIT, L. Cities in the Cloud, A Living PlanIT Introduction to Future City Technologies. In:
LIVING PLANIT. Anais. . . [S.l.: s.n.], 2012.
POLLITT, M. M. An Ad Hoc Review of Digital Forensic Models. In: SYSTEMATIC
APPROACHES TO DIGITAL FORENSIC ENGINEERING, 2007. SADFE 2007. SECOND
INTERNATIONAL WORKSHOP ON. Anais. . . [S.l.: s.n.], 2007. p.43–54.
QUN-LI, S.; JIE, L. Two software architecture evaluation methods based on scenario. In:
CONTROL AND DECISION CONFERENCE, 2008. CCDC 2008. CHINESE. Anais. . .
[S.l.: s.n.], 2008. p.2001–2004.
ROY, B.; GRAHAM, T. N. Methods for evaluating software architecture: a survey. School of
Computing TR, [S.l.], v.545, p.82, 2008.
SANCHEZ, L. et al. SmartSantander: the meeting point between future internet research and
experimentation and the smart cities. In: FUTURE NETWORK & MOBILE SUMMIT
(FUTURENETW). Anais. . . [S.l.: s.n.], 2011. p.1–8.
SCHUMPETER, J. A. The Theory of Economic Development: an inquiry into profits, capital,
credit, interest, and the business cycle. [S.l.]: Transaction Books, 1934. (Harvard Economic
Studies).
SHAO, C. An Internet of Things Application with Location Perception Based on IMS. In:
THIRD INTERNATIONAL CONFERENCE ON MULTIMEDIA INFORMATION
NETWORKING AND SECURITY (MINES). Anais. . . [S.l.: s.n.], 2011. p.163–166.
101
REFERENCES
SOMMERVILLE, I. Software Engineering. 8.ed. [S.l.]: Addison Wesley, 2007.
SPÍNOLA, R. O.; TRAVASSOS, G. H. Towards a framework to characterize ubiquitous
software projects. Inf. Softw. Technol., Newton, MA, USA, v.54, n.7, p.759–785, July 2012.
TOMORDY, M. Smart Cities - Transforming the 21st century city via the creative use of
technology. [S.l.]: ARUPCorp., 2011.
TOUSEAU, L.; DONSEZ, D.; RUDAMETKIN, W. Towards a SLA-based Approach to Handle
Service Disruptions. In: IEEE INTERNATIONAL CONFERENCE ON SERVICES
COMPUTING - VOLUME 1, 2008., Washington, DC, USA. Proceedings. . . IEEE Computer
Society, 2008. p.415–422. (SCC ’08).
VEGA-BARBAS, M. et al. Smart Spaces and Smart Objects Interoperability Architecture
(S3OiA). In: INNOVATIVE MOBILE AND INTERNET SERVICES IN UBIQUITOUS
COMPUTING (IMIS), 2012 SIXTH INTERNATIONAL CONFERENCE ON. Anais. . .
[S.l.: s.n.], 2012. p.725–730.
WU, H. et al. 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. Anais. . . [S.l.: s.n.], 2011. p.253 –257.
ZYGIARIS, S. Smart City Reference Model: assisting planners to conceptualize the building of
smart city innovation ecosystems. Journal of the Knowledge Economy, [S.l.], p.1–15, 2012.
Apêndice
105
A
Repositórios de busca na SLR
Tabela A.1: Repositórios de busca na SLR
Nome
IEEExplore
Science Direct
ACM Digital Library
Springer Link
CiteSeerX
Academia.edu
ISI Web of Science & Digital
World Intellectual Property
Organization (WIPO)
International Conference on
Computational Intelligence,
Modeling and Simulation
(IJCCI)
International Conference on
Intelligent Environments (IE)
Multimedia
Information
Networking and Security
(MINES)
Emerging Technologies for a
Smarter World (CEWIT)
International Conference on
Innovative Mobile and Internet Services in Ubiquitous
Computing (IMIS))
Tipo
Digital
Digital
Digital
Digital
Digital
Digital
Digital
Patente
Digital
Manual
URL
http://ieeexplore.ieee.org/
http://www.sciencedirect.com/
http://dl.acm.org/
http://link.springer.com/
http://citeseerx.ist.psu.edu/
http://www.academia.edu/
http://wokinfo.com/
http://www.wipo.int
Manual
http://www.intenv.org/
Manual
http://www.ieee-mines.org/
Manual
http://www.cewit.org/
Manual
http://voyager.ce.fit.ac.jp/conf/imis/2013/
http://www.ijcci.org/
107
B
Avaliação da Arquitetura de Software (AS)
file = images/proposs cenarios.eps, width = 10cm
Figura B.1: Printscreen do formulário online utilizado pelos participantes para propor os
cenários de uso da AS
file = images/scenarios1 .eps, width = 10cm
Figura B.2: Printscreen da Parte 1/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários
file = images/scenarios2 .eps, width = 10cm
Figura B.3: Printscreen da Parte 2/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários
file = images/scenarios3 .eps, width = 10cm
Figura B.4: Printscreen da Parte 3/3 do formulário online para quantificar a adequação
da AS aos respectivos cenários