04 Cap 05

97
5 A linguagem de padres
We must start decomposing a system by objects, and then use the resulting structure as the framework for expressing the other perspective. (Booch)
Com a evoluo do desenvolvimento de SMAs, os engenheiros de software vo enfrentando novos problemas para resolver a separao de concerns do agente. De fato, apesar de essa separao ser crtica para os desenvolvedores de SMAs, alcan-la em SMAs reais no algo trivial. Dependendo da complexidade do agente, um aspecto do agente afeta no apenas as classes kernel, como tambm outros aspectos do agente (Seo 3.6.4). O captulo anterior apresentou aos projetistas de
PUC-Rio - Certificao Digital N 0016030/CA
SMAs as diretrizes bsicas para a definio de concerns do agente que devem ser separados e a ordem em que devem ser tratados. Entretanto, o mtodo arquitetural no oferece diretrizes detalhadas sobre como estruturar cada aspecto do agente. O refinamento do mtodo proposto no captulo anterior levanta algumas questes importantes, como: (i) (ii) Como definir a estrutura interna de cada aspecto do agente? como definir os diferentes relacionamentos entre classes kernel e aspectos do agente? (iii) com refinar os aspectos do agente no contexto de diferentes papis e tipos de agente? (iv) como compor vrios aspectos e resolver conflitos de composio entre eles? (v) como implementar os aspectos do agente usando uma linguagem orientada a aspectos? Neste captulo, apresentada uma linguagem de padres a fim de responder a essas questes, fornecendo diretrizes mais especficas para cada concern do agente. Os padres podem ser vistos como minimtodos para lidar com as especificidades dos aspectos do agente. A linguagem de padres orienta em detalhes como ir de
98
objetos a agentes usando aspectos. Os padres orientados a aspectos desacoplam as propriedades de agente da funcionalidade bsica dos objetos de agente. De fato, os padres de projeto so um veculo importante para o suporte construo de sistemas orientados a aspectos com reusabilidade e manutenibilidade (Seo 2.1). A necessidade de padres de projeto ainda maior para o desenvolvimento de software orientado a aspectos uma vez que esse paradigma oferece muitas formas de decompor e compor um sistema de software (Seo 2.2.3). Apesar de o paradigma orientado a aspectos defender o suporte a uma melhor separao de concerns, ainda no est claro como alcanar isso em termos de abstraes orientadas a aspectos. O desafio fica ainda maior ao usar aspectos para crosscutting concerns especficos a domnios, como concerns do agente. No entanto, conforme mencionado anteriormente (Seo 2.2.3), experincias com boa prtica em
desenvolvimento de software orientado a aspectos so bastante limitadas e ficaram restritas a crosscutting concerns comuns ou triviais, como auditoria [12, 88], rastreamento [12, 88], distribuio [226, 88], persistncia [226, 88], concorrncia [141] e tratamento de excees [87, 97, 161]. Alm disso, eles foram quase sempre estudados de forma isolada. H pouca compreenso sobre o uso de aspectos com vrios concerns em um sistema de software. A linguagem de padres proposta guia os projetistas em relao a como estruturar os vrios concerns do agente nos nveis do projeto detalhado e da implementao. A linguagem composta por sete padres: (1) o padro Kernel do Agente, (2) o padro Interao, (3) o padro Adaptao, (4) o padro Autonomia, (5) o padro Papel, (6) o padro Mobilidade e (7) o padro Aprendizagem. O padro Kernel do Agente o padro central da linguagem uma vez que todos os outros baseiam-se em sua estrutura e comportamento. Esse padro define o objeto alvo que desejamos transformar em um agente, introduzindo as propriedades de agente. Ele tambm descreve as classes adicionais para representar o conhecimento do agente. Cada padro define uma soluo detalhada para introduzir uma propriedade de agente ao objeto alvo. A linguagem tambm mostra como juntar todos os padres orientados a aspectos.
99
O primeiro alvo da linguagem de padres todos os engenheiros de software de aplicaes multiagentes que precisam definir e implementar as diferentes propriedades de agente que regem seus sistemas. Tambm pode ser interessante para os desenvolvedores de diferentes tipos de frameworks de SMAs (Seo 3.7) usar os padres propostos, uma vez que podem decidir incorporar as solues orientadas a aspectos diretamente em suas arquiteturas. As contribuies deste captulo foram parcialmente descritas nos trabalhos [90]. No entanto, esses trabalhos no apresentam em detalhes as solues orientadas a aspectos propostas, porque seu foco a apresentao do mtodo arquitetural (Captulo 4). Alm disso, no so apresentados no formato de padres. Apenas mostram uma verso preliminar das solues de padro apresentadas aqui. Os padres surgiram a partir da aplicao extensiva do mtodo em diferentes sistemas
(Captulo 7) e sua implementao em duas linguagens orientadas a aspectos diferentes, AspectJ e Hyper/J. O estudo comparativo da implementao das duas linguagens pode ser encontrado nos trabalhos [42, 260]. Esses trabalhos mostram como a implementao dos padres orientados a aspectos no sistema Portalware (Captulo 4) pode ser facilmente mapeada em uma implementao de Hyper/J (Captulo 7). A linguagem de padres tambm foi publicada como um relatrio tcnico e enviada a ACM Transactions on Software Engineering and Methodology (TOSEM). Alguns relatrios tcnicos e trabalhos apresentados em workshops documentam as diferentes fases do desenvolvimento da linguagem de padres [81, 84, 94]. O restante deste captulo est organizado da seguinte forma. A Seo 5.1 apresenta o exemplo usado ao longo do captulo para ilustrar os padres de projeto. A Seo 5.2 apresenta uma viso geral da linguagem de padres orientada a aspectos. As Sees de 5.3 a 5.9 apresentam os padres de projeto. A Seo 5.10 discute as questes de implementao e implantao. J a Seo 5.11 introduz os trabalhos relacionados. A Seo 5.12 apresenta o resumo do captulo.
100
5.1 Expert Committee: um estudo de caso Esta seo introduz um SMA a fim de ilustrar os padres apresentados neste captulo. Esse prottipo um sistema de gerenciamento de conferncia, um exemplo clssico de uma aplicao baseada em agentes de software [57, 253]. Esse sistema inclui vrios concerns do agente, tpicos de muitas aplicaes orientadas por agente existentes. Ele derivado de um estudo de caso realizado no Laboratrio de Engenharia de Software na PUC-Rio no Brasil, doravante Expert Committee (EC). EC um sistema multiagentes que oferece suporte ao gerenciamento de envios de trabalho e ao processo de reviso de uma conferncia. Os agentes de software foram introduzidos ao sistema de EC a fim de auxiliar os pesquisadores nas atividades que consomem tempo nos envios de trabalho e processos de reviso.
Os agentes de EC so assistentes de software que representam os autores dos trabalhos, a chair, os membros do comit do programa e os revisores e que coordenam suas atividades. So atribudos diferentes papis a cada usurio do EC, mas as principais so: (i) autor do trabalho, (ii) revisor, (iii) membro do comit do programa e (iv) chair. O papel de chair possui planos para a distribuio de propostas de reviso; o papel de revisor e membro do comit do programa tm planos para a avaliao das propostas da chair. A chair, os membros do comit do programa e os revisores negociam entre si a realizao das revises. H outros planos para tratar da carga de trabalho do usurio e de convites a novos revisores. O conhecimento de agente modela o mundo exterior a fim de refletir as preferncias do usurio e o status do processo de reviso. O sistema EC tambm incorpora os agentes de informao. Cada tipo de agente oferece servios diferentes, mas todos so interativos, adaptativos e autnomos. Cada tipo de agente possui tambm diferentes propriedades de agncia especficas a aplicaes. Para simplificar, esta seo enfatiza a descrio dos agentes de usurio. Esses agentes possuem outras propriedades, incluindo papis, aprendizagem e mobilidade. Os agentes de usurio interagem com o ambiente usando duas infra-estruturas de comunicao: JADE [20] e uma arquitetura blackboard [155]. O blackboard usado para a comunicao interna entre os agentes, e a infra-estrutura JADE usada para a
101
interao com agentes externos ao sistema. So usadas duas linguagens de comunicao: ACL [75] e uma linguagem de comunicao interna, tambm em conformidade com a especificao FIPA [75]. Os servios de agente tambm podem ser acessados diretamente chamando as classes Agent. Os agentes de usurios monitoram os objetos do ambiente a fim de adaptar seu conhecimento e comportamento e aprender sobre as preferncias dos usurios. Eles observam os eventos associados aos componentes de banco de dados, os objetos GUI e os componentes lgicos do negcio. Esse comportamento sensorial e as instrues explcitas do usurio disparam a adaptao do comportamento e do conhecimento do agente. Os agentes aprendem as preferncias do usurio ao observ-lo, observar os componentes da aplicao e a colaborao com outros agentes. Essa experincia de aprendizagem indireta porque
o agente criar seu conhecimento por meio dos resultados das negociaes. O aprendizado automtico usado para tratar da aquisio de conhecimento. So usadas diferentes tcnicas de aprendizagem no sistema EC: Temporal Difference Learning (TD-Learning) [172] e Least Mean Squares (LMS) [172]. TD-Learning usada pelo papel de revisor a fim de aprender as preferncias do usurio em relao aos assuntos que gosta de revisar. LMS usado pela chair para aprender sobre as preferncias do revisor. Este captulo mostra os diferentes cenrios que envolvem cada concern do agente e por que o projeto orientado a objetos para propriedades de agente resulta em crosscutting concerns. Ele tambm apresenta como usar as solues dos padres para modularizar os crosscutting concerns do agente. O sistema EC foi escolhido para ilustrar os padres de projeto propostos neste captulo porque mais complexo do que o sistema Portalware (Seo 4.1). Alm disso, esse exemplo envolve cenrios interessantes para explorar todas as solues de padres. A Figura 37 descreve a
arquitetura orientada a aspectos dos agentes de usurio do EC. Ela mostra a natureza crosscutting dos concerns do agente. Essa arquitetura mais complexa do que as arquiteturas de agente do sistema Portalware em vrios sentidos: (i) inclui todas as propriedades adicionais e de agncia, (ii) possui uma interface sensorial para observar eventos externos nos objetos do ambiente, (iii) tambm incorpora a interface crosscutting LearningKnowledge, (iv) incorpora diferentes tcnicas de aprendizagem
102
e (v) os papis chair e revisor so associados s propriedades adicionais e de agncia assim, precisam ser definidos aspectos adicionais e de agncia para esses papis.
Agenthood
Knowledge Adaptation Adaptation Environment Behavior Adaptation
Additional Properties
Learning Information Gathering Learning Knowledge
Message Reception
Sensory Interaction
Knowledge Updating Message Sending Kernel
Services
Traveling Mobility
Extrinsic Collaboration Knowledge Protocol
Legend:
component
Goal Creation
Autonomy
Execution Autonomy Collaboration
Role Binding
aspectual component
crosscutting interface normal interface
Figura 37. A arquitetura orientada a aspectos dos agentes do EC.
5.2 A linguagem de padres: uma viso geral O problema tratado pela linguagem de padres envolve o projeto detalhado de agentes de software, enfatizando a separao de concerns. Elas se baseiam em aspectos para separar as propriedades de agente e permitem a composio flexvel na construo de agentes heterogneos (Seo 5.2.1). Cada padro possui um propsito especial e trata de uma propriedade de agente especfica. A linguagem de padres contm informaes conectivas teis que ajudam a validar os padres e a aplic-los (Seo 5.2.3).
103
5.2.1 O propsito O propsito bsico da linguagem de padres oferecer suporte modularizao de crosscutting concerns do agente. Ela forma a base para a separao e a composio de concerns do agente, oferecendo o desenvolvimento de agentes com manutenibilidade e reusabilidade. O propsito no fornecer solues para o mecanismo usado para implementar cada concern do agente. Cada concern do agente requer mecanismos de implementao especficos e uma linguagem de padres adicional. Por exemplo, o padro de Lange [10] trata de alguns problemas especficos relacionados mobilidade do agente. Nesse sentido, os padres propostos neste captulo podem estar conectados a outros padres que tratam de problemas mais especficos para um dado concern. Eles apresentam solues orientadas a aspectos
para a segregao de concerns do agente.
5.2.2 Por que so padres de projeto? As solues propostas aqui so padres por algumas razes. Primeiro, os padres foram identificados e abstrados com base em sua aplicao em trs SMAs em diferentes domnios de aplicao por vrios grupos de desenvolvedores [51, 57, 89] (Captulo 7), e no estudo de algumas arquiteturas de implementao (Seo 3.7). Como conseqncia, podem ser aplicados a uma grande variedade de aplicaes de agente. Segundo, apesar de os padres serem originais, uma vez que usam solues orientadas a aspectos, o uso de aspectos dedica-se a resolver os problemas associados a padres orientados a objetos conhecidos para o desenvolvimento de concerns do agente (Seo 3.6). As foras desses padres enfatizam a reusabilidade e manutenibilidade. Por exemplo, o padro Papel melhora a soluo do padro Objeto do Papel [19], que a melhor soluo conhecida para a estruturao de papis do agente [136, 146]. O padro Interao melhora a soluo do padro Adaptador [79], que uma soluo orientada a objetos elegante para a modularizao do concern de interao [137].
104
Alm do mais, os padres foram implementados em duas linguagens orientadas a aspectos diferentes (Seo 5.11). A implementao do padro refina alguns idiomas e padres de aspectos gerais [114, 115]. Como a linguagem de padres independente do framework de implementao de SMAs, muitos desenvolvedores desse tipo de sistema podero empreg-lo.
5.2.3 A estrutura da linguagem de padres A linguagem composta por sete padres de projeto classificados em dois tipos: padres de agncia e padres adicionais. A Figura 38 ilustra a estrutura da linguagem de padres. Um retngulo denota um padro, com as setas representando os relacionamentos entre os padres. Um crculo representa o padro Kernel do Agente
que oferece o contexto no qual todos os demais padres agem. A figura tambm descreve os relacionamentos crosscutting entre os padres de projeto. Apesar de um relacionamento crosscutting representar dois tipos de crosscutting - crosscutting esttico e crosscutting dinmico (Seo 2.2), a Figura 38 no apresenta essa distino. A descrio de cada padro esclarece quando cada tipo de crosscutting usado. Cada padro depende dos padres que afeta; a rede dessas conexes entre os padres que cria a linguagem.
Agenthood Additional Properties
Environment
Adaptation
Mobility
incoming message new message new goal absent knowledge new event
Interaction
outgoing message
Kernel
Learning
absent knowledge new message agent creation collaboration joining
new event
Autonomy
Legend : Crosscuts
Roles
Figura 38. A estrutura da linguagem de padres.
105
Cada padro de projeto est relacionado a mais de um padro. Por exemplo, o padro Interao afeta o padro Kernel e os objetos do ambiente. Quando h uma mensagem saindo de planos de agente ou aes de agente (padro Kernel do Agente), o padro Interao responsvel pela deteco de eventos externos e pelo envio e recebimento de mensagens. Quando h uma mensagem chegando das classes do ambiente, o padro Interao responsvel pelo recebimento de mensagens de forma que o agente possa trat-las e interpret-las. Por outro lado, o padro Adaptao e Autonomia afetam o padro Interao sempre que chega uma nova mensagem. A nova mensagem pode resultar na adaptao de conhecimento (padro Adaptao) e na criao de objetivo (padro Autonomia). A Figura 38 apresenta apenas os inter-relacionamentos de padres bsicos, ou
seja, os relacionamentos dependentes da aplicao. Esses relacionamentos sempre ocorrem e so independentes da complexidade do agente. No entanto, muitos relacionamentos crosscutting aumentam com o aumento da complexidade do agente. Isso uma conseqncia da natureza crosscutting dos concerns do agente (Seo 3.6.4). A Figura 39 mostra relacionamentos crosscutting adicionais para o padro Interao (39a) e o padro Autonomia (39b), os dois aplicados ao exemplo do EC (Seo 5.1). Nesse sistema, a Figura 39a ilustra que as mensagens so enviadas a partir de diferentes componentes do agente: componentes de papel (padro Papel), componentes de mobilidade (padro Mobilidade) e planos de deciso (padro Autonomia). A Figura 39b mostra que o comportamento autnomo de agentes cognitivos do EC afeta elementos de cinco padres. Os padres de projeto so estruturados seguindo os modelos usados na literatura [35, 79] (Seo 2.1.2). Apesar de a incluso de variantes e usos conhecidos no modelo do padro parecer muito extensa, suas descries foram includas para colocar este trabalho de pesquisa em perspectiva, levando em considerao outras contribuies encontradas na literatura. Os padres so expressos usando a notao descrita na Seo 2.2. Omitimos a seo de implementao de cada padro com o objetivo de simplificar sua apresentao. Contudo, introduzimos a seo de implementao dos padres no Apndice I, porque sua implementao em AspectJ tambm uma
106
contribuio deste trabalho. S esto disponveis na literatura experincias usando crosscutting concerns bem conhecidos, como a distribuio, a persistncia e a transao. O Apndice I descreve trechos do cdigo relevantes para a compreenso dos benefcios do padro no nvel da implementao. Alm disso, discute questes importantes sobre a implementao de padres usando AspectJ, uma linguagem orientada a aspectos atualmente em voga.
Agenthood
Agenthood
Adaptation
new goal new message absent knowledge
Mobility
Adaptation
Mobility
new goal new message absent knowledge new event
Interaction
outgoing message
Kernel
absent knowledge
Interaction
outgoing message
Kernel
Learning
new message agent creation
absent knowledge new event collaboration joining
collaboration joining
new event
Autonomy
Roles
Autonomy
Roles
(a) O padro Interao Figura 39. Vrios padres crosscutting.
(a) O padro Autonomia
5.3 O padro Kernel do Agente Inteno. O padro Kernel do Agente descreve a estrutura bsica dos tipos de agente; define as classes para representar o conhecimento intrnseco dos tipos de agente. Tambm conhecido como. Padro Fundao, Padro Esqueleto. Contexto. Os projetistas de SMAs precisam especificar as funcionalidades bsicas dos tipos de agente. Cada tipo de agente possui seu prprio conhecimento intrnseco (Seo 3.2.3). Eles precisam definir o conhecimento intrnseco dos tipos de agente de forma que fique separado do conhecimento extrnseco. Os elementos fundamentais que expressam o conhecimento do agente so suas crenas, objetivos, aes e planos (Seo 3.3.1).
107
Exemplo de motivao. Os agentes do usurio no sistema EC possuem o conhecimento extrnseco e intrnseco. Em relao ao conhecimento intrnseco, cada agente possui crenas, objetivos, aes e planos bsicos. Todos os agentes possuem crenas genricas, incluindo seu identificador, seu nome e a lista de agentes disponveis no ambiente. Os agentes do usurio tm crenas intrnsecas, incluindo o currculo, uma lista de trabalhos e a lista de interesses de pesquisa dos usurios. Eles tm objetivos intrnsecos, como o objetivo de atualizar o currculo do usurio em diferentes instituies de pesquisa medida que ele vai mudando. Em relao ao conhecimento extrnseco, o papel de chair introduz algum conhecimento adicional aos agentes do usurio. Ele inclui conhecimento especfico, como os prazos da conferncia, a lista de trabalhos enviados, a lista de revisores e seus agentes associados etc.
Problema. Como definir a estrutura bsica dos tipos de agente do sistema? Muitas foras so associadas a esse problema de projeto: O projeto do agente deve oferecer suporte definio de separao de conhecimento intrnseco e extrnseco. Alm disso, esses tipos de conhecimento devem ser facilmente compostos. necessria uma soluo flexvel e reutilizvel para facilitar a reutilizao de diferentes partes do conhecimento. Os desenvolvedores de SMAs devem ser capazes de entender e refinar com facilidade o conhecimento de agente bsico. O conhecimento de agente deve ser separado da lgica de controle associada a diferentes propriedades de agente, como autonomia, adaptao e aprendizagem. A prpria estrutura deve identificar um nico componente que representa o agente no sistema. Soluo. Usar abstraes orientadas a objetos para representar a estrutura bsica dos tipos de agente. Usar classes para representar um agente e seus elementos de conhecimento (Seo 4.4.1). A classe Agent especifica a estrutura principal de um agente e pode ser estendida para criar os tipos de agente da aplicao. Cada instncia
Agent
representa um agente e o identifica de forma nica no SMA. Os mtodos
108
representam as aes de agente, enquanto os atributos representam as crenas do agente. Os atributos da classe Agent so usados para representar as crenas gerais, comuns a todos os tipos de agente na aplicao. Os mtodos da classe Agent so usados para atualizar as crenas gerais e implementam as aes gerais do agente. As classes tambm so usadas para representar os elementos do conhecimento de um agente (Figura 40). As subclasses Agent representam os tipos de agente (Seo 4.4.3). As subclasses Agent contm referncias aos elementos do conhecimento intrnseco, enquanto os aspectos contm referncias a elementos do conhecimento extrnseco. A Figura 40 apresenta as principais classes que representam o conhecimento do agente. A Figura 41 ilustra como criar tipos de agente; os aspectos so usados para introduzir o conhecimento extrnseco de forma transparente para o conhecimento intrnseco do agente.
Belief name ... Agent belief1 belief2 ... goals plans toAchieveGoals toPerformPlans addGoal() removeGoal() setGoal() action1() action2() ...
Plan
*
preConditions() posConditions() execute() stop()
Goal name subgoals ...
Figura 40. A viso esttica do padro Kernel do Agente.
Estrutura. Os atributos de um objeto Agent fazem referncias a objetos que representam elementos do conhecimento intrnseco, a saber os objetos Belief, Goal e Plans. A classe Agent oferece operaes padro para a busca, insero, atualizao e excluso dos elementos de conhecimento. A classe Agent tambm possui atributos para representar crenas genricas do agente. Por exemplo, cada agente est acoplado a um nome, que uma crena genrica do agente. Os engenheiros de SMAs devem refinar a classe abstrata Agent para definir os tipos de agente do sistema (Figura 41). Para definir o conhecimento intrnseco de
109
tipos de agente, os projetistas de aplicao devem dividir as classes Belief, Goal e Plan em subclasses. Essas classes so estruturadas como hierarquias. A classe Belief pode ter os atributos a seguir: (i) um nome para identificar as instncias da crena e (ii) atributos dependentes de aplicao. A classe Belief possui mtodos de busca e atualizao de crenas. A classe Goal possui um nome e mtodos set e get. Tambm possui uma lista de subobjetivos associados, uma vez que um objeto Goal pode ser decomposto em subobjetivos. Alm disso, tem uma lista de planos porque um objetivo pode ter diferentes planos e, assim, um objeto Goal pode ter mais de um objeto Plan associado.
Agent
belief1 belief2 ... action1() action2() ...
AspectN Aspect2 Aspect1
AgentType1
AgentType2
belief2 belief3 ... goals plans action1() action2() ... extrinsic knowledge
intrinsic knowledge
Figura 41. Definio dos tipos de agente.
A classe Plan tem um nome de identificao e um mtodo abstrato execute() que deve ser chamado para dar incio a um plano. Essa classe genrica pode ser implementada como uma thread. Uma subclasse de Plan deve implementar o mtodo execute() de acordo com o plano concreto. Em geral, os planos so implementados como uma seqncia de aes. A classe Plan possui um mtodo stop() que pode ser chamado para conclui o plano. Ela tambm define os mtodos para verificar as precondies e definir as ps-condies. As precondies listam as crenas que
110
devem ser mantidas a fim de executar o plano, enquanto as ps-condies descrevem os efeitos da execuo de um plano bem-sucedido usando crenas de um agente (Seo 3.3.1). Variantes. Kernel de Herana. A soluo do padro define como estruturar o conhecimento do agente desde o incio. Nessa soluo, as referncias a elementos do conhecimento so definidas nas classes Agent que representam os tipos de agente. Diferente dessa soluo, a variante kernel de herana incorpora o uso de aspectos para introduzir de forma transparente os elementos de conhecimento a um objeto existente, como listas de objetivos e planos. A introduo desses elementos especificada nas inter-type declarations. Conseqncias. O uso do padro Kernel do Agente oferece as vantagens a seguir:
Adaptao dinmica. A representao explcita e a manipulao de objetivos e planos facilitam, por exemplo, um ajuste em tempo de execuo do comportamento do sistema necessrio para lidar com as diferentes circunstncias.
Reutilizao do conhecimento. A modularizao de planos em classes oferece suporte a sua reutilizao em diferentes contextos como parte de outros planos.
Separao de concerns. O conhecimento do agente deve ser separado da lgica de controle associada a diferentes propriedades de agente, como autonomia (Seo 5.5), adaptao (Seo 5.6) e aprendizagem (Seo 5.9). No h referncia a essas propriedades nas classes kernel agent. Alm disso, o conhecimento intrnseco definido separado do conhecimento extrnseco.
Reutilizao da Lgica de Controle. A separao da lgica de controle e os algoritmos de princpios do conhecimento permitem escrever procedimentos de inferncia reutilizveis e otimizados [22, 57].
Reutilizao de Aes. As aes bsicas so desacopladas dos planos de forma que as aes possam ser reutilizadas no contexto de diferentes planos.
111
Identificao nica. Um objeto nico, uma instncia de Agente, representa cada agente. Os aspectos do agente so tranados dentro das classes Agent com base no mecanismo dos processos de combinao (Seo 2.2.2).
Transparncia. A variante Kernel de Herana define como introduzir de forma transparente os elementos de conhecimento em um objeto existente, que desejamos transformar em agente.
Usos conhecidos. Essa abordagem tem o suporte de alguns frameworks de implementao OO. Por exemplo, a arquitetura SkeletonAgent [37] usa classes para estruturar planos, objetivos e crenas do agente. Padres relacionados. O padro Composio [79] pode ser usado para estruturar
hierarquias de objetivo complexas (por exemplo, objetivos e subobjetivos) e hierarquias de crena complexas (por exemplo crenas compostas e primitivas). O padro Estratgia [79] pode ser usado para estruturar diferentes implementaes de plano. O padro Papel (Seo 5.7) define como especificar o conhecimento extrnseco de tipos de agente. Todos os demais padres orientados a aspectos desse catlogo esto relacionados ao padro Kernel do Agente.
5.4 O padro Interao Inteno. O Padro Interao modulariza o comportamento interao. Ele desacopla o comportamento interativo do agente de sua funcionalidade bsica e dos objetos do ambiente. Tambm conhecido como. Padro Comunicao, Padro Sensorial. Contexto. O comportamento interao de um agente de software caracteriza-se pelo envio e recebimento de mensagens e pelo comportamento sensorial (Seo 3.3.2). Desejamos separar o comportamento de interao do kernel do agente. Exemplo de motivao. No sistema EC, a interao necessria em vrias circunstncias. As mensagens devem ser enviadas a partir de diferentes planos e
112
aes. Alm disso, os agentes de usurio precisam enviar mensagens, por exemplo, quando esto exercendo o papel de revisor ou chair. A chair envia mensagens com as propostas de reviso aos revisores e eles enviam as respostas de volta. Cada revisor usa uma linguagem de comunicao diferente. Alm do mais, um agente, como um revisor, precisa observar os diferentes componentes externos do software: (i) a agenda do usurio que implementada por um sistema de software de programao de tarefas, (ii) a interface com o usurio e (iii) um objeto persistente que armazena o currculo do usurio. A Figura 42 ilustra um exemplo do comportamento interativo dos agentes do EC.
Agents Basic Functionality
Plan1 Agent
effectors sensors inbox outbox belief1 belief2 ... action1() action2() receiveMsg() sendMsg() senseEvent() ... action1() action2() action3() action4() ...
Roles
Plan2
action1() action2() action3() action4() ...
Chair
Reviewer
public void actionN(...) { ... agent.sendMsg(); ... }
Environment Objects
Personal Agenda Persistent Curriculum Initial Interface
Effector
send() ...
Sensor
senseEvent() receiveMsg() ...
timeSlots addAppointment() addMeeting() notifyAgent()
Legend: underlined - interaction concern
barCollor addResearchKW() addPublication() getUserAnswer() addAward() addConference() getAnswerTime() updateAddress() public void addPublication(...) { ... sensor.senseEvent(); ... }
Figura 42. O projeto orientado a objetos do concern de interao.
As implementaes e os projetos orientados a objetos [20, 137] da propriedade de interao so intrusivos. O comportamento interao afeta as classes kernel, os papis e os objetos do ambiente. A Figura 42 ilustra como o comportamento interao est entrelaado e espalhado pelas classes do agente e do ambiente. O mtodo e o cdigo afetados pela propriedade de interao esto sublinhados na figura. As classes kernel (Seo 5.3), que representam a funcionalidade bsica do agente, so normalmente interligadas a mtodos de interao, como sendMsg(), receiveMsg() e senseEvent() e atributos de interao,
113
como a caixa de entrada e sada. Alm do mais, a implementao da interao afeta vrias aes e planos de agente, que enviam mensagens para agentes colaborativos. O comportamento interao tambm afeta os mtodos de papel, que so interligados s chamadas ao mtodo sendMessage(). Ela tambm afeta muitos objetos do ambiente que so monitorados pelo agente (comportamento sensorial). Os objetos precisam notificar os agentes sobre os eventos relevantes chamando os mtodos das classes Sensor.
Adapter Pattern
Sensor
sense() run() ...
SensingPlan
getNext() ...
Adapter1
sense()
Adapter2
sense()
Adapter3
sense()
Personal Agenda
timeSlots addAppointment() addMeeting()
Persistent Curriculum
addResearchKW() addPublication() addAward() addConference() updateAddress()
Initial Interface
barCollor getUserAnswer() getAnswerTime()
public void sense(...) { ... InitialInterface i; i.getUserAnswer(); ... }
Figura 43. Comportamento deteco nos agentes do EC.
Kendall [137] prope a realizao do padro Adaptador [79] para melhorar a separao do comportamento sensorial. Esse padro usado para criar uma classe reutilizvel que coopera com as classes do ambiente. A Figura 43 ilustra a instanciao de padres do sistema de EC. A principal abstrao da soluo de Kendall um conjunto de Sensores especficos que precisam cooperar com as classes especficas a domnios. Essa soluo fornece a interface do Sensor (o mtodo
114
Sense()), enquanto o desenvolvedor da aplicao oferece SensorAdapters especfico a domnios. H uma lista de objetos externos que precisam ser detectados; eles so armazenados na classe SensingPlan. A SensingPlan pode ser apenas um conjunto de sensores e suas mensagens relevantes. A Figura 44 mostra como um objeto Sensor que utiliza um Plano de Deteco e um SensorAdapter para detectar eventos externos levando em considerao as informaes mutveis em um objeto do ambiente. Ele obtm informaes sobre novas preferncias e compromissos do usurio. Para obter mais detalhes sobre essa soluo de padres, consulte [137].
Sensor run()
SensingPlan
SensorAdapter
Initial Interface
getNext() object_Id sense() getUserAnswer(belief_Id) new_Value return
Figura 44. A viso dinmica do padro Adaptador.
A soluo melhora a separao de concerns, uma vez que isola o comportamento sensorial nas subclasses Adapter e na classe SensingPlan. Essa estrutura leva a um cdigo menos entrelaado uma vez que o cdigo de no-interao no se entrelaa com o cdigo de interao, mas no o evita completamente. O cdigo para o envio de mensagens dentro das classes Agent no pode ser desentrelaado. Isso acontece porque a soluo somente tenta resolver o problema relacionado ao comportamento sensorial. Ela no modulariza o comportamento interativo que est entrelaado s classes kernel do agente. Ademais, nos casos em que pode ser desentrelaado (comportamento sensorial), o projetista tem de pagar um preo alto por isso: adaptadores devem ser escritos apenas para cuidar das funes de deteco.
115
Alm disso, a prpria proposta baseada no adaptador introduz outros problemas. Cada sensor uma thread que trabalha como um mecanismo de pooling que aguarda at que algumas informaes sejam reunidas do ambiente externo. Esse monitoramento caro e desnecessrio, uma vez que as alteraes no ambiente no podem ocorrer com freqncia. O comportamento deteco s deve ser ativado quando acontece alguma alterao no ambiente. Finalmente, a soluo assume que h mtodos pblicos nas classes especficas a domnios que fornecem os servios e as informaes necessrios. Essa premissa nem sempre verdadeira em determinadas aplicaes.
Problema. A implementao bsica de planos do agente e aes associadas interligada com chamadas a mtodos especficos a interaes que respondem ao envio
de mensagens a outros agentes. Alm disso, as funcionalidades bsicas das classes do ambiente so alteradas a fim de incorporar as chamadas a mtodos de deteco de forma intrusiva. Como conseqncia, o ambiente e os componentes kernel do agente so altamente acoplados ao comportamento interao. A estrutura bsica do agente deve estar ciente do comportamento interao. As classes Environment no so projetadas para trabalhar como sensores e no devem conter referncias explcitas a sensores. Como desacoplar o comportamento interao da estrutura bsica dos agentes? As foras a seguir so associadas a esse problema: os engenheiros de SMAs devem definir a interao do agente de uma forma que tenha reusabilidade e manutenibilidade; a exploso no nmero de componentes do agente deve ser evitada; as classes externas no devem ser alteradas na implementao da capacidade sensorial do agente.
Soluo. Usar aspectos para melhorar a separao do comportamento interativo do agente. Os aspectos Interaction so usados para capturar o comportamento de interao que afeta muitas partes de um agente de software. Eles separam o comportamento interao de elementos de conhecimento do agente, como aes e planos, e dos componentes de ambiente e papis. Em outras palavras, os aspectos so
116
usados no s para modularizar o centro do comportamento interao, mas tambm para isolar todo o comportamento relacionado ao concern de interao, que inclui o envio e o recebimento de mensagens e o comportamento sensorial. Ao usar os aspectos Interaction, definimos como os planos e as aes do agente interagem com o ambiente externo. Esses aspectos conseguem afetar alguns pontos de execuo do agente por exemplo chamadas a mtodos nas classes Plan e alteram sua execuo normal a fim de enviar mensagens. Os aspectos Interaction monitoram esses pontos de execuo a fim de identificar quando uma mensagem deve ser enviada usando classes auxiliares. As classes auxiliares so usadas para implementar sensores e efetores.
Message Sending
Sensory
Agent Plan Aspect
Interaction
sensing_() inbox outbox init() marshall() unmarshall() Message Reception receiveMsg() incomingMsg_() Class3
sendMsg() outgoingMsg_()
message senders
Effector send() Sensor sense()
Class2 Class1
environment classes
Figura 45. A viso esttica do padro Interao.
Estrutura. O padro Interao possui trs participantes principais e dois tipos de clientes: Principais Participantes: Aspecto Interaction define a lgica bsica do concern de interao. Sensor
117
colabora com as classes Environment e as infra-estruturas de comunicao a fim de receber mensagens e eventos externos relevantes ao agente. Efector
colabora com as classes Environment e as infra-estruturas de comunicao a fim de enviar mensagens e chamar mtodos nas classes environment.
Participantes cliente: Emissor da mensagem fornece o contexto a partir do qual algumas mensagens precisam ser enviadas e no possui qualquer cdigo de interao pode ser um plano, um agente, ou um aspecto do agente.
Classe Environment
fornece o contexto a partir do qual os eventos precisam ser detectados essa classe no possui cdigo de interao.
A Figura 45 apresenta as partes comuns a todas as instanciaes potenciais do padro e outras partes que no so especficas a cada instanciao. As partes comuns so: 1. A existncia de sensores e efetores (ou seja, o fato de algumas classes agirem como sensores e outras como efetores). 2. A lgica de interao geral: a. as mensagens so detectadas, desordenadas e armazenadas. b. as mensagens so armazenadas ordenadas e propagadas para o ambiente. 3. A interface para enviar e receber mensagens. As partes especficas para cada instanciao do padro so: 1. Quais classes so sensores e quais so efetores no contexto de um tipo de agente ou funes especficas. 2. Um conjunto de join points (Seo 2.2.2) em que as mensagens devem ser enviadas ao ambiente externo.
118
3. Um conjunto de join points nas classes do ambiente em que os eventos precisam ser detectados. O propsito do aspecto Interaction tornar interativas as instncia de Agente. Em outras palavras, o aspecto Interaction estende o comportamento da classe Agent para enviar e receber as mensagens. Esse aspecto envia e recebe mensagens e detecta as alteraes do ambiente por meio de sensores e efetores. As inter-type declarations (crosscutting esttica) so usadas para adicionar os novos mtodos especficos a interaes: os mtodos receiveMsg() e sendMsg(). As classes Sensor e Effector representam respectivamente os sensores e efetores e cooperam com as classes do ambiente. Os sensores e os efetores so classes e seu isolamento do aspecto pretende melhorar a reutilizao. O aspecto Interaction possui quatro partes: o prprio aspecto e trs interfaces
crosscutting. Ele mantm uma caixa de entrada, uma caixa de sada, mtodos de inicializao, mtodos para ordenar e desordenar as mensagens e define a lgica de interao. Como o aspecto Interaction implementa a lgica de interao, ele afeta a classe Agent, os sensores, efetores, as classes Agent ou Plan que precisam enviar uma mensagem para outros agentes, e as classes do ambiente que precisam ser observadas pelo agente. As interfaces crosscutting definem como o aspecto Interaction afeta diferentes classes do sistema multiagentes. A interface MessageSending define um pointcut outgoingMsg que especifica os emissores de mensagens; ela especifica join points nas classes Agent a partir das quais as mensagens precisam ser enviadas para o mundo exterior. Alguns exemplos de join points so mtodos de classes Plan e classes Agent. Observe que o pointcut outgoingMsg abstrato porque os join points dependem das funes e dos tipos de agente especficos. O pointcut concretizado nos subaspectos Interaction. A interface contm um advice que executa depois de execues de aes em classes do agente, aes em classes do plano, outros aspectos associados a agentes (por exemplo, os aspectos de papel Seo 5.7, aspectos de mobilidade Seo 5.8). O propsito do advice capturar as informaes necessrias para enviar a mensagem aos agentes e atualizar a caixa de sada.
119
A interface MessageReception define um pointcut incomingMsg para interceptar execues do mtodo sense() nas classes Sensor; o objetivo detectar a chegada de mensagens. Esse pointcut est associado a um after advice responsvel pelo processamento de mensagens recebidas e pela atualizao da caixa de entrada. A interface sensorial implementa o pointcut de deteco que declara quais mtodos das classes do ambiente precisam ser monitoradas. O sensing_ advice processa os eventos externos e atualiza a caixa de entrada. O pointcut de deteco tambm declarado como abstrato porque os join points dependem dos papis e dos tipos de agente especficos. A Figura 46 ilustra a instanciao de padres do agente de usurio no sistema Expert Committee. O aspecto Interaction afeta diferentes aspectos do agente e classes nesse sistema, cerca de 15 componentes. Alm disso, ele tem dois subaspectos: o
aspecto ReviewerInteraction e o aspecto ChairInteraction. No entanto, para fins de simplificao, ela s apresenta algumas dessas classes e aspectos. Ela mostra uma classe Plan, uma classe Agent e um agente de Mobilidade. Os outros seguem essencialmente o mesmo padro. Tambm foram omitidas as classes auxiliares, que oferecem suporte traduo de mensagens.
Message Sending sendMsg() outgoingMsg_() inbox outbox init() marshall() unmarshall() Sensory
Interaction
sensing_() Message Reception receiveMsg() incomingMsg_()
Message Sending Reviewer CVUpdatePlan Mobility

