+
SADAAM
+
Equipe

Alessandro Lima

Leila Soriano

Vinícius Ottoni
+
Conteúdo

Introdução

Trabalhos Relacionados

Metodologia

Fase de Design

Test-Driven Implementation (TDI)

Release e Revisão

Conclusão

Referências
+
Introdução
O QUE É SADAAM ?
AOSE
Agent-Oriented Software Engineer
AOSE
Agent-Oriented Software Engineer
flexible iteractive incremental
Agile
Agile Development
AOSE
Agent-Oriented Software Engineer
Agile
Agile Development
+
SADAAM

Metodologia de desenvolvimento de agentes

Utiliza técnicas de uma variedade de métodos ágeis

SCRUM

XP

TDD
+
Trabalhos relacionados
+
Mase

Permite identificar o que deverá ser desenvolvido


quais e como os agentes se comportarão na sociedade.
Propõe uma seqüência de modelos que mapearão desde os
objetivos gerais até a definição dos casos de usos, papéis,
classes e diálogos entre os agentes.
+
Mase
+
MAS-Commonkads

Extensão da metodologia CommonKads

Referência na Europa no desenvolvimento de sistemas
baseados em conhecimento(SBC).
+
MAS-Commonkads

Divide o conhecimento da aplicação em três subníveis:

nível do domínio


nível de inferência


conhecimento declarativo sobre o domínio
uma biblioteca de estruturas genéricas de inferência
nível de tarefa

ordem das inferências
+
Metodologia
+
Metodologia

Central ao SADAAM está o Agent Development Process
(ADP)

Núcleo ágil do processo de desenvolvimento de agentes

Implementa o Integrated Development Process (IDP) com 4 fases
chave
+
Fases
Release e
Review
TDD
Design
Refactor e
enhacement
+
Metodologia

O ADP suporta uma abordagem bottom up

Aumenta a flexibilidade

Permite ao time

focar na entrega rápida

Responder rapidamente a mundanças nos requisitos
+
Fase de Design
+
Fase de Design

Processo interativo e incremental para análise e design de
agentes autônomos.

Identifica comportamentos do sistema e papéis
desempenhados por agentes
+
Fase de Design

Define agentes

Seus relacionamentos

Interações

Atividades

Define classes de agentes e métodos que compõem a
solução

Estes atributos são concebidos através de um conjunto
mínimo de artefatos de design que se baseam em AgentUML3.
+
Fase de Design

SADAAM adapta o Agile Model Driven Development Process
para a fase de design

Funcionalidades significantes
Análise de
Escopo de
Requisitos
Modelo
Inicial de
Requisitos
Expansão
de
Modelos
Iniciais
SADAAM
Model
Storming
+
Análise de Escopo e Requisitos

Auxilia a determinação de requisitos
+
Modelo Inicial de Requisitos

Esclarece qualquer ambiguidade na especificaçao de
requisitos

Base para dividir a implementação em passos gerenciáveis

Estabelece conhecimentos para compor o Modelo de
Comportamento do Sistema inicial

Provê informações do que o sistema faz

Como as entidades são definidas

Interações entre essas entidades
+
Model Storming Sessions

Invocam o mínimo esforço inicial para transformar requisitos
em modelos

Sessões irão surgir sempre que requisitos devam ser olhados
em grande detalhe

Pode envolver:

Reavaliação dos requisitos

Refinamento dos diagramas iniciais
+
Expansão de Modelos Iniciais

Descrevem os o comportamento do sistema em maiores
detalhes.

A abordagem SADAAM de Modelagem de Requisitos
emprega o Modelo de Comportamento do sistema

Auxilia a identificação de entidades envolvidas

Como os participantes operam no sistema
+
Expansão de Modelos Iniciais

Requer o desenvolvimento de Diagramas Organizacionais e
Comportamento do Sistema

Identificam as entidades básicas e seus relacionamentos
+
Fase de Design

Permite que o time de desenvolvimento trabalhe
iterativamente através do processo de design


entregando modelos em pequenos incrementos
suportando o rápido desenvolvimento e entrega de código para
release e review

Oferece flexibilidade de design

