“u -tropos: uma proposta de processo unificado para apoiar ... · palavras chaves: engenharia de...

Ps-Graduao em Cincia da Computao

U-TROPOS: uma proposta de processo

unificado para apoiar o desenvolvimento de

software orientado a agentes

Por

MARIA JOCELIA SILVA

Dissertao de Mestrado

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, Outubro / 2008

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA

PS-GRADUAO EM CINCIA DA COMPUTAO

MARIA JOCELIA SILVA

U-TROPOS: uma proposta de processo unificado para apoiar o desenvolvimento de software orientado a agentes"

ESTE TRABALHO FOI APRESENTADO PS-GRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO GRAU DE MESTRE EM CINCIA DA COMPUTAO.

ORIENTADOR: JAELSON FREIRE BRELAZ DE CASTRO CO-ORIENTADORA: FERNANDA MARIA RIBEIRO DE ALENCAR

RECIFE, OUTUBRO / 2008

Silva, Maria Jocelia U-TROPOS: uma proposta de processo unificado para apoiar o desenvolvimento de software orientado a agentes / Maria Jocelia Silva. Recife: O Autor, 2008. xii, 177 folhas : il., fig., tab. Dissertao (mestrado) Universidade Federal de Pernambuco. CIn. Cincia da Computao, 2008. Inclui bibliografia e apndices. Engenharia de software. I. Ttulo. 005.1 CDD (22.ed.) MEI2008-090

iv

Resumo

Atualmente existe muita expectativa em relao tecnologia de agentes, que surge como um paradigma promissor para a engenharia de sistemas de software. Agentes so importantes e teis porque permitem um tratamento adequado do fluxo de controle de sistemas altamente distribudos, oferecem um mecanismo que facilita o surgimento de comportamento emergente, bem como incorporam as melhores prticas de como organizar entidades colaborativas concorrentes. Com o aumento da complexidade das aplicaes baseadas em agentes, torna-se importante o uso de notaes, ferramentas e metodologias especficas para seu o desenvolvimento. Nos ltimos anos foram propostas vrias metodologias e notaes para desenvolvimento orientado a agentes, tais como Tropos. Trata-se de abordagem centrada em requisitos, que se preocupa em capturar a complexidade de aspectos sociais. Tropos considerada uma das metodologias mais completas, pois abrange todas as fases do ciclo de desenvolvimento de sistemas multiagentes. Desde a concepo inicial do Tropos em 2000, vrias verses e extenses foram propostas. Contudo, estas propostas tm adotado atividades e notaes diferentes, dificultando sua adoo pelos desenvolvedores de software. Alm disso, no existe um processo padronizado e unificado que oriente as suas atividades de desenvolvimento orientado a agentes. O objetivo principal desta dissertao especificar um processo unificado de desenvolvimento orientado a agentes conforme algumas propostas existentes do projeto Tropos. A especificao ser baseada na linguagem SPEM de especificao de processos. Ser proposto tanto um modelo estrutural como um modelo dinmico do processo. A base para formulao do modelo estrutural do processo a integrao de atividades extradas das duas verses de Tropos com mtodos criados para as fases de projeto arquitetural e projeto detalhado. O modelo dinmico sugere um ciclo de vida orientado pelo modelo de desenvolvimento iterativo e incremental. O resultado o U-Tropos: uma proposta de processo unificado para apoiar o desenvolvimento de software orientado a agentes. Palavras chaves: Engenharia de software, Desenvolvimento de sistemas multiagentes, Metodologia Tropos

v

Abstract

Nowadays, there is great expectation related to agent technology, which emerges as a promising paradigm for software systems engineering. Agents are important and useful because they allow appropriate treatment of the flow of highly distributed control systems, provide a mechanism that facilitates the emergent behavior, and incorporate the best practices of collaborative entities to organize competitors. With the increasing complexity of agent-based applications, the use of specific ratings, tools and methodologies for their development is important. In recent years, methodologies and ratings for agent oriented development have been proposed, such as Tropos, which is a requirements-driven approach that captures the complexity of social aspects. Tropos is considered one of the most complete methodologies, therefore covers all stages of multiagent systems development. Since the Tropos initial design in 2000, various versions and extensions were proposed. However, these proposals have adopted different activities and ratings, hindering their adoption by software developers. Moreover, there is not a unified and standardized process to guide their agent oriented development activities. The main aim of this dissertation is to specify an agent development unified process based on some existing Tropos project proposals. The specification will use SPEM (a processes specification language). Both a process structural model and a process dynamic model will be offered. The basis for formulating the structural model is the integration of activities drawn from two Tropos versions. It will add methods designed for architectural design and detailed design phases. The dynamic model suggests a life cycle driven by the iterative and incremental development model. The result is the U-Tropos: a proposal for a unified process to support the agent oriented software development.

Key words: Software engineering, Multiagent system development, Tropos methodology.

vi

Agradecimentos

Agradeo

a Deus, por todas as coisas;

a minha famlia, por ter me ensinado a chegar at aqui;

a meus amigos, pela fora e apoio recebidos;

a meus amigos e colegas do CIN, pelo companheirismo e colaborao;

a meus amigos e colegas do CEFET-PE, pela colaborao e incentivo;

a minha co-orientadora Fernanda Alencar, por seu apoio e conhecimento compartilhado, que foram fundamentais em todas as fases deste trabalho;

a meu orientador Jaelson Castro pela oportunidade de participar deste conceituado grupo de trabalho;

a todos do Centro de Informtica da UFPE, pela tima estrutura para formao de profissionais e pesquisadores;

a todos que apoiaram, incentivaram e contriburam para a realizao deste trabalho.

vii

Sumrio

1 INTRODUO ............................................................................................................................ 1

1.1 MOTIVAO .............................................................................................................................. 2 1.2 ESCOPO ...................................................................................................................................... 3 1.3 OBJETIVOS ................................................................................................................................ 3 1.4 ESTRUTURA DA DISSERTAO ................................................................................................. 4

2 DESENVOLVIMENTO DE SOFTWARE ORIENTADO A AGENTES ............................... 6

2.1 INTRODUO ............................................................................................................................. 7 2.2 METODOLOGIAS PARA DESENVOLVIMENTO DE SMA ............................................................ 8

2.2.1 AUML (Agent UML) ........................................................................................... 10 2.2.2 MAS-CommonKADS .......................................................................................... 12 2.2.3 GAIA .................................................................................................................... 13 2.2.4 MaSE e O-MaSE .................................................................................................. 14 2.2.5 PASSI ................................................................................................................... 16 2.2.6 TROPOS ............................................................................................................... 17

2.3 CONSIDERAES FINAIS ........................................................................................................ 18

3 O PROJETO TROPOS .............................................................................................................. 21

3.1 INTRODUO ........................................................................................................................... 22 3.2 FRAMEWORK I* ...................................................................................................................... 23 3.3 A ABORDAGEM TROPOS VISO GERAL ............................................................................... 27

3.3.1 Requisitos Iniciais ................................................................................................ 27 3.3.2 Requisitos Finais .................................................................................................. 28 3.3.3 Projeto arquitetural ............................................................................................... 30 3.3.4 Projeto detalhado .................................................................................................. 33 3.3.5 Implementao...................................................................................................... 34

3.4 VERSES DA METODOLOGIA TROPOS ................................................................................... 35 3.5 EXTENSES S FASES DE TROPOS .......................................................................................... 38

3.5.1 Procedimentos para guiar a construo dos modelos i* ....................................... 38 3.5.2 Framework SIRA .................................................................................................. 40 3.5.3 Projeto detalhado em UML .................................................................................. 43


4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ................................................. 49

4.1 INTRODUO ........................................................................................................................... 50 4.2 MODELOS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ........................................ 51 4.3 MODELOS DE PROCESSOS PARA SISTEMAS MULTIAGENTES ................................................ 55 4.4 SPEM - SOFTWARE PROCESS ENGINEERING METAMODEL ................................................. 57 4.5 ESPECIFICAES DE TROPOS USANDO SPEM ...................................................................... 61 4.6 CONSIDERAES FINAIS ........................................................................................................ 62

viii

5 U-TROPOS ................................................................................................................................. 64

5.1 INTRODUO ........................................................................................................................... 65 5.2 CICLO DE VIDA DO PROCESSO ............................................................................................... 67

5.2.1 Fases do Ciclo de Vida ......................................................................................... 67 5.2.2 Iteraes ................................................................................................................ 69

5.3 COMPONENTES DO PROCESSO ............................................................................................... 70 5.4 ESTRUTURA DO PROCESSO ..................................................................................................... 72

5.4.1 Disciplina Requisitos Iniciais ............................................................................... 73 5.4.2 Disciplina Requisitos Finais ................................................................................. 77 5.4.3 Disciplina Projeto Arquitetural ............................................................................. 82 5.4.4 Disciplina Projeto Detalhado ................................................................................ 87 5.4.5 Disciplina Implementao .................................................................................... 92


6 EXEMPLO DE APLICAO DO PROCESSO ..................................................................... 97

6.1 INTRODUO ........................................................................................................................... 98 6.2 O FRAMEWORK DBSITTER-AS .............................................................................................. 98 6.3 O PROCESSO DE ANLISE E PROJETO PARA O DBSITTER-AS .............................................. 99

6.3.1 Iterao 1 Definio do sistema....................................................................... 102 6.3.2 Iterao 2 Anlise dos requisitos do sistema ................................................... 112 6.3.3 Iterao 3 Projeto da arquitetura global do sistema ......................................... 117 6.3.4 Iterao 4 Projeto detalhado do primeiro prottipo do sistema ....................... 128

6.4 CONSIDERAES FINAIS ...................................................................................................... 137

