gustavo henrique rodrigues pinto tomas - repositorio.ufpe.br · catalogação na fonte...

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

RECIFE2014

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Gustavo Henrique Rodrigues Pinto Tomas

UMA ARQUITETURA PARA CIDADES INTELIGENTES BASEADANA INTERNET DAS COISAS

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade 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

RECIFE2014

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çõespara a realização deste trabalho e, principalmente, por ter colocado em meu caminho pessoasmuito especiais que me ajudaram nesta aventura. Algumas destas pessoas serão brevementecitadas a seguir:

Agradeço ao meu orientador Vinicius Cardoso Garcia, pela orientação, pelo espíritoacolhedor, pelo incentivo e pelas cobranças, totalmente necessárias, para me manter o tempotodo focado no objetivo final. Não poderia deixar de agradecer a liberdade e abertura paradiscutir novas ideias e definir novas metas, sem deixar de lado a qualidade do trabalho. Osquestionamentos e a experiência de outras áreas foram de suma importância para a concretizaçãoda proposta. A coragem em se aventurar em uma área de pesquisa recente, na qual ninguémpossuía muita experiência, fatalmente separa os vencedores dos medrosos. Além disso, aconfiança em permitir, que uma parte do mestrado seja realizada remotamente, certamente foiuma atitude de uma pessoa grande, tanto profissionalmente quanto espiritualmente.

Ao grande pesquisador e amigo Alexandre Alvaro pela ajuda e compartilhamento desuas 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 dotrabalho sempre contribuíram de forma muito positivamente, assim como os bate-papos, pormais “viajados” que fossem.

Ao grande irmão de consideração Welington Manoel da Silva, pelo tempo de convi-vência, pelos aprendizados deste período e, principalmente, pela paciência e bom humor paraenfrentarmos juntos toda aquela situação. Em relação à parte técnica, todos os questionamentose palpites foram fundamentais para o aprimoramento da proposta. A forma pelo qual Weling-ton compartilhou seus conhecimentos comigo certamente evidencia uma das suas principaiscaracterísticas: compaixão com o próximo.

Agradeço a minha família pela compreensão nos dias em que fiquei trancado no quarto enos dias de indisponibilidade para conversar por telefone. Em especial aos meus pais Érica eElcio, agradeço ao suporte que, por mais que não seja o que eles gostariam de proporcionar, foimuito 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 mauhumor quando as coisas pareciam estar desabando. Sinceramente, espero que este novo objetivoalcanç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êse 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 deenfrentar os meus desafios sem o seu positivismo. A compreensão e a paciência para enfrentar 9meses à distância certamente comprovaram que somos iguais ao amanhecer: independente doque 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 econfiança em aceitar o desafio de conciliar a rotina de trabalho de 40h semanais com as disciplinasdo mestrado. Nesse sentido, gostaria de agradecer imensamente os meus gestores Paulo Urbanoe Roberta Hazin pela coragem, compreensão e, principalmente, por não aliviarem as minhastarefas, o que contribuiu muito para a minha formação acadêmica e profissional. Espero que elestenham a consciência de que esse tipo de atitude afetou, e muito, positivamente a vida de umapessoa. 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 despro-porcional aos recursos necessários para a vida humana. Cada vez mais a quantidade de pessoasvivendo nas áreas urbanas aumenta, devido à diversos fatores, como as oportunidades que sãogeradas nestes grandes centros.

Este desenfreado crescimento populacional, principalmente nas áreas urbanas, além deoutros fatores como má governança, ocasiona e/ou intensifica diversos problemas urbanos. Paraexemplificar este fato, pode-se citar os grandes problemas que as cidades brasileiras enfrentamnas á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 afim de aumentar a qualidade de vida dos cidadãos. Para tal, uma importante ferramenta para aimplementação de uma CI é a Internet of Things (Internet das Coisas) (IoT), na qual diversosobjetos são combinados para atingir um objetivo em comum como, fornecer informações dofluxo de veículos de uma cidade.

Porém, para que este cenário seja de fato consolidado, necessita-se de uma Arquiteturade Software (AS) capaz de integrar e combinar as diferentes tecnologias e dados que compõemos serviços urbanos.

Na literatura pode-se encontrar várias Arquiteturas de Software (AS’s) para CI, inclusivecom apoio de grandes empresas. Porém, estas AS’s visam atender apenas um determinadoserviço urbano com uma aplicação específica, o que não caracteriza de fato uma implementaçãode CI.

Motivado por estes desafios, esta dissertação apresenta a especificação, o projeto ea avaliação de uma AS para CI que permite a integração com IoT, baseado no conjunto derequisitos extraídos das soluções existentes. Adicionalmente, são discutidos os resultadosobtidos, 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 fromthe essential resources for human life. More and more, the amount of people living in urbanareas is increased due to several factors, including the opportunities which are generated in theselocals.

This unbridled populational growth, mainly in urban areas, and other factors such as poorgovernance, leads and/or enhances many urban problems. To illustrate this fact, we can mentionthe 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 orderto increase the citizens quality of life. For such an important tool for the implementation of a SCis 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 ableto integrate and combine different technologies and data that comprise the urban services isrequired.

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, whichfeatures not in fact an implementation of SC.

Motivated by these challenges, this thesis presents the specification, the design andevaluation of a SC architecture that allows integration of IoT technologies, based on a set ofrequirements drawn from existing approaches. Additionally, we discuss the results obtained, theproblems 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 Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Resultado da filtragem das abordagens . . . . . . . . . . . . . . . . . . . . . . 40

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

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

B.1 Printscreen do formulário online utilizado pelos participantes para propor oscenários de uso da AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

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



Lista de Tabelas

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

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

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

A.1 Repositórios de busca na Systematic Literature Review (Revisão Sistemática daLiteturatura) (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 Introdução 231.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

2 Cidades Inteligentes e Internet das Coisas 292.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 dasCoisas) (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

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

3 Revisão da Literatura de Arquiteturas de Software para Cidades Inteligentes 373.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

3.1.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2.1 Abordagens Resultantes . . . . . . . . . . . . . . . . . . . . 42

3.2 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.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


4 Uma Arquitetura de Software para Cidades Inteligentes baseada na Internet dasCoisas 594.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

4.4 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


21

5 Avaliação da Arquitetura de Software 775.1 Métodos de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.1.1 Métodos Analisados . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.1.2 Descrição dos métodos restantes . . . . . . . . . . . . . . . . . . . . . 79

5.2 Adaptação dos métodos de avaliação . . . . . . . . . . . . . . . . . . . . . . . 805.2.1 Definição do método de avaliação . . . . . . . . . . . . . . . . . . . . 805.2.2 Equipe de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2.3 Descrição do Método de Avaliação . . . . . . . . . . . . . . . . . . . 81

5.3 Processo de Avaliação Executado . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.1 Primeira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.2 Segunda Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.3.3 Terceira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4 Resultados da Avaliação da Arquitetura . . . . . . . . . . . . . . . . . . . . . 865.4.1 Resultados da Avaliação dos Cenários . . . . . . . . . . . . . . . . . . 875.4.2 Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.5 Ameaças à Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.6 Considerações Finais do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . 90

6 Conclusão 916.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

References 97

Apêndice 103

A Repositórios de busca na SLR 105

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

232323

1Introduçã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 Brasileirode Geografia e Estatística (IBGE), publicada no Diário Oficial da União 1, em julho de 2012 oBrasil 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 ocupammenos de 2% da massa terrestre, os residentes urbanos consomem mais de três quartos dosrecursos naturais do mundo e são os principais responsáveis pela emissão de gases do efeitoestufa MARCEAU (2008). Problemas decorrentes da rápida urbanização indicam uma perdade funcionalidades básicas para ser um lugar habitável: por exemplo, a dificuldade na gestãode resíduos, a escassez de recursos naturais, a poluição do ar, as doenças humanas, o intensotráfego de veículos e deterioração e envelhecimento das infraestruturas KRCO (2010).

Algumas iniciativas isoladas estão sendo desenvolvidas para mitigar alguns dos pro-blemas urbanos NAM; PARDO (2011). As iniciativas vão de aplicativos como “Waze”2, umserviço que combina geolocalização no celular com indicações do fluxo e problemas de trânsitovia smartphones, até governamentais, como o Centro de Operações da Prefeitura do Rio de

1http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=22042https://www.waze.com/

http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=2204

24 CAPÍTULO 1. INTRODUÇÃO

Janeiro3, sistema que integra informações a respeito dos diferentes serviços públicos oferecidospela cidade.

Porém, para de fato estabelecer uma Cidade Inteligente (CI) é necessário que estasiniciativas estejam integradas em uma mesma Arquitetura de Software (AS), seja para com-partilhar 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 permitaa 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 monitoramentoda 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. Aoaplicar este conjunto de componentes nos contextos urbanos, vários desafios são gerados paraintegrá-los e obter o melhor de cada componente.

Para este e outros cenários semelhantes, uma AS para CI pode ajudar a integrar essesdiversos componentes. Para tal, a AS deve ser totalmente plugável e expansível, do ponto devista dos protocolos de comunicação implementados.

1.2 Estabelecimento do Problema

Motivado pelas questões apresentadas na Seção anterior, o principal objetivo destetrabalho é, em linhas gerais:

Especificar, projetar e implementar uma Arquitetura de Software (AS) para Ci-dade Inteligente (CI) que permita o desenvolvimento de soluções com base em Internet ofThings (Internet das Coisas) (IoT), independente das especificações de cada tecnologia ecaracterí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 realizadoum estudo das Arquiteturas de Software (AS’s) para CI baseada em IoT tanto na academia quantona indústria, por meio de dois métodos de revisão literária: Revisão Exploratória e RevisãoSistemática. Este estudo teve como finalidade identificar as técnicas empregadas nestas soluçõese 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, umconjunto de requisitos ao qual uma nova AS para CI deve atender foi estabelecido. Em seguida,

3http://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 representaos requisitos fundamentais. Por fim, a AS foi submetida à um processo de avaliação formaladaptado 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 fundamentaispara o contexto de CI. Estes requisitos são implementados a partir da utilização de padrõesarquiteturais já conhecidos e utilizados em outros tipos de AS’s de software, como publisher-

subscriber. A Figura 1.1 ilustra a AS proposta.

Registro de recursos Configuração de recursos

Driver

BD

1BD1

BD2

BD3

DHT-BD

Driver

BD

2...

Interface: Banco de D

ados

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)

Módulo de Persistência de

Dados (MPD)

DHT - Canal

de dados

P P ...

C C ...

Canal 2

P P ...

C C ...

....Canal 3

P P ...

C C ...

Canal 1

Driver

BD

3

REST

Interface: Protocolos de troca de mensagens

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 Gerenci-amento de Recursos (MGR), Módulo de Gerenciamento e Distribuição de Dados (MGDD) eMódulo de Persistência de Dados (MPD). Estes módulos fornecem as funcionalidades essenciaisutilizadas pelos diferentes tipos de usuários do sistema.

O MAC representa o ponto de entrada dos usuários, aplicações ou até mesmo serviçosexternos. O MAC provê todos os mecanismos necessários para o acesso e a comunicação coma AS, tanto para envio quanto para recebimento de informações. Por sua vez, o MGR visagerenciar as informações relativas aos diferentes tipos de recursos disponíveis na AS. Já oMGDD possui a responsabilidade de disseminar os dados na AS, tanto os dados de fora paradentro da AS quanto os dados obtidos a partir de alguma computação interna para os agentesexternos. O último módulo (MPD), como o próprio nome já identifica, possui a responsabilidadede armazenar os dados oriundos dos diferentes níveis da AS. Estes dados, nos mais variadosestágios da AS, são importantes para a predição de acontecimentos futuros, a partir do histórico


de dados.Os detalhes da AS serão descritos no Capítulo 4.

1.4 Escopo Negativo

Como a solução proposta por esta dissertação faz parte de um contexto mais amplo, umconjunto de aspectos relacionados não será tratado no escopo deste trabalho.

Adicionalmente, os requisitos tratados na solução não formam um conjunto completo efechado 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/ouadaptação de uma AS para CI que combine tecnologias de IoT, tanto para coletar informaçõesquanto para atuar no ambiente.

Os seguintes aspectos não fazem parte do escopo deste trabalho:

� Modelo de Negócio: Aspectos relacionados ao suporte a modelos de negócio e es-traté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, estetrabalho não faz nenhum tipo de análise de big data, apenas permite que um serviçoque 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.

1.5 Principais Contribuições

Como resultado do trabalho apresentado nesta dissertação, as seguintes contribuiçõespodem ser destacadas:

� Estado de arte de AS para CI: A partir das revisões da literatura executadas foipossível apresentar um resumo a respeito do estado da arte de CI no Brasil e nomundo, a partir da descrição de algumas abordagens com ou sem apoio dos setoresestatais e privados;

� Comparativo entre dois métodos de revisão literária: A partir dos resultadosobtidos 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 emercadológica;

� Requisitos de uma AS para CI: Um conjunto de requisitos essencias que uma ASpara 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 aosprincipais requisitos de CI que combina conceitos de IoT foi especificada;

� Implementação inicial: Baseado na proposta desta dissertação, uma implementaçãoinicial foi realizada e disponibilizado em domínio público. Esta implementação servede 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 nenhummétodo de avaliação que fosse totalmente compatível com as peculiaridades docontexto deste trabalho. Logo, foi proposta e utilizada uma adaptação de doismétodos de avaliação: SAAM e ATAM. Esta adaptação foi aplicada, na qual se pôdecomprovar a sua utilidade. Este método pode ser empregado em qualquer contextosemelhante, principalmente se a equipe esta geograficamente distribuída.

Além das contribuições finais listadas acima, alguns resultados intermediários destetrabalho 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 Internatio-

nal Conference on Enterprise Information Systems (ICEIS). Lisboa: SCITEPRESS

Science and Technology Publications, 2013. p. 427-434.

� AFONSO, R. A. ; SILVA, W. M. ; TOMAS, G. H. R. P. ; ALVARO, Alexandre ; Garcia,

Vinicius Cardoso . Br-SCMM: Modelo Brasileiro de Maturidade para Cidades


Inteligentes. In: IX Simpósio Brasileiro de Sistemas de Informação (SBSI), 2013,

João Pessoa. Anais do III Simpósio Brasileiro de Sistemas de Informação. Curitiba,

PR, novembro de 2006. Porto Alegre: Sociedade Brasileira de Computação, 2013. v.

1. p. 511-516.

1.6 Organização da Dissertação

O restante desta dissertação está organizado conforme se segue:

� Capítulo 2: contextualiza a temática de CI e IoT, além de esclarecer a interaçãoentre as duas áreas de pesquisa;

� Capítulo 3: apresenta a revisão bibliográfica sobre AS para CI que combinamtecnologias IoT, com o objetivo de identificar as principais soluções existentes naacademia e na indústria e estabelecer um conjunto de requisitos fundamentais queuma 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 principaiscontribuiçõ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 pesquisasfuturas.

292929

