uma arquitetura para cidades inteligentes baseada na internet das coisas

Universidade Federal de Pernambuco

Centro de Informática

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

Uma Arquitetura de Software paraCidades Inteligentes baseada na Internet

das Coisas

Gustavo Henrique Rodrigues Pinto Tomas

Dissertação de Mestrado

RECIFE

Fevereiro de 2014

Universidade Federal de Pernambuco

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

Gustavo Henrique Rodrigues Pinto Tomas

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

Dissertação apresentada como requisito parcial para a ob-

tenção do título de Mestre em Ciências da Computação, área

de concentração em Engenharia de Software pelo Programa

de Pós-Graduação em Ciências da Computação do Centro

de Informática da Universidade Federal de Pernambuco.

Orientador: Vinicius Cardoso Garcia

Coorientador: Alexandre Alvaro

RECIFE, Fevereiro de 2014

À minha família, por sempre me proporcionar totais

condições para a realização dos meus estudos.

Aos meus irmãos, que esta dissertação sirva de inspiração

para suas futuras decisões profissionais.

À Crisley, por sempre estar ao meu lado e me ajudar a ver o

lado bom de tudo.

Dedico.

Agradecimentos

Primeiramente gostaria de agradecer a Deus por me proporcionar todas as condiçõespara a realização deste trabalho e, principalmente, por ter colocado em meu caminhopessoas muito especiais que me ajudaram nesta aventura. Algumas destas pessoas serãobrevemente citadas 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 mantero tempo todo focado no objetivo final. Não poderia deixar de agradecer a liberdade eabertura para discutir novas ideias e definir novas metas, sem deixar de lado a qualidade dotrabalho. Os questionamentos e a experiência de outras áreas foram de suma importânciapara a concretização da proposta. A coragem em se aventurar em uma área de pesquisarecente, na qual ninguém possuía muita experiência, fatalmente separa os vencedores dosmedrosos. Além disso, a confiança em permitir, que uma parte do mestrado seja realizadaremotamente, certamente foi uma atitude de uma pessoa grande, tanto profissionalmentequanto espiritualmente.

Ao grande pesquisador e amigo Alexandre Alvaro pela ajuda e compartilhamentode suas experiências antes mesmo de iniciar o mestrado. Certamente daquele dia emdiante, você começou a ser observado com olhos de admiração. Agradeço tambémpor ter apresentado a área de pesquisa e, principalmente, as oportunidades que estavamenvolvidas. Os feedbacks do trabalho sempre contribuíram de forma muito positivamente,assim como os bate-papos, por mais “viajados” que fossem.

Ao grande irmão de consideração Welington Manoel da Silva, pelo tempo de convi-vência, pelos aprendizados deste período e, principalmente, pela paciência e bom humorpara enfrentarmos juntos toda aquela situação. Em relação à parte técnica, todos os ques-tionamentos e palpites foram fundamentais para o aprimoramento da proposta. A formapelo qual Welington compartilhou seus conhecimentos comigo certamente evidencia umadas suas principais características: compaixão com o próximo.

Agradeço a minha família pela compreensão nos dias em que fiquei trancado noquarto e nos dias de indisponibilidade para conversar por telefone. Em especial aosmeus pais Érica e Elcio, agradeço ao suporte que, por mais que não seja o que elesgostariam de proporcionar, foi muito mais do que o suficiente para a minha formação,tanto como homem quanto profissional. Ainda em relação à família, agradeço aos meusirmãos Larissa e Júnior, por aturarem o meu mau humor quando as coisas pareciam estardesabando. Sinceramente, espero que este novo objetivo alcançado na minha vida sirvade exemplo para que eles acreditem nos respectivos potenciais e, principalmente, na

vii

capacidade de atingir seus objetivos.Não poderia de deixar de fora a minha amiga, companheira, revisora de textos em

inglês e português: Crisley. A sua compaixão e o seu jeitinho singular foram as forçasque eu precisava nos momentos de maiores dificuldades. Olhando para trás, não consigoenxergar outra forma de enfrentar os meus desafios sem o seu positivismo. A compreensãoe a paciência para enfrentar 9 meses à distância certamente comprovaram que somosiguais ao amanhecer: independente do que aconteça, sempre estaremos juntos paraenfrentar qualquer tipo de escuridão.

Ao Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) pela corageme confiança em aceitar o desafio de conciliar a rotina de trabalho de 40h semanais comas disciplinas do mestrado. Nesse sentido, gostaria de agradecer imensamente os meusgestores Paulo Urbano e Roberta Hazin pela coragem, compreensão e, principalmente,por não aliviarem as minhas tarefas, o que contribuiu muito para a minha formaçãoacadêmica e profissional. Espero que eles tenham a consciência de que esse tipo deatitude afetou, e muito, positivamente a vida de uma pessoa. Certamente gestores comesse perfil deveriam ser supervalorizados nas suas atribuições. Considero a forma como asituação foi conduzida um exemplo a ser seguido na minha vida.

Finalmente, gostaria de agradecer a todos que de alguma forma, direta ou indireta-mente, contribuíram para a realização deste trabalho.

viii

Resumo

De acordo com recentes pesquisas, a população mundial esta crescendo de forma des-proporcional aos recursos necessários para a vida humana. Cada vez mais a quantidadede pessoas vivendo nas áreas urbanas aumenta, devido à diversos fatores, como asoportunidades que são geradas 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.Para exemplificar este fato, pode-se citar os grandes problemas que as cidades brasileirasenfrentam nas áreas de transporte, saúde e educação, evidenciados, rotineiramente, pelamí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 ferramentapara a implementação de uma CI é a Internet of Things (Internet das Coisas) (IoT), naqual diversos objetos são combinados para atingir um objetivo em comum como, fornecerinformações do fluxo 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 quecompõem os serviços urbanos.

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

Motivado por estes desafios, esta dissertação apresenta a especificação, o projetoe a avaliação de uma AS para CI que permite a integração com IoT, baseado no con-junto de requisitos extraídos das soluções existentes. Adicionalmente, são discutidos osresultados obtidos, os problemas encontrados, e as direções futuras para pesquisa e odesenvolvimento.

Palavras-chave: Cidades Inteligentes, Internet das Coisas, Arquitetura de Software

ix

Abstract

According to recent researches, global population is increasing disproportionally from theessential 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 generatedin these locals.

This unbridled populational growth, mainly in urban areas, and other factors such aspoor governance, leads and/or enhances many urban problems. To illustrate this fact, wecan mention the major problems that Brazilian cities face in the areas of transport, healthand education, evidenced routinely by the media in general.

In this context, the Smart City (SC) concept attempts to mitigate these problemsin order to increase the citizens quality of life. For such an important tool for theimplementation of a SC is the Internet of Things (IoT), in which several objects arecombined 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 servicesis required.

In literature we can find several architectures for SC, including support of largecompanies. However, these architectures aim to meet only an urban service with specificapplication, which features 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 aset of requirements drawn from existing approaches. Additionally, we discuss the resultsobtained, the problems found, and the future steps for research and development.

Keywords: Smart Cities, Internet of Things, Software Architecture

xi

Sumário

Lista de Figuras xvii

Lista de Tabelas xix

Lista de Acrônimos xxi

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . . 2

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

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

1.4 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Cidades Inteligentes e Internet das Coisas 92.1 Conceito de Cidade Inteligente (CI) . . . . . . . . . . . . . . . . . . . 11

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

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

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

3 Revisão da Literatura de Arquiteturas de Software para Cidades Inteligen-tes 173.1 Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . 19

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

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

3.1.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Abordagens Resultantes . . . . . . . . . . . . . . . . . . . . . 23

3.2 Revisão Exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . 26

3.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

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

3.4 Requisitos para uma Arquitetura de Software para Cidades Inteligentes . 32

xiii

3.4.1 Interoperabilidade de objetos . . . . . . . . . . . . . . . . . . . 32

3.4.2 Monitoramento em tempo real . . . . . . . . . . . . . . . . . . 33

3.4.3 Sustentabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4.4 Aspectos sociais . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.5 Ubiquidade/Mobilidade . . . . . . . . . . . . . . . . . . . . . 34

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

3.4.7 Geolocalização dos sensores . . . . . . . . . . . . . . . . . . . 35

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

3.4.9 Histórico de dados . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4.10 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

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

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

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


4 Uma Arquitetura de Software para Cidades Inteligentes baseada na Internetdas Coisas 414.1 Requisitos abordados . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Metodologia “4+1” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

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

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

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

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

4.3.5 Mapeamento Requisito x Módulo . . . . . . . . . . . . . . . . 48

4.3.6 Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

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

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

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

4.4 Visão de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

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

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

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

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

4.5 Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 54

xiv

4.6 Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.7 Visão Componente Conector . . . . . . . . . . . . . . . . . . . . . . . 57

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

4.9 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

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

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

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

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

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


5 Avaliação da Arquitetura de Software 635.1 Métodos de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.1 Métodos Analisados . . . . . . . . . . . . . . . . . . . . . . . 64

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

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

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

5.2.2 Equipe de Avaliação . . . . . . . . . . . . . . . . . . . . . . . 67

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

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

5.3.1 Primeira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3.2 Segunda Reunião . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3.3 Terceira Reunião . . . . . . . . . . . . . . . . . . . . . . . . . 73

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

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

5.4.2 Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . . 76

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


6 Conclusão 796.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Referências Bibliográficas 84

xv

Apêndice 93

A Repositórios de busca na Systematic Literature Review (Revisão Sistemáticada Liteturatura) (SLR) 95

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

xvi

Lista de Figuras

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

3.1 Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Resultado da filtragem das abordagens . . . . . . . . . . . . . . . . . . 21

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

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

B.1 Printscreen do formulário online utilizado pelos participantes para proporos cenários de uso da AS . . . . . . . . . . . . . . . . . . . . . . . . . 97

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



xvii

Lista de Tabelas

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

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

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

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

xix

Lista de Acrônimos

AS Arquitetura de Software

DHT Distributed Hash Table

IoT Internet of Things (Internet das Coisas)

CI Cidade Inteligente

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

SOA Arquitetura Orientada a Serviços

TIC Tecnologia da Informação e Comunicação

xxi

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 subiupara 50%. Estima-se que em 2050 a porcentagem de pessoas vivendo nos grandescentros urbanos será de 70%. Além disso, 10% da população mundial vive nas 30principais metrópoles (Dobbs and Institute, 2011). No cenário nacional, segundo apesquisa realizada pelo Instituto Brasileiro de Geografia e Estatística (IBGE), publicadano Diário Oficial da União 1, em julho de 2012 o Brasil chegou a 193.946.886 habitantes,que representa um aumento de aproximadamente 1,65% em relação ao ano de 2010.

A expansão das cidades enfrenta uma série de desafios. Embora as cidades ocupammenos de 2% da massa terrestre, os residentes urbanos consomem mais de três quartosdos recursos naturais do mundo e são os principais responsáveis pela emissão de gasesdo efeito estufa (Marceau, 2008). Problemas decorrentes da rápida urbanização indicamuma perda de funcionalidades básicas para ser um lugar habitável: por exemplo, adificuldade na gestão de resíduos, a escassez de recursos naturais, a poluição do ar, asdoenças humanas, o intenso tráfego de veículos e deterioração e envelhecimento dasinfraestruturas (Krco, 2010).

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

1

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

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

CAPÍTULO 1. INTRODUÇÃO

Algumas iniciativas isoladas estão sendo desenvolvidas para mitigar alguns dosproblemas urbanos (Nam and Pardo, 2011). As iniciativas vão de aplicativos como“Waze”2, um serviço que combina geolocalização no celular com indicações do fluxo eproblemas de trânsito via smartphones, até governamentais, como o Centro de Operaçõesda Prefeitura do Rio de Janeiro3, sistema que integra informações a respeito dos diferentesserviços públicos oferecidos pela 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 paracompartilhar informações, seja para facilitar a definição da estratégia de atuação (Filipponiet al., 2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011;Hernández-Muñoz et al., 2011). Da mesma forma, necessita-se de uma AS que permita acriação de novas iniciativas para solucionar os problemas dos cidadãos (Filipponi et al.,2010; Haubensak, 2011; Sanchez et al., 2011), como por exemplo, o monitoramento daqualidade do transporte coletivo.

Além disso, este trabalho é motivado pela vasta gama de sensores, atuadores, pessoas,sistemas, drivers e qualquer outro componente capaz de interagir com os serviços urbanos.Ao aplicar este conjunto de componentes nos contextos urbanos, vários desafios sãogerados para integrá-los e obter o melhor de cada componente.

Para este e outros cenários semelhantes, uma AS para CI pode ajudar a integrar essesdiversos componentes. Para tal, a AS deve ser totalmente plugável e expansível, do pontode vista 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) paraCidade Inteligente (CI) que permita o desenvolvimento de soluções com base emInternet of Things (Internet das Coisas) (IoT), independente das especificações decada tecnologia e características físicas das cidades. Além disto, este trabalho visaprover uma implementação de referência desta AS.

2https://www.waze.com/3http://www.rio.rj.gov.br/web/corio

2

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

1.3 Visão Geral da Solução Proposta

A fim de atingir os objetivos deste trabalho, estabelecidos na Seção anterior, foi realizadoum estudo das Arquiteturas de Software (AS’s) para CI baseada em IoT tanto na academiaquanto na indústria, por meio de dois métodos de revisão literária: Revisão Exploratória eRevisão Sistemática. Este estudo teve como finalidade identificar as técnicas empregadasnestas soluções e se existia a necessidade da criação de um novo padrão arquitetural paraeste 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. Emseguida, a AS da solução foi proposta visando atingir um sub-conjunto destes requisitos,que representa os requisitos fundamentais. Por fim, a AS foi submetida à um processode avaliação formal adaptado do SAAM (Kazman et al., 1994) e ATAM (Kazman et al.,1999, 2000).

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

A AS consiste em módulos que implementam um conjunto de requisitos fundamentaispara o contexto de CI. Estes requisitos são implementados a partir da utilização depadrões arquiteturais já conhecidos e utilizados em outros tipos de AS’s de software,como publisher-subscriber. A Figura 1.1 ilustra a AS proposta.

Os módulos da AS são: Módulo de Acesso e Comunicação (MAC), Módulo deGerenciamento de Recursos (MGR), Módulo de Gerenciamento e Distribuição de Da-dos (MGDD) e Módulo de Persistência de Dados (MPD). Estes módulos fornecem asfuncionalidades essenciais utilizadas pelos diferentes tipos de usuários do sistema.

O MAC representa o ponto de entrada dos usuários, aplicações ou até mesmo serviçosexternos. O MAC provê todos os mecanismos necessários para o acesso e a comunicaçãocom a AS, tanto para envio quanto para recebimento de informações. Por sua vez, oMGR visa gerenciar as informações relativas aos diferentes tipos de recursos disponíveisna AS. Já o MGDD possui a responsabilidade de disseminar os dados na AS, tanto osdados de fora para dentro da AS quanto os dados obtidos a partir de alguma computaçãointerna para os agentes externos. O último módulo (MPD), como o próprio nome jáidentifica, possui a responsabilidade de armazenar os dados oriundos dos diferentes níveisda AS. Estes dados, nos mais variados estágios da AS, são importantes para a prediçãode acontecimentos futuros, a partir do histórico de dados.

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

3


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

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 completoe fechado de funcionalidades que devem sempre estar presentes em qualquer AS paraCI. Contudo, acredita-se que os requisitos identificados podem servir como base paraa construção e/ou adaptação de uma AS para CI que combine tecnologias de IoT, tantopara coletar informações quanto para atuar no ambiente.

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

• Modelo de Negócio: Aspectos relacionados ao suporte a modelos de negócio eestratégias de monetização e cobrança desta proposta não serão tratados nestetrabalho;

• Análises de big data: Apesar da grande quantidade de dados trafegados na AS,este trabalho não faz nenhum tipo de análise de big data, apenas permite que umserviço que o faça seja criado;

• Semântica dos Dados: Este trabalho não faz distinção entre semântica dos dados,uma vez que qualquer tipo de dado relacionado à cidade pode trafegar na AS.

4

1.5. PRINCIPAIS CONTRIBUIÇÕES

1.5 Principais Contribuições

Como resultado do trabalho apresentado nesta dissertação, as seguintes contribuiçõ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;

• 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-ção inicial foi realizada e disponibilizado em domínio público. Esta implementaçãoserve de guia para a utilização desta proposta em qualquer cidade;

• Adaptação de dois métodos de avaliação: Não foi encontrado na literatura ne-nhum método de avaliação que fosse totalmente compatível com as peculiaridadesdo contexto 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 sepôde comprovar a sua utilidade. Este método pode ser empregado em qualquercontexto semelhante, 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.

5


• 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, Alexan-

dre . 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, Ale-

xandre . Synaptic City: An architectural approach using an OSGI Infrastructure

and GMaps API to build a City Simulator. In: The 15th International Conference

on Enterprise Information Systems (ICEIS), 2013, Angers. Proceedings of the

15th International Conference on Enterprise Information Systems (ICEIS). Lisboa:

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

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

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

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

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

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

v. 1. p. 511-516.

1.6 Organização da Dissertação

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

• Capítulo 2: contextualiza a temática de CI e IoT, além de esclarecer a interaçã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;

6

1.6. ORGANIZAÇÃO DA DISSERTAÇÃO

• Capítulo 4: descreve em detalhes a proposta da AS, ressaltando, principalmente,como cada requisito é implementado;

• Capítulo 5: discute o processo de avaliação de AS realizado, totalmente remoto,durante o desenvolvimento da solução, e apresenta os principais resultados;

• Capítulo 6: conclui esta dissertação por meio de de um resumo das principais con-tribuiçõ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.

7

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 ede infraestruturas e consomem um crescente volume de recursos e de energia, com um sig-nificativo impacto a nível econômico, ambiental e de qualidade de vida (ComputerWorld,2013).