prepareToMove() prepareReturn()
sendMsg() outgoingMsg_()
Reviewer Interaction
Sensory sensing_() PersistentCV updateInterest() Agenda
init() ...
DSInterface updateAgenda() GUIoperation()
ReviewerEffector
ReviewerSensor
send()
sense()
Figura 46. O padro de interao para o agente de usurio do EC.
120
Por exemplo, o aspecto ReviewerInteraction afeta dois mtodos do aspecto de Mobilidade (Seo 5.8) porque o agente revisor precisa enviar mensagens de notificao para agentes locais antes de mover para um ambiente remoto e depois de retornar ao ambiente original. Depois das execues do mtodo prepareToMove() (join point), o aspecto ReviewerInteraction intercepta o fluxo de controle do programa e o advice outgoingMsg_ envia uma mensagem aos outros agentes de ambiente, notificando-os de que esse agente est se deslocando para um ambiente remoto e no pode mais receber solicitaes de servio locais. Depois da execuo do mtodo prepareReturn() (join point), o aspecto ReviewerInteraction assume o controle da execuo e o advice envia uma mensagem aos outros agentes de ambiente, notificando-os de que o agente revisor est de volta e j pode receber novas
solicitaes de servio. A Figura 46 tambm descreve o relacionamento entre o aspecto ReviewerInteraction e a classe de plano CVUpdatePlan. Esse relacionamento existe porque uma mensagem precisa ser enviada a um agente quando o currculo do revisor modificado.
Dinmica. Os cenrios a seguir descrevem o comportamento dinmico do padro Interao. Cenrio I Recebendo uma mensagem de outro agente, ilustrado pela Figura 47a, apresenta o comportamento do padro quando os aspectos de interao recebem mensagens de outros agentes em pontos especficos no fluxo de execuo: O sensor recebe uma mensagem da plataforma associada. O sensor delega a desmontagem da mensagem e a traduo dos processos para as classes auxiliares. O aspecto de Interao detecta que uma mensagem foi recebida interceptando o mtodo sense() (join point) da classe Sensor. Esse aspecto captura a mensagem recebida e atualiza a caixa de entrada.
121
: Interaction
Reviewer Sensor
:JADECommunication Module
Chair Effector
writeMsg() sense() incomingMsg_() updateInbox() receiveMsg()
Figura 47a. Padro Interao: recebendo uma mensagem.
Cenrio II Enviando uma mensagem, ilustrado pela Figura 47b, apresenta o comportamento do padro quando os aspectos de interao detectam a necessidade de envio de mensagens em pontos especficos do fluxo de execuo:
O agente comea executando uma de suas aes ou planos. O aspecto Interaction detecta pontos no fluxo de execuo (join points) das aes do agente ou planos em que uma mensagem precisa ser enviada.
Esse aspecto monta a mensagem recebida e atualiza a caixa de sada do agente. O aspecto envia a mensagem selecionando o efetor apropriado. O efetor delega a traduo da mensagem para as classes auxiliares. O efetor envia a mensagem ao ambiente usando a plataforma associada.
:Reviewer Interaction
:Judgment Plan execute() judgeProposal() prepareResponse()
Reviewer Effector
:JADECommunication Module
Chair Sensor
outgoingMsg_() updateOutbox() sendMsg() send() writeMsg() sense()
Figura 47b. Padro Interao: enviando uma mensagem.
122
Cenrio III Detectando um evento externo em uma classe Environment, ilustrado pela Figura 48, apresenta o comportamento do padro quando os aspectos de interao detectam estmulos das classes no ambiente: O aspecto de interao observa um evento a partir do ambiente interceptando alguma execuo de mtodo ou atualizao de atributo em classes do ambiente.
O aspecto Interaction seleciona um sensor de ambiente. O sensor do ambiente delega a desmontagem da mensagem e a traduo para as classes auxiliares. O aspecto Interaction detecta que uma mensagem foi recebida interceptando o mtodo sense() (join point) do sensor. Esse aspecto captura a mensagem recebida e atualiza a caixa de entrada.
Observe que o comportamento sensorial e a recepo de mensagens so tratados de forma uniforme. A nica diferena que os aspectos precisam inspecionar diretamente as classes do ambiente a fim de detectar de forma transparente eventos externos, enquanto as mensagens so recebidas pelas classes Sensor, associadas a plataformas de comunicao.
:Reviewer Interaction Reviewer Sensor :Agenda
updateAgenda() sensing_() senseMsg() updateInbox() receiveMsg()
Figura 48. Padro interao: detectando um evento externo.
Conseqncias. O uso do padro Interao oferece as vantagens a seguir: Melhor Separao de concerns. O protocolo de interao totalmente separado dos demais concerns do agente e das classes do ambiente. Os construtos orientados a aspectos oferecem suporte definio separada do envio de mensagens e do comportamento sensorial que afeta muitas unidades
123
do sistema. Essa separao de concerns permite uma melhor modularidade, evitando o cdigo entrelaado e o espalhamento do mesmo em vrias unidades. Portanto, a manutenibilidade e a reusabilidade tambm sofrem uma melhora. Menor nmero de componentes e menos acoplamento. O padro Interao reduz o nmero de classes e inter-relacionamentos adicionais existentes na soluo baseada em adaptadores [137]. No necessrio criar outros adaptadores ou um plano de deteco para implementar o comportamento deteco. Transparncia. O uso de aspectos uma soluo eficaz para a introduo de comportamento de deteco nas classes da aplicao no desenvolvidas para serem detectadas. As classes do ambiente so observadas de forma
transparente. Facilidade de evoluo. Com a evoluo do sistema multiagentes, novos planos precisam enviar mensagens ou novos objetos externos podem ter de ser detectados pelos agentes. Os desenvolvedores de SMAs s precisam de novos pointcuts no aspecto Interaction a fim de implementar a nova funcionalidade necessria. Suporte para a observao de componentes de terceiros. s vezes, as classes observadas podem fazer parte de componentes de terceiros, dos quais no temos acesso ao cdigo-fonte. O padro Interao ainda aplicvel uma vez que as linguagens orientadas a aspectos, como AspectJ, oferecem suporte ao processo de combinao de bytecode. Nesse caso, apenas os arquivos .class so necessrios para a realizao da combinao. Todavia, essa soluo de padro possui as desvantagens a seguir: Concern inseparvel. O padro Interao no modulariza a montagem da mensagem a partir de diferentes planos ou papis; a mensagem precisa ser preparada em classes de plano ou em aspectos de papel, porque sua montagem muito acoplada ao contexto de planos ou papis. Uma soluo seria separar
124
a montagem da mensagem com aspectos, mas isso resultaria em uma maior complexidade. Definies repetitivas e que consomem tempo. Todos os emissores de mensagens do sistema precisam ser especificados no pointcut dentro do aspecto Interaction. Isso pode, de fato, ser repetitivo e tedioso, sugerindo que AspectJ deve ter construtos de metaprogramao mais poderosos. Contudo, esse problema no insolvel, porque as ferramentas de gerao de cdigo podem auxiliar os engenheiros de SMAs nessa etapa de desenvolvimento (Seo 5.11). Alm disso, podemos estabelecer uma conveno de nomenclatura e usar wildcards suportados pela maioria das linguagens orientadas a aspectos [12] (Apndice I). A implementao do Portalware e do Expert Committee usou convenes de nomenclatura.
Usos conhecidos. O Portalware e o Expert Committee implementaram o padro Interao. A implementao de uma arquitetura simuladora de trfego [51] tambm usou o padro Interao (Captulo 7). Padres relacionados. O padro Interao est relacionado ao padro Kernel do Agente, porque associa o comportamento interativo a diferentes classes desse padro. Ele introduz a caixa de entrada e caixa de sada na classe Agent. Intercepta aes em classes do agente e planos a fim de enviar mensagens ao ambiente externo. O padro Interao tambm est conectado ao padro Mobilidade, conforme demonstrado anteriormente. O padro Autonomia e o padro Adaptao dependem do padro Interao porque eles interceptam as recepes de mensagens. O comportamento autonomia inspeciona as mensagens para tomarem decises e instanciam os objetivos a fim de reagir a solicitaes externas e mudanas de ambientes. O comportamento adaptativo trata das mensagens para adaptar as crenas do agente. Finalmente, o padro Papel est relacionado ao padro Interao, uma vez que as aes colaborativas dentro dos papis precisam enviar mensagens a outros agentes.
125
5.5 O padro Autonomia Inteno. O padro Autonomia permite a transformao de um objeto em um agente autnomo. Ele auxilia os engenheiros de SMAs ao oferecer a definio de trs dimenses de autonomia de forma transparente para o objeto passivo. Tambm conhecido como. Padro Independncia, Padro Iniciativa. Contexto. Os agentes de software so autnomos (Seo 3.3.4) e, como conseqncia, tm suas threads de controle (autonomia de execuo), toma decises (autonomia de deciso) e executa aes e planos a seu critrio (autonomia proativa). Desejamos transformar de forma transparente objetos passivos em agentes autnomos.
Exemplo de motivao. Os agentes de EC incorporam as trs dimenses de autonomia. Em relao autonomia de execuo, cada agente multisegmentado e possui estratgias distintas para instanciar suas threads: thread por solicitao e pooling de threads. Em relao autonomia de deciso, os agentes de usurio precisam: (i) tomar decises quando as mensagens so recebidas de outros agentes por exemplo, quando o agente revisor recebe uma proposta de reviso de um agente chair e (ii) quando so recebidos estmulos externos dos objetos do ambiente por exemplo, quando a agenda do usurio est cheia, e o agente prope ao usurio deixar o comit da conferncia. Em relao autonomia proativa, os agentes do usurio realizam atividades proativas em diferentes circunstncias. Por exemplo, quando a agenda est cheia, o agente revisor sugere que o usurio deixe o comit do programa. O projeto orientado a objetos do concern de autonomia normalmente afeta vrias classes do agente. Problema. O concern de autonomia no bem capturado pelas abstraes orientadas a objetos. Em geral, parte do protocolo de autonomia normalmente afeta vrias classes, incluindo as classes do agente, plano e papel. Como conseqncia, no possvel transformar objetos passivos existentes em entidades autnomas de forma que o objeto passivo seja transparente em relao ao comportamento autnomo
126
introduzido. Como melhorar a separao entre o comportamento autnomo e outros concerns do agente? As foras a seguir moldam a soluo do padro: A soluo do projeto deve oferecer suporte aos desenvolvedores de SMAs para que faam objetos passivos em entidades autnomas de forma transparente para os objetos. A manuteno do comportamento autonomia no deve afetar a funcionalidade bsica do agente. O soluo do projeto deve expor claramente as relaes existentes entre o concern de Autonomia e outros concerns do agente, como adaptao, interao etc. Soluo. Usar aspectos para melhorar a separao do comportamento autnomo. Os aspectos Autonomy so usados para modularizar o comportamento de autonomia que
afeta algumas unidades da modularidade de um agente de software. Um aspecto Autonomy (Figura 49) separa o comportamento autnomo dos elementos do kernel do agente, como planos, crenas e de outros aspectos do agente, como o aspecto Interaction. Esse aspecto ajuda a capturar os eventos que disparam os objetivos proativos e os objetivos de deciso, que no so fceis de modularizar com base apenas em abstraes orientadas a objetos. Esse aspecto captura a instanciao de threads que oferecem suporte execuo autnoma de um agente. Como o comportamento autnomo completo definido em um nico aspecto, a propriedade de autonomia pode ser acoplada e desacoplada de objetos passivos em uma forma plug-and-play. Ele gerencia threads do agente e agrega a definio de eventos quando o agente precisa tomar decises e iniciar atividades internas sem solicitaes externas. Usando o aspecto Autonomy, os desenvolvedores de agente podem definir em um nico mdulo quando os planos de tomada de deciso e os planos proativos podem ser chamados. As chamadas a esses planos no so entrelaadas com as classes do agente bsicas, que fazem parte do kernel do agente. O aspecto Autonomy afeta os pontos de execuo dessas classes e muda sua execuo normal a fim de tomar decises e instanciar objetivos reativos e proativos. Alm do mais, o aspecto Autonomy pode ser usado para implementar o controle do grau de autonomia. A
127
soluo informar (ou seja definir pointcuts para) todos os mtodos que influenciam a confiabilidade do agente.
Goal Creation Agent Belief Aspect Execution Autonomy newAgent_() events_()
Autonomy
DecisionPlan decisionGoals proactiveGoals autonomyDegree initGenericGoals() initSpecificGoals() makeDecision()
makeSpecificDecision()
* executePlan() *
ProactivePlan
executePlan()
observed elements
instantiateGoal() initThread()
Figura 49. A viso esttica do padro Autonomia.
Estrutura. O padro Autonomia possui um participante principal e dois tipos de clientes: Participante Principal: Aspecto Autonomy define a lgica bsica do concern de autonomia.
Participantes cliente: Objeto passivo o objeto que precisa ficar autnomo. Gerador de evento gera eventos que provavelmente daro incio a uma criao de objetivos.
A Figura 49 apresenta as partes comuns a todas as instanciaes potenciais do padro e outras partes que no so especficas a cada instanciao. As partes comuns so: 1. A inicializao de objetivos genricos.
128
2. A especificao dos eventos genricos que disparam os algoritmos de tomada de deciso e as atividades proativas. 3. O protocolo de autonomia geral: a. uma thread acoplada a um objeto que pretende ser autnomo. b. os eventos so detectados, as decises so tomadas e os objetivos so instanciados. 4. A interface para instanciar os objetivos. As partes especficas para cada instanciao do padro so: 1. A inicializao de objetivos especficos. 2. Um conjunto de eventos especficos que provavelmente dispararo os algoritmos de tomada de deciso e as atividades proativas.
O propsito do aspecto Autonomy fornecer para as instncias Agente autonomia de execuo, autonomia de deciso e autonomia proativa. O aspecto Autonomy adiciona threads de controle s instncias Agente. Esse aspecto tambm implementa a criao de objetivos proativos e reativos, que so precedidos por decises quando apropriado. As subclasses DecisionPlan e ProactivePlan modularizam a implementao do comportamento proativo e algoritmos de deciso mais sofisticados. O aspecto Autonomy possui trs partes principais: o prprio aspecto e duas interfaces crosscutting. O aspecto tem os objetivos proativos e de deciso, um nmero inteiro representando o grau de autonomia, os mtodos de inicializao e define o protocolo de autonomia. O aspecto Autonomy abstrato e precisa ser estendido para implementar o comportamento autnomo para contextos especficos de tipos de agente e papis. As interfaces crosscutting definem como o aspecto Autonomy afeta diferentes classes de agentes de software. A interface GoalCreation define os geradores de evento. Essa interface especifica join points nas classes do agente, nas quais os eventos precisam ser detectados para dar incio criao de um objetivo. Ela contm um advice que executa depois de execues de aes em classes do agente, aes em classes de crena, ao em classes de plano e aes em outros aspectos associados a agentes (por exemplo, os aspectos de interao Seo 5.4). Como o aspecto
129
Autonomy implementa o protocolo de autonomia, ele associado s classes do agente, plano ou crena nas quais as alteraes a seu estado podem disparar a criao de um objetivo. Atividades de tomada de deciso especficas (classes DecisionPlan) e atividades proativas (classes ProactivePlan) so implementadas em classes separadas e seu isolamento do aspecto Autonomy desejvel para melhorar a reutilizao. A interface ExecutionAutonomy especifica quando e como uma instncia de thread ser associada a instncias de agente. Essa interface especifica o construtor de agente como join point a partir do qual a thread deve ser instanciada. Ela contm um advice que executa depois das execues de construtores da classe Agent. A Figura 50 ilustra a instanciao de padres do papel de revisor no sistema Expert Committee. O aspecto Autonomy e seus subaspectos afetam classes e outros aspectos do agente nesse sistema. Ele mostra a classe Agent, a classe Belief, o
aspecto Interaction, a classe Agenda e o aspecto Reviewer. H outros, mas eles seguem essencialmente o mesmo padro. O aspecto Autonomy afeta o mtodo receiveMsg() do aspecto Interaction (Seo 5.4), porque um agente normalmente precisa decidir se e qual instncia de objetivo reativo deve ser criada dependendo das mensagens recebidas. Depois da execuo do mtodo receiveMsg() (join point), o aspecto Autonomy assume o controle da execuo do programa e instancia, se necessrio, as decises de objetivo associadas ao tipo de mensagem. Se a deciso for positiva, instanciado um objetivo reativo. Caso contrrio, um plano de deciso enviar uma mensagem ao emissor notificando o agente de que a solicitao de servio no ser realizada, e o objetivo reativo no ser instanciado. A Figura 50 tambm descreve o relacionamento entre o aspecto Autonomy e a classe Agent. Esse relacionamento existe porque uma instncia Thread (padro Objeto Ativo [153]) precisa ser associada a cada nova instncia Agente, ou seja, o aspecto introduz a capacidade de autonomia no objeto Agente passivo. A interface ExecutionAutonomy especifica o construtor do Agente como um join point a partir do qual a thread ser ativada. ReviewerAutonomy definido como um subaspecto de Autonomia. Ele especializa a interface crosscutting GoalCreation a fim de definir os eventos ou join points em que so instanciados objetivos proativos e de deciso. Tambm implementa
130
os mtodos abstratos initSpecificGoals() e makeSpecificDecision(). Os planos proativos e a deciso especfica esto associados a esse subaspecto. O aspecto Autonomy possui outros subaspectos para o papel de chair e para o agente do usurio, mas eles seguem, essencialmente, a mesma estrutura de ReviewerAutonomy.
Goal Creation Interaction receiveMsg() Belief ... Agent addAppointment() ... new() setGoal() ... events_()
Autonomy
Execution Autonomy newAgent_() decisionGoals proactiveGoals autonomyDegree initGenericGoals() initSpecificGoals() makeDecision()
instantiateGoal() initThread()
Goal Creation Reviewer receiveMsg() Agenda ...