2Cidades 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 deinfraestruturas e consomem um crescente volume de recursos e de energia, com um significativoimpacto 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 é descritaem kuper1995social como “um povoado relativamente grande e permanente”. Geralmente, umacidade possui alta densidade populacional e os cidadãos interagem com indústrias, comérciose serviços. No quesito operacional, cidades são baseadas em um conjunto de serviços urbanosbásicos: energia, água, transporte, infraestrutura de informação e comunicação, mercado, saúdepública e saneamento público MORVAJ; LUGARIC; KRAJCAR (2011).

Este conjunto de serviços urbanos básicos é justamente onde se localizam os principaisproblemas das cidades MORVAJ; LUGARIC; KRAJCAR (2011). Além disso, com o crescimentopopulacional supracitado no Capítulo anterior e o envelhecimento das infraestrturas, surge anecessidade 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 criadose/ou otimizados para suprir as necessidades dos cidadãos.

Estes fatores demonstram os grandes desafios para os gestores das cidades. Problemasrelacionados ao tráfego, segurança, consumo de água e energia, dentre outros, têm sido cada vezmais 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 esão uma dura realidade das cidades brasileiras. Catástrofes como enchentes são um problemade defesa civil devido a ocupação desordenada de encostas e morros, ameaçando diversascomunidades 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 deSegurança Pública, entre 2004 e 2005 a taxa de roubo no Brasil por 100 mil habitantes aumentoude 516,7 para 519,4;

Transporte: O sistema de transporte coletivo é de qualidade e eficiência questionáveisna maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e as crescentesfacilidades 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 otrânsito é um problema em muitas cidades. Soluções paliativas, como rodízio de veículos, apenasatenuam o crescimento do problema do tráfego, quando, na verdade, uma otimização no sistemade transportes coletivos faz-se necessária. Dois exemplos da situação do transporte coletivono Brasil podem ser encontrados na Pesquisa de Mobilidade Da Região Metropolitana de SãoPaulo2: 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 aaguardarem em longas filas de espera e o mesmo problema vem assolando pacientes do sistemaprivado 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 pobresgerou uma elevação no consumo de energia elétrica, mas classes média e alta ainda representama maior fatia do consumo de energia elétrica, pelo padrão de consumo e conforto que envolvediversos tipos de eletroeletrônicos. Em Foz do Iguaçu, por exemplo, 7% das famílias corres-pondem 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ísesem desenvolvimento. Enquanto cidades de países desenvolvidos põem em prática diversassoluções de tratamento de lixo orgânico e de reaproveitamento de materiais recicláveis, cidadesde países como o Brasil não conseguem definir ou executar práticas de reciclagem, salvo rarasexceções. Por exemplo, de acordo com a Associação Brasileira de Empresas de Limpeza Públicae Resíduos Especiais (ABRELPE)4, em 2012 cerca de 60% dos municípios registraram algumainiciativa de coleta seletiva. Embora seja expressiva a quantidade de municípios com iniciativasde coleta seletiva, muitas vezes estas atividades resumem-se à disponibilização de pontos deentrega voluntária ou convênios com cooperativas de catadores, que não abrangem a totalidadedo território ou da população do município.

1http://portal.mj.gov.br/services/DocumentManagement/FileDownload.EZTSvc.asp?DocumentID={42595482-B0DD-4185-918E-80E4BAFAFC72}&ServiceInstUID={B78EA6CB-3FB8-4814-AEF6-31787003C745}

2http://www.metro.sp.gov.br/pdf/mobilidade/pesquisa-mobilidade-2012.pdf3http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/ams/default.shtm4http://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 quea academia tem destinado para o tema, ainda não há um consenso a respeito da definição doconceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado para empregá-loGIFFINGER; PICHLER-MILANOVIC (2007); CARAGLIU; DEL BO; NIJKAMP (2009); LIet al. (2011). Logo, a Seção 2.1 visa clarificar a definição de CI a ser utilizada durante estetrabalho.

Um paradigma que vem sendo utilizado em diversas abordagens para CI é a utilizaçãode IoT como ferramenta para captar dados e atuar sobre os serviços urbanos. Logo, a Seção 2.2visa 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, princi-palmente, nas cidades brasileiras. Em seguida, apresenta-se a integração existente entre estasduas áreas de pesquisa e alguns exemplos de utilização desta integração para mitigar algumadeficiê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á umconsenso a respeito deste conceito. A seguir, são apresentadas as principais definições descritasna 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 foiutilizado. Por exemplo, a definição de CI, quando associada com economia, é uma cidade comindústria inteligente, na qual são empregadas tecnologias de última geração para aprimoraros aspectos financeiros e econômicos. No aspecto educação, Giffinger et. al. caracteriza CIcomo o nível de escolaridade dos cidadãos. Além disso, de acordo com Giffinger et. al., umaCI também pode ser mensurada a partir do relacionamento entre o governo e os cidadãos e autilização de modernas tecnologias, não somente relacionada à Tecnologia da Informação eComunicaçã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 emprol 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 naliteratura HERNáNDEZ-MUñOZ et al. (2011), pois permite quantificar o nível de inteligência dascidades. Por exemplo, inovação faz parte do eixo smart economy e é calculado pela quantidadede patentes por habitantes HAUBENSAK (2011).

Apesar dessa definição ser considerada a mais abrangente, cada trabalho adota umadefinição mais apropriada para o escopo do projeto. Em Kehua-2011, a IBM define CI comoo uso de TIC para capturar, analisar e integrar informações relevantes no núcleo dos sistemas


das cidades. Ao mesmo tempo, uma CI pode tomar decisões inteligentes para diferentes tiposde necessidades, incluindo aspectos diários, proteção ambiental, segurança pública, serviços dacidade e atividades industriais e comerciais.

Analogamente, em moss2009informed o termo CI é definido como uma cidade que com-bina TICs com a infraestrutura física, para prover conveniências aos cidadãos, como: eficiênciaenergética; aumento da qualidade da água e do ar; identificar e resolver rapidamente qualquerproblema no funcionamento dos sistemas da cidades; mitigar desastres; capturar dados paraapurar a tomada de decisões e a utilização de recursos de forma eficiente. Logo, a CI não podeser 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 sistemasde sensoriamento são transparentes para os cidadãos, porém desepenham papel fundamental paragarantir o funcionamento operacional da cidade.

Uma CI também é definida como um território no qual as TICs propiciam inovaçõesem diversos segmentos, combinando a criatividade e o talento individual em prol da populaçãoda 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 conceitosociotécnico. Integra-se três vertentes essenciais: a tecnologia, as pessoas e as instituições. UmaCI 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 deveidentificar e otimizar os processos governamentais, mitigando a burocracia que envolve oprocessso 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 Mun-dial para Cidades Inteligentes)5 define que uma CI é uma comunidade com avanços significativosem TICs que transformam o cotidiano dos cidadãos, melhorando os aspectos relacionados aotrabalho 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 comu-mente aplicados aos mesmos contextos, como “cidades virtuais”, “cidades digitais”, “cidadeinformatizada”, “cidade eletrônica” KOMNINOS (2006). Ao generalizar esse conceito aosambientes inteligentes que se relacionam com serviços urbanos, vários sinônimos de CI sãofrequentemente empregados, como “information city”, “wired city”, “telecity”, “knowledge-

based city”, “electronic communities”, “electronic community spaces”, “flexicity”, “teletopia”,“cyberville” DROEGE (1997).

Essa ausência de consenso é devido aos múltiplos movimentos científicos, tecnológicos esociais que compõem o contexto de uma cidade KOMNINOS (2006). Em cada disciplina, existeuma série de problemas que afetam diretamente diversos serviços existentes, como transporte,

5http://www.smartcommunities.org

33 2.2. CONCEITO DE IOT! (IOT!)

segurança, provisão/consumo de energia elétrica e água, saneamento básico, utilização derecursos naturais, controle de catástrofes, principalmente no que tange a gestão individual einfluê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áriomoderno de telecomunicações sem fio. A idéia básica deste conceito é a presença de um conjuntode objetos (things) - como Radio-Frequency IDentification (RFID), sensores, atuadores, telefonescelulares - que, por meio de mecanismos de endereçamento único (como a Internet), são capazesde 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 ecomportamento das pessoas ATZORI; IERA; MORABITO (’2010’). Por exemplo, já existemaplicações IoT que permitem o monitoramento de atividades físicas6 e controle de medicamentosde uso contínuo7. Outro conjunto de aplicações que interferem no cotidiano das pessoas sãoas 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 motivopelo qual IoT é incluída pelo Conselho Nacional de Inteligência dos EUA (NIC) na lista dasseis tecnologias civis “com impactos potenciais sobre o poder nacional dos EUA” (NIC). Alémdisso, 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á-lasao 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çõesLI et al. (2011) para uma AS centralizada HAUBENSAK (2011).

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

10http://www.harvestgeek.com/


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

A partir dos problemas comumente enfrentado pelas cidades, surge o desafio de com-binar diferentes informações com TIC, a fim de mitigar estes problemas e promover melhorescondições de vida aos cidadãos. Neste sentido, as tecnologias IoT também podem ser integradascomo ferramentas para monitorar os eventos de um ambiente, atuar a fim de conter uma situaçãoemergencial 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. Umexemplo é o monitoramento do trânsito em estradas e rodovias. Este monitoramento, a partir desensores espalhados pelas vias, poderia alimentar sistemas de informação capazes de gerar rotasem tempo real, redistribuindo os veículos, aumentando a fluidez das vias. Esta redistribuiçãopoderia ser feita ao enviar informações para os dispositivos GPS dos veículos ou até mesmopor um conjunto de painéis indicativos para orientar os motoristas sobre a melhor rota. Acomunicação e a troca de informações entre estes diferentes objetos constituem um cenário deuso clássico de IoT.

Outro exemplo da utilização maciça de TIC e IoT é o controle do consumo residencialde energia elétrica a partir de eletrodomésticos habilitados a otimizar seu funcionamento deacordo 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 rotineirasdos 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% dasemissões de carbono em Londres, apenas com a mudança de comportamento dos cidadãos, apartir do acompanhamento de todas as tarefas dia-a-dia TOMORDY (2011). Esta mudança decomportamento foi possível a partir de uma rede sensores que fornecia informações do nível decarbono em tempo real .

2.4 Considerações Finais do Capítulo

Este Capítulo contextualizou as duas grandes áreas de pesquisa deste trabalho: CidadeInteligente (CI) e Internet of Things (Internet das Coisas) (IoT).

Como discutido previamente, ainda não há um consenso a respeito da definição maisadequada para CI. Logo, a Seção 2.1 apresentou algumas definições disponíveis na literatura. Apartir destas, a definição a ser utilizada neste trabalho foi explicitada, considerando os diferentespontos de vistas dos demais autores.

Em seguida, a IoT foi definida e exemplificada na Seção 2.2. A partir desta, pode-senotar a evidente correlação entre estas duas áreas de pesquisa. Este fato pode ser comprovadoao 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ésticoATZORI; IERA; MORABITO (’2010’).

Por fim, a Seção 2.3, apresentou alguns exemplos de utilização de IoT e dos conceitos deCI para mitigar estes problemas urbanos. Algumas destas iniciativas já estão sendo desenvolvidase validadas, porém, para de fato se estabelecer uma CI, é necessária a integração destas iniciativasa 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 comoferramenta 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 doismétodos de revisão da literatura.

373737

3Revisão da Literatura de Arquiteturas deSoftware 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 emOuro)

No contexto de uma Cidade Inteligente (CI), as Arquitetura de Software (AS) são desuma importância por uma série de fatores. Primeiramente, uma AS pode permitir a troca deinformações entre diferentes serviços urbanos, a fim de fornecer serviços mais efetivos para oscidadãos. Outro fator relevante é a possibilidade de criar aplicações Internet of Things (Internetdas Coisas) (IoT) que consumam ou forneçam algum tipo de dado para uma determinadafinalidade, como por exemplo, captar informações de pontos turísticos da cidade para melhorara experiência dos turistas. Esta integração das aplicações IoT com a AS será independente datecnologias 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 ASpode permitir que governos adotem ações estratégicas voltadas para as reais necessidades doscidadãos.

Ao adotar um modelo como esse, na qual uma AS centralizada processa e distribuí dosdados dos serviços urbanos, uma CI pode de fato ser implementada, uma vez que existirá um meiopelo 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 deservidor 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 SOFTWAREPARA CIDADES INTELIGENTESatualidade ainda explorada e, sobretudo, mesclada a outras AS para atender ao objetivo de umsoftware FOWLER (2012). Já na década de 2000, nota-se que as aquiteturas propostas são cadavez mais heterogêneas, na qual estilos e tecnologias diferenciadas se misturam para formar novasversões de representações arquiteturais BASS; CLEMENTS; KAZMAN (1998).

Dessa forma, o que se almeja investigar neste Capítulo é o estado da arte de Arquiteturasde 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 rea-lizadas: Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). As revisões sistemáticaspossibilitam a replicação do procedimento, pois possuem um processo repetitível. Porém, atemática deste trabalho envolve aspectos mercadológicos que podem ser excluídos dessas revi-sões, por não serem publicados nos veículos convencionais. Logo, as revisões exploratórias sãoimportantes, pois permitem incluir diversos trabalhos de diferentes veículos de publicação, comopor exemplo, relatório técnico de empresas. Porém, esse tipo de revisão possui certa resistênciapor 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 necessi-dade 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ória16 abordagens foram selecionadas. Nestas duas revisões, 7 abordagens foram encontradasem ambas as revisões. Estes trabalhos destacam-se por envolverem aspectos acadêmicos emercadológicos. Nestes casos, optou-se por descrevê-los apenas na Revisão Sistemática. Porfim, 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 conso-lidar as características mais relevantes de cada abordagem. Em seguida, pretende-se estabelecerum 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 publi-cados 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 finalizao Capítulo.

3.1 Revisão Sistemática

Conforme brevemente introduzido na Seção anterior, de acordo com Kitchenham-2007o 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 daseleçã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ãofoca-se somente nas AS’s que utilizam o paradigma de combinar IoT como ferramenta para aimplementaçã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 utilizadospara filtrar e extrair as informações relevantes de cada pesquisa. Essa estratégía segue asrecomendaçõ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 metodo-logia emprega por Kitchenham-2007, Chen-2009 e Khurum20091982. Esta estratégia é ilustradana Figura ??.

file = images/stringprocess.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 digitaisda literatura (como IEEExplore, Springer Link e ACM Digital Library), não é possível utilizar amesma string de busca em todas as fontes digitais CHEN; ALI BABAR; ALI (2009). Logo, foinecessário um esforço para garantir que as strings utilizadas sejam logicamente e semanticamenteequivalentes.

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 depesquisa que envolve diversos aspectos de negócio e mercado, realizou-se a busca por patentesno 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 depesquisa.

1http://www.wipo.int

40 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWAREPARA CIDADES INTELIGENTES

Tabela 3.1: Quantidade de abordagens por fonte de pesquisa