A literatura apresenta diversas definições do termo Cidade, porém a mais aceitaé descrita em Kuper (1995) como “um povoado relativamente grande e permanente”.Geralmente, uma cidade possui alta densidade populacional e os cidadãos interagemcom indústrias, comércios e serviços. No quesito operacional, cidades são baseadas emum conjunto de serviços urbanos básicos: energia, água, transporte, infraestrutura deinformação e comunicação, mercado, saúde pública e saneamento público (Morvaj et al.,2011).

Este conjunto de serviços urbanos básicos é justamente onde se localizam os prin-cipais problemas das cidades (Morvaj et al., 2011). Além disso, com o crescimentopopulacional supracitado no Capítulo anterior e o envelhecimento das infraestrturas,surge a necessidade de aprimorar técnicas para otimizar a utilização destes serviços (Krco,2010). Simultaneamente, necessita-se de um sistema no qual os demais serviços possamser criados e/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 sidocada vez mais difíceis de serem administrados. A saber:

9

CAPÍTULO 2. CIDADES INTELIGENTES E INTERNET DAS COISAS

Segurança: Os altos índices de criminalidade são grandes preocupações da sociedade.Assaltos, tráfico de drogas e crime organizado são manchetes na TV e nos jornais todosos dias e são uma dura realidade das cidades brasileiras. Catástrofes como enchentessão um problema de defesa civil devido a ocupação desordenada de encostas e morros,ameaçando diversas comunidades em cidades por todo o Brasil. Segundo o Mapa dasOcorrências Registradas pelas Polícias Civis (Janeiro de 2004 a Dezembro de 2005)1,desenvolvido pela Secretaria Nacional de Segurança Pública, entre 2004 e 2005 a taxa deroubo no Brasil por 100 mil habitantes aumentou de 516,7 para 519,4;

Transporte: O sistema de transporte coletivo é de qualidade e eficiência questionáveisna maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e ascrescentes facilidades no financiamento de veículos, a quantidade de motocicletas eautomóveis no país é cada vez maior. A infraestrutura viária não acompanha estecrescimento da frota nacional e o trânsito é um problema em muitas cidades. Soluçõespaliativas, como rodízio de veículos, apenas atenuam o crescimento do problema dotráfego, quando, na verdade, uma otimização no sistema de transportes coletivos faz-se necessária. Dois exemplos da situação do transporte coletivo no Brasil podem serencontrados na Pesquisa de Mobilidade Da Região Metropolitana de São Paulo2: i) entre2002 e 2012, a frota de veículos particulares cresceu 18%; ii) no mesmo período, a taxade 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 pacientesa aguardarem em longas filas de espera e o mesmo problema vem assolando pacientes dosistema privado com planos de saúde. De acordo com a pesquisa da Assistência Médico-Sanitária(AMS)3 realizada em 2002 pelo IBGE, houve uma variação na quantidade deleitos disponíveis no Brasil, de 3,65 leitos por 1 000 habitantes em 1992, para 2,70 em2002, 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 aindarepresentam a maior fatia do consumo de energia elétrica, pelo padrão de consumo econforto que envolve diversos tipos de eletroeletrônicos. Em Foz do Iguaçu, por exemplo,7% das famílias correspondem a mais de 65% do consumo de energia elétrica da cidade

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

10

2.1. CONCEITO DE Cidade Inteligente (CI)

(Heberty H. Amaral and Fernandes, 2010);

Gestão de resíduos: O lixo tem se tornado um grande problema para cidades depaíses em desenvolvimento. Enquanto cidades de países desenvolvidos põem em práticadiversas soluções de tratamento de lixo orgânico e de reaproveitamento de materiaisrecicláveis, cidades de países como o Brasil não conseguem definir ou executar práticasde reciclagem, salvo raras exceções. Por exemplo, de acordo com a Associação Brasileirade Empresas de Limpeza Pública e Resíduos Especiais (ABRELPE)4, em 2012 cercade 60% dos municípios registraram alguma iniciativa de coleta seletiva. Embora sejaexpressiva a quantidade de municípios com iniciativas de coleta seletiva, muitas vezesestas atividades resumem-se à disponibilização de pontos de entrega voluntária ou convê-nios com cooperativas de catadores, que não abrangem a totalidade do território ou dapopulação do município.

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çãodo conceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado paraempregá-lo (Giffinger and Pichler-Milanovic, 2007; Caragliu et al., 2009; Li et al., 2011).Logo, a Seção 2.1 visa clarificar a definição de CI a ser utilizada durante este trabalho.

Um paradigma que vem sendo utilizado em diversas abordagens para CI é a utilizaçãode IoT como ferramenta para captar dados e atuar sobre os serviços urbanos. Logo, aSeção 2.2 visa contextualizar a IoT, a partir de alguns exemplos de aplicações.

Por sua vez, a Seção 2.3 inicialmente pontua alguns dos principais desafios, princi-palmente, nas cidades brasileiras. Em seguida, apresenta-se a integração existente entreestas duas áreas de pesquisa e alguns exemplos de utilização desta integração para mitigaralguma deficiência urbana.

Por fim, a Seção 2.4 consolida as principais contribuições deste Capítulo.

2.1 Conceito de Cidade Inteligente (CI)

A literatura apresenta algumas definições para o termo CI, porém ainda não há umconsenso a respeito deste conceito. A seguir, são apresentadas as principais definiçõesdescritas na literatura e a definição que será utilizada no decorrer deste trabalho.

Em Giffinger and Pichler-Milanovic (2007) é ilustrada uma série de diferentes ambi-entes na qual o termo foi utilizado. Por exemplo, a definição de CI, quando associada comeconomia, é uma cidade com indústria inteligente, na qual são empregadas tecnologiasde última geração para aprimorar os aspectos financeiros e econômicos. No aspecto

4http://a3p.jbrj.gov.br/pdf/ABRELPE%20%20Panorama2012.pdf

11


educação, Giffinger et. al. caracteriza CI como o nível de escolaridade dos cidadãos.Além disso, de acordo com Giffinger et. al., uma CI também pode ser mensurada a partirdo relacionamento entre o governo e os cidadãos e a utilização de modernas tecnologias,não somente relacionada à Tecnologia da Informação e Comunicação (TIC), mas tambémà outros domínios, como transporte e logística.

Por fim, Giffinger et. al. define seis características principais para cidades inteligentes:smart economy, smart people, smart governance, smart mobility, smart environment esmart living. A partir disso, uma CI é uma cidade com bom desempenho nestas seiscaracterísticas, construída a partir da combinação inteligente de atividades independentes,auto-decisivas e em prol dos cidadãos. Esta definição, oriunda dos resultados do projetoEuropean Smart Cities (Caragliu et al., 2009), é a mais bem conhecida e com maioraceitação na literatura (Hernández-Muñoz et al., 2011), pois permite quantificar o nívelde inteligência das cidades. Por exemplo, inovação faz parte do eixo smart economy e écalculado pela quantidade de patentes por habitantes (Haubensak, 2011).

Apesar dessa definição ser considerada a mais abrangente, cada trabalho adota umadefinição mais apropriada para o escopo do projeto. Em Su et al. (2011), a IBM defineCI como o uso de TIC para capturar, analisar e integrar informações relevantes no núcleodos sistemas das cidades. Ao mesmo tempo, uma CI pode tomar decisões inteligentespara diferentes tipos de necessidades, incluindo aspectos diários, proteção ambiental,segurança pública, serviços da cidade e atividades industriais e comerciais.

Analogamente, em Kanter et al. (2009) o termo CI é definido como uma cidadeque combina TICs com a infraestrutura física, para prover conveniências aos cidadãos,como: eficiência energética; aumento da qualidade da água e do ar; identificar e resolverrapidamente qualquer problema no funcionamento dos sistemas da cidades; mitigardesastres; capturar dados para apurar a tomada de decisões e a utilização de recursos deforma eficiente. Logo, a CI não pode ser vista como a soma de partes independentes, masuma rede de infraestrutura interconectada, na qual cada recurso é dependente do outro.

Em Steventon and Wright (2005), as CIs se referem aos ambientes físicos em queas TICs e os sistemas de sensoriamento são transparentes para os cidadãos, porémdesepenham papel fundamental para garantir 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 dapopulação da cidade, instituições locais e orgãos governamentais (Komninos, 2002;Schumpeter, 1934).

Em ComputerWorld (2013) defende-se que CI não é um conceito tecnológico, mas

12

2.1. CONCEITO DE Cidade Inteligente (CI)

um conceito sociotécnico. Integra-se três vertentes essenciais: a tecnologia, as pessoas eas instituições. Uma CI tem que centrar a sua atuação nos cidadãos e nas comunidadesonde vivem e trabalham.

Em relação aos aspectos governamentais, Toppeta (2010) 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çãoMundial para Cidades Inteligentes)5 define que uma CI é uma comunidade com avançossignificativos em TICs que transformam o cotidiano dos cidadãos, melhorando os aspectosrelacionados ao trabalho e ao lazer de forma incremental e transparente (Eger, 2011).

Além da falta de consenso quanto ao termo CI, existem outros termos que sãocomumente aplicados aos mesmos contextos, como “cidades virtuais”, “cidades digitais”,“cidade informatizada”, “cidade eletrônica” (Komninos, 2006). Ao generalizar esseconceito aos ambientes inteligentes que se relacionam com serviços urbanos, váriossinônimos de CI são frequentemente empregados, como “information city”, “wired city”,

“telecity”, “knowledge-based city”, “electronic communities”, “electronic community

spaces”, “flexicity”, “teletopia”, “cyberville” (Droege, 1997).

Essa ausência de consenso é devido aos múltiplos movimentos científicos, tecnoló-gicos e sociais que compõem o contexto de uma cidade (Komninos, 2006). Em cadadisciplina, existe uma série de problemas que afetam diretamente diversos serviçosexistentes, como transporte, segurança, provisão/consumo de energia elétrica e água,saneamento básico, utilização de recursos naturais, controle de catástrofes, principal-mente no que tange a gestão individual e influência mútua, até como planejar e otimizar autilizaçã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 ”.

5http://www.smartcommunities.org

13


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

De acordo com Giusto et al. (2010), a Internet of Things (Internet das Coisas) (IoT),também conhecida como Internet dos Objetos, é um paradigma que vem crescendo nocenário moderno de telecomunicações sem fio. A idéia básica deste conceito é a presençade um conjunto de objetos (things) - como Radio-Frequency IDentification (RFID),sensores, atuadores, telefones celulares - que, por meio de mecanismos de endereçamentoúnico (como a Internet), são capazes de interagir e cooperar uns com os outros paraalcançar objetivos em comum.

Sem dúvida, o principal impacto da IoT será sobre alguns aspectos do cotidiano ecomportamento das pessoas (Atzori et al., 2010). Por exemplo, já existem aplicações IoTque permitem o monitoramento de atividades físicas6 e controle de medicamentos de usocontínuo7. Outro conjunto de aplicações que interferem no cotidiano das pessoas são asvoltadas 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ãorealidades.

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 listadas seis tecnologias civis “com impactos potenciais sobre o poder nacional dos EUA” (,NIC). Além disso, o NIC prevê que até 2025 os “objetos” estarão presentes em todas ascoisas cotidianas, como documentos, embalagens de alimentos e móveis.

