AGENTES AUXILIANDO AMBIENTES DE ENGENHARIA DE SOFTWARE CENTRADO EM PROCESSOS

Transcrição

1 INPE TDI/1364 AGENTES AUXILIANDO AMBIENTES DE ENGENHARIA DE SOFTWARE CENTRADO EM PROCESSOS Bruno Hideo Casillo Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada, orientada pelos Drs. Nilson Sant Anna e Solon Venâncio de Carvalho, aprovada em 26 de junho de Registro do documento original: < INPE São José dos Campos 2008

2 PUBLICADO POR: Instituto Nacional de Pesquisas Espaciais - INPE Gabinete do Diretor (GB) Serviço de Informação e Documentação (SID) Caixa Postal CEP São José dos Campos - SP - Brasil Tel.:(012) /6923 Fax: (012) pubtc@sid.inpe.br CONSELHO DE EDITORAÇÃO: Presidente: Dr. Gerald Jean Francis Banon - Coordenação Observação da Terra (OBT) Membros: Dr a Maria do Carmo de Andrade Nono - Conselho de Pós-Graduação Dr. Haroldo Fraga de Campos Velho - Centro de Tecnologias Especiais (CTE) Dr a Inez Staciarini Batista - Coordenação Ciências Espaciais e Atmosféricas (CEA) Marciana Leite Ribeiro - Serviço de Informação e Documentação (SID) Dr. Ralf Gielow - Centro de Previsão de Tempo e Estudos Climáticos (CPT) Dr. Wilson Yamaguti - Coordenação Engenharia e Tecnologia Espacial (ETE) BIBLIOTECA DIGITAL: Dr. Gerald Jean Francis Banon - Coordenação de Observação da Terra (OBT) Marciana Leite Ribeiro - Serviço de Informação e Documentação (SID) Jefferson Andrade Ancelmo - Serviço de Informação e Documentação (SID) Simone A. Del-Ducca Barbedo - Serviço de Informação e Documentação (SID) REVISÃO E NORMALIZAÇÃO DOCUMENTÁRIA: Marciana Leite Ribeiro - Serviço de Informação e Documentação (SID) Marilúcia Santos Melo Cid - Serviço de Informação e Documentação (SID) Yolanda Ribeiro da Silva e Souza - Serviço de Informação e Documentação (SID) EDITORAÇÃO ELETRÔNICA: Viveca Sant Ana Lemos - Serviço de Informação e Documentação (SID)

3 INPE TDI/1364 AGENTES AUXILIANDO AMBIENTES DE ENGENHARIA DE SOFTWARE CENTRADO EM PROCESSOS Bruno Hideo Casillo Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada, orientada pelos Drs. Nilson Sant Anna e Solon Venâncio de Carvalho, aprovada em 26 de junho de Registro do documento original: < INPE São José dos Campos 2008

4 Dados Internacionais de Catalogação na Publicação (CIP) C269a Casillo, Bruno Hideo. Agentes auxiliando ambientes de engenharia de software centrado em processos/ Bruno Hideo Casillo. São José dos Campos: INPE, p. ; (INPE TDI/1364) 1. Engenharia de software. 2. Agentes de software. 3. Ambientes de engenharia de software centrado em processos. 4. Modelagem de processos. 5. Automatização de processos. I. Título. CDU Copyright c 2008 do MCT/INPE. Nenhuma parte desta publicação pode ser reproduzida, armazenada em um sistema de recuperação, ou transmitida sob qualquer forma ou por qualquer meio, eletrônico, mecánico, fotográfico, microfílmico, reprográfico ou outros, sem a permissão escrita da Editora, com exceção de qualquer material fornecido especificamente no propósito de ser entrado e executado num sistema computacional, para o uso exclusivo do leitor da obra. Copyright c 2008 by MCT/INPE. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, eletronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use of the reader of the work.

5

6

7 A meus pais, Pedro Luiz Casillo e Elisa Nishikawa Casillo.

8

9 AGRADECIMENTOS Agradeço a todas as pessoas que me ajudaram a vencer mais esta etapa da vida. A meus pais pelo aporte financeiro durante esses anos de estudo. Ao Instituto Nacional de Pesquisas Espaciais INPE, pela oportunidade de estudos e utilização de suas instalações. Ao Laboratório de Matemática e Computação Aplicada LAC, pela oportunidade de estudos e utilização de suas instalações. A SESIS pelo conhecimento profissional adquirido e pela ajuda no desenvolvimento do trabalho Aos professores do INPE pelo conhecimento compartilhado. Ao meu orientador Prof. Dr. Nilson Sant Anna, pelo conhecimento passado, e pela orientação e apoio na realização deste trabalho. Ao meu segundo orientador Prof. Dr. Solon Venâncio de Carvalho, pela ajuda na realização deste trabalho. Ao Prof. Dr. Tatuo Nakanishi, pelo apoio na construção do trabalho e pela experiência passada. Aos meus amigos do INPE. À minha noiva Patrícia, pelo amor e compreensão, mesmo nos tempos de difícil compreensão. A meus pais novamente por sempre acreditarem na importância do estudo e sempre acreditarem em mim.

10

11 RESUMO Organizações desenvolvedoras de software estão cada vez mais preocupadas com a qualidade de seus produtos, por isso a abordagem de processos de software está sendo cada vez mais utilizada. Criados para facilitar a utilização de processos de software, ambientes de engenharia de software centrado em processos, disponibilizam ferramentas para apoio a execução de processos em um ambiente voltado para o auxílio ao trabalho colaborativo, um exemplo deste tipo de ambiente é o e-webproject, um ambiente de engenharia de software centrado que conta com ferramentas de suporte ao desenvolvimento e processos implementados com interface através do ambiente. Para cada novo processo inserido ou modificado neste ambiente, uma aplicação específica para a utilização do processo deve ser construída, utilizando recursos nem sempre disponíveis nos projetos da empresa. Visando à rápida introdução de novos processos ao ambiente e à facilidade na melhoria de processos já existentes, a automatização do serviço de criação, e uso dos processos pelo ambiente foi implementada. A aplicação desenvolvida necessita que as tarefas executadas para a implementação do processo no ambiente sejam executadas de forma autônoma, visando criar instâncias de processos dentro do ambiente. A tecnologia de agentes vem de encontro a essa necessidade, possibilitando a criação de agentes que executam as tarefas para instanciação e monitoramento dos processos.