addAppointment() ...
Reviewer Autonomy
specificGoals ... initSpecificGoals()
JudgementPlan executePlan() LeavingPlan ... executePlan() ...
events_()
Figura 50. O padro Autonomia do papel de Revisor.
Dinmica. Os cenrios a seguir descrevem o comportamento dinmico do padro Autonomia. Cenrio I Tornando um agente autnomo, ilustrado na Figura 51, apresenta o comportamento do padro quando o aspecto de autonomia associa o agente a uma thread de controle e cria um objetivo reativo no recebimento de uma mensagem externa: O agente criado pela chamada desse construtor.
131
O aspecto Autonomy informa sobre a criao de agente e fornece execuo de autonomia instncia de agente ou seja ela incorpora uma thread de controle a essa instncia.
Sempre que uma mensagem recebida, o aspecto Autonomy tenta encontrar objetivos de deciso associados ao evento especfico (ou seja, o tipo de mensagem recebida).
O aspecto cria os objetivos de deciso, que podem ser genricos ou especficos a uma funo ou tipo de agente, e executa os planos de deciso associados.
definido um novo objetivo.
:Agent
: Interaction
: Autonomy
:Decision :Decision :Judgement Plan Plan Plan decision plans
newAgent_() receiveMsg(Msg) events_(Msg) makeDecision(Msg) initThread()
instantiateGoal(decisionGoal) executePlan(decisionGoal) setGoal(reactiveGoal) instantiateGoal(reactiveGoal)
Figura 51. Padro Autonomia: tornando um agente autnomo.
Cenrio II Instanciando um objetivo proativo, ilustrado na Figura 52, apresenta o comportamento do padro quando o aspecto Autonomy detecta um evento que um candidato a disparar um comportamento proativo: O aspecto de autonomia detecta o estabelecimento de um novo compromisso de usurio (eventos interno) que pode ser uma razo para o incio do objetivo proativo de propor ao usurio que deixe o Comit do Programa do qual est participando. O objetivo ser definido somente se o grau de autonomia do agente for maior do que zero.
132
O aspecto Autonomy tenta encontrar objetivos de deciso associados a esse evento especfico. O aspecto cria os objetivos de deciso, que podem ser genricos ou especficos a um papel ou tipo de agente, e executa os planos de deciso associados.
definido o novo objetivo.
:Agent
:Agenda
:Reviewer Autonomy
:Decision :Decision :Leaving Plan Plan Plan decision plans
addAppointment() events_(Stimulus)
makeDecision(Stimulus)
checkAutonomyDegree() instantiateDecisionGoal(Stimulus) executePlan(decisionGoal)
setGoal(proactiveGoal)
instantiateGoal(proactiveGoal)
Figura 52. Padro Autonomia: Criando um objetivo proativo.
Conseqncias. A soluo de padro fornece os benefcios a seguir: Melhor Separao de concerns. O concern de autonomia modularizado nos aspectos Autonomy. Os objetos no implementam comportamento autnomo e no so alterados a fim de implementar o protocolo de autonomia. Flexibilidade. So muitas as dimenses da autonomia exploradas nas diferentes aplicaes de SMAs. Os agentes autnomos simples s tm autonomia de execuo (objetos ativos), enquanto os tipos de agente sofisticados tambm incorporam comportamento proativo. Como o padro desacopla o comportamento autnomo em aspectos, as implementaes especficas da autonomia de agente so facilmente configuradas pelo desenvolvedor de agentes.
133
Configurao dinmica. A estratgia da thread pode precisar ser controlada dinamicamente de acordo com a carga de trabalho do agente. A implementao da configurao dinmica da estratgia de threads transparente para os outros mdulos do agente, uma vez que pointcuts podem ser usados para detectar o grau de atividade do agente e alterar a estratgia em tempo de execuo.
Melhor suporte para manuteno. H duas questes principais no protocolo de autonomia que normalmente alteram: (i) os pontos de execuo de agente em que as threads de agente so iniciadas e (ii) os eventos que disparam alguma deciso de agente. Como a definio desses pontos e eventos est localizada em um nico mdulo, o aspecto Autonomy , a manutenibilidade do agente melhorada.
Por outro lado, o uso do padro Autonomia possui algumas desvantagens: Refatorao necessria. Em algumas circunstncias, a realizao do padro Autonomy requer a reestruturao do cdigo-base associado aos outros componentes do agente a fim de expor join points adequados. Por exemplo, precisamos garantir que cada mtodo que pede a confirmao do usurio (quando uma deciso de agente tomada) retorne um valor booleano. Isso permite que o aspecto capture a resposta do usurio e controle o grau de autonomia do agente. Ademais, extramos o cdigo dos mtodos existentes para um novo mtodo para expor um join point no nvel do mtodo. As ferramentas para ajudar a reestruturao facilitariam a introduo de aspectos em um sistema existente. (Seo 5.11.2). Estrutura complexa para agentes simples. Alguns agentes reativos simples no precisam de controle de threads, eles s reagem a alguns eventos, tomam decises muito simples e no tm comportamento proativo. Nesse caso, o cdigo da autonomia tende a ser localizado em menos mtodos. O uso de aspectos nessa situao especfica pode aumentar em vez de diminuir a complexidade do agente.
134
Variantes. Autonomia reativa. Esse variante no contm a especificao dos eventos que disparariam os objetivos proativos. apropriado para agentes que no sejam proativos, mas so multisegmentados e tomam decises com base em eventos. Esse variante similar ao padro Autonomia. No entanto, a interface crosscutting GoalCreation mais simples uma vez que escolhe apenas as recepes de mensagens. Autonomia reflexiva. Esse variante implementa uma verso reflexiva do padro Autonomia. Ele separa o comportamento autonomia de outros concerns do agente com base em metaobjetos, em vez de em objetos. Um protocolo metaobjeto intercepta dinamicamente os eventos e redireciona o fluxo de controle para os metaobjetos que implementam o comportamento autonomia. A desvantagem desse variante que no fcil compor os metaobjetos de autonomia com metaobjetos implementando outros concerns de agente.
Usos conhecidos. Os agentes de EC usam o padro Autonomia, conforme descrito aqui. Os agentes do Portalware implementam o variante Autonomia reativa do padro, porque no so proativos. Briot et al. [112] e Amandi [7, 8] implementaram suas arquiteturas com base no variante reflexivo do padro Autonomia. Padres relacionados. O padro Autonomia est relacionado ao padro Interao porque precisa informar sobre os recebimentos de mensagens. Esse padro depende do padro Kernel do Agente porque introduz o comportamento autonomia nas classes de conhecimento, como a classe Agent. O padro Autonomia pode cooperar com o padro Aprendizagem quando um aspecto Aprendizado infere novas concluses, ele pode disparar um comportamento de agente proativo. Um aspecto Autonomy pode interceptar as inferncias de aprendizagem. Finalmente, a estrutura de autonomia est relacionada ao padro Objeto Ativo [153] porque oferece suporte definio flexvel da estratgia de controle de threads. Esse padro foi usado no sistema do EC para implementar duas estratgias distintas para a instanciao das threads de agente: thread por solicitao e pooling de threads.
135
5.6 O padro Adaptao Inteno. O Padro Adaptao abstrai o comportamento adaptativo do agente. Ele modulariza o protocolo para a adaptao de comportamento e conhecimento, desacoplando a funcionalidade principal do agente dos componentes de adaptao. A soluo do padro permite que os programadores de agente conectem as estratgias de adaptao s classes Agent Kernel de forma transparente. Contexto. Os agentes precisam ser capazes de adaptar seu conhecimento e comportamento natureza dinmica dos ambientes nos quais operam. O protocolo de adaptao consiste em observar os eventos relevantes, juntando as informaes necessrias, selecionando e chamando os adaptadores associados. O comportamento e a estrutura do agente podem ter de ser adaptados em vrias circunstncias: quando as
crenas so alteradas, quando um novo objetivo foi alcanado etc (Seo 3.3.3). O agente precisa ser capaz de observar sua estrutura e comportamento a fim de adaptar o conhecimento e o comportamento. Desejamos descrever o protocolo de adaptao o mais separadamente possvel. Exemplo de motivao. No sistema EC, a adaptao necessria em vrias circunstncias. a chegada de uma nova mensagem, a definio de um novo objetivo, a falha de um plano, as alteraes de crena etc. Esses eventos so eventos importantes que precisam ser observados e provavelmente dispararo algum tipo de adaptao. Quando chega uma proposta de reviso do agente chair, o agente revisor precisa adaptar suas crenas, como o prazo final para o envio de uma resposta chair. A alterao de crenas pode, por sua vez, resultar na alterao de crenas associadas. Quando definido um novo objetivo, deve ser selecionado um novo plano. Kendall prope a implementao do comportamento adaptativo usando o padro Observador [137]. Essa soluo trabalha bem porque a inteno do padro Observador definir uma dependncia um-para-muitos entre objetos de forma que quando um objeto muda de estado, todos os dependentes so notificados e atualizados automaticamente [79]. As implementaes orientadas a objetos do padro Observador normalmente adicionam uma referncia a todos os assuntos potenciais (as
136
classes observadas) que armazenam uma lista de observadores interessados em alteraes desse assunto particular. Quando um assunto deseja reportar um estado para seus observadores, ele chama seu prprio mtodo notify(), que, por sua vez, chama uma mtodo de atualizao para todos os observadores na lista. Como conseqncia, essa soluo possui algumas desvantagens: (i) ela diminui a separao entre os concerns bsicos do agente e o concern de adaptao, (ii) ela abusa do mecanismo de herana (3.6.2) uma vez que todas as crenas observadas precisam implementar a interface Observvel, aumentando a profundidade geral da herana nos SMAs e (iii) as classes kernel (Seo 5.3) so muito acopladas a componentes de adaptao, dificultando a evoluo do sistema.
JADEAgent
getName() moveAgent() beforeMove()
Observable
addAdapter() removeAdapter() notifyAdapters()
Role
collaboratingAgents collaborationProtocol adapters getName() addAgent() removeAgent() addAdapter() removeAdapter() notifyAdapters()
Agent
goals plans agents adapters addAgent() removeAgent() addAdapter() removeAdapter() notifyAdapters() executePlan()
Beliefs
adapters addAdapter() removeAdapter() notifyAdapters()
Observer
Adapter
adapt()
PrimitiveBeliefs
CompositeBeliefs
update()
Chair
papers submissionDeadline reviewDeadline addAgent() removeAgent()
Reviewer
chair MyPaper toReviewPapers reviewDeadline new() fillForm() coauthors updateForm() keywords getChairName() publisher public void fillForm(...) status { ... notifyAdapters(); ... }
Legend: underlined - learning concern
Figura 53. Comportamento adaptao nos agentes do EC. O padro Observador [137].
Considere um exemplo concreto do padro Observador implementado na linguagem Java no contexto da adaptao de conhecimento, conforme demonstrado na Figura 53. Nessa soluo, o padro Observador seria usado para causar operaes mutantes em elementos de crena a fim de notificar os componentes de adaptao. Conforme mostrado na figura, o cdigo para a implementao do padro Observador
137
espalhado pelas classes belief . O componente Observvel uma interface e uma classe no-abstrata porque as classes observveis j estendem uma classe abstrata (JADEAgent). Java, a linguagem orientada a objetos mais comum e expressiva para a implementao de SMAs, no oferece suporte a vrias heranas. Todos os participantes (por exemplo Chair) esto interligados por mtodos do padro Observador e as respectivas chamadas de mtodos e, conseqentemente, possuem cdigo de adaptao. A adio ou remoo do concern de adaptao de uma classe requer alteraes invasivas nessa classe. A alterao do protocolo de adaptao requer alteraes em todas as classes participantes. Problema. Os eventos e as estratgias associados adaptao do agente variam muito. Em geral, o protocolo de adaptao afeta as diversas classes associadas ao kernel do agente. A adaptao de conhecimento afeta muitos elementos, incluindo os
papis, as classes do agente e as classes da crena. A adaptao do comportamento afeta diferentes elementos, como classes do agente e planos. Seria interessante se o kernel do agente e outros concerns pudessem ser decompostos a partir do protocolo de adaptao. Como melhorar a separao entre o comportamento adaptativo e outros concerns do agente? As foras a seguir surgem ao tratar desse problema: A alterao dos eventos e estratgias no deve afetar a funcionalidade bsica do agente. Deve ser fcil reutilizar os protocolos bsicos da adaptao de conhecimento e adaptao de comportamento por diferentes papis e tipos de agente. Soluo. Usar aspectos para melhorar a separao do comportamento adaptativo do agente. Os aspectos Adaptation so usados para capturar o protocolo de adaptao que afeta muitas partes de um agente de software. Um aspecto Adaptation (Figura 54) separa o comportamento adaptativo dos elementos do kernel do agente, como planos, papis, crenas etc. Em outras palavras, os aspectos so usados no s para modularizar o centro do comportamento adaptativo, mas tambm para isolar todo o comportamento relacionado ao protocolo de adaptao, incluindo a adaptao de comportamento e conhecimento.
138
Usando os aspectos Adaptation, definimos quando e como o agente adaptado. Eles conectam os pontos de execuo do programa (eventos) aos elementos do agente que precisam ser adaptados s estratgias de adaptao correspondentes. Esses aspectos conseguem afetar alguns pontos de execuo do agente por exemplo chamadas a mtodos nas classes Agent e alteram sua execuo normal a fim de disparar um adaptador ou componente de adaptao. Eles monitoram esses pontos de execuo a fim de identificar quando uma adaptao deve ser disparada. Em geral, quando um determinado elemento do conhecimento alterado, essa alterao candidata a motivar uma adaptao. As classes auxiliares so usadas para implementar diferentes adaptadores, ou seja, diferentes estratgias de adaptao.
Knowledge Adaptation
Agent Belief Aspect
Adaptation
adapters adaptBelief() findPlan() adaptSpecificBelief() findSpecificPlan()
Behavior Adapation newGoal_() failedPlan_() planFinal_() Plan executePlan() Agent setGoal()
changedBelief_() newMsg_()
knowledge elements observed
Adapter adapt()
Figura 54. A viso esttica do padro Adaptao.
Estrutura. O padro Adaptao possui dois participantes principais e um participante cliente: Principais Participantes: Aspecto Adaptation define o protocolo de adaptao. Adaptador Implementa uma estratgia de adaptao especfica.
Participante cliente:
139
Elemento do conhecimento Oferece o contexto em que uma adaptao de comportamento ou um conhecimento pode ser disparado pode ser uma classe da crena, uma classe do plano, uma classe do agente ou um aspecto do agente.
Na estrutura do padro Adaptao (Figura 54), algumas partes so comuns a todas as instanciaes potenciais do padro e outras partes que so especficas a cada instanciao. As partes comuns so: 1. Os eventos genricos em que o agente sempre precisa ser adaptado, por exemplo, quando definido um novo objetivo ou quando ocorre uma exceo durante a execuo de um plano. 2. O protocolo de adaptao geral: - os eventos so detectados, as condies so
verificadas e as aes/planos disparados. 3. As adaptaes genricas. 4. A lista de adaptadores, ou seja, as referncias a componentes de adaptao mais sofisticados (tcnicas de busca, mecanismo de inferncia e planejadores). As partes especficas so: 5. Os eventos especficos associados a um determinado contexto (tipo de agente ou papel) em que o agente precisa ser adaptado no qual as crenas precisam ser observadas de forma que seja necessria alguma adaptao. 6. As adaptaes especficas.
O propsito do aspecto Adaptation tornar as instncias Agent adaptativas. O aspecto Adaptation estende o comportamento da classe Agent para introduzir o protocolo de adaptao. Esse aspecto contm os pointcuts que descrevem os eventos relevantes e as informaes que precisam ser reunidas dos elementos do conhecimento. Ele contm os advices que chamam os mtodos responsveis pela implementao da adaptao ou de um adaptador especfico. O aspecto Adaptation possui trs partes principais: o prprio aspecto e duas interfaces crosscutting. O aspecto possui os mtodos do adaptador e a lista dos adaptadores especializados. O
140
aspecto Adaptation abstrato e precisa ser estendido para implementar o comportamento adaptativo para contextos especficos de tipos de agente e papis. As interfaces crosscutting definem como o aspecto Adaptation afeta as diferentes classes do sistema multiagentes. A interface KnowledgeAdaptation define os join points nos elementos do conhecimento que devem disparar uma adaptao de alguma parte do conhecimento. Ela descreve dois pointcuts principais: o pointcut changedBelief captura as alteraes do conhecimento e o pointcut newMsg detecta a chegada de uma nova mensagem. Contm um advice que executa depois de execues de aes de classes do agente, aes de classes do plano e outros aspectos associados ao agente (por exemplo, os aspectos de papis Seo 5.7). A interface BehaviorAdaptation define os join points nos elementos do conhecimento que devem disparar o cancelamento da execuo de um plano ou a seleo de um novo plano.
Como o aspecto Adaptation implementa o protocolo de adaptao, os aspectos da adaptao so associados a diferentes elementos do conhecimento, como as classes Agent, classes Plan, classes Belief e aspectos de papis. A Figura 55 ilustra a instanciao de padres do papel de revisor no sistema Expert Committee. O aspecto Adaptation afeta diferentes classes e aspectos do agente nesse sistema (cerca de 9 componentes). No entanto, a figura somente apresenta um conjunto parcial das classes afetadas pelos aspectos. Ela mostra o aspecto Interaction, a classe Belief, a classe Agent, a classe Plan, a classe MyPaper e o aspecto Reviewer; os outros seguem, essencialmente, o mesmo padro. Por exemplo, a adaptao do conhecimento necessria quando recebida uma mensagem do agente. Esse evento detectado pela interceptao do mtodo receiveMsg() no aspecto Interaction. A mensagem capturada pelo pointcut newMsg na interface KnowledgeAdaptation, e a adaptao realizada por meio de mtodos internos do aspecto Adaptation. A Figura 55 tambm ilustra um exemplo da adaptao do comportamento. A interface BehaviorAdaptation captura as alteraes na lista de objetivos por meio da especificao do pointcut newGoal. Um after advice associado ao pointcut e responsvel pela seleo de novos planos para alcanar o novo objetivo. Nesse caso, o mtodo setGoal() interceptado, o objeto do objetivo capturado e um plano associado chamado pelo advice.
141
O aspecto ReviewerAdaptation estende Adaptation para implementar o comportamento adaptativo especfico ao papel de revisor. Ele refina a interface KnowledgeAdaptation para definir as crenas do revisor que disparam a adaptao do conhecimento. Por exemplo, o pointcut changedBelief afeta o construtor da classe MyPaper porque, como um novo trabalho criado, h a necessidade de adaptar a crena que representa os interesses de pesquisa do revisor. As palavras-chave associadas ao novo trabalho precisam ser reunidas, e o mtodo de adaptao dos interesses de pesquisa chamado. Como alternativa, o adaptador de encadeamento chamado a fim de inferir sobre novas reas em que o usurio est interessado.
Knowledge Adaptation Agent removeAgent() Belief ... updateKeywords() Interaction ... receiveMsg() ... changedBelief_() newMsg_()
Adaptation
adapters adaptBelief() findPlan() adaptSpecificBelief() findSpecificPlan()
Behavior Adapation newGoal_() failedPlan_() planFinal_() Plan executePlan() Agent setGoal()
Knowledge Adaptation changedBelief_() MyPaper updateKeywords() Reviewer ... fillForm() ... ...
Reviewer Adaptation
adaptSpecificBelief() findSpecificPlan() ...
ForwardChaining adapt() ...
Planner adapt() ...
Figura 55. O padro Adaptao do papel de revisor.
Dinmica. Os cenrios a seguir descrevem o comportamento dinmico do padro Adaptao. Cenrio II Adaptando crenas de acordo com uma mensagem recebida, ilustrado pela Figura 56, apresenta o comportamento do padro quando o aspecto
142
Adaptation detecta a necessidade de adaptao de crenas devido ao recebimento de mensagens de ambientes externos: O agente recebe uma mensagem do ambiente. O aspecto Adaptation detecta o recebimento de mensagens
interceptando a operao receiveMsg(). Esse aspecto rene as informaes necessrias dos elementos do conhecimento. O aspecto adapta diretamente as crenas do agente, conforme mostrado na Figura 56, ou seleciona um adaptador.
: Interaction receiveMsg(Msg) : Adaptation :Agent
msgReception_(Msg) adaptBelief(Msg) adaptGeneralBelief(Msg)
addAgent()
Figura 56. Padro Adaptao: adaptando Agent no recebimento de uma mensagem.
Cenrio II Adaptando planos devido definio de um novo objetivo, ilustrado pela Figura 57, apresenta o comportamento do padro quando o aspecto Adaptation detecta um novo objetivo que deve ser alcanado: O agente possui um novo objetivo. O aspecto Adaptation detecta o novo objetivo interceptando a operao setGoal(). Esse aspecto rene as informaes necessrias dos elementos do conhecimento (o objeto do objetivo nesse caso). O aspecto tenta encontrar um novo plano para o mesmo objetivo. O aspecto adiciona o objeto do objetivo instncia do novo plano. O aspecto adapta a lista de planos do agente que devem ser executados. O aspecto remove o plano dessa lista quando a execuo do plano concluda.
143
:Agent setGoal(Goal)
: Adaptation
:Searching Plan
newGoal_(Goal) adaptBehavior(Goal) findPlan(Goal) setGoal() queueToPerformPlan()
dequeueToPerformPlan()
planFinal_()
Figura 57. Padro Adaptao: adaptando planos ao definir um novo objetivo.
Cenrio III Adaptando planos devido ao surgimento de uma exceo, ilustrado pela Figura 58, apresenta o comportamento do padro quando o aspecto Adaptation
detecta uma exceo em uma execuo de plano: Uma exceo surge durante a execuo de um mtodo. O aspecto Adaptation detecta a exceo interceptando a resposta da operao executePlan(). Esse aspecto rene as informaes necessrias, o objeto do plano nesse caso. O aspecto tenta encontrar um novo plano para alcanar o objetivo que o plano anterior no conseguiu alcanar. O aspecto adiciona o objeto do objetivo instncia do plano correspondente. O aspecto adapta a lista de planos do agente que devem ser executados.
:BasicSearch Plan executePlan() failedPlanException
: Adaptation
:CombinedSearch Plan
failedPlan_(Plan) findAlternativePlan(Goal) setGoal() queueToPerformPlan()
Figura 58. Padro Adaptao: adaptando planos quando surge uma exceo.
144
Conseqncias. O padro Adaptao possui as seguintes conseqncias: Uniformidade. O protocolo para a adaptao do conhecimento e a adaptao do comportamento definido uniformemente no aspecto Adaptation. O cdigo comum aos protocolos reutilizado. Melhor Separao de concerns. O protocolo de adaptao totalmente separado dos demais concerns do agente, como conhecimento e interao. As classes associadas aos demais concerns no possuem cdigo de adaptao. Menor replicao do cdigo. Conforme discutido anteriormente, o uso do padro Observador [137] introduz a replicao do cdigo medida que a complexidade do agente aumenta. O padro Adaptao oferece suporte modularizao desse cdigo no aspecto Adaptation, minimizando o
entrelaamento e o espalhamento do cdigo. Transparncia. Os aspectos tornam-se uma abordagem elegante e poderosa que pode ser usada para introduzir o comportamento adaptativo em classes do agente de forma transparente. A descrio de quais classes do agente precisam ser observadas est presente no aspecto, e essas classes monitoradas no so modificadas de forma intrusiva. Facilidade de evoluo. Com a evoluo do sistema multiagentes, novas classes do agente precisam ser monitoradas e adaptadas. Os desenvolvedores de SMAs s precisam adicionar novos pointcuts e advices no aspecto Adaptation e conect-los a adaptadores especficos a fim de implementar a nova funcionalidade necessria. Fcil incorporao de adaptadores simples. Muitas estratgias de adaptao so simples e no precisam de adaptadores sofisticados. Estratgias simples podem ser definidas como mtodos em aspectos de adaptao.
Usos conhecidos. O Portalware e o Expert Committee implementaram o padro Adaptao. Um sistema de gerenciamento de trfego tambm usou o padro Adaptao (Seo 7.1).
145
Padres relacionados. O padro Adaptao contm a implementao orientada a aspectos do padro Observador [115]. O padro Estratgia pode ser usado para implementar diferentes estratgias de adaptao [137]. O padro Faade pode ser usado para fornecer uma interface nica para as estratgias de adaptao, independente das tcnicas de raciocnio ou algoritmos de planejamento. Finalmente, a implementao do padro Adaptao (vide a seguir) usa alguns idiomas AspectJ [114], como Template Advice, Composite Pointcut e Advice Method. 5.7 O padro Papel Inteno. O padro Papel oferece suporte definio separada de papis do agente. Ele decompe as dificuldades do comportamento colaborativo da funcionalidade
bsica do agente. Tambm conhecido como. Papel colaborativo. Contexto. Um agente exerce diferentes papis em um sistema multiagentes (Seo 3.4.2). Os papis capturam como os agentes interagem entre si em colaboraes [136]. Um agente exerce papis adicionais, que no fazem parte de sua funcionalidade bsica. Cada papel envolve conhecimento extrnseco (Seo 3.4.2), ele possui suas prprias crenas, objetivos e planos. O papel tambm pode manipular o conhecimento intrnseco associado ao papel bsico do agente. Com o aumento do nmero de papis do agente, h a necessidade de modulariz-los. Precisamos fazer isso o mais separadamente possvel. Exemplo de motivao. Os agentes do usurio no sistema EC exercem os papis atribudos a eles. Esses agentes apresentam quatro papis: chair, revisor, revisor adicional (revisor especial) e chamador (Seo 5.1). Um mesmo agente do usurio pode exercer vrios papis. O papel de chair possui objetivos especficos, incluindo o objetivo de distribuio de trabalhos a revisores (DistributionGoal) e o objetivo do contato de novos revisores quando o nmero de revisores no suficiente (ContactGoal). Ele tambm possui vrios planos para alcanar os objetivos e possui crenas que mantm as informaes da conferncia, incluindo prazos finais, a lista de revisores e a lista de trabalhos enviados. O revisor possui crenas, objetivos e planos
146
especficos. O revisor adicional convidado por um revisor para ajudar na reviso de um trabalho especfico. O papel de chamador associado ao papel de chair. responsvel pela colaborao com agentes de informao sempre que precisa do perfil de um dado revisor. Muitas abordagens foram usadas para a modularizao de papis em linguagens orientadas a objetos [19, 77, 108, 146, 241]. Em [77], Fowler avalia as diferentes abordagens. A mais comum o padro Objeto do Papel [19]. Esse padro fornece uma classe individual a cada papel do agente. Cada classe do papel exibe conhecimento extrnseco e comportamento no-central, especficos ao contexto do papel. Os papis so organizados em uma hierarquia, com subclasses para comportamento de papel mais especializado (AdditionalReviewer). Kristensen e Osterbye [146] propem o Objeto do Papel com o padro Decorador [79] como o melhor suporte para os papis em linguagens orientadas a
objetos.
inteno
do
padro
Decorador
conectar
dinamicamente
responsabilidades adicionais a um objeto. No contexto dos papis, os decoradores oferecem uma alternativa flexvel para subclasses para estender os agentes com funcionalidades de papel. No contexto do padro Objeto do Papel, a estrutura do Decorador usada para o projeto da interface dos papis. A Figura 59 apresenta essa soluo para os agentes do usurio do EC, sendo que uma linha descreve um caminho de colaborao entre dois papis. A figura mostra que UserAgentRole e UserAgentType implementam a mesma interface
CollaborativeUserRole (padro Decorador). Um objeto que est usando uma instncia de UserAgentType somente tem conhecimento de um objeto; no entanto, em tempo de execuo, os papis adicionam comportamento de forma transparente. Um objeto central (uma instncia da classe UserAgentType) contm os papis que exerce como um conjunto de instncias do papel. A atribuio do papel dinmico (conexo do papel) tem suporte porque as instncias que representam os papis atuais podem ser alteradas em tempo de execuo. Esse padro permite o acoplamento e o desacoplamento dos objetos do papel do comportamento e do estado central do agente. O agregado do objeto resultante representa um objeto lgico, apesar de consistir em objetos do papel fisicamente diferentes. O padro Objeto do Papel evita a exploso combinatria de classes, como
147
resultaria do uso de vrias heranas para compor diferentes papis em uma nica classe [19]. No entanto, os clientes da classe UserAgentType provavelmente ficaro mais complexos, uma vez que trabalhar com um objeto por meio de uma de suas interfaces do papel implica uma leve codificao em comparao ao uso da interface fornecida pela classe UserAgentType. Por exemplo, os papis de revisor e chair precisam ser explicitamente criados e ligados a objetos do agente do usurio, e o cliente tem de verificar se o objeto exerce o papel desejado antes da ativao explcita de algumas capacidades introduzidas por ele (Figura 59). Como conseqncia, o cdigo da colaborao dos papis entrelaado ao cdigo no-colaborativo uma vez que os planos precisam implementar a conexo do papel. Alm disso, os planos possuem referncias explcitas aos papis a fim de acessar os servios especficos do papel. Isso aumenta o acoplamento do sistema.
Collaborative UserAgent Agent
getName() setGoal() setPlan() addRole() getRole() hasRole() getInterests() getAgenda() getResearchStage()
interface to all roles
intrinsic role
UserAgentType
userName myRoles researchInterests researchers informationAgents getInterests() getResearchStage() getAgenda()
roles core
UserAgentRole
userAgentCore beliefs goals plans collaboratingAgents collaborationProtocol getInterests() getResearchStage() getAgenda()
extrinsic roles
Plan
executePlan()
Chair
papers submissionDeadline reviewDeadline
Caller
papers submissionDeadline reviewDeadline
Reviewer
papersToReview chairName reviewDeadline biddingDeadline
Legend: ____ replicated code Decorator classes
Additional Reviewer
reviewer
Figura 59. Papis: o padro Objeto do Papel com o padro Decorador [146].
148
Kristensen e Osterbye [146] e outros autores [77, 121, 136] apontam as principais desvantagens a seguir: Esquizofrenia do agente: O comportamento do agente distribudo por tipo de agente e seus papis. O agente deve ser um objeto, mas, em vez disso, incorpora vrios objetos, cada um com sua prpria identidade (Seo 3.6.3). Isso viola o princpio de identidade (Seo 3.4.2), o que pode levar a muitos sintomas, incluindo delegao interrompida, assunes interrompidas e dopplegangers [121]. Mistura de interface ou delegaes sucessivas: A interface para todos os papis deve ser fornecida em uma interface (CollaborativeUserAgent - Figura 59), aumentando a replicao do cdigo e diminuindo a separao de
concerns. Se isso no for feito, os objetos devem receber delegaes sucessivas em tempo de execuo para chamar comportamentos de papel especficos. Composio do papel: A verso Decorador do padro Objeto do Papel no oferece suporte a referncias diferentes, mas sobrepe subconjuntos de decoradores. Ou seja, no oferece suporte ao princpio do papel de agregao (Seo 3.4.2).
Problema. Um tipo de agente pode exercer muitos papis. Portanto, os papis podem afetar vrios tipos de agente [136]. Alm disso, a ativao de um papel pode afetar as classes do plano. O cdigo de aes no-colaborativas no deve ser misturado com o cdigo de colaborao porque ele pode ser executado fora da colaborao. Conforme demonstrado no exemplo de motivao, os projetos orientados a objetos no oferecem suporte adequado a papis do agente. Como separar os papis das classes associados funcionalidade bsica do agente? As foras so associadas aos princpios do papel apresentados na Seo 3.4.2, os princpios de abstratividade, agregao, dependncia, dinamicidade, identidade, herana e multiplicidade. As foras a seguir so associadas ao problema:
149
O projeto deve fornecer uma separao explcita entre o conhecimento intrnseco e o conhecimento extrnseco especfico ao papel de um agente.
Deve ser fcil desenvolver as aes colaborativas de um agente adicionando e removendo novos papis de forma flexvel. A soluo deve minimizar a esquizofrenia do agente, melhorar a manuteno da interface e oferecer suporte composio do papel.
Soluo. Usar aspectos para melhorar a separao entre o tipo do agente e seus papis. Um aspecto de papis usado para capturar o conhecimento extrnseco do papel. Os membros do conhecimento intrnseco bsico fazem parte de uma classe que representa o tipo de agente, enquanto os membros do conhecimento extrnseco
pertencem a um aspecto de papis. Cada aspecto de papis define a atividade do agente e o conhecimento dentro de uma determinada colaborao. Alm disso, os relacionamentos e o contexto do papel residem na instncia do aspecto para facilitar o suporte multiplicidade do papel. Os aspectos Role podem afetar dinamicamente
os diversos objetos (princpio da dinamicidade). Esses aspectos no existem por si s, sua criao sempre depende da instanciao de um tipo de agente (princpio da dependncia). As especializaes do papel tm suporte da herana do aspecto (princpio da herana). Usando os aspectos Role, definimos quando e como o agente exerce o papel. Eles conectam os pontos de execuo do programa (eventos) das classes do agente aos papis correspondentes. Esses aspectos conseguem afetar alguns pontos de execuo do agente por exemplo chamadas a mtodos das classes Agent a fim de ativar um papel. Eles monitoram esses pontos de execuo a fim de identificar quando o papel deve comear a ser exercido pelo agente. Em geral, quando o agente criado, alguns papis so acoplados a ele. Ademais, outros eventos especficos podem ser causados pela ativao dos papis. As classes auxiliares so usadas para implementar os elementos do conhecimento extrnseco do papel, incluindo os objetivos, as crenas e os planos (Figura 60).
150
Estrutura. O padro Papel possui trs participantes principais e uma categoria cliente: Principais Participantes: Tipo de agente implementa o papel intrnseco, ou seja, a funcionalidade bsica, associada a um tipo de agente. Aspecto Role define um papel extrnseco do agente, incluindo suas aes e crenas simples, e as referncias a crenas, objetivos e planos complexos.
Elemento do conhecimento extrnseco representa um elemento do conhecimento extrnseco associado ao papel do agente inclui um objetivo, uma crena e um plano.
Participantes cliente: Elemento do conhecimento intrnseco oferece o contexto a partir do qual um papel pode ser instanciado.
Na estrutura do padro Papel (Figura 60), no h partes comuns para a instanciao do padro. A realizao do padro requer: 1. A definio dos aspectos de papis com aes e crenas simples. 2. A definio de classes da crena, classes do objetivo e classes do plano. 3. A especificao dos eventos associados ao tipo de agente e os elementos do conhecimento em que o aspecto Role precisa estar conectado instncia do agente. O propsito dos aspectos Role implementar os diferentes papis do agente. Eles modularizam as atividades colaborativas especficas a um agente, separando-as da funcionalidade bsica do agente. Todos os comportamentos especficos a papis (extrnsecos) esto localizados no cdigo-fonte do aspecto. Dessa forma, um aspecto
151
de papis pode ser usado para separar de forma eficaz cada concern do papel. Esse aspecto contm os pointcuts que descrevem os eventos que devem motivar a ativao do papel. Contm os advices, associados a esses pointcuts, responsveis pela ativao do papel. O aspecto Role possui duas partes principais: o aspecto em si e uma interface crosscutting. O aspecto possui as estruturas de dados que implementam o conhecimento extrnseco do papel. O comportamento do papel colocado em conjunto com inter-type declarations que so adicionadas ao tipo de agente e advices que informam s classes do conhecimento intrnseco. Ou seja, um aspecto esttico introduz a interface do comportamento especfico a papis classe do tipo do agente e, em seguida, uma instncia do aspecto adiciona ou informa a implementao desse comportamento a instncias da classe do tipo do agente, dinamicamente e conforme necessrio.
Role3 Role2 Role1
belief2 belief3 ... goals plans action1 action2 ...
Role Binding events_()
Belief beliefs
Role Plan AgentType belief1 belief2 ... goals plans action1() action2()
Plan * name preConditions() posConditions()
Goal name
Figura 60. A viso esttica do padro Papel.
A interface crosscutting RoleBinding define quando o aspecto Role acoplado s classes do agente. Ela define os join points nos elementos do conhecimento que devem disparar a ativao do papel. Contm um advice que executa depois de execues de aes de classes do agente, aes de classes do plano
152
e outros aspectos associados ao agente (por exemplo, os aspectos de papis). Essa abordagem a aspectos de papis satisfaz quase todos os princpios do papel. A Figura 61 ilustra a instanciao de padres dos agentes de usurio no sistema Expert Committee. O aspecto Role afeta cerca de 4 classes e aspectos do agente nesse sistema. Todavia, na figura, alguns componentes foram omitidos, como o AdditionalReviewer; uma outra subclasse de Reviewer. Ela mostra a classe UserAgent, a classe DistributionPlan, as outras seguem essencialmente o mesmo padro. Como o papel de chair est relacionado ao papel de chamador, h um relacionamento entre os aspectos Chair e Caller. Eles so adicionados diretamente classe UserAgent. No exemplo apresentado, eles esto ligados s instncias UserAgent quando so criados. Como conseqncia, um pointcut especificado para escolher as chamadas ao construtor da classe UserAgent. O aspecto Chair fornece ao
agente aes, objetivos e planos que implementam as funcionalidades especficas a chair. Ele implementa as aes para colaborar com o papel de revisor. Contm, por exemplo, o plano e as aes associadas para distribuir propostas de reviso aos revisores e receber as respostas. De forma similar, o aspecto Reviewer introduz a capacidade de receber e julgar as propostas e enviar as respostas a chair.
Role Binding events_()
Caller Reviewer Chair

