Uma Avaliação da Metodologia MAS-CommonKADS

Transcrição

1 Uma Avaliação da Metodologia MAS-CommonKADS V.M. B. Werneck 1 ; L. F. Pereira 1 ; T. S. Silva 1 ; E. K. Almentero 1, L. M. Cysneiros 2 1 Instituto de Matemática e Estatística UERJ - Universidade do Estado do Rio de Janeiro - Brasil 2 Dept. of Math. & Stat.- Information Technology Program York University Toronto Canada vera@ime.uerj.br, cysneiro@yorku.ca Abstract: The agent-oriented approach to software engineering introduces concepts such as pro-activeness and autonomy to achieve more flexible and robust systems for complex applications environments. A number of AOSE (Agent Oriented Software Engineering) methodologies have been proposed so far. In order to evaluate and compare some of these methods in depth, we used a common exemplar a detailed application setting within which each of the methodologies will be worked out. In this paper we show how to apply this exemplar to evaluate MAS-Common-KADS. Resumo. A Modelagem Orientada a Agentes introduz conceitos como proatividade e autonomia para obter sistemas mais flexíveis e robustos em ambientes computacionais complexos. Até o momento, várias metodologias foram propostas adotando este novo paradigma. Para avaliar e comparar essas metodologias com mais detalhes, utilizamos um exemplar, onde cenários e questões metodológicas são definidos com o objetivo de modelar esses aspectos de sistemas multi-agentes. Neste trabalho apresentamos a avaliação da metodologia orientada a agentes MAS-CommonKADS baseado nessa proposta de avaliação. 1. Introdução O paradigma orientado a agentes para desenvolvimento de software tem se destacado como uma abordagem para tratar de requisitos que vêem surgindo com a grande proliferação de componentes de software distribuídos por grande número de usuários em distribuições geográficas que podem atingir escala mundial. Necessidades proeminentes dessas novas aplicações, como autonomia e sociabilidade não são tratadas pelos atuais paradigmas. No contexto emergente, uma das principais características destes componentes de software (visto aqui como agentes) é ter autonomia para decidir se um serviço requisitado por outro agente será ou não realizado em tempo real. Esta decisão é baseada nas necessidades individuais de quem estiver usando esse agente. Em decorrência desta autonomia, aspectos de sociabilidade como a dependência de um agente em outro e quanto crítica essa dependência será devem ser tratados desde o principio do processo do desenvolvimento de software. Este trabalho está inserido num projeto de pesquisa de avaliação de metodologias Orientadas a Agentes [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], com

2 base no framework de avaliação proposto por Yu e Cysneiros (2002). Este trabalho visa analisar a metodologia MAS-CommonKADS utilizando-se da experiência na definição, modelagem e implementação dos requisitos de um Sistema Multi-agentes de Apoio a Diabéticos. Este experimento permitiu que a metodologia MAS-CommonKADS fosse avaliada, considerando sua potencialidade na identificação, modelagem e implementação de requisitos e características dos sistemas multi-agentes. Na Seção 2 deste artigo apresentamos o framework de avaliação baseado num exemplar. Na Seção 3 fornecemos uma visão geral da metodologia MAS- CommonKADS. Na Seção 4, apresentamos a modelagem MAS-CommonKADS dos requisitos do domínio do problema abordando os aspectos fundamentais da modelagem e o protótipo desenvolvido. A avaliação de MAS-CommonKADS é discutida no Seção 5, comparando-a a trabalhos correlatos. Na Seção 6 destacamos nossas conclusões e sugestões para trabalhos futuros. 2. O Framework de Avaliação baseado em um Exemplar O framework de avaliação [Yu e Cysneiros, 2002] utilizado neste trabalho é baseado no Projeto Guardian Angel [Szolovits et al, 1994]. Esse estudo de caso provê o suporte automático para assessorar pacientes com doenças crônicas tais como diabetes e hipertensão, integrando todos aspectos relacionados ao sistema de saúde incluindo informações legadas de remédios e informações financeiras. Este exemplo é construído através de um conjunto de agentes representando o hospital (GA_Hospital), os membros familiares em casa (GA_Home) e o paciente monitorado (GA_PDA). Esse sistema pessoal auxilia na captura, gerenciamento e interpretação do histórico pessoal da saúde do paciente e sua rotina diária na condução do tratamento, aconselhando-o com as melhores opções com base em suas preferências pessoais. O sistema mantém os registros médicos de forma compreensiva, acumulativa, correta, e coerente, acessível em tempo, em diferentes locais e para diferentes sistemas de saúde. O projeto do Guardian Angel [Szolovits et al, 1994] foi escolhido como base para o exemplar, pois apresenta um problema complexo, abrangendo as necessidades dos sistemas atuais. Assim, podemos ter experimentos que requerem modelos complexos confrontando com problemas de distribuição, privacidade, autonomia, proatividade e sociabilidade. Como um problema facilmente compreendido e aberto podese analisar melhor o poder e a fragilidade das metodologias, identificando suas vantagens, deficiências e desvantagens. O exemplar [Yu e Cysneiros, 2002] é expresso em termos de um conjunto de cenários numerados (EA0.0 até EA9.0) como por exemplo: EA2.0- Uma vez que o paciente e o médico estabeleceram um plano de tratamento GA-PDA deverá auxiliar para que o paciente siga e monitore o andamento desta rotina. O processo propõe, também, acoplado a esses cenários um conjunto de questões de avaliação (primeira coluna da Tabela 1) para apoiar a avaliação de como a metodologia suporta a modelagem desses cenários. Neste trabalho, porém, utilizamos principalmente as perguntas metodológicas apresentadas no exemplar. Em razão de estarmos desenvolvendo um sistema real baseado em agentes decidimos usar este experimento para avaliar a metodologia MAS- CommonKADS. O uso das perguntas metodológicas apresentadas em Yu e Cysneiros