7 CONCLUSES E TRABALHOS FUTUROS ....................................................................... 139

7.1 CONCLUSO .......................................................................................................................... 140 7.2 CONTRIBUIES ................................................................................................................... 141 7.3 CONSIDERAES FINAIS E TRABALHOS FUTUROS ............................................................. 141

REFERNCIAS ................................................................................................................................ 144

APNDICE A .................................................................................................................................... 152

APNDICE B .................................................................................................................................... 177

ix

Lista de Figuras Figura 2-1 Genealogia de algumas metodologias AO. Adaptado de Henderson-Sellers & Giorgini (2005) ........................................................................................................................... 9 Figura 2-2 Diagrama de seqncia representando um protocolo de interao entre agentes. Adaptado de Odell et al.(2000)................................................................................................. 11 Figura 2-3 Diagrama de atividade representando atividades e papel de agentes. Adaptado de Odell et al.(2000) ...................................................................................................................... 12 Figura 2-4 Fases da Metodologia MAS-CommonKADS...................................................... 13 Figura 2-5 Fases da metodologia GAIA. Adaptado de FIPA (2008) .................................... 14 Figura 2-6 - Fases da metodologia MASE ............................................................................... 15 Figura 2-7 Fases da metodologia PASSI ............................................................................... 16 Figura 2-8 Fases da metodologia Tropos .............................................................................. 18 Figura 3-1 Exemplo do modelo SD ....................................................................................... 25 Figura 3-2 Exemplo do Diagrama SR ................................................................................... 26 Figura 3-3 Modelo SD na fase requisitos iniciais.................................................................. 28 Figura 3-4 - Modelo SR na fase de requisitos iniciais .............................................................. 28 Figura 3-5 Modelo SD na fase requisitos finais .................................................................... 29 Figura 3-6 Modelo SR na fase de requisitos finais ................................................................ 30 Figura 3-7 Diagrama de Arquitetura no estilo Joint Venture ................................................ 32 Figura 3-8 Classe Agente Coordenador................................................................................. 33 Figura 3-9 Diagrama de interaes entre os agentes ............................................................. 33 Figura 3-10 Diagrama de capacidades................................................................................... 34 Figura 3-11 Diagrama de planos ........................................................................................... 34 Figura 3-12 - O framework SIRA............................................................................................. 41 Figura 3-13 Metamodelo de agncia Categoria intencional ............................................... 44 Figura 3-14 Metamodelo de agncia Categoria interacional .............................................. 45 Figura 3-15 Definies de trabalho do processo de projeto detalhado.................................. 46 Figura 4-1 Modelo Cascata ................................................................................................... 52 Figura 4-2 Modelo evolucionrio .......................................................................................... 53 Figura 4-3 Modelo de processo iterativo e incremental ........................................................ 53 Figura 4-4 Modelo de processo em espiral ............................................................................ 55 Figura 4-5 SEP Processo de engenharia de software ......................................................... 56 Figura 4-6 Notao grfica usada em SPEM......................................................................... 59 Figura 4-7 Exemplos de diagramas de elementos de processos em SPEM........................... 60 Figura 5-1 Elementos do U-Tropos ........................................................................................ 66 Figura 5-2 Fases do Ciclo de Vida do Processo ..................................................................... 67 Figura 5-3 Iteraes do Ciclo de Vida do Processo................................................................ 69 Figura 5-4 Notao grfica de SPEM .................................................................................... 73 Figura 5-5 Pacote da Disciplina Requisitos Iniciais .............................................................. 73 Figura 5-6 Definio do trabalho dos Requisitos Iniciais ...................................................... 74 Figura 5-7 Atividades da disciplina Requisitos Iniciais ........................................................ 75 Figura 5-8 Produtos de trabalho da disciplina Requisitos Iniciais ........................................ 76 Figura 5-9 Pacote da Disciplina Requisitos Finais ................................................................ 78 Figura 5-10 Definio do trabalho dos requisitos finais ....................................................... 79 Figura 5-11 Atividades da disciplina Requisitos Finais ........................................................ 80 Figura 5-12 Pacote da Disciplina Projeto Arquitetural ......................................................... 83 Figura 5-13 Definio do trabalho do projeto arquitetural .................................................... 84

x

Figura 5-14 Atividades da disciplina Projeto arquitetural ..................................................... 85 Figura 5-15 Produtos de trabalho da disciplina Projeto Arquitetural .................................... 87 Figura 5-16 - Pacote da Disciplina Projeto Detalhado ............................................................. 88 Figura 5-17 Fluxo de trabalho do projeto detalhado ............................................................. 89 Figura 5-18 Atividades da disciplina Projeto detalhado ........................................................ 90 Figura 5-19 Produtos de trabalho do Projeto detalhado ........................................................ 91 Figura 5-20 Pacote da disciplina Implementao .................................................................. 92 Figura 5-21 Definio de trabalho da Implementao .......................................................... 93 Figura 5-22 Atividades da disciplina Implementao ........................................................... 94 Figura 5-23 Produtos de trabalho da disciplina Implementao ........................................... 94 Figura 6-1 Diagrama de ator Requisitos Iniciais .............................................................. 107 Figura 6-2 Diagrama de Metas Requisitos Iniciais .......................................................... 109 Figura 6-3 Diagrama de atores Requisitos finais ............................................................. 112 Figura 6-4 Diagrama de Metas Requisitos Finais ............................................................ 117 Figura 6-5 Interaes entre os papis .................................................................................. 120 Figura 6-6 Seleo de estilo arquitetural ............................................................................. 122 Figura 6-7 Interaes do estilo arquitetural Joint-Venture .................................................. 122 Figura 6-8 Modelo arquitetural do DBSitter-AS ................................................................. 128 Figura 6-9 Diagrama de metas para os componentes da arquitetura ................................... 130 Figura 6-10 Diagrama arquitetural ...................................................................................... 132 Figura 6-11 Diagrama de comunicao ............................................................................... 133 Figura 6-12 Diagrama intencional ....................................................................................... 134 Figura 6-13 Diagrama de ambiente ..................................................................................... 135 Figura 6-14 Diagrama racional ............................................................................................ 136 Figura 6-15 Diagrama de planos ......................................................................................... 136

xi

Lista de Tabelas Tabela 2-1 Metodologias para desenvolvimento orientado a agentes ................................... 19 Tabela 3-1 Catlogo de estilos arquiteturais.......................................................................... 31 Tabela 3-2 Diferenas entre o i* usado no Tropos02 e Tropos04 ...................................... 37 Tabela 5-1 Elementos dos modelos i* nas disciplinas de requisitos ...................................... 81 Tabela 6-1 Iteraes definidas para o desenvolvimento do DBSitter-AS .............................. 101 Tabela 6-2 Regras para construo do modelo i* propostas pelo PRIM............................ 103 Tabela 6-3 Lista de partes interessadas ............................................................................... 104 Tabela 6-4 Atividades dos atores ........................................................................................ 105 Tabela 6-5 DIS para a atividade Solucionar problemas para atender s necessidades dos clientes .................................................................................................................................... 106 Tabela 6-6 Checagem da transformao do DIS no modelo i* ........................................... 110 Tabela 6-7 DIS para delimitar aes do sistema DBSitter-AS ............................................ 111 Tabela 6-8 DIS para Resolver falhas em objetos lgico ..................................................... 114 Tabela 6-9 DIS para Notificar ao executada .................................................................... 115 Tabela 6-10 Especificao dos papis ................................................................................. 119 Tabela 6-11 Matriz de interaes ........................................................................................ 120 Tabela 6-12 Medida do grau de centralidade ...................................................................... 123 Tabela 6-13 Medida do grau de proximidade dos papis .................................................... 123 Tabela 6-14 Grau de similaridade dos papis ...................................................................... 124 Tabela 6-15 - Medida do grau de centralidade do estilo arquitetural joint-venture ............... 125 Tabela 6-16 - Medida do grau de proximidade do estilo arquitetural Joint-venture .............. 125 Tabela 6-17 Correlao de centralidade entre subgrupos do DBSitter-AS e o Joint-Venture ................................................................................................................................................ 126 Tabela 6-18 Similaridade estrutural entre os subgrupos e o estilo arquitetural................... 126 Tabela 6-19 Correlao de similaridade do exemplo DBSitter-AS .................................... 127 Tabela 6-20 Mapeamento dos elementos do diagrama da Figura 6-9 em i* para UML ..... 131 Tabela A-1 - Detalhamento da atividade Identificar as partes interessadas e suas intenes ... ................................................................................................................................................ 153 Tabela A-2 - Detalhamento da atividade Identificar relacionamentos entre as partes interessadas ........................................................................................................................... 153 Tabela A-3 - Detalhamento da atividade Analisar as dependncias estratgicas ................ 154 Tabela A-4 - Detalhamento da atividade Identificar as atividades detalhadas das partes interessadas ........................................................................................................................... 154 Tabela A-5 - Detalhamento da atividade Realizar anlise orientada a metas ..................... 155 Tabela A-6 - Detalhamento da atividade Realizar anlise meio-fim ................................... 156 Tabela A-7 - Detalhamento da atividade Realizar a anlise da influncia das tarefas/planos ............................................................................................................................................... 156 Tabela A-8 - Detalhamento da atividade Validar os modelos propostos ............................. 156 Tabela A-9 Detalhamento da atividade Elicitar dependncias dos atores do mundo com o sistema .................................................................................................................................. 158 Tabela A-10 Detalhamento da atividade Analisar as dependncias estratgicas do ator sistema ................................................................................................................................... 159 Tabela A-11 Detalhamento da atividade Identificar meios para obter as intenes do ator-sistema ................................................................................................................................... 159 Tabela A-12 Detalhamento da atividade Realizar anlise orientada a metas ................... 159 Tabela A-13 Detalhamento da atividade Realizar anlise meio-fim ................................ 160