papersToReview deadlines ... goals plans getPapers() ...
PapersToReview
author ...
ContactPlan executePlan() DistributionPlan preConditions() executePlan() posConditions() preConditions() posConditions() ContactGoal name DistributionGoal name
DistributionPlan UserAgent belief1 belief2 ... goals plans action1() action2()
Figura 61. O padro Papel para o agente do usurio do EC.
153
O aspecto Caller fornece a UserAgent a capacidade de enviar uma solicitao de busca para um agente de informao e de receber o resultado da busca. Ele ativado no contexto do papel de chair (princpio de agregao). Um after advice startsCaller() est associado a recebimentos de mtodos de busca (search(*)) e responsvel pelo envio da solicitao de busca quando o prprio agente no capaz de encontrar as informaes necessrias. Esse advice verifica os resultados dos mtodos de busca de forma que o chamador seja ativado sempre que o resultado do mtodo for nulo. Observe que os papis so introduzidos de forma transparente e nointrusiva. Observe que os diferentes subtipos de UserAgent podem herdar os aspectos de papis acoplados superclasse UserAgent (princpio de herana).
Dinmica. Os cenrios a seguir descrevem o comportamento dinmico do padro

Papel. Cenrio I Ligando uma instncia do papel a uma instncia do agente, ilustrado pela Figura 62, apresenta o comportamento do padro quando o aspecto Role instanciado na criao de um novo agente: O agente criado pela chamada do construtor da classe Agent. O aspecto Role detecta a criao do agente interceptando a chamada ao construtor do agente. O advice no aspecto de papis inicializa o papel e seus atributos internos.
:UserAgent
:Caller
new() events_() init()
Figura 62. Padro Papel: ligando uma instncia do papel a uma instncia do agente.
154
Cenrio II Ativando a instncia do papel nas diferentes situaes. O aspecto Role pode ser ligado a um agente em situaes muito especficas. Por exemplo, o aspecto Caller ativado quando o papel de chair no contm um determinado perfil de revisor. Esse aspecto implementa a colaborao com um agente Information que responsvel pela busca das informaes necessrias em um banco de dados locais. A Figura 63 ilustra esse cenrio: O papel de chair tenta encontrar um determinado perfil de revisor. O aspecto Caller detecta a chamada do mtodo searchProfile(). O advice no aspecto Caller no retorna nenhum perfil para esse revisor. O papel de Caller chama suas aes colaborativas (implementadas por seus mtodos internos) a fim de colaborar com um agente de informao.
O aspecto Interaction do papel de Caller envia uma mensagem de solicitao ao agente de informao.
:Caller Interaction :Information Agent
:Chair searchProfile() events_() init() checkSearchResult() prepareQueryMessage()
:Caller
outgoinMsg_() sendMsg()
searchProfile()
Figura 63. Padro Papel: ativando um papel quando a informao no encontrada.
Conseqncias. O padro Papel satisfaz quase todos os princpios do papel. Ele oferece suporte a instncias do agente que exercem mais de um papel ao mesmo tempo. Esses papis podem ser independentes (multiplicidade do papel) ou podem ser agregados (composio do papel). A multiplicidade do papel pode ser implementada
155
indexando os papis por contexto em que aparecem. Tambm tem os benefcios a seguir em relao ao padro Objeto do Papel: Ausncia de mistura da interface. O padro no requer que as interfaces de todos os papis sejam fornecidas em uma nica interface como no padro Papel do Objeto. A interface intrnseca do agente no misturada com cada interface do papel potencial. O comportamento extrnseco acessvel sem delegaes sucessivas. Minimizao da esquizofrenia do agente. A maior parte dos comportamentos especficos a agente reside no objeto; somente o relacionamento do papel e o contexto do papel residem no aspecto. No h classes intermedirias como no padro Papel do Objeto.
Melhor separao de concerns. Os tipos de agente no tm referncia a seus papis. O grau de acoplamento do SMA tambm aumenta.
Menor nmero de componentes. O padro Papel no requer classes adicionais como AgentRole e AgentInterface, que so participantes centrais no padro Papel do Objeto.
Falta de replicao do cdigo. No h necessidade de replicao de todas as assinaturas de mtodos do papel em uma AgentInterface. Como conseqncia, facilita as atividades de manuteno.
Plug and Play. Com a evoluo do sistema multiagentes, novos papis do agente precisam ser adicionados de forma transparente a um tipo de agente. Os desenvolvedores de agentes somente precisam adicionar novos pointcuts para associar o tipo de agente ao novo aspecto de papis. Por outro lado, o uso do padro Papel possui algumas desvantagens:
Refatorao necessria. Em algumas circunstncias, a realizao do padro Papel afeta a estruturao das classes Kernel. Isso requer a reestruturao dessas classes a fim de expor join points adequados. Por exemplo, precisamos garantir que cada mtodo que busca o perfil do usurio retorne um valor de objeto de forma que o aspecto possa capturar a resposta do usurio e verificar
156
se o valor retornado foi nulo. Alm disso, extramos o cdigo dos mtodos de planos existentes para criar um novo mtodo para expor um join point no nvel do mtodo. As ferramentas para ajudar o processo de reestruturao facilitariam a introduo de aspectos em um sistema existente. A descrio de aspectos de papis depende de classes principais especficas. Os nomes das classes do conhecimento aparecem na definio dos aspectos de papis. Portanto, a descrio de um aspecto de papis no pode ser diretamente aplicada a outras classes principais. A abordagem RoleEP [240] resolve os pontos fracos desse padro. Variantes. Papis intrusivos. Essa soluo requer a instncia do aspecto para adicionar o comportamento do papel, informando aos membros do papel que j existem em uma instncia central [136]. Ela requer que o comportamento do papel
esteja disponvel na interface da classe do agente, uma vez que s os membros existentes podem ser modificados. O variante diminui a separao dos concerns entre o agente e seus papis. Papis estticos. Esse variante introduz o comportamento do papel em uma classe do agente, em vez de no nvel de instncia do agente [136]. Isso significaria que todas as instncias de um dado tipo de agente exercem os mesmos papis, violando a dinamicidade do papel. Aspectos de Papis como conectores. Os papis e os tipos de agente so classes nessa soluo. Um aspecto esttico integra ou compe as hierarquias das classes do papel e as hierarquias dos tipos de agente. Essa abordagem parece ser extensvel [136]. Contudo, ela requer trs nveis de componentes (objetos centrais representando os agentes, os papis e aspectos) e fica complexa quando h muitas dependncias entre papis e objetos centrais. Alm disso, ela no satisfaz o princpio da identidade. Usos conhecidos. Kendall [136] usa e implementa os trs variantes acima usando AspectJ. Em seu modelo de papel, um objeto possui mtodos/atributos intrnsecos centrais e um papel que adiciona mtodos/atributos extrnsecos e fornece perspectivas que podem ser usadas por outros objetos. Kendall recomendou uma abordagem alternativa: (i) introduzir a interface para o comportamento especfico a papis na
157
classe central; (ii) informar a implementao do comportamento especfico a papis a instncias da classe central; (iii) adicionar relacionamentos e contextos do papel na instncia do aspecto. Entretanto, a soluo de Kendall requer que os clientes conheam os aspectos de papis; aumentando, ento, o acoplamento do sistema. Ubayashi e Tamai [240] propuseram a abordagem RoleEP (Role Based Evolutionary Programming) que uma realizao do padro Papel. Epsilon/J um framework que oferece suporte abordagem RoleEP. Um objeto RoleEP torna-se um agente, ligando-se a um papel definido no ambiente e adquire as funes de colaborao dinamicamente. No entanto, sua proposta tem algumas limitaes: o cdigo de ligao do papel entrelaado ao cdigo de agente no-colaborativo, e a classe do tipo de agente precisa implementar alguns mtodos de uma interface RoleEP. Finalmente, implementamos o padro Papel no sistema Portalware (Captulo 4) e no
sistema EC. Padres relacionados. O padro Papel uma alternativa melhor do que a combinao do padro Objeto do Papel [19] com o padro Decorador [79], que a melhor soluo conhecida orientada a objetos para a implementao de papis do agente [77, 136, 146]. O padro Papel usa o padro Kernel do Agente uma vez que os papis modularizam o conhecimento extrnseco e afetam as classes do kernel. Esse padro tambm est relacionado a todos os outros padres em nossa linguagem de padres, uma vez que pode refinar aspectos de agncia e aspectos adicionais a um contexto do papel. Um modelo do papel fornecido no padro Burocracia [203, 204]. Esse padro normalmente encontrado em sistemas de software [204], mas tambm captura a estrutura das burocracias humanas [136]. O padro Papel pode ser usado juntamente com alguns padres existentes em estratgias de coordenao e colaborao especficas. Alguns exemplos clssicos so: Reunio, Bloqueio, Mensageiro, Facilitador e Grupo Organizado [10].O padro Blackboard Reflexivo, apresentado em outro trabalho [221], oferece suporte colaborao guiada por eventos. Hayden et al. propem um sistema de padres arquiteturais para a coordenao multiagentes [117]. Lea [154] prope um conjunto de padres de concorrncia que podem ser usados para coordenar vrios papis. De fato, usamos o padro Objeto Compartilhado no sistema Portalware (Captulo 4) para
158
coordenar as atividades do papel. Finalmente, dependendo da complexidade do papel, a implementao de AspectJ do padro Papel requer o uso de idiomas avanados, como o Mtodo Pointcut e Pointcut Abstrato [114].
5.8 O padro Mobilidade Inteno. O padro Mobilidade desacopla o comportamento da mobilidade da funcionalidade bsica do agente e outros concerns do agente. Tambm conhecido como. Padro Deslocamento, Padro Migrao. Contexto. Vrios tipos de agentes e papis podem ter a propriedade de mobilidade. Durante a execuo de seus planos, um agente mvel pode se mover de um ambiente em uma rede para outro a fim de alcanar seus objetivos. Muitas facetas de uma
estratgia de mobilidade devem ser consideradas [240], incluindo a especificao: dos elementos do agente (papis e tipos de agente) que so mveis, das circunstncias em que o agente precisa se mover, da partida para ambientes mveis, do retorno ao ambiente host e do itinerrio do agente. Essas facetas da estratgia de mobilidade devem sem diretas em relao s funcionalidades bsicas dos agentes. Exemplo de motivao. Os agentes do usurio do EC precisam se mover em determinadas circunstncias. Por exemplo, quando um agente est exercendo o papel de chair, ele precisa consultar os perfis dos revisores a fim de otimizar a distribuio de trabalhos em termos dos interesses de cada um. Se o perfil de um revisor no estiver disponvel, ele colabora com um agente de informao e solicita a esse agente as informaes sobre um determinado revisor. O agente de informao controla o banco de dados local e consegue buscar o perfil. Entretanto, se as informaes no estiverem disponveis no banco de dados, o agente da chair precisa se mover e tentar encontrar o perfil que est faltando nos ambientes remotos. O agente atribui a tarefa de busca aos agentes de informao dispersos na Internet ao fazer a migrao por hosts. H diversos frameworks orientados a objetos que oferecem suporte implementao do concern da mobilidade em agentes de software, como Aglets [120,
159
152] e JADE [20]. Ubayashi e Tamai [240] apresentam abordagens orientadas a objetos para a separao do concern de mobilidade da funcionalidade do agente e de outros concerns, como a colaborao. Eles apresentam o sistema de padres do projeto de Aridor e Lange [10, 152] como uma das melhores solues orientadas a objetos. Esses padres de projeto foram implementados no framework Aglets. Nessa abordagem, o padro Itinerrio possui as informaes para a migrao ele encapsula em uma instncia da classe Itinerary. Para tornar um tipo de agente mvel, a classe do tipo de agente definida como uma subclasse da classe Agent. Todavia, Ubayashi e Tamai [240] defendem que essa soluo baseada em padro possui algumas limitaes para fornecer o isolamento do concern de mobilidade. Apesar de as funes de mobilidade (cdigo para a migrao em hosts) serem separadas das funes de colaborao (aes do papel), elas so misturadas
com as aes bsicas do agente dentro das classes do kernel do agente. Se um agente precisar ter vrios papis ou aes de mobilidade, seu cdigo ser mais complexo [240]. Como todos os agentes mveis precisam estender a classe Aglets, a classe do tipo de agente possui uma referncia explcita classe Aglet. Tambm possui uma referncia explcita a uma instncia da classe Itinerary. As aes bsicas do agente esto entrelaadas com chamadas explcitas ao mtodo roam(). Esses problemas no so especficos aos padres Aridor e Lange. Os frameworks de mobilidade normalmente impem nas classes do agente a extenso de classes especficas mobilidade, a extenso de mtodos abstratos dessas classes de mobilidade e a chamada de mtodos de mobilidade nas aes bsicas do agente. A Figura 64 ilustra problemas similares ao usar o framework JADE em agentes dos usurios do EC. Observe que o cdigo de mobilidade afeta os diversos mtodos e as classes de papis e planos. Alm disso, outros revisores tm de herdar o comportamento de mobilidade mesmo quando no ser realizada nenhuma ao de mobilidade no contexto desse papel. Supondo que algumas instncias de outros revisores sero mveis e outras sero estticas, um nvel de herana precisa ser adicionado ao sistema a fim de separar o outro revisor mvel e esttico nas diferentes classes. Ademais, todas as classes do agente precisam ser serializadas nos ambientes Java, ou seja, as classes do agente precisam implementar a interface Serializvel para
160
fins de mobilidade. A abordagem baseada em mixins [26] normalmente usada para tratar esse tipo de problema. Nesse caso, as funes solicitadas para um gerenciador podem ser descritas em uma superclasse. Se um agente possui muitos papis, o agente precisa herdar estaticamente as superclasses correspondentes. Portanto, o cdigo do programa precisa ser modificado sempre que os papis solicitados para um agente so adicionados ou excludos. Alm do mais, vrias heranas no so permitidas em muitas linguagens de programao, como Java.
Agent
getName() move() beforeMove() afterMove() ..
Information Agent
database move() beforeMove() afterMove() returnHome()
Reviewer
papersToReview chairName biddingDeadline move() beforeMove() afterMove() returnHome()
Chair
papers submissionDeadline getPapers() getDeadline() move() beforeMove() afterMove() returnHome()
SearchingPlan
executePlan() executeQuery() searchProfile()
Legend: underlined - mobility concern JADE class
Additional Reviewer
reviewer
public Result searchProfile(...) { ... chair.move(); ... chair.returnHome(); ... }
Figura 64. Concern de mobilidade: afetando papis, planos e tipos de agente.
Problema. O fato de agentes e seus papis mudarem sua localizao no deve afetar sua funcionalidade bsica. O uso de solues orientadas a objetos tende a entrelaar o cdigo da mobilidade dentro da funcionalidade bsica do agente. Como conseqncia, difcil entender colaboraes entre agentes e deslocamentos de agentes individuais de uma forma geral, o que, por sua vez, diminui a manutenibilidade e reusabilidade do sistema. difcil definir funes e comportamentos de agentes de forma elegante porque no h suporte para defini-los independente do cdigo de mobilidade. Alm disso, complicado estender o cdigo relacionado a cada concern. Como os agentes incorporam a propriedade de
161
mobilidade sem ter sua funcionalidade bsica entrelaada com o concern de mobilidade? As foras a seguir so associadas a esse problema: O projeto deve oferecer suporte introduo uniforme dos comportamentos de mobilidade dos tipos de agente e papis. Quando um papel se move, seu agente associado precisa ser movido, uma vez que o papel depende das classes do kernel de agente (Seo 5.3).
Soluo. Usar aspectos para melhorar a separao entre o concern de mobilidade e outros concerns do agente. O aspecto de mobilidade usado para modularizar a estratgia de mobilidade que afeta muitas partes do agente do software. Um aspecto de mobilidade separa o comportamento de mobilidade de elementos de conhecimento
do agente, como aes e planos, tipos de agente e aspectos de papis. Ele implementa no apenas as aes de mobilidade bsicas, mas tambm a especificao de quais tipos de agente ou papis so mveis, a declarao das circunstncias de deslocamento, as chamadas de mtodos de partida e retorno e o controle do seu itinerrio. Os aspectos de mobilidade definem como e quando os agentes se deslocaro para outros ambientes. Esses aspectos conseguem afetar alguns pontos de execuo do agente por exemplo chamadas a mtodos nas classes Plan e alteram sua execuo normal a fim de verificar a necessidade de transferir o agente para outro host. O prprio aspecto chama os mtodos responsveis pela implementao das aes de mobilidade. Nenhum cdigo de mobilidade permanece nos outros aspectos e classes do agente.
Estrutura. O padro Mobilidade possui dois participantes principais e duas categorias cliente: Principais Participantes: Elemento mvel representa o elemento mvel pode ser um papel ou um tipo de agente.
162
Aspecto Mobility implementa todo o comportamento de mobilidade.
Participantes cliente: Elemento do conhecimento fornece o contexto a partir do qual as aes de mobilidade so disparadas esse elemento no possui cdigo de mobilidade. Framework de mobilidade parte do framework de mobilidade usado e fornece os servios de mobilidade. A estrutura do padro Mobilidade (Figura 65) possui algumas partes que so
comuns a todas as instanciaes potenciais do padro e outras partes que so especficas a cada instanciao. As partes comuns so: 1. Os eventos genricos que disparam a partida do agente para ambientes remotos. 2. O protocolo de mobilidade geral: a. os eventos so escolhidos b. as condies so verificadas e c. as aes de mobilidade so chamadas. 3. As aes de mobilidade genricas: 4. O objeto itinerrio. As partes especficas para cada instanciao do padro so: 5. Os eventos especficos associados a um contexto especfico (tipo de agente ou papel) quando o agente precisa ser movido as classes ou aspectos precisam ser observados. 6. As aes de mobilidade especficas:
163
Traveling
is Mobile moving_() returning_()
Mobility
itinerary ... move() returnHome() addHost() prepareToMove() ...
Mobility Framework
move() ...
Role AgentType
belief1 belief2 ... goals plans action1() action2() ...
* Plan executePlan() ...
Figura 65. A viso esttica do padro Mobilidade.
O propsito dos aspectos Mobility desacoplar os comportamentos de mobilidade dos diferentes papis do agente. Eles modularizam a estratgia de mobilidade de um agente ou de um papel, separando-a de sua funcionalidade bsica. Todas as estratgias de mobilidade esto localizadas no cdigo-fonte do aspecto. Esse aspecto contm os pointcuts que descrevem os eventos que devem levar o agente a se deslocar para um ambiente remoto. Os aspectos Mobility tambm contm os advices associados a esses pointcuts. Os advices so responsveis por verificar a necessidade de migrao do agente e pela chamada das aes de mobilidade. O aspecto Mobility possui duas partes principais: o aspecto em si e uma interface crosscutting. Ele possui as estruturas de dados e os mtodos que controlam o itinerrio do agente. O aspecto tambm implementa os mtodos para deslocamento at um novo ambiente e retorno ao host original.
164
Traveling
is Mobile moving_() returning_()
Mobility
Traveling
is Mobile
Chair Mobility
Chair
papersToReview deadlines ... goals plans
moving_() returning_()
JADE Agent
move() ...
SearchingPlan
executePlan() executeQuery() searchProfile() ...
getPapers() ...
Figura 66. O padro Mobilidade do papel de Chair.
A interface crosscutting Deslocamento define quais tipos de agente e papis so mveis. Tambm define quando esses elementos do SMA devem se mover. Define os pointcuts nas classes do agente ou aspectos de papis que devem disparar a migrao do agente. H dois pointcuts: o primeiro especifica quando o agente deve se mover para outro ambiente, o segundo especifica quando o agente deve voltar para o ambiente original. Ele contm dois advices que so executados depois da execuo das aes em subclasses Agent, aes em subclasses Plan ou aes em aspectos de papis. Dependendo do framework de mobilidade usado em um determinado SMA, a interface tambm descreve as classes que so serializadas ou devem implementar interfaces de framework especficas (representadas por is Mobile na Figura 65). Como conseqncia, as classes do agente no esto entrelaadas com o cdigo de mobilidade, melhorando, assim, sua manutenibilidade e reusabilidade. Os pointcuts so declarados como abstratos porque precisam ser redefinidos para papis e tipos de agente especficos.
165
O aspecto Mobility no sistema EC afeta cerca de 7 classes e aspectos do agente. A Figura 66 ilustra a instanciao de padres do papel de chair nesse sistema. Ela mostra o aspecto ChairMobility afetando o aspecto Chair e a classe SearchingPlan. O aspecto Mobility afeta esse plano porque quando o mtodo searchProfile() retorna nulo, o agente precisa se mover. O pointcut que se move define as execues do mtodo searchProfile() como os join points de interesse do aspecto ChairMobility. Tambm afeta o aspecto Chair porque o agente precisa fazer uma migrao dependendo dos resultados de algumas aes de papel internas, como o mtodo getPapers(). Dinmica. Alguns cenrios so descritos a seguir a fim de ilustrar o comportamento dinmico do padro Mobilidade. Os cenrios mostram como os aspectos de mobilidade movem os agentes e os papis de forma transparente.
Cenrio I Movendo um papel do agente sempre que seu plano no consegue encontrar uma informao, ilustrado pela Figura 67, apresenta o comportamento do padro quando o aspecto de mobilidade detecta a necessidade de mover o agente para um ambiente remoto: O plano de busca da chair chamado. O aspecto ChairMobility detecta a execuo do mtodo searchProfile() na classe SearchingPlan. Esse aspecto rene as informaes necessrias do contexto do plano, ou seja, o valor de retorno do mtodo searchProfile(). O aspecto de mobilidade detecta a necessidade de mover o agente que exerce o papel de chair. O aspecto chama o mtodo prepareToMove() para executar as ltimas aes antes da migrao do agente. O aspecto ChairInteraction intercepta a execuo desse mtodo para notificar os demais agentes no ambiente para o qual o agente est se movendo. 5
Essa funcionalidade s vezes fornecida pelo framework de mobilidade.
166
O aspecto ChairMobility chama o mtodo para mover fisicamente o agente para o ambiente remoto. O mtodo do framework de mobilidade (JADEAgent) implementa o movimento do agente.
:JADE Agent :Chair Interaction
:Chair
:SearchingPlan new()
:ChairMobility
searchProfile() moving_(Hashtable) checkResult() prepareToMove() outgoingMsg_()
sendMsg()
move()
jadeAgent.move()
Figura 67. Padro Mobilidade: movendo quando um plano no consegue encontrar informaes.
Cenrio II Movendo um agente do papel sempre que sua ao interna no consegue encontrar uma informao, ilustrado pela Figura 68, apresenta o comportamento do aspecto Mobility quando ele detecta a necessidade de mover o papel do agente para um novo ambiente: O mtodo getPapers() chamado. O aspecto ChairMobility detecta a execuo do mtodo getPapers() no aspecto Chair. Esse aspecto rene as informaes necessrias do contexto do plano, ou seja, o valor de retorno do mtodo getPapers(). O aspecto ChairMobility detecta a necessidade de mover o agente que exerce o papel de chair. O aspecto chama o mtodo prepareToMove() para executar as ltimas aes antes da migrao do agente. O aspecto ChairInteraction intercepta a execuo desse mtodo para notificar os demais agentes no ambiente para o qual o agente est se movendo.
167
O aspecto chama o mtodo para mover fisicamente o agente para o ambiente remoto.
:Chair :ChairMobility :JADE Agent :Chair Interaction
getPapers() moving_(Hashtable) checkResult() prepareToMove() outgoingMsg_() jadeAgent.move()
sendMsg()
move()
Figura 68. Padro Mobilidade: movendo quando uma ao do papel no consegue encontrar informaes.
A dinmica do padro semelhante ao caso em que uma ao de um tipo de agente dispara o deslocamento do agente.
Conseqncias. A soluo de padro fornece os benefcios a seguir: Melhor separao de concerns. O concern de mobilidade modularizado em aspectos. As classes do agente bsicas no implementam o comportamento de mobilidade e no so alteradas a fim de implementar a estratgia de mobilidade. O cdigo dos aspectos de papis tambm se mistura ao cdigo de mobilidade. Flexibilidade. As estratgias da mobilidade exploradas na aplicao do SMA podem variar medida que o sistema se desenvolve. O projeto mais flexvel a fim de oferecer suporte alterao da estratgia de mobilidade usada. Transparncia. O concern de mobilidade pode ser adicionado ou removido de forma transparente aos/dos agentes estticos uma vez que seu cdigo no precisa ser alterado. Melhor suporte para manuteno. H duas outras questes no protocolo de mobilidade que normalmente mudam: (i) os pontos de execuo do agente que
168
disparam a migrao do agente e (ii) os eventos que disparam o retorno do agente para o local original. Como a definio desses pontos e eventos est localizada em um nico mdulo, o aspecto Mobilidade, a manutenibilidade do agente melhorada. Apesar de o concern de mobilidade ser completamente definido separado de outros concerns do agente, o uso do padro impe alguns problemas ao projetista do SMA: Refatorao necessria. Em algumas circunstncias, a realizao do padro Mobilidade requer a reestruturao do cdigo-base associado aos outros componentes do agente a fim de expor join points adequados. Ocorre uma questo semelhante com o padro Autonomia e o padro Papel.
A descrio dos aspectos Mobility depende das classes Core especficas. Os nomes das classes do agente e dos aspectos de papis aparecem na definio dos aspectos Mobility. Portanto, a descrio de um aspecto de mobilidade no pode ser diretamente aplicada a outras classes Core. Esse problema similar quele encontrado no padro Papel (Seo 5.7).
Variantes. Mobilidade reflexiva. Esse variante similar soluo orientada a aspectos apresentada aqui. A diferena est no uso dos metaobjetos como alternativa aos aspectos. No entanto, essa abordagem requer um protocolo metaobjeto [165] que normalmente introduz alteraes na mquina virtual. Alm disso, as solues reflexivas no oferecem suporte composio dos metaobjetos de mobilidade com outros concerns. Como a complexidade do agente aumenta, bons mecanismos de composio so essenciais para a manutenibilidade e reusabilidade do sistema. Usos conhecidos. Implementamos o padro Mobilidade no sistema Portalware (Seo 4.1) e no sistema EC. O framework Epsilon/J, que oferece suporte abordagem RoleEP [240], implementou o variante reflexivo. A abordagem RoleEP s oferece suporte mobilidade do agente e mobilidade do papel, e os programadores de agente tm de estender vrias interfaces Epsilon/J e classes abstratas. Em RoleEP, o uso de operao de ligao [240] elimina a necessidade de processos de
169
combinao no estilo POA. As inter-type declarations em AspectJ podem ser substitudas adicionando mtodos de papel pela operao de ligao. Contudo, processos de combinao de advices no correspondem a qualquer construto de modelo em RoleEP. Esse um ponto fraco de RoleEP e reduz a capacidade de evitar a duplicao de cdigo. A partir do ponto de vista da evoluo esttica, o processo de combinao de advices muito til porque evita a duplicao de cdigo. Padres relacionados. O padro Mobilidade est relacionado ao padro Kernel do Agente (seo 5.3) uma vez que o aspecto de mobilidade escolhe join points em classes do plano e classes do tipo de agente. Alm disso, esse aspecto afeta vrias classes do conhecimento a fim de serializ-las. Nesse sentido, o padro Mobilidade afeta quase todas as demais classes do padro, uma vez que todas as classes do agente precisam ser serializadas para fins de mobilidade. Conforme mostrado anteriormente,
o padro Mobilidade est relacionado a: (i) o padro Papel quando os papis so mveis e (ii) o padro Interao para notificar os agentes locais de uma migrao de agente. O padro Mobilidade pode estar combinado ao padro Itinerrio[10] a fim de registrar as aes e planos executados em cada host visitado. Tambm pode ser usado em conjunto com estratgias de mobilidade especficas, como Forwarding e Ticket [10]. O padro Mobilidade potencialmente usado em conjunto com alguns padres existentes para a coordenao e a colaborao remota especficas. Alguns exemplos clssicos so: Reunio, Bloqueio, Mensageiro, Facilitador e Grupo Organizado [10]. O padro Blackboard reflexivo, apresentado em outro trabalho [221], oferece suporte mobilidade com base em espaos de tuplas distribudos. Yoshioka et al. [250] propem um sistema de padres para implementar polticas de segurana para agentes mveis que podem ser combinados com o padro Mobilidade.O padro Mobilidade pode ser conectado a vrios padres clssicos, como: (i) o padro Factory Method [79] permite que os manipuladores de migrao real e virtual sejam instanciados conforme necessrio em tempo de execuo, (ii) o padro Objeto Ativo trata do acesso a recursos compartilhados [153], (iii) o padro Visitante usado para a configurao remota [79] e (iv) o padro Proxy usado em questes de migrao
170
virtual [79]. Finalmente, a implementao de AspectJ do padro Mobilidade requer o uso de idiomas avanados, como o Mtodo Pointcut e Pointcut Abstrato [114].
5.9 O padro Aprendizagem Inteno. O padro Aprendizagem modulariza o protocolo de aprendizagem. Ele separa no s os algoritmos de aprendizagem, mas tambm o processo de coleta de informaes a fim de oferecer suporte ao processo de aprendizagem, desacoplando a estrutura bsica do agente do protocolo de aprendizagem. Especifica como extrair informaes dos diferentes componentes do agente que so necessrios para permitir a aprendizagem do agente. Ele conecta as classes do agente aos componentes de aprendizagem especficos, tornando a funcionalidade bsica do agente transparente
em relao s particularidades dos algoritmos de aprendizagem em uso. Tambm conhecido como. Padro Protocolo de Aprendizagem. Contexto. Os agentes cognitivos aprendem com base em sua experincia como resultado de suas aes, seus erros, as interaes sucessivas com o mundo externo e a colaborao com outros agentes [39, 172, 207]. A separao do protocolo de aprendizagem necessria para facilitar a manuteno e reutilizao dos componentes do agente. Exemplo de motivao. A fim de aprender as preferncias do usurio, os agentes de usurio no sistema EC supervisionam suas aes, a interao com os componentes dos diversos ambientes e suas colaboraes interagente. Por exemplo, eles observam as mensagens trocadas entre revisores e chairs. Esses agentes usam duas tcnicas de aprendizagem diferentes: Temporal Difference Learning (TD-Learning) [172] e Least Mean Squares (LMS) [172]. O primeiro necessrio para o contexto do papel de revisor e o ltimo no contexto do papel de chair. Os revisores aplicam TD-Learning para aprender as preferncias do usurio nos assuntos de que gosta ou no de revisar de acordo com as interaes com o usurio. A chair implementa LMS para aprender sobre as preferncias do revisor com base nas interaes com os agentes revisores.
171
Legend: ____ learning code Observer classes
Observable
addLC() removeLC() notifyLC()
Learning Component
learningRate processInformation()
Strategy pattern
JADEAgent
getName() moveAgent() beforeMove()
TD-Learning
processInformation() getTD() getReward() setReward()
LMS
processInformation() getLR()
Role
collaboratingAgents collaborationProtocol getName() addAgent() removeAgent()
Agent
goals plans agents addAgent() removeAgent()
RevisionProposal
reviewer Paper deadlines currentPaperInterest proposalEvaluation isAccepted() getReviewer() getPaper() getPaperInterest() getEvaluation()
Plan
goal agent preConditions() posConditions() clone() createObject() executePlan()
UserAgent Chair Reviewer