Racionaliza o esforço de desenvolvimento

Permite o time de desenvolvimento a adaptar mundanças em
requisitos eficientemente.
+
Fase de Design
Step 2
Step 1
Create /
Refactor
System
Behaviour
Mode
Step 4
Select System
Behaviour (s)
Step 3
Expand/
Define
Interaction
Diagrams
Expand/
Refine
Activity
Diagrams
+
Passo 1: Criar/ Refatorar o Modelo
do Comportamento do Sistema

O Modelo de Comportamento do Sistema indetifica
comportamentos chave do sistema para o dado cenário.

Comportamentos do sistema são conjuntos de atividades
e/ou interações que ocorre em algum estágio da operação
do sistema

é representado por um diagrama de Casos de Uso UML
modificado

onde atores são esteriotipados como agentes e casos de uso são
esteriotipados como comportamentos do sistema.
+
Passo 1: Criar/ Refatorar o Modelo
do Comportamento do Sistema

SADAAM também inclui a noção de estrutura organizacional
que está por trás de cada dado cenário.

O Modelo de Comportamentos consiste

Num Diagrama Organizacional Unitário (DOU) que descreve a
estrutura organizacional para o sistema alvo

um conjunto de Diagramas de Comportamentos do Sistema que
descrevem os comportamentos chave do sistema.
+
Passo 1: Criar/ Refatorar o Modelo
do Comportamento do Sistema

A Estrutura organizacional quebra o cenário de negócios
num modelo organizacional hierárquico.

O DOU define organizações:

Raiz

Suborganizações unitárias

E é responsável pela atribuição dos agentes para unidades para
unidades organizacionais específicas (UO)
+
Passo 1: Criar/ Refatorar o Modelo
do Comportamento do Sistema

A definição do DOU é um processo de 3 etapas que definem
ambos agentes e UOs no cenário.

Exemplo: Cadeias de Fornecimento
+
Revisão dos requisitos do sistema
e cenário de negócios

Varejista adquire mercadorias do fornecedor, que
posteriormente são entregues através de uma empresa de
transportes indepedente.

O cenário inicia com o comprador solicitando cotações ao
fornecedor

Uma vez que os preços são recebidos, o comprador pede as
mercadorias
+
Revisão dos requisitos do sistema
e cenário de negócios

O Fornecedor contacta a empresa de Transportes

A empresa de Transportes recolhe as mercadorias e entrega
ao varejista
+
Definir a Estrutura Organizacional
e UOs no ambiente em que você
está tentando modelar

A DOU vê nosso cenário como um ambiente
estruturado onde três UOs individuais operarem e
cooperaram sistematicamente para conduzir uma transação.
+
Definir a Estrutura Organizacional
e UOs no ambiente em que você
está tentando modelar

A DOU vê nosso cenário como um ambiente
estruturado onde três UOs individuais operarem e
cooperaram sistematicamente para conduzir uma transação.
+
Passo 1: Criar/ Refatorar o Modelo
do Comportamento do Sistema
+
Atribuir agentes dentro da
estrutura organizacional

Esta etapa associa agentes a OUs específicos, permitindo a
clara identificação dos agentes necessários ao cenário dado.

SADAAM associa um SBD a cada unidade DOU

permitindo cada SBD indentificar todos os comportamentos do
sistema assumidos pelos agentes que são parte de uma unidade
particular ou uma de suas subunidades.
+
Passo 2: Selecionar
comportamentos do sistema

Envolve selecionar um subconjunto de todos os
comportamentos do sistema para uma análise minunciosa.

Trata-se de uma definição do escopo

Identifica quais partes do sistema o time irá trabalhar
+
Passo 3: Expandir/Definir Modelos
de Interações

O Modelo de Interações (IM) define interações que ocorrem
entre agentes desempenhando papéis durante um
comporatmento específico do sistema.

O IM consiste em um conjunto de Agent UML Protocol
Diagrams, que são associados a comportamentos individuais
do sistema.
+
Passo 3: Expandir/Definir Modelos
de Interações

Um dado comportamento do sistema pode ter zero, um, ou
múltiplos diagramas de protocolos associados.