xii

Tabela A-14 Detalhamento da atividade Realizar anlise da influncia dos planos ......... 160 Tabela A-15 - Detalhamento da atividade Validar os modelos propostos ............................ 161 Tabela A-16 - Detalhamento da atividade Identificar papis ............................................... 163 Tabela A-17 - Detalhamento da atividade Identificar dependncias e relaes entre os papis ................................................................................................................................................ 163 Tabela A-18 - Detalhamento da atividade Identificar normas da organizao ..................... 163 Tabela A-19 - Detalhamento da atividade Analisar estilos arquiteturais .............................. 164 Tabela A-20 - Detalhamento da atividade Selecionar um estilo arquitetural ....................... 164 Tabela A-21 - Detalhamento da atividade Agrupar papis a subgrupos ............................... 165 Tabela A-22 - Detalhamento da atividade Analisar a correlao entre subgrupos e estilo arquitetural ............................................................................................................................ 166 Tabela A-23 - Detalhamento da atividade Mapear subgrupos a componentes do estilo arquitetural ............................................................................................................................ 166 Tabela A-24 - Detalhamento da atividade Validar os modelos propostos ........................... 167 Tabela A-25 Detalhamento da atividade Mapear i* para modelos em UML ................... 169 Tabela A-26 - Detalhamento da atividade Modelar a arquitetura ......................................... 169 Tabela A-27 - Detalhamento da atividade Modelar a comunicao dos atores .................... 169 Tabela A-28 Detalhamento da atividade Modelar as intenes ......................................... 170 Tabela A-29 Detalhamento da atividade Modelar o ambiente .......................................... 170 Tabela A-30 - Detalhamento da atividade Modelar o raciocnio para os atores ................... 171 Tabela A-31 - Detalhamento da atividade Modelar a execuo dos planos ......................... 171 Tabela A-32 - Detalhamento da atividade Analisar a capacidade dos atores ....................... 171 Tabela A-33 - Detalhamento da atividade Selecionar padres sociais para o sistema ......... 172 Tabela A-34 - Detalhamento da atividade Aplicar padres sociais ao projeto de agentes ... 172 Tabela A-35 - Detalhamento da atividade Validar modelos ................................................. 173 Tabela A-36 - Detalhamento da atividade Preparar ambiente de implementao ................ 174 Tabela A-37 - Detalhamento da atividade Codificar os agentes ........................................... 175 Tabela A-38 - Detalhamento da atividade Gerar primeira verso do SMA .......................... 175 Tabela A-39 - Detalhamento da atividade Integrar incrementos a verso existente ............. 175

xiii

Lista de Abreviaturas ADL Architectural Description Language

AIP - Agent Interation Protocol

AO - Orientado a agentes

AOSE Agent Oriented Software Engineering

AUML - Agent UML

BDI - Belief Desire Intention

CAME - Computer aided method engineering

CAPE - Computer aided process engineering

CASE - Computer aided software engineering

DIS - Detailed Interaction Script

FIPA - Foundation for Intelligent Physical Agents

LEL - Lexicon extended language

MSC - Message Sequence Charts

OMG - Object Management Group, Inc

OMT - Object-Modeling Technique

OO - Orientado a objetos

OPF Open Proccess Framework

PRiM - Process Reengineering i* Methodology

RDD - Responsibility Driving Design

RiSD - Reduced i* SD models

RUP - Rational Unified Process

SD - Strategical Dependency

SDL - Specification and Description Language

SDSituation - Strategical Dependency Situation

SEP - Software Engineering Process

SIRA - Systematic Integration between Requirements and Architecture

SMA - Sistemas Multiagentes

SPEM - Software Process Engineering Metamodel

SR - Strategical Rationale

UML - Unified Modeling Language

Captulo 1 Introduo

1

Captulo 1 - Introduo

Neste captulo so apresentadas as principais motivaes para realizao desta dissertao e a definio do escopo/contexto em que este trabalho de pesquisa est inserido. Em seguida so definidos os objetivos do trabalho, e finalmente a sua estrutura.

1 Introduo

Captulo 1 Introduo

2

1.1 Motivao

A abordagem de desenvolvimento de softwares orientado a agentes tem sido bastante

explorada. Muitos trabalhos tm sido realizados para criao de processos, metodologias e

tcnicas que permitam a modelagem e construo destes softwares. Isto tem acontecido

devido natureza de problemas a qual o uso de agentes indicado: Aplicaes que requerem

sistemas que possam tomar decises para satisfazer seus objetivos (e.g. sistemas de

recuperao de falhas, controle de trfego, diagnstico, etc.). Um agente um sistema de

computador situado em algum ambiente e que capaz de aes autnomas neste ambiente

para atingir seus objetivos. O agente inteligente deve operar robustamente em ambientes

abertos, imprevisveis, mutveis e com aes que possam falhar [Wooldridge, 2002]. Agentes

no so sistemas isolados. Em muitas situaes eles coexistem e interagem com outros

agentes. Um sistema que consiste de um grupo de agentes que podem interagir com outros

chamado Sistema Multiagentes (SMA). Tropos [Castro; Kolp & Mylopoulos, 2002] uma

das abordagens populares para desenvolvimento de software orientado a agentes e tem sido

objeto de pesquisa do laboratrio de engenharia de requisitos, onde esta dissertao

desenvolvida.

Tropos adota os conceitos oferecidos pelo framework i* [Yu, 1995], tais como ator,

agente, posio e papel assim como as dependncias sociais entre os atores, incluindo

dependncias de metas, tarefas e recursos. Ela usa estes conceitos no somente para modelar a

fase de anlise de requisitos, mas tambm as fases de arquitetura e projeto detalhado. Tropos

foi criado em 2000 [Mylopoulos & Castro, 2000]. Esta proposta original foi evoluda e

existem as verses [Castro; Kolp & Mylopoulos, 2002] e [Bresciani et al., 2004].

Tropos tem sido muito estudada por pesquisadores e desenvolvedores de software

multiagentes e diversos trabalhos1 tm sido gerados para incluir melhorias em sua proposta

inicial. Porm estes trabalhos tm sido construdos em formatos e notaes diferentes

dificultando o seu uso na comunidade de desenvolvimento de Sistemas Multiagentes (SMA).

Os desenvolvedores tm um esforo maior em unificar e integrar todos estes trabalhos, o que

compromete a qualidade dos produtos gerados. Alm disso, no existe um processo

padronizado que oriente as suas atividades, produzindo tambm um esforo extra na

organizao do trabalho, o que pode ocasionar perda de produtividade e retrabalho. Neste

1 www.troposproject.net

Captulo 1 Introduo

3

contexto, esta dissertao de mestrado prope um processo unificado, chamado U-Tropos,

que de forma iterativa e incremental, define um conjunto de atividades para guiar o

desenvolvimento de sistemas multiagentes.

1.2 Escopo

O foco principal desta dissertao a proposta Tropos e suas variantes, que prope uma

metodologia de desenvolvimento centrada nos conceitos de requisitos iniciais e suporta as

seguintes fases de desenvolvimento de um software: Requisitos Iniciais, Requisitos Finais,

Projeto Arquitetural, Projeto Detalhado e Implementao. Vale salientar que existem duas

verses muito populares de Tropos que esto sendo usadas em diferentes grupos de pesquisas.

Estas verses apresentam diferenas em suas abordagens. Alm disto, vrias tcnicas de

melhorias que foram propostas recentemente ainda no foram incorporadas ao Tropos. Uma

dificuldade para adoo de Tropos a inexistncia de um modelo de processo de software

explcito, que oriente o desenvolvimento de sistemas, conforme as melhores prticas de

Tropos e os recentes avanos.

O escopo desta dissertao envolve uma anlise das duas verses do Tropos [Castro;

Kolp & Mylopoulos, 2002] e [Bresciani et al., 2004] para extrao das melhores prticas com

o objetivo de formar um novo processo de desenvolvimento baseado em Tropos. Alm disso,

algumas tcnicas desenvolvidas para detalhar as atividades de requisitos, projeto arquitetural e

projeto detalhados sero acrescentadas. Por ltimo, proposta a especificao de um modelo

de processo em uma linguagem padronizada (SPEM [SPEM, 2007]) para orientar o

desenvolvimento de sistemas multiagentes. O processo sugere atividades de gerenciamento,

verificao e suporte, mas no faz parte do escopo desta dissertao o detalhamento destas

atividades.

1.3 Objetivos

O objetivo principal desta dissertao especificar um processo (U-Tropos) para organizar as

fases de requisitos, projeto arquitetural e projeto detalhado da abordagem Tropos unificando

as atividades extradas das suas verses com tcnicas recentes que possibilitam maior

detalhamento destas atividades.

Os objetivos especficos para cumprir com a proposta desta dissertao so relacionados

a seguir:

Captulo 1 Introduo

4

Analisar as verses da abordagem Tropos para identificar uma seqncia lgica de

atividades para o processo.

Analisar as tcnicas que estendem as fases de requisitos, projeto arquitetural e projeto

detalhado para identificar como estas podem contribuir para detalhamento da

especificao do processo.

Identificar guias e diretrizes que contribuam para tornar mais clara as tcnicas,

ferramentas e modelos utilizados na metodologia.

Descrever um modelo de processo iterativo e incremental para o desenvolvimento das

atividades usando a linguagem de especificao SPEM.

Exemplificar o uso do processo proposto em um sistema multiagente (DBSitter-AS).

1.4 Estrutura da dissertao

Alm deste captulo introdutrio esta dissertao contm mais seis captulos:

