Modelagem de Software Orientado a Agentes utilizando a Metodologia Tropos

Como todo e qualquer Sistema de Software existe a necessidade de planejamento, organização, gerenciamento e com os Sistemas de Software Orientado a Agentes acontece o mesmo. Estes sistemas são conhecidos como Sistemas Multiagentes e que trabalham com entidades superiores a Objetos, que são os Agentes, assumindo um comportamento operacional diferente. Logo, este tipo de sistema precisa seguir um planejamento por modelagem de maneira diferente. Assim, surgiu a necessidade de elaborar metodologias, modelagens e processos que atendam as características de Sistemas Multiagentes. Porém, vale salientar que apesar destes sistemas possuírem Agentes, os mesmos não são os únicos que compõem a sua estrutura, apesar de serem sua estrutura principal. Eles também possuem Objetos e demais estruturas de dados primitivas, logo, existe a necessidade destas metodologias permitirem a modelagem de entidades como Agentes e entidades inferiores.

Sistemas Multiagentes também são conhecidos como sistemas complexos, pois requerem de uma certa forma uma precisa elaboração de requisitos. Outro fato a se levar em consideração são os Sistemas de Software que necessitam atender demandas organizacionais, onde nem sempre projetistas conseguem ter um entendimento apropriado da organização para desenvolvimento do sistema. Como alternativa para solucionar estes problemas existe a Metodologia Tropos para modelagem de Sistemas Multiagentes, com inspiração em análise de requisitos e fundamentada em conceitos sociais e intencionais, visando a redução da incompatibilidade entre o sistema e o seu ambiente de atuação.

Metodologia Tropos

A metodologia Tropos (derivado do grego “tropé”, que significa “facilmente modificável” ou “facilmente adaptável”) é uma metodologia de desenvolvimento de Sistemas Multiagentes dirigida a requisitos. Ou seja, sabe-se que a fase de Elicitação de Requisitos é mais crítica de um projeto de software que, não sendo bem elaborado, pode propagar erros para o restante do projeto. Dessa forma, foi pensado o Tropos, inspirado na análise de requisitos com fundamentos de conceitos sociais e intencionais. Isto quer dizer que o sistema de software é pensado como uma organização cujas entidades envolvidas possuem autonomia (CASTRO, 2006).

No geral, a metodologia Tropos é fundamentada no framework I* (lê-se I-estrela, significa “intencionalmente distribuído”) projetado para viabilizar a modelagem e análise de processos desempenhados por participantes, sob a ótica de uma visão estratégica.

Framework I*

O Framework I* é uma modelagem dirigida a Requisitos, modelando os stakeholders ou conceitos sociais como atores e suas intenções como metas que, por sua vez, são desempenhadas por atores. Um autor pode ter várias cardinalidades para cumprir uma meta ou várias metas, e uma meta pode ser cumprida por um ator ou vários atores e várias metas desempenhadas por vários atores. Por isso que o sistema de software é projetado como uma estrutura organizacional de atores que na dependência de atores cumprem as suas metas. Assim, o framework tem como principais objetivos:

• Obter uma melhor compreensão sobre os relacionamentos da organização;
• Entender as razões envolvidas nos processos de decisões;
• Descrever potenciais alternativas do sistema pretendido.

O framework I* é estruturado em dois modelos: modelo de Dependência Estratégica (DE) e modelo de Razão Estratégica (RE). O modelo de Dependência Estratégica é utilizado para a descrição das intenções de processos em termos de relacionamentos de dependência entre atores; já o modelo de Razão Estratégica fornece a descrição estratégica de processos, levando em consideração elementos processuais e análise de metas que deverão ser cumpridas pelos atores.

Modelo de Dependência Estratégica

O modelo DE é utilizado para projeto de relacionamento entre os atores. Neste modelo são pensados as intenções e motivações destes atores, que se relacionam através de diversos outros componentes. A Figura 1 a seguir ilustra os principais componentes da metodologia I*:

