Daniela Maria Uez
Open AEOlus: um método para
especificação de sistemas
multiagentes abertos
Florianópolis
2018
Daniela Maria Uez
OPEN AEOLUS: UM MÉTODO PARA
ESPECIFICAÇÃO DE SISTEMAS
MULTIAGENTES ABERTOS
Tese submetida ao Programa de Pós-Graduação em Enge-nharia de Automação e Siste-mas para a obtenção do Grau de Doutor.
Orientador: Jomi Fred Hübner
Florianópolis
Uez, Daniela Maria
Open AEOlus: um método para especificação de sistemas multiagentes abertos / Daniela Maria Uez ; orientador, Jomi Fred Hübner, 2018.
261 p.
Tese (doutorado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós Graduação em Engenharia de Automação e Sistemas, Florianópolis, 2018.
Inclui referências.
1. Engenharia de Automação e Sistemas. 2. Método orientado a agentes. 3. Sistema multiagentes abertos. 4. Engenharia de software orientada a agentes. 5. JaCaMo. I. Hübner, Jomi Fred. II. Universidade Federal de Santa Catarina. Programa de Pós-Graduação em Engenharia de Automação e Sistemas. III. Título.
Daniela Maria Uez
Open AEOlus: um método para
especificação de sistemas multiagentes
abertos
Esta Tese foi julgada adequada para a obtenção do Título de Doutor e aprovada em sua forma final pelo Programa de Pós-Graduação em Engenharia de Automação e Sistemas
Florianópolis, 20 de setembro de 2018
Prof. Werner Kraus Junior Coordenador do Curso
Banca Examinadora:
Prof. Jomi Fred Hübner, Dr.
Orientador
Profa. Viviane Torres da Silva, Dra.
IBM Research
Prof. Ricardo Azambuja Silveira, Dr.
UFSC
Prof. Leandro Buss Becker, Dr.
AGRADECIMENTOS
Agradeço à CAPES, aos professores e colegas do departamento de Automação e Sistemas da UFSC, em especial meu orientador Jomi F. Hübner cuja orientação e apoio foi fundamental para que esse trabalho fosse concluído. Também agradeço aos professores Rafael Bordini e Olivier Boissier pelo apoio e auxílio durante esse processo.
Agradeço também à minha família, em especial minha mãe, Maria, meu irmão, Pablo e meu namorado-noivo-marido, Cleverson. Muito obrigada pela paciência e carinho durante todo esse tempo.
Enfin [...] je m’avisai de faire une revue sur les diverses occupations qu’ont les hommes en cette vie, pour tâcher à faire choix de la meilleure; et sans que je veuille rien dire de celles des autres, je pensai que je ne pouvais mieux que de continuer en celle-là même où je me trouvais, c’est-à-dire, que d’employer toute ma vie à cultiver ma raison, et m’avancer, autant que je pourrais, en la connaissance de la vérité [...] René Descartes
RESUMO
Sistemas multiagentes (SMA) abertos auxiliam na resolução de problemas complexos, nos quais nem todos os componentes podem ser conhecidos antes da execução do sistema. Dessa forma, uma ou mais dimensões de um sistema aberto não podem ser especificadas em tempo de desenvolvimento. Um número considerável de métodos foram desenvolvidos para modelagem de SMA, porém estes não apresentam característi-cas que auxiliem na especificação da abertura. Pensando nisso, este trabalho propõe um método, chamado Open AEOlus, para auxiliar na modelagem de SMA abertos. O método está embasado em dois pilares: a modelagem independente de cada uma das dimensões do sistema (agente, ambiente e organiza-ção) e a especificação dos conceitos de borda, que visam prover informações em tempo de projeto que auxiliem os elementos da dimensão aberta a serem incluídos em tempo de execução. O método é composto por três fases de desenvolvimento: aná-lise, que visa criar uma definição clara do sistema; projeto, onde os elementos de cada dimensão fechada serão especifica-dos independentemente; e implementação, onde os elementos definidos durante a fase de projeto serão refinados visando a geração de código para o framework JaCaMo. Nessa tese, o método Open AEOlus é descrito com a ajuda de dois exemplos de uso, que permitem visualizar os work produts gerados ao longo de cada uma das suas fases de desenvolvimento.
Palavras-chave: Método. Sistemas multiagentes abertos. Ja-CaMo.
ABSTRACT
Open multi-agent systems are used to solve many problems in which one or more component can’t be specified in design time. That means that, at design time, at least one of MAS dimensions cannot be specified. Many methods are proposed in agent-oriented software engineering field to analysis and design multi-agent systems, but they don’t offer guidelines to help the design of openness. In this thesis, we present the Open AEOlus method, that aims to allow the analysis and design of open MAS. The method is based on the idea that dimensions (agents, environment and organization) must be specified independently, and also on the definition of the border concepts. Border concepts are used to provide, at design time, information that must be used on runtime in order to support the integration of the open elements. The Open AEOlus method is composed by three development phases: analysis, in which a clear system definition is provided, design, in which the elements of closed dimensions are designed independently, and implementation, in which these elements are refined to allow the code generation in a specific target platform. In this work, we choose JaCaMo framework as a target platform. In this thesis, the Open AEOlus method is described with two examples, that are used to visualize the work products generated throughout the method development phases.
LISTA DE ILUSTRAÇÕES
Figura 1 – Ciclo de vida do SMA . . . 82 Figura 2 – Tipos de abertura X Tempos do ciclo de vida 88 Figura 3 – Modelo da fase de análise . . . 104 Figura 4 – Modelo da dimensão de agentes – fase de
projeto . . . 106 Figura 5 – Modelo da dimensão de ambiente – fase de
projeto . . . 107 Figura 6 – Modelo da dimensão de organização – fase
de projeto . . . 109 Figura 7 – Modelo conceitos de ligação – fase de projeto111 Figura 8 – Modelo conceitos de borda – fase de projeto113 Figura 9 – Modelo da dimensão de agentes – fase de
implementação . . . 114 Figura 10 – Modelo da dimensão do ambiente – fase de
implementação . . . 116 Figura 11 – Modelo dimensão da organização – fase de
implementação . . . 117 Figura 12 – Modelo dimensão da organização – fase de
implementação . . . 119 Figura 13 – Modelo dos conceitos de borda – fase de
implementação . . . 120 Figura 14 – Visão geral do método /aeolus . . . 124 Figura 15 – Notação gráfica dos conceitos no método
Open AEOlus. . . 126 Figura 16 – Diagrama de Cenários - Exemplo . . . 130 Figura 17 – Diagrama de Árvore de objetivos - Exemplo134 Figura 18 – Árvore de objetivos com associação dos
Figura 20 – Diagramas de responsabilidade dos agentes - Exemplo . . . 140 Figura 21 – Diagrama de Planos - Exemplo . . . 141 Figura 22 – Diagrama de Artefatos - Exemplo . . . . 143 Figura 23 – Diagrama de Papéis Refinado - Exemplo. 145 Figura 24 – Diagrama de Responsabilidades dos Papéis
- Exemplo . . . 146 Figura 25 – Diagrama de Protocolos - Exemplo. . . 147 Figura 26 – Especificação das Habilidades - Exemplo. 149 Figura 27 – Especificação das habilidades papel
abs-trato - Exemplo . . . 151 Figura 28 – Especificação da Interface de uso - Exemplo152 Figura 29 – Especificação das Regras Count-as - Exemplo154 Figura 30 – Associação dos planos com agentes e
mó-dulos - Exemplo . . . 157 Figura 31 – Crenças iniciais e regras - Exemplo. . . . 158 Figura 32 – Refinamento dos Planos - Exemplo . . . . 159 Figura 33 – Refinamento dos Artefatos - Exemplo . . 163 Figura 34 – Diagrama final de objetivos - Exemplo . . . 167 Figura 35 – Diagrama de missões - Exemplo . . . 168 Figura 36 – Geração de código agentes - exemplo. . . . 177 Figura 37 – Geração de código organização -
Especifi-cação Estrutural . . . 182 Figura 38 – Geração de código organização -
Especifi-cação Funcional . . . 185 Figura 39 – Agentes em Marte - Tela . . . 203 Figura 40 – Agentes em Marte - Diagrama de Cenários 205 Figura 41 – Agentes em Marte - Árvore de objetivos . 206
Figura 42 – Agentes em Marte - Árvore de objetivos com associação dos atores . . . 207 Figura 43 – Agentes em Marte - Caracterização das
Dimensões . . . 208 Figura 44 – Agentes em Marte - Diagramas de
respon-sabilidades dos agentes . . . 209 Figura 45 – Agentes em Marte - Planos iniciais . . . . 210 Figura 46 – Agentes em Marte - Papéis . . . 211 Figura 47 – Agentes em Marte - Diagrama de
respon-sabilidades dos papéis . . . 211 Figura 48 – Agentes em Marte - Conceito de borda
interface de uso. . . 212 Figura 49 – Agentes em Marte - Conceito de borda
count-as . . . 212 Figura 50 – Agentes em Marte - Agentes e módulos . 213 Figura 51 – Agentes em Marte - Refinamento dos planos214 Figura 52 – Agentes em Marte - Detalhamento dos papéis218 Figura 53 – Agentes em Marte - Refinamento de objetivos218 Figura 54 – Agentes em Marte - Missões . . . 219 Figura 55 – Rota Turística – Diagrama de cenários . . 224 Figura 56 – Rota Turística – Árvore de objetivos . . . 225 Figura 57 – Árvore de objetivos completa . . . 226 Figura 58 – Rota Turística – Caracterização das
Dimen-sões . . . 226 Figura 59 – Rota turística - Artefatos do ambiente . . 228 Figura 60 – Rota Turística - Diagrama de papéis . . . 228 Figura 61 – Rota Turística - Responsabilidades dos papéis229 Figura 62 – Rota Turística - Habilidades . . . 229 Figura 63 – Rota Turística - Interface de Uso . . . 230
do ambiente. . . 233 Figura 65 – Rota Turística - Diagrama de objetivos
re-finado . . . 233 Figura 66 – Rota Turística - Diagrama de missões . . 234
LISTA DE TABELAS
Tabela 1 – Métodos orientados a agentes. . . 75 Tabela 2 – Tipos de abertura . . . 89 Tabela 3 – Conceitos especificados para cada tipo de
abertura . . . 97 Tabela 4 – Conceitos de borda para cada dimensão
aberta . . . 148 Tabela 5 – Detalhamento dos elementos do plano . . 162 Tabela 6 – Detalhamento dos elementos do artefato . 165 Tabela 7 – Detalhamento dos artefatos StudentList e
Enrollment . . . 166 Tabela 8 – Definição das normas - Exemplo . . . 170 Tabela 9 – Detalhamento das habilidades para o papel
professorIngles - Exemplo . . . 171 Tabela 10 – Detalhamento das habilidades para o agente
agBob - Exemplo . . . 172
Tabela 11 – Interface de uso Artefatos ListaAlunos e
Matricula - Exemplo . . . 173
Tabela 12 – Interface de uso agentes - Exemplo . . . . 174 Tabela 13 – Detalhamento das regras count-as - Exemplo175 Tabela 14 – Agentes em Marte - Detalhamento das ações215 Tabela 15 – Agentes em Marte - Detalhamento das
cren-ças. . . 216 Tabela 16 – Agentes em Marte - Detalhamento dos
Eventos . . . 217 Tabela 17 – Agentes em Marte - Detalhamento das
men-sagens . . . 217 Tabela 18 – Agentes em Marte - Normas . . . 219
mon . . . 220 Tabela 20 – Agentes em Marte - Interface de uso
AgRe-pairer . . . 220 Tabela 21 – Agentes em Marte - Interface de uso -
AgIns-pector . . . 221 Tabela 22 – Agentes em Marte - Interface de uso -
Ag-Sentinel . . . 221 Tabela 23 – Agentes em Marte - Detalhamento regras
count-as . . . 222 Tabela 24 – Rota Turística - Detalhamento dos artefatos232 Tabela 25 – Rota Turística - Normas. . . 234 Tabela 26 – Rota Turística - Conceito de Borda
Habili-dade. . . 235 Tabela 27 – Rota Turística - Conceito de Borda
LISTA DE CÓDIGOS
Código 1 – Código fonte para o agente AgentA . . . 177 Código 2 – Código do artefato Enrollment . . . 178 Código 3 – Código do artefato Enrollment . . . 180 Código 4 – Arquivo XML- dimensão do ambiente . . 181 Código 5 – Arquivo XML- Especificação Estrutural . 183 Código 6 – Arquivo XML- Especificação Funcional . 185 Código 7 – Arquivo XML- Especificação Normativa . 187 Código 8 – DTD para geração de código conceitos de
borda - elemento principalborder-concept . . . 189 Código 9 – DTD para geração de código conceito de
borda habilidade - elementocapabilities . . . 189 Código 10 – XML exemplo conceito de borda capability
- elementocapabilities . . . 190 Código 11 – DTD para geração de código conceitos de
borda - elementousage-interface . . . 192 Código 12 – XML exemplo conceito de borda interface
de uso - elementointerface-artifact. . . 193 Código 13 – XML exemplo conceito de borda interface
de uso - elementointerface-agent . . . 195 Código 14 – DTD para geração de código conceito de
borda - elementocount-as . . . 196 Código 15 – XML exemplo conceito de borda count-as 196
LISTA DE SIGLAS
SMA Sistema Multiagente
AOSE Agent Oriented Software Engineering
MDE Model Driven Engineering
A Agentes
E Ambiente
O Organização
BDI Belief-desire-intention
A&A Agentes e Artefatos
HMAS Holonic Multi Agent System
MAPC Multiagent Programming Context
WESAAC Workshop-Escola de Sistemas de Agentes, seus Ambientes e apliCações
SUMÁRIO
1 INTRODUÇÃO . . . . 31 1.1 Problema e Hipótese de Pesquisa . . 34 1.2 Objetivos . . . 35 1.3 Contribuições . . . 36 1.4 Metodologia . . . 36 1.5 Estrutura do Texto . . . 38
2 SISTEMAS MULTIAGENTES
ABER-TOS. . . . 39 2.1 Sistemas Multiagentes . . . 39 2.2 Os Agentes. . . 41 2.3 O Ambiente . . . 44 2.4 A Organização . . . 45 2.5 JaCaMo. . . 47 2.6 Sistemas multiagentes abertos . . . . 49 2.7 Desenvolvimento SMA Abertos. . . . 51 2.8 Considerações . . . 55
3 ENGENHARIA DE SOFTWARE PARA
SISTEMAS ABERTOS . . . . 57 3.1 Métodos orientados a agentes . . . 57 3.1.1 ADELFE . . . 57 3.1.2 ASPECS . . . 59 3.1.3 GORMAS . . . 61 3.1.4 O-MaSE . . . 63 3.1.5 PASSI . . . 65 3.1.6 Prometheus . . . 66 3.1.7 Prometheus AEOlus . . . 68
3.1.9 SODA . . . 71 3.1.10 Tropos. . . 72 3.2 Análise dos métodos . . . 74 3.3 Considerações . . . 78
4 VISÃO CONCEITUAL . . . . 81 4.1 Uma nova definição de abertura . . . 81 4.2 Tipos de abertura . . . 87 4.3 Restrições para a abertura. . . 89 4.4 Desenvolvimento de SMA abertos . . 92 4.5 Considerações . . . 97
5 VISÃO GERAL DO MÉTODO OPEN
AEOLUS. . . 101 5.1 Modelos. . . 102 5.2 Modelo Fase de Análise do Sistema . 103 5.3 Modelo Fase de Projeto. . . 104 5.3.1 Modelo da Dimensão dos Agentes . . 105 5.3.2 Modelo da Dimensão do Ambiente . 106 5.3.3 Modelo da Dimensão da Organização 108 5.3.4 Modelo Ligações entre as Dimensões 110 5.3.5 Modelo Conceitos de Borda . . . 112 5.4 Modelo Fase de Implementação. . . . 113 5.4.1 Modelo Dimensão dos Agentes . . . . 114 5.4.2 Modelo da Dimensão dos Ambiente . 116 5.4.3 Modelo da Dimensão da Organização 117 5.4.4 Modelo Ligações entre as Dimensões 118 5.4.5 Modelo Conceitos de Borda . . . 119 5.5 Considerações . . . 121
6 DESCRIÇÃO DO MÉTODO . . . 123 6.1 O Método Open AEOlus . . . 123 6.2 Notação. . . 126 6.3 Fase de Análise do Sistema . . . 127 6.3.1 Definição dos cenários de uso . . . 128
6.3.1.1 Descrição dos cenários de uso . . . 129
6.3.1.2 Diagrama de cenários de uso . . . 129
6.3.2 Definição dos objetivos . . . 131
6.3.2.1 Lista inicial de objetivos . . . 131
6.3.2.2 Árvore de Objetivos . . . 132
6.3.3 Definição dos atores . . . 133
6.3.3.1 Identificação dos atores . . . 134
6.3.3.2 Associação de atores com objetivos . . . 134
6.3.4 Caracterização das dimensões. . . 135 6.4 Fase de Projeto . . . 136 6.4.1 Projeto de Dimensões . . . 137
6.4.1.1 Dimensão dos Agentes . . . 137
6.4.1.1.1 Identificar agentes . . . 138
6.4.1.1.2 Responsabilidades dos agentes . . . 139
6.4.1.1.3 Identificação dos planos . . . 139
6.4.1.2 Dimensão do Ambiente . . . 140
6.4.1.2.1 Identificação dos artefatos. . . 141
6.4.1.2.2 Definição das operações e eventos . . . 142
6.4.1.3 Dimensão da Organização . . . 143
6.4.1.3.1 Identificação dos papéis . . . 144
6.4.1.3.2 Refinamento dos papéis . . . 144
6.4.1.3.3 Responsabilidades papéis . . . 145
6.4.1.3.4 Definição dos Protocolos . . . 146
6.4.2 Projeto de Abertura. . . 147
6.4.2.3 Conceito de Borda - Count-as . . . 152 6.5 Fase de Implementação . . . 154 6.5.1 Implementação de Dimensões . . . 155
6.5.1.1 Dimensão dos Agentes . . . 156
6.5.1.1.1 Associação dos planos com os agentes e mó-dulos . . . 156
6.5.1.1.2 Crenças iniciais e regras dos agentes . . . . 157
6.5.1.1.3 Refinamento dos planos . . . 158
6.5.1.1.4 Detalhamento . . . 160
6.5.1.2 Dimensão do Ambiente . . . 162
6.5.1.2.1 Definição dos workspaces. . . 162
6.5.1.2.2 Refinamento dos artefatos. . . 162
6.5.1.2.3 Detalhamento . . . 164
6.5.1.3 Dimensão da Organização . . . 166
6.5.1.3.1 Detalhamento dos objetivos. . . 167
6.5.1.3.2 Definição das missões . . . 168
6.5.1.3.3 Revisão dos papéis. . . 169
6.5.1.3.4 Definição das normas . . . 170
6.5.2 Implementação de Abertura . . . 171
6.5.2.1 Conceito de Borda - Habilidade . . . 171
6.5.2.2 Conceito de Borda - Interface de Uso . 172
6.5.2.3 Conceito de Borda - Count-As . . . 174
6.6 Geração de Código. . . 175 6.6.1 Dimensão dos agentes . . . 176 6.6.2 Dimensão do ambiente . . . 178 6.6.3 Dimensão da organização. . . 181
6.6.3.1 Dimensão Estrutural . . . 182
6.6.3.2 Dimensão Funcional . . . 184
6.6.4 Conceitos de Borda . . . 188
6.6.4.1 Conceito de Borda: Habilidade . . . 189
6.6.4.2 Conceito de Borda: Interface de Uso . . 191
6.6.4.3 Conceito de Borda: Count-As . . . 195
6.7 Considerações . . . 197
7 APLICAÇÃO DO MÉTODO . . . 201
7.1 Cenário I – Agentes em Marte . . . . 201 7.1.1 Fase de Análise . . . 203 7.1.2 Fase de Projeto . . . 208
7.1.2.1 Dimensão dos Agentes . . . 208
7.1.2.2 Dimensão da Organização . . . 210
7.1.2.3 Projeto de Abertura. . . 212
7.1.3 Fase de Implementação . . . 213
7.1.3.1 Dimensão dos Agentes . . . 213
7.1.3.2 Dimensão da Organização . . . 217
7.1.3.3 Implementação da Abertura . . . 220
7.2 Cenário II – Rota Turística . . . 222 7.2.1 Fase de Análise . . . 222 7.2.2 Fase de Projeto . . . 227 7.2.2.1 Dimensão do Ambiente . . . 227 7.2.2.2 Dimensão da Organização . . . 227 7.2.2.3 Projeto de Abertura. . . 228 7.2.3 Fase de Implementação . . . 230 7.2.3.1 Dimensão do Ambiente . . . 230 7.2.3.2 Dimensão da Organização . . . 232
7.2.3.3 Conceito de Borda Habilidade . . . 235
7.2.3.4 Conceito de Borda Interface Uso . . . . 235
8.1 Contribuições . . . 243 8.2 Trabalhos Futuros . . . 244
REFERÊNCIAS . . . 247
APÊNDICE A – ESTRUTURA AR-QUIVO XML CON-CEITOS DE BORDA259
31
1 INTRODUÇÃO
Um número cada vez maior de problemas tem sido resolvido através do uso de sistemas multiagentes (SMA) e muitos trabalhos têm demonstrado os benefícios do uso desse paradigma nas mais diversas aplicações (LEITAO,2013; CAMPOS?RODRIGUEZ et al.,2017;ALVES et al.,2018;SKOBELEV et al., 2018; HOFFA-DABROWSKA; KLUSKA, 2018; CANEDO; TRIFAN; NEVES,2018) Muitos métodos foram propostos para apoiar a análise e o projeto desse tipo de sistema, sendo que um número considerável delas já se encontra suficientemente detalhada para ser utilizada profissionalmente, além de contar com o suporte de ferramentas específicas (DAM; WINIKOFF, 2012). Apesar desse crescimento, algumas características de sistemas multiagentes, como a questão da abertura, ainda não são adequadamente cobertas pelos métodos existentes.
Nesta tese, um SMA é visto como sendo composto por pelo menos três dimensões distintas: o conjunto de agentes, o ambiente no qual o sistema está inserido e uma ou mais organizações (DEMAZEAU,1995;BOISSIER et al.,2013). SMA são considerados abertos quando não se conhece, em tempo de desenvolvimento, todos os componentes de pelo menos uma das dimensões, mas esses elementos serão incluídos em tempo de execução. Assim, durante a execução, pode haver mudanças no conjunto de agentes, com a possibilidade de que agentes que não foram especificamente desenvolvidos para esse sistema possam participar dele; pode haver mudanças na estrutura e nas normas organizacionais, com novos papéis ou normas sendo incluídos, ou pode ser que o ambiente no qual
os agentes atuam seja modificado.
Por exemplo, em um sistema que gerencia leilões
on-line pode acontecer de não ser possível saber quais agentes
irão participar do leilão antes da execução do sistema, já que cada interessado no leilão pode desenvolver seu próprio agente e incluí-lo no sistema somente no momento da execução. Por isso, durante a análise e o projeto desse sistema, é possível definir as regras que irão gerenciar o leilão, como os agentes irão dar seus lances e as ferramentas e recursos que poderão ser utilizados pelos agentes. Mas não se pode especificar como os agentes serão, como eles irão se comportar ou o que eles sabem fazer. Mesmo assim, sem saber nada sobre esses agentes, é preciso garantir que o sistema funcione, que os agentes que desejem participar do leilão interajam uns com os outros e que os leilões sejam realizados de forma correta.
Sabendo que a abertura considera que nem todos os componentes do sistema sejam conhecidos na fase de projeto, pode-se constatar pelo menos dois problemas que dificultam a modelagem de SMA abertos nos métodos existentes. O primeiro é a dependência desses métodos com relação aos conceitos de agentes. Apesar de algumas tentativas de mudar o foco da modelagem do sistema para outras dimensões, os métodos ainda veem os SMA como um simples agrupamento de agentes e todas as características acabam por ser definidas por conceitos de agentes (mesmo que essa definição ocorra nas fases finais da especificação). Dessa forma, é difícil pensar no sistema sem pensar nos agentes. Essa dependência também obriga que as demais dimensões sejam conhecidas para que possam ser especificadas através de conceitos de agentes, como
33
planos, crenças e ações.
O segundo problema é a falta de mecanismos que definam explicitamente os conceitos que interligam as dimen-sões. Em parte, esse problema é uma consequência do fato de que os conceitos são encapsulados no agente, o que torna desnecessária a presença de informações sobre como o agente se relaciona com as demais dimensões. Por exemplo, com os protocolos de interação especificados, em forma de mensagens, diretamente nos planos do agente, não é necessário especificar de que forma esse agente pode conhecer o protocolo. Por outro lado, a falta de uma definição explícita de como as dimensões são interligadas em tempo de execução leva à necessidade de definir diretamente nas crenças do agente como ele deve interagir com as demais dimensões, como acontece com os pa-péis organizacionais. A falta de um modo de especificar o que aquele papel faz e quais conhecimentos são necessários para desempenhá-lo, de forma que qualquer agente possa decidir se deve ou não assumir esse papel em tempo de execução, faz com que seja necessário definir explicitamente no agente qual papel ele deve assumir.
Diante disso, pode-se considerar que um método ade-quado à modelagem de SMA abertos precisa permitir a especi-ficação de cada dimensão através de seus próprios conceitos, de forma que uma dimensão possa existir sem que outra também precise ser especificada, bem como a especificação de conceitos que forneçam informações, em tempo de desenvolvimento, que permitam a integração dos elementos abertos em tempo de execução. Assim, mesmo que uma das dimensões não seja conhecida durante a especificação do sistema, esta dimensão
ausente será considerada durante a especificação das demais dimensões e contará com informações que auxiliarão na sua integração.
A modelagem dos sistemas abertos é importante para auxiliar na resolução de problemas complexos, nos quais nem todos as dimensões são conhecidas durante as fases de aná-lise e projeto. Esse tipo de problema tem se tornado cada vez mais comuns com a popularização da internet. Como os métodos não oferecem mecanismos que permitam lidar com essa característica, o desenvolvimento desse tipo de sistema acaba sendo confuso e custoso, além de não contribuir para a qualidade do produto final. Assim, o desenvolvimento de um método mais adequado à especificação dos sistemas abertos deve favorecer a área de engenharia de software orientada a agentes (AOSE), provendo mecanismos que permitam auxi-liar no desenvolvimento desse tipo de software e aumentar a qualidade oferecida por essas soluções.
1.1 PROBLEMA E HIPÓTESE DE PESQUISA
Os métodos atuais existentes na área de AOSE não contribuem para a especificação das dimensões do SMA in-dependentemente. Isso dificulta e até mesmo impede a mode-lagem de sistemas abertos, já que nesse tipo de sistema uma ou mais dessas dimensões não é desenvolvida juntamente com o sistema. Com base nisso, investigamos a hipótese de que um método que permita que os conceitos e as abstrações de cada dimensão sejam especificados independente das outras dimensões, desde as fases iniciais até a implementação do sistema, contribui para a especificação dos sistemas abertos.
1.2. Objetivos 35
1.2 OBJETIVOS
Este trabalho tem como principal objetivo desenvol-ver um método que auxilie o desenvolvimento de SMA abertos, de forma que cada dimensão seja especificada através de con-ceitos e abstrações próprios - sem depender da definição de outras dimensões - e também forneça, em tempo de desenvolvi-mento, informações que auxiliarão a integração das dimensões abertas em tempo de execução.
Além desse objetivo principal, os seguintes objetivos secundários também serão atingidos:
• Análise do conceito de abertura e definição de um con-ceito que leve em conta a possibilidade de abertura em todas as dimensões do SMA.
• Definição dos conceitos de borda, que permitem a inter-ligação entre as dimensões do SMA.
Além disso, o método precisa apresentar algumas ca-racterísticas que são relevantes no desenvolvimento de sistemas abertos, a saber:
• Seguindo uma visão mais completa da questão da aber-tura em SMA, o método proposto deve permitir a espe-cificação de SMA que apresentem abertura em qualquer uma das suas dimensões.
• O método também deve permitir a especificação de siste-mas nos quais uma ou mais dimensões são inexistentes, ou seja, não serão especificadas.
1.3 CONTRIBUIÇÕES
Duas contribuições importantes para a área de AOSE são esperadas com o desenvolvimento desse trabalho. A pri-meira é a definição de um método que permita a análise e o projeto de SMA abertos, um problema para o qual ainda não foi proposta uma solução satisfatória. Além da abertura do conjunto de agentes, que os demais métodos tentaram soluci-onar, esse trabalho também leva em conta a possibilidade de que outros componentes do SMA sejam alterados em tempo de execução, o que permite diversos tipos de abertura.
A segunda contribuição é a definição de um método que permita a análise e o projeto de três dimensões do SMA (agente, ambiente e organização), cada uma utilizando concei-tos e abstrações próprias. Essa abordagem vem ao encontro do que tem sido proposto pelas novas plataformas de de-senvolvimento de SMA, que têm levado em conta não só a implementação do agente mas também das outras dimensões.
Além disso, esse trabalho apresenta um método que auxilia a lidar com a complexidade de SMA abertos, contri-buindo significativamente para a aceitação do paradigma de agentes e seu uso na indústria.
1.4 METODOLOGIA
A pesquisa para esse trabalho foi desenvolvida em etapas. A primeira consiste na revisão da literatura e avaliação do estado da arte, levando em conta conceitos relativos aos SMA abertos e métodos orientados a agentes. Nessa etapa, o
1.4. Metodologia 37
objetivo foi analisar os conceitos e definições envolvidos na área de sistemas multiagentes abertos, bem como verificar os trabalhos existentes na área e como eles se relacionam com essa tese.
Com base nessa análise um novo conceito de abertura, mais abrangente e que inclui as diversas dimensões do SMA foi definido. Essa nova definição norteou a especificação do método Open AEOlus e dos conceitos. A terceira etapa da pesquisa consistiu da definição dos conceitos presentes em cada um dos modelos e como esses conceitos se relacionam uns com outros ao longo das fases de desenvolvimento do método. Optou-se por definir três modelos diferentes, um para cada fase. Seguindo o proposto pela engenharia orientada a modelos (MDE ) (KENT,2002;SCHMIDT,2006), cada fase do método utiliza um conjunto diferente de conceitos que vão sendo detalhados para permitir a geração de código a partir desses modelos. Dessa forma, na fase de análise não se utilizam conceitos computacionais, na fase de projeto os conceitos não são dependentes de plataforma de implementação e na fase de implementação são refinados para permitir a geração de código em uma plataforma de destino específica.
Com os modelos definidos, a etapa seguinte consistiu na definição das atividades e work products que compõem o método. Por fim, o método foi utilizado no desenvolvimento de cenários exemplos juntamente com duas turmas de alunos da pós-graduação. Os alunos auxiliaram na organização das atividades do método e no refinamento dos work products, principalmente naqueles utilizados na fase de projeto.
1.5 ESTRUTURA DO TEXTO
Esta dissertação está dividida sete capítulos. No ca-pítulo 2 uma revisão bibliográfica apresenta os principais conceitos referentes aos agentes, sistemas multiagentes e siste-mas multiagentes abertos que serão utilizados no decorrer do texto. No capítulo3é feita uma revisão dos métodos orien-tados a agentes e como esses métodos lidam com a questão da abertura. No capítulo4são apresentados os conceitos de abertura em sistemas multiagentes da forma como eles serão propostos nesse trabalho. No capítulo5são apresentados os metamodelos sobre os quais o método Open AEOlus foi defi-nido e no capítulo6 o método é descrito, com suas fases e os
work products gerados. No capítulo7são apresentados dois
cenários-exemplos que ilustram o funcionamento do método com diferentes tipos de abertura. Por fim, no capítulo8são apresentadas considerações finais sobre o trabalho desenvol-vido.
39
2 SISTEMAS MULTIAGENTES ABERTOS
Sistemas multiagentes têm sido utilizados para solu-ção de diversos problemas complexos. Um tipo especial de sistemas multiagentes é o sistema aberto. Nesse capítulo, o objetivo é apresentar uma visão geral sobre os sistemas multi-agentes e a questão de abertura nesse tipo de sistema. Assim, na seção2.1será apresentada a definição de sistemas multia-gentes e as dimensões que o compõem. A dimensão dos amultia-gentes será apresentada na seção 2.2. Na seção2.3será apresentada a dimensão do ambiente e a dimensão da organização é apre-sentada na seção2.4. Na seção2.6será apresentado o conceito clássico de abertura e na seção 2.7 são apresentados alguns trabalhos que lidam com questões relacionadas a abertura em sistemas multiagentes.
2.1 SISTEMAS MULTIAGENTES
Um sistema multiagente pode ser definido como um “conjunto organizado de agentes” (BRIOT; DEMAZEAU; GASSER,
2001;DALPIAZ et al.,2010). Agentes são entidades autônomas que estão situadas em um ambiente e interagem entre si para atingir seus objetivos (WOOLDRIDGE, 2009). Um sistema é tradicionalmente definido com sendo “um conjunto organi-zado de elementos dinamicamente relacionados que trabalham para alcançar um objetivo ou uma finalidade” (BERTALANFFY, 1950;CHIAVENATO,2001). Assim, quando os elementos dina-micamente relacionados que compõe o sistema são os agentes, tem-se um SMA (STERLING; TAVETER,2009).
Alguns pesquisadores concebem os SMA como tendo três principais componentes ou dimensões: os agentes (A), o
ambiente (E ) e a organização (O)(BOISSIER et al.,2013). Os
agentes representam as entidades autônomas que fazem parte
do sistema e que agem em prol de seus objetivos. Esses agen-tes estão situados em um ambiente comum, juntamente com objetos (entidades passivas) que fornecem funcionalidades e serviços que auxiliam nas suas atividades e podem ser manipu-ladas por eles (BRIOT; DEMAZEAU; GASSER,2001;BOISSIER et al.,2013). Cada agente conhece somente uma parte do ambi-ente e dos agambi-entes com os quais compartilha esse ambiambi-ente, o que faz com que os SMA sejam intrinsecamente decentraliza-dos (BRIOT; DEMAZEAU; GASSER,2001;WOOLDRIDGE,2009). A organização define as regras de convivência que estruturam a coexistência dos agentes no ambiente comum e o trabalho coletivo, como protocolos de interação e coordenação, a di-visão dos recursos, a dependência entre tarefas, etc. Em um SMA podem existir diversas organizações e um mesmo agente pode fazer parte de várias delas simultaneamente (BRIOT; DEMAZEAU; GASSER, 2001).
Dessa forma, um SMA pode ser desenvolvido a par-tir da seleção do modelo computacional mais adequado para representar cada uma de suas dimensões (DEMAZEAU,1995) e para cada sistema uma combinação diferente dessas dimen-sões pode ser levada em conta. Por exemplo, um sistema que gerencie leilões on-line pode ser composto pela dimensão da organização, que define as regras que permitem aos agentes darem lances e estabelecem quem será o ganhador do leilão, pela dimensão dos agentes, representando os participantes do
2.2. Os Agentes 41
leilão, e pela dimensão do ambiente, representando o placar onde os lances são computados e o ganhador é apresentado. Por outro lado, um sistema de gerenciamento escolar pode ser composto somente pela dimensão dos agentes, representando professores e alunos, e pela dimensão da organização, que es-tabelece as normas que ajustam o comportamento dos agentes enquanto desempenham os papéis de alunos ou professores nesses sistemas.
2.2 OS AGENTES
Um agente pode ser definido como “um sistema computacional que está situado em um ambiente e pode agir autonomamente nesse ambiente para atingir seus ob-jetivos”(WOOLDRIDGE,2009). Agir autonomamente significa que o agente pode decidir qual ação será executada sem que seja necessária a intervenção humana ou de outros sistemas. As ações que o agente pode executar representam as mudan-ças que ele pode realizar em seu ambiente, sendo que cada ação depende de algumas precondições para ser executada (nem todas as ações podem ser executadas em todas as situ-ações). Devido à natureza não determinística do ambiente, uma mesma ação pode gerar resultados diferentes cada vez que for executada, podendo até mesmo ocorrer falhas durante sua execução (WOOLDRIDGE,2009).
Os agentes são chamados “inteligentes” quando apre-sentam também as características de reatividade, proatividade e habilidade social. Reatividade é a capacidade do agente de sentir o ambiente no qual está inserido e responder em tempo hábil às mudanças que ocorrem nesse ambiente, proatividade
é a capacidade de agir por iniciativa própria para atingir seus objetivos e habilidade social é a capacidade de interagir com outros agentes para que seus objetivos sejam atingidos (PADGHAM; WINIKOFF,2004;WOOLDRIDGE,2009).
Diversas arquiteturas foram propostas para o desen-volvimento de agentes. Algumas dessas arquiteturas são pu-ramente reativas, nas quais os agentes selecionam suas ações com base nas percepções do ambiente, ignorando o histórico de percepções anteriores, enquanto outras utilizam estruturas de dados internas que permitem aos agentes raciocinar com base no histórico das percepções recebidas ou até mesmo ma-nipular uma representação simbólica dos dados do ambiente no qual se encontra (RUSSELL; NORVIG,2009;WOOLDRIDGE, 2009).
Dessas arquiteturas, uma das mais conhecidas e estu-dadas é a arquitetura BDI (Belief-desire-intention)(GEORGEFF et al.,1999). Essa arquitetura tem suas raízes em um modelo humano de comportamento desenvolvido na área da filosofia por Bratman (1990). A ideia central é a de que os agentes decidem como agir com base em suas crenças (belief ), desejos (desire) e intenções (intention). Nesse processo, chamado raci-ocínio prático, crenças são as informações que o agente possui sobre o mundo, os desejos são estados do mundo que o agente gostaria de atingir e as intenções são estados do mundo em prol dos quais o agente decidiu trabalhar. As crenças podem ser informações sobre o ambiente, sobre outros agentes ou sobre o próprio agente e são adquiridas a partir das percepções que o agente tem do ambiente. Dessa forma, o agente pode ter crenças desatualizadas ou incorretas. Os desejos do agente
2.2. Os Agentes 43
são usados como base para selecionar suas intenções e podem ser incompatíveis entre si, já que ter um desejo não significa necessariamente que o agente vai tentar atingi-lo (BORDINI;
HÜBNER; WOOLDRIDGE,2007).
O processo de raciocínio prático acontece em duas fases: na primeira, chamada deliberação, o agente decide quais desejos devem se tornar intenções e na segunda, chamada
análise de meios-fins, o agente decide como essas intenções
são atingidas. Durante o processo de deliberação, o agente seleciona as intenções (também chamados objetivos) que ele irá tentar atingir. A seleção das desejos na fase de deliberação é feita com base nas crenças, nos desejos e nas intenções atuais do agente. Após, durante o processo de análise de meios-fins, o agente define um plano de ações (meios) que devem ser executadas para realizar uma determinada intenção (fim)(WOOLDRIDGE,2009;BORDINI; HÜBNER; WOOLDRIDGE, 2007).
Cada agente tem um conhecimento limitado sobre o ambiente e pode executar um conjunto limitado de ações (WOOLDRIDGE,2009). Por isso, sistemas compostos por um único agente são incomuns, sendo mais comum o uso de SMA, nos quais diversos agentes dividem um ambiente e interagem para atingir seus objetivos.
Uma grande quantidade de linguagens e platafor-mas especificas para o desenvolvimento de sisteplatafor-mas baseados em agentes são utilizadas atualmente, sendo que entre as mais conhecidas pode-se citar os frameworks JADE (
LAMERSDORF; POKAHR,2003) e as linguagens Jack (BUSETTA et al., 1999; WINIKOFF, 2005) e Jason (BORDINI; HÜBNER; WOOLDRIDGE, 2007). O trabalho de Bordini et al. (2009) traz informações sobre outras linguagens e plataformas para desenvolvimento de SMA. Nesse trabalho, será utilizado o
framework JaCaMo, que será detalhado na seção2.5.
2.3 O AMBIENTE
Diferentes visões de ambiente têm sido adotadas pela comunidade de agentes. Tradicionalmente, tudo o que é ex-terno ao SMA costuma ser visto como sendo parte do ambiente (RUSSELL; NORVIG,2003). O ambiente também é visto como um repositório de agentes e recursos ou simplesmente como um meio para a comunicação entre os agentes (WEYNS; PA-RUNAK; SHEHORY, 2009). Nessas visões, o ambiente é uma parte implícita do SMA e costuma ser tratado de uma forma
ad-hoc (MOLESINI; OMICINI; VIROLI,2009). Uma visão mais
recente (WEYNS; PARUNAK; SHEHORY,2009;RICCI; PIUNTI; VIROLI,2011) define o ambiente como uma abstração de pri-meira classe, ou seja, como uma parte do SMA que deve ser pensada e programada explicitamente. Nesse ponto de vista, o ambiente provê funcionalidades e serviços que são utiliza-dos pelos agentes. Essa visão permite a separação conceitual entre os agentes – que são as entidades autônomas do SMA e possuem objetivos a atingir – e o ambiente – entidades não autônomas cujas funcionalidades podem ser acessadas pelos agentes. Essas funcionalidades podem ser facilitadores para o acesso dos agentes aos recursos ou ao ambiente externo (outros sistemas, usuários, etc.), estruturas desenvolvidas
especifica-2.4. A Organização 45
mente para facilitar o trabalho dos agentes, ou mediadores e regulamentadores de comunicação entre os agentes, com propósitos organizacionais ou de coordenação (RICCI; PIUNTI; VIROLI, 2011).
Essa abordagem de ambiente como abstração de pri-meira classe foi utilizada no modelo de Agentes e Artefatos (A&A) (RICCI; VIROLI; OMICINI,2008). Nesse modelo, o am-biente é formado por um conjunto dinâmico de entidades computacionais chamadas de artefatos. Os artefatos represen-tam recursos ou ferramentas que os agentes podem utilizar e são organizados em um ou mais workspaces que podem ser distribuídos em nodos diferentes da rede. Para acessar um artefato, o agente precisa entrar no workspace ao qual o arte-fato pertence. Cada artearte-fato provê um conjunto de operações – que são processos computacionais executados interiormente pelo artefato – e um conjunto de propriedades observáveis. Uma operação pode ser disparada por um agente ou por outro artefato e sua execução pode alterar o valor de uma propriedade observável. Essas propriedades são variáveis cujo valor pode ser percebido pelos agentes quando estes estiverem observando o artefato. A execução da operação pode também gerar um sinal, que representa a ocorrência de um evento. Os agentes podem selecionar dinamicamente quais artefatos esta-rão observando e, assim, percebeesta-rão somente as propriedades observáveis e sinais gerados por esse conjunto de artefatos.
2.4 A ORGANIZAÇÃO
Se por um lado a autonomia permite que os agen-tes sejam utilizados para solucionar um conjunto variado
de problemas, a possibilidade de que cada agente haja de acordo com seus próprios objetivos individuais pode acabar levando o sistema a um comportamento indesejado. Como forma de garantir que o sistema atinja o objetivo para o qual foi desenvolvido, o sistema multiagente pode ser dotado de uma organização (HÜBNER; SICHMAN; BOISSIER,2007). Nesse sentido, uma organização é um conjunto de regras compor-tamentais que o agente aceita e adota quando passa a fazer parte do sistema. Essas regras facilitam as interações entre os agentes e que estes atinjam os objetivos globais e individuais
(DIGNUM; ALDEWERELD; DIGNUM,2011).
A organização pode ser dividida em partes, chamadas grupos (ou comunidades, departamentos, times, entre outros). O comportamento dos agentes dentro da organização, repre-sentado pelo papel que cada agente exerce nessa organização, está relacionado com a atividade da organização. Os tipos de relacionamentos entre os agentes são descritos em termos de relacionamentos entre os papéis, atividades e protocolos. Para cada papel, há um conjunto de restrições (normas, requisitos e aptidões) que o agente deve seguir e, assim, exercer aquele papel e usufruir dos seus benefícios (autorizações, lucros, ha-bilidades) (FERBER; GUTKNECHT; MICHEL,2003).
A organização em um SMA pode ser observada de duas formas. Em alguns sistemas – ditos centrados no agente – não existe uma representação explícita da organização. Essa representação está distribuída nos agentes, o que permite a um observador somente montar uma representação subjetiva da organização. Um formigueiro é um exemplo desse tipo de organização, no qual pode-se observar que existe uma
orga-2.5. JaCaMo 47
nização, mas não se pode obter uma descrição única, porque ela está distribuída e implícita no DNA das formigas que o compõem. Em outros sistemas, porém, pode-se obter uma des-crição da organização sem precisar observar o comportamento ou considerar os agentes que o compõem. Esses são sistemas centrados na organização. Os agentes também visualizam a organização sob dois pontos de vista. Em um deles os agentes são capazes de explicitamente representar a organização e de raciocinar sobre ela. Em outra, os agentes não são capazes disso (HÜBNER; SICHMAN; BOISSIER, 2002). Para permitir a representação da organização utilizada em um SMA, são utilizados modelos organizacionais, como o Moise(HÜBNER; SICHMAN; BOISSIER,2002).
2.5 JACAMO
O framework JaCaMo1 (BOISSIER et al., 2013) foi desenvolvido a partir da combinação de três tecnologias: a plataforma de desenvolvimento de sistemas multiagentes
Ja-son(BORDINI; HÜBNER; WOOLDRIDGE, 2007), o framework
para programação de ambientes baseados em artefatos CAr-tAgo (RICCI; VIROLI; OMICINI,2008) e o modelo organizacional Moise (HÜBNER et al.,2010). O JaCaMo integra os conceitos das diferentes dimensões – agente, ambiente e organização – para obter um modelo que permite a programação simplifi-cada de SMA utilizando essas dimensões. Assim, um sistema desenvolvido em JaCaMo é composto por uma organização – desenvolvida em Moise– que organiza um conjunto de
tes – programados em Jason – trabalhando em um ambiente distribuído – programado em CArtAgo.
O Jason é um interpretador para uma extensão da linguagem AgentSpeak(L)(RAO,1996) que permite o desen-volvimento de agentes baseados na arquitetura BDI. O Jason provê algumas funcionalidades, como o uso de atos de fala na comunicação entre os agentes; possibilidade de utilizar anota-ção nos planos que permite uma elaborada seleanota-ção de funções; a customização, em linguagem Java, de diversos aspectos da plataforma (criação de funções, percepções, revisão de crenças, etc.).
O framework CArtAgo (RICCI; PIUNTI; VIROLI,2011) foi desenvolvido com base no modelo A&A e permite a imple-mentação e a execução de ambientes que utilizam o conceito de artefatos e sua integração com os agentes. Nesse framework, o ambiente é definido como abstração de primeira classe e a integração do agente com as entidades do ambiente é feita através de conceitos utilizados pelos agentes, como ações e percepções. Isso permite a modularização e a reusabilidade dos elementos do ambiente em diferentes aplicações. Além disso, os artefatos podem ser dinamicamente construídos, uti-lizados, substituídos ou adaptados pelos agentes, o que facilita a extensão e a adaptação do ambiente.
O Moise descreve a organização com base em três dimensões: estrutural, funcional e normativa. A dimensão es-trutural define como a organização está estruturada, levando em conta o nível individual (papéis), o nível coletivo (grupos) e o nível social (ligações de conhecimento, comunicação,
autori-2.6. Sistemas multiagentes abertos 49
dade e compatibilidade entre os papéis). A dimensão funcional determina como os objetivos globais são atingidos, através da decomposição destes em subobjetivos e do agrupamento em missões. Por fim, a dimensão normativa estabelece as permis-sões e obrigações entre os papéis e as mispermis-sões. Sempre que um agente escolhe exercer um papel em uma organização, este aceita as permissões e obrigações relacionadas àquele papel (HÜBNER et al., 2010).
A principal característica do JaCaMo para desenvol-vimento de SMA está na separação dos conceitos referentes a cada dimensão. Aspectos referentes aos agentes, ao ambi-ente e à organização são desenvolvidos utilizando abstrações específicas de cada dimensão, bem como linguagens correspon-dentes, o que contribui para o desenvolvimento de SMA com maior modularidade, reusabilidade, legibilidade, facilidade de extensão e manutenção do código.
2.6 SISTEMAS MULTIAGENTES ABERTOS
Normalmente, um SMA é dito aberto quando há a possibilidade de alteração, em tempo de execução, dos agentes que fazem parte desse sistema, com agentes podendo entrar e sair livremente (DEMAZEAU; COSTA, 1996; EIJK et al.,2000; JAMROGA; MESKI; SZRETER,2013;ARTIKIS; PITT,2009). Em um SMA aberto, o número de agentes em execução varia com o tempo e o sistema é povoado em tempo de execução por agentes heterogêneos. Essa heterogeneidade pode ser tanto em termos de arquitetura interna quanto em objetivos ou políticas, e se deve ao fato dos agentes poderem ser desenvolvidos por diferentes equipes de desenvolvedores, cada uma utilizando
uma linguagem de programação ou plataforma de agentes diferente. Além disso, não é possível garantir que os agentes apresentarão comportamento benevolente ou que irão agir em prol dos objetivos do sistema (HUYNH; JENNINGS; SHADBOLT, 2004;KAFFILLE; WIRTZ,2006).
Nos sistemas abertos normalmente não é possível que um agente tenha um conjunto completo de informações sobre os outros agentes que participam desse sistema, já que essa informação não está disponível (EIJK et al.,2000;HUYNH; JENNINGS; SHADBOLT, 2004; KAFFILLE; WIRTZ, 2006). Os agentes são completamente independentes e não é possível que um controle ou acesse diretamente o estado mental de outro agente, de forma que não é possível uma entidade central que controle ou puna os agentes (HUYNH; JENNINGS; SHADBOLT, 2004). Por isso, resultado das interações não é previsível, já que um agente pode escolher não responder a uma solicitação ou deliberadamente dar informações incorretas. Além disso, os agentes podem sair do sistema a qualquer momento, seja por falhas na sua execução ou por vontade própria (HUYNH; JENNINGS; SHADBOLT,2004;ARTIKIS; PITT, 2009).
SMA abertos precisam lidar com uma série de proble-mas que não existem em sistema fechados. Esses probleproble-mas costumam incluir a integração dos novos agentes em tempo de execução, já que os agentes não foram especificamente desen-volvidos para trabalhar em conjunto; tratamento de exceções que possam levar o sistema a um estado indesejável, seja pela saída voluntária de um agente do sistema, por uma falha na execução de um agente ou pelo comportamento intencional-mente malicioso que um agente possa apresentar; e questões
2.7. Desenvolvimento SMA Abertos 51
relacionadas a confiança e responsabilidades dos agentes (
DE-MAZEAU; COSTA, 1996; GONZALEZ-PALACIOS; LUCK, 2006;
DIGNUM et al.,2008;ARTIKIS; PITT,2009). Diversos trabalhos têm sido propostos para permitir o desenvolvimento de SMA abertos, levando em consideração diversos aspectos desse tipo de sistema. Alguns desses trabalhos são apresentados na seção a seguir.
2.7 DESENVOLVIMENTO SMA ABERTOS
Uma das abordagens para lidar com SMA abertos e garantir que os agentes trabalhem em conjunto e atinjam tanto seus objetivos individuais quanto os objetivos do sistema, é a definição explícita de uma organização. A organização define regras, objetivos e uma estrutura baseada em papéis e grupos, que descrevem o comportamento esperado do agente quando este passa a fazer parte do sistema (COUTINHO; SICHMAN; BOISSIER, 2005; ARGENTE; JULIAN; BOTTI, 2006;HÜBNER; BOISSIER; BORDINI, 2010). Entre essas abordagens, podem ser citados os modelos AGR (FERBER; GUTKNECHT; MICHEL, 2004), ISLANDER (ESTEVA; PADGET; SIERRA,2002), OperA (DIGNUM, 2004), Moise + (HÜBNER; SICHMAN; BOISSIER, 2007).
Os trabalho de (MAO; YU,2004;COUTINHO; SICHMAN; BOISSIER,2005;ISERN; SÁNCHEZ; MORENO,2011) focam no levantamento e na definição dos conceitos utilizados para ex-pressar a organização, como papel, grupo, sociedade, coalizão ou posição, enquanto no trabalho apresentado por Demazeau e Costa (1996), os autores se preocupam em definir formal-mente a noção da organização dinâmica em SMA. Para isso,
os autores também definiram outros conceitos relacionados, como eventos que afetam interna ou externamente o SMA, os conceitos de população e organização, além de diferenciar os dois termos.
No trabalho deGonzalez-Palacios e Luck(2006), os autores apresentam um modelo para especificação de SMA abertos que leva em conta os conceitos de papel, protocolo e organização. Para os autores, um SMA aberto é formado por quatro elementos: o conjunto dos elementos do sistema, o conjunto dos papéis, o conjunto de protocolos, o conjunto de serviços e um conjunto de restrições sociais. Os autores não levam em conta nenhuma particularidade de implementação, o que garante sua adequação para sistemas multiagentes abertos.
O trabalho deJamroga, Meski e Szreter(2013) apre-senta uma forma para medir a abertura de um SMA. Os autores afirmam que a abertura pode ser medida pela sim-plicidade com que se consegue incluir ou excluir agentes, ou, em outras palavras, o número de passos necessários para acomodar a nova condição do sistema. Nessa abordagem, a simplicidade da abertura está relacionada com o contexto no qual o agente precisa ser incluído ou excluído, como no caso de um sistema de trens e controladores, no qual é mais fácil adicionar um trem do que um controlador. Os autores utilizam um formalismo matemático baseado no conceito de sistemas modulares interpretativos (MIS) para definir de que forma a abertura poderá ser mensurada. A abordagem apresentada permite mensurar outros conceitos, como a complexidade das interações entre agentes e a complexidade geral do sistema. Os autores argumentam que a análise e o projeto de SMA
2.7. Desenvolvimento SMA Abertos 53
abertos tem que ser feito separando os conceitos que permitem a interação entre os agentes dos conceitos internos do agente.
Além da organização, as interações também são im-portantes para garantir a abertura nos SMA. Alguns trabalhos se preocupam em determinar como garantir a interação dos agentes em SMA abertos. Dalpiaz et al.(2010) apresenta um
framework para o desenvolvimento de agentes adaptativos.
Os autores utilizam o termo adaptação para descrever a pos-sibilidade de alterar a estratégia utilizada para atingir um objetivo quando a estratégia original se tornar obsoleta. Nesse caso, uma forma alternativa chamada variante será executada. O trabalho também utiliza o conceito de commitments para integração entre os agentes porque, segundo os autores, são mais adequados para sistemas abertos por representarem um comprometimento público entre agentes. Da mesma forma, o trabalho de Singh e Chopra(2010) também utiliza
commit-ments para descrever as interações entre agentes. Neste os
autores apresentam uma arquitetura que permite a definição de protocolos de alto nível que podem e padrões para definição de contratos de serviço.
Paurobally e Cunningham(2002) analisam os proble-mas existentes na definição e no uso de protocolos de interação em SMA. Os autores analisam os principais métodos para representação dos protocolos e concluem que não existe um método com semântica clara, expressiva e completa, que possa ser utilizado para expressar os protocolos. Além disso, os auto-res afirmam que não existe uma forma de garantir que todos os agentes envolvidos com um protocolo realmente o conhecem, concordam com ele e podem executá-lo e que também não
existem mecanismos para verificação de erros nos protocolos, seja em tempo de projeto ou em tempo de execução. Por fim, durante a execução dos protocolos, há uma dificuldade para determinar se um agente não responde ao protocolo por ter perdido a mensagem anterior ou por não ter conhecimento do protocolo que está sendo executado. Os autores também sugerem o uso de bibliotecas de protocolos e mecanismos que permitam que esses sejam executados, de forma a garantir que todos os agentes conheçam os mesmos protocolos.
No trabalho de Artikis(2012), o objetivo é definir uma infraestrutura para SMA abertos que permita a alteração de protocolos em tempo de execução. Essa infraestrutura foi definida a partir da linguagem de ação C+, usada para formalizar as especificações dinâmicas e também utiliza a ferramenta Ccalc para realizar uma verificação formal das propriedades do SMA.
O trabalho deDignum et al.(2008) trata da recepção de novos agentes e sua integração ao sistema através da utili-zação um agente de interface chamado IMA (agente mediador de instituição). Neste trabalho, os autores estão preocupados com os casos nos quais os agentes são heterogêneos e múltiplas instituições existem no SMA. O agente IMA mantém listas com informações sobre os agentes e as instituições que estão presentes no sistema. Qualquer nova instituição ou agente deve ser registrado junto ao IMA, que fornece informações sobre a compatibilidade entre os agentes e as instituições, definindo quais papéis podem ser assumidos por cada agente, qual a compatibilidade de protocolos, etc.
2.8. Considerações 55
No trabalho de (TEUSSOP,2011), o gerenciamento da entrada e saída de agentes é feito através de portais. A cada portal estão associadas portas que se ligam a papéis, missões ou objetivos do SMA. Essas portas são representadas por agentes organizacionais. Assim, a entrada do agente é feita em duas etapas: candidatura, onde será analisado se oa gente pode ou não acessar a porta, e contratação, onde são negociadas as cláusulas e criados os contratos e estes são criados. Quando um agente deseja deixar o sistema, é necessário que ele faça uma requisição de saída. Sua saída será permitida caso os contratos assumidos tenham sido cumpridos.
2.8 CONSIDERAÇÕES
Neste capítulo foram apresentados os conceitos refe-rentes aos agentes e os SMA em geral. Também foi apresentada a definição clássica de sistemas abertos, que são aqueles siste-mas dos quais agentes podem entrar e sair livremente durante a execução. SMA abertos acabam lidando com uma série de problemas específicos, que não são comuns aos sistemas fecha-dos. Além disso, nesse capítulo também foram apresentados alguns trabalhos relacionados ao desenvolvimento de siste-mas multiagentes abertos, levando em consideração diversos aspectos desse tipo de sistema. No próximo capítulo serão analisados alguns métodos que permitem a modelagem e a especificação de SMA para verificar como esses métodos lidam com a questão da abertura.
57
3 ENGENHARIA DE SOFTWARE PARA SISTE-MAS ABERTOS
O principal objetivo desse capítulo é analisar os mé-todos existentes na área de engenharia de software orientada a agentes e verificar como esses métodos lidam com as dife-rentes dimensões do SMA. Na seção3.1 alguns dos métodos mais conhecidos desenvolvidos na área serão analisados para verificar como os conceitos de cada dimensão são tratados ao longo das fases de desenvolvimento do método. Na seção3.2 uma discussão sobre esses métodos será conduzida.
3.1 MÉTODOS ORIENTADOS A AGENTES
Nas próximas seções alguns métodos bem conhecidos da área de AOSE serão analisados com foco em quais dimen-sões do SMA são modeladas em cada fase. Após, uma breve discussão sobre como esses métodos lidam com as diferentes dimensões e como se relacionam com a abertura é conduzida.
3.1.1 ADELFE
O método ADELFE (Atelier de DÉveloppement de Logiciels à Fonctionnalité Emergente)(BERNON et al., 2002; BERNON et al.,2005) permite o desenvolvimento de SMA com-plexos, dinâmicos, abertos e adaptativos. ADELFE tem por base o processo do método RUP1, no qual atividades específi-cas para modelar sistemas multiagentes foram incluídas. São quatro as fases do processo: requisitos iniciais, requisitos finais, análise e projeto. A fase de requisitos iniciais se preocupa com
o levantamento dos requisitos do sistema e da validação destes. Na fase de requisitos finais, o objetivo é a caracterização do ambiente, dos casos de uso e das interfaces gráficas. Para caracterizar o ambiente, são definidas as entidades (atores externos ou recursos) e como elas interagem com o sistema, além de descrever o ambiente com base em suas características (acessível ou não-acessível, determinista ou não-determinista, contínuo ou discreto, dinâmico ou estático). A definição dos casos de uso leva em conta o ponto de vista do usuário e deve incluir informações sobre como o sistema reage a eventos inesperados ou a falhas de execução. A caracterização das interfaces se dá pela criação de protótipos de interfaces para validação. Com isso, uma versão inicial do diagrama de classes que define as classes modeladas no sistema, é definida.
Na fase de análise, uma atividade para verificar se o sistema possui as características necessárias para ser imple-mentado como um sistema adaptativo é realizada. Em caso positivo, o método continua com a identificação de quais agen-tes compõem o sistema, como eles interagem entre si e com as entidades externa, a definição dos pacotes e das classes que compõem o sistema. Por fim, na fase de projeto, os protocolos de comunicação entre agentes são especificados, bem como os agentes e suas características. Os agentes são definidos em termos do conhecimento necessário para executar as ações (skills), capacidade necessária para raciocinar sobre esse co-nhecimento (aptitude) e situações nas quais a cooperação pode não ser atingida. Nessa fase, com auxílio das ferramentas que fazem parte do ADELFE Toolkit2, também é possível realizar
3.1. Métodos orientados a agentes 59
a simulação de algumas funcionalidades do sistema.
3.1.2 ASPECS
ASPECS(COSSENTINO et al., 2010)3 define um pro-cesso para o desenvolvimento de software que permite a análise, o projeto e o desenvolvimento de sistemas multiagentes holô-nicos (HMAS) . Um hólon é uma estrutura coerente que é composta de hólons e ao mesmo tempo compõe um hólon maior. Dependendo do ponto de vista, um hólon pode ser visto tanto como uma entidade atômica quanto como uma organização de hólons, o que costuma ser chamado de efeito Janus (KOESTLER, 1967). Uma organização hierárquica de hólons é chamada holarquia. Num HMAS, os hólons são com-postos por agentes e são usados para o desenvolvimento de sistemas de software complexos.
O ASPECS foi desenvolvido a partir dos métodos PASSI (COSSENTINO, 2005) e RIO (HILAIRE et al.,2000) e a plataforma Janus4 foi utilizada para permitir a implementa-ção e o desenvolvimento dos sistemas. O ASPECS utiliza uma versão estendida da UML como linguagem de modelagem, na qual conceitos específicos dos SMA e dos HMAS foram incluídos, e define um processo interativo e incremental, na qual o desenvolvimento é divido em fases, tarefas e atividades. Além disso, inspirado pela abordagem da MDA, o ASPECS define três níveis de modelos, cada um representado por um metamodelo que é chamado domínio: o domínio do problema, que provê conceitos do domínio do problema
independente-3 <http://www.aspecs.org/> 4 <http://www.janus-project.org/>
mente de uma solução computacional; o domínio do agente, que introduz conceitos relativos à solução multiagente e holô-nica; e o domínio da solução, que fornece conceitos específicos da implementação da solução. O processo do ASPECS define três fases de desenvolvimento: a fase de análise dos requisitos, que se utiliza dos conceitos definidos no domínio do problema; a fase de projeto da sociedade de agentes, que utiliza os concei-tos definidos no domínio do agente; e a fase de implementação e implantação, que utiliza os conceitos do domínio da solução.
Na fase de análise dos requisitos, o principal objetivo é prover uma descrição completa do problema a ser resolvido. Essa fase inclui sete atividades que se preocupam com a definição das funcionalidades; a definição da ontologia que descreve o domínio do problema; a definição das organizações, dos papéis, de cenários de interação; definição dos planos usados pelos papeis para cumprir suas funcionalidades; e definição das competências, que apresentam a descrição do que uma organização deve fazer, sem apresentar as estratégias.
Na fase de projeto da sociedade de agentes o objetivo é apresentar uma solução efetiva para o problema, apresen-tando um modelo para a sociedade de agentes. Essa fase conta com 10 atividades sendo que na última a sociedade é transfor-mada numa holarquia. As atividades dessa fase compreendem o refinamento da ontologia; a definição dos agentes e suas res-ponsabilidades; definição dos papeis e competências requeridos para cada agente; descrição da ontologia das comunicações que serão feitas entre os agentes; representação do ciclo de vida dos agente com base nas ações que eles farão; relacio-namento das organizações e papéis com suas competências e
3.1. Métodos orientados a agentes 61
serviços que são executados; identificação das restrições entre os papéis; definição das estratégias de adoção de papéis pelos agentes; e, por fim, a definição da holarquia que compreende o mapeamento das entidades em hólons, a definição das regras que regem as relações dentro de cada super-hólon e a definição das regras que governam a dinâmica do sistema.
Na fase de implementação e implantação, o objetivo é adaptar a solução para a plataforma de implementação es-colhida, neste caso, a plataforma Janus. As atividades dessa fase são a definição dos papéis e das competências de cada hólon; a inclusão de códigos pré-existentes que serão reutili-zados; a codificação e os testes dos papéis, das organizações e dos hólons; a descrição das configurações de implantação, localização física do sistema, dados da rede, etc; e os testes finais do sistema como um todo.
3.1.3 GORMAS
O GORMAS (Guidelines for Organizational Multi-Agent Systems)(ARGENTE; BOTTI; JULIáN,2009) é centrado na especificação de organizações virtuais e foi desenvolvido com base num método específico para descrever organizações humanas. Uma organização virtual representa um conjunto de entidades e instituições que precisam coordenar recursos e serviços. Esse método é composto pelas fases de análise e projeto. A fase de análise é composta por análise das missões e análise dos serviços, enquanto a fase de projeto é composta por projeto organizacional e projeto organizacional dinâmico. Na fase de implementação, os autores sugerem a geração de código para o framework Thomas (ARGENTE et al.,2011).