chairName learningComponents setChair() addLC() removeLC() notifyLC() setChair() goals plans Agents myRoles learningComponents addAgent() removeAgent() executePlan() addLC() removeLC() notifyLC()
DistributionPlan
learningComponents addLC() removeLC() notifyLC() executePlan() distributePapers() ...
JudgementPlan
learningComponents addLC() removeLC() notifyLC() executePlan() judgeProposal() ...
papers learningComponents submissionDeadline reviewDeadline addLC() removeLC() notifyLC() getPapers() getReviewers() ...
Judgement ReceptionPlan
learningComponents addLC() removeLC() notifyLC() executePlan() evaluateResponse() ...
Figura 70. Aprendizagem: o padro Observador com o padro Estratgia.
Uma abordagem orientada a objetos flexvel para projetar o protocolo de aprendizagem baseia-se na combinao do padro Observador com o padro Estratgia [137, 211, 212]. O padro Observador [79] til para implementar o mecanismo para o monitoramento de eventos, enquanto o padro Estratgia [79] necessrio para torn-lo flexvel em relao s estratgias de aprendizagem. Considere um exemplo concreto dessa abordagem no contexto do sistema EC, conforme demonstrado na Figura 70. Nesse sistema, o padro Observador usado para notificar os componentes de aprendizagem sobre os eventos relevantes que disparam o processo de aprendizagem. As operaes nas classes Plan, Agent, Role e Belief so monitoradas para fornecer ao componente de aprendizagem as informaes contextuais e dar incio ao processo de aprendizagem. O componente Observvel uma interface e uma classe no-abstrata porque as classes observveis j estendem uma classe abstrata (JADEAgent). Muitas linguagens de programao orientadas a
172
objetos no oferecem suporte a vrias heranas. Conforme mencionado anteriormente, Java, a linguagem orientada a objetos mais comum e expressiva para a implementao de SMAs [22, 20, 181], no oferece suporte a esse recurso. As classes Agent e Role no implementam a interface Observvel porque a aprendizagem no uma propriedade de agncia (Seo 3.3). Alguns papis e tipos de agente so monitorados pelos mecanismos de aprendizagem. A classe LearningComponent implementa o padro Estratgia e representa uma famlia de algoritmos diferentes que implementam as tcnicas de aprendizagem. As subclasses de LearningComponent podem de alguma forma variar independente das classes do agente que as usam. As subclasses TD-Learning e LMS implementam os algoritmos de aprendizagem especficos. Todavia, a introduo do protocolo de aprendizagem possui um grande impacto na estrutura do agente. Ele afeta as
diferentes classes do agente e aspectos. Conforme mostrado na figura, o cdigo para a implementao desse padro se espalha pelas hierarquias de classes de um agente de software. Todos os participantes (ou seja, Chair, Revisor, UserAgent,
RevisionProposal, os planos) devem implementar o mecanismo de observao e, conseqentemente, possuir o cdigo de aprendizagem. Adicionar ou remover o cdigo de aprendizagem das classes requer alteraes nessas classes. A alterao no mecanismo de notificao (como alternar entre os modelos de push e pull [79]) requer alteraes em todas as classes participantes. Problema. Os padres de projeto orientados a objetos normalmente tm vrios efeitos indesejveis ao tratar da propriedade de aprendizagem. O concern de aprendizagem afeta naturalmente as hierarquias de classes, perdendo sua modularidade. Ele afeta os tipos de agente, os planos, papis, crenas e outros objetos. Essas classes precisam ser interligadas ao cdigo de aprendizagem a fim de fornecer aos componentes de aprendizagem as informaes contextuais. Isso dificulta a distino entre o protocolo de aprendizagem e outros concerns de agente envolvidos. A adio, remoo e modificao do concern de aprendizagem de um SMA so normalmente invasivas, difceis de reverter. Como separar o concern de aprendizagem dos demais concerns de agncia? As foras a seguir surgem desse problema:
173
A manuteno dos eventos e as estratgias de aprendizagem no devem afetar a funcionalidade bsica do agente. Deve ser fcil reutilizar os protocolos bsicos de aprendizagem para diferentes papis e tipos de agente. As classes do kernel do agente no devem se misturar ao conhecimento especfico aprendizagem.
Soluo. Usar aspectos para melhorar a separao do protocolo de aprendizagem. Os aspectos Learning (Figura 71) so usados para modularizar o protocolo de aprendizagem que afeta muitas partes de um agente de software. Eles separam o comportamento de aprendizagem das classes do agente, como tipos de agente, planos, papis, crenas etc. Em outras palavras, os aspectos so usados no s para
modularizar o centro do concern de aprendizagem, mas tambm para isolar todo o comportamento relacionado coleta de informaes e ao conhecimento especfico aprendizagem. Usando os aspectos Learning, definimos quando e como o agente aprende. Eles conectam os pontos de execuo (eventos) das diferentes classes do agente com as estratgias de aprendizagem correspondentes. Esses aspectos conseguem afetar alguns pontos de execuo do agente por exemplo chamadas de mtodos nas classes do kernel do agente a fim de alterar sua execuo normal e disparar um componente de aprendizagem. Eles monitoram esses pontos de execuo (eventos) a fim de identificar quando um processo de aprendizagem deve ser disparado. Esses eventos incluem a alterao de um elemento do conhecimento, execuo de aes em planos, papis, tipos de agente ou ainda alguma exceo levantada. As classes auxiliares so usadas para implementar diferentes tcnicas de aprendizagem. Estrutura. O padro Aprendizagem possui dois participantes principais e um participante cliente: Principais Participantes: Aspecto Learning define o protocolo de aprendizagem.
174
Componente de aprendizagem Implementa uma estratgia de aprendizagem especfica.
Participante cliente: Elemento do conhecimento Oferece os eventos relevantes e informaes contextuais para fins de aprendizagem pode ser uma classe Belief, uma classe Plan, uma classe Agent ou um aspecto do agente (papel, interao, ...).
Information Gathering Agent Belief events_()
Learning
learnPreferences() updatePreferences() ... Learning Component
learningRate processInformation() ...
Plan Aspect Learning Knowledge belief1 belief2 ... action1() action2() ...
Figura 71. A viso esttica do padro Aprendizagem.
Na estrutura do padro Aprendizagem (Figura 71), algumas partes so comuns a todas as instanciaes potenciais do padro, e outras partes so especficas a cada instanciao. As partes comuns so: 1. Os eventos genricos em que o agente sempre aprende, por exemplo, quando uma mensagem recebida. 2. O protocolo de aprendizagem geral: a. os eventos so detectados b. as informaes contextuais so recebidas e c. os componentes de aprendizagem so chamados. 3. A lista de componentes de aprendizagem, ou seja, as referncias a estratgias de aprendizagem mais sofisticadas.
175
As partes especficas so: 5. A especificao dos eventos especficos associados a um contexto especfico em que o agente precisa aprender. 6. A coleta de informaes especficas: 7. A configurao das estratgias de aprendizagem especficas usadas.
O propsito do aspecto Learning tornar os agentes mais espertos. O aspecto Learning estende as classes do agente para introduzir o protocolo de aprendizagem. Ele possui trs partes principais: o prprio aspecto e duas interfaces crosscutting. O seu propsito tornar os agentes mais espertos. Alm disso, ele estende as classes do agente para introduzir o protocolo de aprendizagem. Possui trs partes principais: o prprio aspecto e duas interfaces crosscutting. O aspecto possui a lista de
componentes de aprendizagem especializados e os mtodos para atualizar o conhecimento do agente uma vez que novas concluses so obtidas a partir dos componentes de aprendizagem. As interfaces crosscutting definem como o aspecto Learning afeta as diferentes classes de agentes de software. A interface InformationGathering define os join points que descrevem as informaes e eventos relevantes que devem ser reunidos das classes do agente a fim de permitir o processo de aprendizagem. Ele contm os advices que chamam os mtodos responsveis pela implementao do comportamento de aprendizagem ou de um componente de aprendizagem especfico. Os advices normalmente executam depois de execues de aes de classes do agente, aes de classes do plano e outros aspectos associados ao agente (por exemplo, os aspectos de papis Seo 5.7). A interface LearningKnowledge introduz as diferentes crenas especficas aprendizagem e as aes em diferentes classes do agente ou papis com base em inter-type declarations. A Figura 72 ilustra a instanciao de padres do sistema Expert Committee. O aspecto Learning e seus subaspectos afetam os diferentes aspectos do agente e classes nesse sistema, cerca de 12 componentes. No entanto, a figura somente apresenta um conjunto parcial das classes afetadas pelos aspectos Learning. Ela mostra o aspecto Reviewer, a classe RevisionProposal, a classe UserAgent e a classe JudgementPlan. O aspecto Learning possui dois subaspectos: ChairLearning e ReviewerLearning; a
176
Figura 72 ilustra ReviewerLearning. Esse aspecto afeta a ao de julgamento de uma proposta, o mtodo judgeProposal() na classe JudgementPlan, porque uma vez concludo o julgamento, as informaes relacionadas a ele so usadas pelo aspecto Learning a fim de aprender sobre as preferncias do usurio. O aspecto ReviewerLearning rene as informaes associadas ao julgamento da proposta e o componente de aprendizagem associado chamado (a classe TDLearning nesse caso). O aspecto ReviewerLearning tambm intercepta os mtodos no aspecto Reviewer e na classe UserAgent. A Figura 72 tambm ilustra como a interface LearningKnowledge do aspecto Learning modifica a estrutura da crena RevisionProposal. Ela introduz os atributos paperInterest e avaliao e os setters e getters associados.
Learning Knowledge
RevisionProposal
reviewer Paper deadlines isAccepted() getReviewer() getPaper()
paperInterest evaluation
Learning
learnPreferences() updatePreferences() ...
... getInterest() getEvaluation() ...
Information Gathering events_() Reviewer UserAgent JudgementPlan