• Ator: representa um agente físico (por exemplo, uma pessoa, um animal, um carro), ou um agente de software, bem como um papel ou uma posição. Um papel é caracterizado pela abstração de um comportamento que um ator exerce dentro de algum contexto especializado, enquanto uma posição representa um conjunto de papéis, geralmente interpretada por um agente. Um agente pode ocupar uma posição, enquanto que uma posição é dita para cobrir um papel;
• Objetivo: é semelhante a casos de uso da UML utilizados para representação dos Requisitos Funcionais de um sistema;
• Meta Objetivo: é utilizada para representação de Requisitos Não Funcionais tais como qualidade de software, segurança, desempenho, manutenção e etc.;
• Tarefa/Plano: representa os procedimentos de como satisfazer os Objetivos ou Meta Objetivos;
• Recurso: representa entidade física ou de informação que é ofertada ou necessária pelos atores (GIUNCHIGLIA, 2002);

Figura 1. Representação de componentes gráficos do framework I*

Outro tipo de componente da notação utilizado para relacionamentos entres os demais componentes e os atores é uma seta vazada, como pode ser visualizado na Figura 2. Esta seta é utilizada para viabilizar os diversos tipos de relações entre atores. Em um relacionamento de dependência existem dois tipos de atores: ator dependência e ator dependido, e entre eles fica o componente de dependência. O framework I* permite dois tipos de dependência entre atores: a dependência por meta-objetivo e a dependência por objetivo. Nas relações de dependência, o componente dependente só pode ser usado no máximo por dois atores que, neste caso, são o ator dependente e o ator dependido. Ou seja, um componente de dependência não poderá ser usado por mais de um ator dependente e por mais de um ator dependido e não existe relação direta entre atores.

Existe algumas ferramentas que permitem a relação de dependência de recursos e de tarefas entre atores.

Figura 2. Modelo de dependência entre atores.

Modelo de Razão Estratégica

O modelo RE é usado para descrever os interesses, preocupações e motivações dos participantes de um processo, além de possibilitar avaliação das possíveis alternativas de definição do processo e investigar mais detalhadamente as razões existentes por trás das dependências entre os vários atores (CASTRO, 2006). Neste modelo existem dois tipos de ligações: as ligações de decomposição de tarefas e ligações meio e fim. As ligações de decomposição de tarefas ligam um nó de tarefa a seus nós componentes - podem ser outras tarefas, objetivos e recursos. As ligações meio e fim indicam relacionamentos entre um nó fim, que pode constituir um objetivo a ser atingido, uma tarefa a ser realizada, um recurso a ser produzido ou uma meta objetivo a ser satisfeita - e um meio para atingi-lo (DA SILVA, 2005). A Figura 3 ilustra exemplos de ligação de decomposição de tarefas e, como pode ser observado, uma tarefa pode ser decomposta em outra tarefa ou em um recurso ou em um objetivo. A Figura 4 ilustra exemplos de ligação meio e fim e, como pode ser observado, um objetivo pode ser alcançado pela realização de uma tarefa ou de outro objetivo.

Figura 3. Ilustração de decomposição de tarefas.

Figura 4. Ilustração de realização de objetivos

Além dos modelos apresentados, o Framework I* permite a visualização do software sob vários pontos de visão:

• Social: os atores, seus interesses, obrigações e capacidades;
• Intencional: os objetivos e suas dependências;
• Comunicativa: interação entre os atores e suas formas de comunicação;
• Orientada a processos: recursos computacionais e atores envolvidos ou outros sistemas relacionados;
• Orientada a objetos: se existem estruturas como objetos e classes e seus relacionamentos (DA SILVA, 2005).

A metodologia Tropos engloba praticamente todas as fases de desenvolvimento de software: Requisitos Iniciais, Requisitos Finais, Projeto Arquitetural e Projeto Detalhado. Existem algumas ferramentas que estendem a metodologia Tropos para que a mesma dê suporte a fase de Implementação. Além disso, devido a metodologia Tropos ser orientada a requisitos, a mesma segue um modelo de processo de desenvolvimento chamado de “modelo V”.