A partir da evidente gama de possibilidade oriundas da IoT, torna-se natural associá-las ao contexto de CI. Em uma CI, para o funcionamento adequado dos serviços inteli-gentes é necessária a utilização de tecnologias que sejam capazes de captar e distribuirestas informações (Li 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/

14

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

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

A partir dos problemas comumente enfrentado pelas cidades, surge o desafio de combinardiferentes 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 serintegradas como ferramentas para monitorar os eventos de um ambiente, atuar a fim deconter uma situação emergencial ou, até mesmo, propagar uma informação relevante.

Os cenários da utilização de TICs e IoT para esta finalidade são os mais variados.Um exemplo é o monitoramento do trânsito em estradas e rodovias. Este monitoramento,a partir de sensores espalhados pelas vias, poderia alimentar sistemas de informaçãocapazes de gerar rotas em tempo real, redistribuindo os veículos, aumentando a fluidezdas vias. Esta redistribuição poderia ser feita ao enviar informações para os dispositivosGPS dos veículos ou até mesmo por um conjunto de painéis indicativos para orientaros motoristas sobre a melhor rota. A comunicação e a troca de informações entre estesdiferentes objetos constituem um cenário de uso clássico de IoT.

Outro exemplo da utilização maciça de TIC e IoT é o controle do consumo residencialde energia elétrica a partir de eletrodomésticos habilitados a otimizar seu funcionamentode acordo com os hábitos e necessidades de seus moradores. Além disso, estes eletrodo-mésticos, atuando em uma rede de objetos, podem trocar informações a fim de otimizartarefas rotineiras dos cidadãos, tais como, compras nos supermercados e manutenção dolar.

Um caso real da eficiência em aplicar TICs baseada em IoT é a redução de 30%das emissões de carbono em Londres, apenas com a mudança de comportamento doscidadãos, a partir do acompanhamento de todas as tarefas dia-a-dia (Tomordy, 2011).Esta mudança de comportamento foi possível a partir de uma rede sensores que forneciainformações do nível de carbono em tempo real .

2.4 Considerações Finais do Capítulo

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

Como discutido previamente, ainda não há um consenso a respeito da definiçãomais adequada para CI. Logo, a Seção 2.1 apresentou algumas definições disponíveisna literatura. A partir destas, a definição a ser utilizada neste trabalho foi explicitada,

15


considerando os diferentes pontos de vistas dos demais autores.Em seguida, a IoT foi definida e exemplificada na Seção 2.2. A partir desta, pode-

se notar a evidente correlação entre estas duas áreas de pesquisa. Este fato pode sercomprovado ao analisar as principais aplicações de IoT: a grande maioria visa otimizaralgum aspecto relacionado ao cotidiano das pessoas, tanto no ambiente profissionalquanto no doméstico (Atzori et al., 2010).

Por fim, a Seção 2.3, apresentou alguns exemplos de utilização de IoT e dos conceitosde CI para mitigar estes problemas urbanos. Algumas destas iniciativas já estão sendodesenvolvidas e validadas, porém, para de fato se estabelecer uma CI, é necessária aintegração destas iniciativas a partir de uma AS centralizada (Filipponi et al., 2010;Anthopoulos and 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 deuma CI. Logo, o próximo Capítulo apresenta exemplos destas abordagens, encontradas apartir de dois métodos de revisão da literatura.

16

3Revisão da Literatura de Arquiteturas de

Software para Cidades Inteligentes

Cada dia sem treinar, estudar ou se dedicar a algo realmente

importante significa um dia mais distante da realização do seu sonho.

—BERNARDO ROCHA DE REZENDE, 2010 (Transformando Suorem Ouro)

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 trocade informações entre diferentes serviços urbanos, a fim de fornecer serviços mais efetivospara os cidadãos. Outro fator relevante é a possibilidade de criar aplicações Internet of

Things (Internet das Coisas) (IoT) que consumam ou forneçam algum tipo de dado parauma determinada finalidade, como por exemplo, captar informações de pontos turísticosda cidade para melhorar a experiência dos turistas. Esta integração das aplicações IoTcom a AS será independente da tecnologias utilizada, devido a vasta gama de sensores,atuadores, pessoas, sistemas, drivers e qualquer outro componente capaz de interagircom os serviços urbanos. Além disso, a AS pode permitir que governos adotem açõesestratégicas voltadas para as reais necessidades dos cidadãos.

Ao adotar um modelo como esse, na qual uma AS centralizada processa e distribuídos dados dos serviços urbanos, uma CI pode de fato ser implementada, uma vez queexistirá um meio pelo qual os serviços urbanos poderão ser integrados (Filipponi et al.,2010; Anthopoulos and Fitsilis, 2010; Haubensak, 2011; Sanchez et al., 2011; Hernández-Muñoz et al., 2011).

Nos ínicio dos anos 90, a AS era basicamente voltada para os sistemas cliente-servidor,

17

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

na qual uma máquina exercia o papel de cliente requisitante e a outra máquina, o papelde servidor com a responsabilidade de atender as requisições (Sommerville, 2007). Destemodo, a arquitetura cliente-servidor tornou-se padrão no desenvolvimento de software,sendo em nossa atualidade ainda explorada e, sobretudo, mesclada a outras AS paraatender ao objetivo de um software (Fowler, 2012). Já na década de 2000, nota-se queas aquiteturas propostas são cada vez mais heterogêneas, na qual estilos e tecnologiasdiferenciadas se misturam para formar novas versões de representações arquiteturais(Bass et al., 1998).

Dessa forma, o que se almeja investigar neste Capítulo é o estado da arte de Arquite-turas de Software (AS’s) para CI que empregam IoT na solução de problemas urbanos.

Para aumentar a abrangência desta investigação, duas revisões da literatura foramrealizadas: Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). As revisõessistemáticas possibilitam a replicação do procedimento, pois possuem um processorepetitível. Porém, a temática deste trabalho envolve aspectos mercadológicos que podemser excluídos dessas revisões, por não serem publicados nos veículos convencionais.Logo, as revisões exploratórias são importantes, pois permitem incluir diversos trabalhosde diferentes veículos de publicação, como por exemplo, relatório técnico de empresas.Porém, esse tipo de revisão possui certa resistência por ser baseado totalmente nas buscasnão-metódicas do pesquisador.

Estes dois métodos de revisão literária também têm como objetivo identificar anecessidade de criar ou adaptar um padrão arquitetural específico para este contexto deCI e IoT.

Na Revisão Sistemática, foram selecionadas 11 abordagens. Já na Revisão Explo-ratória 16 abordagens foram selecionadas. Nestas duas revisões, 7 abordagens foramencontradas em ambas as revisões. Estes trabalhos destacam-se por envolverem aspectosacadêmicos e mercadológicos. Nestes casos, optou-se por descrevê-los apenas na RevisãoSistemática. Por fim, ao todo, foram encontrados 20 abordagens condizentes com oobjetivo deste trabalho.

Após a descrição das abordagens encontradas nas duas revisões, a Seção 3.3 visaconsolidar as características mais relevantes de cada abordagem. Em seguida, pretende-seestabelecer um conjunto de requisitos que uma AS para CI deve atender (Seção 3.4).

Este conjunto de requisitos e os demais resultados da Revisão Exploratória forampublicados em da Silva et al. (2013). Já os resultados da Revisão Sistemática forampublicados em Tomas et al. (2013).

Por fim, a Seção 3.6 dicute os pontos mais relevantes deste Capítulo e a Seção 3.7

18

3.1. REVISÃO SISTEMÁTICA

finaliza o Capítulo.

3.1 Revisão Sistemática

Conforme brevemente introduzido na Seção anterior, de acordo com Kitchenham andCharters (2007) o objetivo de uma SLR é fornecer indícios para o desenvolvimentode pesquisas baseadas em evidências, a partir da seleção e síntese das pesquisas maisrelevantes. Além disso, a SLR deve identificar, avaliar, interpretar e comparar todas asfontes 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 ferramentapara a implementação de uma CI.

3.1.1 Metodologia de Pesquisa

O objetivo desta subseção é descrever a estratégia de busca e todos os passos utilizadospara filtrar e extrair as informações relevantes de cada pesquisa. Essa estratégía segue asrecomendações descritas por Kitchenham and Charters (2007).

Estratégia de Busca e Fontes de Dados

A estratégia empregada para a construção das strings de buscas segue a mesma metodo-logia emprega por Kitchenham and Charters (2007), Chen et al. (2009) e Khurum andGorschek (2009). Esta estratégia é ilustrada na Figura 3.1.

Figura 3.1 Estratégia de Busca

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

(smart city OR intelligent city OR digital city OR urban environment) AND (internet of

things OR heterogeneous sensors) AND (architecture OR middleware OR platform)

19


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ívelutilizar a mesma string de busca em todas as fontes digitais (Chen et al., 2009). Logo,foi necessário um esforço para garantir que as strings utilizadas sejam logicamente esemanticamente equivalentes.

Após definir a string de busca, realizou-se a busca nos seguintes repositórios digitais (1.IEEExplore; 2. Science Direct; 3. ACM Digital Library; 4. Springer Link; 5. CiteSeerX;6.Academia.edu; e 7. ISI Web of Science). Além disso, considerando que CI é uma linhade pesquisa que envolve diversos aspectos de negócio e mercado, realizou-se a busca porpatentes no banco de patentes World Intellectual Property Organization(WIPO)1.

Em relação à busca manual, foi realizada nos seguintes anais (1. International Confe-

rence 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. Interna-

tional 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 fontesde pesquisa.

Tabela 3.1 Quantidade de abordagens por fonte de pesquisaFonte 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

1http://www.wipo.int

20


identificadas como primários, conforme discutido em Chen et al. (2009). Dessa forma,algumas abordagens podem não ter sido incluídas, caso os autores tenham usado outrostermos além dos mencionados acima.

Seleção das Abordagens

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

que centralize os diversos contextos e tecnologias que envolvem o ambiente urbano. Paratal, 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 3.2 ilustra os resultados de cada filtro, baseado naquantidade de abordagens resultantes.

Filtro 1

Filtro 3

Filtro 2

Estudos encontrados nas fontes de pesquisa 6435

Exclusão de estudos baseada no título

Remoção de duplicações

Exclusão de estudos que não foram publicados entre 2008-

2012

Filtro 4

4310

71

61

Exclusão de estudos baseada nos resumos.Filtro 5 33

Exclusão de estudos baseada na relevância.Filtro 6 11

Figura 3.2 Resultado da filtragem das abordagens

O objetivo destes filtros é selecionar as principais abordagens que descrevem AS’spara CI baseadas em IoT. O primeiro filtro corresponde a todas as abordagens encontradasnas fontes de pesquisa, descritas anteriormente, a partir da string de busca.

O segundo filtro foi aplicado para excluir as abordagens que não foram publicadasentre 2008-2012. Este intervalo foi escolhido após analisar e verificar que as abordagenspropostas antes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens forampropostas para solucionar problemas específicos de um contexto usando apenas umatecnologia, sem analizar a conexão entre os diferentes contextos urbanos.

21


Para realizar a terceira filtragem, todos os títulos das abordagens foram lidos eresultaram apenas 71. Esta alta discrepância com o valor resultante do filtro anterior estárelacionada a falta de eficiência das engines de busca, como discutido em Kitchenhamet al. (2009).

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 propostadeste trabalho.

Em relação aos critérios de inclusão, as abordagens foram incluídas se:

• Propõem uma AS para centralizar a informação de diferentes contextos urbanosOU

• 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,restaram 11 abordagens para serem analisadas.

Existem diversas razões para esta alta discrepância entre a quantidade inicial detrabalhos com a quantidade resultante. A principal razão é a alta quantidade de estudosduplicados com resultados semelhantes. Estas razões são discutidas e explicadas emKitchenham et al. (2009).

Em relação às patentes, não foi encontrada nenhuma patente relacionada. Geralmente,as patentes mais próxima à temática dessa revisão sistemática descrevem um algoritmoespecífico ou a otimização de uma técnica empregada em um ambiente controlado.

3.1.2 Resultados

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

22


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 anode publicação. A Tabela 3.2 lista as 11 abordagens analisadas, organizadas em ordemcronológica.

Tabela 3.2 Abordagens resultantes por ordem cronológicaID Abordagem Ano Referência1 Al-Hader’2009 2009 (Al-Hader et al., 2009)2 Anthopoulos’2010 2010 (Anthopoulos and Fitsilis, 2010)3 SOFIA 2010 (Filipponi et al., 2010)4 EcoCity/ISMP-UC 2011 (Lee et al., 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)

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’sencontradas, ordenadas em ordem cronológica, ressaltando os principais objetivos ecaracterísticas de cada abordagem.

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 einfraestrutura de redes. O primeiro princípio corresponde às aplicações que fazem uso dediferentes tecnologias para monitorar sensores, como Global Positioning System (GPS).De acordo com (Al-Hader et al., 2009), a maioria destas aplicações atendem as demandasoperacionais das cidades, porém, ao utilizar as regras definidas no segundo princípio -negócios - elas podem agregar soluções economicamente viáveis. O terceiro princípio é ogerenciamento de processos na qual relacionamentos, regras, estratégias e políticas entreas aplicações e as unidades de negócios são definidas. Finalmente, o último princípiocorresponde a toda a infraestrutura de rede, responsável por conectar os outros trêsprincípios.

Anthopoulos and Fitsilis (2010) propõem uma AS baseada na análise de diferentesiniciativas já implementadas, modelada a partir dos princípios das Enterprise Architec-

23


tures (Booch, 2010). Anthopoulos and Fitsilis (2010) enfatizam que a construção deuma CI deve ser guiada pela integração de sistemas legados com as novas infraestruturas,migração e reuso de dados existentes, simplificação dos processos urbanos, otimizaçãoda utilização de recursos naturais, interoperabilidade de sistemas e equipamentos e proverferramentas 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 embarcadosem geral. A AS SOFIA é baseada em eventos, na qual cada evento corresponde àmudança de estado de qualquer sistema de TIC. Estes eventos podem ser iniciados apartir de eventos do mundo real (como detecção de presença) ou ao término de algumprocessamento.

O monitoramento e gerenciamento de sensores também são objetivos definidos pelaabordagem denomida EcoCity/ISMP-UC (Lee et al., 2011). A AS EcoCity/ISMP-UC éconstituída de três camadas. A camada inferior consiste de diferentes tipos de sensores,atuadores e outros dispositivos distribuídos pela cidade. Já a camada superior representaum conjunto de serviços U-eco City. Entre essas duas camadas existe um middleware

responsável por coletar e processar informações contextuatilizadas. Esta AS orientada àserviços possibilita o desenvolvimento de serviços independentes e que sejam consumidosvia interfaces padronizadas, como web services.

Por sua vez, Mostashari et al. (2011) propõem um framework denominado Cognitive

Process Architecture Framework (CPAF), o qual permite o desenvolvimento de 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 partirdestas conclusões. Um sistema cognitivo é capaz de perceber e responder às mudançasno ambiente, portanto, pode melhorar a performance dos serviços urbanos.

Outra abordagem na qual utiliza vários sensores embarcados nos contextos urbanos éSmartSantander Sanchez et al. (2011). A quantidade de dispositivos configurados na AS ésuperior à 12.000. O SmartSantander provê: i) uma AS refência para sistemas IoT; ii) umescalá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)um grande conjunto de experimentos relacionados à Internet do Futuro.

Com o mesmo objetivo de interoperabilidade de objetos abordado em Smart Santander,a abordagem IMS (Shao, 2011) propõe uma AS que combina IoT com os cidadãos dascidades. Shao (2011) acreditam que o desenvolvimento de TIC esta relacionado à

24


proximidade com os moradores das cidades. Para isso, IMS é baseada em três camadas:acesso, sessão e aplicações. A camada de acesso é a camada mais baixa e provê todaa infraestrutura para acessar a rede IMS a partir de diferentes terminais. A camada desessão provê o gerenciamento de sessões entre a camada inferior (Acesso) e a superior(Aplicações). Finalmente, a camada de aplicação permite o desenvolvimento de diversasaplicações.

A interoperabilidade de objetos também é explorada por Hernández-Muñoz et al.

(2011), que propõem uma AS denominada Ubiquitous Sensor Network (USN). O objetivoé prover uma infraestrutura que seja capaz de integrar sensores heterogêneos e distantesgeograficamente em um base centralizadora, na qual serviços podem ser facilmentedesenvolvidos. Adicionalmente, a AS inclui um módulo conhecido como USN-Gateway

que possibilita a interoperabilidade entre redes de sensores e redes IP.

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

First e agente de troca de mensagens.

Em Fazio’2012 (Fazio et al., 2012) é proposto uma AS que permite a agregaçãode diferentes tipos de informações oriundas de diferentes sensores distribuídos peloscontextos urbanos. O principal objetivo dessa abordagem é de prover dados contextu-alizados, combinando diferentes fontes de dados. Para isso, a AS consiste de quatrocamadas: I) REST que permitem interações sob-demanda com os clientes, aplicaçõese outros serviços; II) Sensor Observation Service Agent (SOS Agent) que suporta todasas funcionalidades para a descrição de sensores; III) Sensor Manager capaz de interagircom sensores, coordenar suas atividades e coletar dados para as demais camadas; IV)Sensing Infrastructure é composto de vários diferentes sensores.

Finalmente, a abordagem conhecida como S3OiA (Vega-Barbas et al., 2012) tambémpermite o gerenciamento de diferentes tipos de informação. A AS S3OiA é sintáticae semântica aos princípios do SOA, que permitem a integração de qualquer tipo dedispositivo IoT. Com essa estratégia, a AS suporta a composição de aplicações ad hoc.Para tal, foi definido dentro do projeto da AS um conjunto de módulos de dependênciasemântica de gestão que controlam serviços e recursos, permitindo que os aplicativos jácriados possam continuar a execução, apesar das mudanças do contexto.

25


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-seressaltar o interesse das organizações governamentais e/ou privadas, como Microsoft(PlanIT, 2012), além das iniciativas nos modelos de Startup, como Libelium 2 e Every 3.

Além disso, pode-se encontrar diversas iniciativas em formato Web/HTML ou relató-rio técnico disponibilizados pela própria organização, como HP (Hoover et al., 2010) eIBM (Dirks and Keeling, 2009).

Desta forma, para aumentar a eficácia e a abrangência da revisão literária faz-senecessário à realização de uma revisão exploratória. Uma revisão exploratória consisteem um mecanismo que não possui nenhum processo pré-definido para encontrar as fontesde informações.

Nesse tipo de revisão, todas as fontes relacionadas com o tema são analisadas, inde-pendente do tipo e do veículo de publicação do conteúdo. Em algumas situações, essasrevisões podem ser consideradas mais abrangentes, por não possuírem nenhum processode classificação. Porém, em outras situações, são consideradas tendenciosas, já que oprocesso de revisão dificilmente pode ser repetido.

Logo, essa revisão exploratória visa discutir e analisar as principais abordagens quepropõem uma AS para CI baseada em IoT, encontradas nos mais diversos veículosde comunicação. Dentre eles, destacam-se websites, blogs, relatórios técnicos nãopublicados e eventos.

3.2.1 Metodologia de Pesquisa

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

No caso dessa revisão, inicialmente algumas buscas foram realizadas em três re-positórios de buscas: IEEE Xplore, Mendeley e ACM Digital Library. As principaispalavras-chaves utilizadas foram: Smart Cities, Internet of Things, Architecture, Smart

Enviroment, Digital City, Smart Cities Survey. Apesar de empregar estas palavras-chaves,nenhuma string de busca específica foi definida.

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

26

3.2. REVISÃO EXPLORATÓRIA

A partir dos resultados dessas buscas, alguns trabalhos foram classificados comorelevantes de acordo com o título e uma rápida leitura do conteúdo. Em seguida, todos ostrabalhos restantes foram lidos e discutidos, com o mesmo grupo da Revisão Sistemática,do ponto de vista arquitetural e do emprego das tecnologias IoT para resolver a proble-mática de CI. A partir destas fontes, as principais referências destes trabalhos tambémforam analisadas, repetindo a abordagem até não restar nenhum trabalho potencialmenteinteressante.

As revisões exploratórios possuem alguns riscos eminentes. No contexto destetrabalho, a principal ameaça é de não encontrar abordagens maduras e com os mesmosobjetivos desta proposta, uma vez que a metodologia de pesquisa não é abrangente osuficiente. Além disso, ao realizar uma revisão exploratório após a SLR pode-se encontrarvárias abordagens repetidas.

3.2.2 Resultados

Em Klein and Kaefer (2008) é relatada uma perspectiva de CI voltada para negócio, espe-cificamente de provedores de infraestruturas e soluções dentro do contexto de utilizaçãoeficiente de energia elétrica para infraestruturas inteligente e data centers. O objetivodo trabalho é aderir eficiência energética dos equipamentos, reduzindo os custos comenergia e criando mecanismos para que softwares e serviços tornem-se autoconscientesde seu consumo de energia. De acordo com os autores, esta característica é essencial naimplementação de uma AS de CI, permitindo desenvolvimento e operação sustentáveis.

Em Blackstock et al. (2010) é proposta uma plataforma chamada Magic Broker

(MB2), a qual possui o objetivo de permitir a interoperabilidade de objetos. Inicialmentedesenvolvida com o objetivo de prover um modelo consistente e padronizar as interfacespara a construção de aplicações de IoT, o MB2 esta sendo adaptado para o contextode CI. Para tal, além de prover a API para consultas, a plataforma provê abstraçõesfundamentais, como: eventos, estado, serviços e gerenciamento de conteúdo.

O MB2 consiste de uma evolução do MB original (Erbad et al., 2008), na qualforam inseridas diversas características para a construção de aplicações ubíquas, como ainclusão de um middleware responsável por tratar as informações oriundas dos diferentesdispositivos. Para tal, foram acoplados diversos protocolos de comunicação como HTTP eXML. Cada implementação desses protocolos foi implementada usando serviços OSGi4.

Seguindo o princípio de ser um laboratório para validação de tecnologias com focoem CI, em Lisboa/Portugal foi construída uma cidade com 1700 hectares de extensão.

4http://www.osgi.org

27


Conhecida como PlanIT Valley5, a cidade deve produzir 150% da energia necessária,gerenciar os resíduos sólidos e reciclar toda a água consumida. Empresas privadas, comoa Microsoft, Cisco, Massachusetts Institute of Techonology e McLaren Eletronic System

estão apoiando esse projeto (PlanIT, 2012).

A estratégia desse projeto é implementar um Sistema Operacional Urbano(UOS).Esse sistema operacional é uma plataforma com o intuito de integrar cada domínio quecompõem uma cidade. O sistema será alimentado por uma vasta rede de sensores e todosesses dados serão capturados por tempo indeterminado, para auxiliar na tomada e napredição de decisões. Além de prever catástrofes, caso ocorra, o sistema pode antever ospossí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 desertode Abu Dhabi com 6 km quadrados, 50.000 habitantes, 1500 empresas e universidades.O objetivo do projeto é desenvolver projetos auto-suficientes com o mínimo de impactoambiental. Toda a cidade é livre de combustíveis fósseis, na qual toda a energia é oriundade fontes renováveis, sem nenhum tipo de resíduo. Além disso, 80% da água consumidaserá tratada. No quesito transporte, os veículos privados são proibidos e os meios detransporte são veículos elétricos e bicicletas. As estações de transportes elétricos serãoseparadas por uma distância de no máximo 200 metros. A primeira fase do contémaparelhos ecologicamente corretos desenvolvidos pela General Eletric (GE).

Em Nam and Pardo (2011) é descrita a teoria da sinergia que deve existir entretecnologia, pessoas e instituições na concepção de CI. O trabalho destaca especificamenteque a inteligência refere-se comumente às mudanças inovadoras trazidas por novastecnologias. Em relação ao aspecto tecnologia, os autores afirmam que é essencial que acidade possua alta adaptabilidade às necessidades de seus cidadãos, independente de suaslimitações, com capacidade de autoconfiguração, proteção, otimização e recuperaçãode falhas, garantindo disponibilidade de serviços a qualquer tempo. Para isso, faz-senecessário uma infraestrutura de computação ubíqua, sobre a qual os serviços serãodisponibilizados.

De acordo com Andreini et al. (2011), SOA é considerada uma investida promissorana construção de CI através da implementação da IoT. Assim, objetos conectados à redepublicariam seus serviços, que por sua vez seriam acessados a partir de clientes móveis,permitindo interações humano-máquina e máquina-máquina (M2M) mais flexíveis. Issoseria construído a partir de uma abordagem semelhante ao Domain Name System (DNS),

5http://living-planit.com

28

3.2. REVISÃO EXPLORATÓRIA

no qual um objeto seria identificado através de um nome, usado para acessá-lo e consultarserviços. Os autores propõe uma implementação usando Distributed Hash Table (DHT),que atribui o nível de escalabilidade desejado para a abordagem adotada, permitindo arecuperação eficiente de serviços no contexto de aplicações para CI.

