ads:
MINIST
´
ERIO DA DEFESA
EX
´
ERCITO BRASILEIRO
DEPARTAMENTO DE CI
ˆ
ENCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAC¸
˜
AO
JO
˜
AO ALBERTO NEVES DOS SANTOS FILHO
ASPECTUALJADE: UMA PLATAFORMA PARA O
DESENVOLVIMENTO DE SISTEMAS MULTI-AGENTES COM
MODULARIZAC¸
˜
AO DE CARACTER
´
ISTICAS TRANSVERSAIS
Rio de Janeiro
2007
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
INSTITUTO MILITAR DE ENGENHARIA
JO
˜
AO ALBERTO NEVES DOS SANTOS FILHO
ASPECTUALJADE: UMA PLATAFORMA PARA O
DESENVOLVIMENTO DE SISTEMAS MULTI-AGENTES COM
MODULARIZAC¸
˜
AO DE CARACTER
´
ISTICAS TRANSVERSAIS
Disserta¸c˜ao de Mestrado apresentada ao Curso de
Mestrado em Sistemas e Computa¸c˜ao do Instituto Mili-
tar de Engenharia, como requisito parcial para obten¸c˜ao
do t´ıtulo de Mestre em Sistemas e Computa¸c˜ao.
Orientador: Ricardo Choren Noya - DSc
Rio de Janeiro
2007
ads:
c
2007
INSTITUTO MILITAR DE ENGENHARIA
Pra¸ca General Tib´urcio, 80-Praia Vermelha
Rio de Janeiro-RJ CEP 22290-270
Este exemplar ´e de propriedade do Instituto Militar de Engenharia, que poder´a inclu´ı-
lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma
de arquivamento.
´
E permitida a men¸c˜ao, reprodu¸c˜ao parcial ou integral e a transmiss˜ao entre bibliotecas
deste trabalho, sem modifica¸c˜ao de seu texto, em qualquer meio que esteja ou venha a
ser fixado, para pesquisa acadˆemica, coment´arios e cita¸c˜oes, desde que sem finalidade
comercial e que seja feita a referˆencia bibliogr´afica completa.
Os conceitos expressos neste trabalho s˜ao de responsabilidade do autor e do orientador.
S237 Santos Filho, Jo˜ao Alberto Neves dos
AspectualJADE: Uma Plataforma para o Desen-
volvimento de Sistemas Multi-agentes com Modular-
iza¸c˜ao de Caracter´ısticas Transversais/ Jo˜ao Alberto
Neves dos Santos Filho.
– Rio de Janeiro: Instituto Militar de Engenharia, 2007.
133 p.: il., tab.
Disserta¸c˜ao (mestrado) – Instituto Militar de Enge-
nharia – Rio de Janeiro, 2007.
1. Sistemas Multi-agentes. 2. Aspectos. I. T´ıtulo. II.
Instituto Militar de Engenharia.
CDD 003.5
2
INSTITUTO MILITAR DE ENGENHARIA
JO
˜
AO ALBERTO NEVES DOS SANTOS FILHO
ASPECTUALJADE: UMA PLATAFORMA PARA O
DESENVOLVIMENTO DE SISTEMAS MULTI-AGENTES COM
MODULARIZAC¸
˜
AO DE CARACTER
´
ISTICAS TRANSVERSAIS
Disserta¸c˜ao de Mestrado apresentada ao Curso de Mestrado em Sistemas e Com-
puta¸c˜ao do Instituto Militar de Engenharia, como requisito parcial para obten¸c˜ao do
t´ıtulo de Mestre em Sistemas e Computa¸c˜ao.
Orientador: Ricardo Choren Noya - DSc
Aprovada em 21 de Dezembro de 2007 pela seguinte Banca Examinadora:
Ricardo Choren Noya - DSc do IME - Presidente
Prof. Arndt von Staa - Ph.D, da Puc-Rio
Prof. Raquel Coelho Gomes Pinto - DSc, do IME
Rio de Janeiro
2007
3
Dedico esta minha disserta¸c˜ao `a minha esposa. Tendo me casado
no meio da disserta¸c˜ao, demonstrou paciˆencia no decorrer de v´arias
noites que estive dedicado ao mestrado. Por diversas vezes me deu
for¸cas para ir em frente, sou muito grato por tˆe-la ao meu lado. Este
trabalho tamb´em ´e seu, te amo mais do que consiga imaginar.
4
AGRADECIMENTOS
Agrade¸co em primeiro lugar `a Deus, por ter me dado a oportunidade para fazer um
curso de mestrado em uma institui¸c˜ao respeitada. Agrade¸co `a minha esposa Bruna, por
todo o incentivo para seguir em frente e por ser uma companheira de valor imensur´avel.
Aos meus pais, que me possibilitaram educa¸c˜ao, respeito e valoriza¸c˜ao `as pequenas coisas
da vida. Ao meu irm˜ao, amigo fiel `a quem tenho grande admira¸c˜ao. Aos meus familiares
e aos familiares de minha esposa, por todo o apoio que me deram em v´arios momentos
dif´ıceis e que torcem para o meu sucesso pessoal e profissional. Ao meu orientador Ricardo
Choren, por seus ensinamentos durante o curso e por toda a ajuda prestada, mesmo em
finais de semana e feriados.
`
A todos os meus amigos, que direta ou indiretamente con-
tribu´ıram para o sucesso deste trabalho.
`
A empresa Milestone-TI, por todo o incentivo e
compreens˜ao no cumprimento do mestrado.
Por fim, a todos os professores e funcion´arios do Departamento de Engenharia de
Sistemas (SE/8) do Instituto Militar de Engenharia.
Jo˜ao Alberto Neves dos Santos Filho
5
´
E melhor tentar e falhar, que preocupar-se e ver
a vida passar; ´e melhor tentar, ainda que em v˜ao,
que sentar-se fazendo nada at´e o final. Eu prefiro
na chuva caminhar, que em dias tristes em casa me
esconder. Prefiro ser feliz, embora louco, que em con-
formidade viver ...
Martin Luther King
6
SUM
´
ARIO
LISTA DE ILUSTRAC¸
˜
OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LISTA DE ABREVIATURAS E S
´
IMBOLOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 INTRODUC¸
˜
AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 O problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Estrutura da disserta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 FUNDAMENTAC¸
˜
AO TE
´
ORICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Sistemas Multi-Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Propriedades de Agˆencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Plataformas de Implementa¸c˜ao de SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Caracter´ısticas Transversais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Paradigma Orientado a Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Aspectos na modelagem de SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.1 “Modeling Multi-Agent Systems Using UML” (SILVA et al., 2006) . . . . . . . . . 30
3.1.2 “An Aspect-Oriented Modeling Framework for Designing Multi-Agent
Systems - AODM” (GARCIA et al., 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.3 “Agent Crosscutting Concerns Modeling Framework - ACROSS” (PERES,
2006a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Aspectos na implementa¸c˜ao de SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1 “Um Framework Orientado a Aspectos para a Mobilidade de Agentes
de Software - AspectM (Aspectizing Mobility)” (LOBATO, 2005) . . . . . . . . . . 39
3.2.2 “An Aspect-Based Approach for Developing Multi-Agent Object-Oriented
Systems” (GARCIA et al., 2001b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Discuss˜ao sobre trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 ASPECTUALJADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1 A abstra¸c˜ao modificada de agente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7
4.1.1 Desenvolvendo agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 A nova abstra¸c˜ao de aspecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 Desenvolvendo aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Relacionamentos transversais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 MERGE - REFINE e REDEFINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Considera¸c˜oes sobre o AspectualJADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1 O Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 A Modelagem do SMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Modelagem do OA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2 Modelagem do OLig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.3 Modelagem de aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.4 Modelagem do Crosscutting no n´ıvel de planos e a¸c˜oes . . . . . . . . . . . . . . . . . . . 63
5.3 Implementando o SMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.1 O Agente OA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.2 O Agente OLig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.3 O Aspecto Autonomia para o relacionamento horizontal merge . . . . . . . . . . . 67
5.3.4 O Aspecto Interatividade para o relacionamento horizontal add . . . . . . . . . . . 70
6 AGENTES E ASPECTOS NA ENGENHARIA DE SOFTWARE . 75
6.1 Corretude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Manutenabilidade e Evolu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 Transparˆencia e Quantifica¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 Visibilidade para o AspectualJADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7 CONCLUS
˜
OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1 Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8 REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9 AP
ˆ
ENDICE - LISTAGENS DE C
´
ODIGOS DE AGENTES . . . . . . . 95
8
10 AP
ˆ
ENDICE - LISTAGENS DE C
´
ODIGOS DE ASPECTOS . . . . . . 117
9
LISTA DE ILUSTRAC¸
˜
OES
FIG.2.1 C´odigo entrela¸cado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
FIG.2.2 C´odigo espalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
FIG.3.1 Estere´otipos de agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
FIG.3.2 Modelo de agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
FIG.3.3 Modelo de aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
FIG.3.4 Modelo de de incidˆencia de aspectos em agentes . . . . . . . . . . . . . . . . . . . . . 34
FIG.3.5 Dimens˜oes de crosscutting para o modelo de agentes . . . . . . . . . . . . . . . . . 35
FIG.3.6 Hierarquia entre abstra¸c˜oes de aspectos e agentes (PERES, 2006) . . . . . . 36
FIG.3.7 Composi¸c˜ao gr´afica dos relacionamentos horizontais para a com-
posi¸c˜ao de objetivos entre agentes e aspectos . . . . . . . . . . . . . . . . . . . . . . . 37
FIG.3.8 Exemplos de composi¸c˜ao gr´afica dos relacionamentos verticais ex-
istentes entre as abstra¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
FIG.3.9 Relacionamentos entre planos e a¸c˜oes, de aspectos para agentes . . . . . . . . 39
FIG.3.10 Aspecto Mobilidade definindo pontos de corte . . . . . . . . . . . . . . . . . . . . . . . 40
FIG.4.1 Determina¸c˜ao de condi¸c˜ao de parada no m´etodo evalCondition() . . . . . . 46
FIG.4.2 Exemplo de relacionamentos entre planos e suas a¸c˜oes e/ou sub-
planos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
FIG.4.3 Modifica¸c˜oes de relacionamentos verticais no JADE . . . . . . . . . . . . . . . . . . 47
FIG.4.4 Modifica¸c˜ao de comportamentos-filho conclu´ıdos no JADE . . . . . . . . . . . . 47
FIG.4.5 Modifica¸c˜ao para adicionar status “pronto” (done) no JADE . . . . . . . . . . 48
FIG.4.6 Exemplo de codifica¸c˜ao da a¸c˜ao espec´ıfica “Sugerir n˜ao atirarei” no
JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
FIG.4.7 Codifica¸c˜ao do plano ReacaoAoPedidoDeMTPlan . . . . . . . . . . . . . . . . . . . . 49
FIG.4.8 Codifica¸c˜ao do agente AnalisadorPedidoMTAgent . . . . . . . . . . . . . . . . . . . . 50
FIG.4.9 Modifica¸c˜oes de visibilidade no JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
FIG.4.10 Exemplo de a¸c˜ao que extende um plano que, por sua vez, extende
a entidade aspecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
FIG.4.11 Exemplo para o relacionamento REFINE BEFORE, atraves do
MERGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
FIG.4.12 Estrutura da perspectiva gen´erica para o relacionamento MERGE . . . . . 54
10
FIG.4.13 Estrutura da perspectiva de planos para o relacionamento MERGE . . . . 55
FIG.4.14 Diferen¸cas entre REFINE AROUND e REDEFINE na perspectiva
de a¸c˜oes para o relacionamento MERGE . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
FIG.5.1 Intera¸c˜ao entre agentes e usu´arios humanos, descritos pelo SMAC . . . . . . 60
FIG.5.2 Modelagem dos planos e a¸c˜oes associados ao objetivo “Buscar alvo” . . . . 61
FIG.5.3 Modelagem do plano e das a¸c˜oes associados ao objetivo “Pedir MT” . . . 61
FIG.5.4 Modelagem de planos em rela¸c˜ao `a seus respectivos objetivo . . . . . . . . . . 62
FIG.5.5 Planos e a¸c˜oes em rela¸c˜ao ao objetivo “Tomar decis˜oes” do aspecto
autonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
FIG.5.6 Planos e a¸c˜oes em rela¸c˜ao aos objetivos “Enviar mensagens” e “Re-
ceber mensagens” do aspecto interatividade . . . . . . . . . . . . . . . . . . . . . . . . 63
FIG.5.7 Crosscutting do aspecto autonomia no agente OA . . . . . . . . . . . . . . . . . . . 64
FIG.5.8 Crosscutting do aspecto interatividade no agente OLig . . . . . . . . . . . . . . . 65
FIG.5.9 A¸c˜ao “Sugerir Rea¸c˜ao” do agente OA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
FIG.5.10 Plano “Busca de Alvos” do agente OA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
FIG.5.11 Agente OA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
FIG.5.12 Plano “Autoriza¸c˜ao de Fogo” do agente OLig . . . . . . . . . . . . . . . . . . . . . . . 67
FIG.5.13 Agente OLig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
FIG.5.14 Verifica¸c˜ao de a¸c˜oes no agente OA a serem interceptados pelo as-
pecto Autonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
FIG.5.15 Adi¸c˜ao de relacionamentos em a¸c˜oes no agente OA no momento em
que s˜ao adicionados `a seus respectivos planos . . . . . . . . . . . . . . . . . . . . . . 70
FIG.5.16 Pointcuts para informar `a camada de a¸c˜oes do aspecto Autonomia
se a a¸c˜ao corrente do agente OA deve ser interceptada . . . . . . . . . . . . . . . 70
FIG.5.17 Assinaturas e controle de ordem de execu¸c˜oes de a¸c˜oes do aspecto
Autonomia, em a¸c˜oes do agente OA que devem ser interceptados . . . . . 71
FIG.5.18 Console com a¸c˜oes do aspecto Autonomia e do agente OA . . . . . . . . . . . . 72
FIG.5.19 Verifica¸c˜ao de planos, de acordo com o agente OLig, a serem inter-
ceptados pelo plano “Plano de envio de mensagens” do aspecto
Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
FIG.5.20 Verifica¸c˜ao de planos, de acordo com o agente OLig, a serem in-
terceptados pelo plano “Plano de recebimento de mensagens” do
aspecto Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11
FIG.5.21 Console com a¸c˜oes em planos do aspecto Interatividade e do agente
OLig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
FIG.6.1 Exemplo de wildcard em aspecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
12
LISTA DE ABREVIATURAS E S
´
IMBOLOS
ABREVIATURAS
ACROSS - Agent CROSScutting Concerns Modeling Framework
ADL - Architectural Description Language
POA - Programa¸c˜ao Orientada a Aspectos
API - Aplication Programming Inteface
BDI - Belief-Desire-Intention
DF - Directory Facilitator
FIPA - Foundation of Intelligent Physical Agents
GAC - Grupo de Artilharia e Campanha
IC - Interface de Crosscutting
IDE - Integrated Development Environment
IME - Instituto Militar de Engenharia
JADE - Java Agent DEvelopment
MT - Miss˜ao de Tiro
OA - Observador Avan¸cado
OLig - Oficial de Liga¸c˜ao
OMG - Object Management Group
OO - Orienta¸c˜ao `a Objetos
S/3 - Oficial de Opera¸c˜oes (Escal˜ao Unidade)
SMA - Sistemas Multiagentes
SMAC - Sistemas Multiagentes para Artilharia de Campanha
TAO - Tamming Agents and Objects
UML - Unified Modeling Language
XML - eXtensible Markup Language
13
RESUMO
Com o aumento da complexidade de sistemas, cada vez torna-se mais necess´aria a
presen¸ca de entidades que possuam a capacidade de autonomia, ou seja, a capacidade de
tomar decis˜oes sem a intera¸c˜ao humana ou de outros sistemas previamente desenvolvidos
para este fim. Para atender esta demanda, Sistemas Multi-agentes disponibilizam agentes,
que s˜ao entidades computacionais com comportamentos autˆononomos. A id´eia principal
de agentes em um sistema multi-agente ´e que um comportamento global inteligente possa
ser alcan¸cado a partir dos comportamentos individuais dos mesmos.
Funcionalidades de sistemas est˜ao sujeitos `a composi¸c˜ao expl´ıcita no decorrer de seus
respectivos desenvolvimentos, revelando c´odigo espalhado e entrela¸cado, principalmente
entre requisitos funcionais e n˜ao-funcionais. O paradigma de orienta¸c˜ao a aspectos procura
evitar este tipo de problema, oferecendo uma entidade chamada aspecto, de maneira que
a composi¸c˜ao entre m´odulos seja realizada fora do contexto da aplica¸c˜ao. Tais m´odulos
s˜ao conhecidos como caracer´ısticas transversais.
Este trabalho tem como objetivo apresentar a plataforma AspectualJADE para pro-
mover a modulariza¸c˜ao de caracter´ısticas transversais em sistemas multi-agentes, atrav´es
do paradigma de orienta¸c˜ao a aspectos. A plataforma AspectualJADE prop˜oe uma inte-
gra¸c˜ao entre o framework para desenvolvimento de agentes, o JADE, e a linguagem para
desenvolvimento de aspectos, o AspectJ. Al´em disso, provˆe um modelo de composi¸c˜ao
baseado nas abstra¸c˜oes, como agentes, aspectos, planos e a¸c˜oes; e nos relacionamentos
horizontais e verticais propostos pelo framework ACROSS. Uma prova de conceito foi
realizada para mostrar o modelo de composi¸c˜ao apresentado pela plataforma Aspectual-
JADE.
14
ABSTRACT
With the advances in Internet technologies, the complexity of application systems is
steadly increasing. In this sense, it is necessary to develop autonomous entites, such as
software agents, i.e. entities that have the ability to make decisions without human or
other systems’ intervention. In a multi-agent system (MAS), agents cooperate to achieve
a global behavior.
Systems funcionalities still are subject to an explicit composition. Crosscutting con-
cerns are aspects of a program which affect (crosscut) other concerns. These concerns often
cannot be cleanly decomposed from the rest of the system in both the design and imple-
mentation, and result in either scattering or tangling of the program, or both. Aspect-
oriented programming introduces the aspect entity in order to solve the scattering and
tagling problems.
This work presents the AspectualJADE agent development platform to allow the
composition of crosscutting concerns in MAS using aspects. AspectualJADE proposes
the integration of the JADE agent platform and the AspectJ extension to the Java pro-
gramming language for modularizing crosscutting concerns. The AspectualJADE pro-
vides a composition model based on agent-oriented abstractions, such as agents, plans
and actions and it uses the relationships defined by the ACROSS framework. To show
the composition model and the functionalities of AspectualJADE, a sample application
was developed.
15
1 INTRODUC¸
˜
AO
O desenvolvimento de software passou por diversas etapas durante sua evolu¸c˜ao, desde
sistemas com alto acoplamento de m´odulos, at´e sistemas que conseguiam representar enti-
dades do mundo real. Esse ´ultimo ganhou for¸ca com o paradigma de Orienta¸c˜ao a Objetos
(OO), pois seus conceitos permitem o desenvolvimento de sistemas mais complexos e ro-
bustos, al´em de facilitar a manuten¸c˜ao e o reuso de seus m´odulos.
Por´em, m´odulos de sistema s˜ao acionados atrav´es da intera¸c˜ao humana ou de sub-
sistemas previamente programados para este fim, pois estes sistemas n˜ao s˜ao capazes de
tomar decis˜oes, tendo em vista que os objetos da OO apenas respondem `as chamadas
externas que s˜ao requisitadas.
Para que entidades de software sejam capazes de tomar decis˜oes, independentemente
da intera¸c˜ao humana, devem ser constitu´ıdas em um ambiente de Sistemas multi-agentes
(SMA´s). Sistemas multi-agentes s˜ao compostos por entidades que possuem compor-
tamento diferenciado, quando comparados ao paradigma OO, pois constituem sistemas
autˆonomos, ou seja, provˆeem um paradigma para o desenvolvimento de software inde-
pendente de qualquer intera¸c˜ao externa, provendo ainda caracter´ısticas de aprendizado e
adapta¸c˜ao em ambientes para a colabora¸c˜ao entre entidades autˆonomas, conhecidas como
agentes.
Um agente pode ser caracterizado como uma entidade computacional com um com-
portamento autˆonomo que lhe permite decidir suas pr´oprias a¸c˜oes, de acordo com as
mudan¸cas que venham a ocorrer no ambiente em que se encontra. Assim como entidades,
ou objetos, s˜ao representados na orienta¸c˜ao a objetos como classes, em SMA as entidades
s˜ao caracterizadas como agentes.
Na preocupa¸c˜ao de pesquisadores de Engenharia de Software para a melhoria do reuso,
da compreens˜ao e da manuten¸c˜ao de sistemas de software, ´e apresentado o princ´ıpio da
separa¸c˜ao de interesses (concerns), ou ainda separa¸c˜ao de caracter´ısticas. Tal princ´ıpio
estabelece que um interesse pode ser decomposto em m´odulos que lidam, cada um, com
apenas um interesse indivis´ıvel (DIJKSTRA, 1976). O objetivo da decomposi¸c˜ao ´e lidar
com a complexidade de sistemas atrav´es da especifica¸c˜ao de abstra¸c˜oes e mecanismos que
permitam uma melhor decomposi¸c˜ao e modulariza¸c˜ao de sistemas (PARNAS, 1972).
16
Contudo, mesmo que seja poss´ıvel identificar m´odulos (ou interesses) indivis´ıveis em
sistemas, ainda assim h´a mistura entre interesses funcionais e n˜ao-funcionais, traduzindo-
se em requisitos que sofrem composi¸c˜ao expl´ıcita pelo desenvolvedor, diminuindo a possi-
bilidade de reuso de software e dificultando a manutenabilidade e compreens˜ao do contexto
envolvido. Tanto a orienta¸c˜ao a objetos quanto o paradigma de agentes de software n˜ao
s˜ao suficientes para a proje¸c˜ao e implementa¸c˜ao de interesses que est˜ao presentes em v´arios
m´odulos de um determinado sistema, chamados de caracter´ısticas transversais. Exemplos
de interesses, identificados principalmente como requisitos n˜ao-funcionais de sistemas, s˜ao
a defini¸c˜ao de logging, requisitos de autentica¸c˜ao e autoriza¸c˜ao, acesso `a bancos de dados
entre outros (KICZALES et al., 1997).
Al´em de requisitos n˜ao-funcionais, o comportamento autˆonomo de agentes abrange
caracter´ısticas de agˆencia que s˜ao definidas em SMA´s. Entre elas, encontram-se, por
exemplo, mobilidade (BELLIFEMINE et al., 2005), autonomia (COSSENTINO e ZAM-
BORELLI, 2004) e interatividade (CHEONG e WINIKOFF, 2006). A dificuldade em
se implementar caracter´ısticas transversais est´a na verifica¸c˜ao de especifica¸c˜oes (carac-
ter´ısticas de agˆencia) com problemas de c´odigo espalhado e entrela¸cado (KICZALES et al.,
1997), pois entrecortam transversalmente v´arios outros interesses ou caracter´ısticas de um
sistema.
1.1 O PROBLEMA
A tecnologia de aspectos apresenta-se como uma alternativa interessante na modulariza¸c˜ao
de requisitos n˜ao-funcionais e de caracter´ısticas de agˆencia, tidas como transversais em
SMA. No entanto, para que esta tecnologia possa, de fato, permitir a defini¸c˜ao de fun-
cionalidades ortogonais em SMA, o mesmo deve estar presente em todas as etapas do ciclo
de desenvolvimento de software, desde a an´alise de requisitos at´e a implementa¸c˜ao. Em
espec´ıfico para este trabalho, aspectos devem oferecer suporte suficiente na modulariza¸c˜ao
de caracter´ısticas transversais em SMA.
Quanto `as primeiras etapas (requisitos, modelagem), v´arias pesquisas tˆem apontado
para o estudo a respeito dos Early-Aspects (RASHID, 2002). Na identifica¸c˜ao de rele-
vantes caracter´ısticas transversais em SMA, sua concep¸c˜ao deve surgir desde as primeiras
etapas no ciclo de desenvolvimento de software, isto ´e, desde a an´alise de requisitos. Para
isso, existem diversos trabalhos, tais como (CHOREN e LUCENA, 2005), (ODELL et al.,
2000), (SILVA et al., 2004), (WOOLDRIDGE et al., 2000) e (PERES et al., 2006), buscam
17
a modelagem de caracter´ısticas transversais no contexto de agentes de software.
Dentre estes trabalhos, o de (PERES et al., 2006) especifica que aspectos devem incidir
em agentes atrav´es da modelagem de abstra¸c˜oes no mesmo n´ıvel e que tais abstra¸c˜oes
devem basear-se em conceitos de SMA, tais como objetivos, planos e a¸c˜oes. Isso quer
dizer que aspectos tamb´em devem beneficiar-se das abstra¸c˜oes de objetivos, planos e
a¸c˜oes, origin´arias dos conceitos de agentes de software. Adicionalmente, objetivos de
aspectos relacionam-se com objetivos de agentes, da mesma forma para os conceitos de
planos e a¸c˜oes.
Pode-se ver que, j´a para a fase de implementa¸c˜ao, existem plataformas que possuem o
objetivo de promover a modulariza¸c˜ao de caracter´ısticas transversais em SMA com aspec-
tos no n´ıvel de projeto e implementa¸c˜ao, por exemplo (LOBATO, 2005) e (GARCIA et al.,
2001b). (LOBATO, 2005) apresenta uma solu¸c˜ao pontual, relatando a modulariza¸c˜ao da
propriedade de mobilidade. J´a (GARCIA et al., 2001b) procura ser uma plataforma
gen´erica de modulariza¸c˜ao de caracter´ısticas transversais em SMA. No entanto, ela n˜ao
segue as especifica¸c˜oes FIPA (FIPA-OS, 2001) e mistura conceitos de OO com agentes.
Mesmo com a existˆencia de uma abordagem que trata agentes e aspectos no mesmo
n´ıvel de abstra¸c˜ao na fase de modelagem de sistemas, n˜ao h´a nenhuma proposta na litera-
tura que busque a mesma abordagem no n´ıvel de projeto detalhado e na implementa¸c˜ao.
Al´em disso, a separa¸c˜ao de interesses atrav´es de aspectos em SMA ´e poss´ıvel, mas a pro-
posta de (GARCIA, 2004) tamb´em mistura conceitos de objetos no paradigma de agentes
de software. O desenvolvedor de agentes, mesmo que possua abstra¸c˜oes de aspectos para
modelar aspectos, ´e obrigado a desenvolver agentes a partir de conceitos de objetos.
Logo, observa-se que n˜ao existem trabalhos no n´ıvel de projeto detalhado e imple-
menta¸c˜ao, que obede¸cam `as seguintes premissas: obten¸c˜ao de generaliza¸c˜ao a partir da
modulariza¸c˜ao de caracter´ısticas transversais em SMA com aspectos; oferecimento de uma
plataforma de acordo com as especifica¸c˜oes FIPA (FIPA-OS, 2001); tratamento de aspec-
tos e agentes a partir das mesmas abstra¸c˜oes provenientes do paradigma de SMA; impedir
a mistura de conceitos da orienta¸c˜ao a objetos, tanto no paradigma de agentes, quanto
no de aspectos; e transforma¸c˜ao de modelos na etapa de requisitos em representa¸c˜oes nos
n´ıveis de projeto detalhado e implementa¸c˜ao.
18
1.2 OBJETIVOS
Este trabalho se prop˜oe a oferecer uma plataforma para o desenvolvimento de SMA com
caracter´ısticas transversais modularizadas em aspectos. A plataforma sugerida visa tratar
aspectos no mesmo n´ıvel que agentes de software, isto ´e, aspectos devem ser descritos com
planos e a¸c˜oes, e os pontos de jun¸c˜ao devem descrever a incidˆencia de planos ou a¸c˜oes
de aspectos sobre planos ou a¸c˜oes de agentes, respectivamente.
´
E necess´ario, ent˜ao, a
especifica¸c˜ao da decomposi¸c˜ao de agentes em planos e a¸c˜oes atrav´es da modifica¸c˜ao de
alguma plataforma de desenvolvimento que esteja de acordo com as especifica¸c˜oes FIPA
(FIPA-OS, 2001).
A POA ´e o paradigma escolhido para a modulariza¸c˜ao de caracter´ısticas transversais
em SMA, pois possui conceitos que se aplicam `a separa¸c˜ao de propriedades de agentes
(ou m´odulos n˜ao-funcionais) de m´odulos espec´ıficos de sistemas, m´odulos funcionais,
evitando-se o c´odigo espalhado e entrela¸cado (KICZALES et al., 1997). Para isso, as-
pectos apresentam-se como uma alternativa vi´avel, atrav´es de seus conceitos, como join
points, pointcuts e advices, provenientes da utiliza¸c˜ao da linguagem de aspectos AspectJ
(KICZALES et al., 2001), na determina¸c˜ao de mecanismos de crosscutting para a in-
cidˆencia em agentes a partir dos mesmos n´ıveis de abstra¸c˜oes.
Este trabalho preocupa-se, ainda, com a rastreabilidade entre artefatos de especifica¸c˜ao
de SMA com aspectos e a implementa¸c˜ao. Isto permite a orienta¸c˜ao ao desenvolvedor a
fim de criar consistˆencia ao longo do projeto do SMA.
1.3 CONTRIBUIC¸
˜
OES
As contribui¸c˜oes deste trabalho s˜ao:
• Preparar o framework JADE para tornar poss´ıvel a implementa¸c˜ao de abstra¸c˜oes
de planos e a¸c˜oes, assim como os relacionamentos verticais entre eles;
• Apresentar a plataforma AspectualJADE, uma proposta de integra¸c˜ao entre agentes
e aspectos, dos quais estabelecem um elo de comunica¸c˜ao de acordo com os mesmos
n´ıveis de abstra¸c˜oes;
• Reaproveitamento de abstra¸c˜oes e relacionamentos entre aspectos e agentes, definidos
no framework ACROSS (PERES, 2006) em n´ıvel de projeto detalhado para o As-
pectualJADE, possibilitando a gera¸c˜ao parcial de c´odigos de planos e a¸c˜oes;
19
• Apresentar o Estudo de Caso baseado na pesquisa de (PERES, 2006), para ilustrar
o uso de AspectualJADE, a fim de mostrar as abstra¸c˜oes e os relacionamentos entre
agentes e aspectos no n´ıvel de implementa¸c˜ao.
1.4 ESTRUTURA DA DISSERTAC¸
˜
AO
Esta disserta¸c˜ao est´a estruturada de maneira que o cap´ıtulo 2 descreve toda a funda-
menta¸c˜ao te´orica necess´aria para o entendimento da pesquisa, conduzindo o leitor `a com-
preens˜ao do problema apresentado e `a an´alise posterior da proposta de solu¸c˜ao.
O cap´ıtulo 3 apresenta v´arios trabalhos relacionados `a corrente pesquisa, ou seja,
modulariza¸c˜ao de caracter´ısticas transversais em sistemas multi-agentes. No decorrer da
descri¸c˜ao de tais trabalhos, s˜ao feitas compara¸c˜oes com o AspectualJADE, apresentando
as diferen¸cas identificadas, al´em das vantagens e desvantagens.
O cap´ıtulo 4 caracteriza-se como a se¸c˜ao principal da disserta¸c˜ao, pois apresenta a
contribui¸c˜ao do AspectualJADE para a modulariza¸c˜ao de caracter´ısticas transversais em
SMA´s, com base no framework ACROSS na modelagem de requisitos. Tomando-se como
base as abstra¸c˜oes e relacionamentos analisados no ACROSS, ´e detalhado o modelo de
composi¸c˜ao no n´ıvel de projeto detalhado, com o objetivo de orientar o desenvolvedor
de agentes `a incorporar o uso de caracter´ısticas transversais em SMA´s, beneficiando-se
do paradigma orientado `a aspectos para impedir o espalhamento e entrela¸camento de
interesses ortogonais, al´em de obstruir a mistura de conceitos de orienta¸c˜ao `a objetos no
contexto designado.
O cap´ıtulo 5 especifica a prova de conceito, descrevendo como deve ocorrer a aplica¸c˜ao
do modelo de composi¸c˜ao em alguns fragmentos do estudo de caso da disserta¸c˜ao de
Janilma (PERES, 2006), onde as abstra¸c˜oes e os relacionamentos s˜ao utilizados na imple-
menta¸c˜ao resultante da integra¸c˜ao do framework JADE (BELLIFEMINE et al., 2005) com
a linguagem de aspectos AspectJ (KICZALES et al., 2001). O estudo de caso ´e referente
`a um SMA de Comando e Controle voltado para a atua¸c˜ao da Artilharia de Campanha,
n´ıvel Brigada, em exerc´ıcios e opera¸c˜oes de combate. O objetivo deste cap´ıtulo ´e demons-
trar, na pr´atica, como o desenvolvedor de agentes pode criar e manter SMA´s a partir
do AspectualJADE. O cap´ıtulo 6 discute sobre a relevˆancia do desenvolvimento de SMA
apoiados por aspectos para caracter´ısticas da Engenharia de Software, tais como corre-
tude, manuten¸c˜ao, evolu¸c˜ao, transparˆencia (obliviousness) e quantifica¸c˜ao. Finalmente,
o cap´ıtulo 7 examina os resultados obtidos e de que maneira as contribui¸c˜oes apontadas
20
pelo ca´ıtulo 1 foram alcan¸cadas, al´em de sugest˜oes para trabalhos futuros e conclus˜ao.
21
2 FUNDAMENTAC¸
˜
AO TE
´
ORICA
Este cap´ıtulo visa demonstrar os principais conceitos tidos como base para a presente
disserta¸c˜ao. Desta forma, ser´a apresentada toda a fundamenta¸c˜ao te´orica que envolvem
sistemas multi-agentes, caracter´ısticas transversais e desenvolvimento orientado `a aspec-
tos.
2.1 SISTEMAS MULTI-AGENTES
A orienta¸c˜ao a agentes apresenta-se como um paradigma mais adequado ao desenvolvi-
mento de sistemas distribu´ıdos e que possuem subsistemas que interagem entre si (JEN-
NINGS e WOOLDRIDGE, 2001). Agentes de software s˜ao abstra¸c˜oes de mais alto n´ıvel
quando comparados ao paradigma orientado a objetos (YU, 2001), pois busca aproximar-
se de requisitos atrelados ao mundo real, j´a que entidades podem tomar decis˜oes e agir
conforme suas pr´oprias premissas.
O paradigma de agentes em SMA originou-se na Engenharia de Software a partir de
conceitos de Inteligˆencia Artificial (WOOLDRIDGE, 1997) que podem ou n˜ao ser uti-
lizadas, dependendo das caracter´ısticas de seus agentes (cognitivos, reativos ou h´ıbridos)
(WOOLDRIDGE, 2002). SMAs possibilitam que pesquisadores mantenham e criem enti-
dades autˆonomas, ou seja, que essas entidades sejam capazes de tomar decis˜oes sem qual-
quer interven¸c˜ao externa (humana ou computacional) (WOOLDRIDGE, 1997), tamb´em
conhecidas como agentes de software. Na orienta¸c˜ao a objetos ´e necess´ario que haja
alguma intera¸c˜ao para que os m´odulos de um sistema “entrem em a¸c˜ao”, al´em da impos-
sibilidade da existˆencia de outras caracter´ısticas que independam de ativa¸c˜ao atrav´es de
terceiros.
Na Engenharia de Software, agentes de software atuam em um ambiente onde intera-
gem com outros agentes e possuem a capacidade de se moverem para outros ambientes e
de executarem a¸c˜oes de maneira autˆonoma e flex´ıvel, buscando concretizar os objetivos a
que foram designados (JENNINGS e WOOLDRIDGE, 2001).
As principais asbtra¸c˜oes em SMA, de acordo com (PERES et al., 2006), s˜ao:
• Agente: ´e a entidade autˆonoma em si, ou seja, ´e a entidade de primeira classe,
22
constitu´ıda de um ou mais objetivos;
• Objetivo: constitui um estado a ser atingido pelo agente, ou seja, caracteriza-se
como um comportamento a ser atingido. Assim como agentes possuem objetivos,
os objetivos possuem um ou mais planos de execu¸c˜ao;
• Plano: agrupa as a¸c˜oes a serem perseguidas para que um agente atinja seu objetivo
determinado;
• A¸c˜ao: ´e basicamente a computa¸c˜ao atˆomica que proporciona a mudan¸ca de estados
em agentes, ou seja, especifica o processamento computacional a ser realizado.
Na verdade, um comportamento autˆonomo deve ser resultante da intera¸c˜ao entre as
abstra¸c˜oes especificadas, fornecendo ao pesquisador de SMA maior transparˆencia e fa-
cilidade de acompanhar o desenvolvimento de tais sistemas em todas as etapas do ciclo
de desenvolvimento de software. Comportamentos devem ser decompostos atrav´es de
abstra¸c˜oes com responsabilidades bem definidas.
A determina¸c˜ao de objetivos de agentes de software ocorre atrav´es de um conjunto
de axiomas (regras, leis ou princ´ıpios) que estabelecem comportamentos e pap´eis para
os agentes (SILVA et al., 2004). O ambiente em que tais agentes se encontram podem
influenciar diretamente nos conjuntos de axiomas em cada agente como, por exemplo, na
ordem de execu¸c˜ao de tarefas de agentes, analisando objetivos conflitantes entre agentes
e grau de importˆancia de cada agente naquele mesmo ambiente. Enfim, s˜ao discutidas as
propriedades que caracterizam o comportamento de agˆencia.
2.1.1 PROPRIEDADES DE AG
ˆ
ENCIA
Propriedades que caracterizam entidades como de agˆencia podem ser divididas em duas
categorias: propriedades b´asicas e adicionais, embora hajam divergˆencias entre autores
(WOOLDRIDGE, 1997) (GARCIA, 2004). As propriedades b´asicas s˜ao fundamentais
para a existˆencia de um agente de software, ou seja, sem ao menos uma delas, entidades
n˜ao podem ser qualificadas como agentes. As propriedades adicionais s˜ao tidas como
peculiares, ou seja, nem todo agente ´e capaz de herd´a-las.
As propriedades b´asicas s˜ao:
• Autonomia: ´e a propriedade mais importante de agentes, pois determina que agentes
podem tomar decis˜oes independentemente de qualquer chamada externa (humana
23
ou computacional) e executar a¸c˜oes que caracterizam seus comportamentos no mo-
mento em que julgar adequado;
• Pr´o-atividade: ´e a capacidade do agente possuir iniciativa pr´opria para o cumpri-
mento de seus objetivos (WOOLDRIDGE, 1997), reflexo da propriedade autonomia;
• Interatividade: ´e a habilidade de agentes interagirem uns com os outros, perseguindo
o prop´osito de atingirem seus pr´oprios objetivos. Os objetivos de agentes podem
depender da intera¸c˜ao entre si, atrav´es de trocas de mensagens (muitas vezes deter-
minadas pela linguagem padr˜ao de comunica¸c˜ao entre agentes, a ACL - Agent Com-
munication Language) ou ainda de intera¸c˜oes mais complexas, que podem envolver
situa¸c˜oes como, por exemplo, coopera¸c˜ao, coordena¸c˜ao e negocia¸c˜ao (JENNINGS e
WOOLDRIDGE, 2001);
• Estar situado: propriedade que garante ao agente a capacidade de percep¸c˜ao quanto
ao ambiente em que se encontra, interagindo com informa¸c˜oes decorrente deste
ambiente e agindo conforme sua autonomia determinar.
As propriedades b´asicas revelam funcionalidades comuns que devem obrigatoriamente
estar presentes em agentes de software, independentemente da existˆencia de regras es-
pec´ıficas em ambientes que podem estar inseridos. Por este motivo, estas propriedades
caracterizam-se como transversais, isto ´e, entrecortam as funcionalidades prescritas de re-
gras de neg´ocio de sistemas. Os conceitos de caracter´ısticas transversais ser˜ao discutidos
na se¸c˜ao 2.2.
Outras propriedades tamb´em podem caracterizar agentes adicionalmente:
• Adaptabilidade: ´e a capacidade conferida ao agente de adaptar-se `as mudan¸cas no
ambiente em que est´a situado ou aos objetivos de outros agentes (GARCIA et al.,
2001b), ou seja, o agente pode assumir compromisso com novos objetivos que possam
surgir.
• Aprendizado: ´e a possibilidade de um agente aprender com situa¸c˜oes e que utilize-
as como referˆencia para an´alise de decis˜oes em situa¸c˜oes futuras. O aprendizado
constitui basicamente na montagem de uma base hist´orica de situa¸c˜oes j´a ocorridas
e ´e aplicada ”inteligˆencia” nas pr´oximas decis˜oes baseadas neste hist´orico;
24
• Colabora¸c˜ao: possui como objetivo determinar como agentes cooperam entre si para
atingirem objetivos individuais ou de sistema (GARCIA et al., 2001b);
• Mobilidade: prop˜oe aos agentes a possibilidade de moverem-se de um ambiente a
outro, como programas que trafegam de uma rede `a outra, coletando informa¸c˜oes
para alcan¸carem seus objetivos. Investimentos vˆem sendo realizados na tecnologia
de agentes m´oveis, pois muitos pesquisadores e profissionais identificam agentes
como adequados `as aplica¸c˜oes de e-business (LUCK, 2004).
Da mesma maneira que as propriedades b´asicas, estas propriedades s˜ao normalmente
transversais, embora n˜ao constituam como obrigatoriedade para a defini¸c˜ao de agentes de
software. Por exemplo, alguns trabalhos, como (LOBATO, 2005) e no detalhamento em
(BELLIFEMINE et al., 2005) tratam a propriedade da mobilidade.
2.1.2 PLATAFORMAS DE IMPLEMENTAC¸
˜
AO DE SMA
Linguagens e metodologias de modelagem devem conduzir o desenvolvimento de SMA
para que a implementa¸c˜ao dos mesmos possam basear-se em t´ecnicas e representa¸c˜oes que
auxiliem solu¸c˜oes consistentes e r´ıgidas, no sentido de proverem melhor clareza, qualidade
e capacidade de melhor manutenabilidade.
Atualmente, existem diversas plataformas (frameworks) para o desenvolvimento de
SMA. Dentre elas, destacam-se o Java Agent Compiler and Kernel (JACK) (AOS, 2005),
o Jason (BORDINI, 2005) e o Java Agent Development Environment (JADE) (BEL-
LIFEMINE et al., 2005).
O JACK ´e uma plataforma de desenvolvimento de agentes de software baseada em
uma linguagem de agentes imperativa, a JACK Agente Language (JAL). Abordagens
imperativas, embora menos comuns na programa¸c˜ao orientada a agentes, permitem a re-
presenta¸c˜ao de abstra¸c˜oes provenientes de SMA de maneira declarativa. A linguagem JAL
´e baseada em id´eias de sistemas de planejamento reativos, resultantes do trabalho prove-
niente da arquitetura Belief-Desire-Intention (BDI) e, embora proponha uma linguagem
baseada em l´ogica, ´e caracterizada como uma extens˜ao da linguagem de programa¸c˜ao ori-
entada a objetos Java (BORDINI et al., 2005). O JACK tamb´em provˆe um ambiente de
desenvolvimento, o JACK Development Environment (JDE), voltado especialmente para
fins comerciais.
25
O Jason oferece uma plataforma para SMA fundamentada em uma linguagem de
agentes h´ıbrida, o AgentSpeak(L) (BORDINI et al., 2005), ou seja, al´em de influenciada
pelo trabalho proveniente da arquitetura BDI, tamb´em baseia-se em l´ogica BDI (RAO e
GEORGEFF, 1995). O Jason, assim como o JACK, tamb´em apresenta uma IDE para
executar e manipular agentes em SMA, al´em de distribui-los atrav´es de uma rede de forma
simples (BORDINI et al., 2005).
O JADE ´e um framework de desenvolvimento de agentes especialmente designado
para SMA distribu´ıdos, melhor caracterizado como middleware, fornecendo uma s´erie
de servi¸cos e v´arias ferramentas gr´aficas para codifica¸c˜ao, debugging e testes. O frame-
work se destaca por promover a interoperabilidade com outras plataformas atrav´es das
especifica¸c˜oes FIPA (Foundation for Intelligent Physical Agents) (FIPA-OS, 2001) para
a defini¸c˜ao de sua arquitetura e de sua infra-estrutura de comunica¸c˜ao, al´em de utilizar
uma linguagem com formato padr˜ao para trocas de mensagens, a Agent Communication
Language (ACL).
Originalmente, o framework JADE ´e orientado a objetos, ou seja, utiliza-se de classes,
m´etodos e atributos para descrever agentes de software. A vers˜ao 3.5 do JADE, possui os
seguintes conceitos para o desenvolvimento de agentes:
• Agentes: s˜ao as entidades de primeira-classe, constitu´ıdas por classes jade.core.Agent
da linguagem de programa¸c˜ao Java que devem ser estendidas por classes que repre-
sentam agentes de sistema;
• Comportamentos: s˜ao entidades que representam o comportamento atribu´ıdo para
os agentes; Classes jade.core.behaviours.Behaviour especificam o que realmente deve
ser executado no sistema para que satisfa¸ca os objetivos dos agentes.
Ent˜ao, toda a execu¸c˜ao em SMA ´e determinada pelos comportamentos. Estes com-
portamentos s˜ao originalmente atribu´ıdos como a¸c˜oes atˆomicas, ou seja, comportamentos
indivis´ıveis. Cabe salientar que n˜ao existe uma abstra¸c˜ao pr´opria para a implementa¸c˜ao
de planos em JADE.
2.2 CARACTER
´
ISTICAS TRANSVERSAIS
O termo “concern” na Engenharia de Software significa interesse ou caracter´ıstica de um
determinado sistema (PERES, 2006). Alguns pesquisadores (PIVETA et al., 2004) uti-
lizam o termo ”interesse”, enquanto que outros utilizam o termo “caracter´ıstica” (DA SILVA,
26
2006). J´a existe o termo “interesse” na Engenharia de Requisitos para denotar atores in-
teressados em sistemas como, por exemplo, os usu´arios (DA SILVA, 2006). Ent˜ao, o termo
“caracter´ıstica” foi utilizado neste trabalho.
Para melhor compreens˜ao na defini¸c˜ao de caracter´ısticas de sistema, eles podem ser
classificados, segundo (SOARES e BORBA, 2002):
• Caracter´ısticas funcionais, ou regras de neg´ocio: s˜ao referentes aos requisitos es-
pec´ıficos de regras de neg´ocio, ou seja, atendem `as funcionalidades espec´ıficas de
um sistema;
• Caracter´ısticas n˜ao-funcionais, ou arquiteturais: referem-se aos requisitos perif´ericos
de sistemas que entrecortam m´odulos distintos. Como exemplos, podem ser cita-
dos: logging, integridade de transa¸c˜oes, autentica¸c˜ao, autoriza¸c˜ao, desempenho,
distribui¸c˜ao, persistˆencia e profiling (ELRAD et al., 2001).
Ent˜ao, caracter´ısticas n˜ao-funcionais buscam atender `as funcionalidades que entrecor-
tam sistemas, ou seja, realizam alguma a¸c˜ao comum, sem levar em considera¸c˜ao que regras
de neg´ocio est˜ao envolvidas. Com isso, s˜ao identificados dois problemas (KICZALES et al.,
1997):
• C´odigo entrela¸cado (tangling code): existˆencia de v´arios requisitos n˜ao-funcionais
”entrela¸cados” em um m´odulo espec´ıfico de sistema, ou seja, existe a necessidade
de incidˆencia de v´arias caracter´ısticas arquiteturais na execu¸c˜ao de um m´odulo fun-
cional. A figura 2.1 mostra um esquema de entrela¸camento de c´odigo.
FIG. 2.1: C´odigo entrela¸cado
27
• C´odigo espalhado (scattering code): predominˆancia de catacter´ısticas n˜ao-funcionais
em v´arios m´odulos espec´ıficos de sistema. Por exemplo, a utiliza¸c˜ao de logging para
a depura¸c˜ao de sistema aparece em v´arios m´odulos funcionais, comprometendo o
reuso (ver figura 2.2).
FIG. 2.2: C´odigo espalhado
Os problemas relatados resultam em diversas conseq¨uˆencias, tais como: forte acopla-
mento - requisitos funcionais estabelecem dependˆencias com requisitos n˜ao-funcionais;
fraca coes˜ao - comportamentos funcionais estabelecem comportamentos que n˜ao depen-
dem de suas pr´oprias regras; redundˆancia - aparecimento de diversos fragmentos de c´odigos
semelhantes em diversos pontos do sistema; e dificuldade de compreens˜ao, manutenabili-
dade e reuso - relatados ao alto grau de dependˆencia identificado entre m´odulos.
V´arias abordagens tiveram elevada importˆancia para a contribui¸c˜ao na modulariza¸c˜ao
de caracter´ısticas transversais, tais como a programa¸c˜ao orientada a aspectos (KICZA-
LES et al., 1997), programa¸c˜ao orientada `a sujeitos (TARR et al., 1999) e programa¸c˜ao
adaptativa (LIEBERHERR et al., 1994). Diante das contribui¸c˜oes, a que tem se mostrado
mais promissora ´e a programa¸c˜ao orientada a aspectos (ELRAD et al., 2001).
2.3 PARADIGMA ORIENTADO A ASPECTOS
A orienta¸c˜ao a aspectos possui como objetivo permitir que a separa¸c˜ao de caracter´ısticas
transversais seja feita de maneira eficiente e reaproveit´avel. O paradigma caracteriza-se
como uma extens˜ao da orienta¸c˜ao `a objetos e provˆe alta modularidade na constru¸c˜ao de
sistemas e reuso de software, evitando assim o c´odigo espalhado e entrela¸cado (KICZALES
et al., 1997).
Aspectos s˜ao entidades de primeira classe e representam a decomposi¸c˜ao modular de
caracter´ısticas transversais (TARR et al., 1999). O paradigma atribui, em todo o ciclo
28
de desenvolvimento de sistemas, a defini¸c˜ao de comportamentos modulares, independen-
temente de quaisquer funcionalidades espec´ıficas (BANIASSAD e CLARKE, 2004). No
intuito de contribuir com a composi¸c˜ao modular (ou com o crosscutting) de caracter´ısticas
transversais, a Programa¸c˜ao Orientada a Aspectos (POA) oferece mecanismos de com-
posi¸c˜ao de acordo com (KICZALES et al., 2001), destacados a seguir:
• Ponto de jun¸c˜ao (join point): determina o momento na execu¸c˜ao de um m´odulo de
sistema onde um ou mais aspectos incidem, de acordo como foram designados;
• Corte pointcut: determina uma regra a partir de um ou mais pontos de jun¸c˜ao, onde
um aspecto intercepta com um comportamento estabelecido;
• Chamada advice: ´e o comportamento transversal em si, semelhante a um m´etodo
em OO. A execu¸c˜ao de um advice pode ocorrer antes, durante ou depois de um
pointcut ser alcan¸cado.
Na POA, duas caracter´ısticas devem ser obedecidas de acordo com (FILMAN e FRIED-
MAN, 2005): a transparˆencia, que verifica se ´e poss´ıvel determinar se um comportamento
aspectual ser´a executado e em que momento o realizar´a; e a quantifica¸c˜ao, que possui o
papel de especificar um mecanismo que permita o controle da rela¸c˜ao entre o comporta-
mento transversal e o de sistema. Tais mecanismos de quantifica¸c˜ao podem ser:
• Est´aticos, ou determin´ısticos: baseados em eventos s´ıncronos, onde a incidˆencia de
aspectos ´e conhecida;
• Dinˆamicos: exatamente o oposto, ou seja, baseados em eventos ass´ıncronos e n˜ao-
determin´ısticos. Como exemplo, pode-se citar a ocorrˆencia e tratamento de exce¸c˜oes,
de acordo com (PERES, 2006)
Al´em disso, deve contar com outro mecanismo, o de jun¸c˜ao (weaving), que define como
o compilador de aspectos ir´a aplicar o crosscutting em um sistema a partir da interpreta¸c˜ao
de join points e pointcuts e em que momento ir´a aplicar efetivamente os comportamentos
transversais (ou a¸c˜ao que incide transversalmente), ou seja, os advices: antes, durante ou
depois de comportamentos espec´ıficos de sistema.
´
E importante destacar que o c´odigo
compilado a partir da sintaxe de aspectos ´e transformado para c´odigo em objetos em
tempo de execu¸c˜ao.
29
3 TRABALHOS RELACIONADOS
Este cap´ıtulo tem como objetivo apresentar alguns trabalhos relacionados com a cor-
rente pesquisa. J´a existem trabalhos que tratam a modulariza¸c˜ao de caracter´ısticas em
SMA em dois n´ıveis: no n´ıvel de modelagem (se¸c˜ao 3.1) e nos n´ıveis de projeto detalhado
e implementa¸c˜ao (se¸c˜ao 3.2).
3.1 ASPECTOS NA MODELAGEM DE SMA
A orienta¸c˜ao a aspectos deve ser refletida em todas as etapas no processo de desenvolvi-
mento de software, pois assim ´e poss´ıvel definir caracter´ısticas transversais de maneira
modular em SMA para que haja consistˆencia na separa¸c˜ao de funcionalidades entre estas
etapas. Para as fases iniciais, ou seja, Engenharia de Requisitos e Projeto Arquitetural,
v´arias pesquisas vˆem apontando para estudos no contexto dos Early-Aspects (BANI-
ASSAD e CLARKE, 2004). Mais recentemente, muitos esfor¸cos vˆem apontando para
a modelagem de caracter´ısticas transversais em SMA atrav´es dos benef´ıcio que a POA
proporciona. Dentre eles, destacam-se o o trabalho de (SILVA et al., 2006), o AODM
(GARCIA et al., 2006) e o ACROSS (PERES et al., 2006).
3.1.1 “MODELING MULTI-AGENT SYSTEMS USING UML” (SILVA et al., 2006)
Esta pesquisa baseou-se em uma extens˜ao do meta-modelo da UML 2.0 para capturar as
caracter´ısticas de agˆencia para a modelagem de SMA no n´ıvel arquitetural, a partir do
uso de estere´otipos que a UML 2.0 oferece e de uma nota¸c˜ao pr´opria. Para que a proposta
consista com solidez em suas premissas, ela trabalha na melhoria do Tropos (MYLOPOU-
LOS e CASTRO, 2000), pois este oferece suporte `a todas as fases de desenvolvimento de
software, al´em do Tropos basear-se na nota¸c˜ao i*.
A utiliza¸c˜ao do i* como uma linguagem de descri¸c˜ao arquitetural (ADL) n˜ao ´e sufi-
ciente, devido `as suas limita¸c˜oes na descri¸c˜ao de detalhes em requisitos comportamentais
para a etapa de design, assim como protocolos, conectores, portas e interfaces. A partir
da proposta de (SILVA et al., 2003), ´e sugerida a utiliza¸c˜ao do UML-Real Time (UML-
RT) (SELIC e RUMBAUGH, 1998) como uma ADL para o Tropos, pois parte de seus
30
conceitos foram incorporados para a constru¸c˜ao da descri¸c˜ao arquitetural na UML 2.0
(OMG, 2005). Este trabalho, ent˜ao, prop˜oe uma abordagem para a descri¸c˜ao a n´ıvel
arquitetural em SMA atrav´es do Tropos com a nota¸c˜ao da UML 2.0.
A utiliza¸c˜ao de estere´otipos provenientes da UML 2.0 permite que meta-classes de
meta-modelos distintos sejam estendidos e adaptados para quaisquer finalidades espera-
das, em diferentes contextos. Esta proposta busca a utiliza¸c˜ao deste mecanismo para
adaptar e especificar entidades de representa¸c˜ao do paradigma orientado a agentes, con-
ceitualizados como profiles, especialmente contextualizadas como Agency profiles. Com
isso, o meta-modelo que prescreve as funcionalidades esperadas no contexto divide-se em
duas categorias:
• Intencionais: modelos para as abstra¸c˜oes de agentes, especifica¸c˜ao de como estes mo-
delos est˜ao relacionados colaborativamente. Exemplos de modelos: agente, cren¸ca,
organiza¸c˜ao, objetivo;
• Interativos: prop˜oem funcionalidades arquiteturais para a intera¸c˜ao entre entidades.
Exemplos de modelos: agente, intera¸c˜ao, mensagem, porta, conector.
Atrav´es da UML 2.0, ´e poss´ıvel beneficiar-se de t´ecnicas de extens˜oes de meta-classes
para a utiliza¸c˜ao de estere´otipos, promovendo um mecanismo de adapta¸c˜ao de meta-
modelos existentes de dom´ınios espec´ıficos. Por exemplo, nesta abordagem o estere´otipo
“Agent” extende a defini¸c˜ao da meta-classe “Class”, assim como demais estere´otipos,
visualizados na figura 3.1.
FIG. 3.1: Estere´otipos de agentes
Tamb´em s˜ao apresentados diagramas de modelagem para SMA, de acordo com o meta-
modelo de agentes:
• Diagrama de Arquitetura: define que agentes alcan¸cam seus objetivos a partir de
planos associados, retratado no padr˜ao cliente-servidor (SHAW e GARLAN, 1996);
31
• Diagrama de Comunica¸c˜ao: instˆancias de agentes e suas respectivas mensagens
trocadas entre si, no objetivo de oferecer um provedor de servi¸co;
• Diagrama de Ambiente: agentes comp˜oem uma organiza¸c˜ao situada em um ambi-
ente, onde este ambiente ´e composto por recursos acessados por agentes de acordo
com suas regras para delimitar suas responsabilidades;
• Diagrama de Inten¸c˜oes: agentes, cren¸cas, objetivos e planos s˜ao contextualizados
como normas, de acordo com uma ontologia utilizada em sua organiza¸c˜ao.
´
E descrito um meta-modelo de agˆencia, onde agentes colaboram entre si atrav´es de
uma vis˜ao orientada `a servi¸cos (ou `a pap´eis), como em uma arquitetura cliente-servidor
(SILVA et al., 2004). Dessa maneira, “servi¸cos” ou “pap´eis” poderiam ser compartilhados
por outros, assim como o agente Directory Facilitator (DF) (FIPA-OS, 2001), um agente
espec´ıfico para a localiza¸c˜ao de servi¸cos em um sistema multi-agente, semelhante `a um
servi¸co de p´aginas amarelas. A implementa¸c˜ao do agente DF pode ser encontrado, por
exemplo, no framework JADE.
A proposta sugere que as propriedades referentes aos agentes de software devem
apresentar-se apenas no n´ıvel de implementa¸c˜ao, de maneira an´aloga `a regras de neg´ocio
espec´ıficas de sistemas. Mesmo que sejam usadas v´arios estere´otipos, assim como a UML
2.0 define atrav´es do profile para a descri¸c˜ao arquitetural, n˜ao h´a como definir um aspecto
explicitamente, como por exemplo o estere´otipo <<Aspect>>.
3.1.2 “AN ASPECT-ORIENTED MODELING FRAMEWORK FOR DESIGNING MULTI-
AGENT SYSTEMS - AODM” (GARCIA et al., 2006)
A crescente demanda pela modelagem de caracter´ısticas transversais em SMA atraiu
diversos pesquisadores (CHEONG e WINIKOFF, 2006) (KANG et al., 2004) (MALLYA
e SINGH, 2005) (MOURATIDIS et al., 2005) (WEISS et al., 2003). No entanto, essas
pesquisas apontam para requisitos espec´ıficos, tratados de maneira isolada, tais como
mobilidade e autonomia.
A existˆencia de metodologias distintas, cada uma delas para a modelagem de cada
uma das propriedades de agentes, aumenta a dificuldade de determina¸c˜ao de abstra¸c˜oes e
mecanismos para representa¸c˜ao de propriedades de agentes, pois impede a generaliza¸c˜ao
de artefatos de software, caracter´ıstica importante na interoperabilidade de modelos. A
32
AODM ´e o resultado de uma pesquisa entre t´ecnicas para a modelagem e implementa¸c˜ao
de SMA em um contexto orientado a aspectos e `as abstra¸c˜oes de aspectos que incidem em
uma linguagem de modelagem orientada a agentes, conhecida como ANote (CHOREN e
LUCENA, 2005).
O framework de modelagem, al´em de permitir a modulariza¸c˜ao de caracter´ısticas de
agˆencia (b´asicas ou adicionais), tamb´em auxilia na defini¸c˜ao de requisitos funcionais e n˜ao-
funcionais em SMA, baseando-se em abstra¸c˜oes consideradas fundamentais em agentes de
software: objetivos e a¸c˜oes. Adicionalmente, provˆe a reutiliza¸c˜ao de modelos de aspectos
utilizados no trabalho de (CHAVEZ, 2004). O AODM prevˆe a utiliza¸c˜ao de trˆes modelos
conceituais relacionados:
• Modelo de agentes: define um meta-modelo conceitual (fig. 3.2) para a modelagem
de SMA, a partir de abstra¸c˜oes provenientes de agentes de software, assim como
agentes, objetivos e a¸c˜oes.
FIG. 3.2: Modelo de agentes
• Modelo de aspectos: define um framework que suporta conceitos, relacionamentos
e propriedades para prover a modelagem do paradigma orientado a aspectos na
etapa de design.
´
E constitu´ıdo de um modelo de componentes, onde o modelo de
agentes referencia as incidˆencias de join points de aspectos; modelo de join point,
que descrevem os tipos de join points existentes e suas restri¸c˜oes de uso, que s˜ao a
localiza¸c˜ao de agentes, objetivos e a¸c˜oes no modelo de agentes; e o modelo-n´ucleo,
que especifica como aspectos incidem em agentes e seus respectivos objetivos e a¸c˜oes.
33
FIG. 3.3: Modelo de aspectos
FIG. 3.4: Modelo de de incidˆencia de aspectos em agentes
• Modelo de composi¸c˜ao: tem a finalidade de promover a composi¸c˜ao entre agentes
e aspectos a partir de semˆanticas, especificando-se quais s˜ao as poss´ıveis op¸c˜oes de
incidˆencia de aspectos em agentes, seus objetivos e a¸c˜oes. As seguintes op¸c˜oes de
composi¸c˜ao s˜ao poss´ıveis:
– Composi¸c˜ao aspecto-agente: um aspecto introduz v´arios objetivos em um
agente, atrav´es de um operador chamado INTRODUCE. Nesta composi¸c˜ao, s˜ao
identificados quais objetivos de um aspecto incidem em objetivos de agentes;
– Composi¸c˜ao de objetivos entre agentes e aspectos: tratam como objetivos de
aspectos incidem em objetivos de agentes, decompondo-os ou substituindo-
os, atrav´es de diversos operadores, entre os quais est˜ao MERGE, REPLACE,
AND, OR, XOR, BEFORE e AFTER;
34
– Composi¸c˜ao objetivo-a¸c˜ao: ´e denotado que um aspecto incide com uma a¸c˜ao
diretamente em um objetivo de agente. O operador para este fim ´e novamente
o INTRODUCE;
– Composi¸c˜ao a¸c˜ao-a¸c˜ao: estabelece o relacionamento entre a a¸c˜ao de aspecto
na incidˆencia na a¸c˜ao de agentes, atrav´es dos operadores MERGE-BEFORE e
MERGE-AFTER na fus˜ao e do REPLACE para a substitui¸c˜ao.
FIG. 3.5: Dimens˜oes de crosscutting para o modelo de agentes
3.1.3 “AGENT CROSSCUTTING CONCERNS MODELING FRAMEWORK - ACROSS”
(PERES, 2006A)
O framework ACROSS apresenta uma proposta de modelagem que provenha suporte `a
modulariza¸c˜ao de caracter´ısticas transversais em SMA a partir da orienta¸c˜ao a aspectos,
promovendo a generaliza¸c˜ao de modelos e a independˆencia de paradigma, ou seja, sem a
mistura de conceitos de objetos da orienta¸c˜ao a objetos. Para isso, defende a necessidade
de defini¸c˜ao de conceitos em dois escopos: abstra¸c˜oes e relacionamentos. As abstra¸c˜oes
s˜ao orientadas aos conceitos de agentes de software, ou seja, agentes, objetivos, planos e
a¸c˜oes.
´
E adicionada tamb´em a abstra¸c˜ao aspecto, de forma a representar aspectos para
a modulariza¸c˜ao de caracter´ısticas transversais e como entidade de primeira-classe, assim
como representa a abstra¸c˜ao de agente. O ACROSS define que as abstra¸c˜oes devem existir
tanto no paradigma de agentes quanto no de aspectos, onde cada abstra¸c˜ao de aspecto
incide transversalmente na abstra¸c˜ao de agente correspondente, ou seja, aspectos cortam
agentes em cada n´ıvel da hierarquia de abstra¸c˜oes (fig. 3.6).
35
FIG. 3.6: Hierarquia entre abstra¸c˜oes de aspectos e agentes (PERES, 2006)
Os relacionamentos visam determinar como as abstra¸c˜oes influenciam umas nas outras,
a partir de suas especifica¸c˜oes. Existem no ACROSS dois tipos de relacionamentos: rela-
cionamentos horizontais e verticais. Os relacionamentos horizontais seguem um modelo
baseado em objetivos (ou metas) j´a existente, o V-Graph (YU et al., 2004). O V-Graph ´e
um gr´afico em forma de ”V”, onde os dois v´ertices acima s˜ao consitu´ıdos como objetivos
e co-objetivos (goals e soft-goals) e o v´ertice abaixo representa a tarefa (ou o conjunto de
tarefas) que viabiliza a contribui¸c˜ao entre os objetivos e co-objetivos. O relacionamento
horizontal ´e unidirecional, onde objetivos de aspectos incidem em objetivos de agentes,
nunca o contr´ario.
Os relacionamentos horizontais, de acordo com o V-Graph, s˜ao conhecidos como link´s
de correla¸c˜ao e demonstram que co-objetivos influenciam positivamente ou negativamente
em objetivos em diferentes n´ıveis (fig. 3.7):
• Make: o objetivo do agente s´o pode ser alcan¸cado se o objetivo do aspecto for
alcan¸cado;
• Help: o objetivo do agente pode ser melhor alcan¸cado (quest˜oes de performance
etc.) se o objetivo do aspecto for alcan¸cado;
• Hurt: o objetivo do agente n˜ao deve ser alcan¸cado se o objetivo do aspecto for
alcan¸cado;
36
• Break: o objetivo do agente n˜ao pode ser alcan¸cado se o objetivo do aspecto for
alcan¸cado;
• Unknown: n˜ao h´a interferˆencia clara na incidˆencia do objetivo do agente, dado que
o objetivo do aspecto seja alcan¸cado.
FIG. 3.7: Composi¸c˜ao gr´afica dos relacionamentos horizontais para a composi¸c˜ao de ob-
jetivos entre agentes e aspectos
Os relacionamentos verticais estabelecem como as abstra¸c˜oes de diferentes n´ıveis, mas
do mesmo paradigma (agentes ou aspectos) devem demonstrar a decomposi¸c˜ao refinados
em termos de ´arvores AND/OR (MYLOPOULOS et al., 1992) e proposto tamb´em o
operador XOR (ou exclusivo) (fig. 3.8). Assim, ´e poss´ıvel determinar o cumprimento
de uma abstra¸c˜ao a partir dos relacionamentos entre seus “filhos”, ou seja, dado por
exemplo um objetivo, para que ele cumpra seu papel, os operadores que o relacionam
`a seus planos determinam quando isso ir´a acontecer: se todos os seus planos devem ser
executados (AND), se ao menos um deles foi executado (OR) ou se apenas um deles foi
realizado (XOR).
O cumprimento de cada uma das abstra¸c˜oes segue o modelo de ´arvore, ou seja, en-
quanto os objetivos-folha dependem simplesmente dos relacionamentos que possui com
seus planos, os objetivos que cont´em sub-objetivos necessitam que seus sub-objetivos
cumpram seus pap´eis para, de acordo com os relacionamentos verticais determinados
com seus objetivos, chegarem `as suas respectivas situa¸c˜oes de finalizadas. O framework
ACROSS prop˜oe que comportamentos possam ser decompostos em objetivos, planos e
a¸c˜oes, como especifica o padr˜ao de projetos Composite (GAMMA et al., 1995).
A partir de extens˜oes da Interface de Crosscutting (CHAVEZ, 2004), ´e poss´ıvel deter-
minar o crosscutting est´atico e dinˆamico. Para o crosscutting est´atico, s˜ao introduzidos
relacionamentos ADD, onde novas caracter´ısticas comportamentais s˜ao introduzidas por
um aspecto em uma entidade-base (no caso, agentes). J´a os tipos de relacionamentos
dinˆamicos s˜ao representados por MERGE, onde os planos de aspectos ser˜ao combinados
com planos de agentes, mas o crosscutting ser´a determinado entre os n´ıveis mais baixos
da hierarquia de abstra¸c˜oes, ou seja, entre as a¸c˜oes de aspectos e planos.
37
FIG. 3.8: Exemplos de composi¸c˜ao gr´afica dos relacionamentos verticais existentes entre
as abstra¸c˜oes
Relacionamentos est´aticos s˜ao especificados como ADD BEFORE e ADD AFTER.
O relacionamento ADD BEFORE concretiza a execu¸c˜ao de planos de aspectos antes da
execu¸c˜ao de planos de agentes. De forma an´aloga, ADD AFTER estabelece a execu¸c˜ao
de planos de aspectos depois que planos de agentes forem executados.
Para o relacionamento do tipo MERGE, o crosscutting ocorre nas abstra¸c˜oes de a¸c˜oes
entre aspectos e agentes, ou seja, atrav´es de refinamentos e redefini¸c˜oes entre a¸c˜oes. Ent˜ao,
planos de aspectos incidem em planos de agentes a partir dos relacionamentos entre suas
a¸c˜oes envolvidas. Dessa forma, refinamentos podem ser REFINE BEFORE, REFINE
AROUND ou REFINE AFTER, onde a¸c˜oes de aspectos incidem antes, durante ou depois
da execu¸c˜ao de a¸c˜oes de agentes, respectivamente; enquanto redefini¸c˜oes podem ser do
tipo REDEFINE, assumindo-se que a¸c˜oes de aspectos substituem a¸c˜oes de agentes. A
figura 3.9 apresenta os relacionamentos de crosscutting propostos pelo ACROSS.
3.2 ASPECTOS NA IMPLEMENTAC¸
˜
AO DE SMA
Alguns esfor¸cos vˆem sendo realizados na fase de projeto detalhado e implementa¸c˜ao, onde
aspectos cortam transversalmente agentes de software como, por exemplo, o AspectM
(LOBATO, 2005) e o (GARCIA et al., 2001b).
38
FIG. 3.9: Relacionamentos entre planos e a¸c˜oes, de aspectos para agentes
3.2.1 “UM FRAMEWORK ORIENTADO A ASPECTOS PARA A MOBILIDADE DE
AGENTES DE SOFTWARE - ASPECTM (ASPECTIZING MOBILITY)” (LO-
BATO, 2005)
O principal problema apontado por este trabalho se refere ao alto grau de acoplamento
entre frameworks OO para o desenvolvimento de SMA, no que diz respeito `a codifica¸c˜ao da
caracter´ıstica de mobilidade, citando-se alguns exemplos: classes abstratas precisam ser
estendidas; m´etodos abstratos referentes `a mobilidade devem ser implementados; m´etodos
referentes `a mobilidade precisam ser acessados explicitamente; e interfaces de mobilidade
tamb´em precisam ser implementadas.
Para resolver este impasse, o AspectM visa a separa¸c˜ao n´ıtida entre a caracter´ıstica de
mobilidade de outros interesses, al´em de introduzir de forma transparente a mobilidade
em agentes, tornando a integra¸c˜ao entre frameworks OO mais flex´ıvel. O objetivo deste
trabalho foi apresentar uma generaliza¸c˜ao para tornar a propriedade de mobilidade de
agentes, reutiliz´avel a partir da POA, evitando-se assim o c´odigo espalhado e entrela¸cado.
Para isso, ´e criado um aspecto abstrato (fig. 3.10) que trata todas as caracter´ısticas
b´asicas da mobilidade e, a partir da´ı, sugere-se que sejam criados aspectos que estendam
este aspecto gen´erico, na finalidade de reutilizar suas premissas b´asicas para a defini¸c˜ao
de regras de mobilidade espec´ıficas de sistema. Ent˜ao, toda a implementa¸c˜ao referente
`a mobilidade ´e tratada por aspectos e n˜ao mais por agentes, representando melhoria no
reuso e manutenabilidade.
Portanto, o AspectM especifica um protocolo gen´erico para a mobilidade onde even-
39
FIG. 3.10: Aspecto Mobilidade definindo pontos de corte
tos s˜ao detectados, condi¸c˜oes s˜ao verificadas e, finalmente, m´etodos (ou m´odulos) que
realizam a mobilidade s˜ao chamados. O AspectM define hot spots que caracterizam sua
contribui¸c˜ao, isto ´e, situa¸c˜oes em que a mobilidade “corta” as funcionalidades de SMA:
defini¸c˜ao de agentes ou pap´eis como sendo m´oveis ou n˜ao; configura¸c˜oes de itiner´ario;
integra¸c˜ao facilitada com frameworks OO que fornecem implementa¸c˜oes de SMA; estabe-
lecimento de pointcuts que disparam a movimenta¸c˜ao e o retorno de agentes; defini¸c˜ao de
objetos que ser˜ao movidos com agentes ou pap´eis; e defini¸c˜ao de elementos serializ´aveis.
3.2.2 “AN ASPECT-BASED APPROACH FOR DEVELOPING MULTI-AGENT OBJECT-
ORIENTED SYSTEMS” (GARCIA et al., 2001b)
Este trabalho destaca que existem duas abordagens para o desenvolvimento de SMA.
A primeira trata o desenvolvimento de SMA como uma “nova engenharia de software”
(JENNINGS, 2000) (PETRIE, 1996). A segunda trata agentes e objetos como abstra¸c˜oes
complementares, isto ´e, prop˜oe extens˜oes de conceitos da orienta¸c˜ao a objetos para o
orientado a agentes (GARCIA et al., 2001a) (KENDALL, 1998). O autor utiliza a segunda
abordagem em sua pesquisa, com argumentos que existem diversas motiva¸c˜oes para a
inclus˜ao de agentes no contexto OO (IGLESIAS et al., 1998), mas que esta integra¸c˜ao
n˜ao ´e trivial, pela existˆencia de v´arias diferen¸cas entre os paradigmas (JENNINGS, 2000).
Para a integra¸c˜ao de agentes e objetos, ´e proposto o framework conceitual TAO -
Taming Agents and Objects (GARCIA, 2004), que tem como objetivo oferecer as bases
para a compreens˜ao de caracter´ısticas essenciais em SMA. S˜ao oferecidos conceitos para
a forma¸c˜ao de uma terminologia consistente e a semˆantica b´asica para o projeto e im-
plementa¸c˜ao de agentes, essenciais para o desenvolvimento de m´etodos e arquiteturas.
40
A proposta do TAO ´e facilitar a compreens˜ao de que maneira ocorre a intera¸c˜ao entre
agentes e outras abstra¸c˜oes de algum outro paradigma (neste caso, de objetos) atrav´es
de uma descri¸c˜ao em linguagem natural de categorias dos conceitos centrais e seus rela-
cionamentos, de forma similar `a modelos de caracter´ısticas conceituais (GARCIA, 2004).
Sua pesquisa para o desenvolvimento de SMA apresenta-se como uma extens˜ao orien-
tada a aspectos do modelo de objetos, a partir da divis˜ao entre v´arias perspectivas:
• Estados de agentes e comportamentos: classes s˜ao utilizadas para representar agentes
e seus componentes, tais como cren¸cas, objetivos e planos. Estados de agentes s˜ao
descritas em termos de objetivos, cren¸cas e planos, da mesma maneira que um objeto
de agente possui referˆencias `a objetos de cren¸cas, objetivos e planos;
• Tipos de agentes: aborda a especifica¸c˜ao de diferentes tipos de agentes, assim como
´e utilizado em OO;
• Aspectos para propriedades de agentes: aspectos devem realizar funcionalidades
previstas atrav´es de propriedades de agentes, tais como intera¸c˜ao, autonomia e
adapta¸c˜ao;
• Propriedades particulares de agentes providas por aspectos: aspectos definem pro-
priedades de agˆencia em determinados tipos de agentes, isto ´e, agentes espec´ıficos
possuem determinadas propriedades, de acordo com sua funcionalidade em sua hi-
erarquia correspondente;
• Aspectos colaborativos: embora a colabora¸c˜ao seja uma caracter´ıstica de agˆencia,
esta colabora¸c˜ao deve ser especificada atrav´es de um conjunto de colabora¸c˜oes par-
ticulares. Ent˜ao, diferentes aspectos de colabora¸c˜ao podem estar associados ao
mesmo agente;
• Aspectos para composi¸c˜ao: ´e necess´ario que sejam capturados os resultados prove-
nientes da intera¸c˜ao entre diversos aspectos em propriedades de agentes em um
mesmo SMA;
• Evolu¸c˜ao de Agentes: Aspectos devem ser modulares o suficiente para suportarem
a evolu¸c˜ao de agentes em SMA. Por exemplo, um aspecto que realiza a busca de
informa¸c˜oes em um ambiente, devido `a evolu¸c˜ao do sistema, deve ser interceptado
pelo aspecto de mobilidade quando o agente n˜ao encontra a informa¸c˜ao que procura
41
no ambiente em que est´a situado. Desta maneira, o agente ser´a movido para outro
ambiente pelo aspecto de mobilidade para realizar uma nova busca.
´
E interessante destacar que s˜ao utilizadas abstra¸c˜oes j´a discutidas anteriormente, como
agentes, objetivos e planos, al´em de relacionamentos verticais entre as abstra¸c˜oes, seme-
lhantes aos citados por (PERES, 2006).
3.3 DISCUSS
˜
AO SOBRE TRABALHOS RELACIONADOS
A proposta de modelagem baseada na UML 2.0 aborda caracter´ısticas transversais na
modelagem arquitetural, proveniente da utiliza¸c˜ao do mecanismo de profiling, decorrente
de estere´otipos, e da especifica¸c˜ao de uma nova linguagem para a descri¸c˜ao arquitetural
(ADL), a UML-RT, permitindo a defini¸c˜ao de requisitos comportamentais de sistemas, tais
como protocolos conectores, portas e interfaces. Por´em, da mesma forma que o AODM,
mistura conceitos de objetos com agentes de software. Al´em disso, n˜ao h´a como definir um
aspecto explicitamente atrav´es de um estere´otipo, algo como <<Aspect>>. Finalmente,
o autor utiliza um contexto orientado a servi¸cos, fugindo do escopo da corrente proposta
de pesquisa.
O AODM prop˜oe uma solu¸c˜ao fundamentada na defini¸c˜ao de modelos de agentes e de
aspectos, para a representa¸c˜ao de abstra¸c˜oes necess´arias. Estes modelos refletem, enfim,
em um modelo de composi¸c˜ao, com semˆanticas bem-definidas de regras para a incidˆencia
de aspectos em agentes de software. Por´em, foca-se na modulariza¸c˜ao exclusiva de pro-
priedade de agentes, b´asicas ou adicionais. A modulariza¸c˜ao neste caso perde o sentido de
generalizar qualquer comportamento que possa ser identificado como transversal. Al´em
disso, a utiliza¸c˜ao de conceitos da UML mistura conceitos de objetos no paradigma de
agentes, dificultando a clareza e aumentando-se a dependˆencia entre agentes e objetos.
O framework ACROSS apresenta uma proposta de modelagem de aspectos e agentes
atrav´es de abstra¸c˜oes e relacionamentos, onde aspectos contribuem com comportamentos
que atravessam SMA, sem mistura com conceitos da orienta¸c˜ao a objetos. Por esses mo-
tivos, o ACROSS ´e utilizado como base para a corrente pesquisa, no n´ıvel de modelagem.
Em seguida, foram analisadas as propostas mais relevantes quando comparadas ao tra-
balho corrente, ou seja, no n´ıvel de implementa¸c˜ao. O AspectM fornece uma solu¸c˜ao para
a implementa¸c˜ao de mobilidade em SMA com aspectos, desacoplando esta caracter´ıstica,
identificada como transversal, da codifica¸c˜ao que define toda a estrutura necess´aria para
42
a instancia¸c˜ao de SMA tais como, por exemplo, agentes e ambientes. A solu¸c˜ao apenas
contribui para uma propriedade de agentes (mobilidade), apesar de adotar abstra¸c˜oes re-
levantes em SMA, como planos e a¸c˜oes. O AspectM tamb´em mistura conceitos de objetos
no paradigma de agentes.
O trabalho de (GARCIA, 2004) tem como premissa a modulariza¸c˜ao de caracter´ısticas
transversais em SMA em sistemas orientados `a objetos. O autor defende que objetos
devem estar relacionados com agentes, que esses dois paradigmas se complementam. Esta
premissa ´e exatamente o contr´ario do que esta disserta¸c˜ao prega, ou seja, agentes de
software constituem um paradigma independente, sem mistura com conceitos de objetos.
Duas abordagens distintas podem ser seguidas na modulariza¸c˜ao de caracter´ısticas
transversais em SMA com aspectos: o paradigma de agentes ´e beneficiado por conceitos
da orienta¸c˜ao a objetos; e agentes de software constituem um paradigma independente,
sem mistura de conceitos OO. N˜ao existe abordagem mais ou menos correta, existem
diferentes caminhos para que se alcance o mesmo ideal. O trabalho de (GARCIA, 2004)
demonstra uma proposta consistente no contexto onde objetos auxiliam SMA, por´em n˜ao
trata que agentes e aspectos devem relacionar-se nos mesmos n´ıveis de abstra¸c˜ao, como
faz o framework ACROSS.
43
4 ASPECTUALJADE
Neste cap´ıtulo ´e apresentado o AspectualJADE, um framework para o desenvolvi-
mento de caracter´ısticas transversais em SMA a partir da orienta¸c˜ao a aspectos. Este
framework aborda tais caracter´ısticas nos n´ıveis de projeto detalhado e implementa¸c˜ao,
permitindo o desenvolvimento de caracter´ısticas que entrecortam sistemas multi-agentes,
podendo constituir requisitos funcionais, n˜ao-funcionais e propriedades de agentes (b´asicas
ou adicionais).
O AspectualJADE se vale de abstra¸c˜oes e relacionamentos propostos pelo ACROSS
(PERES, 2006), realizando a integra¸c˜ao entre o JADE e o AspectJ. Em ACROSS, tanto
os agentes quanto os aspectos s˜ao constitu´ıdos de objetivos, planos e a¸c˜oes. O ACROSS
sugere a utiliza¸c˜ao da abstra¸c˜ao de objetivos para a an´alise de requisitos e as abstra¸c˜oes
de planos e a¸c˜oes para o n´ıvel de projeto detalhado. Logo, o AspectualJADE utiliza as
abstra¸c˜oes correspondentes `as entidades de primeira classe, ou seja, agentes e aspectos, e
as abstra¸c˜oes correspondentes `a etapa de projeto detalhado, planos e a¸c˜oes. Os relaciona-
mentos verticais s˜ao mantidos, por´em s˜ao utilizados os relacionamentos horizontais entre
as abstra¸c˜oes de agentes, aspectos, planos e a¸c˜oes.
O framework AspectualJADE prop˜oe uma integra¸c˜ao entre o framework de desenvolvi-
mento de agentes, o JADE, e a linguagem para desenvolvimento de aspectos, o AspectJ.
O JADE foi escolhido por estar em conformidade com o padr˜ao FIPA (FIPA-OS, 2001).
O AspectJ foi selecionado para a linguagem de aspectos pelo seu grau de maturidade e
por caracterizar-se como uma extens˜ao da pr´opria linguagem de programa¸c˜ao Java.
Este trabalho apresenta uma integra¸c˜ao da fase de requisitos com as fases de pro-
jeto e implementa¸c˜ao. J´a para permitir a integra¸c˜ao do JADE com o AspectJ, algumas
modifica¸c˜oes na plataforma JADE tiveram que ser desenvolvidas. A se¸c˜ao 4.1 apresenta,
justifica e detalha todas as modifica¸c˜oes que precisaram ser feitas no framework JADE
para a adapta¸c˜ao necess´aria `a corrente pesquisa. A se¸c˜ao 4.2 detalha como deve ser
a constru¸c˜ao de agentes, de acordo com as modifica¸c˜oes realizadas no JADE. A se¸c˜ao
4.3 demonstra rastreabilidade, ou seja, como abstra¸c˜oes e relacionamentos do n´ıvel de
projeto detalhado refletem os conceitos da modelagem de SMA com modulariza¸c˜ao de
caracter´ısticas transversais. A se¸c˜ao 4.4 apresenta uma discuss˜ao sobre as contribui¸c˜oes
44
no contexto de pesquisa. Finalmente, a se¸c˜ao 4.5 traz os coment´arios finais a respeito do
trabalho desenvolvido.
4.1 A ABSTRAC¸
˜
AO MODIFICADA DE AGENTE
Apesar de j´a possuir uma estrutura b´asica de comportamentos que pode ter direta in-
fluˆencia em abstra¸c˜oes de planos e a¸c˜oes, a estrutura existente no JADE n˜ao permite que
todas as regras necess´arias sejam refletidas em relacionamentos verticais entre abstra¸c˜oes
de planos e a¸c˜oes, isto ´e, os relacionamentos de composi¸c˜ao com and, or e xor. Al´em
disso, foi preciso alterar o JADE para que os aspectos pudessem saber o momento certo
de incidirem sobre os agentes.
Assim, trˆes modifica¸c˜oes foram propostas ao framework JADE:
• Estabelecimento de relacionamentos verticais entre planos e a¸c˜oes: esta modifica¸c˜ao
tem o objetivo de tornar poss´ıvel a customiza¸c˜ao de regras em planos, ou seja, como
planos chegam `a seus objetivos;
• Controle de planos ou a¸c˜oes: para que a defini¸c˜ao das regras possa adquirir o controle
de planos que cumpriram seus objetivos, ´e necess´ario que possa ser verificado, em
determinados momentos, quais s˜ao os planos e/ou a¸c˜oes que j´a chegaram a seus
respectivos objetivos;
• Determina¸c˜ao de estado de execu¸c˜ao: em espec´ıfico, n˜ao h´a como determinar se a
execu¸c˜ao de uma a¸c˜ao ou um plano foi conclu´ıda. Demais estados j´a s˜ao definidos no
JADE e s˜ao: determina¸c˜ao de quando um comportamento est´a pronto para ser exe-
cutado; quando um comportamento est´a em execu¸c˜ao; e quando um comportamento
est´a bloqueado pelo Gerenciador do JADE.
Uma importante modifica¸c˜ao realizada diz respeito `a maneira como o JADE trata
comportamentos divis´ıveis a partir de regras-padr˜ao de relacionamentos verticais. Para
que seja poss´ıvel definir regras para planos, a visibilidade do m´etodo evalCondition()
teve que ser alterada de privada (private) para protegida (protected). Desta maneira,
foi poss´ıvel criar as pr´oprias classes que representam planos, cada uma com sua regra
espec´ıfica.
A figura 4.1 demonstra um exemplo de aplica¸c˜ao de relacionamento entre planos e
a¸c˜oes, extra´ıdo de (PERES, 2006): o Plano de Rea¸c˜ao ao Pedido de MT possui dois tipos
45
FIG. 4.1: Determina¸c˜ao de condi¸c˜ao de parada no m´etodo evalCondition()
de relacionamentos verticais com suas respectivas a¸c˜oes: XOR e AND. Isso significa que,
para que o plano em quest˜ao possa alcan¸car seu objetivo, ele deve executar apenas uma
das a¸c˜oes que possuem o relacionamento XOR (A¸c˜oes: Sugerir “N˜ao atirarei” e “Sugerir
repassar a MT para o GAC”) e a a¸c˜ao Receber posicionamento do usu´ario, pois esta ´ultima
possui o relacionamento vertical AND. Com a modifica¸c˜ao proposta, os relacionamentos
AND e XOR deste exemplo s˜ao descritos no m´etodo evalCondition (fig. 4.2).
FIG. 4.2: Exemplo de relacionamentos entre planos e suas a¸c˜oes e/ou sub-planos
Tamb´em foi preciso modificar o JADE para que planos possam se relacionar com ou-
tros planos e a¸c˜oes hierarquicamente. Ent˜ao, a classe Behaviour foi alterada, de modo que
especifique qual ´e o relacionamento esperado em rela¸c˜ao ao seu pai. A classe Behaviour
possui, para isso, “marcadores” para determinar qual ´e o relacionamento do comporta-
mento em rela¸c˜ao ao seu pai. Logo, foram adicionadas vari´aveis est´aticas and, or e xor,
al´em de outra vari´avel behaviourCondition, que guarda qual ´e o relacionamento, ou seja,
46
um dos citados, assim como pode ser visualizado na figura 4.3. Por padr˜ao, o JADE su-
porta relacionamentos verticais em dois sentidos: quando todos os comportamentos-filhos
chegaram ao final de sua execu¸c˜ao, o plano associado chega ao seu objetivo; e quando
ao menos um dos comportamentos-filhos chega ao final de sua execu¸c˜ao, sinalizando ao
plano que tamb´em chegou ao final de sua execu¸c˜ao.
Para o AspectualJADE, criou-se uma classe gen´erica Plan, aspectual.jade.core.Plan,
que estende a classe ParallelBehaviour do JADE, de forma a permitir a customiza¸c˜ao de
regras em planos, ou seja, para que o desenvolvedor de agentes possa utilizar todos os rela-
cionamentos verticais da maneira como ´e determinada em regras de sistema, promovendo
maior flexibilidade.
FIG. 4.3: Modifica¸c˜oes de relacionamentos verticais no JADE
Para o controle de planos ou a¸c˜oes, ´e necess´ario criar um m´etodo que verifique, na
lista de comportamentos terminados, quais os comportamentos j´a foram executados, assim
como ´e abordado na figura 4.4. Existem listas controladas pela classe ParallelBehaviour e
uma delas ´e a lista de comportamentos que j´a conclu´ıram suas execu¸c˜oes. Dessa maneira,
´e poss´ıvel customizar regras de planos a partir da verifica¸c˜ao de sub-planos e a¸c˜oes que
j´a foram executados pelo Scheduler do JADE.
FIG. 4.4: Modifica¸c˜ao de comportamentos-filho conclu´ıdos no JADE
Finalmente, as ´ultimas modifica¸c˜oes no JADE refletem a adi¸c˜ao do estado de execu¸c˜ao
“pronto”, para que planos determinem quais dos seus filhos conclu´ıram suas respectivas
execu¸c˜oes. Isto ´e importante para informar ao plano de aspecto que o intercepta em que
47
momento o plano de agente alcan¸cou seu objetivo. Para isso, foi modificado o m´etodo
checkTermination() da classe Behaviour (fig. 4.5).
FIG. 4.5: Modifica¸c˜ao para adicionar status “pronto” (done) no JADE
FIG. 4.6: Exemplo de codifica¸c˜ao da a¸c˜ao espec´ıfica “Sugerir n˜ao atirarei” no JADE
4.1.1 DESENVOLVENDO AGENTES
Esta se¸c˜ao tem como meta a demonstra¸c˜ao de um exemplo que aborde planos, a¸c˜oes e
relacionamentos verticais para agentes em SMA utilizando as modifica¸c˜oes propostas. O
exemplo utilizado baseia-se na modelagem demonstrada pela figura 4.2.
Todas as a¸c˜oes espec´ıficas devem estender uma classe gen´erica, chamada Action. Esta
classe, por sua vez, deve estender um comportamento atˆomico de uma classe interna do
JADE, a OneShotBehaviour, que provˆe o comportamento indivis´ıvel e executado uma
´unica vez, al´em de conter apenas um m´etodo abstrato action, a ser implementado pelas
a¸c˜oes espec´ıficas, que explicita a codifica¸c˜ao do que realmente ocorre.
48
FIG. 4.7: Codifica¸c˜ao do plano ReacaoAoPedidoDeMTPlan
A figura 4.6 ilustra a codifica¸c˜ao da a¸c˜ao “Sugerir N˜ao Atirarei”. As demais a¸c˜oes
s˜ao semelhantes, diferenciando-se apenas no que ´e realizado em cada um dos respectivos
m´etodos action implementados.
Em seguida, ´e interessante apresentar como deve ser a codifica¸c˜ao de uma classe de
planos espec´ıfica. Como exemplo, o plano ReacaoAoPedidoDeMTPlan possui trˆes a¸c˜oes
adicionadas atrav´es do m´etodo addAction(Behaviour action) (fig. 4.7). O m´etodo setBe-
haviourCondition() ´e usado para especificar qual ´e o tipo de relacionamento vertical da
a¸c˜ao no plano. J´a a opera¸c˜ao setWhenToStop() ´e usada para verificar o fim da execu¸c˜ao
do plano, isto ´e, para indicar que o plano alcan¸cou seu objetivo. A vari´avel when check
´e usada para explicitar o algoritmo respons´avel pela determina¸c˜ao da condi¸c˜ao de parada
em planos, onde o comportamento-padr˜ao pr´e-estabelecido pelo JADE deve ser ignorado.
A adi¸c˜ao de sub-planos ´e feita de forma an´aloga `a adi¸c˜ao de a¸c˜oes, por´em o m´etodo
que executa esta opera¸c˜ao possui a assinatura addPlan(Behaviour plan).
A codifica¸c˜ao de um agente, ent˜ao, requer simplesmente a adi¸c˜ao de seus planos. Isto
´e feito com o m´etodo addPlano (fig. 4.8).
49
FIG. 4.8: Codifica¸c˜ao do agente AnalisadorPedidoMTAgent
4.2 A NOVA ABSTRAC¸
˜
AO DE ASPECTO
Nesta se¸c˜ao, ser´a apresentado o modelo de rastreabilidade que reflete como as abstra¸c˜oes
e relacionamentos propostos pelo ACROSS s˜ao mapeadas para a implementa¸c˜ao de aspec-
tos, respons´aveis pela modulariza¸c˜ao de caracter´ısticas transversais. O c´odigo completo
do aspecto abordado pode ser encontrado no apˆendice (se¸c˜ao 10, listagem 10.1).
A abstra¸c˜ao aspecto precisa ser introduzida na plataforma. Isto significa introduzir
aspecto, seus planos e a¸c˜oes, e o mecanismo de intercepta¸c˜ao de aspectos em agentes. Para
que agentes de software beneficiem-se da POA atrav´es da metodologia adotada por esta
pesquisa, aspectos devem prover as abstra¸c˜oes relacionadas e o mecanismo de crosscutting
atrav´es de seus conceitos de join points, pointcuts e advices. Assim, a abstra¸c˜ao de
aspectos possui as seguintes caracter´ısticas:
• Gerais: perspectiva que cont´em as caracter´ısticas padr˜oes para a cria¸c˜ao de quais-
quer aspectos que interceptam planos e/ou a¸c˜oes de agentes. Todo aspecto deve
possuir estas caracter´ısticas;
• Descri¸c˜ao de join point: define como os planos e/ou a¸c˜oes de um aspecto incidem
sobre planos e/ou a¸c˜oes de agentes;
• Descri¸c˜ao de pointcut: define o momento e o que deve ser executado quando um
join point ´e alcan¸cado.
Em termos de codifica¸c˜ao, um aspecto ´e decomposto por trˆes partes: uma parte
gen´erica (abstrata); outra para a defini¸c˜ao de caracter´ısticas espec´ıficas; e finalmente a
respons´avel pela execu¸c˜ao (advices).
50
O AspectJ apresenta-se como uma linguagem de aspectos que provˆe mecanismos su-
ficientes para a implementa¸c˜ao das abstra¸c˜oes de planos e a¸c˜oes em aspectos, al´em de
fornecer o suporte necess´ario para a determina¸c˜ao de incidˆencia de aspectos em agentes
de software. Para que o AspectJ possibilite que aspectos “enxerguem” em que momentos
da execu¸c˜ao de um SMA devem interceptar, algumas altera¸c˜oes no JADE tiveram que ser
realizadas, no intuito de modificar a visibilidade em alguns fragmentos.
Para a visibilidade, a classe Behaviour teve a visibilidade alterada de seu m´etodo get-
Parent() de protegido (protected) para p´ublico (public), pois aspectos necessitam identi-
ficar qual ´e o plano associado `a execu¸c˜ao de outro plano ou a¸c˜ao. Alguns dos join point´s
definidos em aspectos, que ser˜ao vistos posteriormente no modelo de composi¸c˜ao, neces-
sitam deste tipo de permiss˜ao. Para destacar as classes constru´ıdas para caracterizarem
o exemplo no estudo de caso da presente disserta¸c˜ao, independentemente da estrutura
original do JADE, a visibilidade da classe BehaviourList deve ser alterada de “dentro do
pacote” (package) para p´ublico (fig. 4.9). As listas de comportamentos s˜ao tratadas no
JADE atrav´es desta classe e s˜ao fundamentais na determina¸c˜ao de comportamentos que
ainda ser˜ao executados, que j´a foram executados e que est˜ao bloqueados pelo framework.
FIG. 4.9: Modifica¸c˜oes de visibilidade no JADE
4.2.1 DESENVOLVENDO ASPECTOS
Esta se¸c˜ao tem como objetivo apresentar como as abstra¸c˜oes de a¸c˜oes e planos devem
ser representados em aspectos, assim como a pr´opria abstra¸c˜ao da entidade de primeira
classe, o aspecto. Para facilitar a distin¸c˜ao, ser´a utilizado o termo “entidade(s) aspecto(s)”
quando deseja-se abordar a abstra¸c˜ao de aspecto, e “aspecto” para a entidade na ´ıntegra,
ou seja, com seus planos e a¸c˜oes.
Como o AspectJ permite o desenvolvimento de aspectos partindo-se do conceito de
hierarquias, assim como a OO tamb´em especifica, ent˜ao cada uma das abstra¸c˜oes ´e re-
presentada como n´ıveis de hierarquias. Desta maneira, a¸c˜oes devem constituir entidades
que estendem planos, assim como planos devem estender entidades aspectos. Assim,
como agentes possuem planos que cont´em a¸c˜oes, aspectos representam o mesmo compor-
tamento. A figura 4.10 demonstra um exemplo onde ´e observada a hierarquia entre a¸c˜oes,
51
planos e a entidade aspecto.
FIG. 4.10: Exemplo de a¸c˜ao que extende um plano que, por sua vez, extende a entidade
aspecto
Para o n´ıvel de a¸c˜oes, a caracter´ıstica de descri¸c˜ao de pointcut ´e utilizada. Neste
n´ıvel, ´e codificada a a¸c˜ao esperado quando solicitada por seu plano. No n´ıvel de planos, a
caracter´ıstica de descri¸c˜ao de join point ´e refletida, onde s˜ao abordados os tipos de rela-
cionamentos horizontais existentes, assim como as a¸c˜oes que possuem. Finalmente, no
n´ıvel da entidade aspecto, s˜ao abordadas as caracter´ısticas gerais para a cria¸c˜ao de quais-
quer aspectos pela metodologia de desenvolvimento do AspectualJADE. O detalhamento
da codifica¸c˜ao destes n´ıveis pode ser analisada na se¸c˜ao seguinte, onde ´e explicado tamb´em
como implementar os relacionamentos horizontais na incidˆencia em SMA.
4.3 RELACIONAMENTOS TRANSVERSAIS
Os relacionamentos propostos pelo ACROSS prop˜oem crosscutting horizontal nos n´ıveis de
planos e de a¸c˜oes. No n´ıvel de planos, aspectos agem transversalmente em agentes atrav´es
da adi¸c˜ao de funcionalidades (ADD), que podem ocorrer antes ou depois da execu¸c˜ao de
planos de agentes (ADD BEFORE e ADD AFTER). Quando funcionalidades transversais
cortam caracter´ısticas de sistema de forma indefinida entre planos de aspectos e agentes
tem-se o relacionamento MERGE.
J´a no n´ıvel de a¸c˜oes, as a¸c˜oes de aspectos refinam a¸c˜oes de agentes antes (REFINE
BEFORE), durante (REFINE AROUND) ou depois (REFINE AFTER) da execu¸c˜ao de
a¸c˜oes de agentes, ou ainda a¸c˜oes de aspectos redefinem a¸c˜oes de agentes, substituindo-
os (REDEFINE). Os momentos de incidˆencia de aspectos em agentes, tanto no n´ıvel
de planos, quanto no n´ıvel de a¸c˜oes, s˜ao definidos atrav´es de pointcuts e join points
correspondentes.
As sub-se¸c˜oes a seguir tˆem o objetivo de demonstrar como implementar cada um
destes relacionamentos propostos pelo ACROSS. Inicialmente, ser˜ao demonstrados como
codificar os relacionamentos de refinamento e redefini¸c˜ao em a¸c˜oes, ou seja, REFINE (BE-
FORE, AROUND e AFTER) e REDEFINE. Em seguida, ser´a demonstrado como refletir
52
o relacionamento entre planos tamb´em proposto pelo ACROSS, isto ´e, o relacionamento
ADD (BEFORE e AFTER). O relacionamento MERGE entre planos apenas sinaliza que
as regras de crosscutting ser˜ao tratadas no n´ıvel de a¸c˜oes.
4.3.1 MERGE - REFINE E REDEFINE
Os relacionamentos de REFINE e REDEFINE adicionam uma caracter´ıstica transversal
(a¸c˜ao de aspectos) antes, durante, depois ou substuindo alguma execu¸c˜ao de a¸c˜ao de
agente. Para melhor ilustrar como ser´a o desenvolvimento de um aspecto que ir´a cortar
um agente, a figura 4.11 demonstra o exemplo que ser´a seguido.
FIG. 4.11: Exemplo para o relacionamento REFINE BEFORE, atraves do MERGE
A figura 4.12 mostra o esqueleto do c´odigo do aspecto que faz o merge apresentado
na figura 4.11. Este c´odigo mostra que o aspecto dever´a ser capaz de alterar a ordem
de execu¸c˜ao de a¸c˜oes na plataforma. A defini¸c˜ao do pointcut addBehaviour intercepta o
momento em que quaisquer planos ou a¸c˜oes s˜ao adicionados `a qualquer agente. Para que
quaisquer aspectos interceptem quaisquer a¸c˜oes de agentes, tamb´em ´e criado o pointcut
actionCall que verifica o momento em que um agente realiza a execu¸c˜ao de alguma a¸c˜ao
associada. Por fim, s˜ao especificadas as assinaturas para os relacionamentos poss´ıveis
para a rela¸c˜ao MERGE entre planos.
O modelo de join point aborda todas as regras que devem existir para definir quais
a¸c˜oes e planos de aspectos incidem em quais a¸c˜oes e planos de agentes. Em primeiro
53
FIG. 4.12: Estrutura da perspectiva gen´erica para o relacionamento MERGE
lugar, deve ser criada uma estrutura que tenha como objetivo informar, dado que existe
alguma a¸c˜ao de agente a ser executado, se esta a¸c˜ao deve ser interceptada por algum
relacionamento. Em seguida, ser´a criado um advice que tem como objetivo atribuir os
relacionamentos existentes de a¸c˜oes de aspectos para a¸c˜oes de agentes. Para validar quais
a¸c˜oes de agentes devem possuir relacionamentos espec´ıficos, deve ser verificado quais a¸c˜oes
de agentes dever˜ao ser “marcadas” com quais relacionamentos oriundos de aspectos. A
figura 4.13 ilustra a codifica¸c˜ao deste modelo.
J´a o modelo de pointcuts possui apenas duas funcionalidades:
• Estabelecimento de advices: estes advices refletem a execu¸c˜ao de a¸c˜oes de aspectos,
de acordo com as execu¸c˜oes de agentes, onde relacionamentos foram previamente
definidos;
• Cria¸c˜ao de a¸c˜oes de aspectos: ´e aqui que s˜ao definidas o que cada a¸c˜ao de aspecto
realiza. De maneira semelhante `a orienta¸c˜ao a objetos, deve possuir a implementa¸c˜ao
54
FIG. 4.13: Estrutura da perspectiva de planos para o relacionamento MERGE
de todas as assinaturas de a¸c˜oes especificadas na perspectiva de planos.
Para verificar como deve ser a codifica¸c˜ao, de acordo com o exemplo, foi especifi-
cado o relacionamento REFINE BEFORE. Para refletir os outros tipos de refinamentos
(AROUND e AFTER), a constru¸c˜ao ´e feita de maneira an´aloga ao apresentado.
Para o estabelecimento do REDEFINE, a t´ecnica ´e semelhante ao REFINE AROUND,
com a diferen¸ca que a a¸c˜ao do aspecto ir´a substituir a a¸c˜ao do agente. Para tanto,
basta criar um advice do tipo around (durante) que n˜ao especifica em que momento a
a¸c˜ao de agentes ir´a executar (fig. 4.14). Dessa forma, as a¸c˜oes dos agentes n˜ao ser˜ao
executadas. Quando o AspectJ identificar a chamada de a¸c˜oes de agentes que sejam
do tipo REDEFINE, ir´a executar a a¸c˜ao do aspecto respons´avel e n˜ao permitir´a que
a¸c˜oes dos agentes relacionados executem. A palavra reservada proceed do AspectJ visa
determinar em que momento a execu¸c˜ao da a¸c˜ao do agente dever´a prosseguir. Quando
o proceed n˜ao ´e utilizado, ent˜ao a a¸c˜ao do agente em quest˜ao n˜ao ser´a executada em
momento algum. A figura 4.14 especifica tamb´em como deve ser o modelo de pointcuts.
55
FIG. 4.14: Diferen¸cas entre REFINE AROUND e REDEFINE na perspectiva de a¸c˜oes
para o relacionamento MERGE
4.3.2 ADD
Para o relacionamento do tipo ADD, devem ser observadas as seguintes caracter´ısticas:
• ADD BEFORE: o plano do aspecto em quest˜ao deve anteceder o plano do agente
que corta, ou seja, antes da realiza¸c˜ao do plano do agente, o plano do aspecto deve
chegar `a sua finalidade;
• ADD AFTER: exatamente o contr´ario ao ADD BEFORE, o plano de aspecto deve
ser verificado ap´os o plano de agente ter sido realizado.
Para o ADD BEFORE, ´e importante que seja verificado se o plano de agente j´a
prescreveu a execu¸c˜ao de suas a¸c˜oes anteriormente. Isto deve ser feito atrav´es do uso de
flag´s e operadores de controle, estabelecendo-se que as a¸c˜oes do plano do aspecto devem
executar antes de qualquer a¸c˜ao ao plano do agente em quest˜ao e que, ap´os a execu¸c˜ao
de seu plano, n˜ao volte a executar;
J´a para o ADD AFTER, confirma-se a importˆancia na defini¸c˜ao do status “pronto”
em planos de agentes no JADE. Para concretizar a usabilidade deste relacionamento
horizontal, planos de agentes devem informar que conclu´ıram seus objetivos para que
aspectos possam executar suas a¸c˜oes do plano de corte correspondente. Como planos de
agentes informam uma ´unica vez que chegaram aos seus objetivos espec´ıficos, planos de
aspectos n˜ao incidem mais que uma vez.
Os c´odigos do agente “Analisador de Pedido de MT” podem ser encontrados no
apˆendice (se¸c˜ao 9, listagem 9.2).
4.4 CONSIDERAC¸
˜
OES SOBRE O ASPECTUALJADE
A proposta do AspectualJADE ´e promover uma plataforma de desenvolvimento de agentes
que possa se beneficiar da modulariza¸c˜ao de caracter´ısticas transversais atrav´es da POA.
56
Diferenciando-se do trabalho de (GARCIA, 2004), ataca o problema partindo da premissa
que conceitos de agentes devem ser totalmente independentes de conceitos de objetos,
ou seja, n˜ao devem existir classes, m´etodos ou atributos em qualquer etapa do ciclo de
desenvolvimento de software orientado a agentes.
Uma das principais preocupa¸c˜oes deste trabalho foi manter a rastreabilidade entre
implementa¸c˜ao (projeto detalhado) e os requisitos. Diante dos trabalhos pesquisados, o
ACROSS atendeu `a todas as demandas do AspectualJADE propondo abstra¸c˜oes e rela-
cionamentos para a decomposi¸c˜ao de comportamentos de agentes e aspectos, onde cada
abstra¸c˜ao possui seu papel bem-definido e estas abstra¸c˜oes comunicam-se atrav´es destes
relacionamentos. O ACROSS prop˜oe tais modelagens nos n´ıveis de requisitos e projeto
detalhado, fundamentando-se em estudos suficientes para que o AspectualJADE possa
basear-se em sua metodologia para promover o modelo de composi¸c˜ao para a imple-
menta¸c˜ao desses tipos de sistemas.
Uma quest˜ao interessante a ser levantada leva em considera¸c˜ao que o AspectualJADE
prop˜oe mecanismos para a implementa¸c˜ao de agentes com aspectos, por´em utiliza um
framework de desenvolvimento de agentes, o JADE, que ´e totalmente constru´ıdo baseado
na orienta¸c˜ao a objetos. Da mesma maneira, aspectos, em sua essˆencia, s˜ao definidos
como extens˜oes da pr´opria orienta¸c˜ao a objetos, j´a que seus conceitos especificam como
devem ocorrer cortes em classes, m´etodos e atributos.
Cabe salientar que o AspectualJADE trabalha com conceitos da orienta¸c˜ao a obje-
tos, em n´ıvel de implementa¸c˜ao, devido `a limita¸c˜ao imposta neste sentido atrav´es de
frameworks de desenvolvimento de agentes, tais como o pr´oprio JADE, e por aspectos
oferecerem “suporte” de acordo com a sintaxe da orienta¸c˜ao a objetos.
57
5 ESTUDO DE CASO
Este cap´ıtulo tem como objetivo apresentar o AspectualJADE atrav´es de um estudo
de caso. O exemplo a ser utilizado baseia-se em sistemas de Comando e Controle (C2),
voltado para a atua¸c˜ao da Artilharia de Campanha (PERES, 2006). Este estudo de caso
leva em considera¸c˜ao as especifica¸c˜oes do Sistema Gˆenesis, que vem sendo desenvolvido
pela ind´ustria de Material B´elico do Brasil, atrav´es da F´abrica de Material de Comu-
nica¸c˜oes e Eletrˆonica (IMBEL/FMCE) (IMBEL, 2006).
´
E interessante destacar que, originalmente, o Sistema Gˆenesis ´e baseado na orienta¸c˜ao
a objetos. Inicialmente, ´e realizada uma breve descri¸c˜ao do SMA para a Artilharia de
Campanha (SMAC) na se¸c˜ao 5.1, no intuito de situar o entendimento deste estudo de
caso. Em seguida, ´e apresentada a modelagem do SMAC de acordo com (PERES, 2006).
Adiante, ´e mostrada a implementa¸c˜ao do SMAC no AspectualJADE.
5.1 O SISTEMA
A artilharia ´e a arma do ex´ercito que ap´oia a realiza¸c˜ao do tiro atrav´es do lan¸camento
de proj´eteis em trajet´oria parab´olica. Tais tiros s˜ao direcionados atrav´es da execu¸c˜ao
de Miss˜oes de Tiro (MTs), que nada mais s˜ao como um conjunto de proj´eteis que s˜ao
desferidos sobre um alvo inimigo, baseados em conjuntos de parˆametros t´ecnicos e t´aticos,
na finalidade de determinar o efeito que se deseja produzir. De acordo com (EGGCF,
2001), existem os respectivos efeitos de uma MT: neutraliza¸c˜ao, destrui¸c˜ao, interdi¸c˜ao,
iquieta¸c˜ao, iluminativo entre outros.
(PERES, 2006) define como deve ser a atua¸c˜ao da Artilharia para o combate no
n´ıvel de Brigada. Observadores Avan¸cados (OA) devem identificar alvos, solicitar MTs e
acompanh´a-las at´e que as mesmas sinalizem que chegaram a seus respectivos objetivos.
Oficiais de Liga¸c˜ao (OLigs) colaboram com a correspondente arma-base (Infantaria ou
Cavalaria) para receber os pedidos de MTs e analis´a-los para decidir a viabilidade de
repassar os alvos especificados para serem batidos pelo Grupo de Artilharia de Campanha
(GAC). O Oficial de Opera¸c˜oes do GAC (S/3 GAC) responsabiliza-se pelo gerenciamento
de baterias que comp˜oem o GAC que, ao receber a MT repassada pelo OLig, dependendo
da decis˜ao se devem dar prosseguimento a ela, aloca as baterias necess´arias para realiz´a-la.
58
Os Comandantes de Linha de Fogo (CLF), que visam o recebimento das MT´s a serem
cumpridas para comandar os tiros das pe¸cas, informando ao GAC sobre a evolu¸c˜ao do
tiro executado. E, finalmente, os Chefes de Pe¸ca (CPs), que objetivam-se em dirigir os
trabalhos ao ambiente pr´e-determinado.
Ent˜ao, podem ser identificados cinco tipos de agentes no SMAC :
• Observador Avan¸cado (OA): tem o objetivo de transmitir a solicita¸c˜ao da MT e por
seu acompanhamento, j´a que os usu´arios correspondentes possuem a visibilidade
sobre alvos. Dessa maneira, comunica aos demais agentes que a miss˜ao foi cumprida,
transmite dados para possibilitar a corre¸c˜ao do tiro, sinaliza o momento apropriado
para efetuar o tiro e alerta para a eventualidade no “cessar fogo”;
• Oficial de Liga¸c˜ao (OLig): fixa-se em representar os elementos de Artilharia ligados
`a arma-base, recebendo o pedido de MT especificado pelos OAs e ajuda na tomada
de decis˜ao se a MT deve ou n˜ao continuar, j´a que conhece a posi¸c˜ao das tropas
aliadas e o ambiente onde estas tropas est˜ao inseridas;
• S3 do Grupo de Artilharia de Campanha (S/3 GAC): tem a finalidade de controlar os
recursos de Artilharia do grupo, onde s˜ao recebidos os parˆametros de MT repassados
pelo OLig e apoia a decis˜ao se o MT correspondente deve ser continuado, define
quais s˜ao os parˆametros mais adequados `a MT e as respectivas baterias a serem
empregadas;
• Comandante de Linha de Fogo (CLF): orienta-se por receber ordens para a execu¸c˜ao
de MTs e comanda como deve ser a execu¸c˜ao do tiro, informando os parˆametros
necess´arios `as pe¸cas, al´em de receber informa¸c˜oes de pe¸cas sobre a execu¸c˜ao do tiro
para o repasse destas informa¸c˜oes ao agente S3;
• Chefe de Pe¸ca (CP): informa ao agente CLF a respeito da execu¸c˜ao de tiros repor-
tados pelo usu´ario CP, al´em de receber do agente CLF o comando para a execu¸c˜ao
do tiro.
A figura 5.1 relata a estrutura geral do SMAC, especificando uma representa¸c˜ao de
troca de informa¸c˜oes entre si e com usu´arios no contexto de combate, extra´ıdo de (PERES,
2006).
59
FIG. 5.1: Intera¸c˜ao entre agentes e usu´arios humanos, descritos pelo SMAC
5.2 A MODELAGEM DO SMAC
Esta se¸c˜ao mostra a modelagem do SMAC com o ACROSS de forma a exprimir dois dos
cinco agentes: o OA e o OLig. Vale lembrar que a abstra¸c˜ao de objetivos n˜ao ´e utilizada
por n˜ao se tratar do foco desta pesquisa, por corresponder `a etapa de requisitos no ciclo de
desenvolvimento de software. Al´em disso, uma parte do estudo de caso referente `a planos
e a¸c˜oes foi utilizado, no intuito de evitar repeti¸c˜ao de referˆencia ao modelo de composi¸c˜ao.
5.2.1 MODELAGEM DO OA
Um dos objetivos do agente OA ´e realizar a busca de alvos em potencial. Para que
este objetivo seja alcan¸cado, ´e necess´ario determinar um plano “Busca de Alvos” para
a decomposi¸c˜ao de um comportamento esperado. Este plano consiste basicamente de
um sub-plano para a identifica¸c˜ao dos alvos; uma a¸c˜ao para cruzar os dados do alvo
com as informa¸c˜oes de inteligˆencia para certificar-se que o pedido de MT ´e apropriado;
e uma a¸c˜ao para sugerir a conduta necess´aria para a MT. O plano de identifica¸c˜ao de
alvos, por sua vez, decomp˜oe-se em a¸c˜oes para que o agente receba as coordenadas do
alvo, sua respectiva natureza e suas dimens˜oes. A figura 5.2 demonstra as abstra¸c˜oes e
relacionamentos verticais que refletem este objetivo.
´
E definido, ainda, um objetivo “Pedir MT”, onde o SMAC contempla um plano para
pedido de neutraliza¸c˜ao do MT, especificando trˆes a¸c˜oes: cruzar a natureza e dimens˜oes
do alvo com informa¸c˜oes de nomogramas; sugerir parˆametros para a execu¸c˜ao de MT;
e receber parˆametros finais do pedido de MT. A figura 5.3 demonstra tais abstra¸c˜oes e
60
FIG. 5.2: Modelagem dos planos e a¸c˜oes associados ao objetivo “Buscar alvo”
relacionamentos verticais.
5.2.2 MODELAGEM DO OLIG
O objetivo “Tratar MT sobre ´otica de manobra” contempla v´arios sub-objetivos, dentre
eles o “Analisar o Pedido de MT”(i), “Tratar mensagens vindas de outros agentes”(ii),
“Suspender fogo”(iii) e “Autorizar fogo”(iv). Cada um destes sub-objetivos relaciona ape-
nas um plano, que s˜ao: “Aprecia¸c˜ao de pedido de MT” (i); “Tratamento de mensagens”
(ii); “Suspens˜ao de fogo” (iii); e “Autoriza¸c˜ao de fogo” (iv). A figura 5.4 demonstra estes
sub-objetivos e seus respectivos planos.
FIG. 5.3: Modelagem do plano e das a¸c˜oes associados ao objetivo “Pedir MT”
61
FIG. 5.4: Modelagem de planos em rela¸c˜ao `a seus respectivos objetivo
5.2.3 MODELAGEM DE ASPECTOS
Dois aspectos podem ser identificados a partir de propriedades de agentes em SMA: au-
tonomia e interatividade. Enquanto que a autonomia especifica mecanismos para fornecer
informa¸c˜oes baseadas em cren¸cas e no ambiente em que um agente possa estar inserido,
a interatividade estabelece um mecanismo para a comunica¸c˜ao entre agentes.
O objetivo principal do aspecto para a autonomia ´e tomar decis˜oes, embora ele possa
ser decomposto em v´arios sub-objetivos. Para prover sua funcionalidade b´asica, pode-se
contemplar apenas um plano associado, de maneira que este plano se baseie na decis˜ao de
cren¸cas e no ambiente que seu agente est´a inserido, atrav´es da manipula¸c˜ao de informa¸c˜oes
dispon´ıveis em uma base acess´ıvel aos agentes. Ent˜ao, agentes podem acessar esta base em
busca de informa¸c˜oes relacionadas aos seus parˆametros em espec´ıfico, para assim tomar
decis˜oes em fun¸c˜ao do retorno destas informa¸c˜oes. A figura 5.5 aborda como o aspecto
beneficia agentes neste contexto.
FIG. 5.5: Planos e a¸c˜oes em rela¸c˜ao ao objetivo “Tomar decis˜oes” do aspecto autonomia
62
O aspecto para a interatividade estabelece, para atingir o objetivo de comunica¸c˜ao
entre agentes, dois sub-objetivos baseados na troca de mensagens: um para o envio, outro
para o recebimento de mensagens. Cada um destes sub-objetivos tamb´em est˜ao associados
com apenas um plano cada um, assim como visualizado na figura 5.6.
FIG. 5.6: Planos e a¸c˜oes em rela¸c˜ao aos objetivos “Enviar mensagens” e “Receber men-
sagens” do aspecto interatividade
Embora os aspectos relacionados possam cortar diversos agentes, este estudo de caso
apresenta o aspecto autonomia para a especifica¸c˜ao, como caracter´ıstica transversal mo-
dularizada, para o agente OA na demonstra¸c˜ao da aplica¸c˜ao do modelo de composi¸c˜ao
para o relacionamento entre planos merge, enquanto que o aspecto interatividade com
incidˆencia no agente OLig, verificando-se o relacionamento entre planos add.
5.2.4 MODELAGEM DO CROSSCUTTING NO N
´
IVEL DE PLANOS E AC¸
˜
OES
O crosscutting estabelece como relacionamentos horizontais de aspectos para agentes deve
ocorrer, respeitando-se a correspondˆencia em cada um dos n´ıveis. Com isso, verifica-se
que o aspecto autonomia incide transversalmente em agentes de acordo com a necessi-
dade de coleta de informa¸c˜oes dispon´ıveis para a tomada de decis˜ao, enquanto que o
aspecto interatividade estabelece o elo de comunica¸c˜ao entre agentes, atrav´es de trocas
de mensagens.
Na especifica¸c˜ao do plano para atender ao objetivo “Tomar decis˜ao”, o relacionamento
merge deve ser especificado, atribuindo-se o crosscutting diretamente no n´ıvel de a¸c˜oes.
As a¸c˜oes de “Receber parˆametros” e “Buscar resultados mais adequados” apresentam-se
como redefini¸c˜oes (redefine) de a¸c˜oes de agentes, pois realizam o cruzamento de dados
na sua base de informa¸c˜oes. J´a a a¸c˜ao “Retornar resultados”, s˜ao realizadas sugest˜oes de
acordo com os resultados retornados, refinando a a¸c˜ao de agentes antes que as mesmas
sejam executadas (refine before). A figura 5.7 demonstra como o relacionamento
63
merge indica o corte transversal em agentes.
FIG. 5.7: Crosscutting do aspecto autonomia no agente OA
Finalmente, para que se cumpra a interatividade entre agentes, mensagens devem ser
enviadas e recebidas entre eles. Logo, planos do aspecto interatividade devem incidir
diretamente em planos de agentes, independentemente de quais a¸c˜oes est˜ao envolvidas
neste contexto, assim como prop˜oe o relacionamento add.
Como o plano de recebimento de mensagens, proveniente do aspecto correspondente,
deve ser executado antes do tratamento de mensagens, o relacionamento add before
predomina entre planos para este fim. De forma an´aloga, como o envio de mensagens
deve ser realizada depois que planos de agentes (que deve atuar o crosscutting) forem
processados, o relacionamento add after deve ser utilizada. Assim, nota-se que o agente
OLig precisa receber mensagens da MT para realizar uma an´alise, para depois enviar
mensagens informativas ao agente OA e ao S3/GAC. A figura 5.8 ilustra como devem ser
os relacionamentos horizontais entre os planos.
5.3 IMPLEMENTANDO O SMAC
Esta se¸c˜ao demonstra como o AspectualJADE possibilita, atrav´es de seu modelo de com-
posi¸c˜ao, a implementa¸c˜ao dos modelos especificados na se¸c˜ao 5.2 para o SMAC. Como
64
FIG. 5.8: Crosscutting do aspecto interatividade no agente OLig
esta pesquisa mant´em o foco na contribui¸c˜ao para o estabelecimento de crosscutting em
agentes, atrav´es da POA, ser˜ao demonstrados os aspectos que cortam tais agentes e como
os relacionamentos horizontais provˆeem a modulariza¸c˜ao das caracter´ısticas transversais
nos n´ıveis de planos e a¸c˜oes. A codifica¸c˜ao de agentes pode ser encontrada no apˆendice
(se¸c˜ao 9, listagem 9.3), assim como dos aspectos Autonomia e Interatividade no apˆendice
(se¸c˜ao 10, listagem 10.2)
Como conven¸c˜ao, adota-se como representa¸c˜ao de entidades de modelos em c´odigo
de forma que o c´odigo seja identificado como a jun¸c˜ao da frase descrita no modelo, sem
acentua¸c˜oes ou caracteres de cedilha, onde a palavra “Plano” ´e colocada no final da
representa¸c˜ao do c´odigo como “Plan” e a¸c˜oes, embora n˜ao-expl´ıcitas nas descri¸c˜oes de
a¸c˜oes, tamb´em s˜ao representados nos finais das representa¸c˜oes do c´odigo como “Action”.
Por exemplo, o plano “Plano de Pedido de Neutraliza¸c˜ao” ´e representado em c´odigo como
“PedidoDeNeutralizacaoPlan” e a a¸c˜ao “Sugerir Rea¸c˜ao” ´e representado em c´odigo como
“SugerirReacaoAction”.
65
5.3.1 O AGENTE OA
Como exemplo, para a cria¸c˜ao da a¸c˜ao “Sugerir Rea¸c˜ao”, basta que seja criada uma
classe SugerirReacaoAction que extenda a classe Action. Ent˜ao, seja codificado no corpo
do m´etodo “action” qual ´e o comportamento atˆomico esperado. A figura 5.9 demonstra
como ´e simples.
FIG. 5.9: A¸c˜ao “Sugerir Rea¸c˜ao” do agente OA
Persistindo no exemplo, o Plano “Busca de Alvos” deve ser uma classe com o nome,
por exemplo, BuscaDeAlvosPlan, devendo extender a classe Plan. Para adicionar a a¸c˜ao
“Sugerir Rea¸c˜ao”, basta que seja chamada a assinatura addAction, passando a referˆencia
da a¸c˜ao abordada como parˆametro. Caso seja necess´ario adicionar sub-planos, ´e o mesmo
procedimento, por´em ´e a assinatura addPlan que deve ser solicitada. A figura a seguir
demonstra a estrutura do plano BuscaDeAlvosPlan.
FIG. 5.10: Plano “Busca de Alvos” do agente OA
Finalmente, a codifica¸c˜ao do agente OA ´e semelhante `a qualquer agente a ser criado no
JADE, isto ´e, deve implementar o m´etodo setup(), adicionando o plano BuscaDeAlvoiPlan
atrav´es do m´etodo addPlano(), da mesma forma como planos adicionam sub-planos e
a¸c˜oes. A figura 5.11 reflete a codifica¸c˜ao esperada.
66
FIG. 5.11: Agente OA
5.3.2 O AGENTE OLIG
A maneira de codificar a¸c˜oes, planos e o pr´oprio agente OLig ´e semelhante ao relatado no
agente OA. Como o foco para o crosscutting no OLig ´e para o relacionamento add, n˜ao
houve a necessidade em criar classes espec´ıficas representando a¸c˜oes (por isso, a utiliza¸c˜ao
do FakeAction na figura 5.12 apenas representa qualquer a¸c˜ao). O motivo assegura-se em
viabilizar a incidˆencia do aspecto Interatividade no agente diretamente atrav´es do n´ıvel
de planos, n˜ao importando quais a¸c˜oes est˜ao presentes no agente.
Ent˜ao, nas figuras 5.12 e 5.13, ´e poss´ıvel verificar como deve ser codificado o plano
“Autoriza¸c˜ao de Fogo” e o agente OLig em si, da mesma forma como demonstrado pelo
agente OA.
FIG. 5.12: Plano “Autoriza¸c˜ao de Fogo” do agente OLig
5.3.3 O ASPECTO AUTONOMIA PARA O RELACIONAMENTO HORIZONTAL
MERGE
Em primeiro lugar, verifica-se quais a¸c˜oes devem ser interceptadas para cada tipo de rela-
cionamento (refine before, refine after, refine around e redefine). O agente
67
FIG. 5.13: Agente OLig
OA possui a¸c˜oes a serem interceptadas pelos relacionamentos refine before (a¸c˜oes,
representadas pelas classes SugerirReacaoAction e SugerirParametrosParaMTAction) e
redefine (a¸c˜oes, representadas pelas classes CruzarDadosComInformacoesDeInteligen-
ciaAction e CruzarNaturezaEDimensoesDoAlvoComNomogramasAction) (fig. 5.14).
Adiante, depois que cada a¸c˜ao ´e adicionada ao plano correspondente do agente OA,
um advice after verifica se a a¸c˜ao em quest˜ao deve ser interceptada pelo relacionamento
refine before ou redefine. Caso deva, o aspecto Autonomia ir´a “guardar” o rela-
cionamento desta a¸c˜ao (fig. 5.15).
Os pointcuts refineBefore e redefine devem verificar se a a¸c˜ao corrente ´e uma chamada-
padr˜ao do JADE e possui o relacionamento correspondente. Caso seja, a camada de a¸c˜oes
reutilizar´a o pointcut relacionado ao relacionamento horizontal. O pointcut refineBefore
informa a execu¸c˜ao da a¸c˜ao “Retornar resultados” do aspecto quando o teste indicar a
execu¸c˜ao de uma a¸c˜ao relacionada ao pointcut, assim como uma chamada-padr˜ao de a¸c˜ao
no JADE. Da mesma maneira ocorre para as a¸c˜oes “Buscar resultados mais adequados”
e “Retornar resultados” no pointcut redefine, quando o teste indicar a execu¸c˜ao de uma
a¸c˜ao relacionada ao pointcut e a chamada-padr˜ao de a¸c˜oes do JADE (fig. 5.16).
A camada de planos especifica as assinaturas das a¸c˜oes do aspecto realizadas pelo as-
pecto Autonomia. Al´em disso, atrav´es da a¸c˜ao “action”, demonstra a ordem da execu¸c˜ao
das a¸c˜oes dos aspectos, dada a verifica¸c˜ao do relacionamento da a¸c˜ao correspondente.
Tanto estas assinaturas, quanto a a¸c˜ao, s˜ao utilizadas diretamente pela camada de a¸c˜oes
do aspecto Autonomia (fig. 5.17).
A defini¸c˜ao das a¸c˜oes na camada de a¸c˜oes reflete o que ´e executado pelo aspecto
68
FIG. 5.14: Verifica¸c˜ao de a¸c˜oes no agente OA a serem interceptados pelo aspecto Autono-
mia
Autonomia. As figuras a seguir especificam dois aspectos diferentes, um para refine before
e outro para redefine, por´em poderiam constituir apenas um. Isso foi feito apenas para
facilitar o entendimento. O c´odigo ´e semelhante ao apresentado no cap´ıtulo 4.
Ap´os a execu¸c˜ao do agente OA, s˜ao geradas no console v´arias mensagens, indicando o
que foi executado em cada momento, ou seja, quando a¸c˜oes do aspecto Autonomia exe-
cutaram e quando a¸c˜oes do agente OA tamb´em o fizeram. Nota-se pela figura 5.15, nas
setas (i) e (ii) a a¸c˜ao “Retornar resultados” executou imediatamente antes da execu¸c˜ao da
a¸c˜ao SugerirReacaoAction, assim como da a¸c˜ao SugerirParametrosParaMTAction, ambos
do OA. As setas (iii), (iv), (v) e (vi) indicam o relacionamento redefine, isto ´e, a substi-
tui¸c˜ao pelas a¸c˜oes “Receber parˆametros” e “Buscar resultados mais adequados”, quando
o aspecto Autonomia identificar a execu¸c˜ao das a¸c˜oes CruzarDadosComInformacoesDeIn-
teligenciaAction e CruzarNaturezaEDimensoesDoAlvoComNomogramasAction. Nota-se,
neste caso, que as a¸c˜oes espec´ıficas de redefine do agente OA n˜ao foram executadas (fig.
5.18).
69
FIG. 5.15: Adi¸c˜ao de relacionamentos em a¸c˜oes no agente OA no momento em que s˜ao
adicionados `a seus respectivos planos
FIG. 5.16: Pointcuts para informar `a camada de a¸c˜oes do aspecto Autonomia se a a¸c˜ao
corrente do agente OA deve ser interceptada
5.3.4 O ASPECTO INTERATIVIDADE PARA O RELACIONAMENTO HORIZON-
TAL ADD
Para a determina¸c˜ao de regras para a intercepta¸c˜ao no n´ıvel de planos, no relacionamento
add o mecanismo diferencia-se do merge, pois o crosscutting deve ser determinado di-
retamente pelo n´ıvel de planos, ou seja, ´e o n´ıvel de planos que de fato determina qual ´e
o momento que planos de aspectos devem incidir em planos de agentes, antes (add be-
fore) ou depois (add after). Ent˜ao, o agente OLig deve ser interceptado pelo aspecto
Interatividade em dois momentos:
• Quando o aspecto define o relacionamento add before nos planos ApreciacaoDe-
PedidoDeMTPlan e TratamentoDeMensagemPlan do agente OLig;
• Quando o aspecto define o relacionamento add after nos planos ApreciacaoDe-
70
FIG. 5.17: Assinaturas e controle de ordem de execu¸c˜oes de a¸c˜oes do aspecto Autonomia,
em a¸c˜oes do agente OA que devem ser interceptados
PedidoDeMTPlan, SuspensaoDeFogoPlan e AutorizacaoDeFogoPlan
Inicialmente deve ser verificado quais planos devem possuir o relacionamento add
before, al´em de verificar se o plano “Plano de recebimento de mensagens” do aspecto
Interatividade j´a executou alguma vez. Esta ´ultima verifica¸c˜ao ´e necess´aria, pois a¸c˜oes
do plano do aspecto Interatividade executam antes que qualquer a¸c˜ao do plano do OLig
verificado, evitando-se que a¸c˜oes do plano de aspecto executem antes da execu¸c˜ao de mais
que uma a¸c˜ao do agente OLig. Ent˜ao, conclui-se que este procedimento assegura que as
a¸c˜oes do plano do aspecto executar˜ao exclusivamente antes que a primeira a¸c˜ao a ser
executada do agente OLig (fig. 5.19).
De maneira muito semelhante, verificam-se tamb´em quais planos devem possuir o
relacionamento add after. Adicionalmente, ´e necess´ario que se teste se o plano corrente
do agente OLig j´a cumpriu seu objetivo, isto ´e, se seu status indica “pronto”, confirmando
a importˆancia na modifica¸c˜ao do JADE para este fim, pois originalmente n˜ao ´e capaz de
informar quando o plano (comportamento decomposto) chegou `a sua meta. A verifica¸c˜ao
deste status ´e de extrema importˆancia, pois sinaliza o momento em que o plano “Plano de
envio de mensagens” do aspecto Interatividade ir´a determinar a execu¸c˜ao de suas a¸c˜oes
71
FIG. 5.18: Console com a¸c˜oes do aspecto Autonomia e do agente OA
FIG. 5.19: Verifica¸c˜ao de planos, de acordo com o agente OLig, a serem interceptados
pelo plano “Plano de envio de mensagens” do aspecto Interatividade
correspondentes (fig. 5.20).
FIG. 5.20: Verifica¸c˜ao de planos, de acordo com o agente OLig, a serem interceptados
pelo plano “Plano de recebimento de mensagens” do aspecto Interatividade
Em seguida, da mesma forma como especificado no relacionamento merge, depois que
cada a¸c˜ao ´e adicionada ao plano correspondente do agente OLig, um advice after verifica
se a a¸c˜ao a ser analisada deve informar ao seu plano se o mesmo deve ser interceptado
pelo relacionamento add before ou add after. Caso atenda, o aspecto Interatividade
ir´a sinalizar ao plano qual ´e o tipo de relacionamento especificado.
O pointcut addBefore verifica, ent˜ao, se a a¸c˜ao correspondente do plano, al´em de ser
uma chamada-padr˜ao do JADE, possui o relacionamento add before. Ent˜ao, qualquer
72
a¸c˜ao do agente OLig, tanto do plano ApreciacaoDePedidoDeMTPlan quanto do Trata-
mentoDeMensagemPlan, n˜ao pode ser executada antes que todas as a¸c˜oes do plano “Plano
de Recebimento de Mensagens” do aspecto Interatividade tiverem sido executadas.
O pointcut addAfter possui a verifica¸c˜ao diretamente em planos do agente OLig para o
relacionamento add after, pois identifica em que momento o JADE sinaliza que o plano
ApreciacaoDePedidoDeMTPlan, SuspensaoDeFogoPlan ou AutorizacaoDeFogoPlan ana-
lisado no agente OLig alcan¸cou seu objetivo. Ent˜ao, o plano “Envio de Mensagens” do
aspecto Interatividade deve atuar ap´os a identifica¸c˜ao de conclus˜ao de cada um dos planos
relacionados do agente OLig.
Da mesma forma que o aspecto Autonomia, o aspecto Interatividade tamb´em especi-
fica, na camada de planos, as assinaturas das a¸c˜oes a serem implementadas na camada de
a¸c˜oes, onde a execu¸c˜ao ocorre de fato. Na figura 5.18, ´e apresentado como os pointcuts
addBefore e addAfter devem ser codificados, al´em das assinaturas das a¸c˜oes do aspecto
Interatividade.
Os planos “Plano de recebimento de mensagens” e “Plano de envio de mensagens” do
aspecto Interatividade definem, ent˜ao, dados os testes previamente executados, a ordem
de execu¸c˜ao de suas respectivas a¸c˜oes para, assim, permitir a execu¸c˜ao efetiva na camada
de a¸c˜oes. As assinaturas “planBefore” e “planAfter” da figura 5.19 demonstram este
comportamento.
Finalmente, a camada de a¸c˜oes exprime o que ´e executado pelo aspecto Interativi-
dade. Da mesma forma que demonstrado pelo relacionamento merge, a separa¸c˜ao da
codifica¸c˜ao em aspectos diferentes tem como intuito destacar o entendimento indepen-
dente entre cada um de seus conceitos.
Ap´os a execu¸c˜ao do agente OLig, tamb´em podem ser visualizadas (enquanto o agente
OA est´a executando), v´arias mensagens no console, verificando-se como os planos “Plano
de recebimento de mensagens” e “Plano de envio de mensagens” do aspecto Interativi-
dade interceptam os planos do agente OLig. Nota-se, pela figura 5.8, como os planos
do aspecto interagem com os planos do agente. De acordo com o relacionamento add
before, o plano de recebimento de mensagens do aspecto Interatividade executa suas
respectivas a¸c˜oes antes que os planos ApreciacaoDePedidoDeMTPlan e TratamentoDe-
MensagemPlan do agente OLig, assim como pode ser verificado nas setas em (i) e (ii).
Imediatamente ap´os a execu¸c˜ao da ´ultima a¸c˜ao dos planos ApreciacaoDePedidoDeMT-
Plan, SuspensaoDeFogoPlan e AutorizacaoDeFogoPlan, o plano de envio de mensagens
73
FIG. 5.21: Console com a¸c˜oes em planos do aspecto Interatividade e do agente OLig
do aspecto Interatividade executa suas respectivas a¸c˜oes, como pode ser conferido nas
setas de (iii), (iv) e (v) (fig. 5.21).
74
6 AGENTES E ASPECTOS NA ENGENHARIA DE SOFTWARE
Na Engenharia de Software, o desenvolvimento de sistemas deve ser acompanhado
por metodologias ou t´ecnicas que evitem o uso de estrat´egias ad-hoc, de maneira que
tais sistemas atinjam n´ıveis de qualidade desej´aveis. Enquanto nas outras engenharias o
produto ´e encarado fundamentalmente como parte integrante de um processo de produ¸c˜ao,
na Engenharia de Software o produto ´e tratado atrav´es de projeto e implementa¸c˜ao, onde
sua cria¸c˜ao requer muito mais trabalho de engenharia do que de fabrica¸c˜ao (REZENDE,
2005).
Para que o software atinja um n´ıvel de qualidade aceit´avel, v´arias caracter´ısticas
devem ser analisadas, tais como corretude, manutenabilidade e evolu¸c˜ao (REZENDE,
2005). Para o caso de software desenvolvido com aspectos, outros mecanismos, tais como
transparˆencia (obliviousness) e quantifica¸c˜ao, deveriam ajudar na sua corretude, manute-
nabilidade e evolutibilidade.
Como a presente pesquisa defende a premissa que este paradigma pode ser constitu´ıdo
como uma nova Engenharia de Software, ent˜ao deve atender tamb´em `as mesmas carac-
ter´ısticas. A POA, como pode oferecer suporte diretamente `a SMA neste e em quaisquer
trabalhos que abordem este contexto, tamb´em deve acompanh´a-las.
No detalhamento das caracter´ısticas da Engenharia de Software que devem estar pre-
sentes em SMA que possuam o suporte de aspectos, as se¸c˜oes seguintes visam discutir
como estas caracter´ısticas s˜ao enfatizadas neste contexto, al´em de sugerir uma an´alise
quanto `a real aplicabilidade nos dias atuais. A se¸c˜ao 6.1 discute sobre a corretude; a
se¸c˜ao 6.2 sobre a manutenabilidade e a evolu¸c˜ao; a se¸c˜ao 6.3 aborda as caracter´ısticas de
transparˆencia e quantifica¸c˜ao; finalmente, a se¸c˜ao 6.4 apresenta uma visibilidade quanto `a
cria¸c˜ao de um estudo de caso real, analisando o que seria necess´ario fazer para que todas
as caracter´ısticas enfatizadas fossem atendidas. Embora esta discuss˜ao n˜ao seja completa,
serve como ponto de partida para o entendimento do uso de agentes com aspectos como
paradigma de desenvolvimento de software.
75
6.1 CORRETUDE
Um programa funcionalmente correto deve realizar suas fun¸c˜oes previamente especifi-
cadas, da forma como o cliente espera (REZENDE, 2005). Como a corretude estabelece
a equivalˆencia entre o software e sua respectiva especifica¸c˜ao, esta caracter´ıstica reflete
diretamente no grau de aceita¸c˜ao de um software por um potencial cliente.
A corretude pode ser determinada de v´arias maneiras (REZENDE, 2005). A utiliza¸c˜ao
de linguagens de alto n´ıvel que realizam a an´alise est´atica de codifica¸c˜ao e a utiliza¸c˜ao
de algoritmos e bibliotecas que garantam a qualidade do software s˜ao algumas das alter-
nativas vi´aveis. Al´em destas, tamb´em podem ser abordadas m´etodos experimentais (ou
testes de software) e m´etodos anal´ıticos, ou seja, a verifica¸c˜ao formal da corretude atrav´es
de f´ormulas, axiomas e provas formais.
Para o desenvolvimento de software orientado a agentes com modulariza¸c˜ao de carac-
ter´ısticas transversais com aspectos ´e necess´ario oferecer mecanismos que possam verificar
a corretude de incidˆencias dos relacionamentos transversais. Para isto, ´e importante es-
tabelecer um conjunto de regras que possam garantir que os aspectos cortam os agentes
certos no momento certo para o qual foram especificados.
Diversos trabalhos (ROCHA, 2005) (LEMOS, 2005) (MONK e HALL, 2002) apontam
para o uso de testes de software para verificar sistemas com caracter´ısticas transversais
modularizadas com aspectos. O trabalho de (ROCHA, 2005) apresenta uma ferramenta,
baseada no paradigma POA, para a realiza¸c˜ao de testes funcionais. Esta ferramenta,
chamada de J-FuT, provˆe o apoio `a testes funcionais atrav´es da linguagem Java e ´e baseada
em predicados que representam requisitos de testes, tais como classes de equivalˆencia e
valores-limite. Apesar do que a ferramenta se prop˜oe, a implementa¸c˜ao destes predicados
apresenta-se como a principal limita¸c˜ao da ferramenta, pois ´e realizada manualmente e
pode demandar esfor¸co.
A pesquisa de (LEMOS, 2005) sugere uma metodologia baseada em um modelo de
grafo de fluxo de controle orientado a aspectos e em dados resultantes da compila¸c˜ao e
da combina¸c˜ao de m´odulos manipulados por aspectos em AspectJ. Sua proposta aborda
o teste estrutural como um complemento ao teste funcional, baseando-se na estrutura de
um programa para que sejam derivados casos de teste. Para isso, ´e proposto um modelo
de fluxo de controle (onde requisitos de teste de fluxo de controle s˜ao derivados) e dois
crit´erios estruturais, destacados a seguir:
76
• Todos-n´os: garante que todas as instru¸c˜oes de um dado m´odulo tenham sido exe-
cutadas ao menos uma vez por algum caso de teste definido;
• Todas-arestas: requisita que cada aresta do grafo determinado seja interceptada ao
menos uma vez por algum caso de teste existente.
Testes unit´arios s˜ao amplamente utilizados no desenvolvimento OO, podendo ser
citado, por exemplo, um dos frameworks mais difundidos no cotidiano, o JUnit (HAROLD,
2005). Apesar de apresentar-se mais maduro em rela¸c˜ao `a abordagem com aspectos, n˜ao
ap´oia nenhuma t´ecnica de teste espec´ıfica, tornando-se ´util apenas para a especifica¸c˜ao e
execu¸c˜ao de casos de testes.
O fato de aspectos serem facilmente removidos ap´os a execu¸c˜ao de testes tamb´em
atraiu diversas pesquisas para permitir que testes fossem cobertos n˜ao apenas na etapa
funcional. (MONK e HALL, 2002) prop˜oem uma alternativa para a substitui¸c˜ao de
imita¸c˜oes virtuais de objetos, ao inv´es de objetos simuladores tradicionais no teste de
unidade (mock objects). Nesta proposta, nenhum objeto mock ´e criado, aspectos in-
terceptam as chamadas de sistema necess´arias e manipulam os valores esperados, sem
a necessidade de instancia¸c˜ao de objetos. Desta forma, aspectos permitem a realiza¸c˜ao
de testes distintos para as mesmas chamadas. A utiliza¸c˜ao desta abordagem se aplica
diretamente `a verifica¸c˜ao da corretude no paradigma de agentes de software, onde n˜ao h´a
mistura com conceitos de objetos.
Na corrente pesquisa, ´e importante que se verifique se aspectos, fundamentados no
modelo de composi¸c˜ao proposto pelo AspectualJADE para interceptar caracter´ısticas
transversais em SMA, realmente interceptam as funcionalidades pr´e-determinadas de
agentes de software e se o fazem no momento correto (antes, durante ou depois). O
estudo de caso n˜ao ´e suficiente para comprovar a corretude, dado que n˜ao ´e utilizada,
nesta pesquisa, nenhum m´etodo experimental ou anal´ıtico. Para a comprova¸c˜ao da cor-
retude, o trabalho proposto por (LEMOS, 2005) apresenta-se como mais interessante,
pois abrange, al´em de testes funcionais, a complementa¸c˜ao atrav´es do teste estrutural,
comprovando-se a partir de verifica¸c˜oes formais. A cobertura por testes deve ser em-
pregada no programa-base e nos aspectos, para que seja verificado se agentes e aspectos
realizam comportamentos esperados. Adicionalmente, testes de crosscutting apresentam-
se como fundamentais para o principal objetivo do AspectualJADE.
77
6.2 MANUTENABILIDADE E EVOLUC¸
˜
AO
Prover manuten¸c˜ao de software requer identificar o que deve ser modificado para que
satisfa¸ca as necessidades do cliente, logo ap´os alguma libera¸c˜ao de vers˜ao (REZENDE,
2005). A manuten¸c˜ao na Engenharia de Software n˜ao se refere apenas `a corre¸c˜ao de
problemas (ou bugs), mas tamb´em `a novas funcionalidades, que podem ser o resultado de
requisitos mal definidos ou que estavam ausentes na especifica¸c˜ao original.
Na verdade, o termo manuten¸c˜ao n˜ao se aplica `a realidade do desenvolvimento de
software, pois o mesmo passa uma id´eia de “consertar pe¸cas que se deterioraram com o
uso”. Um software n˜ao se deteriora em sua utiliza¸c˜ao, mas j´a apresenta “defeitos” quando
suas funcionalidades n˜ao realizam em sua totalidade o que ´e esperado.
A manuten¸c˜ao caracteriza-se como uma das atividades mais custosas no ciclo de de-
senvolvimento de software e pode ser dividida em trˆes categorias (REZENDE, 2005):
• Corretiva: corre¸c˜ao de eventuais erros encontrados em vers˜oes de software ou inseri-
dos na etapa de manuten¸c˜ao. Busca encobrir efeitos de reparo;
• Adaptativa: quando o software passa por altera¸c˜oes para que possa ser adaptado `a
algum novo ambiente ou quando surge a necessidade em se implantar caracter´ısticas,
das quais n˜ao se referem `as funcionalidades do pr´oprio software;
• Perfectiva: envolve a melhoria da qualidade do software, decorrente de modifica¸c˜oes
das pr´oprias funcionalidades, adi¸c˜ao de novas funcionalidades, melhoria de desem-
penho, de interface, ou dentre quaisquer outras caracter´ısticas (funcionais ou n˜ao-
funcionais).
A evolu¸c˜ao de produtos de software est´a diretamente associada `as categorias adapta-
tivas e perfectivas, pois as mesmas s˜ao as respons´aveis por mudan¸cas no software. Neste
intuito, deve ser analisada com que facilidade um sistema com agentes e aspectos pode
evoluir e se corre¸c˜oes podem representar amea¸cas `a qualidade do software. Como as-
pectos complementam o paradigma de agentes em caracter´ısticas transversais, deve ser
feito um rigoroso controle de vers˜oes para que, a partir de mudan¸cas realizadas no c´odigo
de agentes, aspectos possam continuar realizando o que ´e esperado, de forma que sejam
corrigidos ou evolu´ıdos paralelamente aos agentes.
Para que isso seja sustent´avel, o n´ıvel de acoplamento entre agentes e respectivas fun-
cionalidades tamb´em deve ser o m´ınimo poss´ıvel. Uma poss´ıvel corre¸c˜ao ou evolu¸c˜ao entre
78
agentes que afete v´arios m´odulos dependentes uns dos outros pode ocasionar uma an´alise
detalhada de como adaptar ou evoluir o aspecto respons´avel por uma funcionalidade
transversal, demandando um potencial esfor¸co para que o aspecto acompanhe mudan¸cas
em agentes. Para reduzir o acoplamento entre agentes de software, uma t´ecnica relevante
´e a utiliza¸c˜ao de Inje¸c˜ao de Dependˆencias (ou Invers˜ao de Controle) (FOWLER, 2004),
onde tais dependˆencias s˜ao tratadas fora do contexto da aplica¸c˜ao. Desta maneira, torna-
se mais f´acil verificar quais dependˆencias existem para uma funcionalidade de agentes e,
assim, realizar a modifica¸c˜ao correspondente em aspectos com mais precis˜ao.
Prover mudan¸cas em agentes n˜ao implica necessariamente modifica¸c˜oes em aspectos.
Se mudan¸cas em agentes implicarem em modifica¸c˜ao de funcionalidade ou inclus˜ao e
remo¸c˜ao de comportamentos transversais, ent˜ao deve-se analisar o impacto que poder´a
causar em todo o sistema. A Invers˜ao de Controle, embora reduza o n´ıvel de acoplamento
entre agentes, n˜ao garante que uma determinada funcionalidade de agente continue sendo
cortada por uma caracter´ıstica transversal corretamente, implicando a maior aten¸c˜ao do
desenvolvedor. A utiliza¸c˜ao de testes para viabilizar a corretude de pontos de corte em
SMA torna-se fundamental para que se tenha um software de qualidade.
Embora a orienta¸c˜ao a aspectos complemente o paradigma de agentes, devem ser
encarados como paradigmas distintos na gerˆencia de configura¸c˜ao. Desenvolvimento de
requisitos funcionais e n˜ao-funcionais, nesta vis˜ao, s˜ao “projetos” independentes. Para
a integra¸c˜ao cont´ınua e correta entre aspectos e agentes, aspectos devem ser auxiliados
por ferramentas que testem se cortam transversalmente agentes de maneira esperada.
Agentes devem ser desenvolvidos orientados por alguma t´ecnica que permita o menor
desacoplamento entre m´odulos poss´ıvel (por exemplo, a Invers˜ao de Controle j´a abordada)
e que o escopo de mudan¸cas seja avaliado criteriosamente, por´em sem o conhecimento da
presen¸ca de aspectos no sistema, pois caracter´ısticas transversais n˜ao devem interferir na
regra de neg´ocio original de agentes.
Para facilitar a manuten¸c˜ao de um sistema desenvolvido com ACROSS (PERES, 2006)
e AspectualJADE, deve ser analisado como testes de software podem contribuir na cor-
retude de SMA com caracter´ısticas transversais. Al´em disso, um estudo sobre t´ecnicas
ou metodologias de gerˆencia de configura¸c˜ao ´e necess´ario para orientar o desenvolvedor
no controle eficaz de versionamento de c´odigos de agentes e aspectos. Essas linhas de
pesquisa constituem propostas para trabalhos futuros.
79
6.3 TRANSPAR
ˆ
ENCIA E QUANTIFICAC¸
˜
AO
No paradigma orientado a aspectos, de acordo com (FILMAN e FRIEDMAN, 2005), as
propriedades de transparˆencia e quantifica¸c˜ao s˜ao fundamentais para que a POA constitua,
de fato, um paradigma que complemente o desenvolvimento de software. A transparˆencia
estabelece que, dada a existˆencia de um programa-base, n˜ao ´e poss´ıvel determinar como
aspectos incidem nele, na vis˜ao apenas ao programa-base. Ent˜ao, o desenvolvimento
exclusivo de agentes n˜ao necessita de qualquer codifica¸c˜ao que indique a presen¸ca de as-
pectos, isto ´e, n˜ao ´e no sistema, composto exclusivamente de regras de neg´ocio, que podem
ser identificados em que momento (antes, durante ou depois) funcionalidades de aspectos
devem incidir transversalmente.
´
E neste intuito que a POA “enxerga” o programa base e
nunca o contr´ario, onde ´e poss´ıvel determinar, atrav´es de join points, pointcuts e advices
em que momento aspectos devem ser executados em rela¸c˜ao ao programa-base.
A transparˆencia permite que o desenvolvedor de agentes n˜ao se preocupe com a in-
cidˆencia de aspectos no sistema, pois caracter´ısticas transversais, al´em de serem tratadas
e desacopladas por aspectos, n˜ao s˜ao especificadas explicitamente em regras de sistema
provenientes de agentes de software. Desta maneira, o c´odigo de agentes n˜ao necessita
que agentes externalizem as funcionalidades que dever˜ao ser cortadas. Esta caracter´ıstica
deveria facilitar a manuten¸c˜ao do sistema, se o desenvolvimento de agentes for encarado
como independente ao desenvolvimento de aspectos. Neste caso, a utiliza¸c˜ao de docu-
mentos e especifica¸c˜ao de sistema facilita o processo de manuten¸c˜ao do sistema, e devem
acompanhar toda a manuten¸c˜ao (corretiva, adaptativa ou perfectiva) para que se atinja
um n´ıvel de qualidade esperado pelo cliente.
Assim como o AspectualJADE determina que as funcionalidades transversais devem
ser codificadas por aspectos, ent˜ao o desenvolvedor de agentes deve pensar apenas nas
regras de neg´ocio de sistemas. Para isso, caracter´ısticas transversais n˜ao devem ser co-
nhecidas por agentes de software, de maneira que a transparˆencia n˜ao seja violada. O
desenvolvedor de agentes n˜ao deve escrever o agente pensando nos join points provenientes
dos aspectos, pois a estrutura de codifica¸c˜ao de agentes, planos e a¸c˜oes estabelecida pelo
AspectualJADE refere-se exclusivamente `a arquitetura do framework de desenvolvimento
de agentes, o JADE. Portanto, a maneira como se codificam os agentes de software deve
ser obedecida `a estrutura original do JADE, ou seja, a¸c˜oes devem implementar m´etodos
action() e planos devem obedecer `a proposta do AspectualJADE. A utiliza¸c˜ao de assi-
80
naturas previamente estabelecidas, al´em de facilitarem a manuten¸c˜ao e a evolu¸c˜ao de
SMA, ´e fundamentada em regras de codifica¸c˜ao que dificilmente ser˜ao modificadas, dada
a maturidade do JADE.
Seria interessante que se criassem aspectos, por exemplo, que seriam ao mesmo tempo
identificados como caracter´ısticas transversais, como tamb´em regras de neg´ocio, por´em
n˜ao-espec´ıficas de sistemas. Neste caso, desenvolvedores de agentes apenas saberiam que
tais funcionalidades existiriam, mas n˜ao saberiam de que maneira ocorrem. A transparˆencia
nesta situa¸c˜ao seria questionada, pois funcionalidades de neg´ocio estariam fora do alcance
destes desenvolvedores. Por isso, a utiliza¸c˜ao do AspectualJADE deve ser analisada caso
a caso, mas n˜ao pelos modelos de composi¸c˜ao que prop˜oe, e sim pelo significado de sua
utiliza¸c˜ao. Deve-se levar em considera¸c˜ao se aspectos podem ser respons´aveis por regras
de neg´ocio, mesmo se n˜ao forem espec´ıficas de sistemas, j´a que cada projeto de software
possui diferentes pontos de vista.
Ainda de acordo com (FILMAN e FRIEDMAN, 2005), a POA estabelece que o desen-
volvimento de sistemas obede¸ca a seguinte regra: “No programa P, sempre que a condi¸c˜ao
C for alcan¸cada, execute a a¸c˜ao A”. O programa P refere-se ao programa-base (no caso
a ser analisado, os agentes) e a a¸c˜ao A refere-se `a alguma funcionalidade proveniente
de algum aspecto. A quantifica¸c˜ao determina como condi¸c˜oes C, atrav´es da defini¸c˜ao
de join points advinda da POA, devem associar a¸c˜oes de aspectos com o programa-base.
Verifica-se, ent˜ao, que a quantifica¸c˜ao ´e a respons´avel por realizar a correspondˆencia entre
aspectos e agentes. (DA SILVA, 2006) estabelece que a quantifica¸c˜ao ´e a habilidade de se
escrever declara¸c˜oes unit´arias e separadas que visem atingir diversos pontos na codifica¸c˜ao
de sistemas.
Declara¸c˜oes unit´arias neste contexto estabelecem a ponte existente entre o c´odigo de
agentes e o c´odigo de aspectos. A POA permite que tais declara¸c˜oes sejam codificadas
em aspectos, j´a que agentes de software, como o programa-base, n˜ao devem ter ciˆencia
da incidˆencia de aspectos, assim como ´e determinado pela transparˆencia. Para que estas
declara¸c˜oes atinjam v´arios lugares de um sistema, aspectos permitem que sejam declaradas
atrav´es do uso de express˜oes regulares, referenciadas pela POA como wildcards.
A utiliza¸c˜ao de wildcards facilita a especifica¸c˜ao de v´arios pontos de um programa-base
que um ponto de corte (ou pointcut) deve ser atingido. Deste modo, ´e poss´ıvel especi-
ficar a semˆantica de assinaturas de funcionalidades que aspectos devem realizar a¸c˜oes
transversalmente. Em OO, wildcards permitem que m´etodos declarados em classes, de
81
acordo com alguma regra de assinatura, possam ser cortados por aspectos. Por exemplo,
a figura a seguir demonstra que o aspecto Authentication define um pointcut que ´e iden-
tificado atrav´es da execu¸c˜ao de todos os m´etodos da classe Account, independentemente
da quantidade de parˆametros e respectivos tipos (n´umeros, caracteres etc.).
FIG. 6.1: Exemplo de wildcard em aspecto
O maior problema na utiliza¸c˜ao de wildcards ´e a consistˆencia de c´odigo. Supondo
que todos os m´etodos de uma determinada funcionalidade possuam um prefixo “listar” e
se deseje aplicar um aspecto que registre em logging todas as chamadas de m´etodos que
possuam este prefixo. Inicialmente, a semˆantica do sistema significa que todo m´etodo que
possua este prefixo refere-se `a uma listagem de quaisquer objetos. Em determinado mo-
mento, decide-se que algumas classes devem possuir o mesmo prefixo, mas que n˜ao sejam
interceptadas pelo mesmo aspecto, pois podem referir-se `a funcionalidades de listagem
de relat´orios (onde relat´orios n˜ao s˜ao simplesmente listas de objetos), por exemplo. Uma
simples mudan¸ca na regra implica no retrabalho para a determina¸c˜ao de quando o aspecto
dever´a interceptar os pontos necess´arios do programa-base.
Por isso, a utiliza¸c˜ao de wildcards ´e recomendada quando ´e poss´ıvel projetar-se regras
que n˜ao impliquem na semˆantica de assinaturas do programa-base. Para o Aspectual-
JADE, este n˜ao ´e um problema, pois todas as chamadas de a¸c˜oes s˜ao determinadas por
m´etodos action, pois ´e assim como o framework JADE estabelece a chamada de fun-
cionalidades atˆomicas. Uma efetiva mudan¸ca nesta regra afetaria todo o sistema, mas
pela maturidade do JADE, n˜ao apresenta-se como uma mudan¸ca que realmente ir´a ocor-
rer. Al´em disso, toda a¸c˜ao deve estender uma classe Action, obrigando o desenvolvedor a
criar suas a¸c˜oes com a mesma assinatura interceptada por aspectos no AspectualJADE.
82
6.4 VISIBILIDADE PARA O ASPECTUALJADE
Em detrimento `a an´alise das principais caracter´ısticas da Engenharia de Software, ´e rele-
vante que seja verificada a viabilidade da utiliza¸c˜ao do AspectualJADE em um estudo de
caso, de forma que tais caracter´ısticas sejam satisfeitas.
Na an´alise da corretude, foi identificado que, para que se construa um sistema de
forma correta, podem ser utilizadas abordagens experimentais e anal´ıticas. Esta veri-
fica¸c˜ao tamb´em ´e uma preocupa¸c˜ao presente em sistemas OO para aumentar o n´ıvel de
confiabilidade do software. Em especial `a an´alise deste cap´ıtulo, a maior preocupa¸c˜ao
existente ´e verificar se aspectos incidem em SMA da forma como ´e esperada pelo usu´ario,
assim como o AspectualJADE oferece em sua essˆencia.
Para que um sistema baseado nos conceitos do AspectualJADE provenha uma maior
facilidade de manuten¸c˜ao e evolu¸c˜ao, deve ser constru´ıdo pensando-se na modularidade
de funcionalidades previstas. Para que isso seja poss´ıvel, tais funcionalidades devem
possuir baixo acoplamento, e isso pode ser alcan¸cado atrav´es da Invers˜ao de Controle
(FOWLER, 2004). Ent˜ao, as dependˆencias entre agentes e suas respectivas funcionali-
dades s˜ao tratadas fora do contexto das regras de neg´ocio.
Al´em do baixo acoplamento, ´e importante que uma metodologia de desenvolvimento
seja fundamentada em modelos que provenham a generaliza¸c˜ao. Por este motivo, o Aspec-
tualJADE foi baseado nos conceitos e modelos do framework ACROSS (PERES, 2006).
As abstra¸c˜oes e relacionamentos de agentes, tamb´em utilizadas por um paradigma que
complementa SMA - POA, determina que quaisquer sistemas podem ser concebidos, in-
dependentemente das regras de neg´ocio envolvidas.
Em rela¸c˜ao `a transparˆencia, o AspectualJADE n˜ao estabelece relacionamento expl´ıcito
do programa-base (SMA) com aspectos. De acordo com o AspectualJADE, relacionamen-
tos verticais dizem respeito apenas ao paradigma de agentes, enquanto que relacionamen-
tos horizontais s˜ao definidos apenas em aspectos. Ent˜ao, agentes de software podem
ser constru´ıdos e mantidos sem que o desenvolvedor de agentes tenha conhecimento que
existem aspectos realizando caracter´ısticas transversais.
Finalmente, a quantifica¸c˜ao pode ser alcan¸cada atrav´es da utiliza¸c˜ao de wildcards,
recurso dispon´ıvel atrav´es da POA. Como o framework JADE estabelece que o processa-
mento computacional ocorre atrav´es de a¸c˜oes atˆomicas, onde comportamentos s˜ao realiza-
dos atrav´es de m´etodos action(), ent˜ao o modelo de composi¸c˜ao proposto pelo Aspectual-
83
JADE verifica exatamente o momento em que comportamentos de agentes realizam a¸c˜oes.
Para manter a consistˆencia com o JADE, n˜ao poderia existir nenhuma chamada com o
nome action que n˜ao fosse um comportamento atˆomico controlado por algum agente, ao
mesmo tempo que haja alguma entidade que seja filha de uma classe Action. Na ver-
dade, o desenvolvedor de agentes deve ter consciˆencia que a utiliza¸c˜ao da classe Action,
na defini¸c˜ao de uma funcionalidade que possua a assinatura action(), deve ser constitu´ıda
exclusivamente como uma entidade que represente a abstra¸c˜ao de a¸c˜ao, assim como ´e
proposto pelo framework ACROSS (PERES, 2006).
84
7 CONCLUS
˜
OES
Nos ´ultimos anos, tem-se observado o interesse significativo e crescente no estudo e
desenvolvimento de sistemas distribu´ıdos. Este crescimento ´e fruto da prolifera¸c˜ao da
Internet e da demanda pelo acesso ub´ıq¨uo `a informa¸c˜ao, o que vem abrindo maior espa¸co
para o paradigma de SMA. Esta id´eia tem se tornado n˜ao s´o um t´opico de pesquisa
acadˆemica, como tamb´em em aplica¸c˜oes comerciais.
Um SMA possui um conjunto de agentes, que implementam requisitos funcionais, n˜ao-
funcionais e certas caracter´ısticas de agˆencia (autonomia, mobilidade etc.). No desenvolvi-
mento de um agente, ´e dif´ıcil modularizar os requisitos n˜ao-funcionais e as caracter´ısticas
de agˆencia, dificultando a compreens˜ao e o reuso. Uma solu¸c˜ao para este problema ´e o
uso de aspectos, que s˜ao usados para modularizar estas caracter´ısticas transversais.
A pesquisa em SMA com modulariza¸c˜ao de caracter´ısticas transversais possui diversos
trabalhos, tanto no n´ıvel de requisitos (SILVA et al., 2006) (GARCIA et al., 2006) (PERES
et al., 2006), quanto no n´ıvel de projeto detalhado e implementa¸c˜ao (LOBATO, 2005) e
o (GARCIA et al., 2001b). No entanto, os trabalhos no n´ıvel de projeto detalhado e
implementa¸c˜ao de agentes com aspectos n˜ao apresentam solu¸c˜oes que tratam agentes e
aspectos como abstra¸c˜oes de mesmo n´ıvel, isto ´e, como abstra¸c˜oes compostas pelos mesmos
conceitos.
O objetivo do AspectualJADE ´e ser uma plataforma para a modulariza¸c˜ao de car-
acter´ısticas transversais por aspectos para SMA, definindo aspecto como abstra¸c˜ao de
primeira ordem em SMAs e usando o modelo de composi¸c˜ao definido em (PERES et al.,
2006). Para tanto, o AspectualJADE:
• Provˆe abstra¸c˜oes nos n´ıveis de planos e a¸c˜oes estabele¸cam pontos de corte por as-
pectos para a incidˆencia nas abstra¸c˜oes correspondentes de mesmo n´ıvel em agentes,
ou seja, planos de aspectos incidam diretamente em planos de agentes, assim como
a¸c˜oes de aspectos reflitam em a¸c˜oes de agentes;
• N˜ao mistura conceitos da orienta¸c˜ao a objetos, tanto nos paradigmas de agentes de
software, quanto na POA.
Para suprir as quest˜oes levantadas e atender `a seus objetivos, o AspectualJADE prop˜oe
85
algumas modifica¸c˜oes a serem realizadas no framework JADE para que a sua defini¸c˜ao
de comportamento possa sofrer decomposi¸c˜ao em planos, sub-planos e a¸c˜oes. Al´em disso,
tamb´em foram introduzidos os relacionamentos verticais propostos por (PERES, 2006)
e (PERES et al., 2006) entre as abstra¸c˜oes de planos e a¸c˜oes (and, or e xor), com
o intuito de permitir o estabelecimento de regras em planos para que, a partir de seus
relacionamentos, determine em que momento seu objetivo foi alcan¸cado.
Modifica¸c˜oes quanto aos relacionamentos horizontais n˜ao foram necess´arias, justificando-
se que este tipo de relacionamento estabelece o corte transversal de aspectos em agentes,
ent˜ao tais relacionamentos devem ser definidos e controlados por aspectos. No n´ıvel de
planos, os cortes foram refletidos a partir das defini¸c˜oes de add e merge. No rela-
cionamento ADD, planos de aspectos atuam diretamente em planos de agentes, podendo
atuar antes (add before) ou depois (add after) da execu¸c˜ao do plano de agente cor-
respondente. J´a no relacionamento merge, ´e sinalizado que a¸c˜oes de aspectos atuam
diretamente em a¸c˜oes de agentes, podendo ocorrer antes (refine before), durante
(refine around) ou depois (refine after) da execu¸c˜ao das a¸c˜oes correspondentes
de agentes, al´em de ainda ser poss´ıvel a substitui¸c˜ao de a¸c˜oes de agentes por a¸c˜oes de
aspectos (redefine).
7.1 CONTRIBUIC¸
˜
OES
Inicialmente, foram listadas as contribui¸c˜oes para que este trabalho as atingisse como
metas. Estas contribui¸c˜oes s˜ao listadas novamente a seguir, especificando como foram
alcan¸cadas:
• Preparar o framework JADE para tornar poss´ıvel a implementa¸c˜ao de
abstra¸c˜oes de planos e a¸c˜oes, assim como os relacionamentos verticais
entre eles: originalmente, o framework JADE possui uma estrutura b´asica para
a decomposi¸c˜ao de comportamentos (behaviours) de agentes de software. A modi-
fica¸c˜ao realizada baseou-se em explicitar o conceito de planos como comportamentos
decompostos em outros comportamentos, at´e que se chegue em comportamentos in-
divis´ıveis (interpretados como a¸c˜oes). Tamb´em foi necess´ario definir relacionamentos
verticais do tipo and, or e xor para que comportamentos divis´ıveis, visualizados
como planos, possam determinar regras para a execu¸c˜ao de sub-planos e a¸c˜oes para
alcan¸carem seus objetivos particulares;
86
• Apresentar a plataforma AspectualJADE, uma proposta de integra¸c˜ao
entre agentes e aspectos, onde aspectos incidem transversalmente em
agentes: esta plataforma introduziu o conceito de aspecto na plataforma JADE
como forma de modularizar caracter´ısticas transversais em SMAs. O modelo de
composi¸c˜ao entre agentes e aspectos ´e o apresentado em (PERES et al., 2006);
• Reaproveitamento de abstra¸c˜oes e relacionamentos entre aspectos e agentes,
definidos no framework ACROSS (PERES, 2006) em n´ıvel de projeto
detalhado para o AspectualJADE, possibilitando a gera¸c˜ao parcial de
c´odigos de planos e a¸c˜oes: a partir dos conceitos de abstra¸c˜oes e relacionamen-
tos horizontais e verticais no n´ıvel de projeto detalhado definidos em (PERES, 2006),
foi poss´ıvel definir como deve ser a codifica¸c˜ao de agentes e aspectos de acordo com
a metodologia adotada;
• Apresentar o Estudo de Caso baseado na pesquisa de (PERES, 2006),
para demonstrar que o AspectualJADE atende `as abstra¸c˜oes e aos rela-
cionamentos entre agentes e aspectos no n´ıvel de implementa¸c˜ao: assim
como as abstra¸c˜oes e relacionamentos s˜ao baseadas na proposta do ACROSS, o es-
tudo de caso tamb´em foi fundamentado a partir do estudo de caso apresentado no
mesmo trabalho. O estudo de caso comprova a coerˆencia com abstra¸c˜oes e relaciona-
mentos e a viabilidade em desenvolver SMA com modulariza¸c˜ao de caracter´ısticas
transversais atrav´es da AOP sem mistura com conceitos de objetos e relacionando
o crosscutting de aspectos em agentes atrav´es dos mesmos n´ıveis de abstra¸c˜oes.
7.2 TRABALHOS FUTUROS
O AspectualJADE ainda deixa algumas quest˜oes em aberto para trabalhos futuros:
• Desenvolvimento de uma melhor abordagem para a codifica¸c˜ao de planos
em agentes: embora o JADE tenha permitido a decomposi¸c˜ao de comportamentos
para os conceitos de planos, sub-planos e a¸c˜oes, n˜ao houve muita preocupa¸c˜ao em
uma melhor maneira de especificar como as regras de planos devem se comportar.
Assim como pode ser verificado na classe Plan, no apˆendice (se¸c˜ao 9, listagem 9.1), o
m´etodo checkCondition() define como o plano verifica a sua condi¸c˜ao de parada, ou
seja, ´e exemplificado que o plano, quando n˜ao utiliza a forma padronizada do JADE,
87
possui apenas um sub-plano ou a¸c˜ao com o relacionamento vertical and e os demais
s˜ao do tipo or ou xor. Seria adequado definir, apenas no contexto de agentes, uma
forma gen´erica para verifica¸c˜ao de regras em planos como, por exemplo, a utiliza¸c˜ao
de xml-schemas na estrutura¸c˜ao de planos, sub-planos e a¸c˜oes, assim como tamb´em
´e sugerido em (PERES, 2006);
• Ferramenta para identifica¸c˜ao e manipula¸c˜ao de caracter´ısticas de quan-
tifica¸c˜ao em SMA: assim como (FILMAN e FRIEDMAN, 2005) estabelece que
o mecanismo de quantifica¸c˜ao tamb´em ´e necess´aria para a AOP, ent˜ao existe a ne-
cessidade por uma ferramenta que provenha a identifica¸c˜ao e o controle de eventos
est´aticos e dinˆamicos em SMA;
• Melhoria na metodologia de desenvolvimento de SMAs com caracter´ısticas
transversais com aspectos: embora o modelo de composi¸c˜ao atenda ao que ´e
proposto, trata-se da primeira metodologia para a defini¸c˜ao das regras propostas
pelo AspectualJADE. Um estudo mais aprofundado, provavelmente com ˆenfase no
reaproveitamento de outras metodologias identificadas na literatura, pode contribuir
para o amadurecimento de plataformas de implementa¸c˜ao no contexto que o Aspec-
tualJADE atua;
• Defini¸c˜ao de arquitetura para o desenvolvimento de SMAs baseada em
modelos provenientes do ACROSS em (PERES, 2006), de forma semel-
hante ao Model Driven Architecture (MDA): assim como o MDA se baseia
em modelos para prover uma metodologia para desenvolvimento de software, de
acordo com as especifica¸c˜oes OMG (OMG, 2005) para a orienta¸c˜ao a objetos, uma
proposta de cria¸c˜ao de metodologia para a arquitetura de SMAs, fundamentada no
modelo do ACROSS (PERES, 2006), ´e uma proposta que agrega valor na abertura
de novos caminhos de pesquisa;
• Estudo e propostas de metodologias sobre incidˆencia de aspectos em
SMA, segundo alguns crit´erios da Engenharia de Software: um estudo
comparativo entre trabalhos como (ROCHA, 2005), (LEMOS, 2005) e (MONK e
HALL, 2002) pode auxiliar na cria¸c˜ao de uma metodologia orientada a testes para
a verifica¸c˜ao da corretude proposta pelo modelo de composi¸c˜ao do AspectualJADE.
Para prover melhor manuten¸c˜ao e facilidade de evolu¸c˜ao em sistemas neste contexto,
88
deve ser analisado como a Invers˜ao de Controle (FOWLER, 2004) pode contribuir
para o desacoplamento de m´odulos de sistema, assim como deve ser realizada a
gerˆencia de configura¸c˜ao tanto para agentes, quanto para aspectos. Uma an´alise
mais aprofundada quanto `a transparˆencia em um estudo de caso especialmente des-
ignado para esta verifica¸c˜ao tamb´em ´e fundamental na comprova¸c˜ao que aspectos
s˜ao “invis´ıveis” em rela¸c˜ao `a um programa-base. Finalmente, um estudo quanto `a
utiliza¸c˜ao de wildcards em aspectos para prover a quantifica¸c˜ao em SMA mostra-
se fundamental para justificar que o AspectualJADE atende `a pontos de corte em
v´arios pontos de um SMA.
89
8 REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS
AOS. JACK Intelligent Agents Agent Manual, 2005. Dispon´ıvel em
http://www.agentsoftware.com/shared/demos/docs/AgentManual.pdf.
BANIASSAD, E. e CLARKE, S. Finding aspects in requirements with theme/doc.
Aspect-Oriented Requirements Engineering and Architecture Design. Dispon´ıvel em
http://citeseer.ist.psu.edu/643125.html, 2004.
BELLIFEMINE, F. L., CAIRE, G., e GREENWOOD, D. Developing multi-agent
systems with JADE. John Wiley & Songs, 2005.
BORDINI, R. H. Jason, manual, release 0.7 edition, 2005. URL
http://jason.sf.net/.
BORDINI, R. H., BRAUBACH, L., DASTANI, M., SEGHROUCHNI, A. E. F., GOMEZ-
SANZ, J. J., LEITE, J., HARE, G. O., POKAHR, A., e RICCI, A. A survey of
programming languages and platforms for multi-agent systems. Em Infor-
matica (30), p´ags. 33–44, 2005.
CHAVEZ, C. A Model-Driven Approach to Aspect-Oriented Design. Tese de
Doutorado, Computer Science Department, PUC-Rio, 2004.
CHEONG, C. e WINIKOFF, M. Hermes: Designing goal-oriented agent interac-
tions. Lecture Notes in Computer Science : Agent-Oriented Software Engineering VI,
3950:16–27, 2006.
CHOREN, R. e LUCENA, C. J. P. Modeling multi-agent systems with anote.
Software System Modeling 4(2), p´ags. 199–208, 2005.
COSSENTINO, M. e ZAMBORELLI, F. Agent design from the autonomy perspec-
tive. In Agents and Computational Autonomy: Potential, Risks and Solutions (LNCS
2629), p´ags. 140–150, 2004.
DA SILVA, L. F. Uma Estrat´egia Orientada a Aspectos para a Modelagem de
Requisitos. Tese de Doutorado, Computer Science Department, PUC-Rio, 2006.
DIJKSTRA, E. W. A discipline of programming. Prentice-Hall Series in Automatic
Computation, Englewood Cliffs:Prentice Hall, 1976, 1976.
EGGCF. Manual de Campanha C 6-40 - T´ecnica de Tiro de Artilharia de
Campanha, 2001. Volume 12.
ELRAD, FILMAN, e BADER. Aspect-oriented programming. Communications of
the ACM, 44(10):29–32, 2001.
90
FILMAN, R. E. e FRIEDMAN, D. P. Aspect-oriented programming is quantifi-
cation and obliviousness. Em Aspect-Oriented Software Development, p´ags. 21–35.
Addison-Wesley, 2005.
FIPA-OS. FIPA-OS Developers Guide, 2001. URL
http://fipa-os.sourceforge.net/docs/Developers Guide.pdf.
FOWLER, M. Inversion of control containers and the dependency injection
pattern. Technical report, ThoughtWorks, 2004.
GAMMA, E., HELM, R., JOHNSON, R., e VLISSIDES, J. M. Design Patterns:
elements of reusable object-oriented software. Addison-Wesley, 1995.
GARCIA, A., CHAVEZ, C., e CHOREN, R. An aspect-oriented modeling frame-
work for designing multi-agent systems. Em 7th International Workshop on
Agent-oriented Software Engineering (AOSE-2006), p´ag. 12, 2006.
GARCIA, A., LUCENA, C. J. P., e COWAN, D. D. Agents in object oriented soft-
ware enginnering. Technical report, Computer Science Department, University of
Waterloo, Waterloo, Canada, 2001a.
GARCIA, A., SILVA, V. T., LUCENA, C. J. P., e MILIDI
´
U, R. An aspect-based ap-
proach for developing multi-agent object-oriented systems. Simp´osio Brasileiro
de Engenharia de Software, Rio de Janeiro, Brazil, p´ags. 177–192, 2001b.
GARCIA, A. F. Objetos e Agentes: Uma Abordagem Orientada a Aspecto. Tese
de Doutorado, Computer Science Department, PUC-Rio, 2004.
HAROLD, E. An early look at junit 4. Developer Works, p´ag. 10, 2005.
IGLESIAS, C., GARRIJO, M., e GONZALEZ, J. A survey of agent oriented method-
ologies. Em 5th International Workshop on Intelligent Agents: Agent Theories, Ar-
chitectures, and Languages (ATAL-98), p´ags. 317–330, 1998.
IMBEL. Homepage da imbel - sistema genesis, 2006. URL
http://www.imbel.gov.br/.
JENNINGS, N. e WOOLDRIDGE, M. Agent-oriented software en-
gineering. Em Proceedings of the 9th European Workshop on Mod-
elling Autonomous Agents in a Multi-Agent World : Multi-Agent Sys-
tem Engineering (MAAMAW-99), volume 1647, p´ags. 1–7, 2001. URL
http://citeseer.ist.psu.edu/article/jennings00agentoriented.html.
JENNINGS, N. R. On agent based software engineering. Artificial Intelligence, 117
(2):277–296, 2000.
KANG, M., WANG, L., e TAGUCHI, K. Modelling mobile agent applications in
uml 2.0 activity diagrams. Em 3rd Software Engineering for Large-Scale Multi-
Agent Systems (SELMAS-2004) Workshop at International Conference on Software
Engineering (ICSE), p´ag. 8, 2004.
91
KENDALL, A. Agent roles and aspects. Em European Conference on
Object-Oriented Programming (ECOOP-98) Workshops, p´ag. 440, 1998. URL
citeseer.ist.psu.edu/kendall98agent.html.
KICZALES, G., HILSDALE, E., HUGUNIN, J., KERSTEN, M., PALM, J., e GRIS-
WOLD, W. G. An overview of aspectj. Em 15th European Conference on Object-
Oriented Programming, p´ags. 327–353, 2001.
KICZALES, G., LAMPING, J., MENHDHEKAR, A., MAEDA, C., LOPES, C., LO-
INGTIER, J.-M., e IRWIN, J. Aspect-oriented programming. Em AKSIT, P.
e MATSUOKA, S., editores, European Conference on Object-Oriented Programming,
1241:220–242, 1997.
LEMOS, O. A. L. Teste de programas orientados a aspectos: uma abordagem
estrutural para aspectj. Disserta¸c˜ao de Mestrado, Instituto de Ciˆencias Matem´aticas
e de Computa¸c˜ao (ICMC), 2005.
LIEBERHERR, K. J., SILVA-LEPE, I., e XIAO, C. Adaptive object-oriented pro-
gramming using graph-based customization. ACM 37(5), p´ags. 94–101, 1994.
LOBATO, C. A. Um framework orientado a aspectos para mobilidade de agentes
de software. Disserta¸c˜ao de Mestrado, Computer Science Department, PUC-Rio, 2005.
LUCK, M. A manifesto for agent technology: Towards next generation com-
puting. Autonomous Agents and Multi-Agent Systems, 9(3), p´ags. 203–252, 2004.
MALLYA, A. e SINGH, M. P. Incorporating commitment protocols into tropos.
Em 6th International Workshop on Agent-Oriented Software Engineering (AOSE-2005),
p´ags. 69–80, 2005.
MONK, S. e HALL, S. Virtual mock objects using aspectj with junit. Technical
report, XProgramming.com, 2002.
MOURATIDIS, H., KOLP, M., FAULKNER, S., e GIORGINP, P. A secure architec-
tural description language for agent systems. Em 4th International Joint Confer-
ence on Autonomous Agents and MultiAgent Systems (AAMAS-2005), p´ags. 578–585,
2005.
MYLOPOULOS, J. e CASTRO, J. Tropos: A framework for requirements-driven
software development, 2000. URL http://citeseer.ist.psu.edu/393259.html.
Information Systems Engineering: State of the Art and Research Themes.
MYLOPOULOS, J., CHUNG, L., e NIXON, B. Representing and using nonfunc-
tional requirements: A process-oriented approach. Software Engineering, 18(6):
483–497, 1992.
ODELL, J., PARUNAK, H. V. D., e BAUER, B. Extending uml for agents. Em
Agent-Oriented Information Systems (at AAAI) Workshop, p´ag. 15, 2000.
92
OMG, O. M. G. Unified modeling language (uml): Superstructure. Technical
report, OMG, 2005.
PARNAS, D. On the criteria to be used in decomposing systems into modules.
In Communications of the ACM 15(12), p´ags. 1053–1058, 1972.
PERES, J., CHOREN, R., e GARCIA, A. Aspect-oriented modeling in multi-agent
systems development. III Workshop Brasileiro de Desenvolvimento de Software Ori-
entado a Aspectos, p´ags. 80–89, 2006.
PERES, J. A. R. D. V. Integra¸c˜ao e composi¸c˜ao de caracter´ısticas transversais
em sistemas multiagentes. Disserta¸c˜ao de Mestrado, Departamento de Inform´atica,
IME-RJ, 2006.
PETRIE, C. Agent based engineering, the web, and intelligence. IEEE Expert,
Special Issue on Intelligent Systems and their Applications, 11(6), p´ags. 24–29, 1996.
PIVETA, E. K., GARCIA, V. C., ZANCANELLA, L. C., e DO PRADO, A. F. Termos
em portuguˆes para desenvolvimento de software orientado a aspectos. Em I
Workshop Brasileiro de Desenvolvimento Orientado a Aspectos, 2004.
RAO, A. S. e GEORGEFF, M. P. Bdi agents: From theory to practice. Em Pro-
ceedings of the First Intl. Conference on Multiagent Systems, p´ag. 14, 1995.
RASHID, A. E. A. Early aspects: a model for aspect-oriented requirements
engineering, 2002. IEEE Joint International Conference on Requirements Engineering,
Alemanha, 2002.
REZENDE, D. A. Engenharia de Software e Sistemas de Informa¸c˜ao. Brasport,
2005.
ROCHA, A. D. Uma ferramenta baseada em aspectos para apoio ao teste fun-
cional de programas java. Disserta¸c˜ao de Mestrado, USP - Universidade de S˜ao
Paulo, 2005.
SELIC, B. e RUMBAUGH, J. Using UML for modeling complex real-time systems.
Technical report, ObjecTime Limited, 1998.
SHAW, M. e GARLAN, D. Software Architecture: Perspectives on an Emerging
Discipline. Prentice Hall, 1996.
SILVA, C., ARAUJO, J., MOREIRA, A. M. D., CASTRO, J., TEDESCO, P., ALEN-
CAR, F., e RAMOS, R. Modeling multi-agent systems using uml. XX Brazilian
Symposium on Software Engineering (SBES-06), p´ags. 81–96, 2006.
SILVA, C. T. L. L., CASTRO, J., e MYLOPOULOS, J. Detailing architectural de-
sign in requirements driven software development: The tropos case. Second
International Workshop From SofTware Requirements to Architectures (STRAW-03),
1:85–93, 2003.
93
SILVA, V. T., CHOREN, R., e LUCENA, C. A uml based approach for modeling
and implementing multi-agent systems. Em Autonomous Agents and Multi-Agent
Systems (AAAMAS) Conference, p´ag. 11, 2004.
SOARES, S. e BORBA, P. Aspectj, programa¸c˜ao orientada a aspectos em java.
Simp´osio Brasileiro de Linguagens de Programa¸c˜ao (SBLP-02), Rio de Janeiro, Brazil,
p´ag. 17, 2002.
TARR, P. L., OSSHER, H., HARRISON, W. H., e JR., S. M. S. N degrees of sepa-
ration: Multi-dimensional separation of concerns. Em International Conference
on Software Engineering, p´ags. 107–119, 1999.
WEISS, G., ROVATSOS, M., e NICKLES, M. Capturing agent autonomy in roles
and xml. Em Intl. Conference on Autonomous Agents and Multiagent Systems, 2003.
WOOLDRIDGE, M. Agent-based software engineering. IEE Proceedings Software
Engineering, 144(1):26–37, 1997.
WOOLDRIDGE, M. An Introduction to MultiAgent Systems. John Wiley and
Sons, 2002.
WOOLDRIDGE, M., WOOLDRIDGE, M., e KINNY, D. The gaia methodology for
agent- oriented analysis and design. Autonomous Agents and Multiagent Systems
3(3), p´ags. 285–312, 2000.
YU, E. S. K. Agent-oriented modelling: Software versus the world. Em AOSE,
p´ags. 206–225, 2001.
YU, Y., DO PRADO LEITE, J. C. S., e MYLOPOULOS, J. From goals to aspects:
Discovering aspects from requirements goal models. Em Em 12th IEEE Inter-
national Requirements Engineering Conference, ISBN 0-7695-2174-6, 2004.
94
9 AP
ˆ
ENDICE - LISTAGENS DE C
´
ODIGOS DE AGENTES
95
Listagem 9.1: C´odigo de classes utilizadas como base
/∗ C lass e s u t i l i z a d a s como base ∗/
pa ckage t e s t ;
5 im port jad e . cor e . Agent ;
import j ava . u t i l . A r rayL i s t ;
import j a va . u t i l . L i s t ;
10
public c l a s s C2Agent extends Agent{
private L is t <Plan> l i s t a P l a n o s = new ArrayList <Plan > () ;
15 protected void addPlano ( Plan plano ) {
l i s t a P l a n o s . add ( plano ) ;
addBehaviour ( p lano ) ;
}
20 }
pa ckage t e s t ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
25 im port jad e . co r e . be h avi o urs . P a r a l l e l B e h a v i o u r ;
public abstract c l a s s Plan extends P a r a l l e l B e h a v i o u r {
/∗∗
30 ∗
∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 8819245346206430876L ;
public s t a t i c f i n a l i nt WHEN
CHECK = 2 ;
35
public Plan ( S t r i n g name) {
th i s . setBehaviourName ( name ) ;
}
96
40 protected boolean e v a l Co n d i ti o n ( ) {
boolean cond ;
int condicaoDeParada = getWhenToStop ( ) ;
45 switch ( condicaoDeParada ) {
case WHEN ALL:
cond = getSubBehaviours ( ) . isEmpty ( ) ;
break ;
case WHEN ANY:
50 cond = ( getT e rminate d Childr e n ( ) . s i z e ( ) > 0) ;
break ;
case WHEN CHECK:
cond = t h is . checkCondit i o n ( ) ;
break ;
55 defaul t :
cond = ( getT e rminate d Childr e n ( ) . s i z e ( ) >=
condicaoDeParada ) ;
break ;
}
60 return cond ;
}
/∗∗
∗ M´etodo r e s p o n s ´av e l na montagem de r e g r a s de decomposi¸c˜ao de
pl a no s
65 ∗ XOR + AND ou OR + AND ( r e f e r ˆe n c i a s de exemplos do est u do de caso
da
∗ d i s s e r t a ¸c ˜a o da Janilma
∗ @return r e to r n a se a con d i¸c ˜ao f o i s a t i s f e i t a
∗/
private boolean ch e c k Condition ( ) {
70
Behaviour andConditionBehaviour = n ull ;
boolean uniqueAndConditionBehaviour = true ;
int x o r S i z e = 0 ;
75 in t o r Si z e = 0 ;
97
fo r ( in t i = 0 ; i < ge t Termina t edChil d ren ( ) . s i z e ( ) ; i ++) {
Behaviour c u r r e n t = ( Behaviour )
ge t Termina t edChil d ren ( ) . get ( i ) ;
i f ( uniqueAndConditionBehaviour && c u r r e n t .
getBehaviourC o n d i t i o n ( ) == AND CONDITION) {
80 andConditionBehaviour = c u r r e n t ;
uniqueAndConditionBehaviour = f a l s e ;
} e l s e {
i f ( c u r r e n t . getB e h a v i o u r C o n dition ( ) !=
AND CONDITION) {
i f ( c u r r e n t . getBe h a v i o u r C o n d ition ( )
== XOR CONDITION) {
85 x o r S i z e ++;
} e l s e {
i f ( c u r r e n t .
getBehaviourC o n d i t i o n ( )
== OR CONDITION) {
o r S i z e ++;
}
90 }
i f ( x o r S i z e > 0 && o r S i z e > 0)
{
return f a l s e ;
95 }
} e l s e {
return f a l s e ;
}
}
100 }
i f ( x o r S i z e == 1 && andConditionBehav iour != nul l ) {
s e t E x e c u t i o n S t a t e ( Behaviour .STATE DONE) ;
return true ;
105 } el s e {
i f ( o r S i z e > 0 && andConditionBehaviour != nul l ) {
s e t E x e c u t i o n S t a t e ( Behaviour .STATE DONE) ;
return true ;
}
110 }
98
return f a l s e ;
}
115 public int onEnd ( ) {
return 0 ;
}
public void addPlan ( Behaviour plano ) {
120 t h i s . addSubBehaviour ( plano ) ;
}
public void addAction ( Behaviour a c t i o n ) {
th i s . addSubBehaviour ( a c t i o n ) ;
125 }
public abstract void montaEstrutura ( ) ;
}
130
pa ckage t e s t ;
import jad e . c o r e . b e h av i o ur s . OneShotBehaviour ;
135 public abstract c l a s s Action extends OneShotBehaviour {
/∗∗
∗
∗/
140 private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 4923006266414560701L ;
public Action ( S t r i n g nam e ) {
th i s . setBehaviourName ( name ) ;
}
145
@Override
public abstract void a c t i o n ( ) ;
}
150
99
pa ckage t e s t ;
public c l a s s Re l a t i o n s h i p C o n st an t s {
155 public s t a t i c f i n a l S t r i n g RELATIONSHIP MERGE = " merge" ;
public s t a t i c f i n a l S t r i n g RELATIONSHIP ADD AFTER = "addAfter" ;
public s t a t i c f i n a l S t r i n g RELATIONSHIP ADD BEFORE = "addBefore " ;
160
public s t a t i c f i n a l S t r i n g RELATIONSHIP REDEFINE = "redefine" ;
public s t a t i c f i n a l S t r i n g RELATIONSHIP REFINE BEFORE = "
refineBefore" ;
165 public s t a t i c f i n a l S t r i n g RELATIONSHIP REFINE AFTER = "refineAfter
" ;
public s t a t i c f i n a l S t r i n g RELATIONSHIP REFINE AROUND = "
refineAround" ;
public s t a t i c f i n a l i nt RELATIONSHIP REFINE BEFORE CASE = 1 ;
170
public s t a t i c f i n a l i nt RELATIONSHIP REFINE AFTER CASE = 2 ;
public s t a t i c f i n a l i nt RELATIONSHIP REFINE AROUND CASE = 3 ;
175 public s t a t i c f i n a l in t RELATIONSHIP REDEFINE CASE = 4 ;
}
Listagem 9.2: C´odigo de classes do cap´ıtulo 4 (AspectualJADE)
pa ckage t e s t . example ;
import t e s t . C2Agent ;
import t e s t . Plan ;
5
public c l a s s AnalisadorPedidoMTAgent extends C2Agent{
protected void setup ( ) {
100
Plan apreciacaoDePedidoDeMTPlan = new
ApreciacaoDePedidoDeMTPlan ( " ApreciacaoDePedidoDeMTPlan " )
;
10
addPlano ( apreciacaoDePedidoDeMTPlan ) ;
}
15 }
pa ckage t e s t . example ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
20 im port t e s t . Plan ;
public c l a s s ApreciacaoDePedidoDeMTPlan extends Plan {
public ApreciacaoDePedidoDeMTPlan ( S t r i n g name) {
25 super (name) ;
montaEstrutura ( ) ;
}
30 @Override
public void montaEstrutura ( ) {
CruzarDadosDaMTComDadosDaManobraAction acao1 = new
CruzarDadosDaMTComDadosDaManobraAction ( "Acao1 " ) ;
acao1 . set B e ha v i our C o ndi t i on ( Behaviour .AND CONDITION) ;
35 R eacaoAoPedidoDeMTPlan p lano1 = new ReacaoAoPedidoDeMTPlan (
"Plano1" ) ;
plano1 . s e tBe h a vi o u rCo n d iti o n ( Behaviour .AND CONDITION) ;
addAction ( acao1 ) ;
addPlan ( plano1 ) ;
40 }
}
pa ckage t e s t . example ;
101
45
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Plan ;
public c l a s s ReacaoAoPedidoDeMTPlan extends Plan {
50
public ReacaoAoPedidoDeMTPlan ( S t r i n g name) {
super ( name) ;
montaEstrutura ( ) ;
55 }
@Override
public void montaEstrutura ( ) {
S u g e r i r N a o A t i r a r e i A c t i o n acao1 = new
S u g e r i r N a o A t i r a r e i A c t i o n ( " Acao1" ) ;
60 acao1 . se t B eha v i our C ond i t ion ( Behaviour .XOR CONDITION) ;
SugerirRepassarAMTParaOGACAction acao2 = new
SugerirRepassarAMTParaOGACAction ( "Acao2 " ) ;
acao2 . set B e ha v i our C o ndi t i on ( Behaviour .XOR CONDITION) ;
ReceberPosicionamen toDoUsuarioAction acao3 = new
ReceberPosicionamen toDoUsuarioAction ( "Acao3 " ) ;
acao3 . set B e ha v i our C o ndi t i on ( Behaviour .AND CONDITION) ;
65
addAction ( acao1 ) ;
addAction ( acao2 ) ;
addAction ( acao3 ) ;
70 t h i s . setWhenToStop ( Plan .WHEN CHECK) ;
}
}
75 package t e s t . example ;
import t e s t . Action ;
public c l a s s CruzarDadosDaMTComDadosDaManobraAction extends Action {
80
private S t r i n g d e s c r i p t i o n ;
102
public CruzarDadosDaMTComDadosDaManobraAction ( S t r i n g name ) {
super ( name) ;
85 }
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " CruzarDadosDaMTComDadosDaManobraAction "
) ;
90 }
}
pa ckage t e s t . example ;
95
import t e s t . Action ;
public c l a s s ReceberPosicionamentoD oUsuarioAction extends Action {
100 private S t r i n g d e s c r i p t i o n ;
public ReceberPosicionamentoDoUsuari oActi on ( S t r i n g name ) {
super ( name) ;
}
105
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " ReceberPosicionamentoDoUsuarioAction" ) ;
}
110
}
pa ckage t e s t . example ;
115 im port t e s t . Action ;
public c l a s s S u g e r i r N a o A t i r a r e i A c t i o n extends Action {
private S t r i n g d e s c r i p t i o n ;
120
103
public S u g e r i r N a o A t i r a re i A c t i o n ( S t r i n g name) {
super ( name) ;
}
125 @Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " SugerirNaoAtirareiAction" ) ;
}
130 }
pa ckage t e s t . example ;
import t e s t . Action ;
135
public c l a s s SugerirRepassarAMTParaOGACAction extends Action {
private S t r i n g d e s c r i p t i o n ;
140 public SugerirRepassarAMTParaOGACAction ( S t r i n g name ) {
super ( name) ;
}
@Override
145 public void a c t i o n ( ) {
System . out . p r i n t l n ( " SugerirRepassarAMTParaOGACAction " ) ;
}
}
Listagem 9.3: C´odigo de classes do cap´ıtulo 5 (Estudo de Caso)
/∗ C l a s s e s r e f e r e n t e s ao a g ent e Observador Avan¸cado (OA) ∗/
pa ckage t e s t . merge ;
5 im port t e s t . C2Agent ;
import t e s t . Plan ;
public c l a s s ObservadorAvancadoAgent extends C2Agent{
104
10
protected void setup ( ) {
Plan buscadorDeAlvos = new BuscaDeAlvosPlan ( "
BuscaDeAlvosPlan " ) ;
Plan r e q u i s i t a n t e D e N e u t r a l i z a c a o = new
Pe d idoDe N eutral i zacao P lan ( " requisitanteDeNeutralizacao" )
;
15 addPlano ( buscadorDeAlvos ) ;
addPlano ( r e q u i s i t a n t e D e N e u t r a l i z a c a o ) ;
}
}
20
pa ckage t e s t . merge ;
import t e s t . Plan ;
25 public c l a s s BuscaDeAlvosPlan extends Plan {
public BuscaDeAlvosPlan ( S t r i n g name) {
super ( name) ;
30 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
35 Plan plano = new I d en t i f i c a c ao D e A l v o P la n ( "
IdentificacaoDeAlvoPlan" ) ;
Cr uzar Dado sComI nfor macoesDeI ntel igen ciaAc tion acao1 = new
Cr uzar Dado sComI nfor macoesDeI ntel igen ciaAc tion ( "
CruzarDadosComInformacoesDeInteligenciaAction " ) ;
SugerirReacaoActio n acao2 = new SugerirReacaoA c t i o n ( "
SugerirReacaoAction " ) ;
addPlan ( plano ) ;
40 addAction ( acao1 ) ;
addAction ( acao2 ) ;
}
105
}
45
pa ckage t e s t . merge ;
import t e s t . Plan ;
50 public c l a s s I d en t i f i c a c ao D e A l v o P la n extends Plan {
/∗∗
∗
∗/
55 private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 892930574511673401L ;
public I d e n t if i c a c a o D eA lv o P l a n ( S t r i n g name) {
super ( name) ;
60 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
65 ReceberCoordenadasDoAlvoAction acao1 = new
ReceberCoordenadasDoAlvoAction ( "
ReceberCoordenadasDoAlvoAction " ) ;
ReceberNaturezaDoAlvoAction acao2 = new
ReceberNaturezaDoAlvoAction ( " ReceberNaturezaDoAlvoAction
" ) ;
ReceberDimensoesDoAlvoAction acao3 = new
ReceberDimensoesDoAlvoAction ( "
ReceberDimensoesDoAlvoAction" ) ;
addAction ( acao1 ) ;
70 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
}
75
pa ckage t e s t . merge ;
106
import t e s t . Plan ;
80 public c l a s s Pedido D eNeutr alizac a oPlan extends Plan{
public Ped i doDeN e utrali z acaoP l an ( S t r i n g name ) {
super ( name) ;
85 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
90 CruzarNaturezaEDimensoesDoAlvoComNomogramasAction acao1 =
new CruzarNaturezaEDimensoesDoAlvoComNomogramasAction ( "
CruzarNaturezaEDimensoesDoAlvoComNomogramasAction " ) ;
SugerirParametrosParaMTAction acao2 = new
SugerirParametrosParaMTAction ( "
SugerirParametrosParaMTAction " ) ;
ReceberParametrosFinaisDoPedidoDeMTAction acao3 = new
ReceberParametrosFinaisDoPedidoDeMTAction ( "
ReceberParametrosFinaisDoPedidoDeMTAction " ) ;
addAction ( acao1 ) ;
95 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
}
100
pa ckage t e s t . merge ;
import t e s t . Action ;
105
public c l a s s Cru zarDadosC omIn formacoes DeIn telig enci aAct ion extends Action {
/∗∗
∗
110 ∗/
107
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 2976582256195142942L ;
public Cr uzar Dados ComI nfor macoe sDeI ntel igenc iaAc tion ( S t r i n g name ) {
super ( name) ;
115 }
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Cruzados os dados com informa¸c~oes de
intelig^encia ." ) ;
120 }
}
pa ckage t e s t . merge ;
125
import t e s t . Action ;
public c l a s s CruzarNaturezaEDimensoesDoAlvoComNomogramasAction extends
Action {
130 /∗∗
∗
∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −6424206598098648412L ;
135 public CruzarNaturezaEDimensoesDoAlvoComNomogramasAction ( S t r i n g
name ) {
super ( name) ;
}
@Override
140 public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Cruzadas a natureza e as dimens~oes do alvo com
os nomogramas." ) ;
}
}
108
145
pa ckage t e s t . merge ;
import t e s t . Action ;
150 public c l a s s ReceberCoordenadasDoAlvoAction extends Action {
/∗∗
∗
∗/
155 private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −3364765770872951533L ;
public ReceberCoordenadasDoAlvoAction ( S t r i n g name ) {
super ( name) ;
}
160
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Recebidas coordenadas do alvo." ) ;
}
165
}
pa ckage t e s t . merge ;
170 im port t e s t . Action ;
public c l a s s ReceberDimensoesDoAlvoAction extends Action {
/∗∗
175 ∗
∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = 6148007101540433639L ;
public ReceberDimensoesDoAlvoAction ( S t r i n g name ) {
180 super (name) ;
}
@Override
109
public void a c t i o n ( ) {
185 System . out . p r i n t l n ( "Plano : " + t h is . getParentBehaviourName
( ) + ". Recebidas dimens~oes do alvo." ) ;
}
}
190 package t e s t . merge ;
import t e s t . Action ;
public c l a s s ReceberNaturezaDoAlvoAction extends Action {
195
/∗∗
∗
∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −2672535794775086395L ;
200
public ReceberNaturezaDoAlvoAction ( S t r i n g name) {
super ( name) ;
}
205 @Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Recebida natureza do alvo ." ) ;
}
210 }
pa ckage t e s t . merge ;
import t e s t . Action ;
215
public c l a s s ReceberParametrosFinaisDoPedidoDeMTAction extends Action {
/∗∗
∗
220 ∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −2976476341529991851L ;
110
public ReceberParametrosFinaisDoPedidoDeMTAction ( S t r i n g name) {
super ( name) ;
225 }
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Recebidos par^ametros finais do pedido de MT." ) ;
230 }
}
pa ckage t e s t . merge ;
235
import t e s t . Action ;
public c l a s s SugerirParametrosParaMTAction extends Action {
240 /∗∗
∗
∗/
private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −6172990565618231661L ;
245 public SugerirParametrosParaMTAction ( S t r i n g name) {
super ( name) ;
}
@Override
250 public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Sugeridos par^ametros para MT." ) ;
}
}
255
pa ckage t e s t . merge ;
import t e s t . Action ;
111
260 public c l a s s S u g e r ir ReacaoAction extends Action {
/∗∗
∗
∗/
265 private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = −305338647253218690L ;
public Sugerir R e a c a o A c t i o n ( S t r i n g nam e ) {
super ( name) ;
}
270
@Override
public void a c t i o n ( ) {
System . out . p r i n t l n ( " Plano : " + t h is . getParentBehaviourName
( ) + ". Rea¸c~ao sugerida ." ) ;
}
275
}
/∗ C l a s s e s r e f e r e n t e s ao a g ent e O f i c i a l de Liga¸c˜ao ( OLig ) ∗/
280 package t e s t . add ;
import t e s t . C2Agent ;
import t e s t . Plan ;
285 public c l a s s OLigAgent extends C2Agent{
protected void setup ( ) {
Plan apreciacaoDePedidoDeMTPlan = new
ApreciacaoDePedidoDeMTPlan ( " ApreciacaoDePedidoDeMTPlan " )
;
Plan tratamentoDeMensagemPlan = new
TratamentoDeMensagemPlan ( " TratamentoDeMensagemPlan" ) ;
290 Plan suspensaoDeFogoPlan = new SuspensaoDeFogoPlan ( "
SuspensaoDeFogoPlan " ) ;
Plan autorizacaoDeFog oPlan = new AutorizacaoDeFogoPlan ( "
AutorizacaoDeFogoPlan " ) ;
addPlano ( apreciacaoDePedidoDeMTPlan ) ;
112
addPlano ( tratamentoDeMensagemPlan ) ;
295 addPlano ( suspensaoDeFogoPlan ) ;
addPlano ( autoriz acaoDeFogoPlan ) ;
}
}
300
pa ckage t e s t . add ;
import t e s t . Plan ;
305 public c l a s s ApreciacaoDePedidoDeMTPlan extends Plan {
public ApreciacaoDePedidoDeMTPlan ( S t r i n g name) {
super ( name) ;
310 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
315 FakeAction acao1 = new FakeAction ( " Acao1" ) ;
FakeAction acao2 = new FakeAction ( " Acao2" ) ;
FakeAction acao3 = new FakeAction ( " Acao3" ) ;
addAction ( acao1 ) ;
320 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
}
325
pa ckage t e s t . add ;
import t e s t . Plan ;
330 public c l a s s AutorizacaoDeFogoPlan extends Plan {
public AutorizacaoDeFogoPlan ( S t r i n g name ) {
super ( name) ;
113
335 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
340 FakeAction acao1 = new FakeAction ( " Acao1" ) ;
FakeAction acao2 = new FakeAction ( " Acao2" ) ;
FakeAction acao3 = new FakeAction ( " Acao3" ) ;
addAction ( acao1 ) ;
345 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
}
350
pa ckage t e s t . add ;
import t e s t . Plan ;
355 public c l a s s SuspensaoDeFogoPlan extends Plan {
public SuspensaoDeFogoPlan ( S t r i n g name) {
super ( name) ;
360 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
365 FakeAction acao1 = new FakeAction ( " Acao1" ) ;
FakeAction acao2 = new FakeAction ( " Acao2" ) ;
FakeAction acao3 = new FakeAction ( " Acao3" ) ;
addAction ( acao1 ) ;
370 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
114
}
375
pa ckage t e s t . add ;
import t e s t . Plan ;
380 public c l a s s TratamentoDeMensagemPlan extends Plan {
public TratamentoDeMensagemPlan ( S t r i n g name ) {
super ( name) ;
385 montaEstrutura ( ) ;
}
@Override
public void montaEstrutura ( ) {
390 FakeAction acao1 = new FakeAction ( " Acao1" ) ;
FakeAction acao2 = new FakeAction ( " Acao2" ) ;
FakeAction acao3 = new FakeAction ( " Acao3" ) ;
addAction ( acao1 ) ;
395 addAction ( acao2 ) ;
addAction ( acao3 ) ;
}
}
400
pa ckage t e s t . add ;
import t e s t . Action ;
405 public c l a s s FakeAction extends Action {
private S t r i n g d e s c r i p t i o n ;
public FakeAction ( S t r i n g name ) {
410 super (name) ;
}
@Override
115
public void a c t i o n ( ) {
415 System . out . p r i n t l n ( " Executando Action " + getBehaviourName
( ) + ", Plano respons´avel: " + t h i s .
getParentBehaviourName ( ) ) ;
}
}
116
10 AP
ˆ
ENDICE - LISTAGENS DE C
´
ODIGOS DE ASPECTOS
117
Listagem 10.1: C´odigo do aspecto Mobilidade
import t e s t . Plan ;
import t e s t . R el at io n s h i p C o n s t a n t s ;
import t e s t . merge . Cruza rDadosCom Info rmaco esDe Inte ligen ciaA ctio n ;
import t e s t . merge . MergeAbstractAspect ;
5
public a s p e c t M o b ilityAsp e c t extends MergeAbstractAspect {
private s t a t i c boolean t e st R e f in e B e f o r e ( Behaviour b e h a viour ) {
i f ( b e h aviour instanceof Action ) {
10 i f ( b e h aviour instanceof
Cr uzar Dado sComI nfor macoesDeI ntel igen ciaAc tion )
return true ;
}
return f a l s e ;
15 }
a f t e r ( Plan planoPai , Behaviour b e ha v i o ur F i l h o ) : addBehaviour (
planoPai , b e ha v io u r F il h o ) {
i f ( t e s t R e fi n e B ef o r e ( b e h av i o u rF i l h o ) ) {
s e t R e l a t i o n s h i p A c t i o n ( ( Action ) behavi o u r F ilho ,
Re la ti o n s h i p C o n s t a n t s . RELATIONSHIP REFINE BEFORE
) ;
20 }
}
p o i n t c u t r e f i n e B e f o r e ( Action be h a viour ) :
r e f i n e A b s tr a c t B e fo r e ( be h a v i our ) && i f ( t es t R e fi n e B ef o r e (
be h a v iour ) ) ;
25
protected abstract void moverAgente ( Action b e h aviour ) ;
protected void a c t i o n ( Action b ehaviour ) {
i f ( b e h aviour . r e l a t i o n s h i p != n ul l )
30 {
i f ( b e h aviour . r e l a t i o n s h i p . e q u a l s (
Re la ti o n s h i p C o n s t a n t s . RELATIONSHIP REFINE BEFORE
) ) {
moverAgente ( b e h a viour ) ;
118
}
35 }
}
}
40 package t e s t . example ;
import t e s t . Action ;
public a s p e c t M o b ilityCon c r e t e Aspect extends M o b i l i t yAspect {
45
b e f o r e ( Action behavi o u r ) : r e f i n e B e f o r e ( b ehaviour ) {
a c t i o n ( beha v i o u r ) ;
}
50 protected void moverAgente ( Action beh a v i our ) {
System . out . p r i n t l n ( " Agente movido para outro container " ) ;
}
}
Listagem 10.2: C´odigo dos aspectos Autonomia e Interatividade
/∗ Aspecto Autonomia ∗/
pa ckage t e s t . merge ;
5 im port jad e . co r e . Agent ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Action ;
import t e s t . Plan ;
10 public abstract a s p e c t MergeAbstractAspect {
public S t r i n g Action . r e l a t i o n s h i p = nu ll ;
protected void s e t R e l a t i o n s h i p A c t i o n ( Action act i o n , S t r i n g
r e l a t i o n s h i p ) {
15 a c t i o n . r e l a t i o n s h i p = r e l a t i o n s h i p ;
}
119
p o i n t c u t addBehaviour ( Plan planoPai , Behaviour b e h a vi o u r Fi l h o ) :
t a r g e t ( plano Pai ) &&
20 arg s ( be h a v io u r F il h o ) &&
(
c a l l ( void Plan . addPlan ( Behaviour ) ) | |
c a l l ( void Plan . addAction ( Behaviour ) )
) ;
25
p o i n t c u t a c t i o n C a l l ( Action beh a v i our ) :
t a r g e t ( b e h aviour ) &&
c a l l ( void a c t i o n ( ) ) ;
30 p o i n t c u t r e f i n e A b st r a c t B ef o r e ( Action b e h aviour ) : a c t i o n C a l l (
be h a v iour ) ;
p o i n t c u t r e f i ne A b s t r a c t A f t er ( Action behaviou r ) : a c t io n C a l l (
be h a v iour ) ;
p o i n t c u t re f i ne A b str a c tAr o u nd ( Action beha v i o ur ) : a c t i o nC a l l (
be h a v iour ) ;
35
p o i n t c u t r e d e f i n e A b s t r a c t ( Action be h a v iour ) : a c t i o n C a ll ( b e h aviour )
;
}
40 package t e s t . merge ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Action ;
import t e s t . Plan ;
45 im port t e s t . R e l at io n s h i p C o n s t a n t s ;
public abstract a s pe ct Merg e5 21Defi nedRule sAsp ect extends
MergeAbstractAspect {
// Testa s e a¸c˜ao deve p o s s u i r o rela c i o namen t o ” r e f i n e b e fo r e ” .
50 private s t a t i c boolean t e s t R ef i n e B e f o re ( Behaviour behaviou r ) {
120
//Se a¸c˜ao ´e uma i n s t ˆa n c i a da c l a s s e ” Action ” , e s p e c´ı f i c a
para o AspectualJADE .
i f ( b e h aviour instanceof Action ) {
/∗ Se a¸c˜ao ´e do t i p o de umas das e s p e c i f i c a d a s a
s e g u i r , ent˜ao deve p o s s u i r
∗ o rel a c i o namen t o r e f i n e b e f o r e .
55 ∗/
i f ( b e h aviour instanceof Su g e ri rReacaoAction | |
be h a v iour instanceof
SugerirParametrosParaMTAction ) {
return true ;
}
60 }
return f a l s e ;
}
65 // Testa s e a¸c˜ao deve p o s s u i r o rela c i o n ament o ” r e d e f i n e ”.
private s t a t i c boolean t e s t R e d ef i n e ( Behaviour behavi o u r ) {
//Se a¸c˜ao ´e uma i n s t ˆa n c i a da c l a s s e ” Action ” , e s p e c´ı f i c a
para o AspectualJADE .
i f ( b e h aviour instanceof Action ) {
/∗
70 ∗ Se a¸c˜ao ´e do t i p o de umas das e s p e c i f i c a d a s a
s e g u i r , ent˜ao deve p o s s u i r
∗ o rel a c i o namen t o r e f i n e b e f o r e .
∗ ∗/
i f ( b e h aviour instanceof
Cr uzar Dado sComI nfor macoesDeI ntel igen ciaAc tion | |
be h a v iour instanceof
CruzarNaturezaEDimensoesDoAlvoComNomogramasAction
) {
75 return true ;
}
}
return f a l s e ;
80 }
// Po i n t c u t que ” guarda ” os r e l a ci o na m e nt o s das a¸c ˜oe s .
121
a f t e r ( Plan planoPai , Behaviour b e ha v i o ur F i l h o ) : addBehaviour (
planoPai , b e ha v io u r F il h o ) {
// V e r i f i c a ¸c ˜a o p e l a i n s t ˆa n c i a s e deve a d i c i o n a r o
r e l a t i o n s h i p na Action a t r a v´e s do a s p e c t o .
85 i f ( t e s t R e fi n e B ef o r e ( b e h av i o u rF i l h o ) ) {
s e t R e l a t i o n s h i p A c t i o n ( ( Action ) behavi o u r F ilho ,
Re la ti o n s h i p C o n s t a n t s . RELATIONSHIP REFINE BEFORE
) ;
} e l s e {
i f ( t e s t R e d e f i n e ( b e ha v i o ur F i l ho ) ) {
s e t R e l a t i o n s h i p A c t i o n ( ( Action )
behav i o u r Filho , R e l a t i o n s h i p C o ns ta n t s .
RELATIONSHIP REDEFINE) ;
90 }
}
}
/∗
95 ∗ Po i n tc u t que v e r i f i c a s e a¸c˜ao ´e uma chamada−padr˜ao e s e p o s s u i o
∗ rela c i o n ament o r e f i n e b e f o r e .
´
E r e f l e t i d o para a camada de a¸c˜oes
∗ d e s t e as pe c t o .
∗ ∗/
p o i n t c u t r e f i n e B e f o r e ( Action be h a viour ) :
100 r e f i n e A bs t r a c tB e f o r e ( behavio u r ) &&
i f ( t e s t R e fi n e B ef o r e ( behaviou r ) ) ;
/∗
∗ P o in t c u t que v e r i f i c a s e a¸c˜ao ´e uma chamada−padr˜ao e se po s s u i o
105 ∗ rela c i o n ament o r e f i n e b e f o r e .
´
E r e f l e t i d o para a camada de a¸c˜oes
∗ d e s t e as pe c t o .
∗ ∗/
p o i n t c u t r e d e f i n e ( Action b ehaviour ) :
r e d e f i n e A b s t r a c t ( b ehaviour ) &&
110 i f ( t e s t R e d e f i n e ( b e h a viour ) ) ;
/∗
∗ M´etodos a b s t r a t o s : a s s i n a t u r a s de a ¸c˜oes do a sp e c t o s ,
implementados
∗ p e l a camada de a¸c˜oes do a sp e c t o .
115 ∗ ∗/
122
protected abstract void r ecebe r P a r ametr o s ( Action b ehaviour ) ;
protected abstract void buscarResultadosMaisAdequados ( Action
be h a v iour ) ;
protected abstract void r e t o r n a r R e s u l t a d o s ( Action be h a v iour ) ;
120 /∗
∗ Chamada r e a l i z a d a p e l a camada de a¸c˜o e s do aspecto , onde ´e
v e r i f i c a d o se a¸c˜ao p o s s u i
∗ algum rel a c i o namen t o p reviame n te determinado , ent˜ao e x ec u t a
a¸c˜oes do a s p e c t o na ordem
∗ e s p e c i f i c a d a .
∗ ∗/
125 protected void a c t i o n ( Action b ehaviour ) {
//Se a¸c˜ao p o s s u i relac i o n ament o h o r i z o n t a l .
i f ( b e h aviour . r e l a t i o n s h i p != n ul l )
{
130 // Se r e l a ciona m e n t o da a¸c˜ao ´e do t i p o ” r e f i n e
b e f o r e ” , e x e c u t e as a¸c˜oes do a s p e c t o .
i f ( behaviou r . r e l a t i o n s h i p . e q u a l s (
Re la ti o n s h i p C o n s t a n t s . RELATIONSHIP REFINE BEFORE
) ) {
r e t o r n a r R e s u l t a d o s ( behav i o u r ) ;
} e l s e {
//Se r elaci o n a mento da a¸c˜ao ´e do t i p o ”
r e d e f i n e ” , e x e c u t e as a¸c˜oes do a s p e ct o .
135 i f ( behaviou r . r e l a t i o n s h i p . e q u a l s (
Re la ti o n s h i p C o n s t a n t s .
RELATIONSHIP REDEFINE) ) {
receb e r P a ramet r o s ( behav i o u r ) ;
buscarResultadosMaisAdequados (
be h a v iour ) ;
}
}
140 }
}
}
145 package t e s t . merge ;
123
import t e s t . Action ;
public a s p e c t R edefi n e 5 2 1 C oncre t e A spec t extends
Merge 5 21De fin edRu lesAspe ct {
150
void around ( Action b ehaviour ) : r e d e f i n e ( b e haviour ) {
a c t i o n ( beha v i o u r ) ;
}
155 protected void r e c e b erPar a m e t ros ( Action be h a v iour ) {
System . out . p r i n t l n ( " Interceptado por aspecto (REDEFINE): "
+
"Recebidos par^ametros para a a¸c~ao " +
be h a v iour . getBehaviourName ( ) ) ;
}
160 protected void buscarResultadosMaisAdequados ( Action be haviour ) {
System . out . p r i n t l n ( " Interceptado por aspecto (REDEFINE): "
+
"Resultados mais adequados buscados para a
a¸c~ao " + b e haviour . getBehaviourName ( ) ) ;
}
165 protected void r e t o r n a r R e s u l t a d o s ( Action b ehaviour ) {/∗DO NOTHING∗/
}
}
pa ckage t e s t . merge ;
170 im port t e s t . Action ;
public a s p e c t Ref i ne B ef o r e 5 2 1 Co n cr e te A s pe c t extends
Merge 5 21De fin edRu lesAspe ct {
b e f o r e ( Action behavi o u r ) : r e f i n e B e f o r e ( b ehaviour ) {
175 a c t i o n ( beha v i o u r ) ;
}
protected void r e t o r n a r R e s u l t a d o s ( Action b ehaviour ) {
124
System . out . p r i n t l n ( " Interceptado por aspecto (REFINE BEFORE
): " +
180 "Resultados retornados para a a¸c~ao " +
be h a v iour . getBehaviourName ( ) ) ;
}
protected void r e c e b erPar a m e t ros ( Action be h a v iour ) {/∗DO NOTHING∗/
}
185 protected void buscarResultadosMaisAdequados ( Action be haviour ) {/∗
DO NOTHING∗/}
}
/∗ Aspecto I n t e r a t i v i d a d e ∗/
190
pa ckage t e s t . add ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Action ;
195 im port t e s t . Plan ;
public abstract a s pe ct AddAbstractAspect {
200 public S t r i n g Action . r e la t i o n s h i p A d d = n ul l ;
public S t r i n g Plan . r e l a t i o n s h i p = n ul l ;
public boolean Plan . a l r e a d y E xecuted = f a l s e ;
205
protected void s e tRe l a tio n s hi p A ddA c t ion ( Action a cti o n , S t r i n g
r e l a t i o n s h i p ) {
a c t i o n . r e l a t i o n s h i p A d d = r e l a t i o n s h i p ;
}
210 protected void s e t R e l a t i o n s h i p P l a n ( Plan plan , S t r i n g r e l a t i o n s h i p )
{
plan . r e l a t i o n s h i p = r e l a t i o n s h i p ;
}
125
protected void setAlr e a d y E xecuted ( Plan plan , boolean f l a g ) {
215 plan . a l r eadyExecuted = f l a g ;
}
p o i n t c u t addBehaviour ( Plan planoPai , Behaviour b e h a vi o u r Fi l h o ) :
t a r g e t ( plano Pai ) &&
220 arg s ( be h a v io u r F il h o ) &&
(
c a l l ( void Plan . addPlan ( Behaviour ) ) | |
c a l l ( void Plan . addAction ( Behaviour ) )
) ;
225
p o i n t c u t a c t i o n C a l l ( Action beh a v i our ) :
t a r g e t ( b e h aviour ) &&
c a l l ( void a c t i o n ( ) ) ;
230 p o i n t c u t v e r i f y S t a t e P l a n ( Plan plan , S t r i n g s t a t u s ) :
t a r g e t ( pla n ) &&
ar g s ( s t a t u s ) &&
c a l l ( void s e t E x e c u t i o n S t a t e ( S t r i n g ) ) ;
235 p o i n t c u t addAb s t r a c t B efore ( Action be h a v iour ) : a c t i o n C a ll ( b e h a viour
) ;
p o i n t c u t addAbstractAfter ( Plan plan , S t r i n g s t a t u s ) :
v e r i f y S t a t e P l a n ( plan , s t a t u s ) ;
}
240
pa ckage t e s t . add ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Action ;
245 im port t e s t . Plan ;
import t e s t . R el at io n s h i p C o n s t a n t s ;
public abstract a s pe ct Ad d 5 2 0D e fi n ed R u le s In t e ra t iv i da d e As p ec t extends
AddAbstractAspect {
126
250 // Testa s e a¸c˜ao deve p o s s u i r o rela c i o n ament o ”add b e f o r e ” .
private s t a t i c boolean testAddBe f o r e ( Behaviour behavio u r ) {
//Se a¸c˜ao ´e uma i n s t ˆa n c i a da c l a s s e ” Action ” , e s p e c´ı f i c a
para o AspectualJADE .
i f ( b e h aviour instanceof Action ) {
/∗ Se a¸c˜ao ´e do t i p o de umas das e s p e c i f i c a d a s a
s e g u i r , ent˜ao o plan o
255 ∗ a que correspo n d e deve p o s s u i r o relaci o n a mento
add b e f o r e .
∗/
i f ( b e h aviour . g e t P a rent ( ) instanceof
ApreciacaoDePedidoDeMTPlan | |
be h a v iour . g e t P a r e n t ( ) inst anceof
TratamentoDeMensagemPlan ) {
return true ;
260 }
}
return f a l s e ;
}
265
// Testa s e plano deve p o s s u i r o rela c i o n ament o ”add a f t e r ”.
private s t a t i c boolean tes t Add A ft e r To S et R e la t ion s hi p ( Plan plan ) {
//Se p lano ´e uma i n s t ˆa n c i a da c l a s s e ” Plan ” , e s p e c´ı f i c a
para o AspectualJADE .
i f ( plan inst anceof Plan ) {
270 /∗
∗ Se pla n o ´e do t i p o de umas das e s p e c i f i c a d a s a
s e g u i r , ent˜ao deve s e r
∗ ad i cio n ado ao mesmo o r e l aciona m e n to add a f t e r .
∗ ∗/
i f ( plan inst anceof ApreciacaoDePedidoDeMTPlan | |
275 plan instanceof SuspensaoDeFogoPlan
| |
plan instanceof
AutorizacaoDeFogoPlan ) {
return true ;
}
}
280
127
return f a l s e ;
}
/∗
285 ∗ V e r i f i c a ¸c ˜a o se s t a t u s do plano i n d i c a que o mesmo a l c a n ¸c o u sua
meta .
∗/
private s t a t i c boolean t e s t A d d A f ter ( Plan plan , St r i n g s t a t u s ) {
//Se p lano ´e uma i n s t ˆa n c i a da c l a s s e ” Plan ” , e s p e c´ı f i c a
para o AspectualJADE .
i f ( plan inst anceof Plan ) {
290 /∗
∗ Se pla n o ´e do t i p o de umas das e s p e c i f i c a d a s a
s e g u i r , ent˜ao deve s e r
∗ ad i cio n ado ao mesmo o r e l aciona m e n to add a f t e r .
∗ ∗/
i f ( plan inst anceof ApreciacaoDePedidoDeMTPlan | |
295 plan instanceof SuspensaoDeFogoPlan
| |
plan instanceof
AutorizacaoDeFogoPlan ) {
// Aqui ´e r e a l i z a d a a v e r i f i c a ¸c ˜a o .
i f ( s ta t u s . e q u a l s ( Behaviour .STATE DONE) ) {
300 return true ;
}
}
}
305 return f a l s e ;
}
/∗
∗ Testa s e plano j ´a exe cutou , v e r i f i c a n d o sua f l a g .
310 ∗/
private s t a t i c boolean t estAl r e a dyExe c u t e d ( Plan plan ) {
i f ( plan . a l r e a dyExecuted ) {
return true ;
}
315
128
return f a l s e ;
}
// Po i n t c u t que ” guarda ” os r e l a ci o na m e nt o s dos pla n os .
320 a f t e r ( Plan planoPai , Behaviour b e h av i o u r F i lh o ) : addBehaviour (
planoPai , b e ha v io u r F il h o ) {
// V e r i f i c a ¸c ˜a o p e l a i n s t ˆa n c i a s e deve a d i c i o n a r o
r e l a t i o n s h i p no Plan a t r a v´e s do a s p e c t o
i f ( t e s tAddBefor e ( b e h a vi o u r Fi l ho ) ) {
set R e la t i ons h i pAd d A ct i o n ( ( Action ) beha v i o u rFilh o ,
Re la ti o n s h i p C o n s t a n t s .RELATIONSHIP ADD BEFORE) ;
}
325 // V e r i f i c a ¸c ˜a o p e l a i n s t ˆa n c i a se deve a d i c i o n a r o
r e l a t i o n s h i p no Plan a t r a v´e s do a s p e c t o
i f ( te s tA d d Af t e rT o Se t R el a ti o n sh i p ( plan oPai ) ) {
s e t R e l a t i o n s h i p P l a n ( ( Plan ) planoPai ,
Re la ti o n s h i p C o n s t a n t s .RELATIONSHIP ADD AFTER) ;
}
330 }
/∗
∗ P o in t c u t que v e r i f i c a s e a¸c˜ao ´e uma chamada−padr˜ao e se i n d i c a
que seu
∗ pa i p o s s u i o re l a c ionam e n t o add b e f o r e .
´
E r e f l e t i d o para a camada
de a¸c ˜o e s
335 ∗ d e s t e a s p e c t o .
∗ ∗/
p o i n t c u t addBefore ( Action b ehaviour ) :
ad d A b s t r a ctBefore ( behaviou r ) &&
i f ( testAddB e f o re ( b e h aviour ) ) &&
340 i f ( ! testA l r e adyEx e c u ted ( ( Plan )
be h a v iour . g e t P a r e n t ( ) ) ) ;
/∗
∗ P o in t c u t que v e r i f i c a s e plano ´e uma chamada−padr˜ao e s e p o s s u i
o
∗ rela c i o n ament o add a f t e r .
´
E r e f l e t i d o para a camada de a¸c˜oes
345 ∗ d e s t e as pe c t o .
∗ ∗/
129
p o i n t c u t addAfter ( Plan plan , S t r i n g s t a t u s ) :
addAbstractAfter ( plan , s ta t u s ) &&
i f ( t e stAddAfter ( plan , s t a t u s ) ) ;
350
/∗
∗ M´etodos a b s t r a t o s : a s s i n a t u r a s de a ¸c˜oes do a sp e c t o s ,
implementados
∗ p e l a camada de a¸c˜oes do a sp e c t o .
∗ ∗/
355 protected abstract void baixarMensagem ( Action beh a v i our ) ;
protected abstract void formatarMensagem ( Behaviour beh a v i our ) ;
protected abstract void v isualiza r M ensagem ( Action b e haviour ) ;
protected abstract void comporMensagem ( Plan plan ) ;
protected abstract void enviarMensagem ( Plan plan ) ;
360
/∗
∗ R epre senta¸c˜ao do p l ano ”Plano de recebimento de mensagens ” .
∗ Chamada r e a l i z a d a p e l a camada de a¸c˜o e s do aspecto , onde ´e
v e r i f i c a d o se a¸c˜ao p o s s u i
∗ o rel a c i o namen t o add b e f o r e previa m ente determinado , ent˜ao
ex e c u ta a¸c ˜oes do a s p e ct o
365 ∗ na ordem e s p e c i f i c a d a . ∗/
protected void p la n B ef o re ( Action behaviour ) {
i f ( b e h aviour . r e l a t i o n s h i p A d d != nul l )
{
370 i f ( behaviou r . r e l a t i o n s h i p A d d . e q u a l s (
Re la ti o n s h i p C o n s t a n t s .RELATIONSHIP ADD BEFORE) )
{
baixarMensagem ( behavi o u r ) ;
formatarMensagem ( behavi o u r ) ;
vi s u alizarMe n s agem ( behaviou r ) ;
se t A l r e adyExecuted ( ( Plan ) be h a v iour .
get P a r e n t ( ) , true ) ;
375 }
}
}
/∗
380 ∗ R epre senta¸c˜ao do p l ano ”Plano de en v i o de mensagens ” .
130
∗ Chamada r e a l i z a d a p e l a camada de a¸c˜o e s do aspecto , onde ´e
v e r i f i c a d o se o p l ano
∗ c o rr e sp o nd e nt e p o s s u i o r e l a c ionam e n t o add a f t e r pr eviamen t e
determinado , en t˜ao
∗ e x e c ut a a¸c˜oes do a s p e c t o na ordem e s p e c i f i c a d a . ∗/
protected void p l a nA f t e r ( Plan plan ) {
385
i f ( plan . r e l a t i o n s h i p != n ul l ) {
i f ( pl an . r e l a t i o n s h i p . e q u a l s ( R e l a ti on s h i p C o n s t a n t s .
RELATIONSHIP ADD AFTER) ) {
comporMensagem ( plan ) ;
formatarMensagem ( plan ) ;
390 enviarMensagem ( plan ) ;
}
}
}
395 }
pa ckage t e s t . add ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
400 im port t e s t . Action ;
import t e s t . Plan ;
public a s p e c t AddAfte r5 20Concret eAspect extends
Ad d 5 2 0D e fi n e d R u le s In t e ra t iv i dad e As p ec t {
405 a f t e r ( Plan plan , S t r i n g s t a t u s ) : ad dAfte r ( plan , s t a t u s ) {
pl a n A f t er ( p lan ) ;
}
protected void formatarMensagem ( Behaviour b e h aviour ) {
410 System . out . p r i n t l n ( " Interceptado por aspecto (ADD AFTER):
Formatando mensagem atrav´es" +
" do plano: " + behav i o u r . getBehaviourName
( ) ) ;
}
protected void comporMensagem ( Plan plan ) {
131
415 System . out . p r i n t l n ( " Interceptado por aspecto (ADD AFTER):
Compondo mensagem atrav´es" +
" do plano: " + plan . getBehaviourName ( ) ) ;
}
protected void enviarMensagem ( Plan plan ) {
420 System . out . p r i n t l n ( " Interceptado por aspecto (ADD AFTER):
Enviando mensagem atrav´es" +
" do plano: " + plan . getBehaviourName ( ) ) ;
}
protected void baixarMensagem ( Action b e haviour ) {/∗DO NOTHING∗/ }
425
protected void visu a l izarMens a g em ( Action be h a v i our ) {/∗DO NOTHING∗/
}
}
430 package t e s t . add ;
import jad e . c o r e . b e h av i o ur s . Behaviour ;
import t e s t . Action ;
import t e s t . Plan ;
435
public a s p e c t AddBefore5 20Concr eteAspect extends
Ad d 5 2 0D e fi n e d R u le s In t e ra t iv i dad e As p ec t {
b e f o r e ( Action behavi o u r ) : addBefore ( behaviou r ) {
pl a n B e f or e ( behavio u r ) ;
440 }
protected void baixarMensagem ( Action b e haviour ) {
System . out . p r i n t l n ( " Interceptado por aspecto (ADD BEFORE):
" +
"Baixando mensagem atrav´es da a¸c~ao: " +
be h a v iour . getBehaviourName ( ) +
445 " do plano " + b e h aviour .
getParentBehaviourName ( ) ) ;
}
132
protected void formatarMensagem ( Behaviour b e h aviour ) {
System . out . p r i n t l n ( " Interceptado por aspecto (ADD BEFORE):
Formatando mensagem " +
450 "atrav´es da a¸c~ao: " + behav i o u r .
getBehaviourName ( ) + " do plano " +
be h a v iour . getParentBehaviourName ( ) ) ;
}
protected void visu a l izarMens a g em ( Action be h a v i our ) {
455 System . out . p r i n t l n ( " Interceptado por aspecto (ADD BEFORE ):
Visualizando mensagem " +
"atrav´es da a¸c~ao: " + behavi o u r .
getBehaviourName ( ) + " do plano " +
be h a v iour . getParentBehaviourName ( ) ) ;
}
460 protected void comporMensagem ( Plan plan ) { /∗DO NOTHING∗/ }
protected void enviarMensagem ( Plan plan ) {/∗DO NOTHING∗/ }
}
133
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