3 (2002) justifica-se por já termos usado-as em diversos estudos anteriores durante os quais fomos capazes de avaliar o elevado grau de utilidade destas perguntas. Este aspecto será mais detalhado na seção 5. Tabela 1. Questões Metodológicas e Avaliação MAS-CommonKADS MAS- Common KADS QA1 - Pro-atividade S QA18 - Projeto e raciocínio da arquitetura S QA2 - Autonomia Humana X autonomia de software S QA19 - Elicitando e Raciocinando requisitos não-funcionais W QA3 - Raciocínio da autonomia S QA20 - Projeto e raciocínio da arquitetura N QA4 - Diferentes níveis de Abstração S QA21 - Projeto e raciocínio da arquitetura W QA5 - Identificando participantes do domínio S QA22 - Validando especificação ao longo do ciclo de vida W QA6 - Capturando, entendendo e registrando terminologia N QA23 - Rastreando mudanças dos requisitos ao projeto N QA7 - Análise de domínio S QA24 - Rastreando mudanças do projeto ao código N QA8 - Levantamento de requisitos S QA25 - Concorrência W QA9 - Cooperação homem-máquina N QA26 - Rastreando de volta aos requisitos N QA10 - Projeto de banco de dados N QA27 - Modularidade de software S QA11 - Evolução de banco de dados W QA28 - Verificação e Validação Formal W QA12 - Projeto de banco de dados legados N QA29 - Gerenciamento de Projeto N QA13 - Raciocinando diferentes requisitos não-funcionais W QA30 - Trabalhando equipes distribuídas N QA14 - Mobilidade W QA31 - Suporte de ferramentas W QA15 - Projeto de interface com usuário S QA32 - Curva de aprendizagem N QA16 - Gerando casos de teste N QA33 - Integração com outras metodologias N QA17 - Projeto de interface com usuário S QB7- Simplificação da metodologia para problemas simples N Total de S (Pontos Fortes) 11 Total de N (Pontos Neutros) 14 Total de W (Deficiências) 9 MAS- Common KADS 3. O Método MAS-CommonKADS A metodologia MAS-CommonKADS [Iglesias, 1998], [Iglesias e Garijo, 1999], [Iglesias e Garijo, 2005] é uma extensão da metodologia CommonKADS englobando aspectos que são relevantes para sistemas multi-agentes. CommonKADS tornou-se, principalmente na Europa, uma referência no desenvolvimento de sistemas baseados em conhecimento (SBC). No CommonKADS são definidos vários modelos [Schreiber et al, 1999], sendo o Modelo de Experiência o central da metodologia CommonKADS com objetivo de modelar o conhecimento de resolução de problemas empregado por um agente para realizar uma tarefa. Este modelo divide o conhecimento da aplicação em três subníveis: nível do domínio (conhecimento declarativo sobre o domínio), nível de inferência (uma biblioteca de estruturas genéricas de inferência) e nível de tarefa (ordem das inferências). Algumas considerações e problemas foram analisados ao se aplicar diretamente CommonKADS ao desenvolvimento de sistemas multi-agentes [Iglesias, 1998], [Iglesias e Garijo, 1999] surgindo a proposta MAS-CommonKADS centrada no Modelo de Agentes. Esta metodologia define sete modelos (Iglesias, 1998): Modelo de Agentes, Modelo de Organização, Modelo de Tarefas, Modelo de Experiência, Modelo de Comunicação, Modelo de Coordenação e Modelo de Design. O Modelo de Agentes especifica as características de um agente: sua capacidade de raciocínio, habilidades, serviços, sensores, grupos de agentes aos que pertence e classe de agente. Um agente pode ser um agente humano, software, ou qualquer entidade capaz de empregar uma linguagem de comunicação de agentes. O Modelo de Organização é uma ferramenta para analisar a organização humana em que o sistema multi-agente vai ser introduzido e para descrever a organização dos agentes de software e sua relação com o meio. O Modelo de Tarefas descreve as tarefas que os agentes podem realizar, os objetivos de cada tarefa, sua decomposição e os métodos de resolução de problemas para resolver cada objetivo. O Modelo de Experiência descreve o conhecimento necessário aos agentes para atingir seus objetivos. Segue a

