Testes em Sistemas Multi-Agente
Apresentação Original: Elder Cirilo
Adaptação: Francisco Cunha
© LES/PUC-Rio
Background
• A WWW e os dispositivos móveis  novas
aplicações:
– Coleção de componentes distribuídos
– Entrada de uma variedade de fontes
– Adaptada de acordo com a preferência dos usuários
• Tecnologia de Agentes:
– Maneira importante de implementar tais sistemas
– Usa abstrações de nível superior (alto nível).
© LES/PUC-Rio
Agentes – Um novo nível de abstração
Problem Domain
R1
R2
R3
R4
R5
R7
R6
R8
How?
What?
files
functions
Which agents?
modules
Procedural
Object
Attribute
Method
Class
Object Oriented
Agent
Organization
Roles
Messages
Protocols
Agent Oriented
© LES/PUC-Rio
Definição
• Agente:
System
– é uma entidade autônoma
– que executa um plano
– para alcançar um objetivo
– com base em suas crenças (atributos)
– que se comunica de forma assíncrona (baseado em
mensagem)

Garcia, A., Lucena, C., Cowan D. Agents in Object-Oriented Software Engineering. Software Practice &
Experience, Elsevier, 34 (5), pp. 489-521, 2004.
• Autonomia
– Diferentes conjuntos de ações podem alcançar o
mesmo objetivo
© LES/PUC-Rio
Tecnologia de Agentes: Benefícios e Desafios
• Por um lado:
– Facilita atender aos requisitos das aplicações atuais.
• Por outro lado:
– Novos desafios para a testabilidade do software e,
consequentemente, para manutenção.
• Testes:
– Visam descobrir erros de regressão.
– Servir como uma documentação viva.
© LES/PUC-Rio
Obstáculos à Testabilidade do Software
• Testabilidade:
– Controlar a entrada do teste (controllability)
– Observar a saída da unidade que está sendo testada
(observability)

