Apresentação Original: Elder Cirilo Adaptação: Francisco Cunha Testes em Sistemas Multi-Agente © LES/PUC-Rio

Apresentação Original: Elder Cirilo

Adaptação: Francisco Cunha

Testes em Sistemas Multi-Agente

© LES/PUC-Rio

© 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

R1 R3

R2 R4

Problem Domain

R6 R8

R5 R7

functions

files

modules

Procedural

How?

Object Oriented

Object Attribute Method

Class

What?

Agent Oriented

Agent Roles Messages

Organization Protocols

Which agents?

Agentes – Um novo nível de abstração

© LES/PUC-Rio

Garcia, A., Lucena, C., Cowan D. Agents in Object-Oriented Software Engineering. Software Practice & Experience, Elsevier, 34 (5), pp. 489-521, 2004.

Definição

• Agente:

– é 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)

• Autonomia

– Diferentes conjuntos de ações podem alcançar o mesmo objetivo

System

© 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)

• Obstáculos:

– Mais de um comportamento “esperado” para um agente

– Entrada de Teste: dados + mensagens de conversas concorrentes.

Voas, J., and Miller, K.. Software Testability: The New Verication. IEEE Software, 12 3:1728, 1995.

© 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

≠

Ali Murat Tiryaki, Sibel Oztuna, Oguz Dikenelli, R. Cenk Erdur

SUnit: Test Driven Development of Multi-Agent Systems

© 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 inter-relacionamento das subtarefas que compõe o plano HTN.

• Para cada tarefa complexa em um único plano, um caso de teste estrutural deve ser implementado

© LES/PUC-Rio

Assert methods

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.

© LES/PUC-Rio

Assert methods

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.

© LES/PUC-Rio

O Diagrama de Classe do Módulo de Teste de Fluxo

Assert methods

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

© LES/PUC-Rio

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

• Ordem da Mensagem

• Conteúdo da Mensagem

• Aumento no atraso das mensagens

• Faltas nas crenças dos agentes

• Faltas em procedimentos internos

Agentes (novas abstrações) novas fontes de erros

© 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.

message response

send messagemethod call

method output

Tester

Test Class

Agent A

(A) (B)

© 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): execution(protected void Agent.setup())

&& target(o);

pointcut from_running_to_dead (Agent o): execution(public void Agent.doDelete()) && target(o); ...}

running

created waiting

dead

© LES/PUC-Rio

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 © 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.

Synchronizer

Mock Agents

11/04/23 26© 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.

© LES/PUC-Rio

JAT Framework: A Arquitetura

Aspects

class JATDIAGRAM

EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version EA 6.5 Unregistered Trial Version



































TestRunner

TestResult

TestCase TestSuite

TestAgent

AgentController ContainerController

TestReporter

+ getTestResult() : String+ setTestResult() : void

«aspect»Monitor

+ storeAgentState() : void+ waitUnitlAgentsDie() : void+ waitUnitlTestHasFinished() : void

Synchronizer

+ checkTurn() : boolean

MockAgentGenerator

+ generateMockAgent(File) : void

JadeTestCase

+ assertInteractionOK() : void+ startAUT() : void+ startMockAgent() : void

JadeMockAgent

+ receiveMessage() : void+ sendMessage() : void

AgentStateMachine

+ pointcut from_dead_to_started() : void+ pointcut from_runnig_to_dead() : void+ pointcut from_started_to_runnig() : void

class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


«aspect»Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


«xpi»AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


«interface»TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


JADE Middleware

<<crosscuts>>

Monitoring Concern MLegend:

Synchronization Concern Agent State Machine Concern

class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


JAT Framework

class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


JUnit Frameworkclass JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

«interface»Test

Agent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


class JATDIAGRAM




































TestRunner

TestResult

TestCase TestSuite

TestAgent


TestReporter


Monitor


Synchronizer


MockAgentGenerator


JadeTestCase


JadeMockAgent


AgentStateMachine


A S

S

A

M

<<uses>>

<<crosscuts>><<crosscuts>>

<<crosscuts>>

© LES/PUC-Rio

JAT Framework: Dinâmica

AgentStateMachineXPI

© LES/PUC-Rio


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


:Monitor

10.check(msg)

AUT: JADEAtent

6. add(state)5. state = crosscuts( )

Legend:

join point intercepted by Monitor aspect

join point interceptedby Synchronizer aspect

objectaspect

1. testMethod()

:JADETestCase

3. start(params)

:JADEMockAgent

4. start(params)

8. send(msg)

9. send(msg)

11. setResult( )

7. waitUntilTestFinishes ( )

14. notifyTestFinished ()

16. assertions( )

:Synchronizer

2. loadInteractionOrder( )

13. add(state)12. state = crosscuts( )

MonitoringDataRepository

11/04/23 32© LES/PUC-Rio

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.

11/04/23 33© LES/PUC-Rio

Usando a Ferramenta

• Caso de testes exemplo - descrição simplificada:

Agente testado (AUT)

BookSeller

Cenário

Resultado esperado

Dois agentes compradores querem comprar o mesmo livro vendido por um BookSeller, mas só existe uma copia do livro disponível.

O agente vendedor deve vender

o livro para o primeiro agente que solicitar o livro, e rejeitar a venda ao outro agente.

11/04/23 34© LES/PUC-Rio

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

11/04/23 35© LES/PUC-Rio

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

11/04/23 36© LES/PUC-Rio

Questões?

Documents

Apresentação Original: Elder Cirilo Adaptação: Francisco Cunha Testes em Sistemas Multi-Agente © LES/PUC-Rio