Captulo 2 Desenvolvimento de Software Orientado a Agentes: Neste captulo so

apresentados os conceitos da engenharia de software orientada a agentes e a motivao para o

uso de agentes e sistemas multiagentes. Em seguida so revisadas algumas metodologias

atualmente em uso para dar apoio ao desenvolvimento de sistemas multiagentes.

Captulo 3 O projeto Tropos: o projeto Tropos prope uma das abordagens mais completas

para o desenvolvimento de sistemas multiagentes. Este captulo apresenta a viso geral do

Tropos, suas fases, alguns conceitos bsicos e as tcnicas que compe a proposta. Tambm

so apresentadas novas tcnicas e diretrizes que surgiram com o objetivo de melhorar o

trabalho original.

Captulo 4 - Processo de desenvolvimento de Software: Neste captulo so apresentados os

conceitos e modelos de processos usados para o desenvolvimento de software. Ateno

especial dada aos modelos de processo para desenvolvimento de sistemas multiagentes. O

SPEM, que uma abordagem bastante popular para descrio de processos de

desenvolvimento de software, tambm apresentado. Por fim, indicado como Tropos

poder ser descrito atravs de SPEM.

Captulo 5 U-Tropos: Nesse captulo apresentada a principal contribuio desta

dissertao, o processo U-Tropos. O U-Tropos um processo interativo e incremental

Captulo 1 Introduo

5

especificado em SPEM que integra diversas tcnicas, mtodos e diretrizes s atividades da

abordagem Tropos.

Captulo 6 - Exemplo de aplicao do processo: Esse captulo tem o objetivo de apresentar

um exemplo para uso prtico da proposta desta dissertao. Ser utilizado o desenvolvimento

do sistema multiagentes DBSitter-AS, que tem como objetivo a deteco e correo autnoma

de falhas em banco de dados. Nesse contexto, apresentado um guia para a aplicao do

processo dividido em iteraes que geram os produtos de trabalho das atividades de

requisitos, projeto arquitetural e projeto detalhado.

Captulo 7 - Concluses e trabalhos futuros: Neste captulo so apresentadas as consideraes

finais sobre o desenvolvimento deste trabalho, assim como as principais contribuies,

abrangncia e limitaes encontradas. Sero mostrados alguns trabalhos futuros que

complementem esta proposta e que possam direcionar futuras pesquisas nesta rea.

Captulo 2 Desenvolvimento de Software Orientado a Agentes

6

Captulo 2 - Desenvolvimento de Software Orientado a Agentes

A engenharia de software orientada a agentes tem sido objeto de vrias pesquisas e aplicaes para o desenvolvimento de sistemas complexos que exigem caractersticas como autonomia e aprendizagem. Este captulo apresenta os conceitos e a motivao para o uso de agentes e sistemas multiagente e em seguida, as metodologias atualmente em uso para apoiar o desenvolvimento de sistemas multiagentes.

2 Desenvolvimento de Software Orientado a Agentes


7

2.1 Introduo

Os sistemas de computadores da atualidade, geralmente so grandes sistemas distribudos e

interconectados por redes de computadores. Est se tornando raro encontrar sistemas

comerciais ou acadmicos que no sejam conectados a internet. As tarefas que os homens so

capazes de automatizar e delegar aos computadores se tornam cada vez mais complexas.

Quanto mais complexa uma tarefa, mais existe a tendncia desta ser delegada a um sistema de

computadores. Mas para que esta atribuio ocorra com segurana, necessrio atribuir aos

sistemas conceitos e metforas que refletem como os humanos entendem o mundo. Isto

implica que os sistemas de computadores devem ter a habilidade de operar independente da

interveno humana e a habilidade de representar interesses humanos especficos quando

interagindo com pessoas ou outros sistemas.

A partir deste contexto, surgiu um novo campo na cincia da computao: Os sistemas

orientados a agentes [Wooldridge, 2002]. Um agente um sistema de computador situado em

algum ambiente, e que capaz de aes autnomas neste ambiente para alcanar os seus

objetivos. Um agente no tem controle completo sobre o ambiente, ele tem apenas um

controle parcial naquilo que ele pode influenciar. Uma agente monitora seu ambiente e tem

um conjunto de aes que ele pode executar. Estas aes so as capacidades do agente de

modificar o seu ambiente. Cada ao tem precondies que determinam em quais situaes as

aes podem ser executadas. Um agente considerado inteligente quando possui

caractersticas como reatividade, pro atividade e habilidade social.

Um sistema multiagentes um sistema computacional que consiste de um conjunto de

agentes que interagem entre si ou trabalham juntamente para atingir suas metas. Em um

sistema multiagentes, os agentes se relacionam atravs de delegao de tarefas, transferncias

de dados, compromissos, sincronizao de aes, etc. Estes relacionamentos so possveis

dentro de uma organizao que prover suporte para distribuio de tarefas, dados, recursos e a

coordenao de aes [Ferber, 1999].

A tecnologia de agentes saiu da esfera de pesquisas em universidades e laboratrios e

est sendo aplicada em diversas reas comerciais, industriais e de entretenimento2. Existem

diversos aplicativos em uso e cada vez mais est se usando esta tecnologia para

2 Veja tendncias em: AAMAS'08: Proceedings of the 7th international joint conference on Autonomous agents and multiagent systems: industrial track. Publisher International Foundation for Autonomous Agents and Multiagent Systems, Richland, SC. Estoril, Portugal. 2008.


8

desenvolvimento de sistemas complexos. As principais reas de aplicao na indstria so:

Fabricao, Controle de processo, Telecomunicaes, Controle de trfego areo e Sistemas de

transportes. No comrcio, pode ser citada a Gerncia de informao, o Comrcio eletrnico e

a Gerncia de processo de negcio como as principais aplicaes que fazem uso de agentes.

Na rea de entretenimento, os agentes so usados em jogos, cinema interativo e realidade

virtual. Tambm so teis na rea mdica para monitoramento de pacientes e planos de sade.

Um paradigma de desenvolvimento de sistemas para se tornar mais estabelecido na

comunidade da Cincia da Computao deve prover tecnologias para suportar o seu

desenvolvimento. Muitas contribuies tm sido feitas para a engenharia de software

orientada a agentes. Existe uma grande quantidade de metodologias (e.g. GAIA [Zambonelli;

Jennings & Wooldridge, 2003], Tropos [Mylopoulos & Castro, 2000], MASE [Wood &

DeLoach, 2001]), framework de desenvolvimento (e.g. JACK [JACK, 2007], JADE

[Bellifemine et al., 2003], JADEX [Pokahr; Braubach & Lamersdorf, 2005], Whitesteins

Living Systems [Whitestein, 2008]) e aplicaes do mundo real, como por exemplo, solues

providas pelo Whitestein Information Technology Group [Whitestein, 2008].

O objetivo deste captulo estudar as metodologias usadas na engenharia de sistemas

orientados a agentes. A prxima seo apresenta as principais metodologias e so citadas

algumas ferramentas de desenvolvimento usadas por estas metodologias.

2.2 Metodologias para desenvolvimento de SMA

Vrias metodologias para o desenvolvimento de sistemas orientados a agentes tm sido

propostas nos ltimos anos. Estas podem ser divididas em duas correntes: As metodologias

inspiradas ou adaptadas do desenvolvimento orientado a objetos e as metodologias que

adaptam a engenharia de conhecimento ou outras tcnicas.

Henderson-Sellers & Giorgini (2005) fizeram um estudo da genealogia das

metodologias orientadas a agentes mais conhecidas (Figura 2-1). Neste estudo identificou-se

que vrias metodologias reconhecem uma descendncia direta de mtodos orientados a

objetos. Em particular, MASE [Wood & DeLoach, 2000] recebe influncia de Kendall,

Malkoun & Jiang (1995) e herda muitas caractersticas de AAII [Kinny; Georgeff & Rao,

1996]. O-MaSE [DeLoach, 2006] uma extenso de MaSE acrescentando conceitos de

interao e organizao. AAII, por sua vez foi influenciada pela OMT [Rumbaugh et al.,

1991] que uma metodologia orientada a objetos. Da mesma forma a Metodologia OO

Fusion [Coleman et al., 1994] foi uma forte influncia para o projeto de GAIA [Zambonelli;


9

Jennings & Wooldridge, 2003], que por sua vez influenciou SODA [Omicini, 2000]. Duas

outras abordagens tm sido usadas como base para extenses orientadas a agentes. O RUP

[Kruchten, 1999] influenciou ADELFE [Bernon et al., 2002] e MESSAGE [Caire et al.,

2001]. Prometheus [Padgham & Winikoff, 2002] tambm usa diagramas e conceitos OO

quando estes so compatveis com o paradigma orientado a agentes. E PASSI [Cossentino &

Potts, 2002] unifica idias de OO e SMA, usando UML como sua principal notao. MAS-

CommonKADS [Iglesias et al., 1998] baseada em conceitos da inteligncia artificial,

embora ainda assuma que tem influncia da OMT.

Algumas metodologias no reconhecem qualquer influncia da orientao a objetos. Por

exemplo, a metodologia Tropos [Mylopoulos & Castro, 2000] fortemente influenciada pelos

conceitos do i* [Yu, 1995]. Outras abordagens no assumem descendncia direta da

metodologia OO, como por exemplo, Nemo [Huget, 2002], MASSIVE [Lind, 2000],

Cassiopeia [Collinot; Drogoul & Benhamou, 1996]. A abordagem OPEN [Graham;

Henderson-Sellers & Younessi, 1997] para o desenvolvimento OO tem tambm sido

estendida para suportar agentes. Esta abordagem chamada Open / Agents [Debenham &

Henderson-Sellers, 2002].