Outro aspecto muito relevante para qualquer centro urbano é a predição, prevenção ecorreção de situações catastróficas, nas quais medidas urgentes devem ser tomadas nomenor tempo, com a máxima eficácia possível. Em Asimakopoulou and Bessis (2011), éproposto uma AS de gerenciamento de desastres, baseada na coleta de informações dediversas entidades - incluindo pessoas, residências, veículos - imersas em um ambientetotalmente conectado, que monitoram o meio à sua volta. No processo de geração derespostas a situações de emergência é necessário que se tenha conhecimento históricoe em tempo real, das entidades e do ambiente no domínio em questão, para que asolução encontrada seja eficaz. Para isso utilizou-se da abordagem crowdsourcing, naqual os próprios cidadãos, habilitados por algum tipo de aplicação e/ou dispositivo,contribuem com o fornecimento de dados sobre determinado cenário crítico, auxiliandoos stakeholders no processo de tomada de decisão com dados precisos e atualizados.

Já em relação à segurança, ainda na abordagem de Asimakopoulou and Bessis (2011)é discutido que os consumidores e fornecedores de dados devem ser devidamente auten-ticados. Todas as entidades envolvidas na dinâmica proposta pela AS são consideradasrecursos, e sua alocação envolve uma negociação baseada em conjuntos de políticas. Issogarante que a utilização dos recursos será sempre priorizada de acordo com a gravidade dasituação corrente. Mecanismos específicos foram criados para permitir alocação dinâmicae geração parametrizada de alertas, assegurando a disponibilidade dos recursos.

Concomitantemente, em Attwood et al. (2011) é proposta uma AS para infraestruturascríticas em CI, que destaca a necessidade de coleta de dados tempo real de diversosaspectos dentro do ambiente urbano, servindo como substratos para tomada de decisõesem situações críticas. O funcionamento básico da AS consiste em um mecanismo deanotação e agregação, no qual uma rede de sensores distribuída pela cidade estariaconectada e cujos dados estariam mapeados para um serviço específico (Ex.: falha nosistema de distribuição de energia elétrica). Quando algum tipo de falha fosse detectado,os dados coletados seriam fornecidos a uma instância de raciocínio, responsável porsugerir as medidas a serem tomadas para normalizar a situação. Para o caso de falhaem algum nó da rede de sensores, outra rede seria criada a partir dos nós ainda emfuncionamento, permitindo a preservação e distribuição dos dados. Para que esta AS sejaimplementada é requerida uma infraestrutura de hardware distribuída, com capacidade de

29


processamento em tempo real, de alta disponibilidade, preparada para demandas variáveis,tolerante a falhas e energeticamente eficiente.

Por fim, a sustentabilidade também é explorada na AS proposta por Zygiaris (2012).O principal objetivo desta AS é propor um modelo que possa ser empregado em qualquerplanejamento urbano inteligente. Este modelo contempla os conceitos sustentáveis, espe-cificamente na segunda camada, conhecida como Green City. Essa camada é sustentadapela camada responsável pela infraestrutura da cidade e contém todas as políticas am-bientais, por exemplo, o nível de CO2 permitido pelas residências. As demais camadascorrespondem, respectivamente: inovação, aplicação, integração, sincronização e interco-nexão entre diferentes redes. Para validar o objetivo proposto, este modelo foi utilizadonas cidades de Barcelona, Amsterdã e Edimburgo.

3.3 Consolidação das Abordagens Encontradas

As Seções anteriores descrevem várias abordagens obtidas de dois métodos distintos:Revisão Sistemática (Seção 3.1) e Exploratória (Seção 3.2). Na Revisão Sistemática,foram selecionadas 11 abordagens. Já na Revisão Exploratória 16 abordagens foramselecionadas e 7 abordagens foram encontradas em ambas as revisões. No total, 20abordagens foram encontradas a partir destes dois métodos.

A partir da descrição dessas abordagens, pode-se notar a relevância da temática de CI,devido, dentre outros fatores, ao interesse de grandes empresas como Microsoft e Cisco.

A Tabela 3.3 resume as principais características dessas abordagens. Para abordagenspublicadas em periódicos, a coluna “Ano” refere-se ao ano de publicação. Já para asdemais, a mesma refere-se ao ano de criação. Por sua vez, a coluna “Incentivo” categorizaas abordagens que recebem incentivos dos governos (Público), iniciativa privada (Privada)ou de ambos (Ambos).

Ao análisar a Tabela 3.3 percebe-se que a maioria das abordagens não estão ampla-mente validadas em diversos contextos, o que ratifica o caráter inovador deste trabalho.

Além disto, nota-se que das 20 abordagens, 11 não possuem nenhum tipo de validaçã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;

30

3.3. CONSOLIDAÇÃO DAS ABORDAGENS ENCONTRADAS

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

31


• 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 qualapenas 4 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 paraCidades 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. Principalmentepelo fato de que não se pode generalizar restrições locais, aspectos financeiros, sociaise ambientais, ou mesmo garantir a adequação à dinâmica do cotidiano das diferenteslocalidades. A partir do levantamento das arquiteturas realizado, a proposta desta Seção édiscutir um conjunto de requisitos fundamentais que devem ser atendidos na implantaçãode 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 et al., 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ãooriundos de diversos objetos, com tecnologias e protocolos variados.

As AS’s designam um módulo ou camada para atender esse requisito, como emSOFIA (Filipponi et al., 2010), USN (Hernández-Muñoz et al., 2011), EcoCity/ISMP-UC (Lee et al., 2011), Living PlanIT (PlanIT, 2012), Zygiaris’2012 (Zygiaris, 2012),Wu’2011 (Wu et al., 2011) e S3OiA (Vega-Barbas et al., 2012). Em particular, no caso daUSN (Hernández-Muñoz et al., 2011) este módulo, conhecido como USN-Gateway, alémde ser responsável pela interoperabilidade dos objetos em relação a plataforma, tambémimplementa mecanismos que permitem a interoperabilidade entre redes de sensores e arede IP.

32

3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADESINTELIGENTES

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 cidadeconstantemente atualizados.

Além disso, o monitoramento em tempo real é a ferramenta mais importante parafornecer as informações mais relevantes para a predição e tomada de decisões de eventosfuturos e prever fenômenos. Um exemplo disso é o monitoramento do nível dos riosdurante as temporadas de chuva. Nessa situação, a partir de um monitoramento efetivo épossível tomar medidas para mitigar possíveis transtornos aos cidadãos, como enchentese a transmissão de doenças.

Logo, este requisito pode ser considerado como fundamental. Neste contexto, asAS’s que visam atender esse requisito são Al-Hader’2009 (Al-Hader et al., 2009), SOFIA(Filipponi et al., 2010), SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñozet al., 2011), Asimakopoulou’2011 (Asimakopoulou and Bessis, 2011), Attwood’2011(Attwood et al., 2011) e Living PlanIT (PlanIT, 2012).

3.4.3 Sustentabilidade

As cidades concentram altos índices de consumo de recursos naturais, como água 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áriascidades, principalmente as metrópoles.

Neste sentido, uma AS para CI deve permitir que políticas sustentáveis (susten-tabilidade) sejam implementadas com base em estatísticas relacionadas ao dia-a-diados cidadãos. Por exemplo, iniciativas de consumo consciente de alimentos podem serimplementadas ao mapear os hábitos dos cidadãos durante um dia.

Desta forma, estas políticas sustentáveis devem otimizar a utilização de recursosnaturais, 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íniosque compõem uma cidade, como Transporte e Educação.

As AS’s que integram sustentabilidade são Klein’2008 (Klein and Kaefer, 2008),EcoCity/ISMP-UC (Lee et al., 2011), SmartSantander (Sanchez et al., 2011), MasdarCity (Haubensak, 2011) e Zygiaris’2012 (Zygiaris, 2012).

33


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 fatoestabelecer uma CI é necessário envolver as pessoas, procurando a sua participação paralhes proporcionar maior qualidade de vida, mas protegendo a dimensão humana das urbescada vez mais em risco (ComputerWorld, 2013).

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

Apesar do aparato tecnológico fazer parte dos elementos necessários para a imple-mentação de uma solução mais robusta, as pessoas precisam participar e ser beneficiadaspelo processo, caso contrário, todo investimento será em vão. Um exemplo disso, é aCidade Digital de Trikala, Grécia, que após cinco milhões de euros gastos em manuten-ção de infraestrutura e 6 anos de funcionamento, a população não utilizava ou não tinhaconhecimento dos serviços digitais disponíveis (Anthopoulos and Fitsilis, 2010).

De qualquer forma, CI são construídas por pessoas, para pessoas, e essa deve seruma premissa contemplada em todas os aspectos supridos pela AS. Uma CI é feita de,sobretudo, uma mudança no comportamento de seus cidadãos. As pessoas precisam sentir-se inclusas como parte fundamental na implantação de uma CI, sentir-se estimuladas afazer parte da solução. Para isso podem ser criadas formas de estimular e/ou retribuiresse interesse, como é caso da iniciativa Fun Theory6, da Volkswagen, na qual mudam-seas maneiras de fazer as coisas, a fim de estimular a mudança de hábitos.

Além disso, os serviços devem estar disponíveis para todos os cidadãos independentede quaisquer restrições social, física, econômica ou financeira, a tecnologia deve seraplicada a fim de trazer benefícios coletivos, e não alienar ou elitizar uma pequena parteda população.

Apesar da evidente importância deste requisito fundamental, apenas as AS’s queexplicitamente contém aspectos sociais são Klein’2008 (Klein and Kaefer, 2008), IMS(Shao, 2011) e Asimakopoulou’2011 (Asimakopoulou and Bessis, 2011).

3.4.5 Ubiquidade/Mobilidade

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

6http://www.thefuntheory.com/

34


corresponde a qualquer tecnologia móvel capaz de capturar informação sobre o ambienteou atuar sobre o mesmo (Sanchez et al., 2011).

Ao considerar que 4 bilhões de cidadãos já possuem smartphones (Hall, 2012), énatural associar ubiquidade ao uso destes dispositivos. Porém outros dispositivos devemser utilizados, como ZigBee e RFID (Radio-frequency identification).

Logo, uma AS para CI deve permitir a comunicação efetiva com os mais diversosdispositivos oriundos da temática de ubiquidade, uma vez que estes estarão fisicamentepróximos aos cidadãos. Neste contexto, as AS’s que já empregam alguns destes princípiossão SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñoz et al., 2011), MB2(Blackstock et al., 2010) e Zygiaris’2012 (Zygiaris, 2012).

3.4.6 Privacidade e Segurança dos dados

O ambiente de uma cidade pode ser considerado ubíquo já que diversos sensores sã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 deprivacidade e segurança dos dados, tanto em relação à disponibilidade quanto aoarmazenamento.

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 fatopode ser comprovado a partir dos recentes casos de violação de privacidade dos dadosgovernamentais amplamente divulgados pela imprensa, como os documentos vazados daNational Security Agency (NSA) (Bird, 2013).

Devido a alta relevância deste requisito, não é admissível que uma AS não o satisfaça.Apesar disso, apenas as AS’s SmartSantander (Sanchez et al., 2011), Living PlanIT(PlanIT, 2012) e Fazio’2012 (Fazio et al., 2012) abordam este requisito.

3.4.7 Geolocalização dos sensores

De acordo com Shao (2011); Hernández-Muñoz et al. (2011); Vega-Barbas et al. (2012),a geolocalização dos sensores é fundametal para o refinamento do processo de análisede dados. Neste sentido, um sensor corresponde à uma abstração de qualquer dispositivocapaz de fornecer informações sobre determinado contexto.

A partir destas informações geográficas dos sensores é possível realizar ações es-pecíficas para cada ambiente (Jauregui-Ortiz et al., 2012). Esta característica pode sernotada nas abordagens IMS (Shao, 2011), USN (Hernández-Muñoz et al., 2011) e S3OiA

35


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

3.4.8 Composição de Dados Urbanos

Em uma visão sistêmica, ambientes urbanos são essencialmente um conjunto de domínioscomplexos (como transporte, água, energia elétrica, saneamento básico, etc.) disponibili-zados para suprir as necessidades de seus cidadãos. AS’s que se dispõe a dar suporte àesses sistemas devem considerá-los como complementares na busca de um gerenciamentourbano efetivo, ao invés de tratá-los de forma isolada.

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

Estes dados de cada ambiente urbano deve ser disponibilizado de forma que possamser reutilizados e agrupados para criar uma visão holística e contextualizada da cidadena qual a AS foi implementada (Anthopoulos and Fitsilis, 2010; Nam and Pardo, 2011;PlanIT, 2012).

Para atender essa composição de dados urbanos as AS’s Nam’2011 (Nam and Pardo,2011), CPAF (Mostashari et al., 2011), IMS (Shao, 2011), Anthopoulos’2010 (Anthopou-los and Fitsilis, 2010), Fazio’2012 (Fazio et al., 2012) e Living PlanIT (PlanIT, 2012)implementam explicitamente algum módulo que visa atender este requisito fundamental.

3.4.9 Histórico de dados

No contexto de CI, todos os componentes que compõem cada domínio de uma cidadeestão constantemente sendo modificados, seja por eventos humanos, naturais ou tecno-lógicos. Dessa forma, todo dado captado tem potencial para se tornar uma informaçãorelevante, desde que seja agregado a outros dados.

Estes dados históricos podem ser empregados na predição de eventos futuros, prin-cipalmente quando houver um grande período sem dados em tempo real. Por exemplo,a partir de informações meterológicas dos anos anteriores é possível prever os mesesque poderão ter tempestades. Com informação nessa granularidade é possível adotarprovidências preventivas para 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),

36


SmartSantander (Sanchez et al., 2011), EcoCity/ISMP-UC (Lee et al., 2011) e LivingPlanIT (PlanIT, 2012), estas informações historicamente armazenadas potencializarão osresultados 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 garantira disponibilidade da AS. Dentra elas, a mais discutida e utilizada é relacionada àCloud Computing. Desta forma, caso a infraestrutura de cloud computing seja utilizada,mecanismos de controle de fluxo, colisão e redundância devem ser inerentes à solução.

Nas AS’s SmartSantander (Sanchez et al., 2011), USN (Hernández-Muñoz et al.,2011) e Nam’2011 (Nam and Pardo, 2011), estas situações são tratadas utilizando 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 quantitativasque permeiam esses serviços, bem como do resultado que produzem. É através desensoriamento que se obtêm a visão computacional do ambiente urbano; quanto maior onúmero de sensores e mais disperso eles estiverem, maior será o escopo abrangido pelaAS.

A heterogeneidade dos sensores utilizados influencia na riqueza de detalhes e naquantidade de dados que podem ser extraídos de cada cenário monitorado, sendo possívelobter resultados mais precisos. Por exemplo, reports de trânsito em determinada viapodem ser melhor analisados se complementados com imagens obtidas através de câmerasinstaladas nas redondezas.

Em situações que exigem que medidas preventivas ou corretivas sejam tomadasinstantaneamente exige-se processamento em tempo real, com tempo de resposta rápidoo suficiente para fornecer embasamento para ações que devem ser executadas assimque determinada situação é identificada. Considerando quantidades massivas de dadoscoletados, o suporte à esse tipo de contexto sugere a necessidade de processamentodistribuído, explorando a capacidade da infraestrutura existente.

Uma cidade capaz de monitorar todo o ambiente a sua volta, captar dados e gerar

37


informações e conhecimento, permite execução de seus serviços de forma otimizada eum gerenciamento urbano eficiente.

As AS’s que visam atender esse requisito são USN (Hernández-Muñoz et al., 2011),SOFIA (Filipponi et al., 2010), Andreini’2011 (Andreini et al., 2011) e EcoCity/ ISMP-UC (Lee et al., 2011).

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 requisitosinerentes ao contexto de implementação. Por exemplo, a AS deve ser independente depadrões específicos de hardware.

Apesar da evidente relevância deste requisito, apenas três AS’s exploram este requisito:Klein’2008 (Klein and Kaefer, 2008), MB2 Blackstock et al. (2010) e EcoCity/ISMP-UC(Lee et al., 2011).

3.5 Sumário dos Requisitos para Cidades Inteligentes

A Tabela 3.4 ilustra um resumo dos requisitos que foram implementados nas AS’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 imple-mentam minimamente todos os requisitos levantados.

Isto deve-se ao fato de que as AS’s geralmente são projetadas para propósitos especí-ficos e cada uma propõe uma solução focada especificamente no problema que pretenderesolver.

Além disso, percebe-se que os requisitos de Interoperabilidade de Objetos e Monito-ramento em Tempo Real são os mais abordados pelas AS’s. Esta observação confirmaa importância em monitorar constantemente todos os aspectos que envolvem a cidade,processar e disponibilizar os dados coletados rapidamente, a fim de fornecer uma visãode estado do ambiente urbano mais precisa e atualizada para dar suporte às tomadas dedecisã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,garante as mesmas vantagens aos mesmos atribuídas - como abstração e gerenciamento

38

3.6. DISCUSSÃO DO CAPÍTULO

de dispositivos físicos - que aliada à conectividade expande a abrangência de atuaçãodentro do ambiente urbano, criando um ambiente pervasivo favorável a uma gestão urbanaefetiva.

Tabela 3.4 Mapeamento requisitos-arquiteturasRequisito 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

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ãoexploratória foram encontrados trabalhos com investimentos da iniciativa privada e quejá se encontram em estágio de prototipação.

Ao término desse Capítulo, pode-se perceber que não há a necessidade da criação deum novo padrão arquitetural ou adaptação de um padrão já existente para o contexto de CIe IoT. Ainda em relação aos padrões arquiteturais, nota-se que o modelo de arquiteturasem camadas é o mais utilizado, pois permitem o escalonamento de uma AS. Outro padrãobastante empregado pelas AS’s foi o publisher-subscriber, devido, principalmente, asvantagens em utilizá-lo para modelar o ambiente real.