Tipicamente, um diagrama de protocolo inclui as interações
esperadas relacionadas ao comportamento (normalmente o
caso de sucesso); e todas (conhecidas) interações variantes
(i.e.: casos de insucesso).
+
Passo 3: Expandir/Definir Modelos
de Interações
+
Passo 4: Expansão do IM com
Modelo de Atividade

O Modelo de Atividades identifica o conjunto de atividades
realizadas pelos agentes no sentido de entender um dado
comportamento do sistema.

Emprega Diagramas de Atividades UML customizados onde:

Caixas representam atividades individuais

Associações colocam ordem na performance de atividades

Setas rotuladas são introduzidas para associar agentes com
atividades.
+
Conclusões

A fase de Design constrói técnicas ágeis para prover um
processo de design iterativo e incremental

Dá suporte ao envolvimento do cliente

Melhora a flexibilidade

Facilita análises contínuas e feedback
+
Conclusões

Adaptação a situações de mudanças.

Permite ao desenvolvedor aprender e melhorar a versão
anterior através da iteração contínua e melhoria de design.

Facilita priorização de tarefas e alocação eficiente de
recursos.

Finalmente, pode ser incorporado por qualquer framework
de desenvolvimento de agentes.
+
Test-Driven Implementation
Implementação conduzida pelos Testes
+
Test-Driven Implementation

Projetado para ajudar a gerenciar e controlar o
desenvolvimento de um agente.

Conceitos Chave: Test Agent e Application Agent under Test.
TA
Codifica um conjunto
de Casos de Teste que
devem ser satisfeitos
pela AAUT
correspondente.
AAUT
Representa o agente
cujo comportamento
está em teste,
realizando os testes
descritos no TA.
+
Test-Driven Implementation

Arquitetura
+
TDI Phase

Fase dividida em cinco etapas, que
tem como objetivo, implementar,
integrar e debugar os códigos
necessários para os testes dos
agentes.
+
TestSuite Application Structure

Local onde os Agentes de Teste
serão executados e validados.
+
TestSuite Application Structure

Local onde os Agentes de Teste
serão executados e validados.

Criação e validação dos Agentes
de Teste.
+
TestSuite Application Structure

Local onde os Agentes de Teste
serão executados e validados.

Criação e validação dos Agentes
de Teste.

Criação e execução dos Agentes
de Aplicação.
+
TestSuite Application Structure

Local onde os Agentes de Teste
serão executados e validados.

Criação e validação dos Agentes
de Teste.

Criação e execução dos Agentes
de Aplicação.

Integração necessária para
implantação de um SMA.
+
AF Agent Plataform Scripts

Suporte de configuração para a
TestSuite através da plataforma de
servições da TestSuite e a classe
base TestAgent.

TestAgent class: Fornece a
implementação genérica de um
TA.
+
AF Agent Plataform Scripts

Test.aps: Prevê a criação dos agentes
de teste, a associação entre eles e
armazena suas informações. Por
exemplo, a criação dos TAs chamados
testTransportManager e testHauler.
+
AF Agent Plataform Scripts

Test.aps: Prevê a criação dos agentes
de teste, a associação entre eles e
armazena suas informações. Por
exemplo, a criação dos TAs chamados
testTransportManager e testHauler.

Implementation.aps: Associa cada
AAUT com o seu TA e armazena suas
informações. Por exemplo, o Hauler é
associdado ao testHauler.
+
AF Agent Plataform Scripts

Test.aps: Prevê a criação dos agentes
de teste, a associação entre eles e
armazena suas informações. Por
exemplo, a criação dos TAs chamados
testTransportManager e testHauler.

Implementation.aps: Associa cada
AAUT com o seu TA e armazena suas
informações. Por exemplo, o Hauler é
associdado ao testHauler.

Integration.aps: Registra os testes
feitos com os AAUT.
+
TDI Phase

Fase dividida em cinco etapas, que
tem como objetivo, implementar,
integrar e debugar os códigos
necessários para os testes dos
agentes.
+
TDI Phase

Análise da Fase de projeto para
determinar os AAUTs. Exemplo:
TransportManager e Hauler.