executePlan() judgeProposal() ...
Reviewer Learning
initTDLearning() getResponse() ... TD-Learning
processInformation() getTD() getReward() setReward()
Figura 72. O padro Aprendizagem para o agente de usurio do EC.
Observe que todo o cdigo de aprendizagem foi removido das classes do agente e foi implementado separadamente em aspectos de aprendizagem associados, conforme j explicado. Esse tipo de aspecto parece ser um padro orientado a aspectos genrico e comum, no qual os aspectos juntam a funcionalidade de suas classes associadas ao cdigo do sistema original. De fato, o cdigo de aprendizagem consiste em aspectos de aprendizagem e classes auxiliares ou interfaces devotadas a
177
implementar as estratgias de aprendizagem especficas. Quando esse cdigo entrelaado ao cdigo do sistema, ele afeta essencialmente as classes do agente; a comunicao entre os aspectos de aprendizagem afeta os objetos, como na classe RevisionProposal.
:Judgement Plan executePlan() judgeProposal()
:Revision Proposal
:Reviewer Learning
:TDLearning
:UserAgent
events_(RevisionProposal) learnPreferences() setPaperInterest() setEvaluation() processInformation(RevisionProposal) getTD()
result updatePreference() setResearchInterests()
Figura 73. A viso dinmica do aspecto ReviewerLearning.
Dinmica. Os cenrios a seguir descrevem o comportamento dinmico do padro Aprendizagem. Cenrio I Reviewer Learning, ilustrado pela Figura 73, apresenta o comportamento do padro quando o aspecto ReviewerLearning detecta que uma ao importante no plano do agente foi realizada e necessria uma aprendizagem: O plano de julgamento executado. As aes de julgamento so realizadas chamando o mtodo judgeProposal() O aspecto ReviewerLearning detecta o final do julgamento interceptando essa execuo de mtodo. Esse aspecto rene as informaes necessrias do contexto do plano, ou seja o objeto RevisionProposal. O aspecto atualiza o objeto RevisionProposal de forma que chair possa aprender com base no julgamento do revisor ele atualiza esse estado de
178
objeto
chamando
os
mtodos
setPaperInterest()
setEvaluation(),
introduzidos pelo aspecto Learning. O aspecto ReviewerLearning seleciona e chama os componentes de aprendizagem correspondentes, a classe TDLearning nesse caso, e fornece as informaes contextuais. Ele executa seus algoritmos especficos e chega a uma concluso, o que leva atualizao do kernel do agente, nesse exemplo a atualizao de uma crena na classe UserAgent.
:Judgement ReceptionPlan executePlan() evaluateResponse() events_(RevisionProposal) learnPreferences() getPaperInterest() setEvaluation() processInformation(RevisionProposal) getLR() calculateWi() result updatePreference() setReviewerInterests() :Revision Proposal :Chair Learning
:LMS
:Chair
Figura 74. A viso dinmica do aspecto ChairLearning.
Cenrio II Chair Learning, ilustrado pela Figura 74, apresenta o comportamento do padro quando o aspecto ChairLearning detecta que uma ao importante no plano do agente foi realizada e necessria uma aprendizagem: O plano para o recebimento do julgamento do revisor executado. As aes para a avaliao do julgamento do revisor so realizadas chamando o mtodo evaluateResponse(). O aspecto ChairLearning detecta a execuo dessa ao e intercepta o final da execuo de mtodo a fim de aprender com base na resposta do revisor. Esse aspecto rene as informaes necessrias do contexto do plano, ou seja, o objeto RevisionProposal. O aspecto rene as informaes necessrias do objeto RevisionProposal de forma que chair possa aprender com base no julgamento do revisor ele pega
179
as informaes chamando os mtodos getPaperInterest() e getEvaluation(), introduzidos pelo aspecto Learning e atualizados pelo aspecto
ReviewerLearning (Cenrio I). O aspecto ChairLearning seleciona e chama os componentes de aprendizagem correspondentes, a classe LMS nesse caso, e fornece as informaes contextuais. O aspecto executa seus algoritmos especficos e chega a uma concluso, o que leva atualizao do conhecimento de chair, nesse exemplo a atualizao de uma crena no aspecto de papis Chair. Os cenrios apresentados anteriormente mostram o comportamento do padro quando o processo disparado pela execuo de aes. Entretanto, os aspectos de aprendizagem podem interceptar as excees que tambm contribuem para a
aprendizagem do agente [39, 207, 172].
Conseqncias. O padro Aprendizagem possui as seguintes conseqncias: Reusabilidade. O protocolo de aprendizagem bsico modularizado em um aspecto de aprendizagem genrico, que pode ser reutilizado e refinado em diferentes contextos. No exemplo anterior, os aspectos ChairLearning e ReviewerLearning reutilizam o protocolo de aprendizagem bsico do aspecto Learning. Melhor separao de concerns. O protocolo de aprendizagem totalmente separado dos demais concerns do agente, como a interao e os concerns bsicos do agente. As classes e os aspectos associados aos demais concerns do agente no possuem cdigo de aprendizagem. Legibilidade e manutenibilidade. O kernel do agente no entrelaado com chamadas de mtodos responsveis pela implementao da aprendizagem. Como conseqncia, melhora a legibilidade, que, por sua vez, melhora a manutenibilidade. Menor replicao do cdigo. Conforme discutido anteriormente, o uso do padro Observador introduz a replicao do cdigo medida que a
180
complexidade do agente aumenta. O padro Aprendizagem oferece suporte ao isolamento do protocolo de aprendizagem em aspectos de aprendizagem, minimizando a replicao do cdigo. Transparncia. Os aspectos so usados para introduzir o comportamento da aprendizagem nas classes do agente de forma transparente. A descrio de quais classes do agente precisam ser afetadas est presente no aspecto, e essas classes monitoradas no so modificadas de forma intrusiva. Facilidade de evoluo. Com a evoluo do sistema multiagentes, novas classes do agente precisam ser monitoradas e disparam o processo de aprendizagem. Os desenvolvedores de SMAs s precisam de novos pointcuts no aspecto de aprendizagem a fim de implementar a nova funcionalidade necessria.
Variantes. Aprendizagem reflexiva. Esse variante similar soluo orientada a aspectos apresentada aqui. A diferena est no uso dos metaobjetos como alternativa aos aspectos. No entanto, essa abordagem requer um protocolo metaobjeto [165] que normalmente introduz alteraes na mquina virtual. Alm disso, as solues reflexivas no oferecem suporte composio dos metaobjetos de aprendizagem com outros concerns. Como a complexidade do agente aumenta, bons mecanismos de composio so essenciais para a manutenibilidade e reusabilidade do sistema. Aprendizagem indireta. A soluo bsica do padro Aprendizagem considera o treinamento indireto para a aquisio de conhecimento [172, 207]; no trata de treinamento direto [172, 207]. Contudo, o variante da Aprendizagem indireta pode incluir uma classe adicional TrainingExperience para tratar da aprendizagem indireta. Usos conhecidos. O framework Brainstorm [7, 8] implementa o variante de aprendizagem reflexiva. O Portalware e o Expert Committee implementaram o padro Aprendizagem. O sistema Portalware implementa uma verso simplificada do padro. Padres relacionados. O padro Aprendizagem est relacionado ao padro Kernel do Agente e ao padro Papel porque o aspecto de aprendizagem aprende com base
181
nas aes do agente e nas aes do papel. Alm disso, ele influencia as decises e os comportamentos proativos que so executados pelo padro Autonomia. O padro Aprendizagem tambm pode ser usado juntamente com o padro Adaptao, uma vez que o processo de aprendizagem pode ser disparado devido adaptao do conhecimento. O padro Aprendizagem contm a implementao orientada a aspectos do padro Observador [115]. O padro Estratgia pode ser usado para implementar diferentes estratgias de aprendizagem, conforme apresentado anteriormente [137]. O padro Faade pode ser usado para fornecer uma interface nica para as estratgias de aprendizagem, independente da tcnica usada. Finalmente, a implementao do padro Adaptao (vide a seguir) usa alguns idiomas AspectJ [114], como Template Advice, Composite Pointcut e Advice Method.
5.10 Questes de implementao e implantao Os padres de projeto orientado a aspectos foram usados na implementao dos sistemas EC e Portalware. A implementao do EC baseou-se na verso 1.3 da linguagem AspectJ. A implementao do Portalware baseou-se na verso 0.8 (Seo 4.5). Alm disso, os padres de agncia foram naturalmente incorporados na implementao de um sistema de gerenciamento de trfego (Seo 7.1). Ela tambm usou o framework JADE [20] e uma arquitetura blackboard [155] para oferecer suporte comunicao entre agentes. A integrao dos padres propostos com essas infra-estruturas ocorreu de forma direta. O Apndice I apresenta em detalhes as questes de implementao e uma amostra de cdigo. Os aspectos Adaptation e Autonomy possuem pointcuts definidos para o mesmo join point: as execues do mtodo receiveMsg(). O construto de AspectJ declare
precedence
foi usado para especificar a ordem de execuo entre esses aspectos
(Apndice I). Quanto ao concern de interao, havia vrios join points nos quais as mensagens deveriam ser enviadas para outros agentes. Esses join points incluam mtodos em classes do plano e aspectos de papis. A declarao de todos os mtodos no pointcut outgoingMsg leva muito tempo. A fim de facilitar a especificao de
182
pointcuts, esses mtodos foram nomeados com o prefixo prepare. A definio dos pointcuts usou um simples wildcard prepare* para capturar todos esses mtodos. A traduo dos padres do projeto orientado a aspectos para o cdigo AspectJ quase direta, uma vez que sua representao baseia-se amplamente na terminologia POA. Entretanto, os padres tambm podem ser implementados usando outros frameworks orientados a aspectos, como AspectWerkz e JBoss. Apesar de esses frameworks oferecerem suporte ao processo de combinao dinmico, eles incorporam construtos similares linguagem AspectJ. Hyper/J possui alguns construtos diferentes e no possui a dicotomia base-aspecto (Seo 2.2.2). No entanto, a Seo 7.3 mostra que os padres propostos tambm podem ser implementados em Hyper/J usando um conjunto de heursticas.
5.11 Discusso e trabalhos relacionados No fcil entender as relaes entre agentes e objetos a partir do ponto de vista da engenharia de software. Como conseqncia, difcil promover a separao dos concerns do agente com base no paradigma de objetos. Embora haja ligaes inegveis entre agentes e objetos (Captulo 3), poucos trabalhos de pesquisa na comunidade de padres tentaram esclarecer essas relaes. Apesar de alguns padres isolados j terem sido propostos para agentes de software [10, 117, 250], eles so em boa parte de alto nvel e no tratam da separao de concerns de agncia nos nveis de implementao e projeto. Eles negligenciaram os desafios associados interao entre propriedades do agente e as abstraes orientadas a objetos. Nossa linguagem de padres um dos primeiros esforos nessa direo uma vez que: (i) demonstra como os padres orientados a objetos no conseguem tratar da separao de concerns do agente e (ii) orienta a engenharia de software ao adicionar as propriedades de agncia aos objetos de forma elegante e com base em abstraes orientadas a aspectos. Kendall et al [137] propem algumas solues orientadas a objetos para o projeto e a implementao dos concerns do agente com base em padres de projeto conhecidos. Este captulo ilustra muitos padres de Kendall e os problemas associados. Em geral, as solues orientadas a objetos no oferecem
183
suporte separao de concerns, aumentam a esquizofrenia do agente e incorporam a replicao do cdigo. Kendall [136] descreve a aplicao da programao orientada a aspectos para implementar modelos de papis. Essa abordagem usada para representar os diferentes papis que um agente pode exercer durante seu ciclo de vida. De fato, o padro Papel apresentado neste captulo segue algumas de suas diretrizes [136]. Entretanto, a soluo de Kendall requer que os clientes do agente conheam os aspectos de papis; aumentando, ento, o acoplamento do sistema. Ademais, seu trabalho no trata das relaes entre papis e outras propriedades do agente, que so a principal origem da complexidade do agente. Nesse sentido, esse captulo apresenta uma linguagem de padres unificadora para tratar de papis e de outros concerns do agente e seus inter-relacionamentos.
A linguagem de padres apresenta um padro de projeto para a estruturao de papis, mas a linguagem no incorpora um padro para o concern de colaborao. porque h alguns protocolos de colaborao que requerem padres de projeto individuais para cada protocolo. Dessa forma, o concern de colaborao requer uma linguagem de padres adicional. De fato, h alguns padres para determinadas estratgias de coordenao e colaborao [117, 154]. Conforme mencionado anteriormente, o padro Papel proposto pode ser usado juntamente com esses padres existentes.
5.11.1 Vantagens e desvantagens O uso de abstraes orientadas a objetos para o projeto do agente normalmente leva a problemas de crosscutting concerns e replicao de cdigo (Seo 3.6). Os padres propostos apresentam solues orientadas a aspectos de forma que determinados concerns do agente entrelaados em projeto orientado a objetos possam ser desentrelaados. Os padres melhoram a modularidade do sistema uma vez que os aspectos localizam toda a definio dos concerns do agente. A melhora vem primariamente da modularizao da implementao do protocolo associada s propriedades do agente. Por exemplo, o padro Adaptao
184
encapsula o protocolo de adaptao, e o padro Aprendizagem captura o protocolo de aprendizagem. Isso se reflete diretamente no fato de a implementao do protocolo ser textualmente localizada nos aspectos abstratos. Para conseguir isso, preciso remover as dependncias no nvel do cdigo das classes participantes para a implementao dos protocolos nos aspectos. Essa separao de concerns permite que as aplicaes especficas reutilizem o comportamento comum associado s propriedades do agente. Esse comportamento comum fornecido pelos aspectos abstratos. Os desenvolvedores podem se concentrar na funcionalidade dependente da aplicao. Os aspectos abstratos implementam os comportamentos comuns, e os aspectos concretos especializam esses comportamentos para os tipos de agente e papis. Alm disso, apesar de os padres orientados a aspectos serem apresentados como parte de uma linguagem de padres
unificadora, cada um dos padres pode ser usado individualmente em aplicaes de SMAs. A transparncia uma propriedade essencial dos aspectos (Seo 2.2.2), que pode ser usada como uma medida informal que indica a utilidade de sistemas orientados a aspectos. A propriedade da transparncia melhora a separao dos concerns no desenvolvimento de softwares e simplifica a anlise, o projeto e a implementao das classes. Sistemas POA melhores devem ter maior transparncia [67]; no entanto, a transparncia total um objetivo difcil de se alcanar, conforme discutido na prxima seo.
5.11.2 Lies aprendidas Esta seo descreve algumas lies aprendidas a partir da experincia do uso dos padres de projeto para o desenvolvimento do Portalware (Seo 4.1) e Expert Committee (Seo 5.1).
Exposio de Join Points
muito provvel que vrias propriedades do agente em um SMA no tenham sido desenvolvidas desde o incio como aspectos, conforme descrito nos padres de
185
projeto. Em vez disso, muitos crosscutting concerns surgiro medida que um SMA evolui. Um framework de avaliao pode ajudar na deteco de crosscutting concerns (Captulo 6). Capturar esses concerns como aspectos, s vezes, requer a reestruturao das classes e dos mtodos para expor os join points adequados. Por exemplo, extramos o cdigo dos mtodos existentes de uma classe de plano para um novo mtodo para expor um join point no nvel do mtodo de forma que o aspecto de papis possa intercept-lo. Nesses casos, a transparncia do aspecto no total. A
Intimidade definida como um esforo adicional necessrio para preparar as classes e os mtodos para a incorporao de aspectos ao sistema [71]. As ferramentas para ajudar a refatorao facilitariam a introduo de aspectos em um sistema existente.
Gerenciamento da complexidade do aspecto
Na implementao dos padres, o autor observou que mais fcil construir um sistema orientado a aspectos quando a interface entre aspectos e classes estreita e unidirecional. Unidirecional significa que o cdigo do aspecto se refere s classes, mas no vice-versa. De fato, no centro dos padres propostos est a noo da estruturao de crosscutting concerns separadamente dos concerns do agente primrios, usando aspectos que no podem ser referenciados de volta pelos objetos. Estreito significa que o cdigo do aspecto possui um efeito bem definido em pontos particulares nesse cdigo. Lippert e Lopes fizeram observaes similares com base em um estudo feito usando AspectJ para capturar os construtos de tratamento de exceo [161].
Aspectos como Conectores entre hierarquias de classes
Muitos padres de projeto possuem uma estrutura comum: o cdigo do aspecto forma a conexo entre duas estruturas orientadas a objetos. Por exemplo, os aspectos Learning so uma conexo entre a hierarquia de tipos de agente e a hierarquia de estratgias de aprendizagem. A estrutura de projeto benfica porque permite expressar a funcionalidade bsica do agente na prpria estrutura do objeto e usar um aspecto para injetar essa propriedade do agente na funcionalidade bsica de forma transparente. Esse estilo deve ser melhor investigado como uma diretriz POA geral para tratar de outros crosscutting concerns.
186
Gerao de cdigo
A implementao dos padres de projeto envolve algumas tarefas que demandam muito tempo na definio dos aspectos do agente, como uma descrio extensiva de pointcuts. Devem ser desenvolvidas ferramentas para maximizar a gerao automtica de pointcuts e realizar essas tarefas trabalhosas. Estamos desenvolvendo uma abordagem gerativa [55] que oferece suporte gerao de cdigo dos padres propostos [147]. O mtodo arquitetural proposto e a linguagem de padres proposta tm o suporte de diversas ferramentas e assistentes que automatizam a gerao de cdigo em AspectJ.
5.12 Resumo
Como as propriedades do agente esto sendo usadas hoje em dia em diferentes aplicaes de software, os requisitos das aplicaes baseadas em SMAs variam significativamente. Portanto, importante que o projetista da aplicao configure as propriedades do agente para se ajustar s necessidades da mesma. Este captulo apresentou uma linguagem orientada a aspectos para padres de projeto orientado a aspectos que desacoplam propriedades de agncia da funcionalidade de agente bsica. As solues orientadas a aspectos minimizam a esquizofrenia do agente, reduzem a replicao de cdigo, aumentam a modularidade e a extensibilidade, e melhoram a reutilizao dos componentes do agente. Os padres de projeto apresentados neste captulo refinam os componentes da arquitetura do agente orientado a aspectos (Seo 4.3.2), fornecendo solues de projeto detalhadas. Esses padres seguem a estrutura geral da arquitetura orientada a aspecto e as diretrizes do mtodo arquitetural (Captulo 4). Os concerns identificados e modularizados no nvel arquitetural so mapeados no nvel de projeto detalhado usando abstraes orientadas a aspectos. Dessa forma, a separao alcanada no nvel arquitetural preservada no projeto detalhado.