Além disso, pode-se perceber que algumas AS’s foram propostas para finalidadesespecíficas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem meca-nismos interessantes de tratamento de eventos em tempo real que devem ser considerados

39


no desenvolvimento de qualquer AS para CI.Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há um

consenso amplamente aceito na literatura sobre quais os requisitos que uma AS deveatender para ser considerada efetiva, independente da forma como foi implementada. Apartir das abordagens estudadas, pode-se estabelecer um conjunto de requisitos essenciaisao analisar os principais objetivos das abordagens previamente descritas. Esses requisitosconstituem a base para qualquer AS para CI, pois abrangem os princípios definidos parauma 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 ignoramalguns requisitos 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 consideradainteligente. Esses requisitos servirão como pilares para a elaboração da AS para CI quecombine as tecnologias 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 siste-mática. Posteriormente, os resultados foram apresentados em ordem cronológica.

Por sua vez, a Seção 3.2 apresentou a revisão ad-hoc e os respectivos resultados,ressaltando, principalmente, o estágio de validação das abordagens encontradas.

Na Seção 3.3 foi realizado uma consolidação das características mais relevantes decada abordagem. Por fim, a Seção 3.4 apresentou um conjunto de requisitos, extraídos apartir da análise das abordagens, que uma AS para CI deve atender.

Estes requisitos foram utilizados para guiar o desenvolvimento da proposta destetrabalho. Logo, o próximo Capítulo apresenta esta proposta, utilizando um método dedescrição arquitetural amplamente discutido na literatura (Kruchten, 1995).

40

4Uma Arquitetura de Software para

Cidades Inteligentes baseada na Internetdas 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 aintegração de tecnologias IoT e no conjunto de requisitos que foi definido no Capítuloanterior, este Capítulo visa propor uma AS para CI que permita a combinação comtecnologias IoT. O foco da solução proposta consiste em atender um sub-conjunto destesrequisitos, bem como prover mecanismos, do ponto de vista de infraestrutura, para quenovos requisitos possam ser futuramente incluídos, de acordo com o contexto de cadacidade.

Dessa forma, a Seção 4.1 apresenta este sub-conjunto de requisitos que serão aborda-dos nesta proposta. Já para descrever a proposta detalhadamente é utilizado um métodode descrição de AS’s baseado em visões, conhecido como “4+1”, na Seção 4.2.

Em seguida, cada visão abordará aspectos específicos da AS. A Seção 4.3 apresentaráa Visão Lógica, a partir de um ponto de vista funcional, relacionando os principaismódulos e as operações realizadas com mais frequência. Por sua vez, a Seção 4.4apresentará a Visão de Execução, com o mapeamento dos componentes lógicos emprocessos e threads. A Seção 4.5 apresentará a Visão de Implementação, seguido daSeção 4.6 explicitando a Visão Física. Além das visões deste método, duas outrasvisões definidas pelo SEI (Clements, 2003) foram utilizadas para facilitar a compreensão

41

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

pelos stakeholders: Visão Componente Conector (Seção 4.7) e Visão de Dependências(Seção 4.8).

Por fim, a Seção 4.9 apresentará alguns dos principais cenários de utilização destaAS, do ponto de vista de orgãos governamentais e não-governamentais, cidadãos edesenvolvedores.

Finalmente, a Seção 4.10 consolida as principais características da AS propostadiscutidas neste Capítulo e a Seção 4.11 finaliza o Capítulo.

4.1 Requisitos abordados

A partir da descrição dos requisitos realizada no Capítulo anterior, um sub-conjunto derequisitos foi selecionado para ser abordado nesta proposta de AS. A Tabela 4.1 exibetodos os requisitos e indica quais destes foram abordados nesta proposta, ordenadospela quantidade de abordagens encontradas que visam atender o determinado requisito,conforme ilustrado na coluna #.

Tabela 4.1 Requisitos abordadosRequisito Abordado #

Interoperabilidade de objetos Sim 7Monitoramento 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 foramponderados: i) a importância/relevância do requisito, inferida a partir da quantidade deabordagens na literatura que visam satisfazer esse requisito, conforme pode ser observadona coluna “#”; e ii) este conjunto de requisitos foi incluído nesta proposta são os requisitosmínimos que toda AS de software para CI deve atender.

Os demais requisitos que, mesmo considerados importantes/relevantes, não foramabordados nesta proposta, dificilmente podem ser abordados nesta proposta no estágioatual. A saber:

42

4.2. METODOLOGIA “4+1”

• 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 campanhaspara incentivar 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 desenvol-vido com este escopo. Este trabalho de privacidade será acoplado à esta propostaassim que finalizado. Para isso, as definições de interfaces e padrões de mensagensestão sendo definidas em conjunto. O escopo deste trabalho de privacidade é criarum 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 deserviço urbano.

• 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 à infraestruturana qual 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 pordividi-la em um conjunto de componentes que interagem entre si para realizar parte deuma ou várias funcionalidades do sistema (Garlan and Shaw, 1994).

Porém, diversos autores relatam a falta de eficiência em documentar essas AS’s paraque sejam legíveis para os mais variados stakeholders (Garlan and Shaw, 1994; Clements,2003). Visando atender essa ineficiência, em Kruchten (1995) é proposto um método dedescrição de AS’s baseado em visões chamado “4+1”. Para facilitar a compreensão pelosstakeholders, duas outras visões definidas pelo SEI (Clements, 2003) foram utilizadas:Visão Componente Conector e Visão de Dependências. A integração dessas visões éilustrada na Figura 4.1.

Este uso de múltiplas visões permite abordar separadamente as preocupações de váriosstakeholders da AS: usuários finais, desenvolvedores, engenheiros de sistemas, gerentes

43


Visão Lógica

Visão Implementação

Visão Componente

Conector

Visão Execução

Visão Física

Visão Dependência

Cenários

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

de projetos, entre outros; e permite avaliar separadamente os requisitos funcionais e nãofuncionais. Estas visões abordam aspectos de relevância arquiteturais sob diferentesperspectivas:

• 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;

• 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 doselementos 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.

44

4.3. VISÃO LÓGICA

No contexto de CI, diferentes stakeholders são envolvidos no processo de criaçãode uma solução eficiente, por exemplo, prefeito, secretarias públicas, desenvolvedorese cidadãos. Logo, o método “4+1” foi escolhido e duas visões foram adicionadas paradescrever esta proposta arquitetural justamente para contribuir no entendimento por estesdiferentes 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. Ainterface entre estes elementos também é especificada. A Figura 4.2 ilustra a arquiteturado ponto de vista lógico.

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

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

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

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

45


a comunicação com a AS, a partir da interface REST (Representational state transfer).

De acordo com Blackstock et al. (2010) e Hernández-Muñoz et al. (2011), utilizaruma interface padronizada, como REST, é uma das técnicas empregadas para tornar aAS compatível com as tecnologias móveis, como totens, smartphones e tablets. Estadecisão arquitetural permite que a AS torna-se compatível com o requisito de ubiqui-dade/mobilidade.

Além disso, de acordo com Blackstock et al. (2010) e Filipponi et al. (2010), aprincipal estratégia para que uma AS contemple a interoperabilidade de objetos é permitira comunicação com dispositivos e sistemas através de diferentes protocolos de troca demensagens. Para tal, o MAC contém uma interface padronizada que permite a inserçãode novos adaptadores que implementam os diferentes protocolos de troca de mensagemsob 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çõespara interagir com a AS, por exemplo, operações responsáveis pelo Registro de Recursos,como será detalhado na seção a seguir. De acordo com a operação do método, este delegaação para o respectivo módulo.

4.3.2 Módulo de Gerenciamento de Recursos (MGR)

Do ponto de vista de uma AS para CI, um recurso pode ser considerado sensores espalha-dos 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 dedados (Sanchez et al., 2011; Klein and Kaefer, 2008; Asimakopoulou and Bessis, 2011).

Desta forma, o Módulo de Gerenciamento de Recursos (MGR) visa gerenciar asinformações relativas a estes fornecedores de dados. Dentre essas informações, a geoloca-lização dos sensores deve ser mantida a fim de aumentar a eficiência e a confiabilidade dodado fornecido (Hernández-Muñoz et al., 2011; Shao, 2011; Vega-Barbas et al., 2012).

Para tal, o MGR contém dois sub-módulos: Registro e Configuração de recursos. ORegistro de Recursos contém operações, acessíveis a partir do MAC, que permitem oregistro de um recurso. Além disso, a partir da existênca deste recurso, este sub-módulodisponibiliza todas as informações de um recurso por toda a AS. Já o sub-módulo deConfiguração de Recursos possui operações para gerenciar as configurações do recurso,por exemplo, a frequência de tempo em que os dados são disponibilizados.

46

4.3. VISÃO LÓGICA

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

O Módulo de Gerenciamento e Distribuição de Dados (MGDD) possui a responsabilidadede disseminar os dados por toda AS. Logo, pode ser considerado o core da AS, por (i)atender a maior quantidade de requisitos; (ii) implementar os principais mecanismosque diferenciam esta AS das demais abordagens semelhantes e (iii) implementar toda ainfraestrutura de distribuição de dados.

Um dos padrões mais utilizados no design de AS é o publisher-subscriber, na qual aprincipal vantagem é o desacoplamento entre os produtos e fornecedores de dados (Bus-chmann et al., 1996). O MGDD contém uma implementação deste padrão, representadosna Figura 4.2 pelas 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 dedados para que assim que um novo dado seja disponibilizado, este possa ser recebido eprocessado. Este comportamento é classificado como uma das técnicas para modelar-seeventos do mundo real em AS, pois permite disparar eventos simultâneamente, na qualpode-se ativar um ou mais eventos possivelmente encadeados (Filipponi et al., 2010;Hernández-Muñoz et al., 2011; Sanchez et al., 2011; Wu et al., 2011; Fazio et al., 2012).

A implementação do padrão publisher-subscriber no MGDD também possibilita aadequação à um dos mais importantes requisitos de uma AS para CI: a Composição deDados Urbanos (PlanIT, 2012; Nam and Pardo, 2011; Mostashari et al., 2011). Paratal, um mesmo componente consumidor (subscriber) pode se inscrever em dois oumais canais, obter estes diferentes dados e compô-los de alguma forma. A Seção 4.3.6exemplificará 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çõesdo limite para a criação de canais nas quais dados possam ser trafegados.

Assim que um novo canal de dados é criado, este deve registrar-se na “Distributed

Hash Table (DHT) Canais de Dados”. Esta DHT permite que os canais de dados sejamacessíveis para todos os consumidores, através de consultas pelo tipo de dado que édisponibilizado. Da mesma forma, DHT é utilizada para os fornecedores obterem areferências para os canais mais apropriados para fornecerem seus dados. A Seção 4.3.6exemplificará este cenário com um caso prático.

Além disso, a utilização de uma DHT é importante para prover escalabilidade eprocessamento distribuído. A escalabilidade é obtida a partir da criação de novos canaisde dados, a medida que o sistema se expande. Da mesma forma, como não há limite de

47


consumidores e fornecedores no mesmo canal de dado, a DHT permite a escalabilidadeem termos de recursos de dados.

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

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

O Módulo de Persistência de Dados (MPD) possui a responsabilidade de armazenar osdados 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 éimportante para permitir o desacoplamento entre o respectivo banco de dados com oscomponentes que o utilizam.

Antes de algum recurso realizar uma consulta em um banco de dados específico,este pode ser encontrado a partir da “DHT Banco de Dados”. Por sua vez, essa DHTtem a responsabilidade de gerenciar todos os drivers de banco de dados disponíveis nomomento da transação, além de permitir que os bancos de dados estejam distribuídos emdiferentes 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ódulosda AS.

4.3.6 Operações

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

48

4.3. VISÃO LÓGICA

Tabela 4.2 Mapeamento Requisitos por MóduloRequisito MAC MGR MGDD MPD

Interoperabilidade de objetos X XMonitoramento 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

Consumidor: Recurso receber dados

A Figura 4.3 ilustra uma abstração de um diagrama de fluxo referente as atividades aserem realizadas para que um recurso obtenha um dado. Este diagrama abstrai algu-mas peculiaridades, como a implementação da interface padronizada exigida para ofuncionamento correto 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, areferência é retornada. De posse da referência, o recurso pode se inscrever no respectivocanal. Assim que um novo dado for fornecido por qualquer recurso fornecedor, o dadoserá imediatamente sentregue aos recursos que se inscreveram nesse canal.

MGDDRecurso

Alguém fornece o dado X?

DHT Canais de dados

Referência ao Canal X’

Subscriber

X’

Envio de dados

Novo dado fornecido?

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

49


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á existeum canal no qual o dado é disponibilizado, ou seja, existe pelo menos mais um recursofornecedor que já fornece esse dado; ou (ii) quando é o primeiro recurso fornecedor afornecer 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 dessecanal que corresponde ao primeiro cenário, como ilustrado na Figura 4.4.

MGDDRecurso


DHT Canais de dados


X’

Envio de dados

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

Caso contrário, a DHT retornará uma resposta de que o canal requisitado não existe,como ilustrado na Figura 4.5. A partir desta resposta, o recurso fornecedor deve solicitaruma nova referência de canal para fornecer este tipo de dado, fornecendo as informaçõesnecessárias. Feito isso, a DHT retornará a referência ao novo canal.

De posse da referência ao canal que será fornecido o dado, em ambos os casos, bastao recurso fornecedor enviar os respectivos dados assim que eles estiverem disponíveis.

Compor um dado urbano

A operação de compor um dado urbano pode ser considerada uma combinação entre asoperações de Receber e Fornecer um dado. Como ilustrado na Figura 4.6, esta operaçãoé dividida em 3 fases: Setup, Consumo de Dados e Criação de dados.

A primeira fase, Setup, corresponde aos passos necessários para iniciar uma compo-sição de dados urbanos. Inicialmente, o recurso deve consultar se o canal com o dado

50

4.3. VISÃO LÓGICA

MGDDRecurso


DHT Canais de dados

Canal não existente

Quero novo canal para fornecer dado X


X’

Envio de dados

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

que será combinado já existe. Caso não exista, o recurso deve solicitar a disponibilizaçãodeste canal e a devida referência deve ser retornada.

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

Não há nenhuma restrição na quantidade de dados que podem ser utilizados paracombinação, ou seja, o recurso pode se inscrever em vários canais para utilizar estesdados na combinação.

Feito isso, inicia-se a terceira fase, Criação de Dados. Esta fase corresponde aomecanismo de receber os dados dos vários canais inscritos, combiná-los de alguma formautilizando algum tipo de regra de negócio e disponibilizá-lo no canal obtido na fase deSetup.

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 emque a nova informação combinada é disponibilizada no canal resultante depende da regrade negócio implementada. Por exemplo, um recurso de combinação de dados que geraum relatório das unidades de emergência por regiões de uma cidade pode consumir os

51


MDMDRecurso

Alguém provê o dado X?

Dado X

DHT Canal de Dado

Referência do Canal X’

Alguém provê o dado Y?

Referência do Canal Y

X’ Y’ XY’

SubscribeSubscribe

Dado Y

Combina X e Y

Informação Combinada XY

.

.

.

.

.

.

Canal não existente

Quero novo canal para fornecer o dado XY

Referência ao novo Canal XY’

Setup

Consumo de Dados

Criação de Dados

Alguém fornece do dado XY?

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

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

4.4 Visão de Execução

Esta Seção apresenta o mapeamento dos componentes lógicos da AS em processos 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 ainterface que sera implementada por cada adaptador.

Por sua vez, cada adaptador pode ser executado em um outro processo independente,visto que o único recurso compartilhado é a interface do processo principal. Já em

52

4.4. VISÃO DE EXECUÇÃO

Tabela 4.3 Resumo da quantidade de processos e threads em tempo de execuçãoMó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

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

4.4.2 Módulo de Gerenciamento de Recursos (MGR)

O MGR possui um processo principal que é responsável por conter todas as interfaces dasoperações visíveis aos demais módulos. Além disto, cada cada sub-módulo é executadoem processo separado para que técnicas de cache possam ser futuramente desenvolvidasde forma eficiente.

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, umathread é iniciada para tratar está requisição. A sincronização das informações será feitautilizando técnicas de sincronização por transação.

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

O MGDD possui quatro processos principais: (i) o primeiro corresponde ao processoresponsável pela implementação dos canais de dados; na mesma linha, um processo é ne-cessário para controlar os (ii) consumidores e (iii) outro para os fornecedores; finalmente,(iv) o último processo é responsável por gerenciar a DHT.

Como cada recurso, seja este consumidor ou fornecedor de dado, é independente dosdemais e contém as suas próprias dependências para realizar a computação, uma thread écriada para cada recurso. Da mesma forma, uma thread é criada para cada canal de dado.Esta thread pode ser executada em outro host.

53


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 diferentesmódulos e armazenar no respectivo banco de dados para a predição de eventos futuros.

Da mesma forma que o MGDD, cada instância de banco de dados constitui uma 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 emdomínio público1.

A AS proposta visa atender alguns requisitos considerados como não funcionais,porém não menos importante, como escalabilidade e flexibilidade. Logo, a infraestruturaa ser utilizada para implementação deve ser robusta para atender os diversos sistemasque a utilizarão, além da maciça quantidade de dados. Além disto, como a AS propostacontém vários componentes independentes, a infraestrutura deve proporcionar o deploy decomponentes/adaptadores sem que os demais sejam afetados, conhecido como hot-deploy

(Touseau et al., 2008; Martín et al., 2009).

Neste contexto, a plataforma OSGi consolida-se como uma das mais indicadas paraaplicações na qual hot-deploy é de suma importância (Touseau et al., 2008; Martín et al.,2009). Conforme definido por Gama and Donsez (2010) :