4 decomposição de CommonKADS e reutiliza as bibliotecas de tarefas genéricas. O Modelo de Comunicação descreve as interações entre um agente humano e um agente software. Centra-se na consideração de fatores humanos para dita interação. O Modelo de Coordenação descreve as interações entre agentes de software. E finalmente o Modelo de Design descreve a arquitetura e o design do sistema multi-agentes como passo prévio a sua implementação, sendo o único modelo a não tratar da Análise O modelo de ciclo de vida para o desenvolvimento de sistemas multi-agentes [Iglesias, 1998], [Iglesias e Garijo, 1999], [Iglesias e Garijo, 2005] segue a gestão de projetos de Common-KADS [Schreiber et al, 1999] sendo dirigido por riscos e engloba as seguintes fases: Conceituação, Análise, Design, Codificação, Integração e Operação e Manutenção. A fase de Conceituação consiste na tarefa de elicitação para obter uma primeira descrição do problema e a determinação dos casos de uso que podem ajudar a entender os requisitos informais e a testar o sistema. A Análise determina os requisitos do sistema partindo do enunciado do problema. Durante esta fase se desenvolvem os seguintes modelos: organização, tarefas, agentes, comunicação, coordenação e experiência. No Design define-se como os requisitos da fase de análise podem ser conseguidos mediante o desenvolvimento do modelo de design, determinando-se as arquiteturas tanto da rede multi-agentes como de cada agente. Na Codificação cada agente é implementado e testado e na fase de Integração, o sistema completo é testado. 4. A Modelagem MAS-CommonKADS do Sistema Monitor Glicêmico O sistema Monitor Glicêmico surgiu de uma especialização do Guardian Angel [Szolovits et al, 1994], [Yu e Cysneiros, 2002] para o tratamento de pacientes com Diabetes Mellitus. Esse sistema foi baseado, também, no conhecimento existente e disponível nos sites da Sociedade Brasileira de Diabetes (2005), da Federação Internacional de Diabetes (2005) e da Associação Americana de Diabetes (2005). Um paciente diabético precisa contato constante com um médico para acompanhar o tratamento. Com a idéia do Guardian Angel instanciada no Monitor Glicêmico, é possível fazer isto, sem sair de casa ou marcar consulta. O sistema permite monitorar taxas de açúcar através de um medidor portátil e registrá-las no computador. O processo de identificação dos requisitos do sistema Monitor Glicêmico foi realizado nas fases de Conceituação e Análise seguida de uma fase de rápida de Design e construção de um protótipo. 4.1 Fase de Conceituação O objetivo desta fase é obter uma primeira descrição do problema e do sistema que será desenvolvido. O documento desta fase teve como objetivo modelar um protótipo do Monitor Glicêmico, implementando algumas das funções propostas inicialmente ao sistema. O protótipo foi construído para ajudar pacientes com diabetes mellitus tipo 1, em terapia insulínica intensiva, no seu dia a dia. O sistema Monitor Glicêmico pretende dar mais liberdade ao paciente customizando o próprio tratamento, fornecendo sugestões ao paciente e um direcionamento para o seu tratamento. Este auxilia no controle da taxa de glicose no sangue, no controle da dosagem de insulina e na flexibilização da dieta. O objetivo principal é que o paciente tenha conselhos de um especialista, o sistema no caso, sem precisar efetivamente ir ao médico. Nessa fase de conceituação foram realizadas as