O modelo em V é uma representação do processo de desenvolvimento de sistemas que estende o tradicional modelo em cascata. No modelo em V, o lado esquerdo representa as fases de desenvolvimento e o lado direito representa as fases de teste, momento em que o sistema é testado com base em especificação definida no lado esquerdo (AMBIEL, 2010). A Figura 5 ilustra o modelo V para processo de desenvolvimento de software e como pode ser observado, o modelo cobre as seguintes fases de desenvolvimento: Elicitação de Requisitos, Projeto de Alto Nível, Projeto Detalhado, Codificação. Além disso, o modelo tem as respectivas etapas de testes: Teste de Unidade (que ocorre no código), Teste de Integração junto com os módulos feitos no Projeto Detalhado, Teste de Sistema (realizado com o Projeto de Alto Nível, levando em consideração o Sistema integrado) e Teste de Aceitação, para junto com os Requisitos validar o Sistema.

Figura 5. Modelo V para processo de desenvolvimento de software.

Fase de Requisitos Iniciais

Na fase de Requisitos Iniciais interessa-nos o entendimento do problema através da compreensão do contexto organizacional, no qual o sistema a ser desenvolvido será implantado. Durante esta fase, os engenheiros de requisitos modelam os stakeholders, como atores sociais, que dependem uns dos outros e que têm intenções de atingir objetivos, realizar tarefas e fornecer recursos. A análise realizada nesta fase é orientada a Objetivos, onde cada Objetivo é analisado sob o ponto de vista de seu ator, resultando em um conjunto de dependências entre pares de atores. (CASTRO, 2006). Esta fase deve gerar dois modelos: o modelo DE, capturando os atores do ambiente organizacional, seus objetivos e interdependências; o modelo RE, fazendo uso de ligações meio e fim para projeto de como os Objetivos serão cumpridos pelos seus atores.

Fase de Requisitos Finais

Nesta fase ocorre o refinamento dos modelos DE e RE concebidos na fase anterior. Durante a análise dos requisitos finais, os modelos conceituais desenvolvidos na fase anterior são revisados e estendidos para incluir novos atores, que representam tanto o sistema a ser desenvolvido quanto os seus subsistemas. Para realizar o projeto do modelo DE na fase de Requisitos Finais, os atores devem ser relacionados por meio de novos pares de dependência junto aos atores do ambiente operacional do sistema que foram identificados na fase anterior. Estas dependências relacionadas ao sistema devem refletir responsabilidades atribuídas ao mesmo, de forma a contribuir com as necessidades dos stakeholders. Essas dependências são utilizadas para descrever os requisitos funcionais e não funcionais do sistema a ser desenvolvido (CASTRO, 2006).

Para construção do modelo RE desta fase, o ator representante do sistema que será desenvolvido deverá ser expandido para apresentação das razões que estão relacionadas com as suas dependências. As tarefas e objetivos do sistema precisam ser revisados, analisados e detalhados pelas ligações de decomposição de tarefas e pelas ligações meios e fins. Além disso, pode haver a atribuição de responsabilidades aos subsistemas contidos dentro do sistema. O objetivo desta etapa é dar suporte ao processo de sugestão, exploração e avaliação de soluções alternativas para o sistema (DA SILVA, 2005).

Fase de Projeto Arquitetural

O Projeto Arquitetural serve para definir a arquitetura global do sistema em sua estrutura como subsistemas, interconexões pelo controle fluxo de dados. A arquitetura de um sistema pode ser considerada um modelo, relativamente pequeno e intelectualmente gerenciável da estrutura do sistema que descreve como seus componentes trabalham juntos. Na metodologia Tropos, subsistemas são representados como atores e interconexões de dado/controle são representados como dependências entre os atores.

Assim como sistemas de software convencionais Sistemas Multiagentes também possuem estilos arquiteturais; estes estilos arquiteturais são utilizados para estruturar a organização e comunicação dos componentes do sistema. A metodologia Tropos faz uso de estilos arquiteturais provenientes do Framework I*. A Tabela 1 a seguir ilustra os estilos arquiteturais do framework I*.

Tabela 1. Descrição dos estilos arquiteturais do framework I* (DA SILVA, 2005).