A plataforma de serviço OSGi2 é um middleware universal para desenvolvimento deaplicações modulares, usando princípios de SOA para implementar o desacoplamentoentre componentes. A tecnologia OSGi aproveita a modularização na plataforma Java,que permite instalar, atualizar, para iniciar, parar e desinstalar componentes em tempode execução sem a necessidade de reinicialização do sistema. A plataforma OSGi écomposta por um conjunto de especificações, conduzido por um consórcio de empresas.As especificações são realizadas por diferentes implementações como o Apache Felix3,Equinox4 e Knopflerfish5 (Gama and Donsez, 2010).

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

54

4.5. VISÃO DE IMPLEMENTAÇÃO

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

EQUINOX

Rest Interface

Men-sagem

Registro de

Recursos

Configura-ção de

Recursos

Event Admin

DHT Canal de

Dados

DHT Banco de

Dados

Mongo DB

RestLet GSON C F

MAC MGR MGDD MPD

Figura 4.7 Visão de Implementação

Ao análisar a imagem 4.7, nota-se que o bundle responsável pela MAC contém umadaptador com a implementação inicial de JSON7 utilizando a bibilioteca fornecida peloGoogle Inc. conhecida como GSON8. Este bundle comunica-se ativamente com o bundle

responsável pela comunicação via REST. Por sua vez, o módulo REST implementautilizando o framework Restlet9.

Em relação ao módulo MGR, percebe-se que ele se resume em dois bundles: Registro

6https://www.eclipse.org/7http://www.json.org/8https://code.google.com/p/google-gson/9http://restlet.org/

55


de Recursos e Configuração de Recursos. Estes dois bunddles representam os processodescritos previamente.

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 EventAdmin corresponde à um serviço que contém a implementação de canais dedistribuição de dados, na qual consumidores de dados podem se inscrever nos respectivostópicos de interesse e os fornecedores de dados podem fornecer os dados nestes canais.Na Figura 4.7 as caixas “C” e “P” representam os consumidores e fornecedores dedados. Como pode ser observado, a DHT Canal de Dados comunica-se ativamente com oEventAdmin 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 Canalde Dados, a DHT Banco de Dados utiliza as informações de cada bundle referente a umbanco de dados para gerenciá-lo e oferecê-lo aos demais componentes da AS. Caso umnovo banco de dados seja inserido, basta plugar o respectivo bundle sobre a plataformaOSGi Equinox e registrá-lo na DHT de Banco de Dados.

4.6 Visão Física

Esta Seção visa descrever os requisitos físicos mínimos para utilização da AS proposta.

Por se tratar de um ambiente distribuído, com vários acessos exigindo o máximo deescalabilidade, é 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 doserviço Amazon AWS11. A Tabela 4.4 resume as principais características de hardware esoftware dessa infraestrutura.

Para a utilização em um ambiente real de produção é evidente que esta configuraçãonão é suficiente. Nesse contexto, deve-se analisar as soluções de Cloud oferecidas pelosprovedores para obter melhor desempenho da AS, como por exemplo, Amazon DynamoDB12 e Amazon Elastic Map Reduce13.

10http://www.mongodb.org/11http://aws.amazon.com/12http://aws.amazon.com/dynamodb/13http://aws.amazon.com/elasticmapreduce/

56

4.7. VISÃO COMPONENTE CONECTOR

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

HardwarePlano 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

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 odiagrama de componente conector desta proposta.

Figura 4.8 Diagrama de Componente Conector

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

57


recurso fornecer ou consumir um dado, este deve usar o conector existente entre oscomponentes 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 outrocomponente REST.

O MGDD contém uma porta para cada canal de dado. Esta porta é uma abstraçãopara a comunicação realizada com os diversos Recursos consumidores ou fornecedoresde dados. Além disto, o MGDD contém um componente denominado DHT com asresponsabilidades já descritas na Seção Visão Lógica. Como pode ser observado, oMGDD possui um conector para cada recurso associado à um canal.

Por sua vez, o MPDD possui conectores associados aos módulos MGR e MGDDpara que as informações trafegadas nestes dois módulos possam ser armazenadas para apredição de eventos futuros. Além disto, uma porta é associada à cada instância de bancode 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.

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 componentesRecurso e Dado estar logicamente declarados no MGR. Logo, o MGDD depende do MGRpara interagir com os recursos inscritos em cada canal, além de gerenciar os respectivosdados.

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 que um recurso consiga receber de fato os dados é necessário utilizar os mecanismosprovidos pelo MAC.

58

4.9. CENÁRIOS

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ódulospossam ser armazenadas para a predição de eventos futuros.

4.9 Cenários

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

4.9.1 Desenvolvimento de aplicações móveis

Um desenvolvedor pode criar aplicações móveis que consumam informações das cidadese mantenham seus usuários atualizados sobre os acontecimentos. Por exemplo, umaaplicação que identifique os pontos de alagamento em uma avenida ou registre regiõesafetadas pela falta de energia.

Do ponto de vista da arquitetura proposta, esta proposta deveria ser implementadada seguinte forma. Um recurso, correspondendo à aplicação, deve realizar todas asinterações com a arquitetura através da interface REST, disponível do MAC. O primeiropasso é registrar à aplicação como um recurso no MGR. Para isto, a aplicação deveinvocar o respectivo método oferecido pelo MAC, provendo as devidas informações dorecurso.

Em seguida, este recurso deve consultar a “DHT Canais de Dados” para obter asreferências para todos os canais que oferecem as informações relevantes da respectivacidade. Após se inscrever nestes canais, assim que um novo dado é disponibilizado, aaplicação deve recebê-los a partir de consultas REST. De posse destes dados, a aplicaçãopode exibi-los da maneira mais adequada.

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

As companhias de gerenciamento de trânsito das cidades podem utilizar esta arquiteturapara emitir informações de trânsito da cidade. Para isso, basta registrar cada sensor comoum recurso fornecedor de dado na arquitetura. Estes sensores podem ser as câmeras detrânsito, informações de veículos em radares e quantidade de veículos nas cabines depedágio por minuto.

Além disso, será necessário registrar um recurso consumidor no MGR responsávelpor se inscrever nos canais nas quais estão informações serão fornecidades. A partir disto,

59


este recurso deve interpretar estas informações e gerar os alertas de acordo com a situaçãodo 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 dosproblemas da cidade estejam trafegando pelos diferentes canais do MGDD, basta umrecurso, representando o sistema da secretaria se inscrever nestes canais.

A medida que um dado é disponibilizado, este recurso pode consolidar estas informa-ções em forma de gráfico ou até mesmo notificar os respectivos responsáveis, além deestimar o custo para resolver aquele problema.

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

Um sistema pode ser desenvolvido para predizer catastrófes em áreas de riscos. Paraisto, este sistema deve se registrar no MGR como um recurso consumidor de dados. Emseguida, 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 umatécnica de Rede Neural. Estas informações contextualizadas devem ser fornecidades emoutro canal para que outros recursos possam utilizá-las para alguma outra finalidade.

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

4.10 Discussão do Capítulo

O conjunto de cenários descrito constitui exemplos de utilização da AS. Por ser uma ASpara propósito genérico, esta pode ser facilmente adaptada para os contextos locais decada região. Pode-se imaginar diversos cenários de utilização, desde uma região litorâneautilizar a AS para executar programas de balneabilidade até o controle de obesidade dosidosos de uma regiã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

60

4.11. CONSIDERAÇÕES FINAIS DO CAPÍTULO

concebida para ser aplicada em uma cidade, esta AS pode ser implementada em diversasescalas, como um prédio (Smart Build) e residências (Smart Home).

A partir desta flexibilidade, governos e instituições podem usar esta AS para criarvárias instâncias federativas, como por exemplo, uma instância para região de Sorocaba,outra para Campinas e uma última para a região metropolitana de São Paulo. A partirdessa 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 su-ficientes para testes em pequena escala, porém não serão suficientes no ambiente deprodução real. Esta fato se deve principalmente a fatores relacionados a concorrência,acessos simultâneos e performance.

Logo, esse quesito prático não pode ser considerado suficiente para a avaliação daproposta. Dessa forma, o Capítulo seguinte descreve um método para avaliação da ASproposta, 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 ométodo de descrição de AS’s utilizado, conhecido como “4+1”, que, quando combinadocom duas outras visões definidas pelo SEI, se mostrou ser bastante efetivo para o contextodeste trabalho.

Em seguida, a AS proposta foi apresentada, de acordo com as visões do método:Lógica (Seção 4.3), Execução (Seção 4.4), Implementação (Seção 4.5), Física (Seção 4.6),Visão Componente Conector (Seção 4.7) e Visão de Dependências (Seção 4.8). A VisãoLógica apresentou, a partir de um ponto de vista funcional, os principais módulos e asoperações frequentemente realizadas. Por sua vez, a visão de Execução mostrou o mape-amento dos componentes lógicos em processos e threads. A Visão de Implementaçãoapresentou a implementação de referência que foi realizada e está disponível ém domíniopúblico14. A Visão Física relatou algumas características de hardware utilizadas para estáimplementação de referência. Por fim, as duas visões definidas pelo SEI foram descritaspara facilitar a compreensão pelos stakeholders.

Ao término das descrições das Visões, pode-se compreender as responsabilidadese a comunicação entre os seis módulos da AS proposta. O módulo MCA correspondeao ponto de comunicação da AS com os sistemas externos. Já o MGR corresponde à

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

61


manutenção dos recursos na AS, principalmente ao cadastro e configuração dos mesmos.Por sua vez, o módulo MGDD é responsável por difundir os dados de/para os recursosna AS. Finalmente, o módulo MPD é responsável por armazenar todas as informaçõesrelevantes, em qualquer ponto da AS, para consultas posteriores.

Esse conjunto de módulos compõe a proposta que visa agregar valores para oscidadãos das cidades do Brasil. Alguns desses cenários foram discutidos neste Capítulo(Seção 4.9), ressaltando principalmente o ponto de vista das entidades que podem proporestratégias em prol do cidadão.

Finalmente, a Seção 4.10 abordou algumas características importantes da AS proposta.A partir da descrição da AS reaizada neste Capítulo, o próximo Capítulo descreve um

método para avaliação, baseado em dois métodos: SAAM e ATAM.

62

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 umaimportante ferramenta para quantificar a qualidade de um software a partir da sua des-crição AS (Kazman et al., 1994). De fato, alguns experimentos industriais mostraramque a aplicação de métodos de avaliação de AS gera ganhos consideráveis durante odesenvolvimento de software. Em Maranzano et al. (2005) são relatados vários exemplosda utilização do processo de valiação de AS em grandes empresas, como AT&T1 e Lucent

Technologies2. Maranzano et al. (2005) demonstram que o uso de tal abordagem nestasempresas gerou um ganho de cerca de 1 milhão de dólares em cada projeto que teve seusproblemas 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 objetivode identificar as falhas antes que se tornem grandes problemas no futuro. Logo, a partirda descrição de módulos realizada no Capítulo anterior, este Capítulo visa avaliar a ASproposta.

Para tal, inicialmente, serão apresentados alguns métodos de avaliações de AS’sdisponíveis na literatura (Seção 5.1). Ao analisar esses métodos, foi concluído quenenhum deles atendia o contexto deste trabalho. Logo, a Seção 5.2 propõe uma adaptaçãode dois métodos de avaliação de AS’s amplamente aceitos e validados na literatura

1http://www.att.com/2http://www.lucent.com/

63

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

(Roy and Graham, 2008): SAAM (Kazman et al., 1994) e ATAM (Kazman et al., 1999,2000). Posteriormente, será discutido o processo adotado durante a avaliação desta AS(Seção 5.3).

Em seguida, a Seção 5.4 discute alguns resultados e comentários a respeito dasprincipais questões que surgiram durante a avaliação desta AS. Além disso, a Seção 5.5discute as principais ameaças à avaliação realizada.

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 afim de minimizar custos.