5 seguintes atividades: descrição do problema, identificação dos atores, identificação e descrição dos casos de uso, definição dos diagramas de casos de uso e dos diagramas de seqüência de mensagens. Os seguintes atores foram identificados no sistema: o paciente, o médico e o responsável pelo paciente. Nesta primeira versão, o Paciente é uma Pessoa com diabetes mellitus em terapia insulínica intensiva, com múltiplas doses. O paciente acessará o sistema com o objetivo de auxiliar a administração de alguns aspectos do tratamento. O Médico é responsável pelo tratamento do paciente usuário do sistema e deverá ter completo conhecimento sobre as informações contidas no sistema e sobre o papel deste no tratamento. Ocasionalmente, o médico receberá mensagens do sistema informando a ocorrência de desvios de padrão na taxa glicêmica do paciente. No futuro esses alertas poderão ser configurados pelo médico para que este se sinta confortável com o nível de alerta sem ser incomodado muitas vezes por dia. O Responsável pelo acompanhamento do tratamento do paciente tem o papel de acompanhar o andamento do tratamento, recebendo alertas informando sobre desvios graves no padrão da taxa glicêmica. No futuro todas as funcionalidades relacionadas aos três atores poderão rodar em PDA ou telefones celular, principalmente, no caso de emergências. Para cada ator foram identificados vários casos de uso e, por exemplo, o caso de uso UC06-Enviar Alertas, o paciente participa recebendo alertas de nível leve, médio e grave, enquanto o médico recebe alertas de nível médio e grave, e o responsável somente alertas de nível grave. Na descrição dos casos de uso foram descritos os fluxos de eventos de cada um dos casos de uso identificados e estes fazem referência aos agentes que constituem o sistema. Esses agentes foram descritos de maneira detalhada no modelo de agentes. Os Diagramas de Seqüência de Mensagens formalizam as interações e usam a notação do diagrama de seqüência de mensagens do UML. 4.2 Fase de Análise Nesta fase foram desenvolvidos os Modelos de Agentes, Tarefas, Conhecimento, Organização, Coordenação e Comunicação. O modelo de agentes tem o objetivo de descrever os agentes que participam da solução dos problemas e são descritos nas Planilhas de CRC (Classes- Responsabilidades-Colaborações), nos diagramas de casos de uso interno (extensão do conceito de casos de uso do UML para agentes humanos e de software), nos diagramas de seqüência de mensagens relativas aos casos de uso internos, nas Planilhas de Agentes e na Tabela de Distribuição de Tarefas e Agentes. As atividades realizadas na modelagem de agentes foram identificação dos agentes, descrição dos agentes, classificação dos agentes, identificação, diagramação e descrição dos casos de uso interno e seus respectivos diagramas de seqüência de mensagens. Os diagramas de caso de uso interno descrevem as funções desempenhadas internamente pelos agentes. A partir da fase de conceituação, foi possível identificar os Agentes Humanos: Paciente, Médico e Responsável; e os Agentes de software: Gerenciador de Dados Pessoais, Gerenciador de Alimentação, Gerenciador de Alertas, Gerenciador de Insulina, Gerenciador de Exercícios, Gerenciador do Banco de Dados e Avaliador de Tratamento.

6 Os agentes foram agrupados por categorias, observando as semelhanças e diferenças entre cada agente. Assim pudemos, por exemplo, ter uma Classe de Agentes Especialistas que representa os agentes que utilizam conhecimentos de um especialista na área de diabetes para produzir informações úteis ao paciente. Os Agentes classificados nessa categoria são: Gerenciador de Insulina, Gerenciador de Exercícios e Avaliador de Tratamento. As planilhas CRC proporcionam um método para organizar as classes necessárias para a construção do sistema e facilitam a aplicação dos conceitos de orientação a agentes. Como os agentes humanos não realizam nenhuma tarefa além de iniciar ou terminar cada um dos casos de uso, não foram elaborados os CRCs e as planilhas de Agentes para agentes humanos. Para cada agente de software foi construída uma planilha CRC como apresentado para agente Avaliador de Tratamento na Tabela 2. Tabela 2 Planilha CRC para o Avaliador de Tratamento. Agente: Avaliador de Tratamento Classe: Especialistas Objetivo Plano Conhecimento Colaborador Cadastrar taxa de glicose, dose de insulina e resultado da avaliação. Solicitar cadastro ao Gerenciador do Banco de Dados. Formato da avaliação e da taxa de glicose. Gerenciador do Banco de Dados. Verificar se os resultados do tratamento estão dentro dos padrões esperados. Comparar resultados atuais com o esperado e solicitar ao Gerenciador de alertas o envio de alertas. Formato dos alertas, níveis normais de taxa glicêmica e da dose de insulina, histórico de utilização de insulina, histórico da taxa glicêmica. Gerenciador de Alertas. No sistema Monitor Glicêmico foram identificados vários casos de uso internos: e a Figura 1 ilustra um exemplo de Diagrama de Casos de Uso Interno. As Descrições dos Casos de Uso Internos foram descritas de forma idêntica aos casos de uso através dos fluxos de eventos que fazem referência aos agentes que constituem o sistema. Solicitar envio de alerta MSC Processar e armazenar alerta Legenda Agente de Software Avaliador de Tratamento Armazenar alerta Gerenciador de Alertas Casos de Uso Interno MSC Diagrama de Seqüência de Mensagens Gerenciador do Banco de Dados Figura 1. Diagrama de Casos de Uso Interno UC06 - Enviar Alerta Os diagramas de seqüência de mensagens apresentam a interação entre os agentes, conforme exemplifica a Figura 2. Ainda no Modelo de Agentes foram construídas as planilhas de agentes cujo objetivo é descrever melhor as capacidades e conhecimentos dos agentes. O Modelo de Tarefas é outro modelo elaborado na fase de Análise e permite mostrar a decomposição funcional do sistema. Para representar a decomposição das tarefas foram construídos diagramas de fluxo de dados que permitem mostrar de forma mais explícita a relação entre as tarefas e as informações. A descrição das tarefas se completou na identificação e descrição de seus objetivos. Esse detalhamento contém os parâmetros de entrada e saída, as condições de ativação e finalização além da descrição do processamento e tipo de objetivo. Para finalizar o Modelo de Tarefas e de Agentes foi elaborada uma Tabela com a Distribuição das Tarefas e dos Agentes onde essas tarefas são as descritas nos casos de uso interno.