Os requisitos para cada TA são
definidos através dos casos de
Teste.

Criado os arquivos que definem
cada agente.

Testada a implantação dos agentes
através do arquivo test.aps.
+
TDI Phase

Revisar o projeto para verificar os
requisitos dos AAUTs.

Registrar os AAUTs criados e suas
associações com seus respectivos
TAs no arquivo
implementation.aps.
+
TDI Phase

Testar os AAUTs antes de
implementá-los no SMA.

Revisar, refatorar e iniciar o ciclo
novamente.
+
TDI Phase

Integrar e depurar os AAUTs para
implantar no SMA.

Registrar os testes de integração
no arquivo integration.aps.

Realizar os testes de integração
com os AAUTs dentro da
aplicação.
+
TDI Phase

Revisar, refatorar e iniciar o ciclo
novamente se for necessário.
+
Visão geral da Aplicação

Após todos os passos citados anteriormente, temos a
seguinte visão geral da aplicação SADAAM.
+
Arquitetura Revisada

Após todos os passos citados anteriormente, temos a
seguinte arquitetura.
Monitor SADAAM
TestSuite Application Structure
TDI Phase
AF Agent Plataform Script
+
Release e Revisão
Entregando o Projeto
+
Release e Revisão

Analisar geral após cada Release.

Entrega do projeto para o cliente para Revisão.

Colocar o aplicativo em um ambiente real.

Pode aparecer melhorias necessárias, para preencher todos
os requisitos do cliente.
+
Conclusão
+
Conclusão

Sadaam apresenta uma metodologia ágil para o
desenvolvimento de sistemas multi-agente.
+
Conclusão

Permite ciclos de interações que geram:

Flexibilidade no projeto

Avanço incremental

Eficácia na entrega

Redução no tempo desenvolvimento

Resuo de código (Test Agents)
+
Conclusão

Permite ciclos de interações que geram:

Flexibilidade no projeto

Avanço incremental

Eficácia na entrega

Redução no tempo desenvolvimento

Reuso de código (Test Agents)
+
Referências
+
Referências

Agile Alliance., ”What is Agile Software Development?”,
web:

http://www.agilealliance.org/

2. AGILE Manifesto available at http://agilemanifesto.org

3. Ambler, S., ”Agile Modeling: The Official Agile Modelling
(AM) Site.” Agile Modelling Home Page:
http://www.agilemodeling.com/

4. Amor, M., Fuentes, L. and Vallecillo, A., ”Bridging the Gap
between AO Design and Implementation Using MDA” , AOSE
2004. LNCS 3382, pp 93-108.
+
Referências

5. Bauer, B., Mueller, J., and Odell, J., ”Agent UML: A
Formalisation for Specifying Multi-Agent Software Systems.”,
In P. Ciancarini and M. Wooldridge, ed, 1st Int. Workshop on
Agent-Oriented Software Eng. (AOSE-2000), Limerick, Eire,
2000.

6. Beck, K., ”Extreme Programming Explained: Embrace
Change.”, AW Pub. 1999.

7. Beck, K., ”Test-Driven Development by Example.”, Addison
Wesley, 2003.

8. Bergenti, F. and Poggi, A., ”Exploiting UML in the design of
Multi-Agent Systems.”, In Proc. of the ECOOP Workshop on
Engineering Societies in the Agents’ World 2000 (ESAW’00),
pages 96-103, 2000. Boehm, B. and Turner, R., ”Balancing
Agility and Discipline: A Guide for the Perplexed.”, Boston,
MA: Addison-Wesley, 2004, ISBN 0-321-18612-5, pp 165-194.
+
Referências

9. Boehm, B. and Turner, R., ”Balancing Agility and Discipline:
A Guide for the Perplexed.”, Boston, MA: Addison-Wesley,
2004, ISBN 0-321-18612-5, pp 165-194.

10. Bresciani, P., Giorgini, P., Giunchiglia, F. Mylopoulos, J. and
Perini, A., ”TROPOS: An Agent-Oriented Software
Development Methodology.”, JAAMAS, 2003

11. Cernuzzi, L., Cossentino, M., Zambonelli, F., Process
Models for Agent-based Development, Journal. Eng.
Applications of AI, 18(2), 2005.

