Departamento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Mandala - Interoperabilidade baseada em
Sistemas de Sistemas no âmbito de Cidades
Inteligentes
Altair Brandão Mendes
Natal-RN Fevereiro de 2018
Mandala - Interoperabilidade baseada em Sistemas de
Sistemas no âmbito de Cidades Inteligentes
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Linha de pesquisa: Engenharia de Software
Orientadores
Dra. Thaís Vasconcelos Batista
Dr. Frederico Araújo da Silva Lopes
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Fevereiro de 2018
Mendes, Altair Brandão.
Mandala - interoperabilidade baseada em sistemas de sistemas no âmbito de cidades inteligentes / Altair Brandão Mendes. -2018.
87 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Programa de Pós-Graduação em Sistemas e Computação. Natal, RN, 2018.
Orientadora: Thais Vasconcelos Batista.
Coorientador: Frederico Araújo da Silva Lopes. 1. Engenharia de software - Dissertação. 2.
Interoperabilidade - Dissertação. 3. Middleware - Dissertação. 4. Sistema de sistemas Dissertação. 5. Cidades inteligentes -Dissertação. I. Batista, Thais Vasconcelos. II. Lopes, Frederico Araújo da Silva. III. Título.
RN/UF/CCET CDU 004.41
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Inicialmente, agradeço a DEUS, por me guiar, iluminar, dar saúde e me dar tranqui-lidade para seguir em frente com os meus objetivos e não desanimar com as dificuldades.
Aos meus pais, Mário e Maria José (carinhosamente chamada de Mariinha), meu infi-nito agradecimento pela educação, apoio e por sempre acreditarem em minha capacidade. Obrigado pelo amor incondicional!
À minha querida esposa, Danielle, por ser tão importante em minha vida. Sempre ao meu lado, me dando forças e me fazendo acreditar que posso mais do que imagino. Obrigado por entender minhas faltas e ausências em alguns momentos mais complicados. Sem o seu apoio, certamente, eu não teria conseguido.
Aos meus queridos filhos, Caio e Victor, que, mesmo sendo tão pequenos e querendo sempre a presença do pai, sabiam entender quando eu não podia brincar, colocar para dormir, conversar e estar mais presente. Eu amo vocês!
Às minhas irmãs, Adriana e Andréa (Deinha), meu agradecimento especial, por esta-rem sempre próximas e pela confiança e pelo orgulho que sempre tiveram de mim.
À minha avó Maria, tia Francinete e tio Belo por sempre quererem o meu bem e acreditarem em minha capacidade.
À minha querida sobrinha Minna Miná que sempre me apoiou e com a sua competência me ajudou bastante, criando inclusive a logo do produto desenvolvido neste trabalho.
Aos meus amigos Fábio Dametto, Juliana Dametto, Cícero Gadê, Ana Karine e Gilvete Gomes pelo grande incentivo.
À minha querida orientadora Thais Batista por sempre acreditar em minha compe-tência e determinação e pelo incondicional apoio em todos os momentos deste mestrado. Muito obrigado pela simpatia e educação que sempre me tratou.
Ao co-orientador Fred Lopes. A você eu faço um agradecimento especial pois foste muito mais que um co-orientador e um professor, você foi e continuará sendo um grande amigo. Muito obrigado pelo apoio, dicas, sugestões, companheirismo e amizade. Um
Agradeço também aos companheiros de curso e de projeto, Stefano Loss, que partici-pou ativamente comigo do projeto Mandala e fez, de fato, acontecer; ao professor Everton Cavalcante pelas dicas, ideias e contribuições; e aos amigos Jorge Pereira e Cláudio Trin-dade que percorreram comigo, embora em trabalhos diferentes, esta longa e árdua, porém gratificante, trajetória.
Por fim, agradeço à Instituição IBGE (Instituto Brasileiro de Geografia e Estatística), na pessoa de Aldemir Freire, que me deu apoio e incentivo, durante a execução do curso.
Sistemas no âmbito de Cidades Inteligentes
Autor: Altair Brandão Mendes Orientadora: Dra. Thaís Vasconcelos Batista Co-orientador: Dr. Frederico Araújo da Silva Lopes
Resumo
A área de Engenharia de Software vem, ao longo dos anos, introduzindo ao seu universo uma gama de novas tecnologias, paradigmas e linguagens de programação. Isto tem como consequência o desenvolvimento de uma grande variedade de sistemas de informação, para os mais diversos propósitos e utilizando os mais diferentes conceitos. Com a facilidade de acesso à informação presente nos dias atuais, impulsionada pela popularização da Internet e dos dispositivos como smartphones, as pessoas estão exigindo informações mais rápidas, abrangentes e completas. No entanto, para estas informações serem geradas, frequente-mente, há a necessidade de interoperar vários sistemas de informação. Tal fato pode se tornar um problema se for considerado que os sistemas são, na grande maioria, produ-zidos por linguagens de programação diferentes e/ou não foram projetados para serem interoperáveis e que necessitarão negociar uma forma de comunicação com cada sistema que deseje integrar. Nesse cenário, este trabalho apresenta o Mandala, uma plataforma de middleware baseada em Sistema de Sistemas (ou SoS, do termo em inglês System of Sys-tems) para realizar a interoperabilidade entre sistemas de informação. Além de abstrair a negociação da forma de comunicação entre os sistemas de informação, por ser baseada em SoS, novas funcionalidades podem ser emergidas trazendo benefícios que não podem ser alcançados pelos sistemas envolvidos trabalhando de forma isolada. Para avaliar o Man-dala, foi desenvolvido um estudo de caso, utilizando sistemas simulados de uma cidade inteligente, que é um ambiente que possui características adequadas para o uso de SoS, procurando validar o conceito de interoperação baseado em SoS proposto pela plataforma.
Palavras-chave: Interoperabilidade, Middleware, Sistema de Sistemas, Cidades Inteligen-tes.
Author: Altair Brandão Mendes Advisors: Dra. Thaís Vasconcelos Batista and Dr. Frederico Araújo da Silva Lopes
Abstract
The Software Engineering has, over the years, introduced to its universe a range of new technologies, paradigms and programming languages. This has as consequence the deve-lopment of a great variety of information systems, for the most diverse purposes and using the most different concepts. With the ease of access information at the moment, where a large number of people have access to the Internet, having smartphones a very important role in this process, the idea is that people consume information more easily, with response faster and using as few resources. The solution often is to provide the systems integration, since what the user usually wants is sprayed into several data sources. This can become a problem if it is considered that systems are mostly produced by different programming languages and/or are not designed to be interoperable and will need to negotiate a form of communication with each system that they wish to integrate. In this scenario, this dissertation presents the Mandala, a SoS-centric middleware, to perform interoperability between information systems (constituent systems). Systems of systems (SoS) arise from the interaction among these constituent systems, but the result of such an interaction is said to be more than the sum of the constituents as it enables an SoS to offer new functionalities not provided by any of the constituents working alone. To evaluate the Mandala, a case study was developed using simulated systems of an smart city, which is an environment that has adequate characteristics for the use of SoS, trying to validate the concept of interoperation based on SoS proposed by the platform.
1 Níveis da Interoperabilidade (CURRY, 2012) . . . p. 25
2 Ciclo de vida de um SoS . . . p. 26
3 Funcionalidades oferecidas pelo SoS . . . p. 27
4 Fluxo da missão global Gerar Rotas Otimizadas . . . p. 31
5 Exemplo do código XML gerado pelo BPMN . . . p. 32
6 Arquitetura do JADE com base no modelo de referência definido pela
FIPA (JADE, 2015) . . . p. 41
7 Características de uma cidade inteligente . . . p. 43
8 Arquitetura do Mandala . . . p. 48
9 Envio dos dados do sistema pelo desenvolvedor do Sistema Constituinte
e criação do SoS pelo desenvolvedor do SoS. . . p. 49
10 Publicação do Serviço Web e disseminação nos repositórios das
informa-ções sobre o SoS criado. . . p. 50
11 Solicitação de execução do SoS - Visão do SoS Server . . . p. 51
12 Comunicação do Broker. . . p. 52
13 Diagrama de atividades referente à criação do SoS. . . p. 54
14 Diagrama de atividades referente à publicação do SoS e divulgação aos
interessados sobre a criação do SoS. . . p. 55
15 Diagrama de atividades referente à execução do SoS. . . p. 56
16 Tela de Gerenciamento do JADE . . . p. 57
17 Mensagem do Tipo Request . . . p. 57
18 Mensagem do Tipo Inform . . . p. 57
21 Trecho de código de acesso ao repositório . . . p. 59
22 Classe abstrata de acesso ao sistema constituinte . . . p. 60
23 Classe concreta que acessa o sistema constituinte . . . p. 61
24 Formulário de envio dos dados relativos ao sistema constituinte . . . . p. 61
25 Plugin utilizado na IDE Eclipse para modelar a missão global do SoS . p. 62
26 Criação do perfil do Mandala na ferramenta de modelagem baseada em
BPMN . . . p. 63
27 Criação de um diagrama BPD relativo a uma missão global de um SoS p. 63
28 Utilização da Biblioteca DOM para Modelagem do arquivo XML . . . p. 64
29 Divulgação aos Broker participantes sobre a criação do SoS . . . p. 65
30 Classe editada para a publicação do serviço Web . . . p. 66
31 Serviço Web publicado para acesso pelos clientes . . . p. 66
32 Código que apresenta quando a mensagem de solicitação de execução do SoS é enviada ao Broker responsável pela execução do primeiro passo do
1 Características de agentes de software . . . p. 34
TIC - Tecnologia da Informação e Comunicação
API - Application Programming Interface
SoS - Sistema de Sistemas
SoIS - Sistema de Sistemas de Informação
BPMN - Business Process Model and Notation
BPD - Diagrama de Processos de Negócio
ACL - Linguagem de Comunicação de Agentes
AID - Identificador de Agentes
FIPA - Foundation for Intelligent, Phisical Agents
JADE - Java Agent Development Framework
JVM - Java Virtual Machine
CI - Cidades Inteligentes
ONU - Organização das Nações Unidas
1 Introdução p. 17 1.1 Motivação . . . p. 18 1.2 Objetivos . . . p. 21 1.3 Metodologia . . . p. 21 1.4 Organização do trabalho . . . p. 22 2 Fundamentação Teórica p. 23 2.1 Interoperabilidade . . . p. 23 2.2 Sistemas de Sistemas . . . p. 25
2.2.1 Características dos Sistemas de Sistemas . . . p. 26
2.2.2 Missões no contexto de Sistemas de Sistemas . . . p. 28
2.2.3 Tipos de Sistemas de Sistemas . . . p. 28
2.2.4 Desafios da interoperabilidade em Sistemas de Sistemas . . . p. 29
2.3 Processos de Negócio . . . p. 29
2.4 Agentes de software . . . p. 32
2.4.1 Arquitetura dos agentes . . . p. 35
2.4.1.1 Agente reativo simples . . . p. 35
2.4.1.2 Agente reativo baseado em conhecimento . . . p. 35
2.4.1.3 Agente baseado em objetivo . . . p. 36
2.4.1.4 Agente baseado em utilidade . . . p. 36
2.4.2 Interação entre agentes . . . p. 36
2.4.2.3 Ontologia . . . p. 37
2.4.3 Características dos domínios de aplicações de agentes . . . p. 38
2.4.3.1 Sistemas abertos . . . p. 38 2.4.3.2 Sistemas complexos . . . p. 39 2.4.3.3 Sistemas ubíquos . . . p. 39 2.4.4 FIPA . . . p. 39 2.4.5 JADE . . . p. 40 2.5 Cidades Inteligentes . . . p. 41 2.5.1 Definições . . . p. 42
2.5.2 TIC em cidades inteligentes . . . p. 45
3 Mandala p. 47 3.1 Arquitetura . . . p. 48 3.1.1 SoS Composer . . . p. 49 3.1.2 SoS Manager . . . p. 50 3.1.3 SoS Server . . . p. 51 3.1.4 Broker . . . p. 52 3.1.5 Comunicação e Repositórios . . . p. 53 3.2 Funcionamento . . . p. 54 3.3 Implementação . . . p. 55
3.3.1 Implementação dos agentes de software . . . p. 56
3.3.2 Implementação dos repositórios . . . p. 59
3.3.3 Implementação do Broker . . . p. 60
3.3.4 Implementação dos módulos SoS Composer, SoS Manager e SoS
Server . . . p. 62
4.2 Objetivo . . . p. 70
4.3 Projeto do Estudo de Caso . . . p. 70
4.4 Preparação da Coleta de Dados . . . p. 71
4.5 Coleta e Análise dos Dados . . . p. 71
4.6 Discussão . . . p. 72
5 Trabalhos relacionados p. 75
5.1 Linha de atuação: Interoperabilidade e SoS . . . p. 76
5.2 Linha de atuação: Modelagem de missões . . . p. 77
5.3 Linha de atuação: Uso de agentes de software no contexto de SoS . . . p. 78
6 Considerações Finais p. 79 6.1 Contribuições . . . p. 80 6.2 Limitações . . . p. 80 6.3 Ameaças à validade . . . p. 82 6.4 Trabalhos futuros . . . p. 82 Referências p. 83
1
Introdução
A Engenharia de Software, assim como o próprio universo da TIC (Tecnologia da Informação e Comunicação), é uma área que vive em constante transformação. Tal dina-mismo resulta em uma diversidade de sistemas de informação desenvolvidos com as mais variadas tecnologias e padrões.
Já houve o auge do paradigma de programação estruturada, do paradigma de ori-entação a objetos e, atualmente, vivencia-se a fase da computação ubíqua, vista mais fortemente com o advento da Internet das Coisas (IoT, do termo em inglês Internet of Things) e da tecnologia mobile, na qual praticamente tudo e todos estão conectados.
Muito provavelmente é em função desta fase de alta integração entre pessoas e disposi-tivos que a visão e a exigência das pessoas em relação aos sistemas de informação evoluíram com o passar do tempo. É difícil admitir hoje, pela cultura moderna, por exemplo, que uma empresa não divulgue suas informações ou, dependendo do ramo de atividade, não proveja seus serviços pela Internet. É mais prático e, muitas vezes, mais rápido resolver situações através de um acesso a uma página WEB ou a um aplicativo disponível em um smartphone do que ir fisicamente a um determinado local. O dinamismo exigido pelas pessoas ocorre pelo fato de haver facilidade de acesso aos dispositivos e informações e os dispositivos e sistemas evoluem em função da exigência das pessoas.
Esta facilidade de acesso à informação aliada ao dinamismo exigido pelas pessoas traz ainda outra característica bastante interessante: as pessoas não querem obter em um aplicativo, site ou qualquer outro sistema uma informação que esteja desconexa ou não reflita a realidade. Se alguém atualiza uma informação em um setor de uma prefeitura, por exemplo, para ela, é inconcebível, nos dias atuais, que esta informação não esteja disseminada nos demais setores do órgão ou em outros sistemas que dependam daquela informação, de forma instantânea.
Entretanto, é bastante difícil, dada a necessidade de pluralidade de informações reque-rida por um usuário, que as suas expectativas sejam atendidas por um único sistema de
informação. Inconscientemente, não é apenas uma informação que as pessoas exigem, elas requerem também que os sistemas de informação estejam integrados e aptos a atendê-las como se fossem um único sistema.
1.1
Motivação
De fato, é utópico imaginar que todas as informações pudessem ser disponibilizadas por apenas um grande e completo sistema de informação. Nem em uma mesma empresa ou órgão público há apenas um sistema que resolva tudo. Às vezes, o que acontece, mesmo tomando por base uma única empresa, é uma variedade de sistemas, desenvolvidos, não raramente, por linguagens de programação e paradigmas diferentes. Diante desta situação, não é difícil de prever que a solução para resolver este problema é fazer com que os sistemas que possam produzir alguma informação relevante se conversem e realizem a integração. Ao se falar em integração, para o contexto deste trabalho, imagina-se que seja muito mais que somente uma conexão estabelecida. A ideia é utilizá-la como sinônimo de interoperação, cujo entendimento da informação é o foco.
Para realizar uma integração entre sistemas é fundamental que exista uma forma de comunicação comum aos sistemas que desejem se integrar. Fazendo uma analogia à vida real, se uma pessoa fala português e outra alemão, elas precisam de uma forma de comunicação comum para conversarem, caso uma não entenda o idioma da outra. Ou elas utilizam um terceiro idioma, como o inglês, ou fazem uso de um tradutor ou realizam a comunicação via sinais, por exemplo.
O grande problema é que quase metade dos sistemas de informação não se preocupa com a interoperabilidade na sua fase de projeto (ABUKWAIK; ROMBACH, 2017). Ou não fazem uso ou somente se preocupam após a fase de implementação. Para que seja possível a integração com estes sistemas, algum artifício extra, assim como ocorreu na analogia supracitada, precisa ser realizado para que este sistema possa se comunicar com outros. Este artifício pode ser uma API1 ou alguma alteração no código-fonte que permita que uma conversa com outro sistema possa ser realizada.
Acontece que nem sempre uma integração via serviço Web, API REST ou alterações no código-fonte são suficientes para se resolver o problema de interoperabilidade. Dependendo da quantidade de integrações que o sistema venha a realizar, as negociações podem se tornar problemáticas e outras alternativas que abstraiam essa complexidade se tornem
necessárias. A seguir, duas alternativas serão apresentadas como formas de realização de integração entre sistemas.
Uma alternativa para realizar a integração de sistemas é a utilização de uma forma direta de comunicação. Esta forma consiste no fato de que dois sistemas que desejem se integrar devem negociar uma forma de comunicação comum. Caso ambos os sistemas estabeleçam uma comunicação e haja a necessidade de um outro sistema participar da integração, este novo sistema precisa negociar a comunicação com os outros dois para que seja possível a troca de informações. Para este tipo de integração, a complexidade pode aumentar bastante com o aumento do número de sistemas participantes, uma vez que dificilmente todos os sistemas estarão padronizados no tipo de linguagem de programação e nos tipos de dados trocados, necessitando, algumas vezes de alteração no código-fonte dos sistemas participantes para realizar adequações, a cada inserção ou remoção de um sistema.
Uma segunda alternativa para realizar a integração entre sistemas é utilizar o conceito de Sistemas de Sistemas, ou simplesmente SoS (do termo em inglês, Systems of Systems). Um SoS pode ser definido como um conjunto de sistemas complexos, independentes e heterogêneos (sistemas constituintes) que possuem seus próprios propósitos (missões indi-viduais) e colaboram um com os outros para satisfazer objetivos comuns (missões globais) (WHITTINGTON; DOGAN, 2015)(MAIER, 1998). SoS surgem justamente da interação entre esses diferentes sistemas constituintes, mas o resultado de tal interação é mais do que a mera soma do que pode ser alcançado por estes sistemas, uma vez que ela permite que um SoS ofereça novas funcionalidades que não são providas por qualquer um dos sistemas constituintes operando de forma isolada. Este resultado é conhecido como comportamento emergente. Neste contexto, tem sido possível observar ainda o surgimento dos chamados Sistemas de Sistemas de Informação (SoIS, do termo em inglês Systems of Information Systems), uma classe específica de SoS orientada a processos de negócio em que os sis-temas constituintes são em sua maior parte sissis-temas de informação, cada um podendo pertencer a diferentes organizações (MAJD; MARIE-HÉLÈNE; ALOK, 2015)(SALEH; ABEL, 2015).
A característica de independência, inerente ao SoS, remete ao fato de que os sistemas constituintes que colaborem com o ambiente não devem sofrer interferência operacional nem gerencial por participarem do SoS. Um sistema pode fazer parte de vários SoS e um SoS pode conter vários sistemas e, por causa dessa característica, a entrada do sistema, assim como a sua saída, ao ambiente do SoS, deve ser transparente. Em um ambiente de
dinamismo, também inerente a este tipo de sistema, onde sistemas constituintes podem entrar e sair da colaboração a cada instante, uma ferramenta precisa abstrair esta comple-xidade de gerenciamento e de negociação entre as partes. Esta abstração pode ser provida por um middleware, que é uma camada de software existente entre o sistema operacional e a camada de aplicação, que tem por objetivo gerenciar a complexidade e a heteroge-neidade inerentes aos sistemas distribuídos. Também deve ser função desse middleware conduzir para que a interação entre os sistemas traga à tona o diferencial deste tipo de integração, que é o comportamento emergente.
Falou-se, em um momento anterior deste texto, que as pessoas exigem maior dina-mismo e integração dos sistemas, ainda que de forma inconsciente. Deve-se lembrar que a maioria das pessoas vive em cidades e esta exigência, certamente, é refletida naquele ambiente. Sendo assim, um contexto real, que vem ganhando notoriedade e que é um cenário perfeito para fazer uso dos conceitos de SoS, é o ambiente de cidades inteligentes. Este ambiente é caracterizado por possuir como objetivo a melhoria da qualidade de vida dos cidadãos, utilizando, primordialmente, a TIC como meio de provimento.
Cidades inteligentes podem ser consideradas, de fato, ambientes propícios para SoS, uma vez que tipicamente englobam alguns sistemas distribuídos envolvidos em relaciona-mentos complexos, incluindo a integração e a interação com outros sistemas em direção ao provimento de novas funcionalidades (CAVALCANTE et al., 2017)(TEKINERDOGAN; ERATA, 2017).
Em cidades inteligentes existem sistemas geridos por empresas públicas, privadas, modernos, legados, utilizando sensores, com tecnologia mobile, enfim, das mais diversas formas de tecnologia e de acesso. Devido ao objetivo final das cidades inteligentes, já citado há pouco, que é o provimento da qualidade de vida aos cidadãos, e diante da gama de sistemas existentes, é plausível de imaginar que a integração entre alguns destes sistemas traga benefícios importantes, não somente pela simples integração, mas pelos comportamentos emergentes, característicos dos SoS, que podem surgir.
No entanto, quando há a necessidade de lidar com uma variedade de dispositivos e sistemas, desafios na comunicação tendem a surgir(MOTTA; OLIVEIRA; TRAVASSOS, 2017). Dessa forma, uma adequada integração tem sido cada vez mais necessária para prover a cooperação entre sistemas independentes, a fim de prover funções mais complexas, que não podem ser providas por algum sistema trabalhando de forma separada(NAKAGAWA et al., 2013). Mas, segundo (VARGAS; GOTTARDI; BRAGA, 2016), o campo de SoS ainda sofre com o lento amadurecimento, no contexto de sistemas de informação, quando
compa-rado a outros campos da Engenharia de Software. Diante deste fato, estudos mostram-se necessários para suprir estas lacunas, em busca de benefícios para a área.
1.2
Objetivos
Considerando as informações destacadas nas seções anteriores, este trabalho tem como objetivo principal propor, especificar, implementar e avaliar uma plataforma de Mid-dleware, denominada Mandala2, específica para realizar a interoperabilidade entre siste-mas de informação.
O Mandala é uma plataforma distribuída, baseada em SoS (mais especificamente um SoIS3), que utiliza em sua composição agentes de software para realizar a
interoperabili-dade entre sistemas, procurando diminuir a complexiinteroperabili-dade da negociação de comunicação entre os sistemas, independente da linguagem de programação que tenha sido desenvol-vido. Todo o fluxo de execução é guiado por processos de negócio e serve para direcionar a sequência de atividades da missão global a ser executada. A interface de contato com o usuário acontece via disponibilização de um serviço Web, que após ser solicitado, dispara a execução do SoS presente no Middleware.
Essa plataforma deve ser capaz de:
(i) integrar sistemas utilizando os conceitos do SoS; (ii) permitir que os sistemas constituintes possam colaborar com o SoS, de forma transparente; e, (iii) contribuir para a área de Engenharia de Software trazendo algum benefício para a integração de sistemas que vise à formação de um SoS.
1.3
Metodologia
O desenvolvimento do Mandala foi conduzido em três níveis: (i) Nível de Requisitos: neste nível, um estudo procurando identificar o estado da arte do tema SoS foi realizado para que fosse possível entender um pouco mais sobre o assunto, bem como identificar as lacunas e a possibilidade de melhorias e contribuições a serem exploradas por este trabalho. Além disso, outras tecnologias foram analisadas, em busca de correlação com eventuais linhas de exploração identificadas, a citar: linguagem BPEL, programação ori-entada a agentes, padrões de projetos, tecnologia de serviço Web; (ii)Nível de Arquitetura:
2Mandala - conhecida universalmente como o símbolo da integração e da harmonia 3Nesta dissertação será utilizada, muitas vezes, SoS como sinônimo de SoIS
após a identificação da linha de atuação que o Mandala poderia seguir e nos estudos das tecnologias, uma arquitetura foi desenvolvida para servir como linha de base para a im-plementação da ferramenta; e, (iii)Nível de Imim-plementação: nível onde foi realizada, de fato, a codificação da ferramenta, espelhando-se na arquitetura definida e nas tecnologias mais aplicáveis ao objetivo.
1.4
Organização do trabalho
O restante deste trabalho está organizado da seguinte forma: No Capítulo 2 são apre-sentados os conceitos básicos que fundamentam a proposta do Mandala. O Capítulo 3 detalha a arquitetura, o funcionamento e a implementação da plataforma. O Capítulo 4 se reserva a discutir os resultados de uma avaliação realizada com uma versão do Mandala. Já o Capítulo 5 apresenta a análise de trabalhos correlatos à plataforma proposta e, por fim, o Capítulo 6 apresenta as considerações finais e discute eventuais trabalhos futuros.
2
Fundamentação Teórica
A seguir serão descritos os conceitos e tecnologias necessários para o entendimento deste trabalho. Na Seção 2.1, fala-se sobre interoperabilidade, intuito principal da plata-forma proposta neste documento; Em seguida, serão apresentados os conceitos de SoS, Processos de Negócio e Agentes de Software, que são os pilares da construção da fer-ramenta e que estão dispostos nas Seções 2.2, 2.3 e 2.4, respectivamente. Por fim, na Seção 2.5 discute-se sobre cidades inteligentes, a fim de promover um conhecimento mais aprofundado sobre este tema que servirá como cenário para testes da plataforma.
2.1
Interoperabilidade
São inúmeras as definições associadas à interoperabilidade. De acordo com o IEEE1,
interoperabilidade de sistemas é a capacidade de dois ou mais sistemas ou componentes trocarem informações e usarem as informações trocadas. Na mesma linha de pensamento, (BROWNSWORD et al., 2006) especifica como sendo a capacidade que um conjunto de en-tidades comunicantes têm de compartilhar informações específicas e operarem de acordo com alguma semântica. A interoperabilidade envolve muito mais que fazer com que os sistemas se comuniquem um com o outro, requer entendimento e um esforço para garantir alguma compatibilidade semântica entre os sistemas envolvidos em relação aos dados e mensagens trocadas (MADNI; SIEVERS, 2014). Ainda segundo (MORDECAI; DORI, 2013), a interoperabilidade pode ser definida como a capacidade de organizações e usuários utili-zarem a interconectividade existente entre os sistemas que lhe servem, a fim de cooperar e colaborar, realizar transações comerciais ou operacionais e compartilhar e trocar infor-mações. De forma mais objetiva, (MOTTA; OLIVEIRA; TRAVASSOS, 2017) relata que, desde que as diferenças de comunicação entre os sistemas tenham sido superadas, a interopera-bilidade é a capacidade de interação entre eles em busca de um propósito específico.
Fica evidente, com base nas definições de interoperabilidade citadas anteriormente
que, embora algumas sejam mais genéricas que outras, o ponto principal abordado é o en-tendimento das informações e apenas a comunicação entre as entidades não é suficiente. As entidades podem estar se comunicando e integradas, porém se não houver entendimento sobre a informação trocada, a interoperabilidade não está ocorrendo. A comunicação en-tre entidades, neste caso, pode ter como escopo a comunicação enen-tre pessoas, sistemas computacionais ou a mistura de ambos (BROWNSWORD et al., 2006).
(CARNEY; ANDERSON; PLACE, 2005) trata o relacionamento entre sistemas como sendo a essência da interoperabilidade. Para um sistema interoperar com outro, um serviço deve ser oferecido e isto não acontece se não houver comunicação entre eles. Os relacionamentos de interoperabilidade envolvem, necessariamente, a comunicação. Uma relação de proxi-midade, no entanto, não implica comunicação e, por conseguinte, interoperação. Fazendo uma analogia ao mundo físico, uma pessoa pode estar próxima de outra e não se comu-nicar, assim como um sistema pode estar na mesma máquina que outro e a comunicação não existir.
A interoperabilidade é uma questão bastante complexa no âmbito dos sistemas de informação e que possui diversas barreiras a serem ultrapassadas para obter o sucesso (Figura 1). (CURRY, 2012) relata três dimensões de barreiras de interoperabilidade a serem vencidas:
Barreiras conceituais. Representam as diferenças sintáticas (formato) e semântica (interpretação e significado) das informações trocadas;
Barreiras tecnológicas. Referem-se à incompatibilidade das tecnologias da infor-mação como protocolos, codificações, plataformas e infraestruturas.
Barreiras organizacionais. Dizem respeito à incompatibilidade das responsabilida-des, autoridades e estruturas organizacionais.
A interoperabilidade pode ser alcançada de duas maneiras (MADNI; SIEVERS, 2014): (i) sistemas podem incluir nativamente questões relacionadas à interoperabilidade em seus projetos; ou (ii) sistemas podem ser adaptados. A primeira opção é mais fácil e menos custosa. Entretanto, considerando que sistemas de cidades inteligentes são siste-mas proprietários e que muitas vezes são gerenciados por organizações distintas, eles são desenvolvidos sem considerar a interoperabilidade em seu projeto.
Por outro lado, enquanto a primeira opção é uma alternativa mais fácil, a segunda opção requer um enorme esforço, uma vez que: (i) afeta muitos aspectos dos sistemas existentes (por exemplo: API externa, interface do usuário, uso de padrões e protocolos
Figura 1: Níveis da Interoperabilidade (CURRY, 2012)
de comunicação); e (ii) envolve a compreensão de uma ampla gama de sistemas, que é uma tarefa difícil para os desenvolvedores. Por se tratar de um ambiente extremamente heterogêneo e dinâmico, mesmo requerendo mais esforço, esta alternativa adaptativa tende a ser a mais adequada ao ambiente de cidades inteligentes.
2.2
Sistemas de Sistemas
SoS podem ser definidos como um conjunto de sistemas constituintes heterogêneos e independentes que interoperam a fim de realizarem uma missão global comum (BILLAUD; DACLIN; CHAPURLAT, 2015) (KAZMAN et al., 2013). Tanto sistemas tradicionais quanto SoS são sistemas que são organizados a fim de prover funcionalidades e satisfazer missões. Embora seja formado por outros sistemas já em operação, um SoS possui um ciclo de vida próprio, ilustrado na Figura 2, que é bastante similar ao ciclo de vida de um sistema tradicional.
Quando há a integração entre os sistemas, o SoS inicia o seu ciclo, começa a operar, sofre evoluções (que podem ser, por exemplo, mudanças no ambiente de execução ou alterações nas missões dele ou dos sistemas constituintes) e, por fim, encerra seu ciclo. O encerramento do ciclo pode ocorrer com ou sem o atendimento à missão global do SoS. Um SoS pode conter vários sistemas constituintes (inclusive outros SoS), que, por sua vez, podem constituir novos SoS. Contudo, SoS distinguem-se de outros sistemas
Figura 2: Ciclo de vida de um SoS
complexos e de larga escala devido a um conjunto de características inerentes a essa classe de sistemas, todas elas sendo necessárias para considerar um dado sistema como de fato um SoS (FIRESMITH, 2010) (MAIER, 1998). São tais características que tornam SoS diferentes dos sistemas tradicionais e, portanto, fazem com que seja necessária uma mudança de paradigma para desenvolvimento desses sistemas.
2.2.1
Características dos Sistemas de Sistemas
Há pouco, foi mencionado que os SoS fazem parte de uma classe específica de sistemas que possuem características bem peculiares. Tais características podem ser vistas a seguir.
Independência operacional dos sistemas constituintes. Sistemas constituintes de um SoS são operacionalmente independentes no sentido de que eles proveem suas próprias funcionalidades e satisfazem suas próprias missões mesmo quando não cooperam com outros sistemas no escopo do SoS.
Independência gerencial dos sistemas constituintes. Sistemas constituintes que participam de um SoS são comumente desenvolvidos por diferentes organizações, com seus próprios stakeholders, equipes de desenvolvimento, processos e recursos, além de apresentarem ciclo de vida próprio e possuírem autonomia para gerenciar seus próprios recursos.
Distribuição geográfica dos sistemas constituintes. Esta característica refere-se à distribuição dos sistemas constituintes, de modo que algum tipo de conectividade precisa ser estabelecida para permitir comunicação e troca entre eles (NIELSEN et al., 2015). Dessa forma, sistemas constituintes estão fisicamente desacoplados e trocam apenas informação entre eles.
Desenvolvimento evolucionário do SoS. Um SoS pode continuamente evoluir como resposta a mudanças, sejam elas relacionadas ao ambiente, aos seus sistemas consti-tuintes ou a suas funções e propósitos. Como consequência de sua independência gerencial,
sistemas constituintes podem evoluir por conta própria e sem o controle do SoS, que deve por sua vez absorver tais mudanças e minimizar possíveis efeitos indesejados.
Comportamentos emergentes no SoS. Em sistemas tradicionais, o comporta-mento e as interações de seus componentes são geralmente previsíveis e controláveis da perspectiva do sistema. Entretanto, mesmo que os sistemas constituintes de um SoS pos-sam ser previsíveis, suas independências operacional e gerencial e as interações locais que ocorrem entre eles fazem com que o comportamento do SoS emerja em tempo de execu-ção. Isso representa uma grande desafio para o desenvolvimento dessa classe de sistemas, uma vez que SoS dependem essencialmente de comportamentos emergentes para satisfazer suas missões e prover novas funcionalidades, que resultam da colaboração entre os siste-mas constituintes e que não podem ser providas por nenhum deles isoladamente (Figura 3).
Figura 3: Funcionalidades oferecidas pelo SoS
De maneira particular, SoIS são SoS cujos sistemas constituintes são, em sua maioria, sistemas de informação pertencentes a diferentes organizações que colaboram para prover novas funcionalidades, tecnologias e oportunidades de negócio. Além das cinco caracterís-ticas típicas de qualquer SoS anteriormente descritas, três caracteríscaracterís-ticas são específicas para SoIS, a saber: (i) a existência de fluxos de informação enre os sistemas constituintes, (ii) uma forte natureza orientada a processo de negócio, e (iii) a criação de informação e valor agregado a partir da interoperabilidade entre sistemas de informação e suas res-pectivas organizações que não é possível obter se seus constituintes operam isoladamente. Nessa perspectiva, pode-se dizer que SoIS ampliam o escopo de SoS no sentido de que atravessam fronteiras organizacionais, envolvendo muitas vezes sistemas de informação constituintes de diferentes domínios e gerando grande quantidade de informação (MAJD; MARIE-HÉLÈNE; ALOK, 2015) (SALEH; ABEL, 2015).
2.2.2
Missões no contexto de Sistemas de Sistemas
As missões de SoS normalmente são vistas como características ou um conjunto de tarefas a serem realizadas pelos sistemas constituintes (SILVA et al., 2014). Tais missões são categorizadas em dois tipos: missões individuais e missões globais. Considerando que, em um SoS, cada sistema constituinte é independente de qualquer outro sistema, as missões individuais referem-se aos recursos ou tarefas executadas por cada sistema constituinte iso-lado. Estas missões estão relacionadas a um sistema constituinte específico. Por sua vez, as missões globais estão relacionadas a novos recursos e/ou funcionalidades alcançados pela integração dos sistemas constituintes de um SoS. As missões globais são dependen-tes de um conjunto de sistemas constituindependen-tes e não é possível realizá-las considerando a contribuição de apenas um único sistema constituinte.
2.2.3
Tipos de Sistemas de Sistemas
Dentro de uma estrutura colaborativa, como é o caso do SoS, onde vários sistemas contribuem, porém mantêm o seu nível de independência funcional e gerencial, alguns tipos de SoS são diferenciados com base na forma que eles se relacionam (CURRY, 2012). Os tipos existentes de SoS são:
SoS Direcionados ou Diretivos. São construídos e gerenciados de forma centrali-zada para atender aos objetivos específicos. Os sistemas constituintes mantêm a capaci-dade de operar de forma independente, mas a forma operacional do SoS é subordinada a um objetivo geral.
SoS Reconhecidos. Possuem objetivos definidos e recursos dedicados. Os objetivos, a gerência e os recursos são reconhecidos por todas as partes envolvidas e o gerenciamento central do SoS é baseada na negociação entre as partes. Os sistemas constituintes mantêm sua propriedade e objetivos independentes. As mudanças nos sistemas são baseadas na colaboração entre o SoS e os sistemas constituintes.
SoS Colaborativos. Os sistemas constituintes interagem voluntariamente para al-cançar a missão global do SoS. Os sistemas decidem coletivamente os meios de cumprirem e manterem os padrões do SoS.
SoS Virtuais. Não há gerenciamento centralizado nem um acordo predefinido. Os comportamentos emergentes do SoS acontecem, porém dependem de mecanismos relati-vamente invisíveis para mantê-lo. Os sistemas participam do SoS sem a ciência que estão
participando.
2.2.4
Desafios da interoperabilidade em Sistemas de Sistemas
Os diferentes tipos de SoS requerem diferentes tipos de interoperabilidade (CURRY, 2012). Em um SoS Diretivo, onde há uma autoridade central de gerenciamento, a interope-rabilidade pode ser realizada com uma abordagem integrada, seguindo um modelo muitos para um. Já no caso do SoS Virtual, onde os sistemas constituintes não têm a ciência de sua participação no SoS e não existe uma autoridade central para gerenciar o ambiente, a abordagem de interoperabilidade utilizada é conhecida como federada, caracterizada pelo modelo muitos para muitos.
A interoperabilidade dentro de um SoS, independente do tipo utilizado, é extrema-mente relevante para o alcance de suas missões e deve ser idealizada desde a sua concepção, seguindo durante todo o ciclo de vida do SoS. O principal desafio encontrado na realização da interoperabilidade dentro de um SoS é simplificá-la sem comprometer a complexidade, hierarquia, controle e custo de aquisição do ambiente.
A preocupação com interoperabilidade precisa estar presente na mente do projetista do SoS. Uma abordagem efetiva de interoperabilidade para o SoS minimizará a comple-xidade inerente a um contexto flexível característico deste tipo de ambiente. Em caso de ferramentas específicas que realizam interoperabilidade em SoS, uma infraestrutura bem configurada deve ser capaz de suportar adições, substituições e remoções de sistemas constituintes dentro do ambiente sem a necessidade de reintegração de algum sistema par-ticipante. No entanto, encontrar a interoperabilidade adequada para SoS tem sido ainda um grande desafio para a comunidade de Engenharia de Software(NAKAGAWA et al., 2015).
2.3
Processos de Negócio
Missões em SoS (mais especificamente em SoIS), sejam elas individuais ou globais, podem possuir um processo de negócio associado como uma sequência de atividades inter-dependentes a serem realizadas por capabilidades específicas dos sistemas de informação constituintes, além de envolver os fluxos de informação que ocorrem entre tais sistemas (NETO et al., 2017). Apesar de ainda não haver uma notação específica para modelagem de missões em SoIS, é possível utilizar BPMN2 para complementar a especificação de missões
desse tipo de sistema, permitindo uma melhor compreensão da sua natureza orientada a negócio em termos de atividades e os relacionamentos entre elas (WESKE, 2012).
O BPMN pode representar os processos de negócio, sendo definido como uma notação de modelagem especialmente voltada para a especificação, em alto nível, da análise do domínio na forma de um processo de negócio (OMG, 2011). O principal objetivo do BPMN é dar suporte ao gerenciamento de processos de negócio, fornecendo uma notação intuitiva capaz de representar a semântica complexa do processo como um todo e facilitando o entendimento de todas as partes interessadas no negócio.
A modelagem do processo representa uma abstração do caminho do que se pretende percorrer para a realização das atividades, fazendo com que todos os envolvidos tenham a mesma visão geral. A ideia é distinguir todos os processos realizados, bem como os participantes que a executam, recursos utilizados e produzidos e informações relacionadas. No caso específico do SoIS, cuja orientação do fluxo é orientada pelo processo de negócio, uma representação deste tipo faz com que se consiga visualizar a sequência correta e a responsabilidade de cada sistema dentro do processo.
Para modelar um processo de negócio, BPMN define uma Diagrama de Processos de Negócio (BPD3) que utiliza um conjunto de elementos gráficos divididos em quatro categorias (SHAPIRO et al., 2010):
1. Objetos de fluxo - são elementos principais do BPMN e podem ser eventos, ati-vidades ou gateways de convergência/divergência de atiati-vidades;
2. Objetos de conexão - servem para conectar os objetos de fluxo em termos de sequências, mensagens ou associações;
3. Raias (swimlanes) - organizam visualmente as atividades em diferentes categorias ou responsabilidades; e,
4. Artefatos - agregam informações adicionais aobre o processo e podem ser objetos de dados, grupos de elementos ou anotações (descrições ou comentários).
A padronização do BPMN pela OMG (Object Management Group) em 2011, levando ao chamado BPMN 2.0, trouxe como maior mudança a serialização de BPD, permitindo a tradução dos elementos gráficos especificados em BPMN em esquemas no formato XML. Com esse XML gerado, é possível utilizar o BPMN como um orquestrador durante a execução de um sistema qualquer.
Figura 4: Fluxo da missão global Gerar Rotas Otimizadas
A Figura 4 ilustra um BPD referente à missão global Gerar Rotas Otimizadas, em que cada uma das raias representa um executor do passo da missão. Neste caso específico, o início (representado pelo Start Event ) e o final do fluxo (representado pelo End Event ) são executados pelo Serviço Web relativo ao SoS. As demais raias são representadas por sistemas constituintes do SoS e a execução segue a sequência definida pelos objetos de conexão (ilustrado pelas setas) até que se encontre o (End Event ), que representa o final do fluxo de execução.
O XML (Figura 5) gerado pelo BPMN e ilustrado pelo BPD (Figura 4) contém algu-mas tags de identificação de execução do fluxo. A tag lane, visualizada nas linhas 6,9,12 e 15, por exemplo, representa a raia e serve para identificar o responsável pelo passo de execução da tarefa. O parâmetro name difere cada lane existente no fluxo e ajuda a dar uma melhor visualização de todo o processo. A tarefa do fluxo a ser executada é identificada pela tag scriptTask. Após ser referenciada pela tag flowNodeRef, dentro de alguma lane, conforme exemplificado na linha 10, o detalhamento de ligação dessa tarefa com as demais do fluxo envolve as tags incoming e outgoing, que representam, respectiva-mente, a entrada e a saída daquela tarefa. A linha 25 informa que a entrada para a tarefa ScriptTask_1, nominada neste exemplo de "Solicita Containers Criticos", é representada pelo elemento SequenceFlow_9. A sua saída, identificada pela tag outgoing na linha 26 do XML, é representada pelo elemento SequenceFlow_10. O elemento SequenceFlow_10 já é identificado como entrada da tarefa ScriptTask_2, cuja tag incoming comprova na linha 31. O fluxo desta forma vai sendo traduzido da parte gráfica e sendo apresentado em formato XML.
Figura 5: Exemplo do código XML gerado pelo BPMN
2.4
Agentes de software
A necessidade de maior interoperabilidade entre os grandes sistemas e organizações vem, ao longo dos anos, exigindo da área da Engenharia de Software um maior esforço para conseguir fornecer alternativas para o desenvolvimento de software, que estão se tornando cada vez mais extensos e complexos. (PARSONS; WOOLDRIDGE, 2002) relatam que muitas pesquisas buscam novos paradigmas para aumentar a habilidade de modelar, projetar e construir complexos sistemas de informação de natureza distribuída.
Vários paradigmas têm sido utilizados pela Engenharia de Software para atingir o propósito de facilitação no desenvolvimento e gerenciamento dos sistemas de informação como programação estruturada, declarativa, orientada a objetos, orientada a componentes, etc. Um paradigma, no entanto, que vem atraindo a atenção da indústria de software e que, devido a suas características, tem um grande potencial para o desenvolvimento de
sistemas complexos e distribuídos, é o paradigma de programação orientada a agentes.
A programação orientada a agentes é caracterizada pelo uso dos agentes de software, que são sistemas computacionais capazes de ações flexíveis e autônomas em um ambiente dinâmico, aberto e imprevisível (JENNINGS; BUSSMANN, 2003). (JENNINGS et al., 2001) informa que o uso da abordagem orientada a agentes surgiu na comunidade de inteligência artificial e é baseada nos argumentos de que: (i) o aparato conceitual de sistemas orientados a agentes é adequado para construir soluções de software para sistemas complexos, e (ii) as abordagens orientadas a agentes representam um verdadeiro avanço sobre o estado da arte na engenharia de sistemas complexos.
Cabe frisar, no entanto, que a autonomia é um conceito difícil de identificar com precisão, mas o sentido proposto recai sobre a capacidade que o sistema tem de atuar sem a intervenção de humanos (ou outros agentes) e deve ter controle sobre suas próprias ações e estado interno (JENNINGS et al., 2001).
Segundo (JENNINGS et al., 2001), as técnicas orientadas a agentes são adequadas para desenvolver sistemas complexos de software porque:
• as decomposições orientadas a agentes são efetivas quando repartem o espaço do problema em um sistema complexo;
• as abstrações principais presentes no modo de pensar orientado a agentes são um meio natural de modelar sistemas complexos; e
• a filosofia para identificar e gerenciar relacionamentos organizacionais é apropriada para lidar com as dependências e interações que existem em um sistema complexo.
Um outra definição sobre agentes é que eles podem ser entidades solucionadoras de problemas que interagem entre si para resolverem problemas que estão além das capa-cidades ou conhecimento de cada entidade em particular (SYCARA et al., 1996). É uma entidade de software autônoma que tem capacidades de atuação, interagindo com seu ambiente e adaptando seu estado e comportamento com base nesta interação (COLOMB et al., 2006). Este ambiente de interação pode ser constituído de máquinas, de humanos, e de outros agentes de software em vários ambientes e através de várias plataformas ( CO-LOMB et al., 2006). Uma rede fracamente acoplada destas entidades é chamada de sistema multiagente.
Os agentes de software possuem características (resumidas na Tabela 1) bem definidas que os tornam uma classe bem diferenciada no âmbito da Engenharia de Software. O
fun-Tabela 1: Características de agentes de software Característica Definição
Autonomia Capacidade de atuar sem a intervenção direta de seres humanos ou outros agentes, tendo controle sobre suas próprias ações e seu estado de forma não supervisionada
Comunicação Capacidade de trocar informações acerca de seus recursos, seu co-nhecimento e suas decisões com outras entidades, com o ambiente onde executa e com seres humanos
Cooperação e habilidade social
Capacidade de trabalhar em conjunto com outros agentes em busca de um objetivo comum
Inteligência Capacidade computacional ou analítica que um agente possui para analisar seu ambiente e resolver problemas
Aprendizado Capacidade de aprender através de um conjunto de instruções ou continuamente por experiência, com base no resultado das decisões tomadas de forma autônoma a partir da percepção do ambiente Reatividade Capacidade de perceber mudanças no ambiente e responder a tais
mudanças
Proatividade Capacidade de iniciativa para realizar o objetivo atribuído ao agente em vez de simplesmente reagir a mudanças no ambiente Mobilidade Capacidade de movimentação entre ambientes de execução
cionamento do agente de software baseia-se, em especial, na troca de mensagens síncronas ou assíncronas com outros agentes do ambiente local ou externo, utilizando para isso lin-guagem específica e padronizada. Ao identificar alterações no ambiente ou mensagens que merecem algum tipo de tratamento, o agente tem autonomia para executar ações.
O simples fato de ser autônomo não faz do agente uma entidade inteligente. ( HAYES-ROTH, 1995) classifica agentes inteligentes como aqueles que percebem a condição dinâ-mica de seu ambiente, tomam atitudes para modificar condições no seu ambiente, racio-cinam para interpretar percepções, resolvem problemas, traçam inferências e determinam ações. Para o agente ser inteligente, segundo (WOOLDRIDGE; JENNINGS, 1995), além da autonomia, percepção e reatividade, deve ser possível a inclusão da proatividade, carac-terizada por decisões próprias de sua iniciativa e não apenas em relação a uma resposta ao ambiente.
Segundo (JENNINGS et al., 2001), a proatividade de um agente é uma característica que requer que os agentes não devam simplesmente agir em resposta ao seu meio ambiente, eles devem ser capazes de exibir comportamentos oportunistas e dirigidos a objetivos, tomando a iniciativa quando apropriado. Já a reatividade dos agentes deve fazê-los capaz de perceber seu ambiente (que pode ser o mundo físico, um usuário, uma coleção de
agentes, a Internet, etc.) e responder em tempo hábil às mudanças que ocorrem nele.
O comportamento proativo, desta forma, é principalmente adequado a ambientes que não ofereçam muito dinamismo, onde condições sejam alteradas enquanto o agente está tomando decisões, uma vez que podem resultar em situações indesejadas. É mais prudente que este comportamento seja utilizado em ambientes que a mudança de estado do agente seja de conhecimento prévio e informações sobre o ambiente de execução sejam mais claras.
2.4.1
Arquitetura dos agentes
A arquitetura de um agente pode ser utilizada como critério para classificar o agente. Ela se baseia no tipo de comportamento adequado (reativo ou proativo) e especifica o pro-cesso de deliberação e a escolha da ação a ser tomada, de acordo com as percepções obtidas (WOOLDRIDGE; JENNINGS, 1995). Segundo (RUSSELL; NORVIG, 2003), quatro arquiteturas relacionadas a agentes inteligentes merecem destaques: agentes reativos simples, agentes reativos baseados em conhecimento, agentes baseados em objetivo e agentes baseados em utilidade.
2.4.1.1 Agente reativo simples
A base deste sistema para a tomada de decisão é do tipo condição-ação. É o tipo mais simples de agente e a sua principal característica é a reatividade. Não há histórico armazenado de ações e a atuação é efetuada com base na leitura do sensor. Ao rece-ber a informação do ambiente, o mapeamento condição-ação é verificado e a atuação é executada.
2.4.1.2 Agente reativo baseado em conhecimento
O conhecimento adquirido por este agente refere-se ao estado do ambiente em que se encontra. Diferente do agente reativo simples, esse agente avalia o estado interno mantido a respeito de seu ambiente para tomar a decisão. Um agente reativo baseado em conhe-cimento é mais adequado em situações onde ele mantém uma representação interna do ambiente que ele não consegue observar. Os agentes reativos simples são, por sua vez, mais específicos para ambientes que exigem respostas rápidas (RUSSELL; NORVIG, 2003).
2.4.1.3 Agente baseado em objetivo
Essa modalidade de arquitetura de agente baseia-se no planejamento. Segundo ( RUS-SELL; NORVIG, 2003), o planejamento deve encontrar sequências de ações que alcançam os objetivos do agente. O agente, em função do estado atual do ambiente, define que ações deverá tomar para alcançar o seu objetivo. Dois pontos devem ser observados nesta situ-ação: (i) como está o ambiente atualmente e (ii) como ficará o ambiente após a execução do agente.
É importante relatar que o ambiente não deve sofrer modificações após o planejamento das ações, sob pena da sequência de ações trazer resultados indesejados.
2.4.1.4 Agente baseado em utilidade
Quando há mais de um caminho a ser percorrido para alcançar um determinado obje-tivo, decisões equivocadas podem ser tomadas pelos agentes. Segundo (RUSSELL; NORVIG, 2003), o processo para resolução deste conflito é composto por quatro fases:(i) identificar como o ambiente está atualmente; (ii) qual evolução acontecerá com o ambiente caso uma ação seja tomada; (iii) qual a utilidade de determinada ação no atual estado do ambiente; e (iv) que ação o agente pode executar no momento.
Nesta arquitetura, a estrutura é bem mais complexa, não sendo utilizadas regras de mapeamento condição-ação e o uso de conceitos de inteligência artificial são bem mais apurados.
2.4.2
Interação entre agentes
Considerada uma das características mais importantes do paradigma de programação orientada a agentes (NWANA, 1996), a forma de interação entre estes, envolvendo a sua comunicação e troca de mensagens, é ponto fundamental para prover interoperabilidade entre os diversos agentes envolvidos no ambiente.
(LIN et al., 2000) menciona que há três elementos principais para que uma interação multiagente ocorra com sucesso:
• linguagem e protocolo de comunicação padronizado;
• formato comum para o conteúdo de comunicação; e
2.4.2.1 Linguagens de comunicação de agentes - ACL
A comunicação entre agentes é a troca voluntária de informações causada pela detec-ção e produdetec-ção de sinais por parte dos agentes. Em um ambiente multiagente, essa troca de informações serve como base para coordenar as ações e possibilitar a cooperação.
De forma análoga ao que acontece entre as pessoas, no mundo real, para que a comu-nicação ocorra entre os agentes, uma linguagem precisa ser definida para que o emissor e o receptor estabeleçam contato. Tal linguagem, no escopo do paradigma de programação orientada a agentes, é conhecida como linguagem de comunicação de agentes (ACL, do inglês Agent Communication Language).
Segundo (COLOMB et al., 2006), através de uma especificação ACL, os elementos bá-sicos de interação entre os agentes são efetivamente codificados. A ACL somente permite comunicação entre os próprios agentes.
2.4.2.2 Mecanismo de transporte de mensagem
Com a forma de comunicação estabelecida entre os agentes, há a necessidade que exista uma estrutura que suporte a criação e forneça a eles identificadores únicos no ambiente. Os AID (do termo em inglês Agent Identifier ) são os endereços dos agentes e a sua publicação, necessária para que todos os demais agentes tenham conhecimento da sua existência, é realizada em um serviço conhecido como páginas amarelas.
As mensagens podem ser configuradas para serem enviadas de modo síncrono ou assíncrono, dentro de um mecanismo de transporte que deve suportar formas de endere-çamentos de diversos modos (unicast, multicast e broadcast ) (COLOMB et al., 2006).
2.4.2.3 Ontologia
É possível que mesmo com uma troca de informações consolidada entre os agentes, as mensagens recebidas não estejam sendo interpretadas da forma correta. Isto pode ser comum de ocorrer em agentes que realizam comunicação com agentes de outro ambiente onde o vocabulário não está bem definido causando ruídos na conversa entre eles. Isso é similar quando há uma conversa entre pessoas e uma dessas pessoas usa termos que você não compreende o significado, embora a linguagem utilizada seja de conhecimento de ambos. A ontologia procura, através de um vocabulário com termos próprios para um domínio específico, uniformizar o entendimento entre os participantes.
2.4.3
Características dos domínios de aplicações de agentes
As características básicas e alguns detalhes arquiteturais dos agentes foram vistos e o questionamento de quão os agentes de software podem ser úteis e em que área eles podem ser aplicados talvez ainda persista. (JENNINGS et al., 2001) considera que para uma tecnologia ser considerada útil ela deve oferecer duas coisas:
• a capacidade de resolver problemas que nenhuma tecnologia existente poderia re-solver; e
• a capacidade de resolver problemas que já podem ser resolvidos por uma tecnologia existente, porém de uma forma bem melhor.
Certos tipos de sistemas de informação são mais difíceis de projetar corretamente e implementar que outros (JENNINGS et al., 2001). Os mais simples são os funcionais, cuja característica recai sobre uma entrada, o processamento e o resultado. Sistemas reativos, onde há interações com algum ambiente são inerentemente mais difíceis de conceber.
Considerando apenas os sistemas reativos, cuja complexidade é mais abrangente, estes sistemas podem ser divididos em três classes (JENNINGS et al., 2001):
• sistemas abertos;
• sistemas complexos; e
• sistemas ubíquos.
(JENNINGS et al., 2001) (GENESERETH; KETCHPEL, 1994) relatam ainda que o uso de agentes pode ser interessante para realizar a interoperabilidade entre sistemas lega-dos, onde estes necessitam de atualizações periódicas para acompanhar as necessidades dos negócios e a reescrita do sistema seja proibitiva, ou por ser caro ou por ser demo-rado. O processo de transformação de um software em um agente pode ser chamado de agentificação (SHOHAM, 1993).
2.4.3.1 Sistemas abertos
Um sistema aberto é aquele em que a estrutura do próprio sistema é capaz de trabalhar dinamicamente. As características desse sistema são a alta heterogeneidade, a mudança ao longo do tempo e desconhecimento dos seus componentes de forma antecipada. A Internet
é um bom exemplo de um sistema aberto. Qualquer sistema de informação operando na Internet deve saber lidar com essas adversidades e essa funcionalidade certamente requi-sitará técnicas baseadas na negociação e na cooperação, que estão estabilizados dentro do domínio de sistemas multiagentes (GASSER, 1988).
2.4.3.2 Sistemas complexos
Os agentes são poderosas ferramentas para modularizarem sistemas. A modularização e a abstração são importantes técnicas para minimizar a complexidade no desenvolvimento de sistemas. Desta forma, se o domínio de um problema é complexo, extenso e indefinido, o uso de agentes de software pode ser utilizado para modularizar componentes e solucionar aspectos do desenvolvimento (JENNINGS et al., 2001).
2.4.3.3 Sistemas ubíquos
Embora o avanço da tecnologia seja avassalador e as pessoas tenham um contato cada vez mais frequente com mídias digitais, uma boa parte das pessoas ainda hoje sente dificuldades em interagir com o computador. Talvez uma razão para isso seja a falta de autonomia da máquina em resolver os problemas que o usuário necessita.(NEGROPONTE, 2000) já acreditava que o futuro da computação seria 100% conduzido pela delegação das tarefas às máquinas ao invés de manipulá-las. Desta forma, para conseguir entregar essa funcionalidade, os sistemas devem ser autônomos, proativos, reativos e adaptativos (JENNINGS et al., 2001). Estas características, no entanto, casam perfeitamente com as características de agentes de software, evidenciando a importância deste paradigma para a área de desenvolvimento de sistemas ubíquos.
2.4.4
FIPA
O paradigma de desenvolvimento de software orientado a agentes possui uma estreita relação com soluções de interoperabilidade entre sistemas heterogêneos. A facilidade en-contrada na forma de comunicação entre organizações distintas faz desse paradigma uma poderosa ferramenta para a área de Engenharia de Software. Contudo, para que a inte-roperabilidade ocorra, algum nível de padrão precisa existir. Se cada plataforma que se propõe a gerenciar agentes construir seu próprio protocolo de comunicação e estrutura de agentes, haverá diversas plataformas espalhadas e elas não conseguirão se comunicar. Desta forma, faz sentido existir uma entidade que defina as diretrizes que tais plataformas
precisem seguir.
A FIPA é uma organização internacional destinada a definir um modelo de referência para uma plataforma de agentes e um conjunto de serviços que devem ser fornecidos ao se conceber sistemas multiagentes interoperáveis. Foi fundada em 1996 e é constituída por empresas e universidades. A especificação de sua arquitetura abstrata tem o propósito de promover interoperabilidade e reusabilidade através de elementos da arquitetura que devem ser codificados.
A FIPA4 define a referência que deve ser seguida pelas plataformas que desejarem gerenciar agentes e se baseia na adoção de três agentes especiais, que são responsáveis pelo gerenciamento da plataforma (AMS, do termo em inglês Agent Management System), pela divulgação dos agentes ativos (DF, do termo em inglês Directory Facilitator ) e pela comunicação (ACC, do termo em inglês Agent Communication Channel ).
2.4.5
JADE
No contexto de sistemas baseados em agentes, o JADE5 é um framework destinado à criação e gerenciamento do ciclo de vida de agentes, implementado na linguagem Java, e que segue as especificações definidas pela FIPA (Figura 6). O framework inclui:
• um ambiente de execução, onde os agentes JADE podem ser criados e se mantém ativos;
• uma biblioteca de classes (API) que programadores pode utilizar para desenvolver seus agentes;e
• um conjunto de ferramentas gráficas que permitem administrar e monitorar as ati-vidades dos agentes em execução.
O JADE é um sistema completamente distribuído onde habitam agentes, que se co-municam através de mensagens, geralmente assíncronas. Cada agente possui um nome globalmente único dentro da plataforma, definido pela FIPA como AID, que o JADE constrói concatenando um apelido definido pelo próprio usuário ao nome da plataforma.
Os agentes encontram-se em ambientes conhecidos como contêiner ou host, que abriga vários agentes e representa, geralmente, um local de execução dentro do ambiente distri-buído. O conjunto de todos os hosts é chamado de plataforma e forma uma camada única
4Foundation for Intelligent Phisical Agents (www.fipa.org) 5Java Agent Development Framework (jade.tilab.com)
Figura 6: Arquitetura do JADE com base no modelo de referência definido pela FIPA (JADE, 2015)
que abstrai toda a complexidade e heterogeneidade das entidades subjacentes como hard-ware, sistema operacional, tipos de rede, JVM6, etc. A mobilidade de estados de execução é permitida pelo JADE e um agente pode interromper uma execução em um host e migrar para outro host para realizar a sua execução neste ponto remoto.
As mensagens trocadas entre os agentes dentro do JADE baseiam-se na linguagem ACL, também especificada pela FIPA, e contém campos alguns parâmetros que podem servir como formas de enriquecimento da mensagem enviada.
Os módulos gráficos são um grande diferencial dessa ferramenta e podem servir como um grande auxílio para facilitar o gerenciamento e acompanhamento das mensagens tro-cadas entre os agentes dentro da plataforma, como também simular requisições, criar e finalizar agentes, mover os agentes entre os contêineres, entre outras diversas funcionali-dades e facilifuncionali-dades.
2.5
Cidades Inteligentes
A ONU7 estima que a população mundial ultrapasse os 9 bilhões de habitantes em 40
anos e que no ano de 2050, cerca de 65% da população viva em cidades. Em contrapartida,
6Java Virtual Machine
os recursos existentes nas cidades para atender a essa população tendem a não crescer ou, se crescerem, o farão em um ritmo muito menor que o populacional. Isto implica problemas sérios como falta de água, redução da qualidade de prestação de serviços oferecidos à população, engarrafamentos, poluição do ar, entre outros graves problemas, resultando em uma queda brusca na qualidade de vida das pessoas e comprometendo de forma assustadora o desenvolvimento sustentável de uma cidade.
Diante destes aspectos críticos e desafiadores, a solução recai em identificar uma forma de otimização do uso dos recursos e infraestrutura existentes na cidade, de forma susten-tável, e com vistas a melhorar a qualidade de vida da população. Nesta perspectiva, a TIC (Figura 7) insere-se como viabilizador de um sistema que pode prover maior inteligência na gestão de cidades (NAM; PARDO, 2011), em várias áreas. Este elemento estratégico para o planejamento e gestão inteligente de cidades ajuda a concretizar o conceito de cidades inteligentes.
2.5.1
Definições
De acordo com (KANTER; LITOW, 2009), as cidades inteligentes são aquelas capazes de conectar de forma inovadora, eficiente e eficaz, as infraestruturas físicas e de TIC, convergindo os aspectos organizacionais, normativos, sociais e tecnológicos, a fim de me-lhorar as condições de sustentabilidade e de qualidade de vida da população. Outros autores afirmam que as cidades inteligentes são aquelas que reconhecem a importância das TIC e as aplicam para alavancar competitividade econômica, promover suporte às ações de gestão ambiental e proporcionar melhoria da qualidade de vida dos cidadãos (HERNÁNDEZ-MUÑOZ et al., 2011) (ALDAMA-NALDA et al., 2012).
Embora reconheça que a TIC esteja, obrigatoriamente, presente em cidades inteligen-tes, (NAM; PARDO, 2011) citam que o simples fato de ter componentes digitais não dá "inteligência"a uma cidade. As cidades inteligentes são aquelas que têm por objetivo a melhoria na qualidade de vida dos cidadãos e no serviço prestado pelo governo. Surge, dessa forma, a necessidade de distinção entre dois conceitos importantes: (i) a cidade digi-tal é caracterizada primordialmente pela capacidade de implementação de tecnologias de comunicação, promovendo o acesso amplo a ferramentas, conteúdos e sistemas de gestão, de forma a atender às necessidades do poder público e seus servidores, dos cidadãos e das organizações; e, (ii) a cidade inteligente, por sua vez, emerge da cidade digital. A visão de inteligência das cidades vem da convergência entre a sociedade do conhecimento - onde a informação e a criatividade têm grande ênfase e que considera os capitais humano e social
Figura 7: Características de uma cidade inteligente
como seus mais valiosos ativos (CARDOSO; CASTELLS, 2006) - e a cidade digital - que faz extensivo uso de sistemas de telecomunicações e recursos da Internet como meio para transformar significativamente as formas de relacionamento e de vida (KANTER; LITOW, 2009)(NAM; PARDO, 2011).
A conceitualização de cidades inteligentes, talvez pelos diversos aspectos associados, não pode ser considerada uma unanimidade. (GIFFINGER; GUDRUN, 2010), por exemplo, é um dos autores que não deixa claro o uso da TIC como meio de alcance de qualidade de vida e como forma de melhoria da gestão governamental em uma cidade inteligente. Ele é lacônico sobre o uso de TIC, porém trata de cidade inteligente de uma forma bem interessante. A definição de uma cidade inteligente para (GIFFINGER; GUDRUN, 2010) está associada a uma forma de medição a partir do relacionamento entre o governo e os ci-dadãos e a utilização de modernas tecnologias, não necessariamente TIC, mas também relativas a outros domínios, como transporte e logística. A análise ocorre com base em desempenhos observados em seis áreas ou domínios: economia, pessoas, governança, mo-bilidade, meio-ambiente e qualidade de vida. Em outras palavras, uma cidade pode ser ou estar inteligente na área de economia, por exemplo, e ainda apresentar problemas no aspecto de gerenciamento de trânsito.
Há de se convir, realmente, que cada cidade possui suas próprias características. Uma cidade que possui milhões de habitantes tende a sofrer mais com o trânsito do que uma cidade menos populosa. De forma análoga, dependendo do investimento, o nível de gover-nança nas metrópoles pode ser mais elevado que cidades que não têm muitos processos a