Fonte de Dados #1. IEEExplore 242. Science Direct 12913. ACM Digital Library 19334. Springer Link 14845. CiteSeerX 3996. Academia.edu 427. ISI Web of Science 48. WIPO 12339. IJCCI 410. IE 811. MINES 312. CEWIT 313. IMIS 7Total 6435

A qualidade dos motores de busca podem influenciar a integridade das abordagens iden-tificadas como primários, conforme discutido em Chen-2009. Dessa forma, algumas abordagenspodem não ter sido incluídas, caso os autores tenham usado outros termos além dos mencionadosacima.

3.1.1.2 Seleção das Abordagens

Nesta SLR foram selecionadas somente abordagens que propõem uma AS e/ou fra-

mework 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 noprocesso de seleção e classificação

Após definir a string de busca e as fontes, foram definidos filtros para classificar asabordagens encontradas. A Figura ?? ilustra os resultados de cada filtro, baseado na quantidadede 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 paraCI baseadas em IoT. O primeiro filtro corresponde a todas as abordagens encontradas nas fontesde pesquisa, descritas anteriormente, a partir da string de busca.

O segundo filtro foi aplicado para excluir as abordagens que não foram publicadas entre2008-2012. Este intervalo foi escolhido após analisar e verificar que as abordagens propostasantes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens foram propostas parasolucionar problemas específicos de um contexto usando apenas uma tecnologia, sem analizar a


conexão entre os diferentes contextos urbanos.

Para realizar a terceira filtragem, todos os títulos das abordagens foram lidos e resultaramapenas 71. Esta alta discrepância com o valor resultante do filtro anterior está relacionada a faltade 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 oquinto filtro, todos os resumos foram lidos e discutidos entre a equipe.

Cada uma das 33 abordagens resultantes foram lidas e discutidas entre a equipe destaSLR. Em seguida, apenas 11 abordagens resultaram como relevantes para a proposta destetrabalho.

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 maistecnologias diferentes e/ou contextos urbanos E

� Abordagens que ainda não foram selecionadas.

Durante esta revisão, foram encontradas diversas abordagens que descrevem a mesmaAS. Neste caso, somente o trabalho mais completo foi considerado. Após essa etapa, restaram11 abordagens para serem analisadas.

Existem diversas razões para esta alta discrepância entre a quantidade inicial de tra-balhos com a quantidade resultante. A principal razão é a alta quantidade de estudos du-plicados com resultados semelhantes. Estas razões são discutidas e explicadas em Kitche-nham:2009:SLR:1465742.1466091.

Em relação às patentes, não foi encontrada nenhuma patente relacionada. Geralmente, aspatentes mais próxima à temática dessa revisão sistemática descrevem um algoritmo específicoou 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 acordocom os critérios descritos na Seção anterior, restaram 11 abordagens. Estas abordagens foramlidas e discutidas entre os 5 pesquisadores supracitados, com o objetivo de realçar os tópicosrelacionados às questões de pesquisa. Esta seção visa discutir estas abordagens, iniciando poruma descrição inicial de cada abordagem.

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


Tabela 3.2: Abordagens resultantes por ordem cronológica

ID Abordagem Ano Referência1 Al-Hader’2009 2009 AL-HADER et al. (2009)2 Anthopoulos’2010 2010 ANTHOPOULOS; FITSILIS (2010)3 SOFIA 2010 FILIPPONI et al. (2010)4 EcoCity/ISMP-UC 2011 LEE; BAIK; CHOONHWA LEE (2011)5 CPAF 2011 MOSTASHARI et al. (2011)6 SmartSantander 2011 SANCHEZ et al. (2011)7 IMS 2011 SHAO (2011)8 USN 2011 HERNáNDEZ-MUñOZ et al. (2011)9 Wu’2011 2011 WU et al. (2011)

10 Fazio’2012 2012 FAZIO et al. (2012)11 S3OiA 2012 VEGA-BARBAS et al. (2012)

3.1.2.1 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 cadaabordagem.

Iniciando por Al-Hader’2009 AL-HADER et al. (2009), no qual é proposto uma ASbaseada em quatro princípios: aplicações, negócios, gerenciamento de processos e infraestruturade redes. O primeiro princípio corresponde às aplicações que fazem uso de diferentes tecnologiaspara monitorar sensores, como Global Positioning System (GPS). De acordo com AL-HADERet 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 agregarsoluções economicamente viáveis. O terceiro princípio é o gerenciamento de processos na qualrelacionamentos, regras, estratégias e políticas entre as aplicações e as unidades de negócios sãodefinidas. Finalmente, o último princípio corresponde a toda a infraestrutura de rede, responsávelpor 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çãode sistemas legados com as novas infraestruturas, migração e reuso de dados existentes, simplifi-cação dos processos urbanos, otimização da utilização de recursos naturais, interoperabilidadede 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 FILIPPONIet al. (2010), centrada no conceito de Smart Environment (Ambiente inteligente) como umecossistema de interação de objetos, como sensores, dispositivos e sistemas embarcados emgeral. A AS SOFIA é baseada em eventos, na qual cada evento corresponde à mudança de estadode qualquer sistema de TIC. Estes eventos podem ser iniciados a partir de eventos do mundo


real (como detecção de presença) ou ao término de algum processamento.

O monitoramento e gerenciamento de sensores também são objetivos definidos pelaabordagem denomida EcoCity/ISMP-UC LEE; BAIK; CHOONHWA LEE (2011). A ASEcoCity/ISMP-UC é constituída de três camadas. A camada inferior consiste de diferentestipos de sensores, atuadores e outros dispositivos distribuídos pela cidade. Já a camada superiorrepresenta 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çospossibilita o desenvolvimento de serviços independentes e que sejam consumidos via interfacespadronizadas, como web services.

Por sua vez, mostashari2011citizens propõem um framework denominado Cognitive

Process Architecture Framework (CPAF), o qual permite o desenvolvimento de diferentesserviços urbanos com habilidades cognitivas. Nesse contexto, cognição é a habilidade dosistema aprender a partir das experiências anteriores e adaptar seu comportamento a partir destasconclusõ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 conjuntorepresentativo de casos de uso implementados para facilidades de experimentação e iv) umgrande conjunto de experimentos relacionados à Internet do Futuro.

Com o mesmo objetivo de interoperabilidade de objetos abordado em Smart Santander, aabordagem 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 comos 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 IMSa partir de diferentes terminais. A camada de sessão provê o gerenciamento de sessões entre acamada inferior (Acesso) e a superior (Aplicações). Finalmente, a camada de aplicação permiteo desenvolvimento de diversas aplicações.

A interoperabilidade de objetos também é explorada por Hernandez-2011, que propõemuma AS denominada Ubiquitous Sensor Network (USN). O objetivo é prover uma infraestruturaque seja capaz de integrar sensores heterogêneos e distantes geograficamente em um basecentralizadora, na qual serviços podem ser facilmente desenvolvidos. Adicionalmente, a ASinclui um módulo conhecido como USN-Gateway que possibilita a interoperabilidade entre redesde sensores e redes IP.

Da mesma forma que USN, Wu’2011 WU et al. (2011) propõem um middleware paragerenciamento de informações dispersas oriundas de múltiplas fontes, com diferentes formatose estruturas. Esta abordagem é construída seguindo os princípios de Arquitetura Orientada aServiços (SOA), baseada em duas principais componentes: modelo Contract-First e agente de

44 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWAREPARA CIDADES INTELIGENTEStroca de mensagens.

Em Fazio’2012 FAZIO et al. (2012) é proposto uma AS que permite a agregação dediferentes tipos de informações oriundas de diferentes sensores distribuídos pelos contextosurbanos. O principal objetivo dessa abordagem é de prover dados contextualizados, combinandodiferentes fontes de dados. Para isso, a AS consiste de quatro camadas: I) REST que permiteminteraçõ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 dadospara as demais camadas; IV) Sensing Infrastructure é composto de vários diferentes sensores.

Finalmente, a abordagem conhecida como S3OiA VEGA-BARBAS et al. (2012) tambémpermite o gerenciamento de diferentes tipos de informação. A AS S3OiA é sintática e semânticaaos princípios do SOA, que permitem a integração de qualquer tipo de dispositivo IoT. Comessa estratégia, a AS suporta a composição de aplicações ad hoc. Para tal, foi definido dentrodo projeto da AS um conjunto de módulos de dependência semântica de gestão que controlamserviços e recursos, permitindo que os aplicativos já criados possam continuar a execução, apesardas 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 desen-volvidas tanto no ambiente acadêmico quanto no empresarial. Por exemplo, pode-se ressaltar ointeresse das organizações governamentais e/ou privadas, como Microsoft PLANIT (2012), alémdas 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óriotécnico disponibilizados pela própria organização, como HP HOOVER et al. (2010) e IBMDIRKS; 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 mecanismoque 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, indepen-dente do tipo e do veículo de publicação do conteúdo. Em algumas situações, essas revisõespodem 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ãodificilmente pode ser repetido.

Logo, essa revisão exploratória visa discutir e analisar as principais abordagens que pro-põ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.

2http://www.libelium.com3http://www.evrythng.com

45 3.2. REVISÃO EXPLORATÓRIA

3.2.1 Metodologia de Pesquisa

Nas revisões exploratórias não há um processo ou guideline definido POLLITT (2007).Geralmente, o procedimento consiste em levantar diversas fontes com a informação desejada eentão separá-las a partir de métodos específicos.

No caso dessa revisão, inicialmente algumas buscas foram realizadas em três repositóriosde buscas: IEEE Xplore, Mendeley e ACM Digital Library. As principais palavras-chavesutilizadas foram: Smart Cities, Internet of Things, Architecture, Smart Enviroment, Digital

City, Smart Cities Survey. Apesar de empregar estas palavras-chaves, nenhuma string de buscaespecífica foi definida.

A partir dos resultados dessas buscas, alguns trabalhos foram classificados como rele-vantes de acordo com o título e uma rápida leitura do conteúdo. Em seguida, todos os trabalhosrestantes foram lidos e discutidos, com o mesmo grupo da Revisão Sistemática, do ponto devista arquitetural e do emprego das tecnologias IoT para resolver a problemática de CI. A partirdestas fontes, as principais referências destes trabalhos também foram analisadas, repetindo aabordagem 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 destaproposta, uma vez que a metodologia de pesquisa não é abrangente o suficiente. Além disso, aorealizar 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, especifi-camente de provedores de infraestruturas e soluções dentro do contexto de utilização eficiente deenergia elétrica para infraestruturas inteligente e data centers. O objetivo do trabalho é aderireficiência energética dos equipamentos, reduzindo os custos com energia e criando mecanismospara que softwares e serviços tornem-se autoconscientes de seu consumo de energia. De acordocom os autores, esta característica é essencial na implementação de uma AS de CI, permitindodesenvolvimento e operação sustentáveis.

Em MB2-2010 é proposta uma plataforma chamada Magic Broker (MB2), a qual possuio objetivo de permitir a interoperabilidade de objetos. Inicialmente desenvolvida com o objetivode prover um modelo consistente e padronizar as interfaces para a construção de aplicaçõesde IoT, o MB2 esta sendo adaptado para o contexto de CI. Para tal, além de prover a APIpara consultas, a plataforma provê abstrações fundamentais, como: eventos, estado, serviços egerenciamento de conteúdo.

O MB2 consiste de uma evolução do MB original ERBAD et al. (2008), na qual foraminseridas diversas características para a construção de aplicações ubíquas, como a inclusão de ummiddleware 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 SOFTWAREPARA CIDADES INTELIGENTESdesses 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 comoPlanIT Valley5, a cidade deve produzir 150% da energia necessária, gerenciar os resíduos sólidose 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). Essesistema operacional é uma plataforma com o intuito de integrar cada domínio que compõemuma cidade. O sistema será alimentado por uma vasta rede de sensores e todos esses dados serãocapturados por tempo indeterminado, para auxiliar na tomada e na predição de decisões. Alémde 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, comoem Masdar City HAUBENSAK (2011). A cidade de Masdar City foi desenvolvida no deserto deAbu Dhabi com 6 km quadrados, 50.000 habitantes, 1500 empresas e universidades. O objetivodo projeto é desenvolver projetos auto-suficientes com o mínimo de impacto ambiental. Todaa 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 quesitotransporte, os veículos privados são proibidos e os meios de transporte são veículos elétricos ebicicletas. As estações de transportes elétricos serão separadas por uma distância de no máximo200 metros. A primeira fase do contém aparelhos ecologicamente corretos desenvolvidos pelaGeneral Eletric (GE).

Em nam2011conceptualizing é descrita a teoria da sinergia que deve existir entre tec-nologia, pessoas e instituições na concepção de CI. O trabalho destaca especificamente que ainteligência refere-se comumente às mudanças inovadoras trazidas por novas tecnologias. Emrelação ao aspecto tecnologia, os autores afirmam que é essencial que a cidade possua alta adap-tabilidade às necessidades de seus cidadãos, independente de suas limitações, com capacidadede autoconfiguração, proteção, otimização e recuperação de falhas, garantindo disponibilidadede serviços a qualquer tempo. Para isso, faz-se necessário uma infraestrutura de computaçãoubíqua, sobre a qual os serviços serão disponibilizados.

De acordo com andreini2011scalable, SOA é considerada uma investida promissora naconstrução de CI através da implementação da IoT. Assim, objetos conectados à rede publicariamseus serviços, que por sua vez seriam acessados a partir de clientes móveis, permitindo interaçõeshumano-máquina e máquina-máquina (M2M) mais flexíveis. Isso seria construído a partirde uma abordagem semelhante ao Domain Name System (DNS), no qual um objeto seriaidentificado através de um nome, usado para acessá-lo e consultar serviços. Os autores propõeuma implementação usando Distributed Hash Table (DHT), que atribui o nível de escalabilidade

4http://www.osgi.org5http://living-planit.com

47 3.2. REVISÃO EXPLORATÓRIA

desejado para a abordagem adotada, permitindo a recuperação eficiente de serviços no contextode aplicações para CI.

Outro aspecto muito relevante para qualquer centro urbano é a predição, prevenção ecorreção de situações catastróficas, nas quais medidas urgentes devem ser tomadas no menortempo, com a máxima eficácia possível. Em asimakopoulou2011buildings, é proposto umaAS 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, quemonitoram 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 ambienteno domínio em questão, para que a solução encontrada seja eficaz. Para isso utilizou-se daabordagem crowdsourcing, na qual os próprios cidadãos, habilitados por algum tipo de aplicaçãoe/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, esua alocação envolve uma negociação baseada em conjuntos de políticas. Isso garante que autilizaçã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 parametrizadade alertas, assegurando a disponibilidade dos recursos.