A fase de Projeto Arquitetural exige a realização de três atividades. A primeira atividade consiste na escolha do Estilo Arquitetural, que deve estar relacionado com os atributos de qualidade que se deseja do sistema de software como disponibilidade, adaptabilidade, segurança e etc. Cada estilo arquitetural possui características próprias que visam atender a um ou mais de um atributo de qualidade. A Tabela 2 ilustra a correlação entre os Estilos Arquiteturais e os atributos de qualidade. Em geral, um Estilo Arquitetural visa atender aos Requisitos Não Funcionais especificados para o sistema.

A segunda atividade consiste em refinar os modelos DE e RE para refletirem o Estilo Arquitetural escolhido gerando um novo modelo RE da Arquitetura do Sistema, podendo surgir novos atores e dependências.

A terceira e última atividade na fase de Projeto Arquitetural consiste na aplicação de padrões sociais, que são utilizados para descrever interações e negociações entre os agentes. Os padrões sociais do Tropos são organizados em duas categorias: padrões entre pares, como por exemplo booking, callfor-proposal, subscription, e bidding; e padrões de mediação como monitor, broker, matchmaker, mediator, embassy, e wrapper. Na terceira atividade se faz necessário a criação de mais um modelo RE aplicando os padrões sociais.

Tabela 2. Ilustração da correlação entre os atributos de qualidade e os Estilos Arquiteturais.

Fase de Projeto Detalhado

A fase de projeto detalhado lida com a especificação do micro nível dos agentes, estando preocupada em apresentar detalhes adicionais para cada componente arquitetural do sistema. Isto inclui aspectos dos agentes que envolvem a comunicação e seus comportamentos. São modelados pelo Diagrama de Sequência da UML as interações e troca de mensagens. A comunicação fica por conta do padrão FIPA-ACL ou KQML. Nesta fase é definido como os objetivos atribuídos aos atores serão realizados pelos agentes. Ainda nesta fase os padrões sociais são detalhados.

Fase de Implementação

Na fase de Implementação deve ocorrer o mapeamento do Projeto Detalhado para linguagem de programação. A metodologia Tropos em si não menciona nada quanto a fase de implementação. No entanto, devido a metodologia ter um alto refinamento do sistema na sua última fase, algumas ferramentas CASE’s dão suporte a metodologia Tropos, cobrindo a fase de Implementação e montando esqueleto de código. Estas ferramentas geram esqueletos de código para framework como JACK, JADEX, JADE e etc. Em geral, a programação de Sistemas Multiagente não é trivial, portanto há a necessidade de utilização de framework de programação.

Ferramentas Case

No site da Metodologia Tropos existe um catálogo das ferramentas CASE desenvolvidas para dar suporte a metodologia. Vale salientar que algumas ferramentas, além de darem suporte a metodologia, ainda fazem extensões a mesma, acrescentando outros componentes. A seguir, na Tabela 3 são descritas de forma sucinta as ferramentas que estão presentes no site.

Tabela 3. Catálogo das ferramentas CASE para suporte a metodologia Tropos.

Este post teve por objetivo dar uma visão geral sobre a Metodologia Tropos para Desenvolvimento de Software Orientado a Agentes, conhecido como Sistemas Multiagentes. Trata-se de uma metodologia simples de se interpretar e com poucos componentes de se utilizar, mas ao mesmo tempo, robusta para modelagem e gerenciamento do modelo ao longo do ciclo de vida do software. Mais informações no site da metodologia, onde poderá encontrar artigos, livros e demais recursos de apoio. Espero que tenham gostado do post e até a próxima.

Referências

AMBIEL, L. M. B. Tópicos de Engenharia de Software Orientada a Agentes. p. 6, 2010.

CASTRO, J. F. B. DE; ALENCAR, F. M. R.; SILVA, C. T. L. L. DA. Engenharia de Software Orientada a Agentes. Atualizações em Informática, n. 2006, p. 38, 2006.

DA SILVA, I. G. L. Projeto e Implementação de Sistemas Multi-Agentes: O Caso Tropos. Universidade Federal de Pernambuco, 2005.

GIUNCHIGLIA, F.; MYLOPOULOS, J.; PERINI, A. The Tropos Software Development Methodology: Processes, Models and Diagrams. AAMAS Conference (2002). Anais...2002.