7 O Modelo de Conhecimento foi, também, definido na fase de Análise, sendo composto das Estruturas de Domínio, Inferências e de Tarefas. A Estrutura de Domínio representa o conhecimento declarativo do problema, descrevendo as entidades relevantes do domínio e as relações entre essas entidades. Neste sistema foram identificados conceitos agrupados nos seguintes esquemas do domínio: Esquemapaciente, Esquema-insulina e Esquema-exercício. A Estrutura de Inferência foi especificada para os agentes inteligentes mediante a definição das inferências que são realizadas para a resolução do problema e da estrutura que relaciona as inferências e os papéis do conhecimento. Essa estrutura foi definida e instanciada para o domínio do problema a partir de estruturas genéricas contidas numa biblioteca de modelo [Schreiber et al, 1999]. A Estrutura de Tarefas representa de forma procedural de tarefas as primitivas definidas na estrutura de inferência. No Monitor Glicêmico especificamos a Estrutura de Inferência e de Tarefas para o Avaliador de Tratamento. msc PROCESSAR ALERTA Avaliador de Tratamento Gerenciador de alertas Gerenciador de Banco de Dados solicitar_envio_alerta (gravidade,msg alerta) solicitar_armazenamento confirma_armazenamento ( ) informa_resultado (cod_ret) retorna_erro (desc_erro) Figura 2. Diagrama de Seqüência de Mensagens: Processar e armazenar alerta. O Modelo de Organização construído permitiu analisar as relações estruturais entre os agentes, tanto de software quanto humanos, que interagem com o sistema. Finalmente o último modelo elaborado na fase de Análise foi o Modelo de Coordenação cujo principal objetivo foi definir as interações entre agentes, permitindo um estudo mais aprofundado das interações homem-máquina e máquina-máquina. Para cada interação foi definido um Diagrama de Fluxo de Eventos, descrevendo como os agentes processam as mensagens recebidas e como enviam a mensagem através dos Diagramas de Transição de Estado na notação do UML [Rumbaugh, Jacobson e Booch, 1999]. 4.3 Fase de Design e Protótipo O Modelo de Design tem como propósito a descrição dos componentes que cumprem os requisitos dos modelos de análise e que levam em conta os requisitos funcionais. Nesse primeiro protótipo, a plataforma escolhida foi a Web, para permitir o acesso de qualquer lugar via Internet. Além de outras vantagens, elimina as etapas de instalação e configuração do software o que facilita o primeiro contato com o usuário. Nessa primeira versão as linguagens utilizadas foram Java, JSP, HTML, JavaScript. e SQL. Uma nova versão está sendo implementada em JADE (2006). O acesso do sistema é realizado através de um login 1 e uma senha disponibilizando suas funções. Este protótipo encontra-se em fase de teste com 1 O sistema pode ser acessado para teste com Usuário: vera e Senha: veraxxx e o endereço de acesso é

8 especialistas que consideram o sistema muito importante. Entretanto, algumas regras de inferência deverão ser melhor calibradas, pois ainda não atingiu o nível esperado de um especialista. A Figura 3 ilustra uma interação do sistema mostrando o cálculo da dosagem de insulina e o resultado da avaliação do paciente. Fig. 3. Monitor Glicêmico - Resultado do cálculo da dose de insulina 5. AVALIAÇÃO DA METODOLOGIA MAS-COMMON-KADS A escolha do framework de avaliação proposto por Yu e Cysneiros (2002) é justificada considerando vários aspectos, sendo fundamental o uso de um exemplo prático, real e grande o suficiente para testar e verificar como a metodologia se comporta em situações reais. Embora o Monitor Glicêmico seja um sistema específico para o tratamento de diabéticos este foi definido com base nos cenários descritos no framework. Alguns desses cenários são incompletos, intencionalmente omitidos para testar como a metodologia direciona e suporta a elícitação de requisitos. As questões metodológicas complementam esses cenários, identificando situações em que a metodologia deve orientar na elicitação e análise dos requisitos e também casos específicos de modelagem que a metodologia deve atender. Trabalhos anteriores de avaliação das metodologias Tropos, Gaia, MESSAGE e UML/RUP [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], mostraram o uso eficiente desse framework de avaliação ressaltando os pontos fortes, as deficiências e as potencialidades de cada metodologia. Assim apresentamos, a priori, uma análise geral da metodologia MAS- CommonKADS, com os principais aspectos identificados a partir da respostas fornecidas para as diversas questões conforme a Tabela 1. Na segunda coluna da Tabela 1 temos relacionadas as questões metodológicas de avaliação da metodologia MAS- CommonKADS em termos dos pontos fortes (S), das deficiências (W) e dos pontos neutros (N). A seguir é descrita uma comparação com base em outras avaliações realizadas nesse projeto e os trabalhos correlatos encontrados na literatura. 5.1 Avaliação Geral MAS-CommonKADS é uma metodologia oriunda da engenharia de conhecimento por isso agrega aspectos interessantes da definição de estruturas heurísticas. Nessa metodologia foram também incorporadas técnicas orientadas a objetos, técnicas