12

13 AGENTS ASSISTING PROCESS-CENTERED SOFTWARE ENGINEERING ENVIROMENTS ABSTRACT Software development organizations are each time more worried about the quality of its products, therefore the boarding of software processes is being more used. Created to facilitate the use of software processes, processcentered software engineering environments, presents tools for support the execution of processes in an environment directed toward to assist the collaborative work, an example of this environment are e-webproject, a process-centered software engineering environment that have support tools to the development of software and processes implemented into the environment. For each new process inserted, or modified in this environment, an specific application for the management of the process must be constructed, using available resources nor always available to the projects of the company. Aiming at the fast introduction of new processes to the environment and the facility in processes improvement, the automatization of creation, and use of the processes into the environment was implemented. The developed application needs that tasks which are executed, aiming to create instances of processes inside the environment in a autonomous way. The technology of agents can be used to solve this necessity, making possible the creation of agents who execute the instanciation and monitoring tasks of the processes.

14

15 SUMÁRIO Pág. LISTA DE FIGURAS... LISTA DE SIGLAS E ABREVIATURAS... 1 INTRODUÇÃO Objetivo do Trabalho Estrutura do trabalho AMBIENTES DE ENGENHARIA DE SOFTWARE Ambientes de Engenharia de Software Centrado em Processos e-webproject AGENTES Agentes Categoria de Agentes Framework de Agentes Jade Agentes Auxiliando Processos de Engenharia de Software SERVIÇO DE MODELAGEM E INSTÂNCIA DE PROCESSOS Modelagem de processos Instância do processo Coordenação de Processos INTEGRAÇÃO ENTRE AMBIENTE DE AGENTES E AMBIENTE DE ENGENHARIA DE SOFTWARE Agentes no e-webproject IMPLANTAÇÃO DO SERVIÇO DE MODELAGEM E INSTÂNCIA DE PROCESSOS APOIADO POR AGENTES DE SOFTWARE Modelagem de processos Instância do processo Agente Instanciador Agente Coordenador Agente Escalonador Coordenação do Processo Agente Monitor CONSIDERAÇÕES FINAIS Contribuições Trabalhos Futuros...89 REFERÊNCIAS BIBLIOGRÁFICAS...91 APÊNDICE A A.1 - Código fonte Servlet...100

16 A.2 - Código Fonte Agente A.3 - Código Fonte Interação A.4 - Código Fonte Sincronizador A.5 - Código Fonte Gerenciador de Comportamentos A.6 - Código Fonte Comportamento Resposta Servlet A.7 - Código Fonte Comportamento Banco A.8 - Código Fonte Busca de Agentes...120

17 LISTA DE FIGURAS Componentes e Camada Conceitual do Ambiente. FONTE: (Sant Anna 2000) Modelo Padrão de Plataforma de Agentes definido pela FIPA. Adaptado de JADE (2005) Ciclo de Vida dos Agentes como definido pela FIPA.Retirado de JADE(2005) Modelagem dos Comportamentos dos Agentes FONTE: (JADE, 2005) Diagrama de Contexto da Modelagem de Processos Diagrama de Contexto Acompanhamento de Processos Diagrama de Contexto Tarefas do Usuário Diagrama de Contexto Coordenação de Processos Atividades da Arquitetura Criada Seqüência de Interações da Arquitetura Modelos de Processos Existentes Definição de um Modelo de Processo Modelo da Persistência do Modelo de Processo Definição de um Modelo de Tarefa Definição das Restrições de Tarefa do Modelo de Tarefa Alocação de um Papel para Execução do Modelo de Tarefa Modelo de Persistência do Modelo de Tarefas Definição de Estado liberado para o Modelo de Processo Diagrama de Caso de Uso da Instância do Processo Atividades do Agente Instanciador Diagrama de Seqüências do Agente Instanciador Modelo de Persistência do Processo Instanciado Modelo de Persistência do Repositório Dinâmico de Tarefas Diagrama de Casos de Uso da Instância da Tarefa Atividades do Agente Coordenador na Colaboração Incluir Tarefas no Repositório Dinâmico Atividades do Agente Coordenador na Colaboração Criar Instância de Tarefas Modelo de Persistência da Tarefa Instanciada Diagrama de Caso de Uso Alocar Pessoa Atividades para Alocar Pessoa para a Tarefa Diagrama de Caso de Uso Acompanhar Evolução das Tarefas Atividades do Agente Monitor...84

18

19 LISTA DE SIGLAS E ABREVIATURAS ACL Agent Communication Language API Bibliotecas da linguagem Java CMMI Capability Maturity Model Integration DF Diretório Facilitador PSEE - Process-Centered Software Engineering Enviroment SPICE - Software Process Improvement and Capability Determination

20

21 INTRODUÇÃO As organizações reconhecem a importância de gerenciar o processo de desenvolvimento de software visando melhoria da qualidade de seus produtos. Pensando na melhoria constante de produtos e processos, cada vez mais a utilização de modelos de maturidade e capacitação são adotados no processo de desenvolvimento de software (PETERS E PEDRYCZ, 2001) (THUNEM, 1997). Modelos como CMMI (CMMI, 2005) e SPICE (SPICE, 1995) auxiliam no processo de desenvolvimento de software definindo diretrizes a serem seguidas por processos existentes dentro do processo de desenvolvimento. São exemplos de processos internos ao processo de desenvolvimento de software: a engenharia de requisitos, gestão de configuração e versão, garantia da qualidade, planejamento e acompanhamento de projetos, melhoria de processos dentre outros. O aumento do grau de maturidade da organização oriundo da implementação de processos, possibilita definir com maiores níveis de confiança características como prazos e custos de desenvolvimento (PAULA FILHO, 2003; SOMMERVILLE, 2003). Apesar da importância do uso de processos, as organizações têm dificuldade em sua implantação dentro do processo de desenvolvimento de software. Esta dificuldade tem como principais causas a falta de cultura relacionada ao gerenciamento dos processos, a dificuldade na definição das responsabilidades no processo e a quantidade de recursos que precisam estar disponíveis para a definição e implementação dos processos. Mesmo depois de implementados, os processos podem necessitar de melhorias na sua concepção, e mais uma vez, para modificar o processo, responsabilidades devem ser definidas e recursos devem ser disponibilizados, recursos estes nem sempre disponíveis para o projeto, como por exemplo: recursos humanos, financeiros ou de tempo (MAIA ET AL, 2004; ATKINSON, NOLL, 2003). 19