Concomitantemente, em attwood2011sccir é proposta uma AS para infraestruturas críti-cas em CI, que destaca a necessidade de coleta de dados tempo real de diversos aspectos dentrodo 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 qualuma rede de sensores distribuída pela cidade estaria conectada e cujos dados estariam mapeadospara um serviço específico (Ex.: falha no sistema de distribuição de energia elétrica). Quandoalgum tipo de falha fosse detectado, os dados coletados seriam fornecidos a uma instância deraciocí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ósainda em funcionamento, permitindo a preservação e distribuição dos dados. Para que esta ASseja implementada é requerida uma infraestrutura de hardware distribuída, com capacidadede 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. Oprincipal objetivo desta AS é propor um modelo que possa ser empregado em qualquer planeja-mento urbano inteligente. Este modelo contempla os conceitos sustentáveis, especificamentena segunda camada, conhecida como Green City. Essa camada é sustentada pela camada res-ponsável pela infraestrutura da cidade e contém todas as políticas ambientais, por exemplo, onível de CO2 permitido pelas residências. As demais camadas correspondem, respectivamente:

48 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWAREPARA CIDADES INTELIGENTESinovação, aplicação, integração, sincronização e interconexão entre diferentes redes. Para validaro 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, foramselecionadas 11 abordagens. Já na Revisão Exploratória 16 abordagens foram selecionadas e 7abordagens foram encontradas em ambas as revisões. No total, 20 abordagens foram encontradasa 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 abordagenspublicadas 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 aborda-gens 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 amplamentevalidadas 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çãoprá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 nosambientes reais.

Esta falta de suporte governamental é comprovada na coluna “Incentivo”, na qual apenas4 abordagens contém esse tipo de suporte.

A partir dessas abordagens, a próxima Seção visa elencar um conjunto de requisitosmínimos que uma nova AS para CI que combine IoT deve atender.

3.4 Requisitos para uma Arquitetura de Software para Cida-des 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

49 3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADESINTELIGENTES

Tabela 3.3: Resumo das abordagens descritas na literatura

Abo

rgag

emA

noO

bjet

ivo

Valid

ação

Ince

ntiv

oK

lein

’200

820

08A

umen

tara

efici

ênci

aen

ergé

tica

dedi

spos

itivo

sco

nect

ados

aoam

bien

teur

bano

Sem

valid

ação

prát

ica

Priv

ada

Al-

Had

er’2

009

2009

Perm

itira

cria

ção

deso

luçõ

esin

telig

ente

sSe

mva

lidaç

ãopr

átic

aA

mbo

sA

ntho

poul

os’2

010

2010

Inte

graç

ãodo

ssi

stem

asle

gado

sco

mas

nova

sin

frae

stru

tura

s,m

igra

ção

ere

uso

deda

dos

exis

tent

esSe

mva

lidaç

ãopr

átic

aPr

ivad

a

MB

220

10Pe

rmiti

rain

tero

pera

bilid

ade

deob

jeto

sV

alid

ada

emam

bien

teco

n-tr

olad

oPr

ivad

a

And

rein

i’20

1120

11Pl

ataf

orm

aes

cáve

lque

perm

itea

inte

rope

rabi

lidad

ede

obje

tos

apa

rtir

deSO

ASe

mva

lidaç

ãopr

átic

aPr

ivad

a

Asi

mak

opou

lou’

2011

2011

Pred

ição

,pre

venç

ãoe

corr

eção

desi

tuaç

ões

cata

stró

ficas

Val

idad

aem

ambi

ente

con-

trol

ado

Priv

ada

Attw

ood’

2011

2011

Plat

afor

ma

para

situ

açõe

scr

ítica

sSe

mva

lidaç

ãopr

átic

aPr

ivad

aIM

S20

11In

tero

pera

bilid

ade

deob

jeto

sSe

mva

lidaç

ãopr

átic

aPr

ivad

aC

PAF

2011

Cri

ação

dese

rviç

osur

bano

sco

mha

bilid

ades

cogn

itiva

sSe

mva

lidaç

ãopr

átic

aPr

ivad

aSO

FIA

2011

Inte

graç

ãode

sens

ores

Val

idad

aem

ambi

ente

con-

trol

ado

Priv

ada

Wu’

2011

2011

Ger

enci

amen

toefi

cien

tede

info

rmaç

ões

disp

ersa

sor

iund

asde

múl

tipla

sfo

ntes

,com

dife

rent

esfo

rmat

ose

estr

utur

asSe

mva

lidaç

ãopr

átic

aPr

ivad

a

Mas

darC

ity20

11Im

plem

enta

rsus

tent

abili

dade

nos

serv

iços

urba

nos

Em

anda

men

toA

mbo

sU

SN20

11In

tero

pera

bilid

ade

deob

jeto

sSe

mva

lidaç

ãopr

átic

aPr

ivad

aE

coC

ity/I

SMP-

UC

2011

Om

onito

ram

ento

ege

renc

iam

ento

dese

nsor

esre

mot

amen

teV

alid

ada

emam

bien

teco

n-tr

olad

oA

mbo

s

Nam

’201

120

11C

riaç

ãode

plat

afor

ma

ubíq

uaSe

mva

lidaç

ãopr

átic

aPr

ivad

aSm

artS

anta

nder

2011

Plat

afor

ma

para

acr

iaçã

ode

solu

ções

urba

nas

inte

ligen

tes

Val

idad

aem

ambi

ente

con-

trol

ado

Priv

ada

Zyg

iari

s’20

1220

12M

odel

opa

rage

renc

iam

ento

inte

ligen

tede

qual

quer

cida

deV

alid

ado

nas

cida

des

deB

ar-

celo

na,

Am

ster

dãe

Edi

m-

burg

o

Am

bos

S3 OiA

2012

Inte

graç

ãode

disp

ositi

vos

via

SOA

Sem

valid

ação

prát

ica

Priv

ada

Liv

ing

Plan

IT20

12C

riaç

ãode

Sist

ema

Ope

raci

onal

Urb

ano

Em

anda

men

toem

Lis

boa,

Port

ugal

Priv

ada

Fazi

o’20

1220

12Pr

over

dado

sco

mbi

nado

sV

alid

ada

emam

bien

teco

n-tr

olad

oPr

ivad

a

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 partirdo levantamento das arquiteturas realizado, a proposta desta Seção é discutir um conjunto derequisitos fundamentais que devem ser atendidos na implantação de uma AS para CI.


3.4.1 Interoperabilidade de objetos

Um dos requisitos mais discutidos e estudados em projetos IoT é a interoperabilidadede objetos, na qual cada objeto é uma abstração de um sensor, atuador ou qualquer outrodispositivo 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 umavasta gama de objetos com diferentes especificações técnicas.

No contexto de CI este requisito também é fundamental, visto que os dados são oriundosde diversos objetos, com tecnologias e protocolos variados.

As AS’s designam um módulo ou camada para atender esse requisito, como em SOFIAFILIPPONI 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 S3OiA VEGA-BARBAS et al. (2012). Em particular, nocaso 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émimplementa 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 temporeal. Este requisito é de suma importância para manter todos os serviços da cidade constante-mente atualizados.

Além disso, o monitoramento em tempo real é a ferramenta mais importante para forneceras informações mais relevantes para a predição e tomada de decisões de eventos futuros e preverfenômenos. Um exemplo disso é o monitoramento do nível dos rios durante as temporadas dechuva. Nessa situação, a partir de um monitoramento efetivo é possível tomar medidas paramitigar 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 quevisam atender esse requisito são Al-Hader’2009 AL-HADER et al. (2009), SOFIA FILIPPONIet 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 ealimentos. 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, principalmenteas metrópoles.


Neste sentido, uma AS para CI deve permitir que políticas sustentáveis (sustentabili-dade) sejam implementadas com base em estatísticas relacionadas ao dia-a-dia dos cidadãos. Porexemplo, iniciativas de consumo consciente de alimentos podem ser implementadas ao mapearos 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 umacidade, 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 otimizadanão pode significar a erosão da qualidade de vida das pessoas. Até porque, para de fato estabeleceruma CI é necessário envolver as pessoas, procurando a sua participação para lhes proporcionarmaior qualidade de vida, mas protegendo a dimensão humana das urbes cada vez mais em riscoCOMPUTERWORLD (2013).

Uma AS para CI não pode ser sustentada somente com tecnologia. O propósito principalna concepção de uma CI é o aumento na qualidade de vida de seus cidadãos, através de aspectossociais.

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 anosde funcionamento, a população não utilizava ou não tinha conhecimento dos serviços digitaisdisponíveis ANTHOPOULOS; FITSILIS (2010).

De qualquer forma, CI são construídas por pessoas, para pessoas, e essa deve ser umapremissa 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 comoparte 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 dainiciativa Fun Theory6, da Volkswagen, na qual mudam-se as maneiras de fazer as coisas, a fimde estimular a mudança de hábitos.

Além disso, os serviços devem estar disponíveis para todos os cidadãos independente dequaisquer restrições social, física, econômica ou financeira, a tecnologia deve ser aplicada a fimde trazer benefícios coletivos, e não alienar ou elitizar uma pequena parte da população.

6http://www.thefuntheory.com/


Apesar da evidente importância deste requisito fundamental, apenas as AS’s que explici-tamente contém aspectos sociais são Klein’2008 KLEIN; KAEFER (2008), IMS SHAO (2011) eAsimakopoulou’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 cor-responde a qualquer tecnologia móvel capaz de capturar informação sobre o ambiente ou atuarsobre 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 serutilizados, como ZigBee e RFID (Radio-frequency identification).

Logo, uma AS para CI deve permitir a comunicação efetiva com os mais diversos dispo-sitivos oriundos da temática de ubiquidade, uma vez que estes estarão fisicamente próximos aoscidadãos. Neste contexto, as AS’s que já empregam alguns destes princípios são SmartSantanderSANCHEZ 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ãoinstalados 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 esegurança dos dados, tanto em relação à disponibilidade quanto ao armazenamento.

Certamente a consolidação destes políticas é um desafio que pode impedir os cida-dãos, instituições e o governo de fornecerem determinados dados críticos. Este fato pode sercomprovado a partir dos recentes casos de violação de privacidade dos dados governamentaisamplamente 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 dossensores é fundametal para o refinamento do processo de análise de dados. Neste sentido, umsensor corresponde à uma abstração de qualquer dispositivo capaz de fornecer informações sobredeterminado contexto.


A partir destas informações geográficas dos sensores é possível realizar ações específicaspara cada ambiente JAUREGUI-ORTIZ et al. (2012). Esta característica pode ser notada nasabordagens IMS SHAO (2011), USN HERNáNDEZ-MUñOZ et al. (2011) e S3OiA VEGA-BARBAS et al. (2012). No caso da abordagem IMS, a geolocalização dos sensores é importantepara a investigação do comportamento dos cidadãos; na USN, a localização é considerada umrequisito diferenciador; por fim, em S3OiA a localização é utilizada para unificar as açõesrealizadas 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ínioscomplexos (como transporte, água, energia elétrica, saneamento básico, etc.) disponibilizadospara suprir as necessidades de seus cidadãos. AS’s que se dispõe a dar suporte à esses sistemasdevem considerá-los como complementares na busca de um gerenciamento urbano efetivo, aoinvés de tratá-los de forma isolada.

Pelo fato de que CI pode ser considerada um sistema de sistemas, a composição dosdados oriundos destes ambientes urbanos deve ser considerada um requisito fundamental.

Estes dados de cada ambiente urbano deve ser disponibilizado de forma que possam serreutilizados e agrupados para criar uma visão holística e contextualizada da cidade na qual a ASfoi 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 ANTHO-POULOS; 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 cidadeestã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, desdeque seja agregado a outros dados.

Estes dados históricos podem ser empregados na predição de eventos futuros, princi-palmente quando houver um grande período sem dados em tempo real. Por exemplo, a partirde informações meterológicas dos anos anteriores é possível prever os meses que poderão tertempestades. Com informação nessa granularidade é possível adotar providências preventivaspara evitar catóstrofres.

Logo, torna-se substancial que as AS’s contemplem mecanismos eficientes de arma-zenamento 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 SOFTWAREPARA CIDADES INTELIGENTES(2011) e Living PlanIT PLANIT (2012), estas informações historicamente armazenadas potenci-alizarã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çõescontextualizadas, 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 dis-ponibilidade 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 defluxo, 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 diversosmecanismos 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 permeiamesses serviços, bem como do resultado que produzem. É através de sensoriamento que se obtêma visão computacional do ambiente urbano; quanto maior o número de sensores e mais dispersoeles estiverem, maior será o escopo abrangido pela AS.

A heterogeneidade dos sensores utilizados influencia na riqueza de detalhes e na quan-tidade de dados que podem ser extraídos de cada cenário monitorado, sendo possível obterresultados mais precisos. Por exemplo, reports de trânsito em determinada via podem sermelhor analisados se complementados com imagens obtidas através de câmeras instaladas nasredondezas.

Em situações que exigem que medidas preventivas ou corretivas sejam tomadas instanta-neamente exige-se processamento em tempo real, com tempo de resposta rápido o suficiente parafornecer embasamento para ações que devem ser executadas assim que determinada situaçãoé identificada. Considerando quantidades massivas de dados coletados, o suporte à esse tipode contexto sugere a necessidade de processamento distribuído, explorando a capacidade dainfraestrutura existente.

Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerarinformações e conhecimento, permite execução de seus serviços de forma otimizada e umgerenciamento 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-UCLEE; BAIK; CHOONHWA LEE (2011).

55 3.5. SUMÁRIO DOS REQUISITOS PARA CIDADES INTELIGENTES

3.4.12 Flexibilidade/Extensibilidade

Este requisito corresponde à capacidade da AS adaptar-se à mudanças e extensões. Alémda inserção de novos serviços, a AS deve ser capaz de adaptar-se à novos requisitos inerentes aocontexto de implementação. Por exemplo, a AS deve ser independente de padrões específicos dehardware.

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-UCLEE; 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’sabordadas nesse Capítulo. Nesta tabela, a coluna # representa a quantidade de abordagensencontradas que visam atender ao determinado requisito.

Ao analisar essas informações, pode-se perceber que nenhuma dessas AS’s implementamminimamente todos os requisitos levantados.

Isto deve-se ao fato de que as AS’s geralmente são projetadas para propósitos específicose 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 Moni-toramento em Tempo Real são os mais abordados pelas AS’s. Esta observação confirma aimportância em monitorar constantemente todos os aspectos que envolvem a cidade, processare disponibilizar os dados coletados rapidamente, a fim de fornecer uma visão de estado doambiente 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 consideradosessenciais no contexto desse trabalho. A abordagem de estruturação da AS, cujas camadasapresentam os mesmos princípios de abstração encontrados em sistemas operacionais, garanteas mesmas vantagens aos mesmos atribuídas - como abstração e gerenciamento de dispositivosfí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óriaforam encontrados trabalhos com investimentos da iniciativa privada e que já se encontram emestágio de prototipação.

Ao término desse Capítulo, pode-se perceber que não há a necessidade da criação de umnovo padrão arquitetural ou adaptação de um padrão já existente para o contexto de CI e IoT.


Tabela 3.4: Mapeamento requisitos-arquiteturas

Requisito Abordagens #Interoperabilidade de objetos SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygia-

ris’2012, Wu’2011 e S3OiA7

Monitoramento em temporeal

Al-Hader’2009, SOFIA, SmartSantander, USN, Asimako-poulou’2011, Attwood’2011 e Living PlanIT

7