04 Cap 05

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

04 Cap 05

Hochgeladen von

Copyright:

Verfügbare Formate

97

Learning Information Gathering Learning Knowledge

Knowledge Updating Message Sending Kernel

PUC-Rio - Certificao Digital N 0016030/CA

Extrinsic Collaboration Knowledge Protocol

Execution Autonomy Collaboration

crosscutting interface normal interface

Figura 37. A arquitetura orientada a aspectos dos agentes do EC.

para a segregao de concerns do agente.

absent knowledge new message agent creation collaboration joining

Figura 38. A estrutura da linguagem de padres.

new goal new message absent knowledge new event

PUC-Rio - Certificao Digital N 0016030/CA

new message agent creation

absent knowledge new event collaboration joining

(a) O padro Interao Figura 39. Vrios padres crosscutting.

(a) O padro Autonomia

representa um agente e o identifica de forma nica no SMA. Os mtodos

preConditions() posConditions() execute() stop()

Goal name subgoals ...

Figura 40. A viso esttica do padro Kernel do Agente.

PUC-Rio - Certificao Digital N 0016030/CA

belief1 belief2 ... action1() action2() ...

AspectN Aspect2 Aspect1

Figura 41. Definio dos tipos de agente.

PUC-Rio - Certificao Digital N 0016030/CA