22 Uma alternativa para diminuir a dificuldade na implantação desses processos é a utilização de um ambiente que possua características de apoio a utilização de processos, tais como ferramentas de apoio ao trabalho colaborativo (CONRADI, BELKHATIR, 1995; SANT`ANNA, 2000; MUEHLEN, 2001). Um ambiente que disponibiliza estes recursos é o e-webproject, Os processos dentro do ambiente, apesar de existentes, devem ser construidos em sua totalidade de forma manual, ou seja, depois de definidos, devem ser implementados por uma equipe de desenvolvimento. A necessidade de automatização da implementação e do uso dos processos de software que podem ser agregados pelo ambiente, motiva o desenvolvimento de uma ferramenta que, de forma autônoma, execute as tarefas desempenhadas pela equipe de desenvolvimento. O e-webproject (SANT ANNA et al., 2002) é um ambiente de engenharia de software comercial implementado a partir do trabalho de pesquisa Um Ambiente Integrado para o Apoio ao Desenvolvimento e Gestão de Projetos de Software para Sistemas de Controle de Satélite - AMBGES (SANT ANNA, 2000) desenvolvido no Instituto Nacional de Pesquisas Espaciais INPE. Este ambiente visa auxiliar o desenvolvimento de software disponibilizando ferramentas de apoio à execução de processos e ao trabalho colaborativo. Como o ambiente foi definido para a utilização de processos, outros trabalhos de pesquisas foram realizados utilizando a estrutura disponível pelo e- WebProject. Estes trabalhos contribuem para a definição e criação de processos de software, tais como gerenciamento de projetos (BORREGO FILHO, 2003), gerenciamento de requisitos (GENVIGIR, 2004), garantia da qualidade (Lahoz, 2004), gerenciamento de modificações e configuração (ABDALA, 2004), e modelagem de processos (CEREJA JUNIOR, 2004). Apesar de definidos, apenas o processo de gerenciamento de projetos dentre os acima citados foi implementado completamente como ferramenta dentro do ambiente de engenharia de software, devido a fatores como tempo e custo. 20

23 1.1 Objetivo do Trabalho O ambiente de engenharia de software e-webproject, possui ferramentas para apoiar o desenvolvimento de software, como mostra a camada de serviços exemplificada na Figura 1.1, o ambiente possui também processos definidos e implementados que são utilizados no processo de desenvolvimento de software. Porém para cada novo processo definido, é necessária a alocação de pessoas tanto para a definição quanto para a implementação do processo, devido à inexistência de uma aplicação que possibilite a gestão deles pelo ambiente. A abordagem adotada até então pelo ambiente dificulta a utilização de diversos processos, tais como gerência de configuração, garantia da qualidade, resolução de problemas entre outros, o que faz com o que o processo de desenvolvimento de software possa ser prejudicado pela não existência de ferramentas necessárias à gestão. FIGURA Componentes e Camada Conceitual do Ambiente. FONTE: Sant Anna (2000). O objetivo deste trabalho é desenvolver uma ferramenta de gestão de processos para o ambiente de engenharia de software e-webproject. Esta 21

24 ferramenta tem como objetivo fornecer um serviço de gestão de processos. Através dele novos processos podem ser definidos e utilizados através do ambiente. Para a implementação da modelagem do processo, foi seguida a arquitetura do ambiente, utilizando linguagem Java e suas API s para execução em ambiente WEB. Para automatizar a criação de processos no ambiente, foi utilizada a tecnologia de agentes, devido à sua autonomia para execução de tarefas, portanto a implementação da instância do processo no ambiente foi realizada utilizando a tecnologia de agentes escritos em linguagem Java. Para facilitar a criação dos agentes, um framework de agentes que disponibiliza recursos para a rápida criação e manutenção dos agentes foi utilizado. Apesar de desenvolvidos sobre a plataforma Java, o ambiente de engenharia de software e o framework de agentes não possuem interação, pois utilizam de diferentes tecnologias e possuem diferentes objetivos, sendo o primeiro um sistema de execução em ambiente WEB e o segundo uma aplicação clienteservidor. Para tornar possível a interação dos agentes com as informações do ambiente e-webproject e facilitar o gerenciamento destes, foi construída uma arquitetura para que os agentes possam ser controlados pelo próprio ambiente de engenharia de software. 1.2 Estrutura do trabalho O trabalho está organizado em mais 6 capítulos e um apêndice, conforme descritos a seguir: Capítulo 2 Ambientes de Engenharia de Software Este Capitulo aborda os conceitos de processo de software, ambientes que suportem esses processos, denominados ambientes de engenharia de software, apresentando um ambiente chamado e-webproject. Capítulo 4 Serviço de Modelagem e Instância de Processos Capítulo 3 Agentes 22

25 Este capítulo abrange conceitos sobre agentes, suas categorias e características de um framework de agentes, caracterizados pelo framework JADE. Mostra também como os agentes podem auxiliar processos de engenharia de software que são suportados pelos ambientes de engenharia de software Capítulo 4 - Serviço de modelagem e Instância de Processos O Capítulo 4 apresenta a especificação de um serviço definido para a modelagem e instância de processos, ou seja, define quais elementos um processo deve possuir, como a definição de tarefas para o processo, define também o fluxo de trabalho dessas tarefas, fornecendo informações para que o processo possa ser implementado em um ambiente de engenharia de software centrado em processos. Capítulo 5 Integração entre Ambiente de Agentes e Ambiente de Engenharia de Software Uma arquitetura construída para que os agentes que são executados no framework JADE possam ter seu ciclo de vida controlados através de interfaces do e-webproject, utilizando a plataforma WEB/Internet, é apresentada neste Capítulo. Capítulo 6 Implantação do processo de modelagem e instância de processos apoiado por agentes de software No Capítulo 6 é apresentada a forma como foi realizada a implementação do serviço que torna possível a modelagem e instância de novos processos dentro do e-webproject. A modelagem do processo foi implementada utilizando a tecnologia Java com Java servlet e interfaces JSP e a instância do processo foi implementada utilizando a tecnologia de agentes em Java persistindo no framework JADE. 23

26 Capítulo 7 Considerações Finais Este Capítulo apresenta os resultados e conclusões obtidos pelo estudo e a definição de trabalhos futuros. Apêndice A Código fonte da arquitetura de integração do framework de agentes JADE com o e-webproject. No apêndice A são anexados os códigos fonte do agente instanciador, representando a estrutura criada para que o e-webproject seja integrado ao JADE. É apresentado também o código fonte da busca de agentes de serviço no repositório de agentes do framework, representando o controle dos agentes através da interface do ambiente de engenharia de software. 24

27 CAPÍTULO 2 AMBIENTES DE ENGENHARIA DE SOFTWARE 2.1 Ambientes de Engenharia de Software Centrado em Processos Ambientes de engenharia de software centrado em processos, ou processcentered software engineering enviroments PSEEs, são ambientes que têm como objetivo suportar as atividades do desenvolvimento de software (CUGOLA, GHEZZI, 1998). Estes ambientes exploram uma representação explícita do processo, chamado modelo de processo, que especifica como conduzir as atividades do processo, os papéis e tarefas dos desenvolvedores de software e como usar e controlar as ferramentas de desenvolvimento de software (AMBRIOLA et al, 1997; SOUZA, 2001). PSEEs podem integrar diversas ferramentas de desenvolvimento em um único ambiente para suportar o desenvolvimento do processo (KNEUPER, 2001). No desenvolvimento de sistemas de software, tarefas como planejamento, execução, gerenciamento, controle e melhoria das atividades relacionadas à construção do software devem ser consideradas. Essas tarefas podem ser organizadas na forma de um processo de software (SPICE, 1995; FUGGETA et al, 1997; PRESSMAN, 1997; BARTHELMESS, 2002; EMAN, 2001). Nos primeiros anos da Engenharia de Software, o termo processo de software era utilizado para denotar o processo de desenvolvimento de software como um todo. Porém, com o passar do tempo, outros termos foram surgindo, como processo de gerenciamento, processo de garantia da qualidade, processo de planejamento de projetos, etc. Esses termos também foram apresentados como responsáveis pelo produto final da construção do software (SANT`ANNA, 2000). 25