Figura 2-1 Genealogia de algumas metodologias AO. Adaptado de Henderson-Sellers & Giorgini (2005)

Recentemente, o desenvolvimento orientado a agentes tem sido influenciado pelas

prticas do desenvolvimento gil [Cockburn, 2000]. A abordagem Agile-PASSI [Chella et al.,

2004] uma verso gil de PASSI. A metodologia SADAAM [Clynch & Collier, 2007]

tambm utiliza tcnicas derivadas de uma variedade de mtodos geis incluindo o manifesto


10

gil [AGILE, 2008], a modelagem gil [Ambler, 2008], Extreme Programming [Beck, 1999]

e desenvolvimento orientado a testes (TDD - Test-Driven Development) [Beck, 2003].

Em seguida so apresentadas as caractersticas principais de algumas tcnicas e

metodologias. Inicia-se pela linguagem de modelagem Agent UML (AUML) que uma

extenso para a UML e muito usada como notao em muitas metodologias orientadas a

agentes. Depois so apresentadas brevemente algumas metodologias: MAS-CommonKADS

por ter origem na engenharia do conhecimento e inteligncia artificial. Gaia e MaSE so

metodologias que cobrem as fases de anlise e projeto e se tornaram muito populares, sendo

citadas como referncia em vrios trabalhos de pesquisas em engenharia de software

orientada a agentes. PASSI e Tropos tm a caracterstica de abordar todo o ciclo de

desenvolvimento desde os requisitos at a implementao. Para a descrio grfica das fases

das diversas metodologias a seguir, ser utilizada a notao SPEM [SPEM, 2007].

2.2.1 AUML (Agent UML)

Os diagramas de UML (Unified Modelling Language) [UML, 2007] foram projetados para

suportar a descrio dos aspectos inerentes a orientao a objetos. Em Odell et al. (2000), um

agente uma extenso do conceito de objeto, o que permite explorar a UML para representar

caractersticas do paradigma Orientado a Agentes. Odell et al. (2000) afirma que a UML

insuficiente para modelagem de agentes e sistemas baseados em agentes e prope extenses

UML, criando assim a AUML (Agent UML).

A AUML prope um subconjunto de extenses para a UML com o objetivo de

especificar protocolos de interao de agentes e outras noes baseadas em agentes. Um

protocolo de interao de agentes (AIP Agent Interation Protocol) descreve um padro de

comunicao como uma seqencia de mensagens entre agentes e as restries do contedo

destas mensagens. A especificao de AIP resolve problemas na fase de anlise e projeto de

sistemas e prover uma semntica formal e notao grfica amigvel.

Usam-se pacotes da UML para representar templates para o AIP com o objetivo de

focar na finalidade da interao e no na ordem precisa das mensagens trocadas. Diagramas

de seqncia (Figura 2-2) so usados para modelar elementos bsicos de comunicao entre

agentes. Por exemplo, a Figura 2-2 mostra um protocolo de interao genrico, modelado na

forma de um template. So indicados os papis dos agentes (Iniciador e Participante),

possveis restries durante as interaes (e.g. a existncia de prazos) e as aes de

comunicao presentes no protocolo de comunicao (e.g. chamada-de-proposta, recusa, etc).


11

Algumas extenses so adicionadas para expressar os agentes e seus papis, atos de

comunicao de agentes e threads de interao so representados para suportar concorrncia.

Diagramas de colaborao tambm podem ser usados para descrever um padro de interao

entre agentes.

Figura 2-2 Diagrama de seqncia representando um protocolo de interao entre agentes. Adaptado de Odell et al.(2000)

O diagrama de atividade usado para especificar semnticas de thread de

processamento mais claras expressando as operaes e os eventos que as iniciam. Por

exemplo, na Figura 2-3, o Agente Vendedor aceita, monta, envia e fecha o pedido. A

execuo comea no estado de partida, representado por um crculo vazado e termina no

estado final, representado por um crculo preenchido. O diagrama de atividade

especialmente til em protocolos complexos que envolvam processamento concorrente.

Tambm pode ser usado para expressar o processamento interno de um agente simples. O

diagrama de estado geralmente no usado para expressar AIP por que ele centrado em

estados e no em agentes (ou processos). Contudo um agente poderia embutir as restries de

transio de estados garantindo que as restries do protocolo de interao sejam encontradas.

Portanto, ele mais apropriado para expressar o comportamento interno do agente.

A AUML tambm adiciona uma forma de representar papis de agentes aos modelos

UML existentes. Os diagramas de seqncia, colaborao e atividades recebem estas

mudanas. Os modelos da UML original tambm poderiam ser utilizados, mas ficariam


12

complexos e ilegveis. Diagramas de distribuio (implantao) tambm podem ser usados e

estendidos para expressar mobilidade de agentes.

Figura 2-3 Diagrama de atividade representando atividades e papel de agentes. Adaptado de Odell et al.(2000)

2.2.2 MAS-CommonKADS

MAS-CommonKADS [Iglesias, 1998] uma extenso da metodologia CommonKADS

[Schreiber et al., 1999] com o acrscimo de caractersticas relevantes aos sistemas

multiagentes. O CommonKADS uma metodologia para desenvolvimento de sistemas

baseados em conhecimento. O MAS-CommonKADS adicionou ao CommonKADS tcnicas

de metodologias OO tais como a OMT [Rumbaugh et al., 1991] e RDD (Responsibility

Driving Design) [Wirfs-Brock; Wilkerson & Wiener, 1990] e tcnicas da engenharia de

protocolos para descrever protocolos de agentes tais como SDL (Specification and

Description Language) [Belina & Hogrefe, 1999] e MSC (Message Sequence Charts)

[Rudolph; Grabowski & Graubmann,1996]. O modelo de processo da metodologia combina a

abordagem orientada a riscos com a abordagem orientada a componentes.

MAS-CommonKADS segue o modelo de ciclo de vida proposto por CommonKADS e

engloba as seguintes fases (Figura 2-4): (i) fase de Conceituao, que envolve as atividades de

elicitao dos requisitos e a gerao de casos de uso para descrever os requisitos informais e

testar o sistema; (ii) fase de Anlise, que determina os requisitos do sistema partindo do

enunciado do problema. So gerados cinco modelos na fase de anlise: o modelo de

organizao usado para analisar a organizao humana em que o sistema ser inserido e

descreve a organizao dos agentes de sistema e sua relao com o meio; o modelo de tarefas

descreve as tarefas que os agentes realizam, os objetivos de cada tarefa, sua decomposio e

os mtodos de resoluo de problemas para resolver cada objetivo; o modelo de agentes

especifica a capacidade de raciocnio dos agentes, suas habilidades, servios providos,

sensores, grupos de agentes a que pertence e a classe de agente. Um agente pode ser um

agente humano, software, ou qualquer entidade capaz de empregar uma linguagem de

comunicao de agentes; o modelo de comunicao descreve as interaes entre um agente


13

humano e um agente software; o modelo de coordenao descreve as interaes entre agentes

de software; e o modelo de experincia descreve o conhecimento necessrio aos agentes para

atingir seus objetivos; (iii) fase de Projeto, que determina a arquitetura da rede multiagentes e

de cada agente. Utiliza o modelo de projeto que descreve a arquitetura e o projeto do sistema

multiagentes como passo prvio a sua implementao; na (iv) fase de Codificao cada agente

implementado e testado e na fase de (v) Integrao, o sistema completo testado.

Figura 2-4 Fases da Metodologia MAS-CommonKADS

2.2.3 GAIA

A metodologia Gaia foi criada por Wooldrige, Jennings & Kinny (1999) como uma

metodologia especfica para o desenvolvimento de sistemas baseados em agentes. Uma verso

mais recente foi proposta por Zambonelli; Jennings & Wooldridge (2003). Em Gaia o sistema

modelado como uma sociedade ou organizao de agentes. Abaixo da organizao esto os

papis que os agentes podem assumir dentro desta. Um papel definido por trs atributos:

responsabilidades, permisses e protocolos. As responsabilidades determinam as funes que

cada papel executa. Existem dois tipos de responsabilidades: propriedades de progresso (do

ingls liveness), que descrevem as aes e os estados que os agentes devem buscar, de acordo

com as condies do ambiente; e propriedades de segurana (do ingls safety), que indicam os

estados que os agentes devem manter continuamente. As permisses so direitos dos papis

sobre determinados recursos.


14

A metodologia compreende duas fases (Figura 2-5): a primeira a Anlise, que utiliza

os conceitos acima e modela os papis e as interaes entre estes papis. No processo de

anlise, primeiramente identificam-se os papis do sistema gerando um prottipo do modelo

de papis. Em seguida, para cada papel, os protocolos (padres de interaes) associados so

identificados e documentados gerando o modelo de interaes. Usando-se o modelo de

interaes, elabora o modelo definitivo de papis. Estes trs primeiros passos so repetidos

at chegar a um nvel satisfatrio de anlise; a segunda fase de Gaia o Projeto, que tem

como objetivo transformar os modelos abstratos da anlise em modelos suficientemente

detalhados para aplicao em outras metodologias de desenvolvimento de software, como as

orientadas a objetos. Gaia no sugere que a fase de implementao use ferramentas

especficas para agentes. O projeto constitudo pela construo de trs modelos: modelo de

agentes, modelo de servios e modelo de conhecimento. O modelo de agentes documenta os

agentes e papis que sero usados pelo sistema em construo e as instncias de agentes que

podem surgir em tempo de execuo. Utiliza-se um diagrama especfico para visualizar os

papis que o agente executa. O modelo de servios descreve as funes desempenhadas para

cada papel de agente, especificando suas principais propriedades. O modelo de conhecimento