9 estruturadas (Diagramas de Fluxo de Dados) e técnicas de colaboração como os cartões de Classes-Responsabilidade-Colaboração (CRC). O uso de técnicas consagradas facilitou a definição dos diagramas e planilhas. Entretanto, alguns desses artefatos não são bem definidos nem exemplificados. A metodologia MAS-Common-KADS mostrouse fácil de modelar embora em muitos modelos como Modelo de Especialidade foi necessário consultar livros da metodologia Common-KADS [Schreiber et al, 1999], refletindo na atribuição neutra para curva de aprendizagem (QA32). O grande número de diagramas e planilhas dificulta a referência cruzada dos diagramas/planilhas e a rastreabilidade dos requisitos (QA23, QA24 e QA26). MAS-CommonKADS suporta a pro-atividade (QA1) através do Modelo de Agentes, Modelo de Tarefas, Modelo de Conhecimento e Modelo de Coordenação. Neste último são definidas também as interações entre os agentes e seus detalhes (QA9), sendo possível definir melhor a pro-atividade. No aspecto de decidir autonomia humana versus autonomia do software (QA2), MAS-CommonKADS permite que isso possa ser feito em tempo de execução através de heurísticas definidas no Modelo de Conhecimento. No raciocínio da autonomia (QA3) podemos ter um protocolo de cooperação entre os agentes através da negociação. Esta é expressa nos diagramas do Modelo de Coordenação através de categorias de decisão que podem se apoiar em estratégias, preferências, procedimentos ou comportamentos. MAS-CommonKADS tem três níveis de abstração (QA4) definidos nas fases de conceituação que define os requisitos iniciais, de análise e projeto. Na identificação do domínio do problema (QA7) e dos participantes do domínio (QA5), MAS- CommonKADS apóia o desenvolvedor na compreensão dos objetivos do sistema e representa a hierarquia dos agentes (QA18) através do Modelo de Organização. A fase de conceituação permite capturar requisitos (QA8) através dos seus casos de uso e também pelas suas interações definidas nos Diagramas de Seqüência de Mensagens. Assim as interações humanas e dos agentes de software (QA9) são definidas num alto nível de abstração. Esta fase foi considerada fundamental na captura de novos requisitos e refinamentos de requisitos já identificados previamente. Os Casos de Uso Interno e os seus Diagramas de Seqüência de Mensagens são definidos em MAS-CommonKADS para modelar o comportamento dos agentes. Porém, os aspectos não funcionais (QA13, QA19) não são explicitamente modelados nem é possível através desses diagramas considerar os aspectos não funcionais que irão ou não trazer conseqüências ao sistema. Apesar da rastreabilidade dos requisitos (QA23, QA24, QA26) ser um aspecto considerado não muito bem definido, 82% dos requisitos funcionais identificados na modelagem puderam ser facilmente identificados no código. Os requisitos nãofuncionais são de difícil identificação. Os agentes e seus comportamentos não são identificados no código possivelmente por ser utilizada uma linguagem orientada a objetos nesse primeiro protótipo. A maior dificuldade encontrada foi no rastreamento das funcionalidades onde havia alguma pró-atividade, pois essa característica na programação orientada a objetos ficou diluída nas várias classes. Assim sendo, a equipe não chegou a um consenso neste atributo. E MAS-CommonKADS não se preocupa em definir meios de se obter rastreabilidade. MAS-CommonKADS incentiva o uso de encapsulamento de conhecimento e comportamento nos agentes de software (QA18) o que minimiza o impacto de mudanças futuras. O modelo de projeto identificou para arquitetura (QA20, QA21)