28 Um processo de software composto de um conjunto de processos capazes de conduzir a organização envolvida com a construção de produtos de software com qualidade e custos preditíveis, de forma eficiente, gerenciada e com possibilidade de melhoria constante pode ser chamado de processo de engenharia de software. Ambiente de Engenharia de software pode ser caracterizado como um conjunto de ferramentas de desenvolvimento de software, para serem utilizadas pelos projetos de uma organização, suportando o processo de engenharia de software de forma consistente (SPICE, 1995). Esses ambientes devem apoiar a execução de um processo de engenharia de software que deve ser moldado para se adequar às características da organização que o emprega, isto é, estabelecer quais processos o compõe, levando em consideração a ordem em que são executados e os responsáveis pela execução de cada um (ELLMER, 1996; SANT`ANNA, 2000; CEREJA JUNIOR, 2003). O processo de software, conforme definido anteriormente, deve ser bem estabelecido, permitindo a utilização de ferramentas, métodos e a participação de pessoas nas tarefas do desenvolvimento de software.(fuggeta et al, 1997) Um processo bem definido pode ser utilizado para evitar eventualidades catastróficas ao projeto e como mecanismo de aprendizado (melhoria na cultura das pessoas). À medida que o projeto é desenvolvido, os métodos utilizados são melhorados para atender as necessidades que vão surgindo, estas melhorias são incorporadas à cultura das organizações (BORGES, PAULA FILHO, 2003; BRIAND et al, 2002). Para que um ambiente de engenharia de software seja efetivo em seu objetivo principal, deve ter recursos flexíveis e abrangentes, dando suporte eficiente e de forma integrada ao processo de engenharia de software. Recursos como interoperabilidade, extensibilidade, melhoria aos passos, flexibilidade, rapidez, eficiência, capacidade de suportar uma grande quantidade de usuários e de 26

29 classes diferentes, facilidade de utilização, capacidade de apoiar a visibilidade dos produtos e dos processos, capacidade de apoiar o gerenciamento de forma efetiva e capacidade de apoiar o trabalho cooperativo, podem ser considerados.(sant`anna, 2000; AMBRIOLA, GERVASI, 2001) Existem diversas abordagens de ambientes de desenvolvimento de software com ênfase em processos de software (ARBAOUI et al, 2002), como por exemplo: SPADE (BANDINELLI et al, 1994), ADELE-TEMPO (BELKHATIR et al, 1994), Memphis (VASCONCELOS, WERNER, 1998), ProSoft (REIS, REIS, 1999), HyperCode (PERRY et al, 1996), A.I.P.M Fusion (SANTANDER et al, 1997), CAGIS (WANG, HANSSEN, 2001), EPOS (JACCHERI et al., 1992) (NGUYEN et al, 1997), Merlin (JUNKERMANN et al, 1994), APEL (DAMI et al, 1998) e e-webproject (SANT`ANNA et al, 2002). 2.2 e-webproject O e-webproject (SANT ANNA et al., 2002) é um ambiente de engenharia de software comercial desenvolvido pela SESIS Sistemas de Engenharia de Software, a partir do trabalho de pesquisa Um Ambiente Integrado para o Apoio ao Desenvolvimento e Gestão de Projetos de Software para Sistemas de Controle de Satélite - AMBGES (SANT ANNA, 2000) desenvolvido no Instituto Nacional de Pesquisas Espaciais INPE. O e-webproject é um PSEE que tem como principal função prover ferramentas e um ambiente que possibilite à execução de processos de software. O ambiente tem como principais características: o apoio ao trabalho cooperativo, a gestão de projetos, a execução de processos, a gestão do conhecimento organizacional e apoio à infra-estrutura organizacional (SANT`ANNA, 2002) (BORREGO FILHO et al, 2002) (CEREJA JUNIOR et al, 2002). O ambiente e-webproject propõe um modelo de processo de desenvolvimento, levando em consideração principalmente o ciclo de vida do produto e os grupos participantes. O ambiente apresenta características evolutivas (CEREJA JUNIOR, 2003) e permite a configuração baseada nas necessidades 27