public void actionN(...) { ... agent.sendMsg(); ... }

timeSlots addAppointment() addMeeting() notifyAgent()

Legend: underlined - interaction concern

Figura 42. O projeto orientado a objetos do concern de interao.

PUC-Rio - Certificao Digital N 0016030/CA

public void sense(...) { ... InitialInterface i; i.getUserAnswer(); ... }

Figura 43. Comportamento deteco nos agentes do EC.

PUC-Rio - Certificao Digital N 0016030/CA

getNext() object_Id sense() getUserAnswer(belief_Id) new_Value return

Figura 44. A viso dinmica do padro Adaptador.

PUC-Rio - Certificao Digital N 0016030/CA

Agent Plan Aspect

Figura 45. A viso esttica do padro Interao.

Message Sending Reviewer CVUpdatePlan Mobility

Sensory sensing_() PersistentCV updateInterest() Agenda

DSInterface updateAgenda() GUIoperation()

Figura 46. O padro de interao para o agente de usurio do EC.

writeMsg() sense() incomingMsg_() updateInbox() receiveMsg()

Figura 47a. Padro Interao: recebendo uma mensagem.

:Judgment Plan execute() judgeProposal() prepareResponse()

outgoingMsg_() updateOutbox() sendMsg() send() writeMsg() sense()

Figura 47b. Padro Interao: enviando uma mensagem.

updateAgenda() sensing_() senseMsg() updateInbox() receiveMsg()

Figura 48. Padro interao: detectando um evento externo.

Goal Creation Agent Belief Aspect Execution Autonomy newAgent_() events_()

PUC-Rio - Certificao Digital N 0016030/CA

Figura 49. A viso esttica do padro Autonomia.

PUC-Rio - Certificao Digital N 0016030/CA

Goal Creation Reviewer receiveMsg() Agenda ...

JudgementPlan executePlan() LeavingPlan ... executePlan() ...

Figura 50. O padro Autonomia do papel de Revisor.

definido um novo objetivo.

PUC-Rio - Certificao Digital N 0016030/CA

:Decision :Decision :Judgement Plan Plan Plan decision plans

newAgent_() receiveMsg(Msg) events_(Msg) makeDecision(Msg) initThread()

instantiateGoal(decisionGoal) executePlan(decisionGoal) setGoal(reactiveGoal) instantiateGoal(reactiveGoal)

Figura 51. Padro Autonomia: tornando um agente autnomo.