define a comunicao entre os diversos tipos de agentes.

Figura 2-5 Fases da metodologia GAIA. Adaptado de FIPA (2008)

2.2.4 MaSE e O-MaSE

A Metodologia MaSE (Multiagent Systems Engineering Methodology) [Wood & DeLoach,

2001] similar a Gaia em sua generalidade e domnio da aplicao. Porm MaSE fornece um

suporte criao automtica de cdigo para agentes atravs de suas ferramentas. A primeira

verso de MaSE apresentava algumas deficincias, tais como, a falta de um mecanismo para


15

interao dos agentes com o ambiente e o uso de organizaes de tamanho fixo. Para

solucionar estas deficincias, MaSE foi estendida com conceitos organizacionais originando

uma nova verso chamada O-MaSE [DeLoach, 2006].

O-MaSE composta de trs fases principais (Figura 2-6): inicia com a fase de

Requisitos, onde os requisitos so documentados em um Diagrama hierrquico de metas

representado por um modelo de classes da UML; a segunda fase a Anlise, onde a

organizao definida no Modelo organizacional usando diagramas de caso de uso, seqncia

e atividades da UML. A ontologia usada na organizao tambm capturada e documentada

em um Modelo de domnio. A identificao dos papis define o conjunto inicial de papis do

sistema que so representados no Modelo de papis; a ltima fase o Projeto, onde os

modelos da anlise so transformados em construes utilizveis para a implementao de um

sistema multiagente. A fase do Projeto composta por quatro passos: criao das classes de

agentes, projeto dos protocolos de interao, definio dos planos e da poltica da

organizao. Os Modelos de classes de agentes so definidos por meio de papis executados,

capacidades ou servios fornecidos. Os Modelos de protocolos so usados para definir os

protocolos de passagem de mensagem entre classes de agentes. O comportamento dos agentes

definido usando Modelo de planos. O Modelo de capacidades inclui as capacidades, aes e

operaes realizadas pelos agentes. Por fim, o Modelo de poltica define um conjunto de

regras especificadas formalmente para descrever como uma organizao se comporta em

situaes particulares. O projeto do sistema implica na definio do sistema a ser

implementado, uma vez que j foram definidos os diagramas para identificar as caractersticas

dos agentes no sistema. O ambiente de desenvolvimento AgentTool III (ou aT3)3 utilizado

para apoiar o processo de anlise, projeto e implementao do sistema.

Figura 2-6 - Fases da metodologia MASE

3 http://agenttool.projects.cis.ksu.edu/


16

2.2.5 PASSI

PASSI (Process for Agent Societies Specification and Implementation) [Cossentino & Potts,

2002] uma metodologia para desenvolver sociedades de sistemas multiagentes, que prope

atividades para todas as fases desde os requisitos at a codificao. Ela adota conceitos tanto

da orientao a objetos, quanto da inteligncia artificial e usa a UML como notao.

Est dividida em cinco fases e doze passos para o processo de construir sistemas

multiagentes (Figura 2-7): (i) a fase de requisitos responsvel pela definio do modelo de

requisitos do sistema, que produz descries de funcionalidades baseadas em caso de uso e

adaptaes de acordo com o paradigma de agentes. Esta fase subdividida em descrio do

domnio, identificao de agentes, identificao de papis e especificao de tarefas; (ii) a

fase sociedade de agentes cria o modelo de sociedade de agentes. Este modelo representa as

interaes sociais e dependncias entre os agentes que executam uma parte da soluo. A fase

subdividida em descrio da ontologia, descrio dos papis e descrio de protocolos; (iii)

a fase de implementao gera o modelo de implementao dos agentes, que modela uma

soluo em termos de classes e mtodos. Est dividida em dois passos que so a definio da

estrutura dos agentes e a descrio do comportamento dos agentes; (iv) a fase codificao

modela a soluo no nvel de codificao e tem os passos reuso de cdigo e concluso do

cdigo; e (v) a fase de implantao (distribuio) gera o modelo de implantao que modela a

distribuio de partes do sistema em unidades de processamento de hardware e composto de

um nico passo que a configurao da implantao.

Figura 2-7 Fases da metodologia PASSI


17

A abordagem Agile-PASSI [Chella et al., 2004] uma verso gil de PASSI. O Agile

PASSI acrescenta uma fase de testes conforme as prticas do desenvolvimento gil, que

sugere que os testes devem comear o mais cedo possvel dentro do processo de

desenvolvimento, j sendo definido no planejamento dos requisitos do sistema.

2.2.6 TROPOS

A metodologia Tropos [Mylopoulos & Castro, 2000] [Castro; Kolp & Mylopoulos, 2002]

[Bresciani et al., 2004] orientada a requisitos no sentido que baseada em conceitos usados

durante a fase de anlise de requisitos iniciais. O objetivo de usar conceitos da engenharia de

requisitos reduzir a incompatibilidade entre o sistema e seu ambiente. Para este fim, foram

utilizados os conceitos oferecidos pelo framework i* [Yu 1995]. Tropos est descrita em duas

verses que sero mais detalhadas no Captulo 4.

Tropos dividido em cinco fases de desenvolvimento de software (Figura 2-8): (i)

requisitos iniciais, cujo objetivo o entendimento de um problema a partir da anlise e estudo

da configurao organizacional onde o problema est inserido. Produz o modelo de

dependncias estratgica para descrever a rede de relacionamentos entre os atores e o modelo

de raciocnio estratgico para justificar o raciocnio que cada ator tem sobre seu

relacionamento com outros atores; (ii) requisitos finais, onde includo explicitamente o

sistema com o seu ambiente operacional, a partir de requisitos funcionais relevantes e

requisitos de qualidade (os chamados requisitos no funcionais). So produzidos os modelos

revisados de dependncia estratgica e raciocnio estratgico; (iii) projeto arquitetural, cujo

objetivo a definio global da arquitetura do software em termos de subsistemas e suas

dependncias. produzido o modelo de projeto arquitetural, que modela a estrutura do

sistema em partes relativamente pequenas e intelectualmente gerenciveis, que descreve como

os papis de agentes trabalham; (iv) projeto detalhado que detalha o comportamento de cada

componente arquitetural atravs de linguagens de comunicao entre agentes, mecanismos de

transporte de mensagens, ontologias, protocolos de interao de agentes da comunidade de

programao de agentes. Produz o diagrama de classes de agentes, diagrama de interaes,

diagrama de capacidades e diagrama de planos; e (v) implementao onde proposto o uso do

ambiente de desenvolvimento orientado a agentes, chamado JACK Intelligent Agents [JACK,

2007] para implementar os agentes.


18

Figura 2-8 Fases da metodologia Tropos

2.3 Consideraes Finais

Existe muito esforo em criar metodologias para orientar o desenvolvimento de sistemas

multiagentes. Isto tem ocorrido devido ao interesse crescente no uso de sistemas orientados a

agente na indstria de software. As metodologias tm como objetivo fornecer mtodos,

tcnicas e ferramentas para facilitar o desenvolvimento desses softwares, que so complexos

por sua natureza.

Neste captulo foi feita uma breve reviso das metodologias orientadas a agentes,

incluindo MAS-CommonKADS, Gaia, MaSE, PASSI e Tropos (Tabela 2-1). Estas

metodologias foram escolhidas por serem as mais populares no desenvolvimento orientado a

agentes. O objetivo foi analisar a abordagem de cada uma dessas metodologias, suas

atividades e produtos de trabalho gerados para caracterizar o que a comunidade de sistemas

orientados a agentes considera como importante em uma metodologia. Observa-se que a

maioria das metodologias tem razes na engenharia de software orientada a objetos, inclusive

fazendo uso da UML e extenses, como a AUML. MAS-CommonKADs, Gaia, MaSE / O-

MaSE, PASSI tm influncia da orientao a objetos em seus conceitos ou produtos de

trabalhos, fazendo uso de artefatos da UML para modelar os produtos de trabalhos. Tropos

usa conceitos da modelagem organizacional do i* [Yu, 1995] em sua verso original

[Mylopoulos & Castro, 2000], mas as verses posteriores adotaram a modelagem UML na


19

fase de projeto detalhado. A UML (com extenses para conceitos de agentes) tem sido

adotada, de forma geral, pela comunidade de desenvolvimento de agentes como a linguagem

de modelagem para sistemas orientados a agentes.

Tabela 2-1 Metodologias para desenvolvimento orientado a agentes

Metodologia Influncia Fases Produtos gerados

MAS-CommonKADS

[Iglesias, 1998]

Engenharia do

conhecimento e Orientao

a objetos

Conceituao Casos de Uso

Anlise

Modelo de organizao

Modelo de tarefas

Modelo de comunicao

Modelo de coordenao

Modelo de experincia

Modelo de agentes

Projeto Modelo de projeto

Codificao Agente codificado

Integrao Sistema completo

GAIA

[Wooldrige, Jennings & Kinny 1999] e

[Zambonelli; Jennings & Wooldridge,

2003]

Orientao a objetos

Anlise

Prottipo de modelo de papis

Modelo de papis

Modelo de interao

Projeto

Modelo de agentes

Modelo de servio

Modelo de conhecimento

O-MaSE

[DeLoach, 2006]

Orientao a objetos

Requisitos Modelo de Metas

MaSE

[Wood & DeLoach, 2001] e

O-MaSE

[DeLoach, 2006]

Anlise

Modelo organizacional

Modelo de domnio

Modelo de papeis

Projeto

Modelo de classes de agentes

Modelo de protocolo

Modelo de planos

Modelo de Poltica

PASSI

[Cossentino & Potts, 2002] e

Agile PASSI

[Chella et al., 2004] Orientao a objetos