30 organizacionais. Este ambiente utiliza a abordagem de processo do Software Process Improvement and Capability Determination (SPICE, 1995), integrando seus processos de forma adequada à visão de objetos e organizado em áreas de negócio, de maneira a proporcionar apoio eficiente à gerência de projetos. Entre as características do ambiente, pode-se destacar o uso do trabalho cooperativo centrado no processo e o conceito de ambiente ativo ou capacidade de forçar o fluxo de trabalho, o chamado Workflow (GENVIGIR, 2004; CEREJA JUNIOR, 2002; SANT`ANNA, 2000; SILVA et al, 2006). A integração das equipes de trabalho, a utilização de tecnologia para controle dos processos envolvidos e a utilização pelos participantes de um conjunto de serviços oferecidos pela internet são alguns dos benefícios obtidos com utilização do ambiente, os quais podem trazem ganhos de produtividade. Do mesmo modo, os produtos gerados pelo processo de construção de software tendem a atender melhor os aspectos relacionados à qualidade e confiabilidade devido à utilização de modelos de maturidade de software, que inclusive, poderão ser ajustados às necessidades organizacionais (ELLMER, 1996). 28

31 CAPÍTULO 3 AGENTES 3.1 Agentes Definir agentes com um conceito único ou padrão é muito difícil, pois existem varias abordagens e ponto de vista de diferentes autores. Além disso, devido às suas mais diversas aplicações uma definição precisa torna-se cada vez mais complicada e variada (GREEN et al, 1997). Um agente humano é uma pessoa que age por ou no lugar de outra, segundo autoridade por ela outorgada é um representante da pessoa. Estes, geralmente, realizam tarefas determinadas, são especialistas naquilo que fazem, possuem capacidades que outras pessoas não têm, têm acesso a informações relevantes para sua tarefa e as realizam a um custo bem menor do que se pessoas comuns tentassem realizar. Exemplos não faltam como: agentes de seguro, agentes bancários, agentes de viagens e etc. No caso de agentes artificiais, ou agentes de software, as características acima citadas são também aplicáveis apesar de não haver uma definição universalmente aceita. No entanto, o que se tem visto é um consenso no fato de que agentes são entidades que se adaptam a um meio, reagem a ele e provocam mudanças neste meio (SILVA, 2003). A FIPA, Foundation for Intelligent Physical Agents (FIPA, 2005), define agente como uma entidade que reside em um ambiente, interpreta dados através de sensores os quais refletem eventos no ambiente e executam ações que modificam o ambiente. Um agente pode ser software ou hardware puro. Alguns pesquisadores, adotaram duas definições gerais: noção fraca e noção forte de agentes. Na definição de noção fraca de agentes, eles conceituam como sistemas computacionais, sendo hardware ou software, com certas 29

32 propriedades tais como autonomia, habilidade social, reatividade e próatividade. Na noção forte de agentes, mais adotada pelos pesquisadores ligados a área de Inteligência Artificial, possui, além das propriedades acima citadas, noções relacionadas ao comportamento humano tais como o conhecimento, a crença, a intenção e a obrigação. Agente também pode ser categorizado como entidade física ou virtual. Física, seria o software visto sob a perspectiva de sua composição, como conjunto ordenado de instruções de código; virtual seria o software visto sob a perspectiva de execução, ele é uma entidade ativa capaz de provocar eventos. A visão ativa da execução do software para realizar um serviço de processamento pode ser definida como componentes de softwares, que é o objeto deste estudo. No geral, agentes seriam componentes de software autônomos que atuam em determinado ambiente de forma a interagir com este e também com outros agentes (CASILLO, SANT`ANNA, 2004; SILVA, 2003), além de produzir ações e percepções sem requerer intervenções humanas constantes. Numa abordagem mais aplicada à Inteligência Artificial, um agente ideal teria que ser capaz de funcionar continuamente e adquirir experiências e conhecimentos acerca do ambiente que está interagindo. Ou seja, ser capaz de aprender e tomar decisões a partir de situações diferentes. Pode-se dizer algumas propriedades que são essenciais para uma melhor caracterização de agente. Uma delas é a autonomia, que o agente deve ter de tomar decisões e ações importantes para a conclusão de uma tarefa ou objetivo sem a necessidade da interferência do ser humano ou qualquer outra entidade, isto é, ser capaz de agir independentemente com seu ambiente através de seus próprios sensores ou com as suas próprias percepções com o objetivo de realizar alguma tarefa seja ela externa ou gerada por ele próprio; operam sem a intervenção humana e tem algum tipo de controle sobre suas ações e seu estado interno. Associado à autonomia está a pró-atividade, que nada mais é do que a capacidade que o agente deve ter de tomar iniciativas. Eles não respondem simplesmente de 30

33 acordo com o meio, mas podem até mesmo alterá-los. Têm a capacidade de exibir comportamentos baseados em objetivos. O agente pode apresentar também características como reatividade que é a capacidade de reagir rapidamente a alterações no ambiente, ou seja, percebe o meio e responde de modo oportuno e robusto, para ser capaz de tomar decisões baseando-se em informações incompletas ou escassas, lidar com erros e ter uma capacidade de adaptação ou aprendizagem através da experiência. Deve ser também capaz de se comunicar com repositórios de informações, como por exemplo outro agente ou o próprio ambiente, a fim de alcançar seus objetivos. Outra característica importante que o agente pode possuir é o raciocínio, talvez o aspecto mais importante para distinguir um agente inteligente dos outros agentes. Afirmar que um agente tem raciocínio significar dizer que ele tem a capacidade de analisar e inferir baseando-se no seu conhecimento atual e nas suas experiências. Esse raciocínio pode ser: Baseado em regras - onde eles usam um conjunto de condições prévias para avaliar as condições no ambiente externo. Baseado em conhecimento - onde eles têm à disposição grandes conjuntos de dados sobre cenários anteriores e ações resultantes, dos quais eles deduzem seus movimentos futuros. Por fim, deve haver uma capacidade de cooperação: agentes podem, e devem, trabalhar junto para mútuo benefício na execução de uma tarefa complexa e um comportamento adaptativo, no qual possa examinar o meio externo e adaptar suas ações para aumentar a probabilidade de ser bem sucedido em suas metas (JENNINGS et al, 1996; JENNINGS, 2000). Para garantir uma maior segurança e confiança ao usuário de que o agente vai representar fielmente seu papel com precisão é fundamental também um alto grau de confiabilidade por parte do agente. 31