12. Chella, A. Cossentino, M., Sabatucci, L., and Seidita, V.,
”Agile PASSI: An Agile Process for Designing Agents”,
International Journal of Computer Science and Eng. Special
Issue on ”Software Eng. for Multi-Agent Systems”, May 2006
+
Referências

13. Coelho, R., Kulesza, U., von Staa, A., and Lucena, C., ”Unit
testing in multiagent systems using mock agents and aspects,
Procs of the 2006 Int. workshop on Software engineering for
large-scale multi-agent systems, Shanghai, China

14. Collier, R.W. ”Agent Factory: A Framework for the
Engineering of Agent-Oriented Applications.”, PhD thesis,
Dept. of Computer Science, UCD, Dublin, 2002.

15. Collier, R.W., O’Hare, G.M.P., Lowen, T.D. and Rooney,
C.F.B., ”Beyond Prototyping in the Factory of Agents.”, 3rd Int.
Central and Eastern European Conf. on Multi-Agent Systems,
CEEMAS 2003, Prague, Czech Republic, 16-18th June, Lecture
Notes in Computer Science (LNCS), Springer Verlag, 2003.
+
Referências

16. Collier, R. W., Rooney, C. and O’Hare, G. M. P., ”A UMLbased Software Engineering Methodology for Agent
Factory.”, Proceeding of the 16th International Conference on
Software Engineering and Knowledge Engineering (SEKE2004), Banff, Alberta, Canada, 20-25th June, 2004.

17. Fowler, M., ”Refactoring: Improving the Design of Existing
Code.”, Addison Wesley Longman, 1999.

18. P. Giorgini, eds, ”Agent-Oriented Methodologies”,
IdeaGroup, B. Henderson - Sellers 2005.

19. Huget, M-P, Bauer, B., Odell, J., Levy, R., Turci, P., Cervenka,
R., Zhu, Hong, Interaction Diagram Specification, FIPA AUML
Website, http://www.auml.org
+
Referências

20. Iglesias, C., Garijo, M., Gonzalez, J., Velasco, J., ”Analysis
and Design of MultiAgent Systems using MASCommonKADS.”, Springer,LNCS 1365, p489, 2004

21. Jennings, N.R., ”Building Complex Software Systems: The
Case for an Agent-Oriented Approach.”, Communications of
the ACM, 2001.

22. Jennings, N.R. and Wooldridge, M.; ”Agent-Oriented
Software Engineering.” in Handbook of Agent Technology,
(ed. J. Bradshaw), AAAI/MIT Press, 2000.

23. Knublauch, H., Koeth, H, and Rose, T., ”Agile Development
of a Multi-Agent System: An Extreme Programming Case
Study.”, Appears in: Proc of the 3rd Int. Conf. On Extreme
Programming and Agile Processes in Software Engineering
(XP2002), Alghero, Sardinia, Italy.
+
Referências

24. Rooney, C F.B., Collier, R.W., O’Hare, G.P., ”VIPER: VIsual
Protocol EditoR”, in 6th Int. Conf. on Coordination Languages
and Models (Coordination 2004), Pisa, February 24-27, 2004.

25. Schwaber, K., and Beedle, M., ”Agile Software
Development with Scrum.”, Prentice Hall, 2001.

26. Sommerville, I., ”Software Engineering.”, Addison-Wesley
6th Ed., 2000.

27. Tveit, A., ”A survey of Agent-Oriented Software
Engineering.” In Proceedings of the First NTNU Computer
Science Graduate Student Conference, Norwegian University
of Science and Technology, May 2001.
+
Referências

28. Wood, M.F. and DeLoach, S.A., ”An Overview of MultiAgent Systems Engineer ing Methodology.” AOSE-2000, 1st
Int. Workshop on AOSE, Limerick, Eire, 2000.

29. Zambonelli, F., Jennings, N.R., Omicini, A., and
Wooldridge, M., ”Coordination of Internet Agents: Models,
Technologies and Applications”, Agent-Oriented Software
Engineering for Internet Applications, Springer-verlag, 2000