Requisitos Modelo de requisitos

Sociedade de agentes Modelo de sociedade de agentes

Implementao Modelo de implementao

Codificao Modelo de codificao

Implantao Modelo de implantao

Agile PASSI [Chella et al., 2004] Testes Modelo de testes

Tropos

[Mylopoulos & Castro, 2000],

[Castro; Kolp & Mylopoulos, 2002] e

[Bresciani et al., 2004]

i* (modelagem

organizacional)

Requisitos iniciais Modelo de dependncia estratgica

Modelo de raciocnio estratgico

Requisitos finais Modelo de dependncia estratgica

Modelo de raciocnio estratgico

Projeto arquitetural Modelo de projeto arquitetural

Projeto detalhado

Diagrama de classes

Diagrama de interaes

Diagrama de Planos

Diagrama de capacidades

Implementao Sistema codificado

Todas as metodologias tm uma forte preocupao com a anlise e projeto do sistema.

MAS-CommonKADS, PASSI e Tropos geram modelos de definio de requisitos e modelos

para orientar a implementao. O-MaSE acrescentou a fase de requisitos verso inicial da


20

metodologia MaSE. A verso mais recente de PASSI (Agile-PASSI) acrescentou uma fase

explcita de testes para orientar o desenvolvimento gil de agentes. Existe hoje uma

preocupao em atualizar as metodologias, investindo nas fases de requisitos e acrescentando

modelos de processo para guiarem o desenvolvimento. A fase de requisitos crtica em um

processo de desenvolvimento, uma vez que todo o sistema baseado nos conceitos definidos

nesta fase. Modelos de processos para orientar o desenvolvimento tambm tem sido

preocupao da comunidade de desenvolvimento de agentes, como apresentado no captulo 4.

gile-PASSI um bom exemplo de extenses baseada em modelos de processo.

Tropos a nica que usa conceitos extrados das fases de requisitos iniciais, que

prope o entendimento do problema antes da construo do sistema. Alm disso, uma

abordagem que est em constante evoluo4, tendo sido gerados diversas extenses a verso

original. No prximo captulo, esta metodologia ser estudada mais detalhadamente.

4 www.troposproject.net

Captulo 3 O projeto Tropos

21


O projeto Tropos prope uma das abordagens mais completas para o desenvolvimento de sistemas multiagentes. Este captulo apresenta a viso geral do Tropos, suas fases, alguns conceitos bsicos e as tcnicas que compe a proposta. Tambm so apresentadas novas tcnicas e diretrizes que surgiram com o objetivo de melhorar o trabalho original.

3 O projeto Tropos


22

3.1 Introduo

Os processos bsicos do ciclo de vida de um software propostos pela ISO/IEC-12207:1994

consistem em cinco partes principais: aquisio, suprimento, desenvolvimento, operao e

manuteno de produtos de software. O projeto Tropos [Mylopoulos & Castro, 2000] prope

o processo de desenvolvimento de produtos de softwares orientados a agentes, englobando as

atividades de definio de requisitos (iniciais e finais), projeto arquitetural, projeto detalhado

e implementao.

O nome Tropos derivado da palavra grega trop, que significa "facilmente mutvel"

ou "facilmente adaptvel". A metodologia orientada a requisitos no sentido que baseada

em conceitos usados durante a fase de anlise de requisitos iniciais. O objetivo de usar

conceitos da engenharia de requisitos reduzir a incompatibilidade entre o sistema e seu

ambiente. Para este fim, foram utilizados os conceitos oferecidos pelo framework i* [Yu

1995] que, so geralmente aplicados na fase de requisitos. Contudo, em Tropos, eles tambm

so usados nas fases de arquitetura e projeto detalhado.

Tropos foi desenvolvida por diversos grupos de pesquisa e possui duas principais

verses publicadas. Embora estas abordagens incluam as mesmas atividades, elas apresentam

diferenas na seqncia de realizao das etapas das atividades e nos artefatos gerados [Silva,

M. J. et al., 2007]. Nesta dissertao, estas duas abordagens so chamadas de Tropos02

[Castro; Mylopoulos & Kolp, 2002] e Tropos04 [Bresciani et al., 2004]. Diversos trabalhos

tm sido desenvolvidos estendendo as duas abordagens principais. Alguns trabalhos como o

framework SIRA [Bastos, 2005] que, descreve como gerar uma configurao arquitetural a

partir dos requisitos do sistema e o modelo de projeto detalhado de [Silva, C.T.L.L. et al.;

2007a] utilizam a abordagem Tropos02. Alguns trabalhos para gerenciamento de segurana

[Giorgini & Mouratidis, 2005] e anlise de risco [Asnar; Gorgini & Mylopoulos, 2006]

utilizam a abordagem Tropos04. O comit tcnico de metodologias da FIPA [FIPA, 2007]

props a especificao de Tropos [FIPA, 2008] usando a notao de especificao de

processos SPEM [SPEM, 2007]. O objetivo foi a criao de um meta-modelo que pudesse ser

usado para descrever as metodologias e estruturas dos sistemas multiagentes. A verso

utilizada nesta descrio foi a Tropos04. O Spiral Tropos [Wautelet; Kolp & Achbany, 2005]

a descrio da metodologia Tropos02 como um processo de desenvolvimento em espiral. O

objetivo deste processo estender a metodologia Tropos para incluir as vantagens do modelo

de desenvolvimento em espiral para softwares orientados a agentes.


23

Neste captulo so apresentados os conceitos usados por Tropos e as principais

variaes existentes. Inicia descrevendo o framework i*, depois o Tropos e suas variaes e

por fim as tcnicas de melhoria e extenso do Tropos. So apresentadas as tcnicas mais

conhecidas para detalhamento das fases de requisitos iniciais e finais e tcnicas que estendem

as fases de projeto arquitetural e projeto detalhado. As tcnicas citadas anteriormente para

gerenciamento de requisitos, anlise de risco e segurana, no so detalhadas, pois no fazem

parte do escopo desta dissertao.

Para um melhor entendimento, neste trabalho, so usados exemplos ilustrativos dos

conceitos apresentados. Para isto utilizado um sistema multiagentes chamado DBSitter-AS

[Maciel, 2007] que foi modelado usando os conceitos do i* e fazendo uso de um subconjunto

de atividades extradas do Tropos02 e Tropos04 [Silva, M.J et al., 2007]. O DBSitter-AS

um sistema multiagentes que tem como objetivo monitorar um banco de dados e resolver

falhas que podem ocorrer durante seu uso.

3.2 Framework i*

O framework i* [Yu, 1995] foi criado sob a premissa que, o entendimento mais profundo de

um processo pode ser obtido a partir de uma viso estratgica e intencional. O nome i* est

relacionado noo de intencionalmente distribudo. Desta forma ele se baseia em uma

unidade central: o ator estratgico e intencional. O ator intencional no somente executa

atividades e produz entidades, mas tem motivaes, intenes e raciocnio por trs de suas

aes. Os aspectos intencionais de um ator podem ser caracterizados por metas, crenas,

habilidades e compromissos. Um ator estratgico quando ele no est meramente focalizado

em encontrar suas metas imediatas, mas est interessado nas implicaes de seus

relacionamentos com outros atores. O i* consiste de dois modelos: o modelo de dependncia

estratgica (Modelo SD) e o modelo de raciocnio estratgico (Modelo SR).

O Modelo SD prov uma descrio intencional de um processo em termos de uma rede

de relacionamentos de dependncias entre atores. O modelo pode ajudar a identificar as partes

interessadas (do ingls stakeholders) no sistema, analisar vulnerabilidades e oportunidades,

reconhecer padres de relacionamentos e identificar mecanismos para minimizar

vulnerabilidades. O modelo SD consiste de um conjunto de ns e ligaes. Cada n representa

um ator e cada ligao entre dois atores representa uma dependncia entre estes.


24

Os conceitos utilizados no modelo SD so atores, metas, metas-soft5, tarefas, recursos e

dependncias. Os atores representam papis exercidos pelas pessoas, funes ou cargos

ocupados, organizaes ou subdivises da organizao, sistemas ou envolvidos no contexto

onde sistema est inserido. As metas representam os interesses estratgicos dos atores, ou

seja, suas intenes, necessidades ou objetivos almejados para cumprir o seu papel dentro do

ambiente em que est inserido. As metas-soft tambm representam os interesses estratgicos

dos atores. Neste caso, estes interesses tm natureza subjetiva, isto , no so medidas de

forma concreta, mas so geralmente usadas para descrever desejos dos atores relacionados aos

atributos de qualidade com que eles querem que suas metas sejam satisfeitas. As tarefas

representam a forma de executar alguma atividade, isto , indicam como realizar alguma ao

para obter a satisfao de uma meta ou meta-soft. Os recursos representam dados ou

informaes que podem ser fornecidas ou recebidas por um ator.

As dependncias representam um acordo entre dois atores. O ator que depende de outro

ator chamado depender e o ator que satisfaz a dependncia de outros atores chamado

dependee. O objeto da dependncia chamado dependum. O tipo da dependncia descreve a

natureza do acordo entre os atores. A dependncia de metas ocorre quando um ator tem uma

meta a cumprir, mas depende de outros atores para a satisfao desta meta. Ento esta

dependncia representa uma delegao da responsabilidade de atingir uma meta de um

depender para um dependee. Neste caso, o depender no especifica como ele quer que a meta

seja executada, ele apenas repassa a responsabilidade para o ator dependee, que assume o

compromisso de execut-la de acordo com suas capacidades. A dependncia de metas-soft

semelhante dependncia de metas, com a diferena que o dependum uma meta-soft. O ator

depender delega a responsabilidade de obteno da meta-soft ao ator dependee e este assume

