Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Dissertação de Mestrado
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE
2014
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
RECIFE
2014
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno, CRB 4-1758
______________________________________________
Prof. Kiev Santos da Gama
Centro de Informática / UFPE
______________________________________________
Prof. Gibeon Soares de Aquino Junior
Departamento de Informática e Matemática Aplicada/UFRN
_______________________________________________
Prof. Vinícius Cardoso Garcia
Centro de Informática / UFPE
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
À minha família, por sempre me proporcionar totais
condições para a realização dos meus estudos.
Aos meus irmãos, que esta dissertação sirva de inspiração
para suas futuras decisões profissionais.
À Crisley, por sempre estar ao meu lado e me ajudar a ver o
lado bom de tudo.
Dedico.
Agradecimentos
De acordo com recentes pesquisas, a população mundial esta crescendo de forma despro-
porcional aos recursos necessários para a vida humana. Cada vez mais a quantidade de pessoas
vivendo nas áreas urbanas aumenta, devido à diversos fatores, como as oportunidades que são
geradas nestes grandes centros.
Este desenfreado crescimento populacional, principalmente nas áreas urbanas, além de
outros fatores como má governança, ocasiona e/ou intensifica diversos problemas urbanos. Para
exemplificar este fato, pode-se citar os grandes problemas que as cidades brasileiras enfrentam
nas áreas de transporte, saúde e educação, evidenciados, rotineiramente, pela mídia em geral.
Neste contexto, o conceito de Cidade Inteligente (CI) visa mitigar estes problemas a
fim de aumentar a qualidade de vida dos cidadãos. Para tal, uma importante ferramenta para a
implementação de uma CI é a Internet of Things (Internet das Coisas) (IoT), na qual diversos
objetos são combinados para atingir um objetivo em comum como, fornecer informações do
fluxo de veículos de uma cidade.
Porém, para que este cenário seja de fato consolidado, necessita-se de uma Arquitetura
de Software (AS) capaz de integrar e combinar as diferentes tecnologias e dados que compõem
os serviços urbanos.
Na literatura pode-se encontrar várias Arquiteturas de Software (AS’s) para CI, inclusive
com apoio de grandes empresas. Porém, estas AS’s visam atender apenas um determinado
serviço urbano com uma aplicação específica, o que não caracteriza de fato uma implementação
de CI.
Motivado por estes desafios, esta dissertação apresenta a especificação, o projeto e
a avaliação de uma AS para CI que permite a integração com IoT, baseado no conjunto de
requisitos extraídos das soluções existentes. Adicionalmente, são discutidos os resultados
obtidos, os problemas encontrados, e as direções futuras para pesquisa e o desenvolvimento.
4.1 Integração das visões do modelo “4+1” com as visões definidas pelo SEI . . . . 61
4.2 Visão lógica da Arquitetura de Software (AS) proposta . . . . . . . . . . . . . 63
4.3 Abstração da operação de um recurso receber dados . . . . . . . . . . . . . . . 66
4.4 Abstração da operação de um recurso fornecer dado . . . . . . . . . . . . . . . 66
4.5 Abstração da operação de um recurso fornecer um novo tipo de dado . . . . . . 66
4.6 Operação de composição de dados urbanos . . . . . . . . . . . . . . . . . . . 67
4.7 Visão de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.8 Diagrama de Componente Conector . . . . . . . . . . . . . . . . . . . . . . . 71
4.9 Diagrama de Dependências . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
AS Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
DHT Distributed Hash Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
IoT Internet of Things (Internet das Coisas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CI Cidade Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
SLR Systematic Literature Review (Revisão Sistemática da Liteturatura) . . . . . . . . . . 38
SOA Arquitetura Orientada a Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TIC Tecnologia da Informação e Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Sumário
1 Introdução 23
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 Estabelecimento do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Visão Geral da Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.1 Visão Geral da Arquitetura de Software (AS) . . . . . . . . . . . . . . 25
1.4 Escopo Negativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.5 Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.6 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Conclusão 91
6.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
References 97
Apêndice 103
1
Introdução
1.1 Motivação
De acordo com relatório divulgado pela UNESCO NATIONS (2007), por volta de 1950,
30% da população mundial vivia em áreas urbanas e em 2010 esta porcentagem subiu para 50%.
Estima-se que em 2050 a porcentagem de pessoas vivendo nos grandes centros urbanos será
de 70%. Além disso, 10% da população mundial vive nas 30 principais metrópoles DOBBS;
INSTITUTE (2011). No cenário nacional, segundo a pesquisa realizada pelo Instituto Brasileiro
de Geografia e Estatística (IBGE), publicada no Diário Oficial da União 1 , em julho de 2012 o
Brasil chegou a 193.946.886 habitantes, que representa um aumento de aproximadamente 1,65%
em relação ao ano de 2010.
A expansão das cidades enfrenta uma série de desafios. Embora as cidades ocupam
menos de 2% da massa terrestre, os residentes urbanos consomem mais de três quartos dos
recursos naturais do mundo e são os principais responsáveis pela emissão de gases do efeito
estufa MARCEAU (2008). Problemas decorrentes da rápida urbanização indicam uma perda
de funcionalidades básicas para ser um lugar habitável: por exemplo, a dificuldade na gestão
de resíduos, a escassez de recursos naturais, a poluição do ar, as doenças humanas, o intenso
tráfego de veículos e deterioração e envelhecimento das infraestruturas KRCO (2010).
Algumas iniciativas isoladas estão sendo desenvolvidas para mitigar alguns dos pro-
blemas urbanos NAM; PARDO (2011). As iniciativas vão de aplicativos como “Waze”2 , um
serviço que combina geolocalização no celular com indicações do fluxo e problemas de trânsito
via smartphones, até governamentais, como o Centro de Operações da Prefeitura do Rio de
1 http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=2204
2 https://www.waze.com/
24 CAPÍTULO 1. INTRODUÇÃO
Janeiro3 , sistema que integra informações a respeito dos diferentes serviços públicos oferecidos
pela cidade.
Porém, para de fato estabelecer uma Cidade Inteligente (CI) é necessário que estas
iniciativas estejam integradas em uma mesma Arquitetura de Software (AS), seja para com-
partilhar informações, seja para facilitar a definição da estratégia de atuação FILIPPONI et al.
(2010); ANTHOPOULOS; FITSILIS (2010); HAUBENSAK (2011); SANCHEZ et al. (2011);
HERNáNDEZ-MUñOZ et al. (2011). Da mesma forma, necessita-se de uma AS que permita
a criação de novas iniciativas para solucionar os problemas dos cidadãos FILIPPONI et al.
(2010); HAUBENSAK (2011); SANCHEZ et al. (2011), como por exemplo, o monitoramento
da qualidade do transporte coletivo.
Além disso, este trabalho é motivado pela vasta gama de sensores, atuadores, pessoas,
sistemas, drivers e qualquer outro componente capaz de interagir com os serviços urbanos. Ao
aplicar este conjunto de componentes nos contextos urbanos, vários desafios são gerados para
integrá-los e obter o melhor de cada componente.
Para este e outros cenários semelhantes, uma AS para CI pode ajudar a integrar esses
diversos componentes. Para tal, a AS deve ser totalmente plugável e expansível, do ponto de
vista dos protocolos de comunicação implementados.
a AS da solução foi proposta visando atingir um sub-conjunto destes requisitos, que representa
os requisitos fundamentais. Por fim, a AS foi submetida à um processo de avaliação formal
adaptado do SAAM KAZMAN et al. (1994) e ATAM KAZMAN et al. (1999, 2000).
Módulo de
REST Acesso e
Módulo de Comunicação
Persistência de Interface: Protocolos de troca de mensagens (MAC)
Dados (MPD)
Módulo de
DHT-BD
Gerenciamento
Registro de recursos Configuração de recursos de Recursos
(MGR)
Driver
BD1
BD1
Interface: Banco de Dados
Driver
BD2
Canal
BD3
de dados.
Os detalhes da AS serão descritos no Capítulo 4.
Análises de big data: Apesar da grande quantidade de dados trafegados na AS, este
trabalho não faz nenhum tipo de análise de big data, apenas permite que um serviço
que o faça seja criado;
Semântica dos Dados: Este trabalho não faz distinção entre semântica dos dados,
uma vez que qualquer tipo de dado relacionado à cidade pode trafegar na AS.
Estado de arte de AS para CI: A partir das revisões da literatura executadas foi
possível apresentar um resumo a respeito do estado da arte de CI no Brasil e no
mundo, a partir da descrição de algumas abordagens com ou sem apoio dos setores
estatais e privados;
Arquitetura de Software (AS) para CI e IoT: Uma AS que visa atender aos
principais requisitos de CI que combina conceitos de IoT foi especificada;
Além das contribuições finais listadas acima, alguns resultados intermediários deste
trabalho estão sendo reportados na literatura, como mostrado a seguir:
2
Cidades Inteligentes e Internet das Coisas
Polícias Civis (Janeiro de 2004 a Dezembro de 2005)1 , desenvolvido pela Secretaria Nacional de
Segurança Pública, entre 2004 e 2005 a taxa de roubo no Brasil por 100 mil habitantes aumentou
de 516,7 para 519,4;
Transporte: O sistema de transporte coletivo é de qualidade e eficiência questionáveis
na maioria das cidades brasileiras. Com o aumento do poder aquisitivo no Brasil e as crescentes
facilidades no financiamento de veículos, a quantidade de motocicletas e automóveis no país é
cada vez maior. A infraestrutura viária não acompanha este crescimento da frota nacional e o
trânsito é um problema em muitas cidades. Soluções paliativas, como rodízio de veículos, apenas
atenuam o crescimento do problema do tráfego, quando, na verdade, uma otimização no sistema
de transportes coletivos faz-se necessária. Dois exemplos da situação do transporte coletivo
no Brasil podem ser encontrados na Pesquisa de Mobilidade Da Região Metropolitana de São
Paulo2 : i) entre 2002 e 2012, a frota de veículos particulares cresceu 18%; ii) no mesmo período,
a taxa de motorização passou de 184 para 212 automóveis particulares por 1.000 habitantes;
Saúde: No Brasil, a infraestrutura do sistema de saúde é insuficiente para atender à
demanda. Vários hospitais públicos possuem atendimento deficitário, forçando pacientes a
aguardarem em longas filas de espera e o mesmo problema vem assolando pacientes do sistema
privado com planos de saúde. De acordo com a pesquisa da Assistência Médico-Sanitária(AMS)3
realizada em 2002 pelo IBGE, houve uma variação na quantidade de leitos disponíveis no Brasil,
de 3,65 leitos por 1 000 habitantes em 1992, para 2,70 em 2002, uma redução de quase 25%;
Uso sustentável de recursos: O aumento do poder aquisitivo das classes mais pobres
gerou uma elevação no consumo de energia elétrica, mas classes média e alta ainda representam
a maior fatia do consumo de energia elétrica, pelo padrão de consumo e conforto que envolve
diversos tipos de eletroeletrônicos. Em Foz do Iguaçu, por exemplo, 7% das famílias corres-
pondem a mais de 65% do consumo de energia elétrica da cidade HEBERTY H. AMARAL;
FERNANDES (2010);
Gestão de resíduos: O lixo tem se tornado um grande problema para cidades de países
em desenvolvimento. Enquanto cidades de países desenvolvidos põem em prática diversas
soluções de tratamento de lixo orgânico e de reaproveitamento de materiais recicláveis, cidades
de países como o Brasil não conseguem definir ou executar práticas de reciclagem, salvo raras
exceções. Por exemplo, de acordo com a Associação Brasileira de Empresas de Limpeza Pública
e Resíduos Especiais (ABRELPE)4 , em 2012 cerca de 60% dos municípios registraram alguma
iniciativa de coleta seletiva. Embora seja expressiva a quantidade de municípios com iniciativas
de coleta seletiva, muitas vezes estas atividades resumem-se à disponibilização de pontos de
entrega voluntária ou convênios com cooperativas de catadores, que não abrangem a totalidade
do território ou da população do município.
1 http://portal.mj.gov.br/services/DocumentManagement/FileDownload.EZTSvc.asp?DocumentID={42595482-
B0DD-4185-918E-80E4BAFAFC72}&ServiceInstUID={B78EA6CB-3FB8-4814-AEF6-31787003C745}
2 http://www.metro.sp.gov.br/pdf/mobilidade/pesquisa-mobilidade-2012.pdf
3 http://www.ibge.gov.br/home/estatistica/populacao/condicaodevida/ams/default.shtm
4 http://a3p.jbrj.gov.br/pdf/ABRELPE%20%20Panorama2012.pdf
31 2.1. CONCEITO DE Cidade Inteligente (CI)
Apesar da evidente necessidade de cidades cada vez mais inteligente e a atenção que
a academia tem destinado para o tema, ainda não há um consenso a respeito da definição do
conceito de Cidade Inteligente (CI), nem quanto ao ambiente mais adequado para empregá-lo
GIFFINGER; PICHLER-MILANOVIĆ (2007); CARAGLIU; DEL BO; NIJKAMP (2009); LI
et al. (2011). Logo, a Seção 2.1 visa clarificar a definição de CI a ser utilizada durante este
trabalho.
Um paradigma que vem sendo utilizado em diversas abordagens para CI é a utilização
de IoT como ferramenta para captar dados e atuar sobre os serviços urbanos. Logo, a Seção 2.2
visa contextualizar a IoT, a partir de alguns exemplos de aplicações.
Por sua vez, a Seção 2.3 inicialmente pontua alguns dos principais desafios, princi-
palmente, nas cidades brasileiras. Em seguida, apresenta-se a integração existente entre estas
duas áreas de pesquisa e alguns exemplos de utilização desta integração para mitigar alguma
deficiência urbana.
Por fim, a Seção 2.4 consolida as principais contribuições deste Capítulo.
das cidades. Ao mesmo tempo, uma CI pode tomar decisões inteligentes para diferentes tipos
de necessidades, incluindo aspectos diários, proteção ambiental, segurança pública, serviços da
cidade e atividades industriais e comerciais.
Analogamente, em moss2009informed o termo CI é definido como uma cidade que com-
bina TICs com a infraestrutura física, para prover conveniências aos cidadãos, como: eficiência
energética; aumento da qualidade da água e do ar; identificar e resolver rapidamente qualquer
problema no funcionamento dos sistemas da cidades; mitigar desastres; capturar dados para
apurar a tomada de decisões e a utilização de recursos de forma eficiente. Logo, a CI não pode
ser vista como a soma de partes independentes, mas uma rede de infraestrutura interconectada,
na qual cada recurso é dependente do outro.
Em Steventon-2005, as CIs se referem aos ambientes físicos em que as TICs e os sistemas
de sensoriamento são transparentes para os cidadãos, porém desepenham papel fundamental para
garantir o funcionamento operacional da cidade.
Uma CI também é definida como um território no qual as TICs propiciam inovações
em diversos segmentos, combinando a criatividade e o talento individual em prol da população
da cidade, instituições locais e orgãos governamentais KOMNINOS (2002); SCHUMPETER
(1934).
Em Dossier-2013 defende-se que CI não é um conceito tecnológico, mas um conceito
sociotécnico. Integra-se três vertentes essenciais: a tecnologia, as pessoas e as instituições. Uma
CI tem que centrar a sua atuação nos cidadãos e nas comunidades onde vivem e trabalham.
Em relação aos aspectos governamentais, toppeta2010smart acredita que uma CI deve
identificar e otimizar os processos governamentais, mitigando a burocracia que envolve o
processso de inovação de soluções e gerenciamento de técnicas sustentáveis.
Por fim, CI pode ser considerada um conjunto de comunidades inteligentes LI et al.
(2011). A partir dessa perspectiva, a World Foundation for Smart Communities (Fundação Mun-
dial para Cidades Inteligentes)5 define que uma CI é uma comunidade com avanços significativos
em TICs que transformam o cotidiano dos cidadãos, melhorando os aspectos relacionados ao
trabalho e ao lazer de forma incremental e transparente EGER (2011).
Além da falta de consenso quanto ao termo CI, existem outros termos que são comu-
mente aplicados aos mesmos contextos, como “cidades virtuais”, “cidades digitais”, “cidade
informatizada”, “cidade eletrônica” KOMNINOS (2006). Ao generalizar esse conceito aos
ambientes inteligentes que se relacionam com serviços urbanos, vários sinônimos de CI são
frequentemente empregados, como “information city”, “wired city”, “telecity”, “knowledge-
based city”, “electronic communities”, “electronic community spaces”, “flexicity”, “teletopia”,
“cyberville” DROEGE (1997).
Essa ausência de consenso é devido aos múltiplos movimentos científicos, tecnológicos e
sociais que compõem o contexto de uma cidade KOMNINOS (2006). Em cada disciplina, existe
uma série de problemas que afetam diretamente diversos serviços existentes, como transporte,
5 http://www.smartcommunities.org
33 2.2. CONCEITO DE IOT! (IOT!)
3
Revisão da Literatura de Arquiteturas de
Software para Cidades Inteligentes
A estratégia empregada para a construção das strings de buscas segue a mesma metodo-
logia emprega por Kitchenham-2007, Chen-2009 e Khurum20091982. Esta estratégia é ilustrada
na Figura ??.
(smart city OR intelligent city OR digital city OR urban environment) AND (internet of things
OR heterogeneous sensors) AND (architecture OR middleware OR platform)
Devido à variação dos resultados de cada motor de busca das principais fontes digitais
da literatura (como IEEExplore, Springer Link e ACM Digital Library), não é possível utilizar a
mesma string de busca em todas as fontes digitais CHEN; ALI BABAR; ALI (2009). Logo, foi
necessário um esforço para garantir que as strings utilizadas sejam logicamente e semanticamente
equivalentes.
Após definir a string de busca, realizou-se a busca nos seguintes repositórios digitais
(1. IEEExplore; 2. Science Direct; 3. ACM Digital Library; 4. Springer Link; 5. CiteSeerX;
6.Academia.edu; e 7. ISI Web of Science). Além disso, considerando que CI é uma linha de
pesquisa que envolve diversos aspectos de negócio e mercado, realizou-se a busca por patentes
no banco de patentes World Intellectual Property Organization(WIPO)1 .
Em relação à busca manual, foi realizada nos seguintes anais (1. International Conference
on Computational Intelligence, Modeling and Simulation (IJCCI); 2. International Conference
on Intelligent Environments (IE); 3. Multimedia Information Networking and Security (MINES);
4. Emerging Technologies for a Smarter World (CEWIT); 5. International Conference on
Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS)).
A Tabela 3.1 ilustra a quantidade de abordagens encontradas de acordo com as fontes de
pesquisa.
1 http://www.wipo.int
40 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
Tabela 3.1: Quantidade de abordagens por fonte de pesquisa
Fonte de Dados #
1. IEEExplore 24
2. Science Direct 1291
3. ACM Digital Library 1933
4. Springer Link 1484
5. CiteSeerX 399
6. Academia.edu 42
7. ISI Web of Science 4
8. WIPO 1233
9. IJCCI 4
10. IE 8
11. MINES 3
12. CEWIT 3
13. IMIS 7
Total 6435
A qualidade dos motores de busca podem influenciar a integridade das abordagens iden-
tificadas como primários, conforme discutido em Chen-2009. Dessa forma, algumas abordagens
podem não ter sido incluídas, caso os autores tenham usado outros termos além dos mencionados
acima.
Nesta SLR foram selecionadas somente abordagens que propõem uma AS e/ou fra-
mework que centralize os diversos contextos e tecnologias que envolvem o ambiente urbano.
Para tal, 5 pesquisadores, sendo 2 mestrandos, 2 PhD e 1 doutorando, foram envolvidos no
processo de seleção e classificação
Após definir a string de busca e as fontes, foram definidos filtros para classificar as
abordagens encontradas. A Figura ?? ilustra os resultados de cada filtro, baseado na quantidade
de abordagens resultantes.
O objetivo destes filtros é selecionar as principais abordagens que descrevem AS’s para
CI baseadas em IoT. O primeiro filtro corresponde a todas as abordagens encontradas nas fontes
de pesquisa, descritas anteriormente, a partir da string de busca.
O segundo filtro foi aplicado para excluir as abordagens que não foram publicadas entre
2008-2012. Este intervalo foi escolhido após analisar e verificar que as abordagens propostas
antes de 2008 relatam CI e IoT isoladamente, ou seja, as abordagens foram propostas para
solucionar problemas específicos de um contexto usando apenas uma tecnologia, sem analizar a
41 3.1. REVISÃO SISTEMÁTICA
Descreve uma AS IoT na qual seu design permite a combinação de uma ou mais
tecnologias diferentes e/ou contextos urbanos E
Durante esta revisão, foram encontradas diversas abordagens que descrevem a mesma
AS. Neste caso, somente o trabalho mais completo foi considerado. Após essa etapa, restaram
11 abordagens para serem analisadas.
Existem diversas razões para esta alta discrepância entre a quantidade inicial de tra-
balhos com a quantidade resultante. A principal razão é a alta quantidade de estudos du-
plicados com resultados semelhantes. Estas razões são discutidas e explicadas em Kitche-
nham:2009:SLR:1465742.1466091.
Em relação às patentes, não foi encontrada nenhuma patente relacionada. Geralmente, as
patentes mais próxima à temática dessa revisão sistemática descrevem um algoritmo específico
ou a otimização de uma técnica empregada em um ambiente controlado.
3.1.2 Resultados
Após realizar as buscas nas principais fontes de pesquisa, filtrar as abordagens de acordo
com os critérios descritos na Seção anterior, restaram 11 abordagens. Estas abordagens foram
lidas e discutidas entre os 5 pesquisadores supracitados, com o objetivo de realçar os tópicos
relacionados às questões de pesquisa. Esta seção visa discutir estas abordagens, iniciando por
uma descrição inicial de cada abordagem.
Caso uma abordagem tenha algum nome, este será utilizado para referir-se a ela. Caso
contrário, será dado um nome usando o sobrenome do primeiro autor seguido pelo ano de
publicação. A Tabela 3.2 lista as 11 abordagens analisadas, organizadas em ordem cronológica.
42 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
Tabela 3.2: Abordagens resultantes por ordem cronológica
3.2.2 Resultados
Em klein2008industrial é relatada uma perspectiva de CI voltada para negócio, especifi-
camente de provedores de infraestruturas e soluções dentro do contexto de utilização eficiente de
energia elétrica para infraestruturas inteligente e data centers. O objetivo do trabalho é aderir
eficiência energética dos equipamentos, reduzindo os custos com energia e criando mecanismos
para que softwares e serviços tornem-se autoconscientes de seu consumo de energia. De acordo
com os autores, esta característica é essencial na implementação de uma AS de CI, permitindo
desenvolvimento e operação sustentáveis.
Em MB2-2010 é proposta uma plataforma chamada Magic Broker (MB2), a qual possui
o objetivo de permitir a interoperabilidade de objetos. Inicialmente desenvolvida com o objetivo
de prover um modelo consistente e padronizar as interfaces para a construção de aplicações
de IoT, o MB2 esta sendo adaptado para o contexto de CI. Para tal, além de prover a API
para consultas, a plataforma provê abstrações fundamentais, como: eventos, estado, serviços e
gerenciamento de conteúdo.
O MB2 consiste de uma evolução do MB original ERBAD et al. (2008), na qual foram
inseridas diversas características para a construção de aplicações ubíquas, como a inclusão de um
middleware responsável por tratar as informações oriundas dos diferentes dispositivos. Para tal,
foram acoplados diversos protocolos de comunicação como HTTP e XML. Cada implementação
46 CAPÍTULO 3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE
PARA CIDADES INTELIGENTES
desses protocolos foi implementada usando serviços OSGi4 .
Seguindo o princípio de ser um laboratório para validação de tecnologias com foco em CI,
em Lisboa/Portugal foi construída uma cidade com 1700 hectares de extensão. Conhecida como
PlanIT Valley5 , a cidade deve produzir 150% da energia necessária, gerenciar os resíduos sólidos
e reciclar toda a água consumida. Empresas privadas, como a Microsoft, Cisco, Massachusetts
Institute of Techonology e McLaren Eletronic System estão apoiando esse projeto PLANIT
(2012).
A estratégia desse projeto é implementar um Sistema Operacional Urbano(UOS). Esse
sistema operacional é uma plataforma com o intuito de integrar cada domínio que compõem
uma cidade. O sistema será alimentado por uma vasta rede de sensores e todos esses dados serão
capturados por tempo indeterminado, para auxiliar na tomada e na predição de decisões. Além
de prever catástrofes, caso ocorra, o sistema pode antever os possíveis impactos na cidade.
A sustentabilidade é um fator relevante que foi abordado em outras abordagens, como
em Masdar City HAUBENSAK (2011). A cidade de Masdar City foi desenvolvida no deserto de
Abu Dhabi com 6 km quadrados, 50.000 habitantes, 1500 empresas e universidades. O objetivo
do projeto é desenvolver projetos auto-suficientes com o mínimo de impacto ambiental. Toda
a cidade é livre de combustíveis fósseis, na qual toda a energia é oriunda de fontes renováveis,
sem nenhum tipo de resíduo. Além disso, 80% da água consumida será tratada. No quesito
transporte, os veículos privados são proibidos e os meios de transporte são veículos elétricos e
bicicletas. As estações de transportes elétricos serão separadas por uma distância de no máximo
200 metros. A primeira fase do contém aparelhos ecologicamente corretos desenvolvidos pela
General Eletric (GE).
Em nam2011conceptualizing é descrita a teoria da sinergia que deve existir entre tec-
nologia, pessoas e instituições na concepção de CI. O trabalho destaca especificamente que a
inteligência refere-se comumente às mudanças inovadoras trazidas por novas tecnologias. Em
relação ao aspecto tecnologia, os autores afirmam que é essencial que a cidade possua alta adap-
tabilidade às necessidades de seus cidadãos, independente de suas limitações, com capacidade
de autoconfiguração, proteção, otimização e recuperação de falhas, garantindo disponibilidade
de serviços a qualquer tempo. Para isso, faz-se necessário uma infraestrutura de computação
ubíqua, sobre a qual os serviços serão disponibilizados.
De acordo com andreini2011scalable, SOA é considerada uma investida promissora na
construção de CI através da implementação da IoT. Assim, objetos conectados à rede publicariam
seus serviços, que por sua vez seriam acessados a partir de clientes móveis, permitindo interações
humano-máquina e máquina-máquina (M2M) mais flexíveis. Isso seria construído a partir
de uma abordagem semelhante ao Domain Name System (DNS), no qual um objeto seria
identificado através de um nome, usado para acessá-lo e consultar serviços. Os autores propõe
uma implementação usando Distributed Hash Table (DHT), que atribui o nível de escalabilidade
4 http://www.osgi.org
5 http://living-planit.com
47 3.2. REVISÃO EXPLORATÓRIA
requisitos fundamentais que devem ser atendidos na implantação de uma AS para CI.
Portugal
Fazio’2012 2012 Prover dados combinados Validada em ambiente con- Privada
trolado
3.4.3 Sustentabilidade
As cidades concentram altos índices de consumo de recursos naturais, como água e
alimentos. Além disso, vários problemas de poluição, seja poluição sonora, visual, atmosférica,
da água ou do solo, prejudicam a qualidade de vida dos cidadãos de várias cidades, principalmente
as metrópoles.
51 3.4. REQUISITOS PARA UMA ARQUITETURA DE SOFTWARE PARA CIDADES
INTELIGENTES
Neste sentido, uma AS para CI deve permitir que políticas sustentáveis (sustentabili-
dade) sejam implementadas com base em estatísticas relacionadas ao dia-a-dia dos cidadãos. Por
exemplo, iniciativas de consumo consciente de alimentos podem ser implementadas ao mapear
os hábitos dos cidadãos durante um dia.
Desta forma, estas políticas sustentáveis devem otimizar a utilização de recursos naturais,
a partir de iniciativas relacionadas ao meio ambiente e economia FELS (2010). Para tal é
importante ressaltar que políticas devem ser propostas nos diversos domínios que compõem uma
cidade, como Transporte e Educação.
As AS’s que integram sustentabilidade são Klein’2008 KLEIN; KAEFER (2008),
EcoCity/ISMP-UC LEE; BAIK; CHOONHWA LEE (2011), SmartSantander SANCHEZ et al.
(2011), Masdar City HAUBENSAK (2011) e Zygiaris’2012 ZYGIARIS (2012).
3.4.5 Ubiquidade/Mobilidade
A proximidade dos dispositivos com as pessoas/cidadãos, geralmente a partir da internet,
origina o termo ubiquidade SPÍNOLA; TRAVASSOS (2012). Neste sentido, este termo cor-
responde a qualquer tecnologia móvel capaz de capturar informação sobre o ambiente ou atuar
sobre o mesmo SANCHEZ et al. (2011).
Ao considerar que 4 bilhões de cidadãos já possuem smartphones HALL (2012), é
natural associar ubiquidade ao uso destes dispositivos. Porém outros dispositivos devem ser
utilizados, como ZigBee e RFID (Radio-frequency identification).
Logo, uma AS para CI deve permitir a comunicação efetiva com os mais diversos dispo-
sitivos oriundos da temática de ubiquidade, uma vez que estes estarão fisicamente próximos aos
cidadãos. Neste contexto, as AS’s que já empregam alguns destes princípios são SmartSantander
SANCHEZ et al. (2011), USN HERNáNDEZ-MUñOZ et al. (2011), MB2 BLACKSTOCK et al.
(2010) e Zygiaris’2012 ZYGIARIS (2012).
3.4.10 Disponibilidade
Para permitir a captação de dados em tempo real e o fornecimento de informações
contextualizadas, a AS deve ser altamente disponível, em qualquer dia e horário.
Na literatura existem diversas iniciativas que propõem mecanismos para garantir a dis-
ponibilidade da AS. Dentra elas, a mais discutida e utilizada é relacionada à Cloud Computing.
Desta forma, caso a infraestrutura de cloud computing seja utilizada, mecanismos de controle de
fluxo, colisão e redundância devem ser inerentes à solução.
Nas AS’s SmartSantander SANCHEZ et al. (2011), USN HERNáNDEZ-MUñOZ et al.
(2011) e Nam’2011 NAM; PARDO (2011), estas situações são tratadas utilizando diversos
mecanismos de modularidade em relação a cloud.
3.4.12 Flexibilidade/Extensibilidade
Este requisito corresponde à capacidade da AS adaptar-se à mudanças e extensões. Além
da inserção de novos serviços, a AS deve ser capaz de adaptar-se à novos requisitos inerentes ao
contexto de implementação. Por exemplo, a AS deve ser independente de padrões específicos de
hardware.
Apesar da evidente relevância deste requisito, apenas três AS’s exploram este requisito:
Klein’2008 KLEIN; KAEFER (2008), MB2 BLACKSTOCK et al. (2010) e EcoCity/ISMP-UC
LEE; BAIK; CHOONHWA LEE (2011).
Requisito Abordagens #
Interoperabilidade de objetos SOFIA, USN, EcoCity/ISMP-UC, Living PlanIT, Zygia- 7
ris’2012, Wu’2011 e S3 OiA
Monitoramento em tempo Al-Hader’2009, SOFIA, SmartSantander, USN, Asimako- 7
real poulou’2011, Attwood’2011 e Living PlanIT
Sustentabilidade Klein’2008, EcoCity/ISMP-UC, SmartSantander, Masdar 5
City e Zygiaris’2012
Aspectos sociais Klein’2008, IMS e Asimakopoulou’2011 3
Ubiquidade/Mobilidade SmartSantander, USN, MB2 e Zygiaris’2012 4
Privacidade e Segurança dos SmartSantander, Living PlanIT e Fazio’2012 3
dados
Geolocalização dos Sensores IMS, USN e S3 OiA 3
Composição de Dados Urba- Nam’2011, CPAF, IMS, Anthopoulos’2010, Fazio’2012 e 6
nos Living PlanIT
Histórico de dados MB2, SmartSantander, EcoCity/ISMP-UC e Living Pla- 4
nIT
Disponibilidade SmartSantander, USN e Nam’2011 3
Sensoriamento e Processa- USN, SOFIA, Andreini’2011 e EcoCity/ISMP-UC 4
mento Distribuído
Flexibilidade/Extensibilidade Klein’2008, MB2 e EcoCity/ISMP-UC 2
Ainda em relação aos padrões arquiteturais, nota-se que o modelo de arquiteturas em camadas é
o mais utilizado, pois permitem o escalonamento de uma AS. Outro padrão bastante empregado
pelas AS’s foi o publisher-subscriber, devido, principalmente, as vantagens em utilizá-lo para
modelar o ambiente real.
Além disso, pode-se perceber que algumas AS’s foram propostas para finalidades es-
pecíficas, como gerenciamento de catastrófes. Apesar disso, essas AS’s possuem mecanismos
interessantes de tratamento de eventos em tempo real que devem ser considerados no desenvolvi-
mento de qualquer AS para CI.
Apesar dos objetivos comuns destas abordagens, uma coisa é fato: ainda não há um
consenso amplamente aceito na literatura sobre quais os requisitos que uma AS deve atender para
ser considerada efetiva, independente da forma como foi implementada. A partir das abordagens
estudadas, pode-se estabelecer um conjunto de requisitos essenciais ao analisar os principais
objetivos das abordagens previamente descritas. Esses requisitos constituem a base para qualquer
AS para CI, pois abrangem os princípios definidos para uma CI.
Dessa forma, ao propor uma nova AS para CI é de suma importância que ela atenda a
maior quantidade desses requisitos, para que uma cidade possa ser de fato considerada inteli-
gente. Esses requisitos servirão como pilares para a elaboração da AS para CI que combine as
tecnologias de IoT que será descrita nos próximos Capítulos.
57 3.7. CONSIDERAÇÕES FINAIS DO CAPÍTULO
4
Uma Arquitetura de Software para Cidades
Inteligentes baseada na Internet das Coisas
Baseado nas demandas de uma AS para Cidade Inteligente (CI) que possibilite a inte-
gração de tecnologias IoT e no conjunto de requisitos que foi definido no Capítulo anterior,
este Capítulo visa propor uma AS para CI que permita a combinação com tecnologias IoT. O
foco da solução proposta consiste em atender um sub-conjunto destes requisitos, bem como
prover mecanismos, do ponto de vista de infraestrutura, para que novos requisitos possam ser
futuramente incluídos, de acordo com o contexto de cada cidade.
Dessa forma, a Seção 4.1 apresenta este sub-conjunto de requisitos que serão abordados
nesta proposta. Já para descrever a proposta detalhadamente é utilizado um método de descrição
de AS’s baseado em visões, conhecido como “4+1”, na Seção 4.2.
Em seguida, cada visão abordará aspectos específicos da AS. A Seção 4.3 apresentará
a Visão Lógica, a partir de um ponto de vista funcional, relacionando os principais módulos e
as operações realizadas com mais frequência. Por sua vez, a Seção 4.4 apresentará a Visão de
Execução, com o mapeamento dos componentes lógicos em processos e threads. A Seção 4.5
apresentará a Visão de Implementação, seguido da Seção 4.6 explicitando a Visão Física. Além
das visões deste método, duas outras visões definidas pelo SEI CLEMENTS (2003) foram utili-
zadas para facilitar a compreensão pelos stakeholders: Visão Componente Conector (Seção 4.7)
e Visão de Dependências (Seção 4.8).
Por fim, a Seção 4.9 apresentará alguns dos principais cenários de utilização desta AS,
do ponto de vista de orgãos governamentais e não-governamentais, cidadãos e desenvolvedores.
Finalmente, a Seção 4.10 consolida as principais características da AS proposta discutidas
60CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
neste Capítulo e a Seção 4.11 finaliza o Capítulo.
Requisito Abordado #
Interoperabilidade de objetos Sim 7
Monitoramento em tempo real Sim 7
Composição de Dados urbanos Sim 6
Sustentabilidade Não 5
Histórico de dados Sim 4
Ubiquidade/Mobilidade Sim 4
Sensoriamento e Processamento Distribuído Sim 4
Geolocalização dos Sensores Sim 3
Privacidade e Segurança dos dados Não 3
Aspectos sociais Não 3
Disponibilidade 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ídos
nesta proposta e 8 foram incluídos. Para realizar essa priorização, dois fatores foram ponderados:
i) a importância/relevância do requisito, inferida a partir da quantidade de abordagens na literatura
que visam satisfazer esse requisito, conforme pode ser observado na coluna “#”; e ii) este conjunto
de requisitos foi incluído nesta proposta são os requisitos mínimos que toda AS de software para
CI deve atender.
Os demais requisitos que, mesmo considerados importantes/relevantes, não foram abor-
dados nesta proposta, dificilmente podem ser abordados nesta proposta no estágio atual. A
saber:
Módulo de
REST Acesso e
Módulo de Comunicação
Persistência de Interface: Protocolos de troca de mensagens (MAC)
Dados (MPD)
Módulo de
DHT-BD
Gerenciamento
Registro de recursos Configuração de recursos de Recursos
(MGR)
Driver
BD1
BD1
Interface: Banco de Dados
Driver
BD2
Canal
BD3
uma interface padronizada que permite a inserção de novos adaptadores que implementam os
diferentes protocolos de troca de mensagem sob demanda.
O funcionamento do MAC consiste em receber cada requisição dos diferentes recursos
e encaminhá-las para os demais módulos. Para isso, o MAC oferece todos os operações para
interagir com a AS, por exemplo, operações responsáveis pelo Registro de Recursos, como será
detalhado na seção a seguir. De acordo com a operação do método, este delega ação para o
respectivo módulo.
A Tabela 4.2 ilustra o módulo no qual cada requisito é contemplado. Como nota-se,
geralmente um requisito é implementado a partir da combinação de dois ou mais módulos da
AS.
Por sua vez, o mecanismo para fornecer um dado é bem parecido ao recebimento de um
dado. Existem dois cenários específicos para o fornecimento de dado: (i) quando já existe um
canal no qual o dado é disponibilizado, ou seja, existe pelo menos mais um recurso fornecedor
que já fornece esse dado; ou (ii) quando é o primeiro recurso fornecedor a fornecer o dado.
Em ambos os casos, primeiramente, o recurso deve verificar na DHT se já existe um
canal no qual este dado é fornecido. Caso exista, a DHT retornará a referência desse canal que
corresponde ao primeiro cenário, como ilustrado na Figura ??.
file = images/fornecerd ado.pd f , width = 10cm
Figura 4.4: Abstração da operação de um recurso fornecer dado
Caso contrário, a DHT retornará uma resposta de que o canal requisitado não existe,
como ilustrado na Figura ??. A partir desta resposta, o recurso fornecedor deve solicitar uma
nova referência de canal para fornecer este tipo de dado, fornecendo as informações necessárias.
Feito isso, a DHT retornará a referência ao novo canal.
file = images/fornecern ovod ado.pd f , width = 10cm
Figura 4.5: Abstração da operação de um recurso fornecer um novo tipo de dado
De posse da referência ao canal que será fornecido o dado, em ambos os casos, basta o
recurso fornecedor enviar os respectivos dados assim que eles estiverem disponíveis.
67 4.4. VISÃO DE EXECUÇÃO
A operação de compor um dado urbano pode ser considerada uma combinação entre
as operações de Receber e Fornecer um dado. Como ilustrado na Figura ??, esta operação é
dividida em 3 fases: Setup, Consumo de Dados e Criação de dados.
A primeira fase, Setup, corresponde aos passos necessários para iniciar uma composição
de dados urbanos. Inicialmente, o recurso deve consultar se o canal com o dado que será
combinado já existe. Caso não exista, o recurso deve solicitar a disponibilização deste canal e a
devida referência deve ser retornada.
De posse da referência do canal na qual será disponibilizada o dado combinado, inicia-se
a segunda fase, conhecida como Consumo de Dados. Nesta fase, o recurso deve consultar a DHT
para adquirir a referência de todos os canais que já fornecem os dados que serão utilizados para a
combinação. Após obter a referência de todos os canais, o recurso deve se inscrever para receber
os dados oriundos destes canais.
file = images/compord ado.pd f , width = 14cm
Figura 4.6: Operação de composição de dados urbanos
Não há nenhuma restrição na quantidade de dados que podem ser utilizados para com-
binação, ou seja, o recurso pode se inscrever em vários canais para utilizar estes dados na
combinação.
Feito isso, inicia-se a terceira fase, Criação de Dados. Esta fase corresponde ao meca-
nismo de receber os dados dos vários canais inscritos, combiná-los de alguma forma utilizando
algum tipo de regra de negócio e disponibilizá-lo no canal obtido na fase de Setup.
Vale ressaltar que a fase de Criação de Dados é a única que continua sendo executada
em background por tempo indeterminado. Além disso, ressalta-se que o momento em que a
nova informação combinada é disponibilizada no canal resultante depende da regra de negócio
implementada. Por exemplo, um recurso de combinação de dados que gera um relatório das
unidades de emergência por regiões de uma cidade pode consumir os dados de cada unidade e
gerar esse relatório uma vez por dia.
Por sua vez, cada adaptador pode ser executado em um outro processo independente,
visto que o único recurso compartilhado é a interface do processo principal. Já em relação as
requisições, uma thread é criada para cada requisição, já que as requisições são gerenciadas de
forma independente.
O MGR possui um processo principal que é responsável por conter todas as interfaces
das operações visíveis aos demais módulos. Além disto, cada cada sub-módulo é executado em
processo separado para que técnicas de cache possam ser futuramente desenvolvidas de forma
eficiente.
As operações que serão realizadas nos sub-módulos devem ser eficientes a ponto de
não comprometer a computação do recurso requisitante. Logo, para cada operação, uma thread
é iniciada para tratar está requisição. A sincronização das informações será feita utilizando
técnicas de sincronização por transação.
Ao análisar a imagem 4.7, nota-se que o bundle responsável pela MAC contém um
adaptador com a implementação inicial de JSON7 utilizando a bibilioteca fornecida pelo Google
Inc. conhecida como GSON8 . Este bundle comunica-se ativamente com o bundle responsável
pela comunicação via REST. Por sua vez, o módulo REST implementa utilizando o framework
Restlet9 .
Em relação ao módulo MGR, percebe-se que ele se resume em dois bundles: Registro de
Recursos e Configuração de Recursos. Estes dois bunddles representam os processo descritos
previamente.
Já no módulo MGDD, a implementação do padrão publisher-subscriber foi realizada
utilizando o serviço oferecido pelo próprio OSGi Equinox denominado EventAdmin. O EventAd-
min corresponde à um serviço que contém a implementação de canais de distribuição de dados,
na qual consumidores de dados podem se inscrever nos respectivos tópicos de interesse e os
fornecedores de dados podem fornecer os dados nestes canais. Na Figura 4.7 as caixas “C” e “P”
representam os consumidores e fornecedores de dados. Como pode ser observado, a DHT Canal
de Dados comunica-se ativamente com o EventAdmin para gerenciar os canais de dados.
Por fim, a ilustração correspondente ao módulo MPD exemplifica a utilização de um
banco de dados específico, conhecido como MongoDB10 . Similarmente à DHT Canal de Dados,
a DHT Banco de Dados utiliza as informações de cada bundle referente a um banco de dados
para gerenciá-lo e oferecê-lo aos demais componentes da AS. Caso um novo banco de dados
seja inserido, basta plugar o respectivo bundle sobre a plataforma OSGi Equinox e registrá-lo na
DHT de Banco de Dados.
infraestrutura.
Tabela 4.4: Requisitos físicos de utilização da arquitetura
Requisito Configuração
Hardware
Plano Amazon AWS Amazon EC2 - Free Tier
Memória RAM 613Mb
Software
Amazon Machine Image (AMI) amzn-ami-pv-2012.09.0.x86_64-ebs
Sistema Operacional Linux Amazon (Red Hat)
Restlet Versão 2.4.1
GSON Versão 2.2.4
MongoDB Versão 2.4.6
Servidor Web Jetty 7
Para a utilização em um ambiente real de produção é evidente que esta configuração não
é suficiente. Nesse contexto, deve-se analisar as soluções de Cloud oferecidas pelos provedores
para obter melhor desempenho da AS, como por exemplo, Amazon Dynamo DB12 e Amazon
Elastic Map Reduce13 .
Como pode ser observado na Figura 4.8, os componentes principais são Recurso e Dado.
Apesar destes dois componentes fazerem parte logicamente do MGR, eles são utilizados pelos
demais módulos da AS. No próprio MGR, estes componentes são utilizados pelos módulos de
Configuração e Gerenciamento de Recurso. Os dados que trafegam na AS são representados
pelo componente Dado. Toda vez que um determinado recurso fornecer ou consumir um dado,
este deve usar o conector existente entre os componentes Recurso e Dado.
No caso do MAC, o componente Recurso é utilizado pois representa a entidade que
fornece e recebe dados da arquitetura. Esta comunicação é realizada a partir do outro componente
REST.
O MGDD contém uma porta para cada canal de dado. Esta porta é uma abstração para
a comunicação realizada com os diversos Recursos consumidores ou fornecedores de dados.
12 http://aws.amazon.com/dynamodb/
13 http://aws.amazon.com/elasticmapreduce/
72CAPÍTULO 4. UMA ARQUITETURA DE SOFTWARE PARA CIDADES INTELIGENTES
BASEADA NA INTERNET DAS COISAS
Além disto, o MGDD contém um componente denominado DHT com as responsabilidades já
descritas na Seção Visão Lógica. Como pode ser observado, o MGDD possui um conector para
cada recurso associado à um canal.
Por sua vez, o MPDD possui conectores associados aos módulos MGR e MGDD para
que as informações trafegadas nestes dois módulos possam ser armazenadas para a predição de
eventos futuros. Além disto, uma porta é associada à cada instância de banco de dados.
Como pode ser observado na Figura 4.8, apesar do MGDD ser o core da AS, o módulo
que é mais utilizado pelos demais é o MGR. Este fato deve-se ao fato dos componentes Recurso
e Dado estar logicamente declarados no MGR. Logo, o MGDD depende do MGR para interagir
com os recursos inscritos em cada canal, além de gerenciar os respectivos dados.
Por sua vez, o MGR contém dependência apenas do MAC. Esta dependência deve-se
ao fato do MAC ser a porta de entrada e saída dos sistemas externos com a AS. Logo, para que
um recurso consiga receber de fato os dados é necessário utilizar os mecanismos providos pelo
MAC.
Assim como no diagrama de Componentes Conectados, o MPDD possui dependência
com os módulos MGR e MGDD para que as informações trafegadas nestes dois módulos possam
ser armazenadas para a predição de eventos futuros.
4.9 Cenários
Esta Seção visa apresentar alguns dos principais cenários de utilização da AS proposta.
aplicação como um recurso no MGR. Para isto, a aplicação deve invocar o respectivo método
oferecido pelo MAC, provendo as devidas informações do recurso.
Em seguida, este recurso deve consultar a “DHT Canais de Dados” para obter as referên-
cias para todos os canais que oferecem as informações relevantes da respectiva cidade. Após se
inscrever nestes canais, assim que um novo dado é disponibilizado, a aplicação deve recebê-los a
partir de consultas REST. De posse destes dados, a aplicação pode exibi-los da maneira mais
adequada.
5
Avaliação da Arquitetura de Software
Obstáculo é aquilo que você enxerga quando tira os olhos do seu objetivo.
—JUSTIN HERALD, 2006 ˙It’s All a Matter of Attitude
Por fim, a Seção 5.6 consolida as principais características do método proposto e dos
resultados obtidos a partir do processo de avaliação utizado.
Um outro fator que deve ser levado em consideração no momento de escolher qual
método de avaliação utilizar é o objetivo do método CLEMENTS (2003). Logo, a Tabela 5.2
apresenta o objetivo de cada método resultante do pré-requisito anterior.
79 5.1. MÉTODOS DE AVALIAÇÃO
Método Objetivo
SAAM Adequação arquitetural e identificação de riscos
ATAM Foco em sensibilidade da arquitetura e análise trade-off
Avaliar arquiteturas legadas a partir de reengenharia, utilizando Domain
SBAR
Specific Software Architecture, para criar uma base reutilizável e flexível
SACAM Comparação com outras arquiteturas de software descritas na literatura
DoSAM Comparação com outras arquiteturas de software descritas na literatura
A partir destas duas pré-condições, nota-se que o método SBAR não pode ser utilizado
pois a AS proposta não é uma legada. Por sua vez, SACAM e DoSAM não devem ser utilizados,
pois não há nenhuma outra AS, disponível e amplamente aceita na literatura, que possa ser
comparada com a AS proposta, devido a falta de especificação e detalhamento arquitetural.
Por fim, restaram apenas dois métodos que satisfazem o contexto da AS proposta: (1)
SAAM KAZMAN et al. (1994) e (2) ATAM KAZMAN et al. (1999, 2000). A seguir uma breve
descrição de cada um desses métodos é apresentada.
O método SAAM inclui 6 atividades: (i) desenvolvimento dos cenários; (ii) descrição
da AS avaliada; (iii) classificação e priorização dos cenários; (iv) avaliação dos
cenários individual e indireta; (v) interação entre os cenários; (vi) avaliação global
dos cenários KAZMAN et al. (1994).
priorização dos cenários; (iii) Testes: Análise da AS proposta; (iv) Apresentação dos
Resultados KAZMAN et al. (1999, 2000).
Não foi encontrada nenhum método de avaliação para o contexto de equipes distri-
buída geograficamente;
Como as reuniões seriam realizadas por Skype, as reuniões deveriam ser curtas para
manter a equipe concentrada.
Logo, surgiu a necessidade de propor uma adaptação dos dois métodos a fim de sanar
essas peculiaridades. Esta adaptação é baseada no SAAM e ATAM, porém as atividades são
específicas para o contexto remoto. Apesar disto, nenhuma nova etapa foi criada, pelo contrário,
as etapas recomendadas pelo SAAM e ATAM foram apenas combinadas e adaptadas para o
respectivo contexto. A Tabela 5.3 apresenta as 10 etapas do método adaptado.
Expertise #
Doutores ou Doutorandos 3
Mestres ou Mestrandos 2
Engenheiros de Sistemas 4
Especialistas em Cloud Computing 1
Especialistas em IoT 2
Especialistas em Arquiteturas escaláveis 2
Especialistas em Arquiteturas de propósito geral 2
Especialistas em Negócios 2
apresenta alguns métodos de priorização dos atributos de qualidade, porém o mais usual é
estabelecer que cada participante possui 3 votos que deve ser distribuído dentre os atributos de
qualidade. Após todos os participantes votarem, os atributos de qualidade que receberem mais
votos devem ser considerados mais prioritários.
A contexualização sobre o que são cenários para toda a equipe de avaliação deve ser
realizada a seguir. Um cenário, neste contexto, ilustra os tipos de atividades que um sistema
deve suportar. Um exemplo de cenário pode ser: “Qual o impacto na arquitetura caso ocorra
uma mudança no modelo de troca de mensagens entre os componentes”. Vale ressaltar que
o desenvolvimento desses cenários é crucial para capturar os principais usos do sistema, seus
usuários, antecipar mudanças no sistema, e qualidades que o sistema deve satisfazer agora e no
futuro. Estes cenários devem ser elicitados por todos os stakeholders do sistema a partir dos
objetivos de negócios, logo, representam questões sob diferentes pontos de vista e, na maioria
das vezes, trazem informações bem específicas do sistema avaliado.
Antes da próxima etapa deste processo de avaliação é importante criar algum mecanismo
para que os participantes possam propor os possíveis cenários. Uma técnica que pode ser
utilizada é o compartilhamento de uma planilha online entre cada participante e o arquiteto.
No início da próxima etapa, todos os cenários propostos pelos participantes devem ser
apresentados, para que os demais participantes conheçam os diferentes pontos de vista. Em
seguida, todos devem priorizar os cenários de acordo com a relevância para a AS proposta. Esta
priorização pode ser feita da mesma forma que a priorização dos QAs.
Para a próxima etapa, de avaliação dos cenários propostos, também é interessante criar
um mecanismo para que seja realizada remotamente. Um exemplo é a criação de um formulário
online na qual cada participante deve dar uma nota para o quão cada cenário está contemplado
pela AS.
Feito isso, na etapa seguinte o arquiteto deve conduzir uma discussão a respeito das
interferências dos atributos de qualidades nos cenários priorizados, como descrito pelo ATAM.
Geralmente estas discussões geram conclusões de que, para atender a um cenário específico, mas
muito relevante, deve-se deixar de implementar totalmente um atributo de qualidade.
Por fim, o arquiteto deve apresentar os resultados finais do processo de avaliação. Nesta
etapa é importante apresentar todos os artefatos gerados em cada etapa do processo de avaliação.
Além disso, devem ser apresentados os pontos positivos e os pontos de melhoria que, a partir do
processo executado, foram identificados.
83 5.3. PROCESSO DE AVALIAÇÃO EXECUTADO
# QA Fonte Votos
1º Confiabilidade ISO/IEC 9126 e CMU/SEI-95-TR-021 4
2º Funcionalidade ISO/IEC 9126 3
3º Escalabilidade Participantes 2
4º Portabilidade ISO/IEC 9126 1
5º Disponibilidade Participantes 1
6º Segurança CMU/SEI-95-TR-021 1
7º Performance CMU/SEI-95-TR-021 1
8º Eficiência ISO/IEC 9126 1
9º Usabilidade ISO/IEC 9126 1
10º Acoplamento CMU/SEI-95-TR-021 0
11º Manutenabilidade ISO/IEC 9126 0
b) Priorização dos Cenários (Duração 1hora): A segunda etapa foi uma discussão
conduzida pelo arquiteto na qual o objetivo era a priorização dos cenários. Essa
discussão foi guiada pelo arquiteto, na qual cada cenário foi discutido e um peso de
relevância foi atribuído para cada cenario. Essa priorização levou em consideração
os cenários mais aplicáveis, coerentes e factíveis na AS proposta.
Ao término desta reunião, os cenários resultantes são exibidos na Tabela 5.6, ordenados
de acordo com a priorização.
ID Cenário
Armazenar dados fornecidos por diferentes contextos e provedores,
C1
independente do formato e da natureza do dado
Consultar dados oriundos de um provedor de dado, independente de
C2
quando esse dado foi gerado
Permitir que novos tipos de informações sejam fornecidas, a partir da
C3
combinação de uma ou mais fontes de dados
C4 Permitir a inclusão de novos provedores de dados
A AS deve auxiliar a interoperabilidade entre sistemas, na qual um
C5
evento gerado externamente pode disparar ações
A AS deve auxiliar a fusão de dados, na qual um evento produzido
C6 internamente com base na análise de dados/histórico pode gerar ações
externas
C7 A AS deve permitir a comunicação via API
A AS deve permitir a recuperação de grandes massas de dados
C8 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)
Permitir a criação e comunicação de instâncias federativas, baseada em
C10
serviços
Possuir mecanismo para a inclusão de novos protocolos de comunicação
C11
na AS
Plugar novas soluções para diferentes contextos utilizando a mesma
C12
infraestrutura
Suporte a serviços em Cloud Computing já existentes (Ex.: Google
C13
Analytics e cloud storage)
Gerenciar os dados do usuário de acordo com as políticas de privacidade
C14
governamentais
Para analisar os resultados na Figura 5.1, deve ser considerada a relevância dos cenários
propostos, priorizados durante o processo de avaliação.
Como é possível notar, na opinião dos participantes, a AS atende à três cenários de
maneira EXCELENTE. O primeiro cenário (C2) é relacionado aos mecanismos de distribuição
de dados implementados no MGDD (Seção 4.3.3), principalmente a utilização da DHT de dados.
Conforme discutido, a utilização da DHT permitiu que os recursos fornecedores e consumidores
e os canais de dados estejam distribuídos em uma infraestrutura de cloud.
Já o segundo cenário categorizado como EXCELENTE (C4) foi obtido a partir da imple-
mentação do padrão publisher-subscriber também no MGDD. Esta implementação permite que
um dado seja disponibilizado para todos os recursos consumidores assim que é produzido. No
contexto de CI, esta característica básica é de suma importância se todos os consumidores recebe-
ram os dados simultâneamente e está contemplada nesta proposta. Além disso, o desacoplamento
entre fornecedores e consumidores de dados oriundos a partir do padrão publisher-subscriber
também é de suma importância para futuras expansões da AS.
O último cenário avaliado positivamente (C7) é oriundo do modelo de abstração e da
flexibilidade implementada no MAC (Seção 4.3.1). Esta abstração permite que novos protocolos
de troca de mensagens sejam inseridos sob demanda. Já a flexibilidade está relacionada à
capacidade de trocar a interface REST ou, até mesmo, incluir outro padrão em paralelo.
A maioria dos cenários foram considerados SATISFATÓRIOS pelos participantes da
avaliação. Embora este resultado indique que a AS, em uma primeira instância, atende a um
conjunto de contextos de utilização, ela deve ser aprimorada para atender de maneira segura e
eficiente aos demais contextos.
Além disso, dois cenários foram classificados como PÉSSIMO. O primeiro (C9) está
relacionado à inserção de algum mecanismo de tolerância a falhas. Não foi encontrado nenhum
mecanismo semelhante nas abordagens encontradas na literatura. Porém, no contexto de uma CI
é inadmissível que todo o sistema da cidade deixe de funcionar devido à um problema em algum
módulo ou componente de software. A literatura apresenta diversas técnicas de redundância,
tanto de dados como de componentes de software, que devem ser inseridas na proposta. Além
disso, estratégias de backup, controle de acesso e demais aspectos relacionados à confiabilidade
da proposta devem ser investigadas.
O outro cenário que foi classificado como PÉSSIMO (C14) corresponde às políticas
de privacidade de dados utilizadas pela AS. Conforme pôde ser verificado, este requisito não
faz parte desta AS. Além disso, esta necessidade foi identificada no começo desta pesquisa,
porém um outro trabalho de mestrado está sendo desenvolvido com este escopo. Este trabalho
de privacidade será acoplado à esta proposta assim que finalizado. Para isso, as definições de
interfaces e padrões de mensagens estão sendo definidas em conjunto. O escopo deste trabalho
89 5.5. AMEAÇAS À AVALIAÇÃO
A outra ameaça está relacionada com a ordem das etapas do método de avaliação.
Como apresentação da arquitetura foi realizada antes da definição e priorização dos atributos
de qualidade e dos cenários, a opinião dos participantes pode ter sido enviesada. Apesar disto,
no inicio das etapas de definição e priorização dos atributos de qualidade e dos cenários foi
ressaltado que as opiniões deveriam ser a partir da apresentação dos objetivos de negócios. Logo,
uma melhoria no método de avaliação é alterar a ordem destas etapas.
6
Conclusão
Uma vez que a AS para Cidade Inteligente (CI) foi especificada e projetada, algumas
conclusões e direções para trabalhos futuros podem ser apontadas.
Desta forma, este Capítulo apresenta as conclusões finais deste trabalho e está organizado
da seguinte maneira: a Seção 6.1 apresenta um resumo das principais conclusões deste trabalho.
A Seção 6.2 relata alguns trabalhos relacionados. A Seção 6.3 aponta um conjunto de trabalhos
futuros, e finalmente, a Seção 6.4 contém a conclusão final da dissertação.
Apesar da evidente necessidade de cidades cada vez mais inteligentes, ainda não
há um consenso sobre a definição mais adequada para o termo CI. Mesmo assim,
várias abordagens estão sendo desenvolvidas com o paradigma de utilizar IoT como
ferramenta para a implementação, de fato, de uma CI. Neste contexto, as tecnologias
IoT são utilizadas, principalmente, para monitorar, controlar e atuar sobre os diversos
serviços urbanos (Capítulo 2).
92 CAPÍTULO 6. CONCLUSÃO
A AS proposta por esta dissertação permite que os dados entre os diferentes servi-
ços urbanos sejam difundidos para todos os recursos interessados. Para tal, a AS
implementa um padrão arquitetural bastante conhecido na literatura chamado de
publisher-subscriber (Capítulo 4).
bastante similar com esta proposta no quesito de modelagem do ambiente real. Porém, a principal
diferença é a existência nesta proposta de um mecanismo para geração de histórico para a previsão
de futuros eventos. Além disto, as informações de cada sensor que está fornecendo os dados pode
ser utilizada para otimizar o desempenho dos algoritmos SHAO (2011); HERNáNDEZ-MUñOZ
et al. (2011); VEGA-BARBAS et al. (2012).
Neste sentido, em Hernandez-2011 é proposta uma AS (USN), com o objetivo de prover
uma infraestrutura que seja capaz de integrar sensores heterogêneos e dispersos geograficamente
em um base centralizadora, na qual serviços podem ser facilmente desenvolvidos. Esta aborda-
gem de Hernandez-2011 é similar a esta proposta nas técnicas adotadas para permitir a integração
de sensores heterogêneos. A principal diferença é que nesta proposta novos protocolos de troca
de mensagens podem ser facilmente inseridos. Além disto, o custo para integrar diferentes
fornecedores de dados nesta proposta é muito baixo para otimizar o desempenho em larga escala.
Finalmente, em Components-2009 é proposta uma AS baseada em quatro princípios:
aplicações, negócios, gerenciamento de processos e infraestrutura de redes. O primeiro princípio
corresponde às aplicações que fazem uso de diferentes tecnologias para monitorar sensores,
como GPS. A maioria dessas aplicações atendem as demandas operacionais das cidades, porém,
ao utilizar as regras definidas no segundo princípio - negócios - elas podem agregar soluções
economicamente viáveis. O terceiro princípio é o gerenciamento de processos no qual relaciona-
mentos, regras, estratégias e políticas entre as aplicações e as unidades de negócios são definidos.
O último princípio corresponde a toda a infraestrutura de rede, responsável por conectar os
outros três princípios. A principal diferença da abordagem de Components-2009 para esta
proposta é a criação de um componente específico para modelos de negócio. Este diferencial
pode ser facilmente incorporado nesta proposta, uma vez que este componente poderia ser um
consumidor de dado que, a partir dos dados que estão trafegando na arquitetura, inferir um
modelo de negócios eficaz com estas informações.
Ao analisar os principais trabalhos relacionados, pôde-se observar que todos visam miti-
gar apenas uma deficiência tecnológica relacionada à CI. Apenas a abordagem de livingPlanIT
visa integrar as informações provenientes de diferentes domínios de uma cidade, o que pode
contribuir para tornar uma cidade de fato inteligente.
Além disto, o conjunto de requisitos que esta proposta contempla é superior à todos os
trabalhos relacionados. Apesart deste conjunto de requisitos ter sido definido juntamente com
esta proposta, este refleta uma série de características que qualquer Arquitetura de Software (AS)
para Cidade Inteligente (CI) deveria atender.
Os resultados desta dissertação estão baseados em um trabalho de pesquisa que analisou
o estado da arte e da prática no tocante as AS’s de software para CI que combinam tecnologias
IoT. Estes resultados envolvem, entre outras coisas: (i) um levantamento das soluções existentes,
(ii) a extração de um conjunto de requisitos que uma AS para CI deve atender, (iii) o projeto da
AS, (iv) a avaliação preliminar da AS e (v) uma implementação de referência.
94 CAPÍTULO 6. CONCLUSÃO
Políticas de privacidade: Já que vários dados pessoais dos cidadãos trafegarão pela
AS, torna-se indispensável a adequação de políticas de privacidade, principalmente
relacionadas ao armazenamento, utilização e descarte dos dados;
Modelo de Negócio: Modelos de negócios devem ser discutidos para suprir os custos
envolvendo a implementação, manutenção e expansão desta AS no ambiente real.
Uma estratégia que deve ser discutida é a parceria com governos e empresas para a
utilização desta AS;
Análises de big data: Com o alto volume de dados potencialmente gerado a partir da
utilização desta AS, análises de big data devem ser feitas para otimizar o desempenho
dos serviços urbanos;
6.4 Conclusão
A necessidade de cidades cada vez mais inteligentes é notoriamente crescente. Vários
dados publicados pela mídia em geral comprova que o crescimento populacional não está alinhado
com o desenvolvimento das infraestruturas e dos principais serviços urbanos. A precariedade
destes serviços urbanos afeta negativamente a qualidade de vida dos cidadãos.
Logo, torna-se fundamental o investimento em estratégias que visam mitigar estes
problemas urbanos para otimizar a vida dos cidadãos. Estas iniciativas devem ser desenvolvidas
considerando as partes envolvidas: governo e cidadãos. Além disso, torna-se importante que os
cidadãos estejam conscientes do seu papel em prol de uma cidade melhor para todos.
Neste sentido, esta dissertação apresentou a especificação e o projeto de uma AS para
CI que permite a integração de tecnologias IoT para mitigar estes problemas urbanos. Esta
95 6.4. CONCLUSÃO
AS foi proposta a partir de um conjunto de requisitos mais importante extraído das principais
abordagens disponíveis na literatura.
97
References
DIRKS, S.; KEELING, M. A Vision of Smarter Cities. Centre for Economic Development,
Dublin, Ireland, [S.l.], 2009.
DOBBS, R.; INSTITUTE, M. G. Urban World: mapping the economic power of cities. [S.l.]:
McKinsey Global Institute, 2011.
EGER, J. M. Ten Steps to Becoming a Smart Community. [S.l.]: California Institute for
Smart Communities, 2011. "[Online] Acessado em 16-Outubro-2012".
ERBAD, A. et al. MAGIC Broker: a middleware toolkit for interactive public displays. In:
ANNUAL IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS, 6., Washington, DC, USA. Anais. . . IEEE Computer Society, 2008.
p.509–514. (PERCOM ’08).
FAZIO, M. et al. Heterogeneous Sensors Become Homogeneous Things in Smart Cities. In:
SIXTH INTERNATIONAL CONFERENCE ON INNOVATIVE MOBILE AND INTERNET
SERVICES IN UBIQUITOUS COMPUTING (IMIS). Anais. . . [S.l.: s.n.], 2012. p.775 –780.
FELS, S. Sustainable communities: where does communication fit in? In: FIRST
INTERDISCIPLINARY WORKSHOP ON COMMUNICATION FOR SUSTAINABLE
COMMUNITIES, New York, NY, USA. Anais. . . ACM, 2010. p.1:1–1:2. (IWCSC ’10).
FILIPPONI, L. et al. Smart City: an event driven architecture for monitoring public spaces with
heterogeneous sensors. In: INTERNATIONAL CONFERENCE ON SENSOR
TECHNOLOGIES AND APPLICATIONS, 4., Washington, DC, USA. Anais. . . IEEE
Computer Society, 2010. p.281–286.
GAMA, K.; DONSEZ, D. A survey on approaches for addressing dependability attributes in the
OSGi service platform. SIGSOFT Softw. Eng. Notes, New York, NY, USA, v.35, n.3, p.1–8,
May 2010.
HALL, N. Are There Really More Mobile Phones Than Toothbrushes? "[Online] Available:
1-August-2012", http://bit.ly/RInZMi.
HAUBENSAK, O. Smart Cities and Internet of Things. Business Aspects of the Internet of
Things, [S.l.], p.33, 2011.
99 REFERENCES
HERNáNDEZ-MUñOZ, J. M. et al. Smart cities at the forefront of the future internet. In:
DOMINGUE, J. et al. (Ed.). The future internet. Berlin, Heidelberg: Springer-Verlag, 2011.
p.447–462.
ISO/IEC. ISO/IEC 9126. Software engineering – Product quality. [S.l.]: ISO/IEC, 2001.
KAZMAN, R. et al. SAAM: a method for analyzing the properties of software architectures. In:
SOFTWARE ENGINEERING, 16., Los Alamitos, CA, USA. Proceedings. . . IEEE Computer
Society Press, 1994. p.81–90. (ICSE ’94).
KAZMAN, R. et al. Experience with performing architecture tradeoff analysis. In: SOFTWARE
ENGINEERING, 1999. PROCEEDINGS OF THE 1999 INTERNATIONAL CONFERENCE
ON. Anais. . . [S.l.: s.n.], 1999. p.54–63.
KAZMAN, R. et al. A Basis for Analyzing Software Architecture Analysis Methods. Software
Quality Control, Hingham, MA, USA, v.13, n.4, p.329–355, Dec. 2005.
KLEIN, C.; KAEFER, G. From Smart Homes to Smart Cities: opportunities and challenges
from an industrial perspective. In: INT. CONF. NEW2AN AND 1ST RUSSIAN
CONFERENCE ON SMART SPACES, RUSMART ON NEXT GENERATION
TELETRAFFIC AND WIRED/WIRELESS ADVANCED NETWORKING, 8., Berlin,
Heidelberg. Anais. . . Springer-Verlag, 2008. p.260–260.
KOMNINOS, N. Intelligent Cities: innovation, knowledge systems and digital spaces. [S.l.]:
Taylor & Francis, 2002.
KRCO, S. SmartSantander - A smart city example. ICT event 2010, [S.l.], 2010.
KRUCHTEN, P. The 4+1 View Model of Architecture. IEEE Softw., Los Alamitos, CA, USA,
v.12, n.6, p.42–50, Nov. 1995.
LEE, J.; BAIK, S.; CHOONHWA LEE, C. Building an integrated service management platform
for ubiquitous cities. Computer, Los Alamitos, CA, USA, v.44, p.56–63, 2011.
100 REFERENCES
TOMORDY, M. Smart Cities - Transforming the 21st century city via the creative use of
technology. [S.l.]: ARUPCorp., 2011.
WU, H. et al. A Framework for Integrating Heterogeneous Spatial Information and Applications
Adaptively Based on Multi-agent and Web Service. In: MULTIMEDIA INFORMATION
NETWORKING AND SECURITY (MINES), 2011 THIRD INTERNATIONAL
CONFERENCE ON. Anais. . . [S.l.: s.n.], 2011. p.253 –257.
ZYGIARIS, S. Smart City Reference Model: assisting planners to conceptualize the building of
smart city innovation ecosystems. Journal of the Knowledge Economy, [S.l.], p.1–15, 2012.
Apêndice
105
A
Repositórios de busca na SLR
B
Avaliação da Arquitetura de Software (AS)