34 Contudo, um agente não precisa ter todas essas características ao mesmo tempo. Existem agentes que possuem algumas, outros que possuem todas, o certo é que atualmente existe pouca concordância sobre a importância dessas propriedades e se é necessária sua obrigatoriedade para a caracterização de um agente. O consenso é que essas características tornam um agente muito diferente de simples programas e objetos. 3.2 Categoria de Agentes Para uma melhor compreensão da aplicabilidade da tecnologia de agentes, é interessante falar sobre os diversos tipos de agentes (Wang e Dongming, 2001) (Jennings, 1995) e suas mais variadas diferenças para que se tenha uma melhor noção de utilidade no emprego dos mesmos. É possível fazer uma classificação de agentes de acordo com vários aspectos como quanto à mobilidade, quanto ao relacionamento entre agentes e quanto à capacidade de raciocínio. Agentes Móveis: são agentes que tem a mobilidade como característica principal. Isto é, uma capacidade de mover-se seja por uma rede interna local (intranet) ou até mesmo pela Web, transportando-se pelas plataformas levando dados e códigos. Seu uso tem crescido devido alguns fatos como uma heterogeneidade cada vez maior das redes e seu grande auxílio em tomadas de decisões baseadas em grandes quantidades de informação. Agentes Situados ou Estacionários: são aqueles opostos aos móveis. Isto é, são fixo em um mesmo ambiente e ou plataforma. Não se movimentam em uma rede e muito menos na Web. Agentes Competitivos: são agentes que competem entre si para a realização de seus objetivos ou tarefas. Ou seja, não há colaboração entre os agentes. 32

35 Agentes Coordenados ou Colaborativos: agentes com a finalidade de alcançar um objetivo maior, realizam tarefas específicas, porém coordenando-as entre si de forma que suas atividades se completem. Agentes Reativos: agentes que reagem a estímulos sem ter memória do que já foi realizado no passado e nem previsão da ação a ser tomada no futuro. Não tem representação do seu ambiente ou de outros agentes e são incapazes de prever e antecipar ações. Geralmente atuam em sociedades como uma colônia de formiga, por exemplo. Baseiam-se muito também na teoria do caos na qual se afirma que até mesmo no caos existe uma certa organização. No caso da formiga, por exemplo, uma única não apresenta muita inteligência mas, quando age no grupo todo, ele se comporta como uma entidade com certa inteligência. Ou seja, a força de um agente reativo vem da capacidade de formar um grupo e construir colônias capazes de adaptar-se a um ambiente. Agentes Cognitivos: esses, ao contrário dos agentes reativos, podem raciocinar sobre as ações tomadas no passado e planejar ações a serem tomadas no futuro. Um agente cognitivo é capaz de resolver problemas por ele mesmo. Ele tem objetivos e planos explícitos os quais permitem atingir seu objetivo final. Para que isso se concretize, cada agente deve ter uma base de conhecimento disponível, que compreende todos os dados e todo o know-how para realizar suas tarefas e interagir com outros agentes e com o próprio ambiente. Sua representação interna e seus mecanismos de inferência o permitem atuar independentemente dos outros agentes e lhe dão uma grande flexibilidade na forma de expressão de seu comportamento. Além disso, devido à sua capacidade de raciocínio baseado nas representações do mundo, são capazes de ao mesmo tempo memorizar situações, analisá-las e prever possíveis reações para suas ações. Devido à quantidade de características e o grau de dificuldade de implementação que um agente pode ter, foram criados arquiteturas que 33

36 possibilitam o desenvolvimento e gestão de agentes, a fim de minimizar esforços para a criação de agentes de software. 3.3 Framework de Agentes Frameworks de agentes são ambientes para desenvolvimento de aplicações baseada em agentes conforme as especificações da FIPA (FIPA, 2005), para auxiliar na interoperabilidade de sistemas de agentes. O principal benefício é simplificar e facilitar o desenvolvimento de sistemas de agentes, garantindo um padrão de interoperabilidade entre eles, através de um abrangente conjunto de agentes de serviços de sistema os quais tanto facilitam como possibilitam a sua comunicação. Segundo a FIPA, os serviços que devem existir são os serviços de nomes (naming service) e páginas amarelas (yellow-page service), transporte de mensagens, serviços de codificação e decodificação de mensagens e uma biblioteca de protocolos de interação pronta para ser usada. Aspectos que não fazem parte do agente em si e que são independentes das aplicações tais como transporte de mensagens, codificação e interpretação de mensagens e ciclo de vida dos agentes, também devem fazer parte do framework. O modelo de plataforma representado pela Figura 3.1 possibilita a criação e controle de agentes de software. A partir dele pode-se pensar em como agentes de software podem existir e interagir entre si, para auxiliar a resolver um problema ou extrair uma informação desejada de um determinado sistema ou ambiente. 34

37 FIGURA Modelo Padrão de Plataforma de Agentes definido pela FIPA. FONTE: Adaptado de JADE (2005). 3.4 Jade Jade, Java Agent DEvelopment framework (JADE, 2005), é um ambiente para desenvolvimento de aplicações baseada em agentes que segue as especificações da FIPA. Foi desenvolvido pelo CSELT da Universidade de Parma na Itália. O Jade tem como objetivo simplificar e facilitar o desenvolvimento de sistemas com agentes, garantindo um padrão de interoperabilidade entre eles através de um abrangente conjunto de agentes de serviços de sistema, de acordo com as especificações da FIPA tais como: serviço de nomes (naming service) e páginas amarelas (yellow-page service). De acordo com (BELLIFEMINE, 2003), Jade foi escrito em Java devido a características particulares da linguagem particularmente pela programação orientada a objeto. Foram desenvolvidos tanto pacotes Java com funcionalidades prontas pra uso, quanto interfaces abstratas para se adaptar de acordo com a funcionalidade da aplicação de agentes. FIPA nada especifica sobre as estruturas internas dos agentes, fato que foi uma escolha explícita em conformidade com a opinião de que a interoperabilidade pode ser garantida apenas especificando os comportamentos externos dos agentes (Ex: ACL, protocolos, linguagens de conteúdo e etc.) (FIPA, 2005). 35

