Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Um Serviço de Especificação de Sistemas de
Sistemas no Contexto de Cidades Inteligentes
Stefano Momo Loss
Natal-RN Novembro de 2017
Um Serviço de Especificação de Sistemas de Sistemas
no Contexto de Cidades Inteligentes
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada (DIMAp) da Universidade Federal do Rio Grande do Norte como requisito par-cial para a obtenção do grau de bacharel em Engenharia de Software.
Orientador:
Prof. Dr. Frederico Araújo da Silva Lopes
DIMAp – Departamento de Informática e Matemática Aplicada CCET – Centro de Ciências Exatas e da Terra
UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Novembro de 2017
Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Loss, Stefano Momo.
Um Serviço de Especificação de Sistemas de Sistemas no Contexto de Cidades Inteligentes / Stefano Momo Loss. - Natal, 2017.
62f.: il.
Monografia (graduação) - Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Bacharelado em Engenharia de Software.
Orientador: Frederico Araújo da Silva Lopes.
1. Engenharia de software. 2. Interoperabilidade. 3. Sistemas de sistemas. 4. Cidades inteligentes. I. Lopes, Frederico Araújo da Silva. II. Título.
Aplicada (DIMAp) da Universidade Federal do Rio Grande do Norte como requisito par-cial para a obtenção do grau de bacharel em Engenharia de Software, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Dr. Frederico Araújo da Silva Lopes
Orientador
IMD – Instituto Metrópole Digital
UFRN – Universidade Federal do Rio Grande do Norte
Dr. Everton Ranielly de Sousa Cavalcante
Examinador
DIMAp –Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Dra. Thaís Vasconcelos Batista
Examinador
DIMAp – Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Dedico primeiramente a Deus que me deu forças para completar esta jornada. Dedico também, a minha mãe Sadolange Momo (in memorian), que com muito carinho, não mediu esforços para que eu chegasse até esta etapa de minha vida.
Agradeço primeiramente a Deus que permitiu que tudo isso se concretizasse, por ter me dado saúde e inteligência para superar todas as dificuldades e conseguir chegar onde hoje estou.
Aos meus amigos e familiares, especialmente meu irmão Gabriel Loss e a minhas tias Denise Momo e Mariangela Momo por estar sempre me apoiando e me ajudando em todos os momentos. Ao meu Pai Mario Loss, por confiar em mim e estar me apoiando os momentos da vida.
Agradeço também, meus colegas - ingressantes comigo em Bacharelado em Tecno-logia da Informação (BTI) em 2013 - que me ajudaram durante todo a graduação. Em particular, Thiago Soares, Julliana Caroline, Hiago Mayk, Sidemar Fideles, Ronnypetson Souza, Danilo Damaceno, João Medeiros, Lilian Rêgo, Cephas Barreto. Vocês foram muito importantes para eu chegar até aqui.
Aos meus professores, em especial meu orientador Frederico Lopes, pelo suporte, pelas suas correções e incentivos. Sem sua ajuda não teria terminado essa monografia. Por fim, agradeço aos companheiros do projeto que esse trabalho faz parte, pelos inúmeras tardes passadas nos laboratórios pesquisando e desenvolvendo novas soluções para cidades inteligentes.
Sozinhos, pouco podemos fazer; juntos, podemos fazer muito. Helen Keller
no Contexto de Cidades Inteligentes
Autor: Stefano Momo Loss Orientador: Prof. Dr. Frederico Araújo da Silva Lopes
Resumo
A partir da Revolução Industrial se intensificou o crescimento das cidades em todos os continentes do mundo e junto com o seu crescimento também surgiram vários problemas sociais. Alguns desses problemas podem ser minimizados por meio de sistemas de infor-mação. Porém, na contemporaneidade, o mais comum é que cada cidade possua sistemas computacionais criados com tecnologias diferentes e gerenciados de forma isolada para atender suas demandas - situações de trânsito, gerenciamento de hospitais, prestação de primeiros-socorros, coleta de lixo, entre outros. A não interoperação entre sistemas impos-sibilita, na maioria das vezes, a otimização e a eficiência dos serviços. Mais do que isso, se esses sistemas fosses integrados, essa união poderia trazer resultados antes inimaginá-veis, quando comparada aos resultados adquiridos por cada sistema isolado, sendo mais do que a mera soma dos sistemas envolvidos. Na Universidade Federal do Rio Grande do Norte, desde 2016 até os dias atuais, está sendo desenvolvida uma plataforma chamada Mandala, que é uma alternativa possível para a solução do problema apresentado porque ela abstrai a heterogeneidade dos sistemas legados e minimiza o trabalho dos desenvol-vedores responsáveis ao realizarem a integração e a interoperação com outros sistemas. Este trabalho tem como objetivo desenvolver um componente, constituinte da Mandala, que permita a especificação dos Sistemas de Sistemas (SoS) de modo a integrar sistemas utilizados na cidade com a mínima mudança dos códigos de tais sistemas constituintes. Após isso, realizou-se um experimento com sistemas simulados com a finalidade de testar a sua funcionalidade.
Palavras-chave: Interoperabilidade, Middleware, Sistemas de Sistemas, Cidades Inteligen-tes.
A System-of-Systems Specification Service in the
Context of Smart Cities
Author: Stefano Momo Loss Advisor: Dr. Frederico Araújo da Silva Lopes
Abstract
Since the Industrial Revolution, the growth of the cities in all continents of the world has intensified and with this growth also appeared several social problems. Some of these problems can be minimized through information systems. However, in contemporary ti-mes, each city has computer systems created with different technologies and managed in isolation to meet their demands - traffic congestion, hospital management, first aid care, garbage collection, among others. The noninteroperation of these systems makes it impossible, most times, to optimize and service efficiency. Furthermore, if these systems were integrated, this union could bring results previously unimaginable, when compared to the ones acquired by each system in isolation, being more than the sum of the systems involved. From 2016 to the present day, a platform called Mandala is being developed as a possible alternative for the solution of the presented problem because it abstracts away the heterogeneity of legacy systems and minimizes the work of the responsible ones in accomplishing integration and interoperability with other systems. This work aims to develop a component, constituent of Mandala, that allows specifying of Systems Systems (SoS) to integrate systems used in the city with minimum code change of such constitu-ent systems. Afterwards, an experimconstitu-ent with fictitious systems was performed to test its functionality.
1 Domínios de uma cidade inteligente . . . p. 21 2 Ciclo de vida de um SoS . . . p. 24 3 Novas funcionalidades provenientes da integração dos sistemas . . . p. 25 4 Níveis de Interoperabilidade . . . p. 27 5 Características da Interoperabilidade . . . p. 28 6 Fluxo da missão global Resgate Eficiente . . . p. 32 7 Fragmento de código XML gerado pelo BPD da Figura 6 . . . p. 33 8 Execução do ciclo de vida . . . p. 39 9 Arquitetura do Mandala . . . p. 41 10 Tela do Sniffer com as trocas de mensagens entre os agentes . . . p. 43 11 Diagrama de Relacionamento do Banco de Dados do SoS Manager. . . p. 44 12 Dados armazenados em cada um dos repositórios. . . p. 45 13 Arquitetura do Mandala . . . p. 46 14 Tela de Cadastro de um novo Sistema ao SoS . . . p. 47 15 Diagrama de criação do SoS . . . p. 48 16 Tela de configuração do Palette. . . p. 50 17 XML com as informações dos sistemas cadastrados. . . p. 51 18 Plugin BPMN2 Modeler 1.4.1 após as configuração do Palette. . . p. 51 19 Fragmento de código da comunicação do SoS Composer com SoS
Mana-ger. . . p. 52 20 Fluxo da missão Geração de Rotas Otimizadas em BPD. . . p. 54
21 Tempo de resposta médio (em segundos) observado para diferentes
con-figurações em termos de número de requisições e threads . . . p. 55 22 Troca de mensagens pelos agentes Jade ao executar missão Geração de
Lista de abreviaturas e siglas
ACL - Agent Communication Language API – Application Programming Interface BPD - Busines Process Diagram
BPMN - Busines Process Model Notation CI – Cidade Inteligente
DOM – Document Object Model
FIPA – Foundation for Intelligent, Phisical Agents IoT - Internet das Coisas
JADE – Java Agent Development Framework JSON - JavaScript Object Notation
ONU – Organização das Nações Unidas REST - Representational State Transfer SoS – Sistemas de Sistemas
SoIS - Sistemas de Sistemas de Informação TIC – Tecnologias de Informação e Comunicação
1 Introdução p. 15 1.1 O problema . . . p. 17 1.2 Objetivos . . . p. 17 1.2.1 Objetivo Geral . . . p. 17 1.2.2 Objetivos Específicos . . . p. 18 1.3 Contribuições . . . p. 18 1.4 Metodologia . . . p. 18 1.5 Organização do Trabalho . . . p. 19 2 Referencial Teórico p. 20
2.1 Tecnologias da Informação e Comunicação . . . p. 20 2.2 Cidades Inteligentes . . . p. 20 2.3 Sistemas de Sistemas . . . p. 23 2.3.1 Características do SoS . . . p. 24 2.4 Interoperabilidade . . . p. 26 2.4.1 Desafios da interoperabilidade em SoS . . . p. 29 2.5 Uso de Sistemas de Sistemas em Cidades Inteligentes . . . p. 30 2.6 Processos de Negócio . . . p. 30 2.7 Agentes de Software . . . p. 34 2.7.1 Interação entre Agentes . . . p. 36 2.7.2 JADE - Java Agent Development Framework . . . p. 37 2.7.3 Ciclo de Vida de um Agente JADE . . . p. 38
3 Mandala p. 40 3.1 Componentes . . . p. 40 3.2 Comunicação entre os componentes . . . p. 42 3.3 Repositórios . . . p. 44 3.4 Execução de uma Missão do SoS criado pelo Mandala . . . p. 45
4 SoS Composer p. 47
4.1 Processo de cadastro de um sistema na Mandala . . . p. 47 4.2 Processo de criação de um SoS . . . p. 48 4.3 Implementação do SoS Composer . . . p. 49
5 Experimentos e Resultados p. 53
6 Trabalhos Relacionados p. 57
7 Considerações Finais p. 59
1
Introdução
A partir da Revolução Industrial se intensificou o crescimento das cidades em to-dos os continentes do mundo. Segundo o relatório World Urbanization Prospects1 (2014), produzido pela Divisão da Organização das Nações Unidas (ONU) para a População do Departamento dos Assuntos Econômicos e Sociais, 54% da população mundial em 2014 vivia em áreas urbanas e estima-se que essa proporção, em 2050, passará para 66% da população mundial vivendo em cidades.
Esse crescimento, na maioria das vezes, ocorre de forma desordenada, causando vários problemas sociais, tais como: violência, poluição ambiental, insuficiência no atendimento hospitalar, enchentes, congestionamentos, redução da qualidade na prestação de serviços públicos (WENGE et al., 2014). É dever do poder público a criação de políticas que estimu-lem o crescimento ordenado das cidades de forma inovadora, garantindo serviços públicos e qualidade de vida para toda a população (BOYKO et al., 2006).
No entanto, percebe-se que os recursos públicos existentes não estão sendo suficientes ou não estão sendo empregados corretamente para atender à crescente população urbana, tornando os serviços básicos oferecidos pelo governo cada vez mais precários. Por outro lado, com o avanço da tecnologia, é cada vez mais comum as grandes cidades buscarem a utilização das Tecnologias de Informação e Comunicação (TIC). Essas tecnologias podem ser utilizadas como soluções computacionais para tornar as cidades lugares mais sustentá-veis, agradásustentá-veis, eficientes e capazes de prover serviços públicos de qualidade de maneira eficiente, barata e rápida dando origem ao termo Cidades Inteligentes (CI). Uma cidade inteligente (CI) integra as infraestruturas físicas da cidade com a tecnologia da informação e comunicação, com objetivo de melhorar a qualidade de vida da população (KANTER; LITOW, 2009).
Grande parte dos serviços públicos das metrópoles já utilizam algum sistema de infor-mação e gestão para armazenar seus dados e, em alguns casos, apresentá-los à população.
16
Porém, tais sistemas geralmente são desenvolvidos por empresas privadas e comprados pela gestão pública. Ao mesmo tempo, há órgãos públicos que produzem seus sistemas, mas muitas vezes utilizando tecnologias e conceitos que atualmente são considerados ul-trapassados. Porém, tanto os sistemas desenvolvidos pelas empresas privadas quanto os desenvolvidos pelos órgãos públicos, na maioria das vezes, são projetados de forma iso-lada e sem padronização, o que dificulta a comunicação com outros sistemas de forma interoperável.
Interoperabilidade entre sistemas é a capacidade de um conjunto de sistemas se co-municarem para compartilhar informações específicas e executar missões globais em um determinado contexto. Se os sistemas de uma mesma cidade fossem integrados, provendo interoperabilidade entre eles, poderiam ser melhor aproveitados possibilitando o surgi-mento de novas funcionalidades. Por exemplo, suponha que uma Cidade Inteligente possua os seguintes sistemas:
1. RotasRápidas - sistema desenvolvido e mantido por uma empresa privada que auxilia no trânsito, informando a melhor rota levando em conta o tráfego em tempo real. 2. ResgateJá- sistema com tecnologias ultrapassadas, desenvolvido pela Secretaria de
Saúde de uma cidade. É utilizado para gerenciar o Serviço de Atendimento Médico de Urgência (SAMU) dessa cidade. É através dele que se solicita o resgate, informando o endereço do acidente.
3. MedSaúde - sistema Web sem integração, desenvolvido e mantido por uma empresa privada para uma rede pública de hospitais de uma cidade. Com ele é possível saber a disponibilidade da UTI e dos leitos de cada um dos hospitais.
Cada um desses três sistemas funciona de modo isolado e independente. Como não há interoperação, benefícios como um resgate mais eficiente acabam não acontecendo. Se houvesse interoperação dos sistemas essa eficiência seria possível. Por exemplo, ao ser solicitado resgate em uma determinada localidade pelo ResgateJá, criar-se-ia a melhor rota até o acidente utilizando o RotasRápidas. Após o atendimento no local do acidente o socorrista faria o diagnóstico inicial e buscaria a disponibilidade do atendimento hospitalar mais adequado considerando o diagnóstico do paciente e a disponibilidade de leito ou UTI e o tempo de deslocamento até o hospital, com base nos dados fornecidos pelo MedSaúde e RotasRápidas respectivamente.
Essa agregação de sistemas heterogêneos - desenvolvidos e gerenciados de formas dife-rentes, operando de forma independente - com objetivo de realizar um propósito comum
é chamado de Sistemas de Sistemas (SoS). Essa integração também pode gerar novas funcionalidade que não poderia ser provida por nenhum sistema de forma isolada.
1.1
O problema
Existem muitas formas de integrar sistemas, sendo que, na maioria das vezes, isto é feito de forma ad hoc para atender a uma determinada necessidade do cliente. Para isso, é necessário conhecer os detalhes de implementação dos sistemas candidatos à integração porque é necessário alterar e adicionar partes de código desses sistemas uma vez que o desenvolvedor da plataforma não teria acesso aos códigos dos sistemas. O problema de integrar os sistemas de informação de uma cidade é que cada um deles é construído, na maioria das vezes, utilizando-se tecnologias diferentes e com arquitetura sem prever integração com outro sistema. Assim, a complexidade de integração aumenta com a quan-tidade de sistemas a serem integrados.
Considerando esse problema, a proposta esse trabalho é parte de um projeto que está desenvolvendo a Mandala, plataforma de middleware que é uma alternativa possível para a solução do problema apresentado uma vez que a mesma abstrai a heterogeneidade de sistemas legados e minimiza o trabalho dos responsáveis pelos sistemas em realizar a integração e a interoperação com outros sistemas. Uma vez que, os sistemas das cidades são gerenciados por entidades diferentes, podendo estar geograficamente localizados em diferentes servidores sem nenhuma forma de integração com outros sistemas.
Em outras palavras, a plataforma pretende possibilitar que os sistemas existentes nas cidades sejam interligados mantendo ao máximo a implementação original desses sistemas. Dessa forma, ao construir a plataforma Mandala, tem-se como pergunta de pesquisa: Como especificar a integração dos sistemas de uma cidade de forma a causar o mínimo de mudança nos códigos desses sistemas?
1.2
Objetivos
1.2.1
Objetivo Geral
O objetivo geral deste trabalho desenvolver um componente, constituinte da Mandala, que permita especificar a integração dos sistemas existentes em uma cidade, abstraindo a sua heterogeneidade e possibilitando a integração deles de modo a formar um Sistemas
18
de Sistemas com o mínimo de mudança em sua implementação.
1.2.2
Objetivos Específicos
Para atingir o objetivo geral, são necessários os seguintes objetivos específicos:
• Desenvolver uma solução para criar um modelo dos sistemas de uma cidade para ser cadastrado na plataforma Mandala;
• Desenvolver uma solução para descrever as informações relacionadas aos SoS, pos-sibilitando a integração entre vários sistemas.
• Transformar as especificações cadastradas na plataforma em dados a serem execu-tadas posteriormente pelos outros componentes da plataforma Mandala.
• Tornar o processo de criação do SoS viável para o desenvolvedor de Sistemas de Sistemas.
1.3
Contribuições
As principais contribuições deste trabalho, a saber:
• a concepção, o desenvolvimento e implantação uma ferramenta projetada especial-mente para ser utilizada pelo desenvolvedor do SoS com a finalidade de cadastrar na plataforma Mandala as informações relacionadas aos SoS, possibilitando a inte-gração entre vários sistemas utilizando Notação e Modelo de Processo de Negócio; • utilização do Diagrama de Processo de Negócio, gerado pela ferramenta descrita
acima, para orquestrar a execução da missão do SoS pela plataforma Mandala.
1.4
Metodologia
Visando atingir os objetivos propostos, adotou-se um conjunto de procedimentos me-todológicos. Um desses procedimentos considerados fundamentais foi a realização de pes-quisa bibliográfica. Para essa pespes-quisa, foi utilizado como descritores os seguintes termos: Interoperabilidade, Middleware, Sistemas de Sistemas, Cidades Inteligentes, Criação de
Sistemas de Sistemas. Foi verificado que não existiam muitos artigos relacionados a ques-tão de pesquisa e aos objetivos dessa monografia o que evidencia a importância dessa pesquisa para a criação de Sistemas de Sistemas.
Após esses estudos, foi discutida e definida a arquitetura para a plataforma como um todo. Dividiu-se a plataforma em quatro componentes (descritos na Seção 3): 1) SoS Composer; 2) SoS Manager; 3) SoS Server e 4) Broker. Constatou-se a necessidade de realização de estudos e pesquisas para a implementação de cada componente. No caso, esta pesquisa monográfica ficou responsável pelo componente SoS Composer.
Para a criação do SoS Composer desenvolveu-se uma ferramenta, descrita no Capi-tulo 3. Ao mesmo tempo, este componente foi implementado na plataforma Mandala em sintonia com os demais componentes, conforme demonstrado na Seção 4.3.
Quando o componente estava pronto, realizou-se um experimento com sistemas fictí-cios com a finalidade de validar a utilização da especificação de uma missão global criada por esse componente na orquestração dos sistemas durante a execução dessa missão global, conforme exemplificado no Capítulo 5.
1.5
Organização do Trabalho
O restante deste trabalho está organizado da seguinte forma: Capítulo 2 apresenta o referencial teórico necessário para o bom entendimento desse trabalho. Já no Capítulo 3 contém a descrição da plataforma Mandala, bem como o processo de execução da mesma. Seção 4 apresenta os detalhes do SoS Composer e detalhes da sua implementação. O Capítulo 5 apresenta o experimento realizado e os resultados alcançados com o componente desenvolvido. O Capítulo 6 apresenta alguns trabalhos que possuem forte relacionamento com o que será proposto por esse trabalho. Por fim, Capítulo 7 traz algumas considerações finais e projeções futuras para o componente SoS Composer apresentado neste trabalho.
20
2
Referencial Teórico
Nesse capítulo serão apresentados e definidos os conceitos e tecnologias utilizados na elaboração desse trabalho com base no referencial teórico selecionado.
2.1
Tecnologias da Informação e Comunicação
Segundo Takahashi (2000, p. 176), as TICs são “Tecnologias utilizadas para trata-mento, organização e disseminação de informações”. Também podem ser definidos como uma integração de hardware e software com o objetivo de facilitar a troca de informações (dados) entre as pessoas.
Nas últimas décadas, as TICs tiveram uma evolução exponencial, as pessoas passaram a ter acesso cada vez mais rápido às novas tecnologias. Com essa popularização, junta-mente com o surgimento da Internet, novos sistemas de comunicação e informação foram criados, formando uma verdadeira rede de comunicação. Criações como o e-mail, redes sociais, conferências por vídeos e/ou áudio, revolucionaram a forma de comunicação entre os seres humanos.
A Internet também contribuiu para a disseminação da tecnologia de sensores e atua-dores, possibilitando a comunicação entre esses dispositivos eletrônicos, dando origem ao termo Internet das Coisas (IoT, do inglês Internet of Things).
2.2
Cidades Inteligentes
Para Kanter e Litow (2009) uma cidade inteligente (CI) integra as infraestruturas físi-cas da cidade com a tecnologia da informação e comunicação, com objetivo de melhorar a qualidade de vida da população, a mobilidade urbana e a gestão governamental, economi-zando energia, melhorando a qualidade do ar e da água, identificando problemas urbanos, coletando dados para tomar melhores decisões e corrigi-los rapidamente, entre outros.
Porém, apenas integrar inteligência em cada serviço público de uma cidade (transporte, energia, educação, cuidados de saúde, edifícios, infra-estrutura física, alimentos, água, se-gurança pública) de forma isolada não é suficiente para se ter uma cidade inteligente. Uma cidade inteligente deve ser vista como um organismo complexo, como uma rede composta por serviços integrados e interoperáveis. Em uma cidade inteligente, a atenção deve ser dada também às conexões e não apenas às partes. A melhoria nas cidades decorre da in-tegração apropriada das partes que a compõem tornando-a uma cidade inteligente focada em melhorar a qualidade de vida da população.
Sendo assim, as TICs podem ser o elo integrador entre os serviços de uma cidade inteligente, conforme exemplificado na Figura 1. São elas que podem prover maior inte-ligência na gestão de cidades (NAM; PARDO, 2011) gerando economicidade, eficiência e melhorando a qualidade de vida.
Figura 1: Domínios de uma cidade inteligente Fonte: Própria (2017)
Embora haja obrigatoriedade da presença das TICs em cidades inteligentes, Nam e Pardo (2011) relatam que a presença de componentes digitais não garante a inteligência para uma cidade. Uma cidade digital, que utiliza tecnologias de comunicação e promove o acesso amplo a ferramentas, conteúdos e sistemas de gestão, de forma a atender às necessidades do poder público e de seus servidores, de seus cidadãos e das organizações, não necessariamente é uma cidade inteligente.
22
A visão de inteligência das cidades vem da integração entre a sociedade e a cidade digital. Na integração da sociedade, a informação e a criatividade têm grande importância e considera-se os capitais humanos e sociais como seus bens mais valiosos (CARDOSO; CASTELLS, 2006). Já na cidade digital se faz uso de sistemas de telecomunicações e recursos da Internet como meio para transformar significativamente as formas de relacionamento e de vida da população (KANTER; LITOW, 2009)(NAM; PARDO, 2011).
Ao mesmo tempo não existe uma única maneira de se existir uma cidade inteligente, isso porque os problemas das cidades podem ser variados e as formas de solução também. Por exemplo, o trânsito pode ser um grande problema para uma cidade muito populosa e nem tanto para outras cidades. Dessa forma, dependendo do investimento o uso das TICs pode ser ou não mais presente em algumas cidades. Gama, Alvaro e Peixoto (2012) criam um modelo de maturidade tecnológica para graduar as cidades com base na integração de dispositivos (conceituais e físicos) variados. São cinco os níveis de maturidade definidos por eles:
0 - Caótico: fase de inicio da maioria das cidades, na qual as cidades não utilizam TICs para auxiliar no seu 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 inteligentes. 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. Apresenta utilização intensiva de computação ubíqua e autonômica. O governo pode funcionar como facilitador da cidade inteligentes e fomentador de um ecossistema de serviços.
4 - Otimizado: cidade mais eficiente, buscando inovar e ser pioneira nas soluções de TICs. Utilização de dados obtidos dos diversos domínios da cidade como apoio à tomada de decisão tanto para a população quanto para os governantes.
Observando os níveis descritos pelos autores, pode-se afirmar 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 já caracterizam uma cidade como inteligente. Nesse caso, o que diferencia uma cidade digital de uma cidade inteligente é que na primeira as TICs existem para coletar e armazenar dados, enquanto que na segundo o uso das TICs tem como objetivo a melhoria dos problemas da sociedade. Ao mesmo tempo, para existir uma cidade inteligente é necessária uma cidade digital visando alcançar um nível mais elevado de qualidade de vida, governança e desenvolvimento sustentável, já não é fácil de ser executado sem a ajuda de um elemento importantíssimo como as TICs.
Na verdade, não se pode apenas pensar em inteligência em uma cidade analisando dados de sensores, como se estes fossem as únicas fontes de dados para cidades inteligen-tes. A grande maioria das cidades mantém uma gama de serviços antigos em sistemas de informação com um potencial enorme para uma decisão estratégica que podem ser utilizados na efetivação da cidade inteligente. Assim, ao se unir os sistemas legados com os recém-implantados, melhora-se a capacidade de inovação aliada à prestação de servi-ços e criatividade de novas aplicações. Uma forma de integrar esses sistemas - legados e recém-implantados - é por meio da criação de Sistemas de Sistemas.
2.3
Sistemas de Sistemas
Sistemas de Sistemas (SoS, do inglês System-of-systems) pode ser definido como um conjunto de sistemas constituintes heterogêneos e independentes que interoperam a fim de realizar uma missão global comum (BILLAUD; DACLIN; CHAPURLAT, 2015), (KAZMAN et al., 2013). Tanto sistemas tradicionais quanto SoS são sistemas cujos constituintes são organizados a fim de prover funcionalidades e satisfazer missões.
As missões de SoS normalmente são vistas como características ou um conjunto de tarefas a serem realizadas pelos sistemas constituintes (SILVA et al., 2014). Tais missões são categorizadas em dois tipos: missões individuais e missões globais. Considerando que, em um SoS, cada sistema constituinte é independente de qualquer outro sistema, as missões individuais referem-se aos recursos ou tarefas executadas por cada sistema constituinte iso-lado. Estas missões estão relacionadas a um sistema constituinte específico. Por sua vez, as missões globais estão relacionadas a novos recursos e/ou funcionalidades alcançados pela integração dos sistemas constituintes de um SoS. As missões globais são dependen-tes de um conjunto de sistemas constituindependen-tes e não é possível realizá-las considerando a contribuição de apenas um único sistema constituinte.
24
2, (que se encerra quando a missão global é concluida) e pode conter vários sistemas cons-tituintes (inclusive outros SoS), que, por sua vez, podem constituir novos SoS. Contudo, SoS distinguem-se de outros sistemas 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, descritas nas seções subsequentes deste texto, que tornam SoS dife-rentes dos sistemas tradicionais e, portanto, fazem com que seja necessária uma mudança de paradigma para desenvolvimento desses sistemas.
Figura 2: Ciclo de vida de um SoS Fonte: Própria (2017)
2.3.1
Características do SoS
Abaixo é descrito as principais características do SoS considerando as proposições de Nielsen et al. (2015).
Independência operacional dos sistemas constituintes. Sistemas constituintes de um SoS são operacionalmente independentes, executando 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 desenvolvidos por diferentes organizações, com seus próprios stakeholders, equipes de desenvolvimento, processos e recursos, além de apresentarem ciclo de vida próprio e possuírem autonomia para gerenciar seus próprios recursos.
Distribuição geográfica dos sistemas constituintes. Esta característica refere-se à distribuição dos sistemas constituintes, de modo que algum tipo de conectividade precisa ser estabelecida para permitir comunicação e troca entre eles (NIELSEN et al., 2015). Dessa forma, sistemas constituintes estão fisicamente desacoplados e trocam apenas informação entre eles.
Desenvolvimento evolucionário do SoS. Um SoS pode continuamente evoluir como resposta a mudanças, sejam elas relacionadas ao ambiente, aos seus sistemas consti-tuintes ou a suas funções e propósitos. Como consequência de sua independência gerencial, sistemas constituintes podem evoluir por conta própria e sem o controle do SoS, que deve por sua vez absorver tais mudanças e minimizar possíveis efeitos indesejados.
Comportamentos emergentes no SoS. Em sistemas tradicionais, o comporta-mento e as interações de seus componentes são geralmente previsíveis e controláveis da perspectiva do sistema. Entretanto, mesmo que os sistemas constituintes de um SoS pos-sam ser previsíveis, sua independência 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, como mostrado na Figura 3.
Figura 3: Novas funcionalidades provenientes da integração dos sistemas Fonte: Própria(2017)
De maneira particular, um Sistemas de Sistemas de Informação (SoIS) é formado, em sua maioria, por sistemas de informação pertencentes a diferentes organizações que cola-boram para prover novas funcionalidades, tecnologias e oportunidades de negócio. Além das cinco características típicas de qualquer SoS anteriormente descritas, três caracte-rísticas são específicas para SoIS, a saber: 1) a existência de fluxos de informação entre os sistemas constituintes; 2) uma forte natureza orientada a processo de negócio e 3) a criação de informação e valor agregado a partir da interoperabilidade entre sistemas de informação e suas respectivas organizações que não é possível obter se seus constituin-tes operam isoladamente. Nessa perspectiva, pode-se dizer que SoIS ampliam o escopo de SoS no sentido de que atravessam fronteiras organizacionais, envolvendo muitas vezes
26
sistemas de informação constituintes de diferentes domínios e gerando grande quantidade de informação (MAJD; MARIE-HÉLÈNE; ALOK, 2015) (SALEH; ABEL, 2015).
2.4
Interoperabilidade
Interoperabilidade entre sistemas é a capacidade de um conjunto de sistemas se co-municarem para compartilhar informações específicas e executar missões globais em um determinado contexto.
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 enti-dades comunicantes tem 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).
De acordo com C4ISR Interoperability Working Group (1998) é possível classificar o grau de interoperabilidade entre os sistemas de acordo com a Figura 4, nela é apresentado cinco níveis de interoperabilidade: 1) Isolado - Sem nenhum tipo de conexão; 2) Conectado Conexão eletrônica, sem compartilhamento de dados e aplicações; 3) Funcional -Comunicação miníma de funções, sem compartilhamento de dados e aplicações ; 4) Do-mínio - Compartilhamento de dados; 5) Empreendimento - Compartilhamento de dados e informações;
Somente quando a interoperabilidade entre sistemas atingir o ultimo nível (Empreen-dimento), no qual é possível ter interação simultânea de dados com colaboração simultânea e distribuição global de informação e aplicações, teremos de fato um Sistemas de Sistemas. Segundo Mordecai e Dori (2013), a interoperabilidade pode ser definida como a ca-pacidade de organizações e usuários utilizarem 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 informações.
Fica evidente, com base nas definições de interoperabilidade citadas anteriormente
Figura 4: Níveis de Interoperabilidade
Fonte: C4ISR Interoperability Working Group (1998)
que, embora algumas sejam mais genéricas que outras, o ponto principal abordado é a troca de informações, mas apenas a comunicação entre as entidades não é suficiente. A interoperabilidade vai muito além da troca de mensagens, é necessário, conforme a Figura 5, se preocupar com o hardware, com o a semântica das mensagens e com a integração dos sistemas. Uma vez que 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 entre entidades, neste caso, pode ter como escopo a comuni-cação entre pessoas, sistemas computacionais ou a mistura de ambos (BROWNSWORD et al., 2006).
Carney, Anderson e Place (2005) tratam 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 relaciona-mentos de interoperabilidade envolvem, necessariamente, a comunicação. Uma relação de proximidade, no entanto, não implica em comunicação e, por conseguinte, interopera-ção. Fazendo uma analogia ao mundo físico, uma pessoa pode estar próxima de outra e
28
Figura 5: Características da Interoperabilidade Fonte: Própria (2017)
não se comunicar, assim como um sistema pode estar na mesma máquina que outro e a comunicação ser inexistente.
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. 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.
Visando ultrapassar essas barreias, a interoperabilidade pode ser alcançada de duas maneiras de acordo com Madni e Sievers (2014): 1) sistemas podem incluir nativamente questões relacionadas a interoperabilidade em seus projetos; ou 2) sistemas podem ser adaptados. A primeira opção é mais fácil e menos custosa. Entretanto, considerando que sistemas de cidades inteligentes são sistemas proprietários e que muitas vezes são gerencia-dos por organizações distintas, eles são desenvolvigerencia-dos 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: 1) afeta muitos aspectos dos sistemas existentes (por exemplo: API externa, interface do usuário, uso de padrões e protocolos de comunicação); e 2) 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.4.1
Desafios da interoperabilidade em SoS
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 con-cepção e deve seguir 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.
Motta, Oliveira e Travassos (2017) fazem uma revisão na literatura para compreender o impacto da evolução da interoperabilidade e sua influência na construção de sistemas de software contemporâneos. Também mostra as características da interoperabilidade que devem ser pensadas desde a fase de concepção do software.
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 ambiente 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 participante.
30
2.5
Uso de Sistemas de Sistemas em Cidades
Inteligen-tes
Embora o conceito de SoS não seja recente, a sua aplicação, de forma prática, ainda é incipiente, em especial no contexto de cidades inteligentes. Vargas, Gottardi e Braga (2016) relatam em sua revisão sistemática o lento amadurecimento desta área em comparação a outros campos da Engenharia de Software.
Devido as características dos sistemas de informação de uma Cidade Inteligente - alta heterogeneidade, distribuídos geograficamente, independentes, desenvolvidos utilizando diferentes tecnologias, entre outras - é muito difícil integrar esses sistemas de forma esca-lável, uma vez que, complexidade de integração aumenta proporcionalmente a quantidade de sistemas a serem integrados, sendo necessário conhecer os detalhes de implementação desses sistemas.
Por esse motivo, o uso de Sistemas de Sistemas para a integração de sistemas no âmbito de Cidades Inteligentes é importante pois garante a interoperabilidade entre os sistemas existentes e ainda preserva suas independências operacional e gerencial (Vide características do SoS na Seção 2.3.1).
2.6
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 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 a Notação e Modelagem de Processos de Negócio, do inglês Business Process Mo-del and Notation (BPMN), para complementar a especificação de missões desse tipo de sistema, permitindo uma melhor compreensão da sua natureza orientada a negócio em termos de atividades e os relacionamentos entre elas (WESKE, 2012).
O BPMN pode representar os processos de negócio, sendo definido como uma notação de modelagem especialmente voltada para a especificação, em alto nível, da análise do domínio na forma de um processo de negócio (OMG, 2011). O principal objetivo do BPMN é dar suporte ao gerenciamento de processos de negócio, fornecendo uma notação intuitiva capaz de representar a semântica complexa do processo como um todo e facilitando o
entendimento de todas as partes interessadas no negócio.
A modelagem do processo representa uma abstração do caminho do que se pretende percorrer para a realização das atividades, fazendo com que todos os envolvidos tenham a mesma visão geral. A ideia é distinguir todos os processos realizados, bem como os participantes que a executam, recursos utilizados e produzidos e informações relacionadas. No caso específico do SoIS, cuja orientação do fluxo é orientada pelo processo de negócio, uma representação deste tipo faz com que se consiga visualizar a sequência correta e a responsabilidade de cada sistema dentro do processo.
Para modelar um processo de negócio, a BPMN define um Diagrama de Processos de Negócio (BPD) que utiliza um conjunto de elementos gráficos divididos em quatro categorias (SHAPIRO et al., 2010):
1. objetos de fluxo - são os elementos principais da notação. Podem ser: 1) Even-tos (representado por um círculo), é algum fator externo que acontece durante o processo de execução; 2) Atividades (representado por um retângulo com vértice arredondado), é uma generalização das tarefas a serem realizadas, 3) Gateway (re-presentado por um losango), é usado para controlar a divergência e a convergência de atividades durante o fluxo de execução;
2. objetos de conexão - servem para conectar os objetos de fluxo, com os seguintes tipos: 1) Fluxo de Sequência (representado por uma linha contínua com uma seta preenchida), é usado para mostrar a ordem que as atividades serão executadas em um processo; 2) Fluxo de Mensagem (representado por uma linha tracejada com uma seta vazada), é usado para mostrar a troca de mensagens entre dois processos participantes separados; 3) Associação (ilustrado por uma linha pontilhada com uma seta de ponta aberta), é usado para mostrar as entradas e saídas de atividades. 3. raias (swimlanes) - mecanismo para organizar visualmente as atividades em
di-ferentes categorias ou responsabilidades. Os dois tipos de Swimlanes são: 1) Piscina (ilustrado por um retângulo que contém os demais elementos), representa um par-ticipante em um processo; 2) Raias (representado como um conjunto de retângulos perfilados que contém os demais elementos), é uma subpartição usada para organizar e categorizar atividades; e,
4. artefatos - agregam informações adicionais sobre o processo. Podem ser: 1) Objeto de Dados (representado por um ícone de uma folha de papel), usado para mostrar como um dado é produzido ou requerido por uma atividade; 2) Grupo (representado
32
como um retângulo com vértice arredondado e com linhas tracejadas), usado para agrupar elementos facilitando na documentação; 3) Anotações, usado para adicionar descrição ou comentário a algum elemento ou grupo.
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 eX-tensible Markup Language (XML). Com esse XML gerado, é possível utilizar o BPMN como um orquestrador durante a execução de um sistema qualquer.
Figura 6: Fluxo da missão global Resgate Eficiente Fonte: Própria (2017)
A Figura 6 ilustra um BPD referente à missão global da possível integração dos sis-temas ResgateJá, RotasRápidas e MedSaúde, descritos na Introdução deste trabalho, 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 Usuário ao utilizar o serviço oferecido pela integração dos sistemas após a formação do SoS. As demais raias são representadas por sistemas constituintes (ResgateJá, RotasRápidas e MedSaúde) 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.
Figura 7: Fragmento de código XML gerado pelo BPD da Figura 6 Fonte: Própria (2017)
mostrado na Figura 6 que contém algumas tags de identificação de execução do fluxo. A tag lane, por exemplo, que começa nas linhas 6 e termina na linha 9 da Figura 7, descreve uma raia que representa, nesse caso, o sistema ResgateJá, vide tag name na linha 6 dessa figura. Essa tag serve para identificar as tarefas executadas por cada sistema. Por exemplo, as tarefas do sistema ResgateJá são descritas pela tag flowNodeRef, nesse caso, ScriptTask_3 e ScriptTask_6, vide linha 7 e 8 da Figura 7. O parâmetro name difere cada lane existente no diagrama e ajuda a dar uma melhor visualização de todo o processo.
Outra tag importante é sequenceFlow, que mostra os fluxos de sequencia. Dentro dela, é informado o a origem e o destino do fluxo de sequencia, conforme pode ser visto na linha 23 a 29 da Figura 7, onde cada uma das linhas representa um fluxo de sequencia.
Já, para representar as tarefas realizadas por cada um dos sistemas é utilizado a tag scriptTask, o detalhamento de ligação dessa tarefa com as demais do fluxo envolve as tags, internas a ela, incoming e outgoing, que representam, respectivamente, a entrada e a saída
34
daquela tarefa. A linha 36, da Figura 7, informa que a entrada para a tarefa ScriptTask_2, nominada neste exemplo de "Solicitar resgate", é representada pelo elemento Sequence-Flow_1. A sua saída, identificada pela tag outgoing na linha 38 dessa mesma figura, é representada pelo elemento SequenceFlow_2. O fluxo desta forma vai sendo traduzido da parte gráfica e sendo apresentado em formato XML.
2.7
Agentes de
Software
Atualmente, novos paradigmas estão sendo buscadas para aumentar a habilidade de modelar, projetar e construir sistemas complexos de informação de natureza distribuída. Para isso, vários paradigmas têm sido utilizados pela engenharia de software para facilitar no desenvolvimento e gerenciamento dos sistemas de informação como programação estru-turada, declarativa, orientada a objetos, orientada a componentes, etc. Um paradigma, no entanto, que vem atraindo a atenção da indústria de software e que, devido a suas características, tem um grande potencial para o desenvolvimento de sistemas complexos e distribuídos, é o paradigma de programação orientada a agentes.
A programação orientada a agentes é caracterizada pelo uso dos agentes de software, que são sistemas computacionais capazes de ações flexíveis e autônomas em um ambiente dinâmico, aberto e imprevisível (JENNINGS; BUSSMANN, 2003). Jennings et al. (2001) informa que o uso da abordagem orientada a agentes surgiu na comunidade de inteligência artificial e é baseado nos argumentos que 1) o aparato conceitual de sistemas orientados a agentes é adequado para construir soluções de software para sistemas complexos e 2) 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 pre-cisã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 orien-tadas a agentes são adequadas para desenvolver sistemas complexos de software porque: 1) as decomposições orientadas a agentes são efetivas quando repartem o espaço do pro-blema em um sistema complexo; 2) as abstrações principais presentes no modo de pensar orientado a agentes são um meio natural de modelar sistemas complexos e 3) a filosofia para identificar e gerenciar relacionamentos organizacionais é apropriada para lidar com as dependências e interações que existem em um sistema complexo.
Tabela 1: Características de agentes de software Característica Definição
Autonomia Capacidade de atuar sem a intervenção direta de seres humanos ou outros agentes, tendo controle sobre suas próprias ações e seu estado de forma não supervisionada
Comunicação Capacidade de trocar informações acerca de seus recursos, seu co-nhecimento e suas decisões com outras entidades, com o ambiente onde executa e com seres humanos
Cooperação e habilidade social
Capacidade de trabalhar em conjunto com outros agentes em busca de um objetivo comum
Inteligência Capacidade computacional ou analítica que um agente possui para analisar seu ambiente e resolver problemas
Aprendizado Capacidade de aprender através de um conjunto de instruções ou continuamente por experiência, com base no resultado das decisões tomadas de forma autônoma a partir da percepção do ambiente Reatividade Capacidade de perceber mudanças no ambiente e responder a tais
mudanças
Proatividade Capacidade de iniciativa para realizar o objetivo atribuído ao agente em vez de simplesmente reagir a mudanças no ambiente Mobilidade Capacidade de movimentação entre ambientes de execução
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-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
36
de seu ambiente, tomam atitudes para modificar condições no seu ambiente, raciocinam para interpretar percepções, resolvem problemas, traçam inferências e determinam ações. Já Wooldridge e Jennings (1995) não apenas exigem autonomia, percepção e reatividade. Para ser inteligente, deve ser possível a inclusão da proatividade, caracterizada por deci-sões próprias de sua iniciativa e não apenas em relação a uma resposta ao ambiente.
Segundo Jennings et al. (2001), a proatividade de um agente é uma característica que requer que os agentes não devam simplesmente agir em resposta ao seu meio ambiente, eles devem ser capazes de exibir comportamentos oportunistas e dirigidos a objetivos, tomando a iniciativa quando apropriado. Já a reatividade dos agentes deve fazê-los capaz de perceber seu ambiente (que pode ser o mundo físico, um usuário, uma coleção de agentes, a internet, etc.) e responder em tempo hábil às mudanças que ocorrem nele.
O comportamento proativo, desta forma, é principalmente adequado a ambientes que não ofereçam muito dinamismo, onde condições sejam alteradas enquanto o agente está tomando decisões, uma vez que podem resultar em situações indesejadas. É mais prudente que este comportamento seja utilizado em ambientes que a mudança de estado do agente seja de conhecimento prévio e informações sobre o ambiente de execução seja mais clara.
2.7.1
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: 1) linguagem e protocolo de comunicação padronizado; 2) formato comum para o conteúdo de comunicação e 3) ontologia compartilhada.
A comunicação entre agentes é a troca voluntária de informações causada pela detec-ção e produdetec-ção de sinais por parte dos agentes. Em um ambiente multiagente, essa troca de informações serve como base para coordenar as ações e possibilitar a cooperação.
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. O Agent Identifier (AID) é o endereço de cada um dos agentes utilizado para a sua publicação, necessário 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).
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ási-cos de interação entre os agentes são efetivamente codificados. A ACL somente permite comunicação entre os próprios agentes.
2.7.2
JADE - Java Agent Development Framework
No contexto de sistemas baseados em agentes, o JADE2 é 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 Foundation for Intelligent, Phisical Agents (FIPA). O framework inclui: 1) um ambiente de execução, onde os agentes JADE podem ser criados e se mantém ativos; 2) uma biblioteca de classes (API) que programadores pode utilizar para desenvolver seus agentes e 3) um conjunto de ferramentas gráficas que permitem administrar e monitorar as atividades dos agentes em execução.
O JADE é um sistema completamente distribuído onde habitam agentes, que se co-municam através de mensagens, geralmente assíncronas. Cada agente possui um nome globalmente único dentro da plataforma, definido pela FIPA como AID, que o JADE constrói concatenando um apelido definido pelo próprio usuário ao nome da plataforma. Os agentes encontram-se em ambientes conhecidos como contêiner ou host, que abriga vários agentes e representa, geralmente, um local de execução dentro do ambiente distri-buído. O conjunto de todos os hosts é chamado de plataforma e forma uma camada única que abstrai toda a complexidade e heterogeneidade das entidades subjacentes como hard-ware, sistema operacional, tipos de rede, JVM (Java Virtual Machine), etc. A mobilidade de estados de execução é permitida pelo JADE e um agente pode interromper uma exe-cução em um host e migrar para outro host para realizar a sua exeexe-cução neste ponto remoto.
38
As mensagens trocadas entre os agentes dentro do JADE baseiam-se na linguagem ACL, também especificada pela FIPA, e contém campos alguns parâmetros que podem servir como formas de enriquecimento da mensagem enviada.
Os módulos gráficos são um grande diferencial dessa ferramenta e podem servir como um grande auxílio para facilitar o gerenciamento e acompanhamento das mensagens tro-cadas entre os agentes dentro da plataforma, como também simular requisições, criar e finalizar agentes, mover os agentes entre os contêineres, entre outras diversas funcionali-dades e facilifuncionali-dades.
2.7.3
Ciclo de Vida de um Agente JADE
Todo agente no JADE tem um ciclo de execução predeterminado, o ciclo se inicia com método setUp() (vide Figura 8), onde ocorre a inicialização do agente. Quando pronto, o agente executa o seu comportamento (método action()), implementado pelo desenvolve-dor. Esse comportamento pode fazer uso de tipos predefinidos, tais como one-shot (exe-cução única), cíclico (exe(exe-cução infinita, executando a cada nova requisição) ou temporal (execução periódica). Caso o comportamento seja do tipo one-shot, após a sua execução o agente é morto e finalizado (executado método doDelete() e takeDown()).
Dentro do comportamento infinito, executado a cada nova requisição, caso haja muitas requisições simultâneas o J ADE implementa uma fila de comportamentos para adicionar essas requisições isso porque cada agente somente executa uma requisição por vez.
A implementação do JADE segue as recomendações da FIPA (Foundation for Intelli-gent Physical AIntelli-gents), organismo internacional para o desenvolvimento de aIntelli-gentes inteli-gentes, utilizando a ACL (Agent Communication Language) como linguagem específica e independente utilizada na comunicação entre os agentes.
Figura 8: Execução do ciclo de vida Fonte: (BATISTA, 2008)
40
3
Mandala
Esse capítulo apresenta a arquitetura do Mandala, uma plataforma de middlewareque tem por objetivo promover interoperabilidade entre sistemas visando a formação de um SoIS (doravante chamado apenas de SoS), abstraindo, portanto, detalhes relacionados às tecnologias por ele utilizadas. Cada um dos sistemas constituintes tem a sua missão particular e, como originalmente eles não foram projetados para interoperarem um com os outros, o Mandala seria o responsável por essa interoperação. Embora a contribuição principal desse trabalho seja desenvolver o componente da Mandala responsável pela es-pecificação e criação de SoS, a arquitetura da Mandala é apresentada neste capítulo para contextualizar quais as interações entre o componente de especificação de SoS e o res-tante da plataforma. Vale ainda salientar que o presente trabalho está relacionado à uma dissertação de Mestrado, sendo tal dissertação a responsável por propôr e implementar a Mandala de modo mais completo.
3.1
Componentes
De uma forma geral, a proposta da Mandala visa minimizar, primordialmente, as difi-culdades de fazer com que sistemas desenvolvidos utilizando tecnologias distintas possam interoperar. A Figura 9 ilustra a arquitetura da Mandala, que é composta por quatro elementos ou componentes principais, quais sejam:
• Broker : É componente responsável por intermediar a comunicação entre um sistema constituinte do SoS, sendo necessário um Broker para cada sistema, com o resto da plataforma Mandala. A comunicação entre o Broker e o sistema é dado através da API (Application Programming Interface) do sistema constituinte, possibilitando realizar as consultas às funcionalidades desse sistema. Essa API deve ser desenvol-vida pelo desenvolvedor do sistema candidato à integração, com estilo arquitetural REST (Representational State Transfer) e os seus dados devem ser acessados no formato JSON (JavaScript Object Notation). A comunicação entre o Broker e o
Figura 9: Arquitetura do Mandala Fonte: Própria (2017)
resto da plataforma - SoS Manager, SoS Server, Broker dos outros sistemas - é dada através de Agentes de Software JADE, descrito no Capítulo 2.7.
• SoS Composer : É o componente responsável pela associação aos sistemas consti-tuintes, bem como suas missões individuais, e a criação do SoS. Através deste com-ponente, o desenvolvedor do SoS associa os sistemas candidatos a participarem de algum SoS, com base nas suas missões individuais. Quando o SoS é criado, os siste-mas candidatos passam a ser constituintes e um fluxo é gerado, via BPD seguindo a Notação e Modelo de Processo de Negócio (BPMN). Os passos deste fluxo (descrito em XML que corresponde ao BPD criado) são solicitados para armazenamento no SoS Manager, juntamente com os metadados do SoS recém-criado. Será explicado sua a arquitetura em mais detalhes no Capítulo 4.
• SoS Manager : É o componente responsável pela gravação dos dados solicitados pelo SoS Composer, pela propagação dos dados dos SoS recém criados para todos os Brokers envolvidos no SoS criado e pela solicitação da publicação do serviço Web relativo ao SoS. Essa propagação também é feita utilizando Agentes de Software JADE.
42
• SoS Server : Após a criação do SoS e propagação dos dados em todos os Brokers dos sistemas envolvidos no SoS criado. Para cada novo SoS, um Serviço Web é publicado e as funcionalidades desse SoS passam a ficar disponíveis para consumo pelos clientes. Dessa forma, o SoS Server é o componente responsável por servir tais Serviços Web para serem consumidos pelos clientes que desejam utilizar os SoS.
3.2
Comunicação entre os componentes
É bastante complicado realizar interoperabilidade entre sistemas distribuídos se a estrutura de comunicação não estiver bem planejada e executada. A comunicação para este tipo de solução é um fator preponderante de sucesso.
Por isso, foram utilizados agentes de software na comunicação interna da Mandala para facilitar a comunicação entre os componentes, visto que os componentes podem estar distribuídos, localizados em máquinas e ou em locais diferentes. Os agentes JADE se comunicam por mensagens, em linguagem específica, e utilizam comportamentos para realizar as suas ações. Há agentes de software nos Broker, no SoS Server e no SoS Manager. O agente do SoS Server se comunica com os agentes dos Broker para comunicar que um SoS vai ser consumido ou quando recebe a resposta da execução da missão do SoS. O agente do SoS Manager, por sua vez, serve para disseminar as informações dos SoS criados aos Broker associados aos sistemas constituintes.
Já no SoS Composer, a comunicação é dada utilizando um agente JADE temporário, proveniente da Classe JadeGateway1 do JADE, onde é instanciado um agente somente após a especificação do SoS para se comunicar ao SoS Manager e é encerrado após isso.
Outra vantagem do framework JADE é a ferramenta gráfica Sniffer que permite identificar e visualizar a troca de mensagens e o tipo de requisição solicitada pelos agentes. A Figura 10 é uma visão real capturada durante a realização dos testes de troca de mensagens entre os agentes da plataforma Mandala. A imagem representa a troca de mensagens para a realização de uma missão global do SoS.
Os agentes de software JADE trabalham com o conceito de comportamentos. Há com-portamentos que executam ações paralelas, assim como há comcom-portamentos que executam ações sequenciais apenas uma vez ou infinitas vezes. A escolha destes comportamentos pode trazer mais ou menos dinamismo ao produto.
Figura 10: Tela do Sniffer com as trocas de mensagens entre os agentes Fonte: Própria
No caso do SoS Server, para cada SoS criado, há um serviço Web sempre ativo aten-dendo às requisições dos clientes, um agente de comportamento infinito, que está sem-pre à espera, nesse comportamento, o agente fica no estado "aguardando"ou no estado "executando"no seu ciclo de vida conforme mostrado no Capítulo 3.4. Para atender às requisições, se faz presente. O mesmo perfil de comportamento de agente é encontrado nos Brokers para verificar a chegada de novas mensagens. Caso fosse usado comportamento de execução única, um agente novo necessitaria ser criado a cada requisição, o que não pareceu ser uma estratégia interessante.
Em uma plataforma que trabalha sob demanda de requisições, é natural pensar que, invariavelmente, requisições simultâneas devam ocorrer. Por especificação, o agente de software possui apenas uma thread de execução por agente e não por tarefa. Embora existam alternativas para alterar essa estrutura, a opção de manter a originalidade do agente pode ser interessante para não degradar o seu desempenho. Dessa forma, caso um mesmo agente receba várias requisições ao mesmo tempo, o tratamento da mensagem será
44
sequencial atendendo a ordem de uma fila de execuções.
3.3
Repositórios
Foi utilizado o SQLite2 para montar a estrutura de repositórios dentro da plataforma Mandala para armazenar somente a especificação das missões e os dados sobre os sistemas e sobre o SoS. Esse sistema de gerenciamento de banco de dados é gratuito e não requer uma instalação nem grandes recursos para executar.
Em consonância com a arquitetura apresentada na Figura 9, o Mandala tem três clas-ses distintas de repositórios. O primeiro e o principal é no SoS Manager, que contém as informações de metadados relacionados à estrutura do SoS que foram criados e publica-dos, como as missões (fluxos), a sequência de passos a ser executada, os endereços dos agentes dos Brokers, os sistemas participantes, as suas respectivas tarefas. O Diagrama de Relacionamento desse Banco de dados é mostrado na Figura 11.
Figura 11: Diagrama de Relacionamento do Banco de Dados do SoS Manager. Fonte: Própria (2017)
Outra classe de repositório está localizado no SoS Server que, diferentemente do SoS Manager, para cada SoS em execução é armazenado as informações apenas desse SoS. São armazenadas neste repositório, além da identificação do SoS, as informações dos agentes dos Broker dos sistemas participantes do SoS em execução, como também a sequência de
passos, para que quando uma requisição a um SoS é feito, o SoS Server possa se comunicar, via agente Jade, com os componentes do Mandala, responsáveis pelo acesso aos sistemas constituintes.
Já, a ultima classe está localizada nos Brokers onde armazena todas as informações dos SoS que o sistema faz parte. O Broker recebe as informações do SoS Manager relativas aos SoS que faz parte e armazena no seu repositório. Estas informações incluem o endereço do sistema constituinte, as informações sobre o SoS, a missão e os passos a serem executados. À medida que vai sendo executado o SoS, as informações sobre o último passo executado e sobre o próximo passo do fluxo a ser seguido são atualizadas no repositório. A Figura 12 ilustra os dados presentes em cada uma das diferentes classes de repositório.
Figura 12: Dados armazenados em cada um dos repositórios. Fonte: Própria (2017)
3.4
Execução de uma Missão do SoS criado pelo
Man-dala
A partir do momento que o SoS é iniciado3, já foram repassados os dados necessários para todos os componentes envolvidos e o serviço web daquele SoS já foi publicado, todos já estão cientes da sua participação e da sua responsabilidade dentro daquela missão.
O processo de execução de uma missão é mostrado no diagrama de Sequencia na Figura 13. A execução é iniciada quando um cliente faz uma requisição ao SoS Server para consumir uma missão de um SoS cadastrado na plataforma Mandala. O SoS Server
46
repassa a solicitação para o agente Jade, chamado de WSAgent, responsável pela missão do SoS que foi solicitada, o WSAgent verifica os sistemas que fazem parte dessa missão e envia uma mensagem para os Brokers desses sistemas solicitando a 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 à execução, caso seja ele o responsável. Se ele não se identificar como responsável sobre aquele passo, ignora a mensagem e fica na espera de novas solicitações. Esse processo se repete de acordo com o fluxo da missão solicitada.
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 responsável pelo SoS, dentro do SoS Server, recebe a informação do agente, pela conexão estabelecida anteriormente, e informa ao cliente o resultado da execução.
Figura 13: Arquitetura do Mandala Fonte: Própria (2017)
