mandala - interoperabilidade baseada em sistemas de ... · mandala - interoperabilidade baseada em...
TRANSCRIPT
Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra
Departamento de Informática e Matemática AplicadaPrograma de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Mandala - Interoperabilidade baseada emSistemas de Sistemas no âmbito de Cidades
Inteligentes
Altair Brandão Mendes
Natal-RN
Fevereiro de 2018
Altair Brandão Mendes
Mandala - Interoperabilidade baseada em Sistemas deSistemas no âmbito de Cidades Inteligentes
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre 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çãoDIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da TerraUFRN – Universidade Federal do Rio Grande do Norte
Natal-RN
Fevereiro de 2018
Mendes, Altair Brandão. Mandala - interoperabilidade baseada em sistemas de sistemasno âmbito de cidades inteligentes / Altair Brandão Mendes. -2018. 87 f.: il.
Dissertação (mestrado) - Universidade Federal do Rio Grandedo 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, FredericoAraújo da Silva. III. Título.
RN/UF/CCET CDU 004.41
Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Elaborado por Joseneide Ferreira Dantas - CRB-15/324
À minha família pela paciência, incentivo e incondicional apoio durante todos os
momentos da minha vida.
Agradecimentos
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
grande abraço!
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.
Quanto mais aumenta nosso conhecimento, mais evidente fica nossa ignorância.
John F. Kennedy
Mandala - Interoperabilidade baseada em Sistemas deSistemas 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.
Mandala - SoS-based interoperability in smart cities
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.
Keywords : Interoperability, Middleware, System of Systems, Smart Cities.
Lista de figuras
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
19 Troca de Mensagens entre os Agentes . . . . . . . . . . . . . . . . . . p. 58
20 Estrutura de Armazenamento do Repositório Geral . . . . . . . . . . . p. 59
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
fluxo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
Lista de tabelas
1 Características de agentes de software . . . . . . . . . . . . . . . . . . . p. 34
2 Coisas conectadas no ambiente de CI (em milhões). Fonte: Gartner . . p. 45
Lista de abreviaturas e siglas
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
IoT - Internet das Coisas
Sumário
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.1 Linguagens de comunicação de agentes - ACL . . . . . p. 37
2.4.2.2 Mecanismo de transporte de mensagem . . . . . . . . . p. 37
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 Avaliação p. 67
4.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
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
17
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
18
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 tornem1Application Programming Interface
19
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 sistemas 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
20
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-
21
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 complexidade 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 harmonia3Nesta dissertação será utilizada, muitas vezes, SoS como sinônimo de SoIS
22
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 Implementaçã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.
23
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 anteriormente1IEEE - www.ieee.org
24
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 entre 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
25
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
26
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,
27
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ísticas 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).
28
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 constituintes 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
29
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ões2BPMN - Business Process Model and Notation
30
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 atividades;
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.3BPD - Business Process Diagram
31
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.
32
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
33
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-
34
Tabela 1: Características de agentes de software
Característica Definição
Autonomia Capacidade de atuar sem a intervenção direta de seres humanosou outros agentes, tendo controle sobre suas próprias ações e seuestado 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 ambienteonde executa e com seres humanos
Cooperaçãoe habilidadesocial
Capacidade de trabalhar em conjunto com outros agentes embusca de um objetivo comum
Inteligência Capacidade computacional ou analítica que um agente possui paraanalisar seu ambiente e resolver problemas
Aprendizado Capacidade de aprender através de um conjunto de instruções oucontinuamente por experiência, com base no resultado das decisõestomadas de forma autônoma a partir da percepção do ambiente
Reatividade Capacidade de perceber mudanças no ambiente e responder a taismudanças
Proatividade Capacidade de iniciativa para realizar o objetivo atribuído aoagente 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
35
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).
36
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
• ontologia compartilhada.
37
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 produçã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.
38
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
39
é 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
40
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 única4Foundation for Intelligent Phisical Agents (www.fipa.org)5Java Agent Development Framework (jade.tilab.com)
41
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, JVM 6, 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 facilidades.
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 Machine7ONU - Organização das Nações Unidas
42
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
43
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
44
serem executados.
Desta forma, seguindo a mesma linha de (GIFFINGER; GUDRUN, 2010), com a notável
diferença da obrigatoriedade da análise do uso de TIC, (GAMA; ALVARO; PEIXOTO, 2012)
propõem um modelo de maturidade tecnológica para graduar as cidades com base na in-
tegração de dispositivos (conceituais e físicos) variados. São cinco os níveis de maturidade
definidos por (GAMA; ALVARO; PEIXOTO, 2012):
0 - Caótico: fase onde a maioria das cidades inicia. Nesta fase, as cidades não utilizam
TIC para auxiliar no gerenciamento. Os habitantes podem utilizar redes sociais, mas não
há uso de sistemas voltados à melhoria das condições de vida ou serviços.
1 - Inicial: fase de planejamento e modelagem de sistemas de informação que irão
auxiliar em determinado domínio, assim como a identificação de sistemas existentes que
potencialmente podem ser integrados à solução da cidade inteligente. Pode haver captura
de dados de sensores.
2 - Gerenciado: dados coletados (dados de tráfego, consumo de energia, etc.) e
acessíveis através de sistemas de informação.
3 - Integrado: cidade inteligente com sistemas integrados, podendo utilizar o modelo
de computação em nuvem (Cloud Computing), estando disponíveis na forma de serviços
tanto para cidadãos como para aplicações de terceiros. Uso intensivo da computação
ubíqua e autonômica. O governo pode funcionar como facilitador da cidade inteligente e
fomentador de um ecossistema de serviços.
4 - Otimizado: cidade eficiente, buscando inovar e ser pioneira nas soluções de TIC.
Apoio à tomada de decisões utilizando os dados obtidos dos diversos domínios da cidade.
Suporte à tomada de decisão tanto para a população quanto para os governantes.
(GAMA; ALVARO; PEIXOTO, 2012) ainda alerta para o fato que o nível de maturidade
tecnológica no processo de otimização de cidades pode ser avaliado por domínio (gover-
nança, saúde, transporte, etc.). É importante que a cidade tenha conhecimento de todos
os domínios e respectivos critérios visando planejar a inserção de TIC da melhor forma
possível.
Se for feito um exercício mesclando definições, pode-se dizer, pelas assertivas de
(GAMA; ALVARO; PEIXOTO, 2012) e (NAM; PARDO, 2011), que os níveis 0,1 e 2 do modelo
de maturidade ainda estão relacionados a uma cidade digital, ao ponto que os níveis 3 e
4, pela definição de (NAM; PARDO, 2011), já caracterizam uma cidade como inteligente.
45
Tabela 2: Coisas conectadas no ambiente de CI (em milhões). Fonte: GartnerSubcategoria da cidade inteligente 2015 2016 2017 2018Médico 3,4 5,3 8,4 13,4Serviços públicos 78,6 103,6 133,1 167,4Construções comerciais inteligentes 377,3 518,1 733,7 1064,8Casas inteligentes 174,3 339,1 621,8 1073,7Transporte 276,9 347,5 429,2 517,4Utilidades públicas 260,6 314,0 380,6 463,5Outros 8,6 13,3 20,8 32,3TOTAL 1179,7 1641,0 2327,7 3332,5
Diante das definições, mesmo existindo algumas omissões sobre o uso da TIC em
cidades inteligentes, é perceptível que o alcance de um nível elevado de qualidade de vida,
governança e desenvolvimento sustentável não é fácil de ser executado sem a ajuda de um
elemento importantíssimo como a TIC.
2.5.2 TIC em cidades inteligentes
De uma forma geral, uma cidade inteligente usa a TIC para realçar a qualidade e o
desempenho dos serviços urbanos, reduzir custos e o consumo de recursos e se envolver
mais efetiva e ativamente com os cidadãos(TEKINERDOGAN; ERATA, 2017).
A TIC pode estar presente de várias formas neste tipo de ambiente. Por exemplo,
com o barateamento dos equipamentos e disseminação da tecnologia de sensores, o uso
da conhecida Internet das Coisas (IoT, do inglês Internet of Things) tem ajudado a
produzir diversas aplicações e soluções interessantes em cidades inteligentes. De forma
complementar, a utilização de Computação em Nuvem (Cloud Computing) e Big Data,
para prover infraestrutura para as aplicações desenvolvidas e gerenciamento dos dados
para tomada de decisões, respectivamente, são de extrema importância para impulsionar
esta área, que já se mostra bastante promissora.
O Gartner8 já estimava que 2,3 bilhões de coisas conectadas seriam usadas pelas cida-
des inteligentes em 2017. Um aumento de aproximadamente 42% em relação a 2016. Neste
ano, a estimativa é de mais de 3,3 bilhões de coisas conectadas, conforme apresentado na
Tabela 2.
Graças aos dados coletados de sensores, cidades inteligentes podem interagir e se
envolver com cidadãos e empresas, criando um ambiente colaborativo. Segundo o Gartner,
em Cingapura, por exemplo, os sensores em paradas de ônibus podem identificar pessoas8Gartner Group - www.gartner.com
46
com necessidades diferentes. Os ônibus são anunciados antecipadamente para permitir
que as pessoas idosas tenham tempo suficiente para se prepararem para embarcar. Em
algumas cidades da Espanha, as bicicletas ou carrinhos destinados à entrega de cartas
possuem sensores ambientais que registram a poluição do ar, com os dados carregados
em um portal da Web acessível ao público. As empresas, por sua vez, tornam-se mais
capacitadas para utilizar os dados do sensor para criar proposta de valor. A Gartner
ainda acrescenta que os cidadãos podem contribuir ativamente para o desenvolvimento
estratégico de sua cidade. Na verdade, nos dias atuais, as pessoas podem consumir ou
prover dados, com os seus smartphones, fazendo papel de sensores enquanto provedoras
de dados (crowdsensing).
Em pesquisas recentes, o Gartner também apresenta que a tendência para aplicações
e soluções de cidades inteligentes passa pela inovação, aumento da prestação de serviços e
criatividade. Os dados inteligentes devem ser integrados com soluções de software contendo
múltiplas funcionalidades, mobilidade e colaboração. O cruzamento de serviços, que já se
identificava como uma linha de soluções para cidades inteligentes, se torna ainda mais
expressiva com essa tendência colaborativa relatada pelo Gartner, o que reforça a iniciativa
de ambientes que realizem a integração de sistemas já existentes para proverem mais
funcionalidades. Na verdade, não se pode apenas pensar em inteligência em uma cidade
analisando dados de sensores, como se estas fossem as únicas fontes de dados para cidades
inteligentes. A grande maioria das cidades mantém uma gama de serviços antigos em
sistemas de informação que têm um potencial enorme para uma decisão estratégica. Se
unir o legado com os sistemas recém-implantados e capilarizados pela cidade, a capacidade
de inovação aliada à prestação de serviços e criatividade de novas aplicações, já apontados
pelo Gartner como tendência, tornam de fato um diferencial e transformam um cidade
digital em uma cidade inteligente.
47
3 Mandala
Segundo (VARGAS; GOTTARDI; BRAGA, 2016), as demais áreas da Engenharia de Soft-
ware desenvolvem bem mais rápido que a área de SoS. Em consonância com esta afir-
mativa, (NAKAGAWA et al., 2017) cita a falta de preparo que a área de Arquitetura de
Software possui para lidar com o dinamismo de um SoS. Da mesma forma, (KOBETSKI;
AXELSSON, 2017) e (NETO et al., 2014) relatam, respectivamente, atrasos no avanço do
estudo das propriedades não funcionais de um SoS, em especial, na área de segurança, e
na área de desenvolvimento orientado a modelo para SoS.
Embora as áreas relatadas acima não façam parte do escopo desta dissertação, tais
relatos permitem induzir que a área de SoS, no âmbito da Engenharia de Software, ainda é
uma área carente de maiores estudos. Para reforçar ainda mais esta linha de pensamento,
(NAKAGAWA et al., 2013) destaca que, apesar da relevância da área, o desenvolvimento
de SoS para sistemas intensivos de software não tem sido amplamente investigado no
contexto da Engenharia de Software.
Devido a esta escassez de trabalhos na área e às características específicas do SoS, ci-
tadas no Capítulo 2, que tornam o trabalho de desenvolvimento um pouco mais complexo
que o desenvolvimento de sistemas tradicionais, é bem provável que muitos desenvolvedo-
res sintam-se desencorajados em enfrentar esta área ainda pouco explorada. Em função
dessa carência, o Mandala vem com o intuito de contribuir um pouco para a evolução
da área, visando permitir a integração de sistemas através de um middleware, formando
SoS, utilizando diversas tecnologias agregadas e procurando abstrair ao máximo detalhes
relacionados às tecnologias utilizadas nos sistemas constituintes.
Este capítulo descreve a estrutura do Mandala, detalhando a sua arquitetura, na Se-
ção 3.1, o seu funcionamento, na seção seguinte, e a sua implementação, na 3.3. A sua
arquitetura - composta pelos componentes SoS Composer, SoS Manager, SoS Server e
Broker - será apresentada em detalhes, com a visão da funcionalidade de cada compo-
nente, bem como a forma de comunicação entre eles e o armazenamento dos dados. Do
48
mesmo modo, detalhes sobre o funcionamento da plataforma e a implementação desses
componentes serão apresentados para um melhor entendimento da tecnologia utilizada na
sua produção.
3.1 Arquitetura
De uma forma geral, a proposta do Mandala visa minimizar, primordialmente, as
dificuldades de fazer com que sistemas desenvolvidos utilizando tecnologias distintas pos-
sam interoperar, formando um SoS. Mais que isso, o papel da plataforma é absorver a
responsabilidade pelas negociações de comunicação entre os sistemas constituintes, per-
mitindo que estes sistemas sejam inseridos ou removidos do SoS, sem necessitarem do
conhecimento de quantos e quais sistemas ele necessita se comunicar. A Figura 8 ilustra
a arquitetura do Mandala, que é composta por quatro elementos ou componentes princi-
pais: SoS Composer, SoS Manager, SoS Server e Broker. Complementam a plataforma,
as estruturas de comunicação e de armazenamento dos dados.
Figura 8: Arquitetura do Mandala
Para que fique mais claro o entendimento sobre a arquitetura dos componentes que
formam o Mandala, mais detalhes sobre eles serão apresentados nas subseções que seguem.
49
3.1.1 SoS Composer
Da forma que está projetado o Mandala, os SoS são criados no SoS Composer mediante
associações dos sistemas previamente registrados no SoS Manager (vide Figura 9). A
plataforma possui uma interface de comunicação, que será apresentada com mais detalhes
nas seções seguintes, onde o desenvolvedor do sistema constituinte fornece as informações
sobre o sistema que deseja colaborar com o Mandala. Neste momento, o sistema ainda
é candidato a constituinte e suas informações são armazenadas no repositório do SoS
Manager.
O desenvolvedor de SoS, responsável em agrupar sistemas e associá-los a um SoS, de
posse das informações dos sistemas cadastrados, pode formar, no SoS Composer, quantos
e quais SoS desejar. A quantidade de SoS que os sistemas constituintes participam é
transparente para eles. Em outras palavras, isto quer dizer que, independente de quantos
SoS ele participe, o sistema que deseja colaborar com os SoS formados no Mandala só
será cadastrado uma vez na ferramenta, desde que não tenha alterações em sua forma de
comunicação.
Figura 9: Envio dos dados do sistema pelo desenvolvedor do Sistema Constituinte e criaçãodo SoS pelo desenvolvedor do SoS.
Quando a associação de um SoS é realizada no SoS Composer, uma missão global,
por meio da criação de um fluxo de execução, é definida. Este fluxo, gerado com base
em processos de negócio, possui elementos que são mapeados para objetos para serem
armazenados no repositório do SoS Manager. Após esse processo de composição, conforme
pode ser visto na Figura 10, parte das informações gravadas são replicadas no repositório
de dados do SoS Server e no repositório de cada um dos Broker para que eles tenham
uma cópia de cada fluxo a qual fazem parte. Em seguida, um serviço Web é gerado e
50
publicado para que seja possível o consumo de informações pelos clientes. Cabe reforçar
que um sistema constituinte pode fazer parte de vários SoS e um SoS deve ser formado
por mais de um sistema constituinte.
Figura 10: Publicação do Serviço Web e disseminação nos repositórios das informações sobreo SoS criado.
A partir da publicação do serviço Web, o SoS já está pronto para uso e as caracterís-
ticas de independência funcional e gerencial dos sistemas constituintes devem se manter
intactas.
3.1.2 SoS Manager
Foi visto que quando ocorre o cadastro ou alteração de algum SoS, uma gravação no
repositório de dados do SoS Manager é requisitada pelo SoS Composer. O SoS Manager
recebe a solicitação, realiza a persistência dos dados (metadados do SoS), dissemina as
informações ao SoS Server e aos Broker e prossegue com a (re)publicação do serviço
Web do SoS. Também é função deste componente receber e armazenar as informações dos
sistemas candidatos a constituintes que são enviadas por seus responsáveis.
No entanto, as funções do SoS Manager não se resumem a estas informadas no pa-
rágrafo anterior. Também é de sua responsabilidade substituir, em tempo de execução,
sistemas constituintes que estejam afetando o desempenho do SoS. Esta substituição, ob-
viamente, só pode ocorrer se outro sistema cadastrado no Mandala contenha a mesma
missão individual e forma de acesso.
Embora a ferramenta esteja preparada para utilizar comportamentos proativos, atra-
vés do uso de agentes de software, a funcionalidade supramencionada não faz parte do
escopo deste trabalho.
51
3.1.3 SoS Server
O ponto de entrada para que clientes possam interagir com um SoS criado no Mandala
é o SoS Server. Ao utilizar o serviço Web do SoS, o cliente sinaliza que deseja consumir
as informações daquele SoS e uma solicitação de execução é recebida pela plataforma.
Figura 11: Solicitação de execução do SoS - Visão do SoS Server
A Figura 11 mostra que dentro ainda do componente SoS Server, uma associação entre
o serviço Web relativo ao SoS consumido e um agente de software para o SoS, existente
no componente, é realizada. Para realizar essa associação, um agente de software especial
temporário é criado para cada requisição ao SoS.
Devido ao fato dos agentes de software possuírem uma linguagem específica para a
comunicação, essa associação entre o serviço Web e o agente do SoS se faz necessária para
que o fluxo de execução do SoS dentro do Mandala seja seguido.
Para dar início à execução do SoS, no entanto, é preciso ter conhecimento de quais
sistemas pertencem a ele, como estes podem ser endereçados e qual a responsabilidade de
cada um dentro do fluxo ou missão global definida para o SoS.
O conhecimento dos sistemas participantes do SoS (incluindo o endereço do agente
do Broker responsável) e dos passos a serem seguidos é adquirido mediante consulta ao
repositório local. Com a recuperação do endereço dos agentes de software de cada Broker
relativo ao sistema constituinte, em especial ao responsável pela execução do primeiro
passo da missão, e o envio da solicitação de execução do fluxo, dá-se, de fato, início à
execução do SoS. Ao final da execução do SoS, o agente habitado no SoS Server recebe a
resposta do agente do Broker que executou o último passo e repassa ao cliente.
52
É interessante frisar que esta forma de iniciação do SoS é baseada no tipo de SoS
proposto pelo Mandala no momento. Os SoS criados pela plataforma possuem caracte-
rísticas de SoS direcionados ou diretivos, cujas gerência e construção ocorrem de forma
centralizada. Se os SoS fossem do tipo colaborativo ou virtual, uma exigência maior de
inteligência artificial seria requerida aos agentes e a iniciação dos SoS seria menos mecâ-
nica. Esta limitação pode ser resolvida utilizando as características de proatividade dos
agentes, que, conforme já mencionado, ainda não é prevista no Mandala. Caso a proativi-
dade venha a ser utilizada, a missão global pode ser invocada autonomicamente e, quando
necessário, através dos próprios sistemas constituintes. O SoS Server seria, desta forma,
uma das alternativas de acesso ao Mandala, mas não a única.
3.1.4 Broker
Cada sistema constituinte de um SoS deve possuir uma API para que a plataforma
Mandala possa se comunicar com ele. Essa API deve ser desenvolvida pelo desenvolvedor
do sistema constituinte e informada ao Mandala no momento do seu cadastramento na
plataforma.
Figura 12: Comunicação do Broker.
O componente do Mandala responsável pela comunicação com o sistema constituinte é
denominado Broker. O Broker é desenvolvido pelo desenvolvedor do sistema constituinte
(com base em uma classe abstrata fornecida pelo Mandala) e possui duas interfaces de
comunicação (vide Figura 12): (i) a primeira é baseada em agente de software e serve
53
para realizar a comunicação com os componentes SoS Server, SoS Manager e com outros
Brokers ; e (ii) a segunda permite a comunicação com o sistema constituinte utilizando
técnicas de chamadas à API. Um Broker está associado a apenas um sistema constituinte.
Quando um SoS é ativado, todos os Broker relativos aos sistemas constituintes par-
ticipantes, além do SoS Manager e do SoS Server, recebem uma cópia do fluxo a ser
executado para aquele SoS. A partir do momento que o SoS é iniciado, todos já estão
cientes da sua participação e da sua responsabilidade dentro daquela missão. Todos os
agentes participantes recebem também qual passo é o próximo na fila de execução. Quando
o agente de software do Broker recebe a mensagem de início do SoS ou de continuidade do
fluxo, ele identifica o passo, verifica a responsabilidade com base no fluxo gravado em seu
repositório, e dá início ou prosseguimento à execução, caso seja ele o responsável. Caso
ele não se identifique como responsável sobre aquele passo, ignora a mensagem e fica no
aguardo de novas solicitações.
Cada vez que uma tarefa é realizada, o Broker envia uma mensagem a cada agente
participante do SoS. Se o passo executado foi o último do fluxo, o serviço Web respon-
sável pelo SoS, dentro do SoS Server, recebe a informação do agente, pela associação
estabelecida anteriormente, e informa ao cliente o resultado da execução.
3.1.5 Comunicação e Repositórios
Quando um serviço Web é acessado e um SoS é iniciado, toda a sua comunicação
interna ocorre por troca de mensagens entre agentes de software. Os agentes também são
utilizados para disseminar as informações aos Broker, pelo SoS Manager, quando ocorre
a criação do SoS.
Foi visto no Capítulo 2 que os agentes de software possuem diversas característi-
cas, dentre elas a autonomia, a capacidade de interoperar e a proatividade. Esta última
possibilita o uso de inteligência para assumir situações por iniciativa própria e isto foi
fundamental, juntamente com toda a capacidade de interoperabilidade que o agente já
traz, para a escolha desta tecnologia para realizar a interoperabilidade entre os sistemas
dentro do Mandala. Há de se ressaltar, mais uma vez, que, neste momento, o Mandala
ainda não trabalha de forma proativa, porém a estrutura já está pronta para ser usada
em momento oportuno.
Ainda em consonância com a arquitetura apresentada na Figura 8, o Mandala apre-
senta três classes distintas de repositórios:
54
(i) O primeiro repositório está localizado no SoS Manager, que contém as informações
de metadados relacionados à estrutura do SoS que foram criados e publicados, como as
missões (fluxos), a sequência de passos a ser executada, o endereço dos Broker, os sistemas
participantes e as suas respectivas tarefas;
(ii) Outro repositório está localizado no SoS Server que, diferentemente do SoS Ma-
nager, armazena informações apenas dos SoS que estão em execução. São armazenadas
neste repositório, além da identificação do SoS, as informações do agente dos Broker dos
sistemas participantes do SoS em execução, como também a sequência de passos.
(iii) O terceiro repositório presente no Mandala faz parte do Broker, no qual as infor-
mações relativas à comunicação com os sistemas constituintes estão presentes. O Broker
recebe as informações do SoS Manager relativas aos SoS que o sistema constituinte asso-
ciado a ele faz parte e armazena no repositório. Estas informações incluem as informações
sobre o SoS, como a sua missão e os passos a serem executados.
3.2 Funcionamento
Na seção anterior foi discutida a parte arquitetural do Mandala. Para adicionar um
pouco mais de dinamismo ao que foi apresentado, alguns diagramas de atividades serão
dispostos nesta seção.
Figura 13: Diagrama de atividades referente à criação do SoS.
55
A Figura 13 apresenta o diagrama referente à criação do SoS. Este diagrama relata
as atividades à partir do recebimento das informações relativas ao sistema constituinte,
enviadas pelo desenvolvedor daquele sistema.
Figura 14: Diagrama de atividades referente à publicação do SoS e divulgação aos interessadossobre a criação do SoS.
Na sequência, a atividade referente à publicação do SoS e ao envio das informações
aos interessados, após a criação do SoS, será apresentada na Figura 14.
Após a publicação do SoS, o próximo passo da sequência de atividades dentro do
Mandala é a execução do SoS. Tal atividade está ilustrada na Figura 15.
3.3 Implementação
Após a apresentação da arquitetura e do funcionamento do Mandala, esta seção tem
como objetivo apresentar os detalhes sobre a implementação dos diversos componentes
da arquitetura do Mandala, discutidos nas seções anteriores, bem como a estrutura de
comunicação e de armazenamento.
A ideia nos próximos parágrafos é discorrer apresentando uma sequência similar ao
apresentado nas Seções 3.1 e 3.2, citando pontos da arquitetura e do funcionamento,
porém com uma visão mais ligada a detalhes de código e configuração.
56
Figura 15: Diagrama de atividades referente à execução do SoS.
3.3.1 Implementação dos agentes de software
O Mandala foi desenvolvido utilizando a linguagem de programação JAVA, com o
suporte da IDE Eclipse1. Para agregar algumas facilidades e funcionalidades à plataforma,
algumas bibliotecas e plugins necessitaram ser adicionados à IDE. Alguns detalhes serão
apresentados nos parágrafos seguintes, assim como alguns trechos de código que servem
para enriquecer um pouco mais o entendimento de como a plataforma foi desenvolvida.
Cabe informar, no entanto, que o código completo do Mandala está disponível de forma
gratuita no endereço: github.com/AltairMendes.
Por se tratar de uma ferramenta que objetiva prover interoperabilidade e que tem como
ponto forte a estrutura de comunicação existente entre os componentes, o primeiro passo
foi trabalhar esta parte para depois se aprofundar na implementação dos componentes
periféricos.
Para realizar a comunicação entre alguns componentes do Mandala, um estudo foi1Eclipse - http://www.eclipse.org
57
Figura 16: Tela de Gerenciamento do JADE
realizado e, devido às características e objetivos da plataforma, decidiu-se, conforme apre-
sentado na seção de arquitetura, pela utilização de agentes de software.
Figura 17: Mensagem do Tipo Request
Figura 18: Mensagem do Tipo Inform
Devido a questões de compatibilidade com a linguagem JAVA, uma vez que o Mandala
foi desenvolvido com essa linguagem, e por possuir uma extensa documentação, o JADE2
foi o framework escolhido para o gerenciamento dos agentes.
A Figura 16 representa a tela de gerenciamento do JADE. A partir desta tela é possível
ter acesso às demais ferramentas gráficas, como também gerenciar os agentes criados no
Mandala.
Os agentes são baseados em troca de mensagens e em comportamentos. O tratamento
das mensagens pode ser diferente de acordo com a solicitação que lhe é atribuída e os2JADE - Java Agent DEvelopment Frameork - http://jade.tilab.com
58
Figura 19: Troca de Mensagens entre os Agentes
comportamentos podem definir o nível de proatividade ou reatividade que se deseja ex-
plorar. Há vários tipos de mensagem no JADE. Para exemplificar, a Figura 17 apresenta
uma mensagem do tipo REQUEST, ao ponto que a Figura 18 apresenta uma mensagem
do tipo INFORM. Neste exemplo, uma é específica para requisição de algo, a outra, para
simples transmissão de informação. A implementação do agente é pautada nas escolhas do
tipo de comportamento e de tipo de mensagem associada. Sendo assim, um componente
do Mandala pode tomar uma decisão para realizar uma determinada ação, caso receba
uma mensagem do tipo REQUEST, mas pode simplesmente ignorar ou apenas imprimir
uma mensagem se receber uma mensagem do tipo INFORM.
A Figura 19 apresenta uma visão fornecida por uma das ferramentas gráficas do
JADE, chamada Sniffer, que permite identificar a troca de mensagens e o tipo de requi-
sição solicitada pelos agentes. Esta é uma visão capturada durante a realização dos testes
no Mandala. A imagem representa a troca de mensagens para a realização de um SoS.
O primeiro agente, identificado por um retângulo amarelo e com nome "Control WSIG
Container", identifica a requisição do cliente e solicita ao "WebService Agent"a realização
do SoS. As requisições vão sendo executadas e identificadas por setas de cores diferentes
(a cor da seta de informação da resolução da tarefa é igual ao da requisição). A solici-
tação possui o parâmetro REQUEST. A resposta, INFORM. Entre essas duas trocas de
mensagens, há uma série de outras trocas de mensagens entre outros agentes (setas na cor
cinza). Estes agentes são os agentes dos Broker, que identificam a responsabilidade sobre
a tarefa e solicitam a sua execução ao seu respectivo sistema constituinte.
59
3.3.2 Implementação dos repositórios
A arquitetura do Mandala prevê o armazenamento dos dados em três repositórios, a
citar: repositório do SoS Manager, repositório do SoS Server e repositório do Broker.
Figura 20: Estrutura de Armazenamento do Repositório Geral
A plataforma não tem a necessidade de realizar o armazenamento das informações
que são trocadas entre os sistemas constituintes, conforme mostra a Figura 20, que re-
presenta o repositório do SoS Manager, de onde boa parte será copiada para os demais
repositórios. Os dados armazenados na plataforma serão, de uma forma geral, relativos
aos sistemas constituintes (metadados), SoS criados (incluindo fluxos, passos e missões)
e alguns relacionamentos entre eles. A Figura 21 mostra um trecho de acesso a um dos
repositórios.
Figura 21: Trecho de código de acesso ao repositório
Dessa forma, não foi justificada a necessidade de implantação de um Sistema Geren-
ciador de Banco de Dados tão robusto esperando uma imensa carga de manipulação dos
dados.
60
Devido a este fato, imagina-se que, mesmo que vários SoS sejam criados e executa-
dos, a quantidade de dados armazenada, de fato, na ferramenta, não seja muito grande.
Nesse contexto, estudos foram realizados e optou-se pela utilização do SQLite3, que, além
de gratuito, não requer instalação nem configurações, atendendo perfeitamente ao que
esperava-se de um sistema de armazenamento de dados, na visão específica do Mandala.
3.3.3 Implementação do Broker
O Broker é o componente do Mandala que atua como um intermediário entre a pla-
taforma e o sistema constituinte. Ele recebe as requisições que são originadas pelo SoS
Server e verifica se a tarefa é de responsabilidade do sistema constituinte que ele repre-
senta. Se for, ele solicita a execução e aguarda a resposta para dar continuidade ao fluxo
de execução da missão global do SoS.
Figura 22: Classe abstrata de acesso ao sistema constituinte
A criação deste componente é realizada pelo desenvolvedor do sistema constituinte,
com base em uma classe abstrata disponibilizada pelo Mandala. A classe abstrata pode
ser observada na Figura 22 e um exemplo de sua extensão, na Figura 23.
A comunicação entre o Broker e o sistema constituinte é realizada via acesso à API.
Esta API é informada ao Mandala através do preenchimento de um formulário, que deve
ser enviado pelo desenvolvedor do sistema constituinte, e o seu formato está apresentado
na Figura 24. Neste formulário, informações como o nome e endereço do sistema, nome
do agente de software que será associado ao Broker, funcionalidades disponíveis e tipo de
acesso (GET, POST) são relatadas para armazenamento na plataforma.3www.sqlite.org
61
Figura 23: Classe concreta que acessa o sistema constituinte
Figura 24: Formulário de envio dos dados relativos ao sistema constituinte
Para a comunicação com o Mandala, o sistema constituinte deve fornecer uma API
baseada no estilo arquitetural REST. Caso o sistema constituinte não possua uma interface
de comunicação que possa servir de acesso às funcionalidades do sistema, o desenvolvedor
do sistema precisa realizar alterações em seu código para que este acesso seja permitido.
Após o repasse das informações pelo desenvolvedor do sistema constituinte, a estrutura
do Broker, com agente de software, banco de dados e interface de acesso a este banco é
gerada pelo Mandala.
62
3.3.4 Implementação dos módulos SoS Composer, SoS Managere SoS Server
O SoS Composer é o responsável em criar os SoS com base nos sistemas candidatos a
constituintes armazenados na plataforma. A criação do SoS é realizada pelo desenvolvedor
do SoS e é efetuada diretamente na IDE Eclipse.
Para montar um SoS, no entanto, foi necessário instalar um plugin do BPMN na IDE
Eclipse, para representar o fluxo baseado em processos de negócio. Esse plugin permite
que as missões globais sejam geradas, um diagrama baseado em BPMN seja modelado e
um fluxo seja criado. Detalhes sobre o plugin instalado para realizar essas operações estão
presentes na Figura 25.
Figura 25: Plugin utilizado na IDE Eclipse para modelar a missão global do SoS
Após a instalação do plugin, uma pequena configuração precisou ser realizada para que
ele fosse reconhecido corretamente e apresentasse os componentes necessários ao Mandala.
Foi criado um perfil (vide Figura 26) e, associado a este perfil, os componentes do BPMN
necessários para modelar a missão global do SoS. Os componentes escolhidos para esta
versão do Mandala foram Start Event, End Event, Base Element e Sequence Flow.
Quando o perfil do Mandala é criado na ferramenta de modelagem e os sistemas
candidatos a constituintes começam a ser cadastrados, ao abrir, no Eclipse IDE, uma tela
para edição de um diagrama BPD, que é baseado em BPMN, tanto os sistemas quanto
as funcionalidades ou tarefas cadastradas no formulário, estarão disponíveis para que o
desenvolvedor do SoS possa realizar a associação de sistemas e funcionalidades ao SoS e
montar a sua missão global. A Figura 27 apresenta esta situação.
Feita a associação dos sistemas candidatos (a partir de agora podem ser considerados
constituintes de um SoS), um arquivo XML, fruto do modelo recém-criado, é gerado e
63
Figura 26: Criação do perfil do Mandala na ferramenta de modelagem baseada em BPMN
Figura 27: Criação de um diagrama BPD relativo a uma missão global de um SoS
para que seja entendível pelo Mandala, este arquivo precisa ser traduzido para objetos
JAVA.
A conversão dos dados inseridos no arquivo XML para objetos JAVA é realizada por
uma biblioteca baseada na convenção DOM (do termo em inglês, Document Object Model).
A Figura 28 apresenta detalhes dessa biblioteca. Uma vez convertidos, estes objetos JAVA
são armazenados no repositório do SoS Manager.
O SoS Server, no atual estágio do Mandala, responde, além da função de armazena-
mento das informações de metadados dos sistemas constituintes e dos SoS gerados, pelas
funções de divulgação aos Broker relativos aos sistemas constituintes e pela solicitação de
publicação do serviço Web gerado para o SoS.
Quando o SoS é criado (ou editado) e o SoS Manager recebe a solicitação de gravação
dos dados em seu repositório, este componente automaticamente entende que precisa
divulgar as informações aos Broker participantes, como também solicitar ao SoS Server
a publicação do serviço Web relativo ao SoS. A Figura 29 mostra detalhes do código
64
Figura 28: Utilização da Biblioteca DOM para Modelagem do arquivo XML
implementado para executar a função de divulgação.
Como reforço, cabe lembrar que a comunicação entre o SoS Manager e o Broker é
baseada no envio de mensagens entre agentes de software.
Para a publicação do serviço Web relativo ao SoS, uma classe, em JAVA, pertencente
ao SoS Server é editada e executada com o nome do serviço que se deseja publicar (vide
Figura 30). Para fins de registro, como esta classe é editada pelo desenvolvedor do SoS,
no momento da criação do SoS, não houve a preocupação em desenvolver uma interface
gráfica para tal. Após a publicação, o serviço estará disponível para acesso pelos clien-
tes, bastando requisitá-lo, informando o endereço e o verbo HTTP (GET, POST, PUT,
DELETE) disponível. No caso do serviço apresentado na Figura 31, o acesso ocorre via
solicitação GET.
Quando o serviço Web é requisitado e a requisição chega ao SoS Server, para que o
agente do SoS possa se comunicar com os agente do Broker, informando que o SoS deve ser
executado, é necessário que esta solicitação seja traduzida para uma linguagem entendível
65
Figura 29: Divulgação aos Broker participantes sobre a criação do SoS
pelo agente. Por causa disso, há um módulo, denominado JADEGateway, que tem como
função traduzir algo não reconhecido pelo agente para algo entendível pelo agente.
O JADEGateway faz a criação de um agente temporário para cada requisição que
chega ao SoS. Isto ocorre para que seja possível o agente do SoS receber a requisição e
dar início ao processo de execução do SoS.
Para finalizar todo o processo de criação, divulgação e acesso ao SoS dentro do Man-
dala, no contexto da implementação, a Figura 32 apresenta trecho do código de chamada
ao Broker que executa o primeiro passo do fluxo de execução do SoS.
66
Figura 30: Classe editada para a publicação do serviço Web
Figura 31: Serviço Web publicado para acesso pelos clientes
Figura 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 fluxo.
67
4 Avaliação
A necessidade de integração que os sistemas possuem para poderem gerar novos be-
nefícios, inalcançáveis quando estes sistemas trabalham de forma isolada, é a grande mo-
tivação para o SoS. Contudo, para criar SoS, algumas premissas precisam ser seguidas.
Estas premissas, bem detalhadas no Capítulo 2, são os diferenciais entre a integração
dos sistemas tradicionais e um SoS. Nesse contexto, visando verificar a capacidade que o
Mandala tem de integrar os sistemas com base nas premissas definidas para um SoS, este
capitulo objetiva validar a plataforma utilizando um estudo de caso, em forma de provas
de conceito(JR.; CHEN; PURDIN, 1990). Um estudo de caso é um método empírico explo-
ratório planejado para investigar fenômenos em um ambiente natural usando múltiplas
fontes de evidência (YIN, 2017)(ROBSON; McCartan, 2016).
Dadas as características de dinamismo, distribuição geográfica e independência, tanto
funcional quanto gerencial, além da grande heterogeneidade dos seus sistemas e do objetivo
permanente do provimento de benefícios aos seus cidadãos, o ambiente ideal, perfeito e
plausível para a utilização de SoS, e, por conseguinte, para a validação do Mandala, é o
de cidades inteligentes.
Porém, alguns pontos merecem ressalvas quanto a esta validação:
• O número de cidades inteligentes no Brasil ainda é escasso e a cidade do Natal ainda
não se enquadra nesta categoria;
• É difícil encontrar sistemas em produção disponíveis para a montagem de um SoS;
• Por ser uma área em desenvolvimento, é raro encontrar desenvolvedores de SoS para
utilizarem o Mandala e informarem sobre a sua visão sobre os testes.
Diante deste quadro, o estudo de caso é referente a dois SoS desenvolvidos especifi-
camente para este fim, não sendo, portanto, sistemas em produção ou de alguma cidade
inteligente conhecida.
68
4.1 Cenário
Este estudo de caso é composto por dois SoS, cada qual contendo três sistemas cons-
tituintes. O primeiro SoS e seus respectivos sistemas estão descritos a seguir:
• O primeiro sistema, desenvolvido em JAVA, é responsável pelo cadastro de hospitais
de uma cidade. A missão individual é fornecer os dados sobre a localização de cada
hospital e a quantidade de leitos disponíveis para cada unidade;
• O segundo sistema, também desenvolvido em JAVA, é responsável pelo gerenci-
amento dos chamados às ambulâncias. A sua missão é cadastrar um chamado e
solicitar o envio de uma ambulância para atender o paciente, e levá-lo até o hospital
cadastrado no sistema. O hospital de destino é baseado apenas no CEP do atendi-
mento, onde há uma tabela relacionando um CEP de origem a apenas um CEP de
hospital cadastrado;
• o terceiro e último sistema constituinte é desenvolvido em PHP e a sua missão
individual é fornecer a distância, em metros, entre dois CEPs informados. Este
sistema faz uma chamada à API do Google Matrix1 para obter estas informações.
O SoS formado pela integração entre os três sistemas constituintes supracitados tem
como missão global o fornecimento do hospital mais próximo do local de atendimento e que
possui leitos disponíveis. O ganho deste SoS é impedir que a ambulância leve o enfermo
a um hospital que não tenha vagas disponíveis. Por não possuir a informação sobre os
leitos disponíveis, nem tampouco saber a distância de cada ponto de chamada até os
hospitais, o sistema individual de gerenciamento de ambulâncias é incapaz de realizar tal
feito. Desta forma, percebe-se claramente que há um comportamento emergente e este
SoS é perfeitamente aplicado a um cenário de cidade inteligente.
O outro SoS do estudo de caso, que também é aplicado ao contexto de cidades inteli-
gentes, é o SoS que possui a missão global de gerar rotas otimizadas para os carros do lixo.
Sem o SoS, as rotas são geradas sem analisarem a ocupação do container de lixo, podendo
liberar carros para a coleta sem a devida necessidade, gastando combustível, gerando mais
trânsito e trazendo prejuízo à população. Isso sem contar no fato de que, sem saber da
ocupação do container, este pode estar cheio e o carro demorar a passar para realizar a
coleta, pois tem horários predefinidos para a tarefa.1Google Matrix - https://developers.google.com/maps/documentation/distance-matrix/intro?hl=pt-
br
69
Os sistemas constituintes relativos a esse SoS são descritos a seguir:
• O primeiro sistema, desenvolvido em PHP, simula uma rede de sensores que estão
instalados nos contêineres de lixo espalhados pela cidade e informam periodicamente
a ocupação e o peso do volume armazenado;
• O segundo sistema, desenvolvido em JAVA, é responsável por um portal de in-
formações sobre a produção de lixo na cidade. Este sistema mantém um cadastro
atualizado de todos os contêineres de lixo espalhados pela cidade. A sua missão é
consolidar informações dos contêineres, por bairro, categoria, região, além de infor-
mar a produção de lixo per capita;
• o terceiro e último sistema constituinte é desenvolvido em JAVA e a sua missão
individual é gerenciar os caminhões de lixo da cidade. À medida que um container é
adicionado à lista de coleta, este container é adicionado à rota de alguma caminhão
sem qualquer critério. Os caminhões saem para a coleta em horários predefinidos,
independente da ocupação do container.
Para a execução do estudo de caso foram utilizadas duas máquinas. A primeira, onde
os sistemas desenvolvidos na linguagem JAVA estavam sendo executados, possui a seguinte
configuração:
• Sistema Operacional: MacOS High Sierra
• Processador: Intel i5 2,5GHz
• Memória: 4GB DDR3 1600MHz
A segunda máquina, onde o Mandala executou juntamente com os sistemas desenvol-
vidos em PHP, possui como configuração:
• Sistema Operacional: Linux Ubuntu LTS 16.04
• Processador: Intel i5 2,6GHz x 4
• Memória: 4GB DDR3
70
4.2 Objetivo
O objetivo principal deste estudo de caso é verificar se a plataforma Mandala, diante
da solicitação de integração dos sistemas constituintes, é capaz de realizá-la atendendo
aos requisitos obrigatórios de construção de um SoiS.
Como objetivo secundário, o estudo de caso verifica de que forma pode ser extraída
alguma vantagem pelo uso de um middleware na integração de sistemas com base em
SoIS. Para tentar atingir este objetivo, o estudo de caso verificará se o Mandala é capaz
de trabalhar com mais de um SoS simultaneamente sem que erros de comunicação sejam
observados.
Segundo (KITCHENHAM; PICKARD; PFLEEGER, 1995)(WOHLIN et al., 2012), cinco pas-
sos fundamentais precisam ser seguidos para que um estudo de caso seja definido. São eles:
(i) projeto do estudo de caso, (ii) preparação da coleta de dados, (iii) a coleta de dados
em si, (iv) análise dos dados coletados, e, por fim, (v) a discussão sobre os resultados.
4.3 Projeto do Estudo de Caso
Conforme já mencionado, o que está sendo estudado é se os requisitos de formação
de um SoIS são suportados pelo Mandala quando ocorre a integração e se a plataforma
trabalha bem a sua forma de troca de mensagens quando possui mais de um SoS em
execução.
Desta forma, as seguintes questões de pesquisa foram definidas para a condução do
estudo:
Q1. O Mandala é útil para integrar sistemas de informação com base em
SoIS? Esta questão de pesquisa procura definir se o Mandala é uma ferramenta útil para
integrar sistemas de informação utilizando as características básicas da criação de um
SoIS.
Q2. OMandala é capaz de realizar a interoperabilidade entre sistemas cons-
tituintes de um SoIS e apresentar resultados corretos aos usuários? Esta questão
de pesquisa verifica se o Mandala é capaz de integrar com sucesso sistemas constituintes
heterogêneos.
71
4.4 Preparação da Coleta de Dados
Em muitos estudos de caso, a técnica de coleta de dados é focada em dados qualita-
tivos, mas dados quantitativos também se mostram importantes neste tipo de pesquisa.
(WOHLIN et al., 2012) indica que uma coleta de dados deve seguir a diretriz conhecida
como GQM (Goal/Question/Metric), cuja função é deixar claro os objetivos a serem al-
cançados, o que deve ser respondido pela pesquisa e como alcançar os resultados. Nesta
perspectiva, as seguintes métricas foram definidas e associadas às questões de pesquisa
relatadas na seção anterior:
M1. Número de características do SoIS atendidas pelo Mandala. Conforme
relatado no Capítulo 2, por ser uma classe especial de SoS, o SoIS possui as cinco caracte-
rísticas principais desta classe de sistema (independência gerencial e operacional, sistemas
geograficamente distribuídos, desenvolvimento evolucionário e comportamentos emergen-
tes), além de seguir um fluxo de informações entre os sistemas constituintes, gerar uma
informação de valor agregado (fruto de uma integração entre os sistemas constituintes) e
ser guiado por um processo de negócio. Para verificar se o Mandala é útil à integração de
sistemas utilizando os conceitos de SoIS, conforme especificado na questão de pesquisa 1
(Q1), é necessário analisar quantas destas características são atendidas pela plataforma.
M2. Quantidade de falhas durante a execução do Mandala. A indicação de
que não houve falhas durante a integração de algum SoS pode ser obtida analisando a
quantidade de paradas, erros ou resultados incorretos durante a execução da plataforma
em busca do alcance de uma missão global do SoS. Esta métrica está associada à questão
de pesquisa 2 (Q2).
4.5 Coleta e Análise dos Dados
Para coletar os dados de corretude na requisição ao SoS, definido em Q2, um plano
de testes utilizando a ferramenta JMeter2 foi desenvolvido buscando identificar a página
de retorno das requisições, comparando-a com um trecho de um texto que era esperado
para cada requisição.
A resposta da página de testes é no formato JSON, onde existe uma chave e um valor
associado. Para o primeiro SoS, especificado no cenário, a resposta precisa trazer um
CEP e para o segundo, um container. Estas palavras foram utilizadas então para serem2Apache JMeter:http://jmeter.apache.org
72
verificadas na resposta da requisição. Caso o texto aparecesse na resposta da página, a
comunicação teria ocorrido com sucesso. Em caso negativo, a comunicação teria falhado.
Para promover uma maior confiabilidade aos dados, os testes foram realizados 30
vezes para cada SoS, onde cada teste simulou uma execução de 10 threads (uma thread
representou um usuário virtual), utilizando o ambiente definido no cenário de testes.
Esta quantidade de execuções se fez necessária a fim de obter uma maior significância
estatística, uma vez que o Mandala foi implementado na linguagem de programação JAVA
e pode estar sujeito a influências da Máquina Virtual do JAVA (JVM).
Sobre a análise da plataforma em relação ao fato de estar gerando um SoS, de fato,
quando há a integração, os seguintes pontos devem ser verificados:
• Sistemas geograficamente distribuídos: se pelo menos um sistema está sendo execu-
tado em uma máquina distinta do Mandala, este requisito está sendo atendido;
• Independências gerencial e operacional: Se o sistema constituinte fornece apenas
a API de acesso e não há alterações em seu código e a sua participação nos SoS
geridos pelo Mandala é de forma transparente, sendo inserido ou removido de um
SoS, sem afetar o funcionamento da sua execução individual, este requisito também
está atendido;
• Comportamento emergente: Se o Mandala é capaz de atender aos benefícios que a
integração promete, utilizando apenas as interfaces dos sistemas constituintes for-
necidas ao Mandala, este requisito está sendo atendido;
• Desenvolvimento evolucionário: Mudanças nos sistemas constituintes ou no ambi-
ente de execução do Mandala precisam ser absorvidas pela plataforma, de forma
transparente, sem afetar a execução do SoS, para que possa ser atendida.
• Orientação a Processos de Negócio: Processos de negócio podem representar a missão
global de um SoIS, as atividades a serem realizadas pelos sistemas constituintes
integrados e o fluxo de execução entre estes sistemas. Uma forma de definição e
criação do processo de negócio dentro da plataforma atende ao requisito.
Na próxima seção será apresentada a discussão acerca dos resultados dos testes.
4.6 Discussão
A base da análise dos testes foi pautada em duas questões de pesquisa, quais sejam:
73
1. O Mandala é uma ferramenta útil para integrar sistemas de informação com base
em SoIS?
2. O Mandala é capaz de realizar a interoperabilidade entre sistemas constituintes de
um SoIS e apresentar resultados corretos aos usuários?
Diante destas questões apresentadas, os testes foram efetuados e identificou-se, espe-
cificamente para a questão 1, que:
(i) alguns sistemas constituintes estavam em uma máquina distinta da máquina onde
o Mandala estava sendo executado e, mesmo tendo um ponto de falha, que é a rede
de comunicação de dados, a execução dos testes ocorreu sem problemas e o quesito de
distribuição geográfica dos sistemas foi atendida pelo Mandala;
(ii) durante a execução do SoS, os sistemas constituintes não foram afetados em sua
operação individual. Também não houve necessidade de alterações no código-fonte e a
participação do sistema no SoS foi totalmente transparente;
(iii) ao se criar um SoS no Mandala, um diagrama em BPD é editado para que seja
colocada a missão global. Nos testes realizados, tendo como base um SoS do tipo diretivo,
foi possível alcançar os comportamentos emergentes dessa missão global criando classes
que utilizavam os resultados obtidos de cada tarefa executada pelos sistemas constituintes.
Por esta ótica, o requisito de comportamento emergente estaria atendido. No entanto,
imaginando outros tipos de SoS, que trabalham de forma mais dinâmica e automática, é
possível que o comportamento emergente não seja possível de ser alcançado da forma que
foi desenvolvido nos testes. Por não ter esta garantia, este item vai ser considerado como
parcialmente atendido;
(iv) se os sistemas constituintes não evoluírem ao ponto de afetar o desempenho do
SoS, este quesito está atendido. No entanto, se houver evoluções e o SoS necessite de
adaptação em tempo real, o Mandala ainda não está pronto para isso. Neste ponto, pode-
se dizer que, neste momento, o Mandala só consegue integrar sistemas que não sofram
evoluções; e,
(v) o diagrama BPD (que representa graficamente a notação BPMN) mostrou ser útil
para representar a missão global do SoIS, as atividades a serem realizadas pelos sistemas
constituintes integrados e a execução entre eles. Este modelo e outras transformações
em relação à comunicação e execução baseada em agentes no Mandala tornam a plata-
forma adequada para lidar com conceitos relacionados à orientação inerente ao processo
de negócio relativo ao SoIS.
74
As respostas aos testes mostram que o Mandala ainda possui algumas limitações.
Uma delas é o fato de não utilizar, no momento, todo o potencial dos agentes de software,
deixando a plataforma um pouco limitada quanto às execuções dinâmicas. Isso pode
ser sentido no quesito de desenvolvimento evolucionário e, talvez, nos comportamentos
emergentes. Embora nos testes os comportamentos emergentes tenham sido atendidos, é
possível que sejam necessárias intervenções de proatividade também para que a plataforma
atenda a todas as situações.
No entanto, mesmo com limitações, é possível concluir que o Mandala está no cami-
nho de ser uma plataforma útil para realizar a integração de sistemas independentes e
heterogêneos em SoIS.
Quanto à questão 2, os testes foram executados com dois SoS publicados e após a
verificação do JMeter, erros não foram identificados. Isto significa que o Mandala consegue
trabalhar com mais de um SoS ao mesmo tempo e sua estrutura de comunicação não
ocasionou falhas.
Estima-se, com a análise descrita no parágrafo anterior, que se a plataforma funcionou
com dois SoS distintos trabalhando simultaneamente, é possível que ela também funcione
com uma quantidade maior de SoS.
Além disso, por esconder dos sistemas constituintes a quantidade de SoS que estes
fazem parte, subtende-se que a negociação entre os sistemas constituintes não é responsa-
bilidade deles e, sim, da plataforma. O desenvolvedor do SoS trabalha no desenvolvimento
do comportamento emergente, trabalhando com os dados que recebe das consultas API
direcionadas aos sistemas constituintes.
Diante deste aspecto, mesmo sem realizar entrevistas ou testes específicos para isso,
pode-se inferir que a plataforma pode ser bastante útil à área de Engenharia de Software,
mostrando que é possível haver ganhos com o Mandala, no contexto de integração de
sistemas, trazendo uma maior produtividade e preenchendo uma parte da lacuna existente
na área de SoS.
Por fim, apenas para fins informativos, uma vez que não foi objetivo desta dissertação
analisar o desempenho da plataforma, em termos de tempo de resposta, o Mandala obteve
uma média aritmética, avaliando as 30 execuções de cada SoS, de 3,701s para o SoS que
fornece o CEP do hospital, e 3,743s para o SoS que gera rotas otimizadas para os carros
de lixo.
75
5 Trabalhos relacionados
O Mandala utilizou em sua estrutura tecnologias que, embora algumas não sejam
novidades em soluções comerciais ou acadêmicas, o uso delas em conjunto ainda demonstra
andar a passos curtos. Com isso, há certa dificuldade em encontrar na literatura trabalhos
que adotem de forma conjunta os mesmos conceitos e paradigmas utilizados no Mandala.
A fim de verificar a utilização de ferramentas ou plataformas que busquem integrar
sistemas com base em SoS, foi utilizada a String de pesquisa a seguir em três das mais co-
nhecidas bases de dados digitais: ((system of systems) or (systems of systems) or (system-
of-systems) or (systems-of-systems)) and ((interoperability) or (integration)).
Como os artigos relativos ao tema vinham sendo monitorados e por existir uma revisão
sistemática datada de 2016 ((VARGAS; GOTTARDI; BRAGA, 2016), foi aplicado o filtro para
trabalhos existentes entre os anos de 2015 e 2017. Além disso, também foi aplicado um
filtro para que as palavras estivessem somente no título do trabalho, obtendo-se o seguinte
resultado, em termo de quantidade de trabalhos retornados:
• Springer - 11
• IEEExplore - 12
• ACM Digital Library - 21
Analisando apenas o título e, em alguns casos, o resumo, onde surgia a dúvida sobre
a real finalidade do trabalho, chegou-se à conclusão que nenhum desses trabalhos faz, de
forma concreta, o que o Mandala pretende realizar.
Diante deste fato, uma das alternativas de apresentar os trabalhos relacionados é
fatiar as funcionalidades que o Mandala desenvolve ou associar trabalhos que utilizem
tecnologias semelhantes para o mesmo contexto.
Sendo assim, esta seção apresenta informações sobre trabalhos que também utilizam
algum dos aspectos trabalhados no Mandala, embora poucos apresentem ideias com o
76
mesmo objetivo ou com as mesmas características.
5.1 Linha de atuação: Interoperabilidade e SoS
Embora a pesquisa não tenha retornado muitos trabalhos com ideia aproximada ao
que o Mandala se propõe, há um trabalho datado de 2012 que é muito interessante e
aborda dois pontos explorados no Mandala (interoperabilidade e SoS) é o Linked DataS-
pace (CURRY, 2012). O Linked DataSpace possui dois módulos em sua composição: (i) o
DataSpace, que serve para gerenciar os dados heterogêneos gerados pelas mais diversas
fontes; e, (ii) O LinkedSpace, que tem como função o compartilhamento e o reuso dos
dados. O Linked DataSpace busca atingir interoperabilidade com base na criação de um
espaço de informação global, onde dados heterogêneos estão armazenados oriundos de
vários sistemas e, com base em técnicas de Web Semântica, há uma estruturação desses
dados e um compartilhamento na Web ocorre de acordo com a conveniência do cliente.
Em uma situação onde se quer coletar dados de vários setores para realizar um geren-
ciamento de energia, por exemplo, os sistemas de cada setor informam seus dados brutos,
que serão armazenados no DataSpace, e, com base em técnicas semânticas específicas,
várias visões são formadas para que, de acordo com a demanda, estes dados sejam com-
partilhados, pelo LinkedSpace, da forma mais adequada ao requisitante. É uma ferramenta
que promete criar sistema de sistemas, porém, diferente do Mandala, o foco é em dados e
não segue um fluxo de dados e nem foca em funcionalidades.
Um outro trabalho proposto, nesta linha de atuação, que é bem recente e é um dos
poucos encontrados na literatura que possui características semelhantes ao Mandala, é o
apresentado por (AFOUTNI et al., 2017). Este trabalho também sugere a interoperabilidade
entre sistemas de informação usando como base os conceitos de SoiS. Tal qual o Mandala,
a sua estrutura interna também indica a utilização de agentes de software para realizar
a comunicação entre os sistemas constituintes e a plataforma de integração. Quanto à in-
tegração semântica, o trabalho sinaliza a utilização da interoperabilidade federativa, cujo
mapeamento entre diferentes informações provenientes dos diferentes sistemas é estabele-
cida de forma dinâmica. O MEMORAe é uma ferramenta colaborativa responsável pelo
gerenciamento dos dados e ontologias utilizada no trabalho acima referenciado.
A grande diferença, no entanto, do trabalho supracitado para o Mandala é que, embora
tenham sido apresentados os conceitos de interoperabilidade e de SoIS e um protótipo
realizando a comunicação entre os agentes, ele ainda é um projeto embrionário, bem
77
inicial, onde ainda não foi realizado nenhum teste prático de integração entre sistemas
de informação. Desta forma, é impossível analisar se a ferramenta conseguirá realizar a
integração entre sistemas de informação, assim como o Mandala já realiza. Também não é
possível determinar se as características do SoIS, como a orientação a processos de negócios
e a manutenção das independências operacional e gerencial dos sistemas constituintes,
serão seguidas. O Mandala, por sua vez, mesmo que não realize ainda todas as atividades
a qual se propõe de forma plena, já é um produto em funcionamento.
5.2 Linha de atuação: Modelagem de missões
Um SoS é determinado em função de sua(s) missão(ões) global(is), assim como os
sistemas constituintes, que possuem missões individuais.
Da mesma forma que sistemas tradicionais utilizam a UML1, por exemplo, para mo-
delar as suas atividades, os SoS, embora sejam sistemas com características diferentes
dos sistemas tradicionais, também utilizam linguagens para modelar os seus objetivos ou
missões.
Por isso, nesta seção será citado o mKAOS(SILVA; BATISTA; OQUENDO, 2015), uma
linguagem para definição de missões em SoS, que tem como base a KAOS, uma linguagem
que permite a descrição completa de modelos de sistemas, não se limitando apenas a parte
do software.
O mKAOS estende a linguagem KAOS e realiza o processo de descrição do SoS utili-
zando duas abordagens, a top-down e a bottom-up. Na abordagem top-down, o projeto é
guiado pelos comportamentos emergentes do SoS, ao ponto que na abordagem bottom-up,
quem guiam o projeto são os sistemas constituintes.
O Mandala faz uso de um plugin que é acoplado à IDE Eclipse, chamado de BPMN
Modeller, que realiza a modelagem da missão global do SoS, embora essa não seja a
principal função da ferramenta. Também é possível definir as tarefas associadas a cada
sistema constituinte. É fato que este plugin realiza a modelagem de forma bem mais
tímida que o mKAOS, uma vez que várias visões do modelo podem ser vistas, além das
abordagens já citadas.
Acontece que, por objetivar integrar sistemas com base em uma classe especial do
SoS chamado SoIS, os SoS, além de modelados, precisam seguir um fluxo de atividades,1Unified Modeling Language
78
o que não é previsto na linguagem mKAOS. Após a modelagem da missão global do SoS,
um fluxo orientando a sequência de execuções das tarefas da missão é automaticamente
gerada.
5.3 Linha de atuação: Uso de agentes de software nocontexto de SoS
O uso de agentes de software em qualquer contexto da Engenharia de Software pode
ser um importante aliado, tanto no aspecto de interoperabilidade (uma vez que agentes
permitem trabalhar em ambiente distribuído, com linguagem de comunicação própria,
abstraindo a linguagem de programação associada ao sistema) quanto no de inteligência
(fazendo uso de proatividade).
Conforme apresentado no início deste capítulo, a literatura acerca do tema "intero-
perabilidade para SoS"é bastante escassa e encontrar trabalhos que executem o mesmo
objetivo ou utilize das mesmas tecnologias é bem difícil.
No entanto, tal qual o Mandala, (HACHEM et al., 2016) utiliza em seu trabalho uma
abordagem de sistema multiagentes no contexto de um SoS. o SoSSec (System of Systems
Security) estende o JADE (conhecido framework para gerenciamento de agentes de soft-
ware) para realizar análise de vulnerabilidades em SoS, procurando identificar possíveis
aberturas para ataque em cascata.
O Mandala utiliza o JADE para realizar o gerenciamento dos agentes de software,
assim como o trabalho supramencionado, no entanto, o foco da plataforma é totalmente
diferente. O uso de agentes é realizado para prover a interoperabilidade entre os sistemas
distribuídos.
79
6 Considerações Finais
A cada dia que passa estamos cada vez mais inseridos neste mundo digital, onde
(quase) tudo e (quase) todos estão conectados e em comunicação. As cidades estão sendo
entupidas de sensores, de câmeras e de sistemas. As pessoas estão cada vez mais de-
pendentes dos seus smartphones e dos aplicativos que ali residem, algumas vezes sendo
consumidoras de informação, outras vezes, provedora. Enfim, o que se sabe é que neste
mundo digital a sensação que temos é que tudo está muito próximo e disponível. Basta
acessar o aplicativo ou site e a informação chega. Esse é o desejo de muitas pessoas,
principalmente devido à enorme evolução que a área de TIC, de uma forma geral, vem
sofrendo nos últimos anos.
Acontece que, para a informação estar disponível, há, muitas vezes, a necessidade de
integração entre diversas fontes. Mais que isso, as pessoas e organizações hoje, dados o
dinamismo e a heterogeneidade de fontes e dispositivos, inconscientemente, exigem algo
novo onde só é possível de ser alcançado mediante a integração de sistemas. Desta forma,
plataformas de middleware têm sido vista como uma alternativa para realizar a integração
de sistemas. Estas plataformas procuram abstrair os detalhes de negociação entre os sis-
temas participantes e por causa da necessidade de várias integrações, outras alternativas
de integração, que não dispõem de um middleware, podem ter seu nível de complexidade
aumentado para concluir o processo.
Em função disso, esta dissertação propôs o Mandala, uma plataforma de que visa a
integração de sistemas com base em SoS. O Mandala consegue realizar a integração de
sistemas, utilizando em seu desenvolvimento tecnologias como diagramas baseados em
notação BPMN, para modelar a missão global do SoS, e agentes de software para realizar
a interoperabilidade entre os sistemas participantes.
80
6.1 Contribuições
Em virtude de SoS não ser um conceito novo, curiosamente, esta área ainda é pouco
explorada no âmbito da Engenharia de Software. Por isso, é importante listar aqui as
contribuições que este trabalho está procurando trazer para a área:
• Estudo sobre um tema que, embora não seja muito jovem, é ainda muito pouco
explorado na área de Engenharia de Software. Diversos domínios e ideias são en-
contradas nas bases de dados, porém, por ser um tema que foi bastante utilizado
em áreas militares e em Secretarias de Defesa, principalmente nos Estados Unidos,
pouco se tem disponível de concreto sobre implementação.
• Antes de realizar o desenvolvimento do Mandala, muitas pesquisas foram realizadas
em busca de uma alternativa para realizar a integração de sistemas com base em
SoS. Este estudo motivacional gerou um artigo (LOPES et al., 2016) que ajudou a
delinear o caminho de acesso para o que hoje é o Mandala.
• Houve uma grande dificuldade em encontrar um produto que realizasse algo parecido
com o que Mandala se propôs a fazer. A produção do Mandala, neste aspecto,
foi algo, de certa forma, inovadora e, esta inovação, já traz consigo uma grande
contribuição para novos desenvolvimentos e estudos na área.
• Além do produto em si, a utilização de diversas tecnologias em conjunto também
pode ser considerada uma contribuição interessante e válida.
• Fornecimento de uma plataforma gratuita e que utiliza de tecnologias também gra-
tuitas em busca de uma solução para uma área que, segundo (VARGAS; GOTTARDI;
BRAGA, 2016) e corroborada pela pouca literatura recuperada sobre o assunto, ainda
cresce de forma lenta.
A seguir, algumas das limitações do trabalho serão apresentadas.
6.2 Limitações
Embora o esforço tenha sido muito grande para produzir a plataforma e muitos es-
tudos tenham sido realizados durante a fase de planejamento e execução do produto, o
Mandala ainda tem uma grande quantidade de limitações. Na lista a seguir, algumas
dessas limitações serão destacadas:
81
• Há quatro tipos de SoS, porém o Mandala integra apenas sistemas em um SoS do
modo diretivo.
• A ferramenta incorporada ao IDE Eclipse para realizar a modelagem das missões
globais do SoS possui os itens gráficos que servem para modelar o desenvolvimento
evolutivo dos sistemas constituintes em tempo de execução. Contudo, o Mandala
ainda não está utilizando estes itens gráficos porque necessita incorporar a proati-
vidade dos agentes, que não fez parte do escopo desta dissertação.
• O Mandala não disponibiliza interface gráfica para o desenvolvedor do SoS.
• A interface de envio das informações do sistema constituinte ao Mandala poderia
ser via Web, fazendo uso de um portal, que nesta versão do Mandala ainda não está
disponível.
• Algumas informações de uso do Mandala que são utilizadas para executar o sistema,
ainda estão amarradas no código e poderiam já estar automáticas. Um exemplo disso
é a publicação do serviço Web. Esta já poderia ser automática assim que o SoS fosse
criado, porém, necessita que o desenvolvedor do SoS execute o Container WEB, no
caso o TomCat, para realizar a publicação. Isto pode gerar algum esquecimento e o
serviço não ser publicado.
• Os testes executados não foram exaustivos nem objetivaram avaliar as características
de desempenho e carga da ferramenta. Pode ser que a plataforma tenha limitações
que não foram identificadas no estudo de caso avaliado.
• O estudo de caso não foi realizado com sistemas em produção, o que pode subestimar
algum tipo de dificuldade na integração.
• Como não foram feitas entrevistas com desenvolvedores para saber detalhes sobre
usabilidade e funcionalidade da plataforma, a análise pode ter vindo acompanhada
de um viés.
• Não fez parte do escopo deste trabalho algo relacionado à segurança dos dados
trafegados dentro do Mandala.
Após a visão das contribuições e limitações encontradas na plataforma, as próximas
seções deste capítulo apresentarão as ameaças encontradas e o que necessita ser trabalhado
futuramente para melhorar o Mandala.
82
6.3 Ameaças à validade
Como principal ameaça à validade do processo, pode-se citar o fato de os sistemas
desenvolvidos para participarem dos estudos de caso terem sido desenvolvidos pela mesma
pessoa que desenvolveu a plataforma Mandala.
Além disso, outro ponto que pode causar viés é o fato de os testes terem sido reali-
zados em um ambiente de rede local. Neste tipo de ambiente, dada a sua velocidade de
transmissão, uma eventual carga extra na comunicação entre os sistemas pode ser mas-
carada, gerando gargalos e atrapalhando o processo de comunicação quando utilizada em
uma rede WAN.
6.4 Trabalhos futuros
Muitos dos trabalhos futuros têm como base a melhoria das limitações apontadas na
seção anterior.
Um dos pontos que precisa ser melhorado na plataforma é a parte de interface gráfica.
É importante que um portal seja desenvolvido, permitindo que, através dele, os desenvol-
vedores possam enviar as informações do seu sistema à plataforma. O que tem na versão
atual do Mandala é uma interface gráfica, produzida em JAVA, que não permite editar
alguma informação que foi passada de forma errada. No portal, também seria possível
visualizar detalhes sobre os SoS publicados e ter acesso à documentação de acesso aos
serviços Web disponíveis.
No entanto, a parte mais importante que precisa ser trabalhada mais urgentemente
no Mandala, até para trazer novas funcionalidades, é a inserção da Inteligência Artificial,
com o uso da proatividade dos agentes. Toda a estrutura de gerenciamento dos agentes já
está pronta, porém comportamentos mais inteligentes precisam ser associados aos agentes
para que estes trabalhem, dentro da plataforma, com todo o seu potencial.
Por fim, destaca-se a necessidade de novos e mais detalhados testes para verificar
se o Mandala, de fato, consegue ser inserido em um ambiente de alta heterogeneidade e
dinamismo, como é o caso de uma cidade inteligente.
83
Referências
ABUKWAIK, H.; ROMBACH, D. Software interoperability analysis in practice: Asurvey. In: ACM. Proceedings of the 21st International Conference on Evaluation andAssessment in Software Engineering. [S.l.], 2017. p. 12–20.
AFOUTNI, Z. et al. Towards a proactive interoperability solution in systems ofinformation systems: A plm perspective. In: SPRINGER. IFIP International Conferenceon Product Lifecycle Management. [S.l.], 2017. p. 580–589.
ALDAMA-NALDA, A. et al. Smart cities and service integration initiatives in northamerican cities: A status report. In: ACM. Proceedings of the 13th Annual InternationalConference on Digital Government Research. [S.l.], 2012. p. 289–290.
BILLAUD, S.; DACLIN, N.; CHAPURLAT, V. Interoperability as a key concept forthe control and evolution of the system of systems (SoS). In: SINDEREN, M. van;CHAPURLAT, V. (Ed.). Proceedings of the 6th International IFIP Working Conferenceon Enterprise Interoperability (IWEI 2015). Germany: Springer Berlin Heidelberg, 2015,(Lecture Notes in Business Information Processing, v. 213). p. 53–63.
BROWNSWORD, L. et al. System-of-systems navigator: An approach for managingsystem-of-systems interoperability. [S.l.], 2006.
CARDOSO, G.; CASTELLS, M. Os media na sociedade em rede. [S.l.]: FundaçãoCalouste Gulbenkian, Serviço de Educação e Bolsas, 2006.
CARNEY, D.; ANDERSON, W.; PLACE, P. Topics in Interoperability: Concepts ofOwnership and Their Significance in Systems of Systems. [S.l.], 2005.
CAVALCANTE, E. et al. Challenges to the development of smart city systems: Asystem-of-systems view. In: ACM. Proceedings of the 31st Brazilian Symposium onSoftware Engineering. [S.l.], 2017. p. 244–249.
COLOMB, R. M. et al. The object management group ontology definition metamodel.In: Ontologies for Software Engineering and Software Technology. [S.l.: s.n.], 2006.
CURRY, E. System of systems information interoperability using a linked datas-pace. In: 7th International Conference on System of Systems Engineering, SoSE2012, Genova, Italy, July 16-19, 2012. [s.n.], 2012. p. 101–106. Disponível em:<https://doi.org/10.1109/SYSoSE.2012.6384200>.
FIRESMITH, D. Profiling systems using the defining characteristics of systems ofsystems (SoS) - Technical note: CMU. USA, 2010.
84
GAMA, K.; ALVARO, A.; PEIXOTO, E. Em direção a um modelo de maturidadetecnológica para cidades inteligentes. Simpósio Brasileiro de Sistemas de Informação,VIII, 2012.
GASSER, L. Distribution and coordination of tasks among intelligent agents. In: SCAI.[S.l.: s.n.], 1988. p. 189–204.
GENESERETH, M. R.; KETCHPEL, S. P. Software agents. Commun. ACM, v. 37, n. 7,p. 48–53, 1994. Disponível em: <http://doi.acm.org/10.1145/176789.176794>.
GIFFINGER, R.; GUDRUN, H. Smart cities ranking: an effective instrument for thepositioning of the cities? ACE: Architecture, City and Environment, Centre de Políticadel Sòl i Valoracions-Universitat Politècnica de Catalunya, v. 4, n. 12, p. 7–26, 2010.
HACHEM, J. E. et al. Model driven software security architecture of systems-of-systems.In: IEEE. Software Engineering Conference (APSEC), 2016 23rd Asia-Pacific. [S.l.],2016. p. 89–96.
HAYES-ROTH, B. An architecture for adaptive intelligent systems. Artif. Intell., v. 72,n. 1-2, p. 329–365, 1995. Disponível em: <https://doi.org/10.1016/0004-3702(94)00004-K>.
HERNÁNDEZ-MUÑOZ, J. M. et al. Smart cities at the forefront of the future internet.In: SPRINGER. The Future Internet Assembly. [S.l.], 2011. p. 447–462.
JADE. Java Agent DEvelopment Framework. Dec. 2015. Available at http://jade.tilab.com.
JENNINGS, N. R.; BUSSMANN, S. Agent-based control systems: Why are they suitedto engineering complex systems? IEEE control systems, IEEE, v. 23, n. 3, p. 61–73, 2003.
JENNINGS, N. R. et al. Automated negotiation: prospects, methods and challenges.Group Decision and Negotiation, Springer, v. 10, n. 2, p. 199–215, 2001.
JR., J. F. N.; CHEN, M.; PURDIN, T. D. Systems development in information systemsresearch. Journal of Management Information Systems, Routledge, v. 7, n. 3, p. 89–106,1990. Disponível em: <https://doi.org/10.1080/07421222.1990.11517898>.
KANTER, R. M.; LITOW, S. S. Informed and interconnected: A manifesto for smartercities. 2009.
KAZMAN, R. et al. Understanding patterns for system of systems integration. In: IEEE.System of Systems Engineering (SoSE), 2013 8th International Conference on. [S.l.],2013. p. 141–146.
KITCHENHAM, B.; PICKARD, L.; PFLEEGER, S. L. Case studies for method andtool evaluation. IEEE Software, v. 12, n. 4, p. 52–62, Jul. 1995.
KOBETSKI, A.; AXELSSON, J. Towards safe and secure systems of systems: challengesand opportunities. In: ACM. Proceedings of the Symposium on Applied Computing. [S.l.],2017. p. 1803–1806.
85
LIN, F. et al. Enabling effective and emergent agent conversations. In: Agents. [s.n.],2000. p. 233–234. Disponível em: <http://doi.acm.org/10.1145/336595.341992>.
LOPES, F. et al. SoS-centric middleware services for interoperability in smart citiessystems. In: Proceedings of the 2nd International Workshop on Smart Cities: People,Technology and Data (SmartCities’16). USA: ACM, 2016.
MADNI, A. M.; SIEVERS, M. Systems integration: Key perspectives, experiences, andchallenges. Systems Engineering, Wiley Online Library, v. 17, n. 1, p. 37–51, 2014.
MAIER, M. W. Architecting principles for systems-of-systems. Systems Engineering,v. 1, n. 4, p. 267–284, Feb. 1998.
MAJD, S.; MARIE-HÉLÈNE, A.; ALOK, M. An architectural model for system ofinformation systems. In: Ioana Ciuciu et al. (Ed.). On the Move to Meaningful InternetSystems: OTM 2015 Workshops. Switzerland: Springer International Publisher, 2015,(Lecture Notes in Computer Science, v. 9416). p. 411–420.
MORDECAI, Y.; DORI, D. 6.5. 1 i5: A model-based framework for architectingsystem-of-systems interoperability, interconnectivity, interfacing, integration, andinteraction. In: WILEY ONLINE LIBRARY. INCOSE International Symposium. [S.l.],2013. v. 23, n. 1, p. 1234–1255.
MOTTA, R. C.; OLIVEIRA, K. M. D.; TRAVASSOS, G. H. Rethinking interoperabilityin contemporary software systems. In: IEEE. Software Engineering for Systems-of-Systems and 11th Workshop on Distributed Software Development, Software Ecosystemsand Systems-of-Systems (JSOS), 2017 IEEE/ACM Joint 5th International Workshopon. [S.l.], 2017. p. 9–15.
NAKAGAWA, E. Y. et al. Software architecture and reference architecture ofsoftware-intensive systems and systems-of-systems: contributions to the state of theart. In: ACM. Proceedings of the 11th European Conference on Software Architecture:Companion Proceedings. [S.l.], 2017. p. 4–11.
NAKAGAWA, E. Y. et al. The state of the art and future perspectives in systemsof systems software architectures. In: ACM. Proceedings of the First InternationalWorkshop on Software Engineering for Systems-of-Systems. [S.l.], 2013. p. 13–20.
NAKAGAWA, E. Y. et al. Foreword: towards reference architectures for systems-of-systems. In: IEEE PRESS. Proceedings of the Third International Workshop on SoftwareEngineering for Systems-of-Systems. [S.l.], 2015. p. 1–4.
NAM, T.; PARDO, T. A. Conceptualizing smart city with dimensions of technology,people, and institutions. In: Proceedings of the 12th Annual International Conference onDigital Government Research, DG.O 2011, College Park, MD, USA, June 12 - 15, 2011.[s.n.], 2011. p. 282–291. Disponível em: <http://doi.acm.org/10.1145/2037556.2037602>.
NEGROPONTE, N. From being digital to digital beings. IBM Systems Journal, v. 39,n. 3&4, p. 417–418, 2000. Disponível em: <https://doi.org/10.1147/sj.393.0417>.
86
NETO, V. V. G. et al. On the interplay of business process modeling and missionsin systems-of-information systems. In: 2017 IEEE/ACM Joint 5th InternationalWorkshop on Software Engineering for Systems-of-Systems and 11th Workshop onDistributed Software Development, Software Ecosystems and Systems-of-Systems,JSOS@ICSE, Buenos Aires, Argentina, May 23, 2017. [s.n.], 2017. p. 72–73. Disponívelem: <http://doi.ieeecomputersociety.org/10.1109/JSOS.2017.7>.
NETO, V. V. G. et al. Investigating the model-driven development for systems-of-systems. In: ACM. Proceedings of the 2014 European Conference on software architectureworkshops. [S.l.], 2014. p. 22.
NIELSEN, C. B. et al. Systems of Systems Engineering: Basic concepts, model-basedtechniques, and research directions. ACM Computing Surveys, v. 48, n. 2, Nov. 2015.
NWANA, H. S. Software agents: an overview. Knowledge Eng. Review, v. 11, n. 3, p.205–244, 1996. Disponível em: <https://doi.org/10.1017/S026988890000789X>.
OMG. Business Process Model and Notation (BPMN), version 2.0. Jan. 2011. Availableat http://www.omg.org/spec/BPMN/2.0/.
PARSONS, S.; WOOLDRIDGE, M. Game theory and decision theory in multi-agentsystems. Autonomous Agents and Multi-Agent Systems, Springer, v. 5, n. 3, p. 243–254,2002.
ROBSON, C.; McCartan, K. Real world research. 4th. ed. Chichester, United Kingdom:John Wiley & Sons Ltd., 2016.
RUSSELL, S. J.; NORVIG, P. Artificial intelligence - a modern approach, 2nd Edition.Prentice Hall, 2003. (Prentice Hall series in artificial intelligence). ISBN 0130803022.Disponível em: <http://www.worldcat.org/oclc/314283679>.
SALEH, M.; ABEL, M.-H. Information systems: Towards a system of informationsystems. In: Proceedings of the 7th International Joint Conference on KnowledgeDiscovery, Knowledge Engineering and Knowledge Management (IC3K 2015). Portugal:Scitepress, 2015. p. 193–200.
SHAPIRO, R. et al. Bpmn 2.0 handbook. Future Strategies Inc, 2010.
SHOHAM, Y. Agent-oriented programming. Artif. Intell., v. 60, n. 1, p. 51–92, 1993.Disponível em: <https://doi.org/10.1016/0004-3702(93)90034-9>.
SILVA, E.; BATISTA, T.; OQUENDO, F. A mission-oriented approach for designingsystem-of-systems. In: IEEE. System of Systems Engineering Conference (SoSE), 201510th. [S.l.], 2015. p. 346–351.
SILVA, E. et al. On the characterization of missions of systems-of-systems. In: ACM.Proceedings of the 2014 European Conference on Software Architecture Workshops. [S.l.],2014. p. 26.
SYCARA, K. et al. Distributed intelligent agents. IEEE Expert, v. 11, n. 6, p. 36–46,Dec. 1996.
87
TEKINERDOGAN, B.; ERATA, F. Modeling traceability in system of systems. In:ACM. Proceedings of the Symposium on Applied Computing. [S.l.], 2017. p. 1799–1802.
VARGAS, I. G.; GOTTARDI, T.; BRAGA, R. T. V. Approaches for integrationin system of systems: a systematic review. In: Proceedings of the 4th InternationalWorkshop on Software Engineering for Systems-of-Systems, SESoS@ICSE 2016,Austin, Texas, USA, May 14-22, 2016. [s.n.], 2016. p. 32–38. Disponível em:<http://doi.acm.org/10.1145/2897829.2897835>.
WESKE, M. Business Process Management: Concepts, languages, architectures.Germany: Springer-Verlag Berlin Heidelberg, 2012.
WHITTINGTON, P.; DOGAN, H. Smartpowerchair: A pervasive system ofsystems. In: 10th System of Systems Engineering Conference, SoSE 2015, SanAntonio, TX, USA, May 17-20, 2015. [s.n.], 2015. p. 244–249. Disponível em:<https://doi.org/10.1109/SYSOSE.2015.7151932>.
WOHLIN, C. et al. Experimentation in software engineering. [S.l.]: Springer Science &Business Media, 2012.
WOOLDRIDGE, M.; JENNINGS, N. R. Intelligent agents: Theory and practice. Theknowledge engineering review, Cambridge University Press, v. 10, n. 2, p. 115–152, 1995.
YIN, R. K. Case study research and applications: Design and methods. 6th. ed. ThousandOaks, CA, USA: SAGE Publications, Inc., 2017.