Para realizar tal procedimento, um método de avaliação é utilizado para guiar osprocedimentos de execução e auxiliar na interpretação dos resultados. Embora os métodosde avaliação de AS possam variar quanto às técnicas que utilizam, pode-se dizer que, deuma maneira geral, os métodos possuem um propósito em comum (Kazman et al., 2005).Este propósito é: investigar se uma determinada AS satisfaz os objetivos de negócio dosistema 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 contextos deexecução, como pode-se constatar nos relatos de Roy and Graham (2008), Shanmugapriyaand Suresh (2012); Bass and Nord (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 utilizadafoi os atributos de qualidade (QA) que o método visa avaliar. Como a AS proposta nãopossui uma única finalidade, que possa ser avaliada por um único atributo de qualidade,optou-se por adotar métodos que compreendem vários atributos de qualidade. A Tabela5.1 apresenta os métodos encontrados, nas referências relatadas anteriormente, quesatisfazem esse pré-requisito.

64

5.1. MÉTODOS DE AVALIAÇÃO

Tabela 5.1 Métodos de Avaliação Vs Atributos de QualidadeMé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 Tabela5.2 apresenta o objetivo de cada método resultante do pré-requisito anterior.

Tabela 5.2 Métodos de Avaliação Vs ObjetivoMé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 uti-lizados, pois não há nenhuma outra AS, disponível e amplamente aceita na literatura, quepossa ser comparada com a AS proposta, devido a falta de especificação e detalhamentoarquitetural.

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 umabreve descrição de cada um desses métodos é apresentada.

5.1.2 Descrição dos métodos restantes

• SAAM (Software Architecture Analysis Method) é um método de avaliação 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, extensibili-dade e integrabilidade (Qun-li and jie, 2008).

65


O método SAAM inclui 6 atividades: (i) desenvolvimento dos cenários; (ii) descri-ção da AS avaliada; (iii) classificação e priorização dos cenários; (iv) avaliação 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 ATAMrevela quão bem uma AS satisfaz os requisitos de qualidade desejados, além de iden-tificar os riscos arquiteturais e os conflitos (trade-offs) existentes para se alcançartais requisitos (Qun-li and 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 epriorização dos cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentaçãodos Resultados (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 asseguintes peculiaridades:

• A equipe de avaliação estava distribuída geograficamente, com rotinas e compro-missos diferentes. Logo, a avaliação deveria ser totalmente remota;

• Na equipe de avaliação, não há nenhum stakeholder com domínio em ambos ostemas de pesquisa que envolvem esta proposta (CI e IoT);

• Não foi encontrada nenhum método de avaliação para o contexto de equipesdistribuída geograficamente;

• Como as reuniões seriam realizadas por Skype, as reuniões deveriam ser curtaspara manter a equipe concentrada.

66

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

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

Tabela 5.3 Etapas do método adaptado1º 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

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 desistemas heterogêneos, as pessoas escolhidas para participar da equipe são de diferentesáreas de pesquisa, com diferentes experiências e visões. Além disso, a heterogeneidadeda equipe enriquece as discussões, pois cada um avalia o mesmo quesito por diferentespontos de vista, baseado nos respectivos backgrounds (Clements, 2003).

Esta equipe foi composta por desenvolvedores e arquitetos provenientes do C.E.S.A.R,professores do CIN-UFPE e da UFSCar Sorocaba. Ao total, 5 pessoas foram envolvidasno processo de avaliação. A Tabela 5.4 ilustra as expertises dos envolvidos, na quala coluna “#” ilustra a quantidade dos envolvidos com a determinada expertise. Valeressaltar que um mesmo envolvido pode ter mais de uma expertise.

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

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

67


Tabela 5.4 Expertises da equipe de avaliaçãoExpertise #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

participante da equipe de avaliação com a visão de negócio deve apresentar as expectativasde uma AS para CI que combine IoT. Esta etapa é de suma importância, pois estasexpectativas serão utilizadas para quantificar o quão a AS proposta atende aos objetivosestabelecidos.

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,este método deve fornecer subsídios suficientes para o completo entendimento da AS porparte dos demais participantes, incluindo interações entre os módulos, regras de negóciose o ciclo de vida dos componentes (Kruchten, 1995).

Em seguida, deve-se realizar a etapa de priorização dos atributos de qualidade combase nos objetivos de negócios, previamente discutidos. Para tal, recomenda-se que oarquiteto sugira um conjunto de atributos de qualidade pré-selecionados que possamser empregados. A literatura apresenta alguns métodos de priorização dos atributosde qualidade, porém o mais usual é estabelecer que cada participante possui 3 votosque deve ser distribuído dentre os atributos de qualidade. Após todos os participantesvotarem, os atributos de qualidade que receberem mais votos devem ser consideradosmais prioritários.

A contexualização sobre o que são cenários para toda a equipe de avaliação deveser realizada a seguir. Um cenário, neste contexto, ilustra os tipos de atividades que umsistema deve suportar. Um exemplo de cenário pode ser: “Qual o impacto na arquitetura

caso ocorra uma mudança no modelo de troca de mensagens entre os componentes”. Valeressaltar que o desenvolvimento desses cenários é crucial para capturar os principais usosdo sistema, seus usuários, antecipar mudanças no sistema, e qualidades que o sistema devesatisfazer agora e no futuro. Estes cenários devem ser elicitados por todos os stakeholders

do sistema a partir dos objetivos de negócios, logo, representam questões sob diferentes

68

5.3. PROCESSO DE AVALIAÇÃO EXECUTADO

pontos de vista e, na maioria das vezes, trazem informações bem específicas do sistemaavaliado.

Antes da próxima etapa deste processo de avaliação é importante criar algum meca-nismo para que os participantes possam propor os possíveis cenários. Uma técnica quepode ser utilizada é o compartilhamento de uma planilha online entre cada participante eo 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.Em seguida, todos devem priorizar os cenários de acordo com a relevância para a ASproposta. Esta priorização pode ser feita da mesma forma que a priorização dos QAs.

Para a próxima etapa, de avaliação dos cenários propostos, também é interessantecriar um mecanismo para que seja realizada remotamente. Um exemplo é a criação de umformulário online na qual cada participante deve dar uma nota para o quão cada cenárioestá contemplado pela 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 peloATAM. Geralmente estas discussões geram conclusões de que, para atender a um cenárioespecífico, mas muito relevante, deve-se deixar de implementar totalmente um atributode qualidade.

Por fim, o arquiteto deve apresentar os resultados finais do processo de avaliação.Nesta etapa é importante apresentar todos os artefatos gerados em cada etapa do processode avaliação. Além disso, devem ser apresentados os pontos positivos e os pontos demelhoria que, a partir do processo executado, foram identificados.

5.3 Processo de Avaliação Executado

A partir da descrição do processo de avaliação na Seção anterior, o processo foi 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.

69


As etapas da reunião foram as seguintes:

1. Apresentação do Processo de Avaliação (Duração 30min): Inicialmente, foidescrito a origem da adaptação dos métodos, ressaltando as principais diferençascom os métodos disponíveis na literatura. Consequentemente, o processo deavaliação a ser utilizado foi descrito. O objetivo desta etapa foi situar todos osenvolvidos em relação ao objetivo do processo e aos próximos passos;

2. Objetivos de Negócios (Duração 30min): A segunda etapa da reunião teve aintenção de definir e apresentar os objetivos de negócios da AS proposta. Estepasso foi importante para que os participantes da avaliação entendessem o contextodo sistema 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;

3. 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 foi deta-lhado, 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 neces-sidades dos contextos de CI. Além disso, por meio desta descrição detalhada épossível identificar possíveis falhas e/ou pontos de melhoria na AS proposta;

4. Priorização dos Atributos de Qualidade (Duração 1hora): Como alguns parti-cipantes não estavam acostumados ao conceito de Atributos de Qualidade, ini-cialmente foi descrito o que são e quais os objetivos dos mesmos. Em seguida,o arquiteto apresentou os atributos de qualidade definidos pela ISO/IEC 9126(ISO/IEC, 2001) e pelo CMU/SEI-95-TR-021 (Barbacci et al., 1995), com o obje-tivo de exemplificar possíveis atributos de qualidade aplicáveis à AS proposta.

Ao término dessa etapa, os participantes sugeriram alguns atributos de qualidade,com base nos objetivos de negócios. Em seguida, foi realizado uma votação parapriorizar quais os atributos melhor expressam os objetivos de negócios, apresen-tados anteriormente. Nesta votação, cada participante poderia distribuir 3 votosentre os atributos de qualidade. Cada voto foi computado individualmente a partirde um formulário online disponibilizado para cada envolvido. A Tabela 5.5 exibe

70


o resultado desta votação. A coluna “fonte”, refere-se à origem do atributo dequalidade, na qual “participante” são os atributos propostos pelos participantes daavaliaçã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 quando neces-sário;

• Funcionalidade: conjunto de atributos que evidenciam a existência de umconjunto de funções e suas propriedades especificadas. As funções são as quesatisfazem as necessidades explícitas ou implícitas;

• Escalabilidade: capacidade que um sistema possui de se expandir, de formaa permitir o atendimento das necessidades pelo crescimento do número deusuários do sistema, ou também pelo aumento das informações a seremprocessadas;

• Portabilidade: capacidade do sistema ser transferido de um ambiente paraoutro;

• Disponibilidade: refere-se ao conjunto de atributos que interferem na proba-bilidade de que um sistema esteja funcionando e pronto para uso em um dadoinstante de tempo;

• Segurança: refere-se ao conjunto de propriedades da arquitetura que inter-ferem diretamente na garantia da integridade dos dados da aplicação e noacesso aos mesmos;

71


• Performance: visa quantificar se a arquitetura computará os dados em tempohábil, coerente com o contexto da requisição;

• Eficiência: conjunto de atributos que interferem diretamente nos tempos deresposta de um sistema;

• Usabilidade: conjunto de atributos que evidenciam o esforço necessário parase poder utilizar o software, bem como o julgamento individual desse uso,por um conjunto explícito ou implícito de usuários;

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

• Manutenabilidade: atributos do software que evidenciam o esforço necessá-rio para modificá-lo, remover seus defeitos ou adaptá-lo a mudanças.

5. Contextualização sobre Cenários (Duração 20min): O último passo dessa pri-meira reunião, foi a contextualização sobre cenários. Da mesma forma como osatributos de qualidade, inicialmente foi realizada uma breve apresentação sobreo que são e quais as necessidades dos cenários. Em seguida, alguns cenáriosforam 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 elespudessem detalhar os cenários de utilização da AS com base nos objetivos de negó-cios. Para isso, um prazo de 4 dias foi estipulado para que todos os participantesdescrevessem os possíveis cenários.

5.3.2 Segunda Reunião

A Segunda Reunião foi marcada uma semana depois da primeira reunião, para mitigar orisco dos participantes esquecerem algum tópico abordado.

Após os 4 dias estipulados para que todos os participantes descrevessem os cenários,o arquiteto consolidou todos os cenários. Esta consolidação resumiu-se em, basicamente,filtrar os cenários duplicados e reescrever alguns com outras palavras para facilitar acompreensão dos demais participantes. Apenas 2 cenários foram considerados duplicadose 1 precisou ser reescrito.

1. Apresentação dos Cenários (Duração 30min): Nessa primeira etapa da segundareunião, foram apresentados todos os cenários propostos pelos participantes da

72


avaliação no prazo estipulado. Como vários participantes possuem diferentesvisões e experiências, foram identificados diferentes nichos de aplicabilidade daAS proposta, por exemplo, em contextos totalmente distribuídos ou, até mesmo,em contextos federados.

2. Priorização dos Cenários (Duração 1hora): A segunda etapa foi uma discussã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.

3. Avaliação dos Cenários propostos (Duração 1hora): Em seguida, os cenáriospriorizados foram avaliados e discutidos sobre a AS proposta. O principal objetivofoi avaliar o quão os cenários levantados condizem com a natureza da AS proposta.

Ao término desta reunião, os cenários resultantes são exibidos na Tabela 5.6, ordena-dos de acordo com a priorização.

5.3.3 Terceira Reunião

Da mesma forma que a Segunda Reunião, a Terceira e última reunião foi marcada umasemana depois. O objetivo primordial dessa reunião foi consolidar os resultados e definiras possíveis ações a serem tomadas para aprimorar a proposta.

Para tal, foi criado um formulário online com todos os cenários, ordenados por ordemde priorização. O objetivo deste formulário foi de mensurar quantitativamente o quão aAS contempla cada cenário.

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

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

73


Tabela 5.6 Cenários resultantes de acordo com a relevânciaID 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

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 entendimentodos requisitos.

Logo, conforme descrito na Seção anterior, para mensurar quantitativamente o quãoa AS contempla cada cenário, foi criado um formulário online com todos os cenários,ordenados por ordem de priorização. Neste formulário, cada participante deveria atribuiruma nota para a adequação de cada cenário, na qual 5 representa que a AS ATENDETOTALMENTE e 0 significa que NÃO ATENDE ao cenário em questão.

74

5.4. RESULTADOS DA AVALIAÇÃO DA ARQUITETURA

A partir deste formulário, foram obtidas algumas conclusões, que serão 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 odesvio padrão das respostas, além de 3 faixas de satisfatoriedade, definidas pelos própriosparticipantes da avaliação.

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

Para analisar os resultados na Figura 5.1, deve ser considerada a relevância doscenários propostos, priorizados durante o processo de avaliação.

Como é possível notar, na opinião dos participantes, a AS atende à três cenáriosde maneira EXCELENTE. O primeiro cenário (C2) é relacionado aos mecanismosde distribuição de dados implementados no MGDD (Seção 4.3.3), principalmente autilização da DHT de dados. Conforme discutido, a utilização da DHT permitiu que osrecursos fornecedores e consumidores e os canais de dados estejam distribuídos em umainfraestrutura de cloud.

Já o segundo cenário categorizado como EXCELENTE (C4) foi obtido a partir daimplementação do padrão publisher-subscriber também no MGDD. Esta implementaçãopermite que um dado seja disponibilizado para todos os recursos consumidores assimque é produzido. No contexto de CI, esta característica básica é de suma importância setodos os consumidores receberam os dados simultâneamente e está contemplada nestaproposta. Além disso, o desacoplamento entre fornecedores e consumidores de dadosoriundos a partir do padrão publisher-subscriber também é de suma importância para

75


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 novosprotocolos de troca de mensagens sejam inseridos sob demanda. Já a flexibilidade estárelacionada à capacidade de trocar a interface REST ou, até mesmo, incluir outro padrãoem 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 aum conjunto de contextos de utilização, ela deve ser aprimorada para atender de maneirasegura e eficiente aos demais contextos.

Além disso, dois cenários foram classificados como PÉSSIMO. O primeiro (C9) estárelacionado à inserção de algum mecanismo de tolerância a falhas. Não foi encontradonenhum mecanismo semelhante nas abordagens encontradas na literatura. Porém, nocontexto de uma CI é inadmissível que todo o sistema da cidade deixe de funcionar devidoà um problema em algum módulo ou componente de software. A literatura apresentadiversas técnicas de redundância, tanto de dados como de componentes de software, quedevem ser inseridas na proposta. Além disso, estratégias de backup, controle de acesso edemais aspectos relacionados à confiabilidade da 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 requisitonão faz parte desta AS. Além disso, esta necessidade foi identificada no começo destapesquisa, porém um outro trabalho de mestrado está sendo desenvolvido com este escopo.Este trabalho de privacidade será acoplado à esta proposta assim que finalizado. Para isso,as definições de interfaces e padrões de mensagens estão sendo definidas em conjunto. Oescopo deste trabalho de privacidade é criar um mecanismo em que, a partir das interaçõesanteriores, os cidadãos possam “negociar” o quão seus dados estarão disponíveis para umdeterminado provedor de serviço urbano.

5.4.2 Resultados Gerais

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

Primeiramente, o fato de dois de três cenários categorizados como EXCELENTEestarem diretamente relacionado ao MGDD era esperado. O MGDD pode ser consideradoo core da proposta, principalmente devido ao módulo de distribuição de dados utilizado.

76

5.5. AMEAÇAS À AVALIAÇÃO

Este modelo, utilizando o padrão publisher-subscriber foi encontrado em outros contextose adaptado para esta proposta. Além disso, a alta quantidade de requisitos que o MGDDvisa satisfazer representa os principais diferenciais desta proposta com as demais.

Este fato alerta para possíveis problemas relacionados ao acoplamento do MGDDcom o restante da AS. Por exemplo, deve-se prever e criar mecanismos para mitigar ospossíveis problemas no MGDD relacionados à indisponibilidade da DHT Canais de Da-dos. Caso isso aconteça, os demais módulos devem continuar funcionando corretamentea partir de mecanismos de redundância.

Além disso, de acordo com os participantes, não é necessário descrever um novopadrão arquitetural para o contexto de CI e IoT. Esta conclusão foi obtida a partir daavaliação de que a proposta atual contempla alguns padrões arquiteturais e já atendediversos 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,como trabalho futuro, a proposta atual será implantada em um ambiente real por meio deparcerias com orgãos interessados.

5.5 Ameaças à Avaliação

Na avaliação da arquitetura descrita previamente, algumas ameaças foram identificadas.Estas ameaças não afetam diretamente o resultado final desta avaliação, porém devem 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áreas de uma cidade, como recomendado por Clements (2003), se mais pessoas tivessemparticipado da avaliação outros pontos de vistas poderiam ser levantados. Infelizmente,este pequeno número de participantes foi devido à disponibilidade do grupo de pesquisapara a realização das três reuniões mencionadas.

A outra ameaça está relacionada com a ordem das etapas do método de avaliação.Como apresentação da arquitetura foi realizada antes da definição e priorização dosatributos de qualidade e dos cenários, a opinião dos participantes pode ter sido enviesada.Apesar disto, no inicio das etapas de definição e priorização dos atributos de qualidadee dos cenários foi ressaltado que as opiniões deveriam ser a partir da apresentação dosobjetivos de negócios. Logo, uma melhoria no método de avaliação é alterar a ordemdestas etapas.

77



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 ocontexto da avaliação a ser executada.

Após estes filtros, os métodos SAAM e ATAM foram considerados os mais indicados.Porém, a versão original destes métodos não condiz com o contexto desta avaliação. Logo,a Seção 5.2 propôs uma adaptação destes dois métodos de avaliação de AS’s amplamenteaceitos e validados na literatura.

Finalmente, a Seção 5.3 apresentou todas as etapas do processo de avaliação executado.Por fim, a Seção 5.4 discutiu os principais resultados da avaliação.

A partir da avaliação realizada, pode-se mensurar o quão a AS está apta para serimplantada em um contexto real. Dessa forma, o próximo Capítulo finaliza o trabalhodescrevendo as principais conclusões e as atividades futuras, como implantar a AS emum ambiente real e controlado.

78

6Conclusão

Feliz aquele que transfere o que sabe e aprende o que ensina.

—CORA CORALINA, 2007 (Vintém de cobre: meias confissões deAninha. 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á organi-zado da seguinte maneira: a Seção 6.1 apresenta um resumo das principais conclusõesdeste trabalho. A Seção 6.2 relata alguns trabalhos relacionados. A Seção 6.3 apontaum conjunto de trabalhos futuros, e finalmente, a Seção 6.4 contém a conclusão final dadissertaçã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ãorelacionados 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 IoTcomo ferramenta para a implementação, de fato, de uma CI. Neste contexto, as

79

CAPÍTULO 6. CONCLUSÃO

tecnologias IoT são utilizadas, principalmente, para monitorar, controlar e atuarsobre os diversos serviços urbanos (Capítulo 2).

• Na literatura, várias abordagens estão sendo desenvolvidas com este paradigma.Porém, a maioria destas abordagens focam em apenas um conjunto muito restritode serviços urbanos e não consideram a integração entre estes serviços (Capítulo3).

• A AS proposta por esta dissertação permite que os dados entre os diferentesserviços urbanos sejam difundidos para todos os recursos interessados. Para tal, aAS implementa um padrão arquitetural bastante conhecido na literatura chamadode publisher-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 vezque os principais benefícios citados na teoria, tais como composição de dadosurbanos, foram confirmados (Seção 5.4).

6.2 Trabalhos Relacionados

Em PlanIT (2012) foi adotada uma estratégia de implementar um Sistema OperacionalUrbano (UOS). Este sistema operacional consiste em uma plataforma que visa integrarcada domínio que compõe a cidade. O sistema é alimentado por uma vasta rede desensores e todos esses dados são capturados por tempo indeterminado, para auxiliar natomada e na predição de decisões. Além de prever catástrofes, caso ocorra, o sistema podeantever todos os possíveis impactos na cidade. As principais diferenças da abordagem dePlanIT (2012) e esta proposta são a parceria com setor privado (PlanIT (2012) possui umaparceria com Cisco e Microsoft) e o modelo de distribuição de dados, uma vez que nomodelo adotado em PlanIT (2012) a disponibilização de um novo tipo de dado é custosa,do ponto de vista arquitetural.

Outra abordagem em que se utilizam vários sensores embarcados nos contextos urba-nos é SmartSantander (Sanchez et al., 2011). A quantidade de dispositivos configuradosna AS é superior à 12.000. O SmartSantander provê: i) um modelo de refência de arquite-tura para sistemas IoT do mundo real; ii) um escalável, heterogêneo e confiável facilitadorde experimentos; iii) um conjunto representativo de casos de uso implementados parafacilidades de experimentação e iv) um grande conjunto de experimentos e resultadossobre o futuro da internet. A principal diferença da abordagem descrita por Sanchez et al.

80

6.2. TRABALHOS RELACIONADOS

(2011) com esta proposta, além da parceria com o setor privado, são os mecanismos quepermitem a composição de dados urbanos. Na proposta deste trabalho, assim que umdado novo é disponilizado, permite-se a criação de um novo canal para este dado. Alémdisto, esta proposta contempla mecanismos de gereção de histórico, que é fundamentalpara a tomada de decisões futuras.

Por sua vez, em Filipponi et al. (2010) a integração de sensores é abordada a partirde uma AS 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 domundo real (como detecção de presença) ou ao término de algum processamento. Aabordagem de Filipponi et al. (2010) é bastante similar com esta proposta no quesito demodelagem do ambiente real. Porém, a principal diferença é a existência nesta propostade um mecanismo para geração de histórico para a previsão de futuros eventos. Alémdisto, as informações de cada sensor que está fornecendo os dados pode ser utilizadapara otimizar o desempenho dos algoritmos (Shao, 2011; Hernández-Muñoz et al., 2011;Vega-Barbas et al., 2012).

Neste sentido, em Hernández-Muñoz et al. (2011) é proposta uma AS (USN), com oobjetivo de prover uma infraestrutura que seja capaz de integrar sensores heterogêneose dispersos geograficamente em um base centralizadora, na qual serviços podem serfacilmente desenvolvidos. Esta abordagem de Hernández-Muñoz et al. (2011) é similar aesta proposta nas técnicas adotadas para permitir a integração de sensores heterogêneos.A principal diferença é que nesta proposta novos protocolos de troca de mensagens podemser facilmente inseridos. Além disto, o custo para integrar diferentes fornecedores dedados nesta proposta é muito baixo para otimizar o desempenho em larga escala.

Finalmente, em Al-Hader et al. (2009) é proposta uma AS baseada em quatro prin-cípios: aplicações, negócios, gerenciamento de processos e infraestrutura de redes. Oprimeiro princípio corresponde às aplicações que fazem uso de diferentes tecnologiaspara monitorar sensores, como GPS. A maioria dessas aplicações atendem as demandasoperacionais das cidades, porém, ao utilizar as regras definidas no segundo princípio -negócios - elas podem agregar soluções economicamente viáveis. O terceiro princípio é ogerenciamento de processos no qual relacionamentos, regras, estratégias e políticas entreas aplicações e as unidades de negócios são definidos. O último princípio corresponde atoda a infraestrutura de rede, responsável por conectar os outros três princípios. A princi-pal diferença da abordagem de Al-Hader et al. (2009) para esta proposta é a criação deum componente específico para modelos de negócio. Este diferencial pode ser facilmenteincorporado nesta proposta, uma vez que este componente poderia ser um consumidor de

81

CAPÍTULO 6. CONCLUSÃO

dado que, a partir dos dados que estão trafegando na arquitetura, inferir um modelo denegócios eficaz com estas informações.