10 escolhida como os agentes poderiam ser implementados e seus comportamentos, facilitando a implementação. A implementação embora não tenha utilizado um paradigma orientado a agentes foi bastante simples. Entretanto na implementação da parte heurística encontramos grande dificuldade por não se utilizar nenhuma linguagem orientada ao conhecimento heurístico. 5.2 Comparação com Trabalhos Correlatos Na literatura de orientação a agentes podem ser encontrados trabalhos comparando metodologias, como Sturm e Shehory (2003) que define um framework de avaliação quantitativa e qualitativa e o utiliza na avaliação das metodologias GAIA, Adept e Desire utilizando um estudo de caso de leilão. Outro trabalho de avaliação interessante foi o desenvolvido por Dam e Winikoff (2003) que utiliza um framework baseado em atributos e um questionário enviado e respondido pelos pesquisadores, por autores das metodologias e alunos que modelaram o estudo de caso Planejamento de Itinerário Pessoal. Essa avaliação foi realizada nas metodologias GAIA, MaSE, Message, Prometheus e Tropos. Iglesias e González (1998) descrevem um levantamento de metodologias analisando suas extensões nos paradigmas orientados a objetos e de conhecimento. Ceruzzi e Rossi (2002) propõe outra avaliação que usa métricas e métodos quantitativos, mostrando a utilidade deste framework na comparação das metodologias MAS-CommonKADS e Agent Modelling Technique for Systems of BDI Agents. Essa avaliação é baseada em critérios previamente definidos e através da quantificação dos resultados e aplicação de média aritmética. Um dos resultados apontados para MAS- CommonKADS é que esta só atende o critério de pro-atividade (QA1) parcialmente, pois não permite a definição explicita de objetivos e de aspectos nebulosos e de evolução da autonomia. Entretanto através dos Modelos de Agentes, de Tarefas, de Conhecimento e de Coordenação esse aspecto pode ser bem definido, e apontamos como um aspecto poderoso da metodologia. Realmente a evolução da autonomia é um fator considerado fraco na metodologia, mas esse também é um fator crítico em sistemas inteligentes. Esse fator poderia ser uma questão a ser introduzida no exemplar. Outro exemplo é em relação ao critério transição sistemática, onde Cerruzzi e Rossi (2002) atribuem a MAS-CommonKADS o valor máximo. Entretanto, em nossa avaliação esses atributos (QA23 e QA24) são neutros, pois a metodologia não possui uma descrição detalhada das tarefas para construção de todos os artefatos propostos nem da transição de um para outro. Outro trabalho relevante de avaliação da metodologia MAS-CommonKADS encontrado foi o proposto por Tran, Low e Williams (2004). Nessa proposta são definidos 50 critérios para avaliação agrupados em critérios relacionados a processo, técnica, modelo e apoio. Porém alguns desses critérios não são analisados, principalmente os relativos ao emprego das técnicas. O artigo menciona que uma análise mais profunda deve ser realizada num futuro. No critério suporte a ontologia é atribuída uma afirmação, mas através da questão QA6 consideramos este um fator neutro, pois a descrição de como essa ontologia se insere no MAS-CommonKADS não é encontrada em nenhum documento da metodologia embora seja uma característica da metodologia CommonKADS. Em relação ao suporte na definição da interface de comportamento do agente e instanciação das classes de agentes, Tran, Low e Williams

11 (2004) atribuem zero a esses fatores. Consideram que MAS-CommonKADS não suporta esses aspectos. Entretanto o valor atribuído deveria ser 1, pois o passo é incluído na metodologia mas não referenciado explicitamente ou através de exemplos. O critério QA9 neutro reflete essa questão. Com base nos trabalhos anteriores do projeto [Cysneiros, Werneck e Yu, 2005], [Cysneiros, Werneck, Amaral e Yu, 2005], [Coppieters, Marzulo, Kinder e Werneck, 2005], podemos concluir que MAS-CommonKADS provê apoio as fases de Análise e Projeto inclusive as fases iniciais de Definição de Requisitos como as metodologias MESSAGE e Tropos. Mas não tão abrangente como Tropos, pois não permite a definição e raciocínio dos requisitos não-funcionais nem avaliação de alternativas ao processo. MAS-CommonKADS como Gaia e Tropos permite modelar os conceitos de agentes, como autonomia, pro-atividade, objetivos e desejos. Em termos de facilidade de aprendizagem (QA32) é neutro, pois embora tenha documentação disponível alguns dos seus diagramas e artefatos não são bem definidos. Esse atributo também não foi o máximo nas metodologias MESSAGE e Tropos. Gaia por ser mais concisa tem uma documentação melhor. 6. CONCLUSÃO Neste trabalho foram abordados aspectos importantes da modelagem e da identificação de requisitos em sistemas multi-agentes. O objetivo deste foi avaliar qualitativamente a metodologia MAS-CommonKADS utilizando-a para desenvolver um protótipo de um sistema para ajudar pacientes portadores de diabetes mellitus tipo 1. Esta avaliação foi baseada no conjunto de perguntas apresentada no exemplar proposto por Yu e Cysneiros (2002). O framework utilizado [Yu e Cysneiros, 2002] nessa avaliação foi bastante útil tanto no auxílio à definição dos requisitos como para se identificar situações não modeladas. A análise dos pontos fortes e fracos da metodologia MAS-CommonKADS pode ser melhor compreendida após serem respondidas as questões metodológicas. Podemos sintetizar que a metodologia MAS-CommonKADS tem como pontos fortes a identificação dos agentes, de seus requisitos funcionais através da descrição do comportamento desses diferentes agentes, facilitando principalmente a implementação de agentes que utilizam estruturas de inferência. Entretanto, podemos ressaltar como problemas o uso excessivo de modelos e diagramas de análise e de não descrever explicitamente a relação entre os diferentes artefatos. Outro aspecto que a metodologia necessita de melhoria é no tratamento dos requisitos não-funcionais. A continuação deste trabalho está sendo realizada em duas iniciativas em paralelo. A primeira deverá continuar o processo de avaliação da metodologia implementando essa mesma modelagem utilizando uma plataforma orientada a agentes. A segunda consistirá na continuação do desenvolvimento do sistema Monitor Glicêmico que deverá ser melhorado com mais funcionalidade, melhor desempenho em suas respostas e implementado para diferentes ambientes (PDA, telefone celular,...), pois existe um grande interesse de uso na prática. REFERÊNCIAS BIBLIOGRÁFICAS Ceruzzi, L. e Rossi, G. (2002) On the Evaluation of Agent-Oriented Methods, Agent Oriented Methodology Workshop, November.

