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

of 191 /191
Pós-Graduação em Ciência da Computação “U-TROPOS: uma proposta de processo unificado para apoiar o desenvolvimento de software orientado a agentes” Por MARIA JOCELIA SILVA Dissertação de Mestrado Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao RECIFE, Outubro / 2008

Author: vannhan

Post on 03-Dec-2018

212 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

  • 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

    3.6 CONSIDERAES FINAIS ........................................................................................................ 47

    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

    5.5 CONSIDERAES FINAIS ........................................................................................................ 95

    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

  • Captulo 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.

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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;

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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.

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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/

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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.

  • Captulo 2 Desenvolvimento de Software Orientado a 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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

  • Captulo 2 Desenvolvimento de Software Orientado a Agentes

    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

    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.

    3 O projeto Tropos

  • Captulo 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.

  • Captulo 3 O projeto Tropos

    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.

  • Captulo 3 O projeto Tropos

    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.

  • Captulo 3 O projeto Tropos

    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

  • Captulo 3 O projeto Tropos

    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

  • Captulo 3 O projeto Tropos

    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