38 Para o Jade, um agente é autônomo e independente de processo, tem uma identidade e requer comunicação com outras agentes, seja ela por colaboração ou por competição, para executar totalmente seus objetivos (JADE, 2003). Em outras palavras, pode-se concluir que o Jade é absolutamente neutro no que diz respeito à definição de um agente, ou seja, ele não limita ou especifica que tipo de agente pode ser construído pela plataforma. Em termos mais técnicos um agente em Jade funciona como uma thread que emprega múltiplas tarefas ou comportamentos e conversações simultâneas. Esse agente Jade é implementado como uma classe Java chamada Agent que está dentro do pacote jade.core. Essa classe Agent atua como uma super classe para a criação de agentes de software definidos por usuários. Ela provê métodos para executar tarefas básicas de agentes, tais como: Passagens de mensagens usando objetos ACLMessage (seja direta ou multicast); Suporte completo ao ciclo de vida dos agentes, incluindo iniciar ou carregar, suspender e matar (killing) um agente; Escalonamento e execução de múltiplas atividades concorrentes; Interação simplificada com sistemas de agentes FIPA para a automação de tarefas comuns de agentes (registro no DF, etc). Do ponto de vista do programador, um agente JADE é simplesmente uma instância da classe Agent, no qual os programadores ou desenvolvedores deverão escrever seus próprios agentes como subclasses de Agent, adicionando comportamentos específicos de acordo com a necessidade e objetivo da aplicação, através de um conjunto básico de métodos, e utilizando as capacidades herdadas que a classe Agent dispõe tais como mecanismos básicos de interação com a plataforma de agentes. O modelo computacional de um agente em JADE é multitarefa, onde as tarefas (ou comportamentos) são executadas concorrentemente. Cada funcionalidade ou serviço provido por um 36

39 agente deve ser implementado como um ou mais comportamentos. Esses comportamentos podem ser vários, uma vez que o JADE permite uma variedade de comportamentos em um mesmo agente. Cada agente possui a autonomia implementada pela possibilidade de controlar completamente sua thread de execução. O gerenciador de ciclo de vida é o meio que os agentes utilizam para determinar seu estado atual (ativo, suspenso, etc). FIGURA 3.2 Ciclo de Vida dos Agentes como definido pela FIPA. FONTE: Adaptado de JADE (2005). Um agente JADE pode está em um dos vários estados de acordo com ciclo de vida (Agent Platform Life Cycle) das especificações FIPA, representado pela Figura 3.2. Esses estados são representados em JADE como constantes estáticas da classe Agent. São eles: AP_INIATED: o objeto da classe Agent foi instanciado, mas ainda não se registrou no AMS, não tem nome ou endereço e não pode comunicar com outros agentes. 37

40 AP_ACTIVE: o objeto da classe Agent está registrado no AMS, tem nome formal e endereço e tem acesso a todas as funcionalidades do JADE. AP_SUSPENDED: o objeto da classe Agent está no momento interrompido. Sua thread interna está suspensa e nenhum comportamento está sendo executado. AP_WAITING: o objeto da classe Agent está bloqueado, esperando por alguma coisa. Sua thread interna está dormindo (sleeping) sob um monitor Java e irá acordar quando alguma condição ocorrer (geralmente quando uma mensagem chega). AP_DELETED: o agente está definitivamente apagado ou encerrado. Sua thread interna terminou sua execução, e o agente não está mais registrado no AMS. AP_TRANSIT: um agente móvel entra nesse estado enquanto estiver migrando para uma nova localização. O sistema continua a armazenar mensagens em um buffer que serão enviadas para essa nova localização. AP_COPY: esse estado é usado internamente pelo JADE para agentes que foram clonados. AP_GONE: esse estado é usando internamente pelo JADE quando um agente móvel migrou para outra localização e encontra-se em um estado estável. As ações ou comportamentos que um agente desempenha dentro de um sistema são fundamentais para que o objetivo final da aplicação seja alcançado. No JADE, o desenvolvedor que pretende implementar um agente deve obrigatoriamente herdar a classe Agent e implementar tarefas para o agente escrevendo um ou mais subclasses Behaviour, instanciando-as e adicionando-as ao agente. O framework JADE possui comportamentos prédefinidos para a maioria das tarefas comuns na programação de agentes, tais 38

41 como envio e recebimento de mensagens e até construção de tarefas mais complexas. A estrutura de comportamentos do JADE dá-se através de um escalonador, interno à super classe Agent, que gerencia automaticamente o escalonamento dos comportamentos (behaviours). No escalonamento é utilizada a política de round-robin não preemptivo, em todos os comportamentos disponíveis na fila (BELLIFEMINE, 2003). No escalonamento round-robin cada comportamento adicionado ao agente é colocado em uma fila. Quando esse comportamento passa para o estado de execução, ou seja, o processo passa para a CPU, existe um tempo limite para a sua utilização. Quando esse tempo denominado time-slice ou quantum, expira, sem que antes o processador seja liberado pelo processo, este volta ao estado de pronto, dando a vez para outro processo. Isso permite a execução da classe de um comportamento completo, ou seja, se a tarefa ou comportamento cede sem o controle ter sido completado, ela será re-escalonada no próximo ciclo. Ela poderá não ser re-escalonada, caso esteja bloqueada (um behaviour pode se bloquear no instante em que espera mensagens para evitar desperdício de tempo de CPU e evitar uma espera ocupada). Em outras palavras, um comportamento é executado por vez por um determinado tempo (quantum). Quando acaba esse tempo, o comportamento pode voltar para o fim da fila, caso não tenha acabado de executar sua tarefa. O fato de ser não preemptivo significa dizer que não existe prioridade entre os comportamentos, ou seja, cada comportamento adicionado deve ir para o fim da fila e todos têm a mesma fatia de tempo. O comportamento de um agente é definido pela classe Behaviour que é uma classe abstrata do JADE, disponível no pacote jade.core.behaviours. Uma classe abstrata é uma classe que possui alguns métodos implementados e outros não, e não pode ser instanciada diretamente. O principal método da classe Behaviour é o action (). É nele que serão implementadas as tarefas ou 39