12 Coppieters, A. M., Marzulo, L.A.J., Kinder, E. e Werneck, V.M.. (2005) Modelagem Orientada a Agentes utilizando MESSAGE, Cadernos do IME- Série Informática, Rio de Janeiro, v.18, p Cysneiros, L. M., Werneck, V. M. B., Amaral, J. e Yu, E. (2005) Agent/Goal Orientation versus Object Orientation for Requirements Engineering: A Practical Evaluation Using an Exemplar, In: Proc. Of VIII Workshop in Requirements Engineering, Porto, 2005, p , ISBN Cysneiros, L. M., Werneck, V. M. B.; Yu, Eric (2005) Evaluating Methodologies: A Requirements Engineering Approach Through the Use of an Exemplar. Journal of Computer Science & Technology, USA, v. 5, n. 2, p Dam K. H. e Winikoff, M. (2003) Comparing Agent-Oriented Methodologies, 5th International Workshop on Agent-Oriented Information Systems (AOIS 03), p Iglesias, C. Á. (1998) Definición de una Metodología para el Desarrollo de Sistemas Multiagente, Tese de Doutorado, Departamento de Engenharia de Sistemas de Telecomunicação, Universidade Politécnica de Madri. Madri, 322p. Iglesias, C.A. e Garijo, M. (1999) UER Technique: Conceptualisation for Agent- Oriented Development, In Proceeding of 5th International Conference on Information Systems Analysis and Synthesis (ISAS 99), Vol 5, p Iglesias, C.A. e Garijo, M. (2005) The Agent Oriented Methodology MAS- CommonKADS; IN Agented-Oriented Methodologies, Brian Henderson-Sellers e Paolo Giorgini (ed.), IDEA Group Publishing, p Iglesias, C.A. e González, J.C. (1998) A Survey of Agent-Oriented Methodologies In Proceedings of the 5th International Workshop on Agent Theories, Architectures and Languages (ATAL'98), LNAI n Springer Verlag, Paris, France, p JADE Java Agent Development Framework. Disponível em acessado em abril Rumbaugh, J., Jacobson, I. e Booch, G. (1999) The Unified Modeling Language Reference Manual ; Addison-Wesley. Schreiber, G et al (1999) Knowledge Engineering and Management: The CommonKADS Methodology, Cambridge, MA,. Sturm, A. e Shehory, O. (2003) A Framework for Evaluating Agent-Oriented Methodologies, 5th International Workshop on Agent-Oriented Information Systems (AOIS 03), p Szolovits, P., Doyle, J., Long, W.J., Kohane, I. e Pauker, S. G. (1994) Guardian Angel: Patient-Centered Health Information Systems, Technical Report MIT/LCS/TR-604. Disponível em. Tran, Q.N., Low, G. e Williams, M. (2004) A Prelimary Comparative Feature Analysis of Multi-agent Systems Developments Methodologies, In Proc of the 6th Intl. Bi- Conference Workshop on Agent-Oriented Information Systems (AOIS 2004),. Yu, E. e Cysneiros, L.M. (2002), Agent-Oriented Methodologies-Towards a Challenge Exemplar in Proc of the 4th Intl. Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS 2002), Toronto.