Sustentabilidade Klein’2008, EcoCity/ISMP-UC, SmartSantander, MasdarCity e Zygiaris’2012

5

Aspectos sociais Klein’2008, IMS e Asimakopoulou’2011 3Ubiquidade/Mobilidade SmartSantander, USN, MB2 e Zygiaris’2012 4Privacidade e Segurança dosdados

SmartSantander, Living PlanIT e Fazio’2012 3

Geolocalização dos Sensores IMS, USN e S3OiA 3Composição de Dados Urba-nos

Nam’2011, CPAF, IMS, Anthopoulos’2010, Fazio’2012 eLiving PlanIT

6

Histórico de dados MB2, SmartSantander, EcoCity/ISMP-UC e Living Pla-nIT

4

Disponibilidade SmartSantander, USN e Nam’2011 3Sensoriamento e Processa-mento Distribuído

USN, SOFIA, Andreini’2011 e EcoCity/ISMP-UC 4

Flexibilidade/Extensibilidade Klein’2008, MB2 e EcoCity/ISMP-UC 2

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 empregadopelas AS’s foi o publisher-subscriber, devido, principalmente, as vantagens em utilizá-lo paramodelar o ambiente real.

Além disso, pode-se perceber que algumas AS’s foram propostas para finalidades es-pecíficas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem mecanismosinteressantes de tratamento de eventos em tempo real que devem ser considerados no desenvolvi-mento de qualquer AS para CI.

Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há umconsenso amplamente aceito na literatura sobre quais os requisitos que uma AS deve atender paraser considerada efetiva, independente da forma como foi implementada. A partir das abordagensestudadas, pode-se estabelecer um conjunto de requisitos essenciais ao analisar os principaisobjetivos das abordagens previamente descritas. Esses requisitos constituem a base para qualquerAS para CI, pois abrangem os princípios definidos para uma CI.

Ao analisar esse conjunto de requisitos, nota-se que nenhuma AS atendeu todos osrequisitos. Geralmente, as AS’s são propostas com propósitos específicos e ignoram algunsrequisitos essenciais.

Dessa forma, ao propor uma nova AS para CI é de suma importância que ela atenda amaior quantidade desses requisitos, para que uma cidade possa ser de fato considerada inteli-gente. Esses requisitos servirão como pilares para a elaboração da AS para CI que combine astecnologias de IoT que será descrita nos próximos Capítulos.



Este Capítulo apresentou algumas abordagens arquiteturais encontradas na litetura. Paratal, 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, ressal-tando, 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 cadaabordagem. Por fim, a Seção 3.4 apresentou um conjunto de requisitos, extraídos a partir daaná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 arquiteturalamplamente discutido na literatura KRUCHTEN (1995).

595959

4Uma Arquitetura de Software para CidadesInteligentes 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 inte-graçã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. Ofoco da solução proposta consiste em atender um sub-conjunto destes requisitos, bem comoprover mecanismos, do ponto de vista de infraestrutura, para que novos requisitos possam serfuturamente 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 abordadosnesta proposta. Já para descrever a proposta detalhadamente é utilizado um método de descriçãode 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 eas operações realizadas com mais frequência. Por sua vez, a Seção 4.4 apresentará a Visão deExecução, com o mapeamento dos componentes lógicos em processos e threads. A Seção 4.5apresentará a Visão de Implementação, seguido da Seção 4.6 explicitando a Visão Física. Alémdas visões deste método, duas outras visões definidas pelo SEI CLEMENTS (2003) foram utili-zadas 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 INTELIGENTESBASEADA NA INTERNET DAS COISASneste 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 derequisitos foi selecionado para ser abordado nesta proposta de AS. A Tabela 4.1 exibe todosos requisitos e indica quais destes foram abordados nesta proposta, ordenados pela quantidadede abordagens encontradas que visam atender o determinado requisito, conforme ilustrado nacoluna #.

Tabela 4.1: Requisitos abordados

Requisito Abordado #Interoperabilidade de objetos Sim 7

Monitoramento em tempo real Sim 7Composição de Dados urbanos Sim 6

Sustentabilidade Não 5Histórico de dados Sim 4

Ubiquidade/Mobilidade Sim 4Sensoriamento e Processamento Distribuído Sim 4

Geolocalização dos Sensores Sim 3Privacidade e Segurança dos dados Não 3

Aspectos sociais Não 3Disponibilidade Não 3

Flexibilidade/Extensibilidade Sim 2

Ao analisar a Tabela 4.1, percebe-se que do total de 12, apenas 4 não foram incluídosnesta 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 literaturaque visam satisfazer esse requisito, conforme pode ser observado na coluna “#”; e ii) este conjuntode requisitos foi incluído nesta proposta são os requisitos mínimos que toda AS de software paraCI deve atender.

Os demais requisitos que, mesmo considerados importantes/relevantes, não foram abor-dados nesta proposta, dificilmente podem ser abordados nesta proposta no estágio atual. Asaber:

� Sustentabilidade: A proposta atual não possui nenhuma parceria com instituiçõesgovernamentais. Logo, nas 5 abordagens na qual esta requisito foi encontrado,todas possuíam uma parceria com as prefeituras locais, que criavam campanhas paraincentivar o consumo consciente dos cidadãos.

� Privacidade e Segurança dos dados: De fato, esta necessidade foi identificada nocomeço desta pesquisa, porém um outro trabalho de mestrado está sendo desenvolvidocom este escopo. Este trabalho de privacidade será acoplado à esta proposta assimque finalizado. Para isso, as definições de interfaces e padrões de mensagens estãosendo 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çourbano.

� Aspectos sociais: Da mesma forma que o requisito de Sustenabilidade, para quea AS atenda ao requisito de Aspectos Sociais é necessário o estabelecimento deparcerias com as instituições governamentais para de fato incluir os cidadãos comoparte do sistema de uma CI.

� Disponibilidade: O requisito de Disponibilidade está relacionado à infraestrutura naqual esta proposta estará sendo executada.

4.2 Metodologia “4+1”

A Arquitetura de Software (AS) tem desempenhado um papel fundamental no desenvol-vimento de sistemas de software. Ela oferece um maior entendimento da aplicação por dividi-laem um conjunto de componentes que interagem entre si para realizar parte de uma ou váriasfuncionalidades do sistema GARLAN; SHAW (1994).

Porém, diversos autores relatam a falta de eficiência em documentar essas AS’s paraque sejam legíveis para os mais variados stakeholders GARLAN; SHAW (1994); CLEMENTS(2003). Visando atender essa ineficiência, em Kruchten:1995:VMA:624610.625529 é propostoum método de descrição de AS’s baseado em visões chamado “4+1”. Para facilitar a compreensãopelos 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 naFigura ??.

file = images/promodelo.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áriosstakeholders da AS: usuários finais, desenvolvedores, engenheiros de sistemas, gerentes deprojetos, 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 arelaçã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 INTELIGENTESBASEADA NA INTERNET DAS COISAS

� A visão de implementação centra-se em aspectos relacionados com a organizaçãodo código-fonte do sistema, padrões de AS utilizada e as orientações e as normaspara o desenvolvimento do sistema;

� A visão física demonstra as configurações de hardware e o mapeamento dos elemen-tos de software para os elementos de hardware no ambiente do sistema;

� A visão componente conector se refere ao comportamento dos componentes emtempo de execução e seus conectores, que são responsáveis pela comunicação entreestes;

� 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 umasoluçã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 propostaarquitetural 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. Osprincipais elementos, como módulos e componentes principais são especificados. A interfaceentre estes elementos também é especificada. A Figura 4.2 ilustra a arquitetura do ponto de vistalógico.

As subseções seguintes explicitarão cada módulo, ressaltando sua responsabilidade e osrequisitos 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 asaplicações e serviços externos. O MAC provê os mecanismos necessários para o acesso e acomunicação com a AS, a partir da interface REST (Representational state transfer).

De acordo com MB2-2010 e Hernandez-2011, utilizar uma interface padronizada, comoREST, é 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-secompatível com o requisito de ubiquidade/mobilidade.

Além disso, de acordo com MB2-2010 e Filipponi-2010, a principal estratégia para queuma AS contemple a interoperabilidade de objetos é permitir a comunicação com dispositivose sistemas através de diferentes protocolos de troca de mensagens. Para tal, o MAC contém

63 4.3. VISÃO LÓGICA

Registro de recursos Configuração de recursos

Driver

BD

1BD1

BD2

BD3

DHT-BD

Driver

BD

2...

Interface: Banco de D

ados

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)

Módulo de Persistência de

Dados (MPD)

DHT - Canal

de dados

P P ...

C C ...

Canal 2

P P ...

C C ...

....Canal 3

P P ...

C C ...

Canal 1

Driver

BD

3

REST

Interface: Protocolos de troca de mensagens

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 osdiferentes protocolos de troca de mensagem sob demanda.

O funcionamento do MAC consiste em receber cada requisição dos diferentes recursose encaminhá-las para os demais módulos. Para isso, o MAC oferece todos os operações parainteragir 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 orespectivo 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 sensoresespalhados pela cidade, um cidadão portando um dispositivo móvel ou até mesmo um sistemaexterno (como um perfil em qualquer rede social), dentre outros tipos de fornecedores de dadosSANCHEZ et al. (2011); KLEIN; KAEFER (2008); ASIMAKOPOULOU; BESSIS (2011).

Desta forma, o Módulo de Gerenciamento de Recursos (MGR) visa gerenciar as infor-mações relativas a estes fornecedores de dados. Dentre essas informações, a geolocalização dossensores deve ser mantida a fim de aumentar a eficiência e a confiabilidade do dado fornecidoHERNá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. ORegistro de Recursos contém operações, acessíveis a partir do MAC, que permitem o registro deum recurso. Além disso, a partir da existênca deste recurso, este sub-módulo disponibiliza todasas 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 INTELIGENTESBASEADA NA INTERNET DAS COISASem 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 responsabilidadede disseminar os dados por toda AS. Logo, pode ser considerado o core da AS, por (i) atender amaior quantidade de requisitos; (ii) implementar os principais mecanismos que diferenciam estaAS das demais abordagens semelhantes e (iii) implementar toda a infraestrutura de distribuiçãode dados.

Um dos padrões mais utilizados no design de AS é o publisher-subscriber, na qual a prin-cipal vantagem é o desacoplamento entre os produtos e fornecedores de dados BUSCHMANNet al. (1996). O MGDD contém uma implementação deste padrão, representados na Figura 4.2pelas caixas com a letra ’P’ e ’C’, respectivamente.

No MGDD, os fornecedores (publisher) fornecem dados em um canal específico dedados; por sua vez, os consumidores (subscriber) devem ser inscreverem nestes canais de dadospara 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 mundoreal em AS, pois permite disparar eventos simultâneamente, na qual pode-se ativar um oumais 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 aadequação à um dos mais importantes requisitos de uma AS para CI: a Composição de DadosUrbanos PLANIT (2012); NAM; PARDO (2011); MOSTASHARI et al. (2011). Para tal, ummesmo componente consumidor (subscriber) pode se inscrever em dois ou mais canais, obterestes 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 dolimite 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íveispara todos os consumidores, através de consultas pelo tipo de dado que é disponibilizado. Damesma forma, DHT é utilizada para os fornecedores obterem a referências para os canais maisapropriados para fornecerem seus dados. A Seção 4.3.6 exemplificará este cenário com um casoprático.

Além disso, a utilização de uma DHT é importante para prover escalabilidade e proces-samento distribuído. A escalabilidade é obtida a partir da criação de novos canais de dados, amedida que o sistema se expande. Da mesma forma, como não há limite de consumidores efornecedores no mesmo canal de dado, a DHT permite a escalabilidade em termos de recursosde dados.

65 4.3. VISÃO LÓGICA

Já em relação ao processamento distribuído, a DHT permite que os canais de dadosestejam distribuídos em diferentes hosts, desde previamente registrado no MGR. Logo, assimque 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 deproporcionar 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 armazenaros dados oriundos dos diferentes níveis da AS. Estes dados, em todos os níveis da AS, sãoimportantes 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 interfacetransparente para quem a utiliza sobre o respectivo banco de dados. Esta interface é importantepara permitir o desacoplamento entre o respectivo banco de dados com os componentes que outilizam.

Antes de algum recurso realizar uma consulta em um banco de dados específico, este podeser encontrado a partir da “DHT Banco de Dados”. Por sua vez, essa DHT tem a responsabilidadede gerenciar todos os drivers de banco de dados disponíveis no momento da transação, além depermitir que os bancos de dados estejam distribuídos em diferentes hosts.

Estudos futuros devem ser realizados para avaliar o banco de dados mais adequado deacordo 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 daAS.

Tabela 4.2: Mapeamento Requisitos por Módulo

Requisito MAC MGR MGDD MPDInteroperabilidade de objetos X X

Monitoramento em tempo real X X XComposição de Dados urbanos X X X X

Histórico de dados X XUbiquidade/Mobilidade X X

Sensoriamento e Processamento Distribuído X X XGeolocalização dos Sensores X XFlexibilidade/Extensibilidade X X


4.3.6 Operações

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

4.3.6.1 Consumidor: Recurso receber dados

A Figura ?? ilustra uma abstração de um diagrama de fluxo referente as atividadesa serem realizadas para que um recurso obtenha um dado. Este diagrama abstrai algumaspeculiaridades, como a implementação da interface padronizada exigida para o funcionamentocorreto do padrão publisher-subscriber.

Inicialmente, este recurso deve solicitar a referência do canal que contém o dado emquestã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. Assimque um novo dado for fornecido por qualquer recurso fornecedor, o dado será imediatamentesentregue aos recursos que se inscreveram nesse canal.

file = images/receberdado.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 umdado. Existem dois cenários específicos para o fornecimento de dado: (i) quando já existe umcanal no qual o dado é disponibilizado, ou seja, existe pelo menos mais um recurso fornecedorque 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 umcanal no qual este dado é fornecido. Caso exista, a DHT retornará a referência desse canal quecorresponde ao primeiro cenário, como ilustrado na Figura ??.

file = images/fornecerdado.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 umanova 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/fornecernovodado.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 orecurso fornecedor enviar os respectivos dados assim que eles estiverem disponíveis.

67 4.4. VISÃO DE EXECUÇÃO

4.3.6.3 Compor um dado urbano

A operação de compor um dado urbano pode ser considerada uma combinação entreas 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çãode 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 adevida referência deve ser retornada.

De posse da referência do canal na qual será disponibilizada o dado combinado, inicia-sea segunda fase, conhecida como Consumo de Dados. Nesta fase, o recurso deve consultar a DHTpara adquirir a referência de todos os canais que já fornecem os dados que serão utilizados para acombinação. Após obter a referência de todos os canais, o recurso deve se inscrever para receberos dados oriundos destes canais.

file = images/compordado.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 com-binação, ou seja, o recurso pode se inscrever em vários canais para utilizar estes dados nacombinação.