42 ações que este comportamento irá tomar. Outro importante método é o done (), que é usado para informar ao escalonar do agente se o comportamento foi terminado ou não. Ele retorna true caso o comportamento tenha terminado e assim este é removido da fila de comportamentos, e retorna false quando o comportamento não tenha terminado obrigando o método action () a ser executado novamente. Outros importantes atributos e métodos da classe Behaviour são: protected Agent myagent este atributo retorna o agente a qual esse comportamento pertence. void block () Bloqueia esse comportamento. Pode ser passado como parâmetro um o tempo de bloqueio em milisegundos: void block (long tempo). void restart () Reinicia um comportamento bloqueado. void reset () Restaura o estado inicial do comportamento. boolean isrunnable () Retorna se o comportamento está bloqueado ou não. O JADE possui várias classes de comportamentos prontas para uso pelo desenvolvedor, adequando-as de acordo com a necessidade específica do agente. Hierarquicamente, elas estão estruturadas da seguinte forma: Classe jade.core.behaviours.behaviour Classe jade.core.behaviours.compositebehaviour Classe jade.core.behaviours.fsmbehaviour Classe jade.core.behaviours.parallelbehaviour Classe jade.core.behaviours.sequentialbehaviour Classe jade.core.behaviours.receiverbehaviour 40

43 Classe jade.core.behaviours.simplebehaviour Classe jade.core.behaviours.cyclicbehaviour Classe jade.core.behaviours.oneshotbehaviour Classe jade.core.behaviours.senderbehaviour Classe jade.core.behaviours.tickerbehaviour Classe jade.core.behaviours.wakerbehaviour Como classes mais gerais temos a CompositeBehaviour, ReceiverBehaviour e a SimpleBehaviour; Sendo que algumas destas são subdividas em outras classes para tornar mais específicas suas finalidades. O diagrama representado na Figura 3.3 apresenta as classes CompositeBehaviour e SimpleBehavior, as quais são derivadas da classe Behaviour, a classe ReceiverBehaviour foi omitida do diagrama por não conter classes filhas. 41

44 FIGURA 3.3 Modelagem dos Comportamentos dos Agentes. FONTE: (JADE, 2005). A classe ReceiverBehaviour implementa um comportamento para recebimento de mensagens ACL. Ela encapsula o método receive () como uma operação atômica, ou seja, realiza inteiramente sem nenhuma interrupção, tendo o comportamento encerrado quando uma mensagem ACL é recebida. Possui o método getmessage () que permite receber a mensagem. Já a classe CompositeBehaviour é uma classe abstrata para comportamentos, como o próprio nome diz, compostos por diferentes partes. Ela controla internamente comportamentos filhos dividindo seu quantum de execução, de acordo com alguma política de escalonamento. Possui três classes herdadas disponibilizadas pelo JADE. São elas: FSMBehaviour Comportamento composto baseado no escalonamento por máquina de estados finitos (Finite State Machine). O FSMBehaviour executa cada comportamento filho de acordo com uma máquina de estados finitos 42

45 definido pelo usuário. Mais especificamente cada comportamento-filho representa um estado na máquina de estados finitos. Ela fornece métodos para registrar estados (sub-comportamentos) e transições que definem como se dará o escalonamento desses comportamentos-filho. ParallelBehaviour - Comportamento composto com escalonamento concorrente dos comportamentos filhos. ParallelBehaviour executa seus comportamentos filhos concorrentemente e finaliza quando uma condição particular em seus sub-comportamentos é atingida. Por exemplo, quando um número X de comportamentos-filho terminarem ou um comportamento-filho qualquer terminar ou quando todos os comportamentos filho terminarem. SequentialBehaviour - Comportamento composto com escalonamento seqüencial de comportamentos-filho. Ou seja, os comportamentos-filho são executados numa ordem seqüencial e só é encerrado quando o ultimo comportamento-filho é finalizado. Por último, temos a classe abstrata SimpleBehaviour. Ela é um comportamento atômico. Isto é, modela comportamentos que são feitos para serem únicos, monolíticos e que não podem ser interrompidos. Possui quatro classes herdadas disponibilizadas pelo JADE. São elas: CyclicBehaviour Comportamento atômico que deve ser executado sempre. Essa classe abstrata pode ser herdada para criação de comportamentos que se manterão executando continuamente. No caso, o método done () herdado da super classe Behaviour, sempre retorna false, o que faz com que o comportamento se repita como se estivesse em uma repetição infinita. TickerBehaviour Comportamento executa periodicamente tarefas específicas. Ou seja, é uma classe abstrata que implementa um comportamento que executa periodicamente um pedaço de código definido pelo usuário em uma determinada freqüência de repetições. No caso, o desenvolvedor redefine o método ontick () e inclui o trecho de código que deve ser executado 43

46 periodicamente. O período de ticks é definido no construtor da classe em milisegundos. WakerBehaviour - Comportamento que é executado depois de determinado tempo expirado. Em outras palavras, é uma classe abstrata que uma tarefa OneShot que é executada apenas depois que determinado tempo é expirado. No caso, a tarefa é inserida no método handleelapsedtimeout () o qual é chamado sempre que o intervalo de tempo é transcorrido. OneShotBehaviour Comportamento atômico que é executado uma única vez. Essa classe abstrata pode ser herdada para a criação de comportamentos para tarefas que precisam ser executadas em apenas uma única vez. 3.5 Agentes Auxiliando Processos de Engenharia de Software Como ferramenta de apoio aos processos existentes dentro de um ambiente, é útil o uso de agentes de software para a realização de tarefas específicas a cada processo (WOOLDRIDGE, CIANCARINI, 1999; SANT`ANNA, 2000; MURTA, 2000). Novas tecnologias vêm sendo desenvolvidas, onde plataformas de criação e manipulação de agentes de software podem ser utilizadas para suprir as necessidades do ambiente. A principal contribuição dessas plataformas é que elas propõem uma infra-estrutura de suporte e desenvolvimento de sistemas multiagentes, tornando a implementação mais simples e robusta. Ambientes que suportam processos de engenharia de software podem apresentar problemas no planejamento, execução e controle das atividades dos processos. Para tentar sanar eventuais problemas, propõem-se as seguintes características para os agentes: autonomia, reatividade, próatividade e habilidades de interação, podendo assim, os agentes exercerem as atividades planejadas respondendo a mudanças no ambiente por qualquer atividade do processo (PETRIE, 2000; WOOLDRIDGE, 2000; TOMBROS, GEPPERT, 1995). 44