Ao analisar os principais trabalhos relacionados, pôde-se observar que todos visammitigar apenas uma deficiência tecnológica relacionada à CI. Apenas a abordagem dePlanIT (2012) visa integrar as informações provenientes de diferentes domínios de umacidade, o que pode contribuir 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 juntamentecom esta proposta, este refleta uma série de características que qualquer Arquitetura deSoftware (AS) para Cidade Inteligente (CI) deveria atender.

Os resultados desta dissertação estão baseados em um trabalho de pesquisa queanalisou o estado da arte e da prática no tocante as AS’s de software para CI quecombinam tecnologias IoT. Estes resultados envolvem, entre outras coisas: (i) umlevantamento das soluções existentes, (ii) a extração de um conjunto de requisitos queuma AS para CI deve atender, (iii) o projeto da AS, (iv) a avaliação preliminar da AS e(v) uma implementação de referência.

6.3 Trabalhos Futuros

A versão inicial desta AS não contempla algumas características, principalmente 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ãopela AS, torna-se indispensável a adequação de políticas de privacidade, principal-mente relacionadas ao armazenamento, utilização e descarte dos dados;

• Modelo de Negócio: Modelos de negócios devem ser discutidos para suprir oscustos envolvendo a implementação, manutenção e expansão desta AS no ambientereal. Uma estratégia que deve ser discutida é a parceria com governos e empresaspara a utilização desta AS;

82

6.4. CONCLUSÃO

• Análises de big data: Com o alto volume de dados potencialmente gerado a partirda utilização desta AS, análises de big data devem ser feitas para otimizar odesempenho dos 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áalinhado com o desenvolvimento das infraestruturas e dos principais serviços urbanos.A precariedade destes serviços urbanos afeta negativamente a qualidade de vida doscidadã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 desen-volvidas considerando as partes envolvidas: governo e cidadãos. Além disso, torna-seimportante que os cidadãos estejam conscientes do seu papel em prol de uma cidademelhor 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 AS foi proposta a partir de um conjunto de requisitos mais importante extraído dasprincipais abordagens disponíveis na literatura.

83

Referências Bibliográficas

Al-Hader, M., Rodzi, A., Sharif, A., and Ahmad, N. (2009). Smart city componentsarchiticture. In Computational Intelligence, Modelling and Simulation, pages 93–97.

Andreini, F., Crisciani, F., Cicconetti, C., and Mambrini, R. (2011). A scalable archi-tecture for geo-localized service access in smart cities. In Future Network & Mobile

Summit, pages 1–8. IEEE.

Anthopoulos, L. and Fitsilis, P. (2010). From digital to ubiquitous cities: Defining acommon architecture for urban development. In Proceedings of the 6th International

Conference on Intelligent Environments, pages 19–21.

Asimakopoulou, E. and Bessis, N. (2011). Buildings and crowds: Forming smart citiesfor more effective disaster management. In Innovative Mobile and Internet Services in

Ubiquitous Computing (IMIS), 15th International Conference, pages 229–234. IEEE.

Attwood, A., Merabti, M., Fergus, P., and Abuelmaatti, O. (2011). Sccir: Smart citiescritical infrastructure response framework. In Developments in E-systems Engineering

(DeSE), 2011, pages 460–464. IEEE.

Atzori, L., Iera, A., and Morabito, G. (’2010’). The internet of things: A survey. Comput.

Netw., 54(15), 2787–2805.

Barbacci, M., Klein, M. H., Longstaff, T. A., and Weinstock, C. B. (1995). Qualityattributes. Technical report, Software Engineering Institute.

Bass, L. and Nord, R. (2012). Understanding the context of architecture evaluationmethods. In Joint Working IEEE/IFIP Conference on Software Architecture (WICSA)

and European Conference o n Software Architecture (ECSA), pages 277–281.

Bass, L., Clements, P., and Kazman, R. (1998). Software Architecture in Practice.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Bird, S. (2013). Security and privacy: Why privacy matters. Science and Engineering

Ethics, 19(3), 669–671.

Blackstock, M., Kaviani, N., Lea, R., and Friday, A. (2010). Magic broker 2: An openand extensible platform for the internet of things. In Internet of Things (IOT), 2010,pages 1–8.

85

REFERÊNCIAS BIBLIOGRÁFICAS

Booch, G. (2010). Enterprise architecture and technical architecture. Software, IEEE,27(2), 96–96.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996). Pattern-

oriented software architecture: a system of patterns, vol.1. Wiley.

Caragliu, A., Del Bo, C., and Nijkamp, P. (2009). Smart cities in europe. Serie Rese-arch Memoranda 0048, VU University Amsterdam, Faculty of Economics, BusinessAdministration and Econometrics.

Chen, L., Ali Babar, M., and Ali, N. (2009). Variability management in software productlines: a systematic review. In Proceedings of the 13th International Software Product

Line Conference, SPLC ’09, pages 81–90, Pittsburgh, PA, USA. Carnegie MellonUniversity.

Clements, P. (2003). Documenting Software Architectures: Views and Beyond. SEI seriesin software engineering. Addison-Wesley.

ComputerWorld (2013). Smart cities. http://www.computerworld.com.pt/2013/07/04/dossier-smart-cities/. "[Online] Acessado em 05-Agosto-2013".

da Silva, W. M., Alvaro, A., Tomas, G. H. R. P., Afonso, R. A., Dias, K. L., and Garcia,V. C. (2013). Smart cities software architectures: A survey. In Proceedings of the 28th

Annual ACM Symposium on Applied Computing, SAC ’13, pages 1722–1727, NewYork, NY, USA. ACM.

Dirks, S. and Keeling, M. (2009). A Vision of Smarter Cities. Centre for Economic

Development, Dublin, Ireland.

Dobbs, R. and Institute, M. G. (2011). Urban World: Mapping the Economic Power of

Cities. McKinsey Global Institute.

Droege, P. (1997). Intelligent Environments: Spatial Aspects of the Information Revolu-

tion. Elsevier Science.

Eger, J. M. (2011). Ten steps to becoming a smart community. Technical report, CaliforniaInstitute for Smart Communities. "[Online] Acessado em 16-Outubro-2012".

Erbad, A., Blackstock, M., Friday, A., Lea, R., and Al-Muhtadi, J. (2008). Magicbroker: A middleware toolkit for interactive public displays. In 6th Annual IEEE

86

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

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


International Conference on Pervasive Computing and Communications, PERCOM’08, pages 509–514, Washington, DC, USA. IEEE Computer Society.

Fazio, M., Paone, M., Puliafito, A., and Villari, M. (2012). Heterogeneous sensorsbecome homogeneous things in smart cities. In Sixth International Conference on

Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), pages 775–780.

Fels, S. (2010). Sustainable communities: where does communication fit in? In First

Interdisciplinary Workshop on Communication for Sustainable Communities, IWCSC’10, pages 1:1–1:2, New York, NY, USA. ACM.

Filipponi, L., Vitaletti, A., Landi, G., Memeo, V., Laura, G., and Pucci, P. (2010). Smartcity: An event driven architecture for monitoring public spaces with heterogeneoussensors. In 4th International Conference on Sensor Technologies and Applications,pages 281–286, Washington, DC, USA. IEEE Computer Society.

Fowler, M. (2012). Patterns of Enterprise Application Architecture. Addison-WesleySignature Series (Fowler). Pearson Education.

Gama, K. and Donsez, D. (2010). A survey on approaches for addressing dependabilityattributes in the osgi service platform. SIGSOFT Softw. Eng. Notes, 35(3), 1–8.

Garlan, D. and Shaw, M. (1994). An introduction to software architecture. Technicalreport, School of Computer Science Carnegie Mellon University Pittsburgh, Pittsburgh,PA, USA.

Giffinger, R. and Pichler-Milanovic, N. (2007). Smart Cities: Ranking of European

Medium-sized Cities. Centre of Regional Science, Vienna University of Technology.

Giusto, D., Iera, A., Morabito, G., and Atzori, L. (2010). The Internet of Things: 20th

Tyrrhenian Workshop on Digital Communications. Springer.

Hall, N. (2012). Are there really more mobile phones than toothbrushes? http:

//bit.ly/RInZMi. "[Online] Available: 1-August-2012".

Haubensak, O. (2011). Smart cities and internet of things. Business Aspects of the

Internet of Things, page 33.

Heberty H. Amaral, D. C. C. and Fernandes, D. M. (2010). Estudo da relação entre asclasses sociais e o consumo de energia elétrica residencial do município de foz do

87

http://bit.ly/RInZMi

http://bit.ly/RInZMi


iguaçu do estado do paraná. 8º congresso internacional sobre geração distribuída de

energia no meio rural.

Hernández-Muñoz, J. M., Vercher, J. B., Muñoz, L., Galache, J. A., Presser, M., Gómez,L. A. H., and Pettersson, J. (2011). Smart cities at the forefront of the future internet.In J. Domingue, A. Galis, A. Gavras, T. Zahariadis, and D. Lambert, editors, The future

internet, pages 447–462. Springer-Verlag, Berlin, Heidelberg.

Hoover, C. E., Sharma, R. K., Watson, B. J., Charles, S. K., Shah, A. J., Patel, C. D.,Marwah, M., Christian, T. W., and Bash, C. E. (2010). Sustainable it ecosystems:Enabling next-generation cities. Technical report, Hewlett-Packard DevelopmentCompany.

ISO/IEC (2001). ISO/IEC 9126. Software engineering – Product quality. ISO/IEC.

Jauregui-Ortiz, S., Siller, M., Ramos, F., and Scalabrin, E. (2012). Smart environmen-tal architecture for node localization in a wireless sensor network. In Intelligent

Environments (IE), 2012 8th International Conference on, pages 222 –227.

Kanter, R., Litow, S., and School, H. B. (2009). Informed and Interconnected: A

Manifesto for Smarter Cities. Harvard Business School.

Kazman, R., Bass, L., Webb, M., and Abowd, G. (1994). Saam: a method for analyzingthe properties of software architectures. In Proceedings of the 16th international

conference on Software engineering, ICSE ’94, pages 81–90, Los Alamitos, CA, USA.IEEE Computer Society Press.

Kazman, R., Barbacci, M., Klein, M., Jeromy Carriere, S., and Woods, S. (1999).Experience with performing architecture tradeoff analysis. In Software Engineering,

1999. Proceedings of the 1999 International Conference on, pages 54–63.

Kazman, R., Kazman, R., Klein, M., Klein, M., Clements, P., Clements, P., Compton,N. L., and Col, L. (2000). Atam: Method for architecture evaluation.

Kazman, R., Bass, L., Klein, M., Lattanze, T., and Northrop, L. (2005). A basis foranalyzing software architecture analysis methods. Software Quality Control, 13(4),329–355.

Khurum, M. and Gorschek, T. (2009). A systematic review of domain analysis solutionsfor product lines. Journal of Systems and Software, 82(12), 1982 – 2003.

88


Kitchenham, B. and Charters, S. (2007). Guidelines for performing systematic literaturereviews in software engineering. Technical Report EBSE 2007-001, Keele Universityand Durham University Joint Report.

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., and Linkman, S.(2009). Systematic literature reviews in software engineering - a systematic literaturereview. Inf. Softw. Technol., 51(1), 7–15.

Klein, C. and Kaefer, G. (2008). From smart homes to smart cities: Opportunitiesand challenges from an industrial perspective. In 8th Int. Conf. NEW2AN and 1st

Russian Conference on Smart Spaces, ruSMART on Next Generation Teletraffic and

Wired/Wireless Advanced Networking, pages 260–260, Berlin, Heidelberg. Springer-Verlag.

Komninos, N. (2002). Intelligent Cities: Innovation, Knowledge Systems and Digital

Spaces. Taylor & Francis.

Komninos, N. (2006). The architecture of intelligent clities: Integrating human, col-lective and artificial intelligence to enhance knowledge and innovation. In 2nd IET

International Conference on Intelligent Environments, volume 1, pages 13–20.

Krco, S. (2010). Smartsantander - a smart city example. ICT event 2010.

Kruchten, P. (1995). The 4+1 view model of architecture. IEEE Softw., 12(6), 42–50.

Kuper, A. (1995). The Social Science Encyclopedia. Routledge world reference series.Taylor & Francis.

Lee, J., Baik, S., and Choonhwa Lee, C. (2011). Building an integrated service manage-ment platform for ubiquitous cities. Computer, 44, 56–63.

Li, X., Lu, R., Liang, X., Shen, X., Chen, J., and Lin, X. (2011). Smart community: aninternet of things application. IEEE Communications Magazine, 49(11), 68–75.

Maranzano, J., Rozsypal, S., Zimmerman, G., Warnken, G., Wirth, P., and Weiss, D. M.(2005). Architecture reviews: practice and experience. Software, IEEE, 22(2), 34–43.

Marceau, J. (2008). Introduction: Innovation in the city and innovative cities. Innovation:

Management, Policy & Practice, 10(2-3), 136–145.

89


Martín, J., Seepold, R., Madrid, N., Álvarez, J., Fernández-Montes, A., and Ortega, J.(2009). A home e-health system for dependent people based on osgi. In N. Mar-tínez Madrid and R. Seepold, editors, Intelligent Technical Systems, volume 38 ofLecture Notes in Electrical Engineering, pages 117–130. Springer Netherlands.

Morvaj, B., Lugaric, L., and Krajcar, S. (2011). Demonstrating smart buildings and smartgrid features in a smart energy city. In Energetics (IYCE), 3rd International Youth

Conference, pages 1–8. IEEE.

Mostashari, A., Arnold, F., Maurer, M., and Wade, J. (2011). Citizens as sensors: Thecognitive city paradigm. In Emerging Technologies for a Smarter World (CEWIT),

2011 8th International Conference & Expo on, pages 1–5. IEEE.

Nam, T. and Pardo, T. (2011). Conceptualizing smart city with dimensions of technology,people, and institutions. In Proceedings of the 12th Annual International Digital

Government Research Conference: Digital Government Innovation in Challenging

Times, pages 282–291. ACM.

Nations, U. (2007). World population prospects: The 2006 revision and world urbaniza-tion prospects. Technical report, United Nations, New York.

(NIC), N. I. C. (2008). Disruptive civil technologies - six technologies with potentialimpacts on us interests out to 2025.

PlanIT, L. (2012). Cities in the cloud, a living planit introduction to future city technolo-gies. In Living PlanIT . Living PlanIT.

Pollitt, M. M. (2007). An ad hoc review of digital forensic models. In Systematic

Approaches to Digital Forensic Engineering, 2007. SADFE 2007. Second International

Workshop on, pages 43–54.

Qun-li, S. and jie, L. (2008). Two software architecture evaluation methods based onscenario. In Control and Decision Conference, 2008. CCDC 2008. Chinese, pages2001–2004.

Roy, B. and Graham, T. N. (2008). Methods for evaluating software architecture: Asurvey. School of Computing TR, 545, 82.

Sanchez, L., Galache, J., Gutierrez, V., Hernandez, J., Bernat, J., Gluhak, A., andGarcia, T. (2011). Smartsantander: The meeting point between future internet research

90


and experimentation and the smart cities. In Future Network & Mobile Summit

(FutureNetw), pages 1–8. IEEE.

Schumpeter, J. A. (1934). The Theory of Economic Development: An Inquiry Into

Profits, Capital, Credit, Interest, and the Business Cycle. Harvard Economic Studies.Transaction Books.

Shanmugapriya, P. and Suresh, R. M. (2012). Software architecture evaluation methods -a survey. International Journal of Computer Applications, 49(16), 19–26. Publishedby Foundation of Computer Science, New York, USA.

Shao, C. (2011). An internet of things application with location perception based onims. In Third International Conference on Multimedia Information Networking and

Security (MINES), pages 163–166.

Sommerville, I. (2007). Software Engineering. Addison Wesley, 8 edition.

Spínola, R. O. and Travassos, G. H. (2012). Towards a framework to characterizeubiquitous software projects. Inf. Softw. Technol., 54(7), 759–785.

Steventon, A. and Wright, S. (2005). Intelligent Spaces: The Application of Pervasive

ICT . Computer Communications and Networks. Springer.

Su, K., Li, J., and Fu, H. (2011). Smart city and the applications. In Electronics,

Communications and Control (ICECC), 2011 International Conference on, pages1028–1031.

Tomas, G. H. R. P., da Silva, W. M., da Mota Silveira Neto, P. A., Garcia, V. C., Alvaro,A., and Gama, K. (2013). Smart cities architectures - a systematic review. In ICEIS

(2), pages 410–417.

Tomordy, M. (2011). Smart cities - transforming the 21st century city via the creative useof technology. Technical report, ARUPCorp.

Toppeta, D. (2010). The smart city vision: How innovation and ict can buildsmart,“livable”, sustainable cities.

Touseau, L., Donsez, D., and Rudametkin, W. (2008). Towards a sla-based approach tohandle service disruptions. In Proceedings of the 2008 IEEE International Conference

on Services Computing - Volume 1, SCC ’08, pages 415–422, Washington, DC, USA.IEEE Computer Society.

91


Vega-Barbas, M., Casado-Mansilla, D., Valero, M., Lopez-de Ipina, D., Bravo, J., andFlorez, F. (2012). Smart spaces and smart objects interoperability architecture (s3oia).In Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012

Sixth International Conference on, pages 725–730.

Wu, H., He, C., Liao, A., and Peng, S. (2011). A framework for integrating heterogeneousspatial information and applications adaptively based on multi-agent and web service.In Multimedia Information Networking and Security (MINES), 2011 Third International

Conference on, pages 253 –257.

Zygiaris, S. (2012). Smart city reference model: Assisting planners to conceptualize thebuilding of smart city innovation ecosystems. Journal of the Knowledge Economy,pages 1–15.

92

Apêndice

93

ARepositórios de busca na SLR

Tabela A.1 Repositórios de busca na SLRNome 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/

95

BAvaliação da Arquitetura de

Software (AS)

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

97

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

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

98


99

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


100

uma arquitetura para cidades inteligentes baseada na internet das coisas

Documents