Feito isso, inicia-se a terceira fase, Criação de Dados. Esta fase corresponde ao meca-nismo de receber os dados dos vários canais inscritos, combiná-los de alguma forma utilizandoalgum 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 executadaem background por tempo indeterminado. Além disso, ressalta-se que o momento em que anova informação combinada é disponibilizada no canal resultante depende da regra de negócioimplementada. Por exemplo, um recurso de combinação de dados que gera um relatório dasunidades de emergência por regiões de uma cidade pode consumir os dados de cada unidade egerar 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 ethreads 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 oriundasdos mais variados tipos de clientes. Além disto, este processo é responsável por conter a interfaceque sera implementada por cada adaptador.


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

Módulo Processos ThreadsMAC 1 por adaptador + 1 principal 1 por requisiçãoMGR 1 por sub-módulo + 1 princi-

pal1 por operação

MGDD 4 processos principais 1 por consumidor de dados +1 por fornecedor de dados + 1por canal de dado

MPD 1 principal + 1 DHT + 1 porBanco de Dados

0

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 asrequisições, uma thread é criada para cada requisição, já que as requisições são gerenciadas deforma independente.

4.4.2 Módulo de Gerenciamento de Recursos (MGR)

O MGR possui um processo principal que é responsável por conter todas as interfacesdas operações visíveis aos demais módulos. Além disto, cada cada sub-módulo é executado emprocesso separado para que técnicas de cache possam ser futuramente desenvolvidas de formaeficiente.

As operações que serão realizadas nos sub-módulos devem ser eficientes a ponto denã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 utilizandoté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 processoresponsável pela implementação dos canais de dados; na mesma linha, um processo é necessáriopara controlar os (ii) consumidores e (iii) outro para os fornecedores; finalmente, (iv) o últimoprocesso é responsável por gerenciar a DHT.

Como cada recurso, seja este consumidor ou fornecedor de dado, é independente dosdemais e contém as suas próprias dependências para realizar a computação, uma thread é criadapara 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 bancode dados e a DHT. Este gerenciador é responsável por obter os dados dos diferentes módulos earmazenar 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 novoprocesso. 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 dosistema de acordo com a AS estabelecida. Esta implementação está disponível em domíniopúblico1.

A AS proposta visa atender alguns requisitos considerados como não funcionais, porémnão menos importante, como escalabilidade e flexibilidade. Logo, a infraestrutura a ser utilizadapara implementação deve ser robusta para atender os diversos sistemas que a utilizarão, alémda maciça quantidade de dados. Além disto, como a AS proposta contém vários componentesindependentes, a infraestrutura deve proporcionar o deploy de componentes/adaptadores sem queos 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 paraaplicaçõ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 deaplicações modulares, usando princípios de SOA para implementar o desacoplamento entrecomponentes. A tecnologia OSGi aproveita a modularização na plataforma Java, que permiteinstalar, atualizar, para iniciar, parar e desinstalar componentes em tempo de execução sem anecessidade de reinicialização do sistema. A plataforma OSGi é composta por um conjunto deespecificações, conduzido por um consórcio de empresas. As especificações são realizadas pordiferentes implementações como o Apache Felix3, Equinox4 e Knopflerfish5 GAMA; DONSEZ(2010).

No contexto deste trabalho, a plataforma OSGi foi utilizada para proporcionar maior mo-dularidade, escalabilidade e facilitar a manutenção de componentes. Dentre as implementaçõesde OSGi, foi escolhida o Equinox, pela familiariade com o arcabouço Eclipse6. Cada compo-nente da AS foi implementada utilizando um bundle, que representa um conjunto de classes

1https://github.com/gustahrodrigues/Synaptic2http://www.osgi.org3http://felix.apache.org4http://www.eclipse.org/equinox5http://www.knopflerfish.org6https://www.eclipse.org/

70CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTESBASEADA NA INTERNET DAS COISASJava, geralmente empacotados como “jar”. A Figura 4.7 ilustra a organização dos bundles querepresentam a implementação dos respectivos componentes, do ponto de vista de implementaçãosobre 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 umadaptador 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ávelpela 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 descritospreviamente.

Já no módulo MGDD, a implementação do padrão publisher-subscriber foi realizadautilizando o serviço oferecido pelo próprio OSGi Equinox denominado EventAdmin. O EventAd-

min 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 osfornecedores 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 Canalde 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 umbanco 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 dadospara gerenciá-lo e oferecê-lo aos demais componentes da AS. Caso um novo banco de dadosseja inserido, basta plugar o respectivo bundle sobre a plataforma OSGi Equinox e registrá-lo naDHT 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 dessa7http://www.json.org/8https://code.google.com/p/google-gson/9http://restlet.org/

10http://www.mongodb.org/11http://aws.amazon.com/

71 4.7. VISÃO COMPONENTE CONECTOR

infraestrutura.

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

Requisito ConfiguraçãoHardware

Plano Amazon AWS Amazon EC2 - Free TierMemória RAM 613Mb

SoftwareAmazon Machine Image (AMI) amzn-ami-pv-2012.09.0.x86_64-ebsSistema Operacional Linux Amazon (Red Hat)Restlet Versão 2.4.1GSON Versão 2.2.4MongoDB Versão 2.4.6Servidor 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 provedorespara obter melhor desempenho da AS, como por exemplo, Amazon Dynamo DB12 e AmazonElastic Map Reduce13.

4.7 Visão Componente Conector

Esta seção se refere ao comportamento dos componentes em tempo de execução e seusconectores, que são responsáveis pela comunicação entre estes. A Figura 4.8 ilustra o diagramade 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 pelosdemais módulos da AS. No próprio MGR, estes componentes são utilizados pelos módulos deConfiguração e Gerenciamento de Recurso. Os dados que trafegam na AS são representadospelo 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 quefornece e recebe dados da arquitetura. Esta comunicação é realizada a partir do outro componenteREST.

O MGDD contém uma porta para cada canal de dado. Esta porta é uma abstração paraa comunicação realizada com os diversos Recursos consumidores ou fornecedores de dados.

12http://aws.amazon.com/dynamodb/13http://aws.amazon.com/elasticmapreduce/

72CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTESBASEADA NA INTERNET DAS COISASAlé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 paracada recurso associado à um canal.

Por sua vez, o MPDD possui conectores associados aos módulos MGR e MGDD paraque as informações trafegadas nestes dois módulos possam ser armazenadas para a predição deeventos 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.9ilustra 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óduloque é mais utilizado pelos demais é o MGR. Este fato deve-se ao fato dos componentes Recursoe Dado estar logicamente declarados no MGR. Logo, o MGDD depende do MGR para interagircom 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-seao fato do MAC ser a porta de entrada e saída dos sistemas externos com a AS. Logo, para queum recurso consiga receber de fato os dados é necessário utilizar os mecanismos providos peloMAC.

Assim como no diagrama de Componentes Conectados, o MPDD possui dependênciacom os módulos MGR e MGDD para que as informações trafegadas nestes dois módulos possamser 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 cidadese mantenham seus usuários atualizados sobre os acontecimentos. Por exemplo, uma aplicaçãoque identifique os pontos de alagamento em uma avenida ou registre regiões afetadas pela faltade energia.

Do ponto de vista da arquitetura proposta, esta proposta deveria ser implementada daseguinte forma. Um recurso, correspondendo à aplicação, deve realizar todas as interações coma 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étodooferecido pelo MAC, provendo as devidas informações do recurso.

Em seguida, este recurso deve consultar a “DHT Canais de Dados” para obter as referên-cias para todos os canais que oferecem as informações relevantes da respectiva cidade. Após seinscrever nestes canais, assim que um novo dado é disponibilizado, a aplicação deve recebê-los apartir de consultas REST. De posse destes dados, a aplicação pode exibi-los da maneira maisadequada.

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

As companhias de gerenciamento de trânsito das cidades podem utilizar esta arquiteturapara emitir informações de trânsito da cidade. Para isso, basta registrar cada sensor como umrecurso 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 seinscrever nos canais nas quais estão informações serão fornecidades. A partir disto, este recursodeve 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 recursosespecíficos para as reais demandas da cidade. Para isso, uma vez que os dados dos problemas dacidade estejam trafegando pelos diferentes canais do MGDD, basta um recurso, representando osistema da secretaria se inscrever nestes canais.

A medida que um dado é disponibilizado, este recurso pode consolidar estas informaçõesem forma de gráfico ou até mesmo notificar os respectivos responsáveis, além de estimar o custopara 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. Paraisto, 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 quepermite inferir conhecimentos a partir destas informações, por exemplo, usando uma técnica deRede Neural. Estas informações contextualizadas devem ser fornecidades em outro canal paraque outros recursos possam utilizá-las para alguma outra finalidade.

Em seguida, um recurso consumidor de dado deve se inscrever neste canal que está forne-cendo essas informações contextualizadas e consolidá-las no sistema de predição de catastrófes.


4.10 Discussão do Capítulo

O conjunto de cenários descrito constitui exemplos de utilização da AS. Por ser umaAS para propósito genérico, esta pode ser facilmente adaptada para os contextos locais de cadaregião. Pode-se imaginar diversos cenários de utilização, desde uma região litorânea utilizar aAS para executar programas de balneabilidade até o controle de obesidade dos idosos de umaregião.

Além desta flexibilidade em relação ao propósito da AS, pode-se facilmente identificarque esta proposta é flexível em termos de aplicabilidade. Por exemplo, inicialmente concebidapara ser aplicada em uma cidade, esta AS pode ser implementada em diversas escalas, como umprédio (Smart Build) e residências (Smart Home).

A partir desta flexibilidade, governos e instituições podem usar esta AS para criar váriasinstâncias federativas, como por exemplo, uma instância para região de Sorocaba, outra paraCampinas 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 suficientespara 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 eperformance.

Logo, esse quesito prático não pode ser considerado suficiente para a avaliação daproposta. Dessa forma, o Capítulo seguinte descreve um método para avaliação da AS proposta,ressaltando os resultados obtidos ao aplicá-lo.


Este Capítulo iniciou-se apresentando o sub-conjunto de requisitos abordados nestaproposta na Seção 4.1. Para guiar a descrição desta proposta, a Seção 4.2 apresentou o métodode descrição de AS’s utilizado, conhecido como “4+1”, que, quando combinado com duas outrasvisõ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 Com-ponente 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 frequentementerealizadas. Por sua vez, a visão de Execução mostrou o mapeamento dos componentes lógicosem processos e threads. A Visão de Implementação apresentou a implementação de referênciaque foi realizada e está disponível ém domínio público14. A Visão Física relatou algumascaracterísticas de hardware utilizadas para está implementação de referência. Por fim, as duasvisões definidas pelo SEI foram descritas para facilitar a compreensão pelos stakeholders.

14https://github.com/gustahrodrigues/Synaptic


Ao término das descrições das Visões, pode-se compreender as responsabilidades e acomunicação entre os seis módulos da AS proposta. O módulo MCA corresponde ao pontode comunicação da AS com os sistemas externos. Já o MGR corresponde à manutenção dosrecursos na AS, principalmente ao cadastro e configuração dos mesmos. Por sua vez, o móduloMGDD é responsável por difundir os dados de/para os recursos na AS. Finalmente, o móduloMPD é 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ãosdas 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 proldo 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.

777777

5Avaliaçã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 im-portante ferramenta para quantificar a qualidade de um software a partir da sua descrição ASKAZMAN et al. (1994). De fato, alguns experimentos industriais mostraram que a aplicação demé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 ASem grandes empresas, como AT&T1 e Lucent Technologies2. Maranzano2005 demonstram que ouso de tal abordagem nestas empresas gerou um ganho de cerca de 1 milhão de dólares em cadaprojeto que teve seus problemas identificados e resolvidos previamente.

Sendo assim, podemos concluir que tão importante quanto definir a arquitetura de umsistema de software é tentar realizar uma avaliação do que foi definido, com o objetivo deidentificar as falhas antes que se tornem grandes problemas no futuro. Logo, a partir da descriçãode 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 dispo-níveis na literatura (Seção 5.1). Ao analisar esses métodos, foi concluído que nenhum delesatendia o contexto deste trabalho. Logo, a Seção 5.2 propõe uma adaptação de dois métodos deavaliação de AS’s amplamente aceitos e validados na literatura ROY; GRAHAM (2008): SAAMKAZMAN et al. (1994) e ATAM KAZMAN et al. (1999, 2000). Posteriormente, será discutidoo 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 principaisquestões que surgiram durante a avaliação desta AS. Além disso, a Seção 5.5 discute as principaisameaças à avaliação realizada.

1http://www.att.com/2http://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 dosresultados 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 melhormaneira para garantir a qualidade do produto final CLEMENTS (2003). Dessa forma, é desuma importância que a avaliação da qualidade do software seja iniciada antes mesmo daimplementação, para que possíveis erros arquiteturais sejam identificados e corrigidos a fim deminimizar custos.

Para realizar tal procedimento, um método de avaliação é utilizado para guiar os procedi-mentos de execução e auxiliar na interpretação dos resultados. Embora os métodos de avaliaçãode AS possam variar quanto às técnicas que utilizam, pode-se dizer que, de uma maneira geral, osmétodos possuem um propósito em comum KAZMAN et al. (2005). Este propósito é: investigarse 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 emcená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 contextosde 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 foiestabelecido. Para filtrar esse conjunto de métodos, a primeira condição a ser utilizada foi osatributos 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 adotarmétodos que compreendem vários atributos de qualidade. A Tabela 5.1 apresenta os métodosencontrados, nas referências relatadas anteriormente, que satisfazem esse pré-requisito.

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

Método Atributo de QualidadeSAAM Modificabilidade e funcionalidade, mas pode ser adaptado para outrosATAM Vários Atributos de QualidadeSBAR Vários Atributos de QualidadeSACAM Vários Atributos de QualidadeDoSAM Vários Atributos de Qualidade

Um outro fator que deve ser levado em consideração no momento de escolher qualmétodo de avaliação utilizar é o objetivo do método CLEMENTS (2003). Logo, a Tabela 5.2apresenta 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 ObjetivoSAAM Adequação arquitetural e identificação de riscosATAM Foco em sensibilidade da arquitetura e análise trade-off

SBARAvaliar arquiteturas legadas a partir de reengenharia, utilizando DomainSpecific Software Architecture, para criar uma base reutilizável e flexível

SACAM Comparação com outras arquiteturas de software descritas na literaturaDoSAM 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 utilizadopois 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 sercomparada 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 brevedescriçã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 sim-ples que pode ser adaptado à diferentes contextos. Inicialmente proposto para serutilizado para analisar modificabilidade e funcionalidade, o SAAM é amplamenteutilizado nos demais atributos de qualidade, tais como portabilidade, extensibilidadee integrabilidade QUN-LI; JIE (2008).

O método SAAM inclui 6 atividades: (i) desenvolvimento dos cenários; (ii) descriçãoda AS avaliada; (iii) classificação e priorização dos cenários; (iv) avaliação doscenários individual e indireta; (v) interação entre os cenários; (vi) avaliação globaldos cenários KAZMAN et al. (1994).