Voas, J., and Miller, K.. Software Testability: The New Verication. IEEE Software, 12
3:1728, 1995.
• Obstáculos:
– Mais de um comportamento “esperado” para um
agente
– Entrada de Teste: dados + mensagens de conversas
concorrentes.
© LES/PUC-Rio
Abordagem no Desenvolvimento de MAS
• Adotado Tradicionalmente:
– Processo de prototipagem
– Abordagem ad-hoc para garantir a qualidade do
sistema.
• Poucos trabalhos definem um processo de teste
com suporte a ferramentas:
– Agile
• Plataforma de testes
≠
plataforma real
– Agile Passi
• Agentes seguem um comportamento (autonomia)
– SUnit
– JAT/JAT-BDI/BDI4JAT
© LES/PUC-Rio
SUnit: Test Driven Development of MultiAgent Systems
Ali Murat Tiryaki, Sibel Oztuna, Oguz Dikenelli,
R. Cenk Erdur
© LES/PUC-Rio
Abordagem Utilizada
• Abordagem baseada no desenvolvimento dirigido
aos testes que suporta a construção do SMA de
maneira iterativa e incremental
• Implementa um framework baseado no JUnit para
escrever testes automatizados para o
comportamento dos agentes e interações entre
agentes.
– Mock agents para modelar os aspectos
organizacionais do SMA
– Foi implementado utilizando Hierarchical Task
Network - HTN
© LES/PUC-Rio
Desenvolvimento dirigido a Testes
• Test driven development (TDD)
– Estilo de desenvolvimento de software em que o
desenvolvimento é impulsionado por testes
automatizados.
– Ciclo: desenvolvedor primeiramente escreve testes
funcionais para uma unidade/tarefa; depois escreve
o código que atende aos testes escritos e, em
seguida, o código é refatorado para melhorar o
design
• Apoia a construção de tarefas iterativas e
incrementais
© LES/PUC-Rio
Framework de Testes: SUnit
• Fornece um framework para testes dirigidos ao
desenvolvimento de planos
• Ajuda o desenvolvedor a criar e executar testes
de maneira uniforme e automática durante a
implementação do plano
• Consiste de 3 sub-módulos
– Módulo de Teste Estrutural
– Módulo de Teste de Ação
– Módulo de Teste de Fluxo
© LES/PUC-Rio
Módulo de Teste Estrutural
• Este módulo auxilia o desenvolvedor na definição
de subtarefas e na determinação do interrelacionamento das subtarefas que compõe o
plano HTN.
• Para cada tarefa complexa em um único plano,
um caso de teste estrutural deve ser
implementado
Assert methods
© LES/PUC-Rio
Módulo de Teste de Ação
• Ação é uma tarefa primitiva que gera um
resultado ou uma mensagem para outro agente
na plataforma.
• Este módulo foi projetado para examinar os
resultados ou mensagens em relação aos
conjuntos definidos providos pelo usuário para as
tarefas primitivas.
Assert methods
© LES/PUC-Rio
Módulo de Teste de Fluxo
• Este módulo é projetado para avaliar os resultados
ou mensagens de saída das tarefas em relação as
mensagens recebidas ou conjuntos de mensagens
predefinidas.
O Diagrama de Classe do
Módulo de Teste de Fluxo
Assert methods
© LES/PUC-Rio
Criando um Teste Unitário
• SeagentStructuralTestCase deve ser estendido para validar
a estrutura do plano.
• SeagentActionTestCase tem de ser estendido para ser
capaz de escrever assertivas para tarefas primitivas.
– Verifica os resultados das tarefas primitivas tais como os
resultados ou mensagens geradas.
• SeagentFlowTestCase verifica a correção dos conceitos da
OWL e valor com os esperados.
© LES/PUC-Rio
Criando um Teste Unitário - Exemplo
• Um viajante tenta organizar um plano de férias que inclui
reserva de hotel e detalhes de transporte. O objetivo do
cenário é organizar o plano de férias, selecionando as
opções de acomodação e transporte adequados com base
nas preferências mais baratas dos viajantes.
© LES/PUC-Rio
JAT: A Test Automation Framework for
Multi-Agent Systems
Roberta Coelho, Elder Cirilo, Uirá Kulesza
Arndt von Staa, Awais Rashid, Carlos Lucena
Abordagem
• Define uma abordagem para construção e
execução de testes SMA.
• É baseado na Programação Orientada a Aspectos
para:
– Controlar a entrada do teste
– Observar a saída das unidades em testes
• Foi implementado sobre o JADE:
– Middleware para aplicações desenvolvidas em Java
baseadas em agentes.
© LES/PUC-Rio
JADE Agent Testing (JAT) Framework
• JAT possibilita:
– A criação de testes automatizados no estilo JUnit
para MA desenvolvidos em JADE.
• JAT é usado:
– como um framework genérico de testes para
desenvolvedores JADE
– da mesma maneira como JUnit é para
desenvolvedores Java
© LES/PUC-Rio
Modelo de Faltas
Agentes (novas abstrações)  novas fontes de erros
• Ordem da Mensagem
• Conteúdo da Mensagem
• Aumento no atraso das mensagens
• Faltas nas crenças dos agentes
• Faltas em procedimentos internos
© LES/PUC-Rio
Ideias Principais
1. Usando Agentes para testar Agentes:
• MockAgent (ou Agente Falso):
• adaptação do conceito de mock objects para agentes
• simular um agente real do sistema
• envia mensagens para um agente em teste (AUT) e
• verifica a resposta:
• conteúdo, tempo de resposta, tipo, ordem.
(A)
method call
(B)
Class
send message
method output
message response
Tester
Agent A
© LES/PUC-Rio
Ideias Principais
2. Monitorando os Agentes:
– Agentes são autônomos
– O desenvolvedor precisa conhecer o estado dos
agentes
• Ex.: para responder: saída == saída esperada?
– Monitor Aspect observa e armazena informações
sobre o estado de transição dos agentes (ex.:
running, dead).
© LES/PUC-Rio
Ideias Principais
2. Monitorando os agentes: (cont.)
• A máquina de estado do agente é uma abstração
transversal;
• “espalhada” sobre a aplicação e os módulos da
plataforma;
• Pode ser representada como um aspecto (XPI);
public aspect AgentStateMachine {
pointcut created():call(public
ContainerController.createNewAgent(..));
pointcut from_created_to_running(Agent o): created
execution(protected void Agent.setup())
&& target(o);
pointcut from_running_to_dead (Agent o):
execution(public void Agent.doDelete())
&& target(o);
...
© LES/PUC-Rio
running
waiting
dead
Ideias Principais
2. Monitorando os agentes: (cont.)
privileged public aspect Monitor {
...
before(Agent o):
AgentStateMachine.from_created_to_running(o){
includeInRunningAgents(o);
}
public void waitUntilAgentIsDead (String mockAgentID){
while (!isDead(mockAgentID) && (MAXTIMEOUT > timeSpent)){
wait(20000);
...
}
}
...
}
© LES/PUC-Rio
Ideias Principais
3. Sincronizando MockAgents
– MockAgents implementam parcialmente um cenário de
teste
– Precisamos definir a ordem em que os Agentes Mocks
devem interagir com o AUT.
Mock Agents
Synchronizer
© LES/PUC-Rio
Ideias Principais
• Elementos para controlar o input (cont.):
– Aspecto Synchronizer:
• Assim como um maestro define a ordem de cada instrumento,
este elemento define a ordem em que cada MockAgent deve
interagir com o AUT.
• Monta o script de testes: dividido partes no behavior de cada
Mock.
05/11/2015
© LES/PUC-Rio
26
JAT Framework: A Arquitetura
JADE Middleware
JUnit Framework
<<crosscuts>>
<<crosscuts>>
A
Aspects
<<uses>>
<<crosscuts>>
<<crosscuts>>
M
S
JAT Framework
Legend:
M
Monitoring Concern
A
Agent State Machine Concern
© LES/PUC-Rio
S
Synchronization Concern
JAT Framework: Dinâmica
AgentStateMachineXPI
© LES/PUC-Rio
JAT Framework: Dinâmica
AgentStateMachineXPI
1
© LES/PUC-Rio
JADETestCase: Exemplo de Código
public class BookTradingTesteCase extends JADETestCase {
public void testBookTradingScena1(){
//Load Data Repositories
…
startAUT("seller","BookSeller");
startMockAgent("buyer1","BookBuyerMockAgent",FIRST);
startMockAgent("buyer2","BookBuyerMockAgent",SECOND);
//Blocks until interaction finishes
Monitor.aspectOf(). waitUntilTestHasFinished("buyer1");
Monitor.aspectOf(). waitUntilTestHasFinished("buyer2");
//Check Expected Result:
assertInteractionOK("buyer1");
assertInteractionOK("buyer2");
//Check Expected Result:
Object belief= getBelief(“seller”,“catalogue”);
assertEquals(expectedBelief,belief);
}
...
}
© LES/PUC-Rio
JAT Framework: Dinâmica
JADETestCase
:
JADEMockAgent
:
AUT: JADEAtent
:Monitor
Monitoring
DataRepository
1. testMethod
()
:Synchronizer
2. loadInteraction
Order( )
3. start(params)
4. start(params )
5. state = crosscuts( )
6. add(state)
7. waitUntilTestFinishes ( )
8. send(msg)
9. send(msg)
10.check(msg)
11. setResult
()
12. state =crosscuts( )
13.add(state)
14. notifyTestFinished ()
16. assertions( )
Legend:
join point intercepted
by Monitor aspect
join point intercepted
by Synchronizer aspect
© LES/PUC-Rio
object
aspect
Usando a Ferramenta
• Nosso Objetivo:
– Construir testes automatizados para o
BookTrading.
• Descrição do Sistema:
– Sistema de venda e compra de livros.
– Possui 2 agentes:
• BookSeller: representa usuário que deseja vender
livros.
• BookBuyer: representa usuário que deseja comprar
livros dos agentes vendedores disponíveis no sistema.
05/11/2015
© LES/PUC-Rio
32
Usando a Ferramenta
• Caso de testes exemplo - descrição simplificada:
Agente testado (AUT)
BookSeller
Cenário
Dois agentes compradores querem
comprar o mesmo livro vendido por
um BookSeller, mas só existe uma
copia do livro disponível.
Resultado esperado
O agente vendedor deve vender o
livro para o primeiro agente que
solicitar o livro, e rejeitar a venda ao
outro agente.
05/11/2015
© LES/PUC-Rio
33
Usando a Ferramenta
• Assim como no JUnit, podemos construir testes em
diferentes níveis:
– Unidade:
• Objetivo: avaliar o comportamento de 1 único agente real
• Como: criar 1 agente real e mocks que interagem com ele
– Integração:
• Objetivo: avalia a interação entre 2 ou mais agentes reais
• Como: criar os agentes reais e outros mocks (se necessário)
– Sistema:
• Objetivo: verificamos se uma tarefa a ser desempenhada por um
conjunto de agentes foi bem sucedida
• Como: criar o conjunto de agentes reais e ao final da interação entre
eles verificar se o ambiente foi afetado como esperado
05/11/2015
© LES/PUC-Rio
34
Limitações e Futuras extensões
•
Usar informações de cobertura:
– como uma resposta para melhorar a eficácia dos casos de
teste
•
Geração de casos de teste
– Gerar JADETestCases (e.g. Parasoft JTest).
•
Aplicar o Framework em casos de estudos reais
05/11/2015
© LES/PUC-Rio
35
Questões?
05/11/2015
© LES/PUC-Rio
36