a compromisso de satisfazer esta meta-soft. A dependncia de tarefas ocorre quando um ator

tem uma atividade a cumprir, mas depende de outros atores para a sua execuo. Esta

dependncia representa uma delegao de responsabilidade de como realizar uma atividade. O

depender especifica como ele quer que a atividade seja executada j repassando o plano de

como esta deve ser executada. O ator dependee assume o compromisso de executar a

atividade da forma como especificado no plano recebido. A dependncia de recursos ocorre

quando um ator para cumprir suas responsabilidades, depende de informaes fornecidas por

outros atores. Esta dependncia representa a troca de informaes entre os atores. O ator

5 Os termos em ingls so traduzidos nesta dissertao: Goal traduzido para Meta. Softgoal no tem traduo na lngua portuguesa, mas para manter a padronizao assumido o termo Meta-soft.


25

depender depende de um recurso fornecido por um ator dependee que se responsabiliza em

prover este recurso.

A Figura 3-1 mostra um exemplo de diagrama SD. Os crculos representam os atores do

modelo SD que, interagem ente si, atravs das suas dependncias, representadas pelas

ligaes. O ator1 depende do ator2 para satisfazer suas metas e metas-soft. Neste caso o ator1

o depender e o ator2 o dependee. O ator2 tem dependncias do ator1 para realizar tarefas e

obter recursos. Portanto, o ator2 o depender e o ator1 o dependee. Os dependums

caracterizam os tipos de dependncias, isto , metas, metas-soft, recursos e tarefas.

Figura 3-1 Exemplo do modelo SD

Embora o Modelo de dependncia estratgica mostre dicas sobre o processo estruturado

com os atores e seus relacionamentos, ele no suficiente para apoiar o processo de sugerir,

explorar e avaliar solues alternativas. Este o papel do Modelo de raciocnio estratgico

(Modelo SR). O modelo SR inclui os mesmos quatro tipos de ns principais: as metas, tarefas,

recursos e metas-soft e adiciona trs tipos de ligaes: anlise meio-fim6, decomposio e

contribuies. A relao entre estes novos elementos se d no contexto de um nico ator, que

no diagrama SR representado por uma fronteira, ou seja, um crculo que delimita a anlise

dos elementos de um nico ator.

Os conceitos de ator, metas, metas-soft, tarefas e recursos so os mesmos descritos

anteriormente no modelo SD. Na ligao de decomposio, uma tarefa modelada em termos

de decomposio em subcomponentes. Estes subcomponentes podem ser metas, tarefas,

recursos e/ou metas-soft. Uma decomposio da tarefa em metas indica o objetivo que aquela

tarefa quer atingir. Quando uma tarefa decomposta em uma subtarefa, a subtarefa define

uma ao a ser realizada. Uma decomposio em um recurso implica em uma entidade (fsica

6 Os termos em ingls so traduzidos nesta dissertao: Means-end traduzido para Meio-Fim


26

ou informacional) que ser usada para a tarefa. Um meta-soft serve como uma meta de

qualidade para a tarefa e guia a seleo entre alternativas em outras decomposies da tarefa.

Ao realizar a anlise meio-fim podemos identificar vrias tarefas que seriam alternativas para

execuo de uma meta. Estas tarefas so exclusivas, ento ao final da anlise, deve-se optar

por uma destas, ou seja, as outras no sero executadas. O fim pode ser um uma meta, tarefa

ou recurso e o meio geralmente uma tarefa. Quando o fim uma Meta e o meio uma

Tarefa, esta tarefa especifica o "como atingir a meta" atravs de suas decomposies em

componentes. Quando o fim um recurso e o meio a tarefa, esta tarefa especifica o "como

produzir o recurso" atravs de suas decomposies em componentes. A ligao entre Meta-

soft e Tarefa um caso especial chamado Contribuio. A tarefa o meio para satisfazer as

restries de qualidade da meta-soft. Esta satisfao pode ser negativa ou positiva. Desta

forma esta ligao representada de forma diferente das demais ligaes Meio-Fim, sendo

representado com um atributo extra que identifica o tipo de contribuio da tarefa para a

meta-soft (++ significa satisfeito, + significa parcialmente satisfeito, -- significa proibido, -

significa conflito).

Um exemplo do modelo SR mostrado na Figura 3-2. O crculo pontilhado representa a

fronteira do ator2. O elemento Meta representa a meta principal do ator2 que refinada por

uma anlise meio-fim nas Tarefa1 e Tarefa2. Estas tarefas so as alternativas para realizao

da Meta. A Tarefa1 refinada por uma decomposio em duas subtarefas. A subtarefa1 tem

contribuio negativa sobre a meta-soft enquanto que a tarefa2 tem contribuio positiva. A

anlise das contribuies ajuda ao ator decidir qual tarefa deve ser executada.

Legenda

Figura 3-2 Exemplo do Diagrama SR


27

3.3 A abordagem Tropos viso geral

Tropos foi proposta em 2000 [Mylopoulos & Castro, 2000]. Esta verso original foi evoluda

em duas verses [Castro; Kolp & Mylopoulos, 2002] [Bresciani et al., 2004], que so ambas

utilizadas por pesquisadores em estudos e para modelagem de sistemas multiagentes. A

proposta de Castro, Kolp & Mylopoulos (2002) mais voltada estruturao dos elementos

sociais (pessoas envolvidas), intencionais (metas dos envolvidos), processos (negcios e

responsabilidades) e objetos (objetos, classe e seus relacionamentos). A proposta de Bresciani

et al. (2004) aborda mais profundamente conceitos do paradigma de desenvolvimento

orientado a agentes e prope mudanas nos elementos do framework i* original. Em ambas as

verses, Tropos dividida em cinco fases de desenvolvimento de software, que so requisitos

iniciais, requisitos finais, projeto arquitetural, projeto detalhado e implementao. A seguir,

so apresentadas as caractersticas destas fases.

3.3.1 Requisitos Iniciais

Os requisitos iniciais so o entendimento de um problema a partir da anlise e estudo da

configurao organizacional onde o problema est inserido. Durante esta fase os engenheiros

de requisitos capturam e analisam as intenes das partes interessadas7. Estas so modeladas

como metas, que a partir de uma anlise orientada a metas geram os requisitos funcionais e

no funcionais do sistema. Os modelos do i* so usados para representar as informaes

definidas nesta fase, que so os atores sociais que dependem de outros para atingir suas metas,

realizar suas tarefas e obter recursos. O modelo de dependncias estratgica usado para

descrever a rede de relacionamentos entre os atores enquanto, o modelo de raciocnio

estratgico descreve e justifica o raciocnio que cada ator tem sobre seu relacionamento com

outros atores. A Figura 3-3 exemplifica um modelo de dependncia estratgica (SD) para o

sistema DBSitter-AS na fase requisitos Iniciais. Esta figura mostra cinco atores:

Administrador de BD, Gerncia de informao, Sistema de Informao, RH e

Diretoria executiva que dependem uns dos outros para obter seus objetivos, executar suas

tarefas e prover os recursos. Cada ator tem dependncias entre si, representados pelas

conexes entre eles.

O modelo de raciocnio estratgico (SR) representa o raciocnio que cada ator social usa

para obter suas metas, executar suas tarefas e prover os recursos de sua responsabilidade. A

7 Partes interessadas a traduo assumida nesta dissertao para o termo stakeholder escrito na lngua inglesa

Captulo 3 O projeto T

“u -tropos: uma proposta de processo unificado para apoiar ... · palavras chaves: engenharia de...

Documents

CONSTRUCCIÓN DE MULTIAGENTES ESPECIALIZADOS PARA LA …

Tropos Branding - Froutonea - June 2017

Tropos identitarios en la frontera México / Estados Unidosinstitucional.us.es/revistas/Araucaria/Año 2_nº3/Cap 6 Tropos identitarios en la... · Tropos identitanos en la frontera

Tropos Josef Matthias Hauer

CREATIVE WRITING DIGITAL LIBRARY Tropos

Tropos y figuras literarias

Tropos 7.2

Figuras retóricas y tropos

Metodologia Tropos

Introdução aos Sistemas Multiagentes

Agentes Inteligentes y Sistemas Multiagentes Instructor

Tropos Technology Overview 081704

Tropos y secuencias: el diálogo cantado · a analizar a continuación: los tropos y las secuencias. Desde su descubrimiento por especialistas modernos, los tropos han sido objeto

Agentes inteligentes y sistemas multiagentesusers.exa.unicen.edu.ar/catedras/tmultiag/intro.pdf · Agentes inteligentes y sistemas multiagentes Taller de Sistemas Multiagentes Prof

Tropos Sales Overview 081704

Sistemas Multiagentes Uma Visão geral

TROPOS, TÓPICOS Y CARTOGRAFÍA

Desenvolvendo Sistemas Multiagentes com JADE.pdf

Agentes inteligentes y sistemas multiagentes

Agentes inteligentes e sistemas multiagentes

Catálogo Tropos

Comunicação em Sistemas Multiagentes Métodos Protocolos

MODELOS MENTALES Y SISTEMAS MULTIAGENTES: …

Tropos Digital #4

Tropos, teatro de títeres

Tropos project toward RE

Desenvolvendo Sistemas Multiagentes com JADE

f Pensamiento y Tropos

Tropos literios

Emoções e Sistemas Multiagentes (SMA)

Figuras Literarias y tropos

Organização em Sistemas Multiagentes

Adeus Aos Tristes Tropos

Diccionario de tropos

Tropos Technologies, Inc. “Reinventing the Low Speed Vehicle” · Tropos manufacturing is located in Stockton, CA. Tropos currently is engaged in multiple projects with major corporate