Algumas das principais vantagems do SAAM são a melhoria na documentação daAS 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ãobem uma AS satisfaz os requisitos de qualidade desejados, além de identificar osriscos arquiteturais e os conflitos (trade-offs) existentes para se alcançar tais requisitosQUN-LI; JIE (2008).

O ATAM inclui 4 atividades principais: (i) Descrição: apresentação do ATAM, dosobjetivos de negócios e da AS; (ii) Investigação e Análise: geração dos atritos dequalidade utilizando utility tree; análise das abordagens arquiteturais; brainstorm e


priorização dos cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentação dosResultados KAZMAN et al. (1999, 2000).

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

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

Apesar dos dois métodos restantes serem os mais adequados para a AS proposta, ocontexto de aplicação do método não condizia com o contexto deste trabalho, devido as seguintespeculiaridades:

� A equipe de avaliação estava distribuída geograficamente, com rotinas e compromis-sos 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 temasde pesquisa que envolvem esta proposta (CI e IoT);

� Não foi encontrada nenhum método de avaliação para o contexto de equipes distri-buída geograficamente;

� Como as reuniões seriam realizadas por Skype, as reuniões deveriam ser curtas paramanter a equipe concentrada.

Logo, surgiu a necessidade de propor uma adaptação dos dois métodos a fim de sanaressas peculiaridades. Esta adaptação é baseada no SAAM e ATAM, porém as atividades sãoespecí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 orespectivo contexto. A Tabela 5.3 apresenta as 10 etapas do método adaptado.

Tabela 5.3: Etapas do método adaptado

1º Apresentação do Processo de avaliação2º Apresentação dos Objetivos de Negócios3º Apresentação da AS4º Priorização dos QAs5º Contextualização sobre cenários6º Apresentação dos cenários7º Priorização dos cenários8º Avaliação dos cenários propostos9º Avaliação das interações entre Cenários e QAs

10º Consolidação dos Resultados

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

5.2.2 Equipe de Avaliação

A primeira etapa para a definição do método de avaliação a ser utilizado foi a escolhada equipe de avaliação. Devido ao fato de que CI pode ser considerado um sistema de sistemasheterogê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 asdiscussões, pois cada um avalia o mesmo quesito por diferentes pontos de vista, baseado nosrespectivos 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 noprocesso 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 mesmoenvolvido pode ter mais de uma expertise.

Tabela 5.4: Expertises da equipe de avaliação

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

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

Inicialmente o processo de avaliação deve ser descrito, ressaltando principalmente quaisos artefatos esperados de cada etapa. Em seguida, como recomenda o SAAM, um participanteda equipe de avaliação com a visão de negócio deve apresentar as expectativas de uma AS paraCI que combine IoT. Esta etapa é de suma importância, pois estas expectativas serão utilizadaspara 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, oarquiteto pode utilizar o método de descrição arquitetural que lhe interesse. Entretanto, estemétodo deve fornecer subsídios suficientes para o completo entendimento da AS por parte dosdemais participantes, incluindo interações entre os módulos, regras de negócios e o ciclo de vidados componentes KRUCHTEN (1995).

Em seguida, deve-se realizar a etapa de priorização dos atributos de qualidade com basenos objetivos de negócios, previamente discutidos. Para tal, recomenda-se que o arquiteto sugiraum conjunto de atributos de qualidade pré-selecionados que possam ser empregados. A literatura


apresenta alguns métodos de priorização dos atributos de qualidade, porém o mais usual éestabelecer que cada participante possui 3 votos que deve ser distribuído dentre os atributos dequalidade. Após todos os participantes votarem, os atributos de qualidade que receberem maisvotos devem ser considerados mais prioritários.

A contexualização sobre o que são cenários para toda a equipe de avaliação deve serrealizada a seguir. Um cenário, neste contexto, ilustra os tipos de atividades que um sistemadeve 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 queo desenvolvimento desses cenários é crucial para capturar os principais usos do sistema, seususuários, antecipar mudanças no sistema, e qualidades que o sistema deve satisfazer agora e nofuturo. Estes cenários devem ser elicitados por todos os stakeholders do sistema a partir dosobjetivos de negócios, logo, representam questões sob diferentes pontos de vista e, na maioriadas vezes, trazem informações bem específicas do sistema avaliado.

Antes da próxima etapa deste processo de avaliação é importante criar algum mecanismopara que os participantes possam propor os possíveis cenários. Uma técnica que pode serutilizada é 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, oarquiteto deve consolidar os cenários propostos. Esta consolidação resume-se em filtrar oscená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 serapresentados, para que os demais participantes conheçam os diferentes pontos de vista. Emseguida, todos devem priorizar os cenários de acordo com a relevância para a AS proposta. Estapriorizaçã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 criarum mecanismo para que seja realizada remotamente. Um exemplo é a criação de um formulárioonline na qual cada participante deve dar uma nota para o quão cada cenário está contempladopela AS.

Feito isso, na etapa seguinte o arquiteto deve conduzir uma discussão a respeito dasinterferê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, masmuito 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. Nestaetapa é 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 doprocesso executado, foram identificados.

83 5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

5.3 Processo de Avaliação Executado

A partir da descrição do processo de avaliação na Seção anterior, o processo foi executadoremotamente 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 econtextualizar 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 des-crito a origem da adaptação dos métodos, ressaltando as principais diferenças comos métodos disponíveis na literatura. Consequentemente, o processo de avaliação aser utilizado foi descrito. O objetivo desta etapa foi situar todos os envolvidos emrelaçã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 passofoi importante para que os participantes da avaliação entendessem o contexto dosistema e também as limitações técnicas, econômicas e de cronograma existentespara a execução do projeto. Todos esses aspectos foram apresentados para ajudar nadefiniçã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 detalhadapelo 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 foidetalhado, 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. Estaapresentação foi de suma importância para os participantes perceberem como osrequisitos foram implementados para avaliar se de fato eles satisfazem as necessidadesdos contextos de CI. Além disso, por meio desta descrição detalhada é possívelidentificar possíveis falhas e/ou pontos de melhoria na AS proposta;

d) Priorização dos Atributos de Qualidade (Duração 1hora): Como alguns partici-pantes não estavam acostumados ao conceito de Atributos de Qualidade, inicialmentefoi descrito o que são e quais os objetivos dos mesmos. Em seguida, o arquitetoapresentou os atributos de qualidade definidos pela ISO/IEC 9126 ISO/IEC (2001) epelo CMU/SEI-95-TR-021 BARBACCI et al. (1995), com o objetivo de exemplificarpossíveis atributos de qualidade aplicáveis à AS proposta.


Ao término dessa etapa, os participantes sugeriram alguns atributos de qualidade,com base nos objetivos de negócios. Em seguida, foi realizado uma votação parapriorizar quais os atributos melhor expressam os objetivos de negócios, apresentadosanteriormente. Nesta votação, cada participante poderia distribuir 3 votos entre osatributos de qualidade. Cada voto foi computado individualmente a partir de umformulário online disponibilizado para cada envolvido. A Tabela 5.5 exibe o resultadodesta 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

# QA Fonte Votos1º Confiabilidade ISO/IEC 9126 e CMU/SEI-95-TR-021 42º Funcionalidade ISO/IEC 9126 33º Escalabilidade Participantes 24º Portabilidade ISO/IEC 9126 15º Disponibilidade Participantes 16º Segurança CMU/SEI-95-TR-021 17º Performance CMU/SEI-95-TR-021 18º Eficiência ISO/IEC 9126 19º Usabilidade ISO/IEC 9126 1

10º Acoplamento CMU/SEI-95-TR-021 011º Manutenabilidade ISO/IEC 9126 0

As definições consideradas para os atributos foram:

� Confiabilidade: visa avaliar se a arquitetura estará disponível quandonecessário;

� Funcionalidade: conjunto de atributos que evidenciam a existência deum conjunto de funções e suas propriedades especificadas. As funções sãoas que satisfazem as necessidades explícitas ou implícitas;

� Escalabilidade: capacidade que um sistema possui de se expandir, deforma a permitir o atendimento das necessidades pelo crescimento donúmero de usuários do sistema, ou também pelo aumento das informaçõesa serem processadas;

� Portabilidade: capacidade do sistema ser transferido de um ambientepara outro;

� Disponibilidade: refere-se ao conjunto de atributos que interferem naprobabilidade de que um sistema esteja funcionando e pronto para uso emum dado instante de tempo;

85 5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

� Segurança: refere-se ao conjunto de propriedades da arquitetura queinterferem diretamente na garantia da integridade dos dados da aplicaçãoe no acesso aos mesmos;

� Performance: visa quantificar se a arquitetura computará os dados emtempo hábil, coerente com o contexto da requisição;

� Eficiência: conjunto de atributos que interferem diretamente nos temposde resposta de um sistema;

� Usabilidade: conjunto de atributos que evidenciam o esforço necessáriopara se poder utilizar o software, bem como o julgamento individual desseuso, por um conjunto explícito ou implícito de usuários;

� Acoplamento: refere-se ao grau de dependência entre os componentes desoftware;

� Manutenabilidade: atributos do software que evidenciam o esforço ne-cessá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 primeirareunião, foi a contextualização sobre cenários. Da mesma forma como os atributos dequalidade, inicialmente foi realizada uma breve apresentação sobre o que são e quaisas 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 pudessemdetalhar os cenários de utilização da AS com base nos objetivos de negócios. Paraisso, um prazo de 4 dias foi estipulado para que todos os participantes descrevessemos 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 orisco dos participantes esquecerem algum tópico abordado.

Após os 4 dias estipulados para que todos os participantes descrevessem os cenários, oarquiteto consolidou todos os cenários. Esta consolidação resumiu-se em, basicamente, filtraros cenários duplicados e reescrever alguns com outras palavras para facilitar a compreensãodos demais participantes. Apenas 2 cenários foram considerados duplicados e 1 precisou serreescrito.

a) Apresentação dos Cenários (Duração 30min): Nessa primeira etapa da segundareunião, foram apresentados todos os cenários propostos pelos participantes daavaliação no prazo estipulado. Como vários participantes possuem diferentes visões e


experiências, foram identificados diferentes nichos de aplicabilidade da AS proposta,por exemplo, em contextos totalmente distribuídos ou, até mesmo, em contextosfederados.

b) Priorização dos Cenários (Duração 1hora): A segunda etapa foi uma discussãoconduzida pelo arquiteto na qual o objetivo era a priorização dos cenários. Essadiscussão foi guiada pelo arquiteto, na qual cada cenário foi discutido e um peso derelevância foi atribuído para cada cenario. Essa priorização levou em consideraçãoos 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 prio-rizados foram avaliados e discutidos sobre a AS proposta. O principal objetivo foiavaliar 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, ordenadosde 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 umasemana depois. O objetivo primordial dessa reunião foi consolidar os resultados e definir aspossí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 ordemde priorização. O objetivo deste formulário foi de mensurar quantitativamente o quão a AScontempla cada cenário.

a) Avaliação das interações entre Cenários e Atributos de Qualidade (Duração1hora): Nesta primeira etapa da reunião, os participantes discutiram o quão oscenários priorizados conflitavam com os atributos de qualidade.

b) Consolidação dos Resultados (Duração 1hora): Nesta etapa os resultados foramapresentados. Primeiramente, um overview sobre cada artefato gerado durante oprocesso foi apresentado, principalmente a priorização dos atributos de qualidade eos 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 ASrealizado.

5.4 Resultados da Avaliação da Arquitetura

Um dos benefícios de se realizar qualquer avaliação de Arquitetura de Software (AS) é amelhoria de comunicação entre os stakeholders, resultando em um melhor entendimento dosrequisitos.

87 5.4. RESULTADOS DA AVALIAÇÃO DA ARQUITETURA

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

ID Cenário

C1Armazenar dados fornecidos por diferentes contextos e provedores,

independente do formato e da natureza do dado

C2Consultar dados oriundos de um provedor de dado, independente de

quando esse dado foi gerado

C3Permitir que novos tipos de informações sejam fornecidas, a partir da

combinação de uma ou mais fontes de dadosC4 Permitir a inclusão de novos provedores de dados

C5A AS deve auxiliar a interoperabilidade entre sistemas, na qual um

evento gerado externamente pode disparar ações

C6A 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çõesexternas

C7 A AS deve permitir a comunicação via API

C8A 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

C9 Fornecer algum mecanismo para tolerância a falhas (redundância)

C10Permitir a criação e comunicação de instâncias federativas, baseada em

serviços

C11Possuir mecanismo para a inclusão de novos protocolos de comunicação

na AS

C12Plugar novas soluções para diferentes contextos utilizando a mesma

infraestrutura

C13Suporte a serviços em Cloud Computing já existentes (Ex.: Google

Analytics e cloud storage)

C14Gerenciar 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 aAS contempla cada cenário, foi criado um formulário online com todos os cenários, ordenadospor ordem de priorização. Neste formulário, cada participante deveria atribuir uma nota paraa adequação de cada cenário, na qual 5 representa que a AS ATENDE TOTALMENTE e 0significa que NÃO ATENDE ao cenário em questão.

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

5.4.1 Resultados da Avaliação dos Cenários

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


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áriospropostos, priorizados durante o processo de avaliação.

Como é possível notar, na opinião dos participantes, a AS atende à três cenários demaneira EXCELENTE. O primeiro cenário (C2) é relacionado aos mecanismos de distribuiçãode 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 consumidorese 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 imple-mentação do padrão publisher-subscriber também no MGDD. Esta implementação permite queum dado seja disponibilizado para todos os recursos consumidores assim que é produzido. Nocontexto de CI, esta característica básica é de suma importância se todos os consumidores recebe-ram os dados simultâneamente e está contemplada nesta proposta. Além disso, o desacoplamentoentre 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 daflexibilidade implementada no MAC (Seção 4.3.1). Esta abstração permite que novos protocolosde 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 daavaliação. Embora este resultado indique que a AS, em uma primeira instância, atende a umconjunto de contextos de utilização, ela deve ser aprimorada para atender de maneira segura eeficiente 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 nenhummecanismo 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 algummó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émdisso, estratégias de backup, controle de acesso e demais aspectos relacionados à confiabilidadeda proposta devem ser investigadas.

O outro cenário que foi classificado como PÉSSIMO (C14) corresponde às políticasde privacidade de dados utilizadas pela AS. Conforme pôde ser verificado, este requisito nãofaz 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 trabalhode privacidade será acoplado à esta proposta assim que finalizado. Para isso, as definições deinterfaces 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ãospossam “negociar” o quão seus dados estarão disponíveis para um determinado provedor deserviço urbano.

5.4.2 Resultados Gerais

Esta sub-seção visa elencar os resultados gerais obtidos a partir do processo de avaliaçãoexecutado. Estes resultados foram extraídos a partir das discussões com os participantes e nãonecessariamente são observados nos artefatos do processo.

Primeiramente, o fato de dois de três cenários categorizados como EXCELENTE estaremdiretamente relacionado ao MGDD era esperado. O MGDD pode ser considerado o core daproposta, 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 paraesta proposta. Além disso, a alta quantidade de requisitos que o MGDD visa satisfazer representaos principais diferenciais desta proposta com as demais.

Este fato alerta para possíveis problemas relacionados ao acoplamento do MGDD como restante da AS. Por exemplo, deve-se prever e criar mecanismos para mitigar os possíveisproblemas no MGDD relacionados à indisponibilidade da DHT Canais de Dados. Caso issoaconteça, os demais módulos devem continuar funcionando corretamente a partir de mecanismosde redundância.

Além disso, de acordo com os participantes, não é necessário descrever um novo padrãoarquitetural para o contexto de CI e IoT. Esta conclusão foi obtida a partir da avaliação de que aproposta 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 umcontexto real, para, de fato, verificar a adequação da AS ao contexto de CI e IoT. Logo, comotrabalho futuro, a proposta atual será implantada em um ambiente real por meio de parceriascom 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 seranalisadas para trabalhos futuros.

A primeira ameaça está relacionada à quantidade de pessoas envolvidas no processode avaliação. Por mais que a equipe tenha várias expertises diferentes englobando várias áreasde uma cidade, como recomendado por clements2003documenting, se mais pessoas tivessemparticipado da avaliação outros pontos de vistas poderiam ser levantados. Infelizmente, estepequeno número de participantes foi devido à disponibilidade do grupo de pesquisa para arealização das três reuniões mencionadas.


A outra ameaça está relacionada com a ordem das etapas do método de avaliação.Como apresentação da arquitetura foi realizada antes da definição e priorização dos atributosde 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 foiressaltado 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.


Este Capítulo iniciou-se apresentando os filtros aplicados nos métodos de avaliaçãodisponíveis na literatura Seção 5.1. Estes filtros foram aplicados de acordo com o contexto daavaliaçã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, aSeção 5.2 propôs uma adaptação destes dois métodos de avaliação de AS’s amplamente aceitos evalidados 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 implan-tada em um contexto real. Dessa forma, o próximo Capítulo finaliza o trabalho descrevendoas principais conclusões e as atividades futuras, como implantar a AS em um ambiente real econtrolado.

919191

6Conclusã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, algumasconclusões e direções para trabalhos futuros podem ser apontadas.

Desta forma, este Capítulo apresenta as conclusões finais deste trabalho e está organizadoda 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 trabalhosfuturos, 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 re-lacionados 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 edificultam o gerenciamento das cidades pelos gestores (Seção 1.1).

� Apesar da evidente necessidade de cidades cada vez mais inteligentes, ainda nãohá 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 comoferramenta para a implementação, de fato, de uma CI. Neste contexto, as tecnologiasIoT são utilizadas, principalmente, para monitorar, controlar e atuar sobre os diversosserviços urbanos (Capítulo 2).

92 CAPÍTULO 6. CONCLUSÃO

� 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 deserviç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 ASimplementa um padrão arquitetural bastante conhecido na literatura chamado depublisher-subscriber (Capítulo 4).

� Para avaliar a AS proposta, dois métodos de avaliação arquitetural foram adaptadospara o contexto deste trabalho. Esta adaptação mostrou-se bastante útil, uma vez queos principais benefícios citados na teoria, tais como composição de dados urbanos,foram confirmados (Seção 5.4).

6.2 Trabalhos Relacionados

Em livingPlanIT foi adotada uma estratégia de implementar um Sistema OperacionalUrbano (UOS). Este sistema operacional consiste em uma plataforma que visa integrar cadadomínio que compõe a cidade. O sistema é alimentado por uma vasta rede de sensores e todosesses dados são capturados por tempo indeterminado, para auxiliar na tomada e na predição dedecisões. Além de prever catástrofes, caso ocorra, o sistema pode antever todos os possíveisimpactos na cidade. As principais diferenças da abordagem de livingPlanIT e esta proposta são aparceria com setor privado (livingPlanIT possui uma parceria com Cisco e Microsoft) e o modelode distribuição de dados, uma vez que no modelo adotado em livingPlanIT a disponibilização deum 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 naAS é superior à 12.000. O SmartSantander provê: i) um modelo de refência de arquiteturapara sistemas IoT do mundo real; ii) um escalável, heterogêneo e confiável facilitador deexperimentos; iii) um conjunto representativo de casos de uso implementados para facilidades deexperimentaçã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émda parceria com o setor privado, são os mecanismos que permitem a composição de dadosurbanos. Na proposta deste trabalho, assim que um dado novo é disponilizado, permite-se acriação de um novo canal para este dado. Além disto, esta proposta contempla mecanismos degereçã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 umaAS baseada em eventos, na qual cada evento corresponde à mudança de estado de qualquersistema de TIC. Estes eventos podem ser iniciados a partir de eventos do mundo real (comodetecçã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 principaldiferença é a existência nesta proposta de um mecanismo para geração de histórico para a previsãode futuros eventos. Além disto, as informações de cada sensor que está fornecendo os dados podeser utilizada para otimizar o desempenho dos algoritmos SHAO (2011); HERNáNDEZ-MUñOZet al. (2011); VEGA-BARBAS et al. (2012).

Neste sentido, em Hernandez-2011 é proposta uma AS (USN), com o objetivo de proveruma infraestrutura que seja capaz de integrar sensores heterogêneos e dispersos geograficamenteem um base centralizadora, na qual serviços podem ser facilmente desenvolvidos. Esta aborda-gem de Hernandez-2011 é similar a esta proposta nas técnicas adotadas para permitir a integraçãode sensores heterogêneos. A principal diferença é que nesta proposta novos protocolos de trocade mensagens podem ser facilmente inseridos. Além disto, o custo para integrar diferentesfornecedores 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ípiocorresponde à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çõeseconomicamente viáveis. O terceiro princípio é o gerenciamento de processos no qual relaciona-mentos, 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 osoutros três princípios. A principal diferença da abordagem de Components-2009 para estaproposta é a criação de um componente específico para modelos de negócio. Este diferencialpode ser facilmente incorporado nesta proposta, uma vez que este componente poderia ser umconsumidor de dado que, a partir dos dados que estão trafegando na arquitetura, inferir ummodelo de negócios eficaz com estas informações.

Ao analisar os principais trabalhos relacionados, pôde-se observar que todos visam miti-gar apenas uma deficiência tecnológica relacionada à CI. Apenas a abordagem de livingPlanITvisa integrar as informações provenientes de diferentes domínios de uma cidade, o que podecontribuir para tornar uma cidade de fato inteligente.

Além disto, o conjunto de requisitos que esta proposta contempla é superior à todos ostrabalhos relacionados. Apesart deste conjunto de requisitos ter sido definido juntamente comesta 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 analisouo estado da arte e da prática no tocante as AS’s de software para CI que combinam tecnologiasIoT. 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 daAS, (iv) a avaliação preliminar da AS e (v) uma implementação de referência.

94 CAPÍTULO 6. CONCLUSÃO

6.3 Trabalhos Futuros

A versão inicial desta AS não contempla algumas características, principalmente asquestões relatadas na Seção 1.4, e os resultados da avaliação da AS:

� Utilização em Ambiente Real: A proposta atual será implantada em um ambientereal a partir de parcerias com empresas e prefeituras. Certamente essa etapa vaicontribuir 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 imple-mentadas para que os serviços urbanos não sejam afetados devido a uma eventualfalha em algum ponto da AS;

� Políticas de privacidade: Já que vários dados pessoais dos cidadãos trafegarão pelaAS, torna-se indispensável a adequação de políticas de privacidade, principalmenterelacionadas ao armazenamento, utilização e descarte dos dados;

� Modelo de Negócio: Modelos de negócios devem ser discutidos para suprir os custosenvolvendo 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 autilização desta AS;

� Análises de big data: Com o alto volume de dados potencialmente gerado a partir dautilização desta AS, análises de big data devem ser feitas para otimizar o desempenhodos serviços urbanos;

� Semântica dos Dados: Futuras pesquisas podem investigar a melhor estratégia desemântica dos dados a ser implementada nesta proposta.

6.4 Conclusão

A necessidade de cidades cada vez mais inteligentes é notoriamente crescente. Váriosdados publicados pela mídia em geral comprova que o crescimento populacional não está alinhadocom o desenvolvimento das infraestruturas e dos principais serviços urbanos. A precariedadedestes serviços urbanos afeta negativamente a qualidade de vida dos cidadãos.

Logo, torna-se fundamental o investimento em estratégias que visam mitigar estesproblemas urbanos para otimizar a vida dos cidadãos. Estas iniciativas devem ser desenvolvidasconsiderando as partes envolvidas: governo e cidadãos. Além disso, torna-se importante que oscidadã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 paraCI 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 principaisabordagens disponíveis na literatura.

979797

References

AL-HADER, M. et al. Smart City Components Architicture. In: COMPUTATIONALINTELLIGENCE, 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 commonarchitecture for urban development. In: INTERNATIONAL CONFERENCE ONINTELLIGENT ENVIRONMENTS, 6. Proceedings. . . [S.l.: s.n.], 2010. p.19–21.

ASIMAKOPOULOU, E.; BESSIS, N. Buildings and Crowds: forming smart cities for moreeffective disaster management. In: INNOVATIVE MOBILE AND INTERNET SERVICES INUBIQUITOUS 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 ofthings. 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 UniversityAmsterdam, Faculty of Economics, Business Administration and Econometrics, 2009. SerieResearch Memoranda. (0048).

CHEN, L.; ALI BABAR, M.; ALI, N. Variability management in software product lines: asystematic 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 forSmart 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 ANDCOMMUNICATIONS, 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 INTERNETSERVICES IN UBIQUITOUS COMPUTING (IMIS). Anais. . . [S.l.: s.n.], 2012. p.775 –780.

FELS, S. Sustainable communities: where does communication fit in? In: FIRSTINTERDISCIPLINARY WORKSHOP ON COMMUNICATION FOR SUSTAINABLECOMMUNITIES, 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 withheterogeneous sensors. In: INTERNATIONAL CONFERENCE ON SENSORTECHNOLOGIES AND APPLICATIONS, 4., Washington, DC, USA. Anais. . . IEEEComputer 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 theOSGi 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-MILANOVIC, N. Smart Cities: ranking of europeanmedium-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 ofThings, [S.l.], p.33, 2011.

http://www.computerworld.com.pt/2013/07/04/dossier-smart-cities/

http://www.computerworld.com.pt/2013/07/04/dossier-smart-cities/

http://bit.ly/RInZMi

99 REFERENCES

HEBERTY H. AMARAL, D. C. C.; FERNANDES, D. M. Estudo da relação entre as classessociais e o consumo de energia elétrica residencial do município de Foz do Iguaçu do estado doParaná. 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 aWireless Sensor Network. In: INTELLIGENT ENVIRONMENTS (IE), 2012 8THINTERNATIONAL 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 ComputerSociety Press, 1994. p.81–90. (ICSE ’94).

KAZMAN, R. et al. Experience with performing architecture tradeoff analysis. In: SOFTWAREENGINEERING, 1999. PROCEEDINGS OF THE 1999 INTERNATIONAL CONFERENCEON. 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. SoftwareQuality 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 challengesfrom an industrial perspective. In: INT. CONF. NEW2AN AND 1ST RUSSIANCONFERENCE ON SMART SPACES, RUSMART ON NEXT GENERATIONTELETRAFFIC 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 andartificial intelligence to enhance knowledge and innovation. In: IET INTERNATIONALCONFERENCE 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 platformfor 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 CommunicationsMagazine, [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 gridfeatures in a smart energy city. In: ENERGETICS (IYCE), 3RD INTERNATIONAL YOUTHCONFERENCE. Anais. . . [S.l.: s.n.], 2011. p.1–8.

MOSTASHARI, A. et al. Citizens as sensors: the cognitive city paradigm. In: EMERGINGTECHNOLOGIES FOR A SMARTER WORLD (CEWIT), 2011 8TH INTERNATIONALCONFERENCE & EXPO ON. Anais. . . [S.l.: s.n.], 2011. p.1–5.

NAM, T.; PARDO, T. Conceptualizing smart city with dimensions of technology, people, andinstitutions. In: ANNUAL INTERNATIONAL DIGITAL GOVERNMENT RESEARCHCONFERENCE: 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 urbanizationprospects. New York: United Nations, 2007.

(NIC), N. I. C. Disruptive Civil Technologies - Six Technologies with Potential Impacts onUS 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: SYSTEMATICAPPROACHES TO DIGITAL FORENSIC ENGINEERING, 2007. SADFE 2007. SECONDINTERNATIONAL 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 ofComputing TR, [S.l.], v.545, p.82, 2008.

SANCHEZ, L. et al. SmartSantander: the meeting point between future internet research andexperimentation 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 EconomicStudies).

SHAO, C. An Internet of Things Application with Location Perception Based on IMS. In:THIRD INTERNATIONAL CONFERENCE ON MULTIMEDIA INFORMATIONNETWORKING 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 ubiquitoussoftware 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 oftechnology. [S.l.]: ARUPCorp., 2011.

TOUSEAU, L.; DONSEZ, D.; RUDAMETKIN, W. Towards a SLA-based Approach to HandleService Disruptions. In: IEEE INTERNATIONAL CONFERENCE ON SERVICESCOMPUTING - VOLUME 1, 2008., Washington, DC, USA. Proceedings. . . IEEE ComputerSociety, 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 UBIQUITOUSCOMPUTING (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 ApplicationsAdaptively Based on Multi-agent and Web Service. In: MULTIMEDIA INFORMATIONNETWORKING AND SECURITY (MINES), 2011 THIRD INTERNATIONALCONFERENCE ON. Anais. . . [S.l.: s.n.], 2011. p.253 –257.

ZYGIARIS, S. Smart City Reference Model: assisting planners to conceptualize the building ofsmart city innovation ecosystems. Journal of the Knowledge Economy, [S.l.], p.1–15, 2012.

Apêndice

105105105

ARepositórios de busca na SLR

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

Nome Tipo URLIEEExplore Digital http://ieeexplore.ieee.org/Science Direct Digital http://www.sciencedirect.com/ACM Digital Library Digital http://dl.acm.org/Springer Link Digital http://link.springer.com/CiteSeerX Digital http://citeseerx.ist.psu.edu/Academia.edu Digital http://www.academia.edu/ISI Web of Science & Digital Digital http://wokinfo.com/World Intellectual PropertyOrganization (WIPO)

PatenteDigital

http://www.wipo.int

International Conference onComputational Intelligence,Modeling and Simulation(IJCCI)

Manual http://www.ijcci.org/

International Conference onIntelligent Environments (IE)

Manual http://www.intenv.org/

Multimedia InformationNetworking and Security(MINES)

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

Emerging Technologies for aSmarter World (CEWIT)

Manual http://www.cewit.org/

International Conference onInnovative Mobile and Inter-net Services in UbiquitousComputing (IMIS))

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

107107107

BAvaliação da Arquitetura de Software (AS)

file = images/proposscenarios.eps,width = 10cm

Figura B.1: Printscreen do formulário online utilizado pelos participantes para propor oscená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çãoda AS aos respectivos cenários





gustavo henrique rodrigues pinto tomas - repositorio.ufpe.br · catalogação na fonte...

Documents