Definição dos locais passíveis de adaptação

No modelo proposto, um agente pode iniciar seu processo de adaptação quando for executada qualquer uma das primitivas definidas. Assim, pode-se iniciar uma adaptação quando um novo plano é adicionado a um objetivo, quando o agente se compromete a alcançar um objetivo ou a desempenhar um novo papel, quando uma crença é adicionada ou atualizada no estado mental do agente, entre outros. Deste modo, além das informações contextuais (que também são partes constituintes das crenças do agente) pode-se utilizar qualquer outra informação relacionada à estrutura ou à execução do agente para ativar o seu processo de adaptação.

Para indicar a execução ou chamada de uma primitiva, foi definido o conceito de evento interno no metamodelo FAML (o metamodelo não previa o gerenciamento de

eventos internos ao agente, apenas eventos externos). Cada execução de primitiva resulta na criação de um evento interno, sendo que foi definido um tipo de evento interno para cada primitiva. São esses eventos que disparam o processo de adaptação do agente. Os eventos, além de um tipo, trazem consigo outras informações, como as estruturas alteradas ou adicionadas.

Por padrão, os eventos internos são gerados ao final da execução de uma primitiva. Assim, quando o evento é gerado, o efeito da primitiva já pôde ser percebido no agente. Quando a execução das primitivas é praticamente instantânea, como nos casos das primitivas estruturais e algumas comportamentais, o tempo discorrido entre a execução da primitiva e a geração do evento é desprezível. Porém, há casos onde é necessário indicar o início e o término de uma execução.

As primitivas execute e commitTo são os principais casos a serem considerados devido ao tempo em que podem permanecer em execução na arquitetura de um agente. Nestes dois casos não bastaria gerar um evento ao final da execução ou comprometimento com o alcance de algo: é preciso saber também quando o agente começou a executar o plano/ação ou a desempenhar o papel. Para resolver esse problema, foram criados três novos tipos de eventos internos: executionStart, executionEnd e goalAchieved.

Quando é executada a primitiva execute (qualquer uma das variações), um evento do tipo executionStart é criado. Esse evento permanece ativo até que um evento do tipo executionEnd seja gerado para indicar o término da execução do plano ou ação. O evento executionEnd armazena, além da estrutura base, da estrutura e dos parâmetros utilizados (quando aplicável), o resultado obtido na execução (se satisfatória ou não). Com a criação dos eventos executionStart e executionEnd pode-se indicar que determinada adaptação deve ser realizada enquanto algo estiver sendo executado ao apenas ao fim da execução. Devido a esses dois tipos de eventos, não são criados eventos do tipo execute no modelo proposto.

O evento goalAchieved foi definido especialmente para indicar o alcance de um objetivo. Quando um agente indica que deseja alcançar um objetivo, é criado um evento do tipo commitTo (conforme primitiva genérica definida) e quando ele enfim o alcança é gerado um evento do tipo goalAchieved. O evento goalAchieved também registra o grau de satisfação atingido durante o alcance do objetivo. Eventos do tipo goalAchieved não são gerados quando a primitiva commitTo é utilizada para indicar

que um agente passou a desempenhar um papel (a saber “commitTo (Agent, Role)”), porque um agente não “atinge” um papel, apenas o desempenha ou deixa de desempenhar. Para indicar que um agente deixou de desempenhar um papel, são gerados eventos do tipo abort.

Além dos eventos criados para sinalizar o início e o término de determinadas operações, outros dois tipos de eventos relacionados exclusivamente a agentes adaptativos ao contexto foram definidos. São eles: o contextUpdate e o adaptationDone.

O evento contextUpdate foi definido para auxiliar na especificação do contexto relevante para determinada adaptação. Embora as informações do contexto corrente do agente fiquem armazenadas juntamente com suas crenças (cujas alterações são indicadas por eventos do tipo add), considerou-se pertinente definir um novo tipo de evento para evidenciar aspectos relacionados ao contexto. Assim, há uma clara distinção entre as informações de contexto e as informações regulares utilizadas para a tomada de decisão nos planos e ações. O evento adaptationDone foi definido para sinalizar quando um agente é alvo de adaptações. Esse evento armazena informações sobre o agente que sofreu adaptação e também sobre a estrutura que foi ativada para a realização da adaptação (como será debatido na próxima seção, a estrutura ao qual o evento se refere é chamada de adaptador).

A Tabela 3.5 sumariza os tipos de eventos definidos no modelo e as informações armazenadas por cada um deles (os tipos de eventos que não tem mapeamento direto com as primitivas genéricas definidas estão com preenchimento). Abaixo, há alguns exemplos de eventos internos considerando-se o agente de nome SellerAgent e a utilização das primitivas citadas ao longo do texto.

(a) add (Agent: SellerAgent, Goal: SellBookGoal)

(b) executionStart (Goal: SellBookGoal, Plan: SellBookPlan)

(c) goalAchieved (Agent: SellerAgent, Goal: SellBookGoal, “Good”) (d) contextUpdate(Interpreter:Sales, =, “growing up”)

(e) adaptationDone (Agent: SellerAgent, Adaptor: SalesContextAdaptor) (f) remove (Agent: SellerAgent, Goal: SellBookGoal)

O exemplo (a) apresenta o evento que é gerado quando executada a primitiva add. No exemplo, é adicionado o objetivo SellBookGoal ao agente SellerAgent. Já o

exemplo (b) mostra o evento gerado ao início da execução de um plano (no exemplo, é iniciada a execução do plano SellBookPlan no contexto do objetivo SellBookGoal). O exemplo (c) apresenta o evento gerado quando um agente alcança um objetivo (no terceiro elemento da n-tupla está o grau de satisfação atingido). Os exemplos (d) e (e) mostram a utilização dos eventos definidos exclusivamente para agentes adaptativos ao contexto. O exemplo (d) indica que, em determinado momento, o interpretador de nome Sales possui como valor a string “growing up”. Já o evento (e), indica que o agente SellerAgent sofreu adaptação quando o adaptador de identificação SalesContextAdaptor foi ativado. Por fim, o evento (f) mostra a remoção de um objetivo do estado mental de um agente. Em todos os exemplos, foi omitido o valor do timestamp.

Por fim, cabe salientar que os eventos internos não são nem consumidos nem descartados depois do uso, ao invés disto, são armazenados em uma estrutura chamada AgentHistory. Na verdade, os eventos internos ficam ativos durante determinado tempo (tempo de vida) e, depois de transcorrido esse tempo, são considerados eventos “antigos”, e então passam a fazer parte do histórico de eventos do agente. Os eventos do tipo contextUpdate, executionStart e commitTo são uma exceção a essa regra, uma vez que permanecem ativos até que, respectivamente, o contexto seja alterado, a execução de um plano ou ação seja finalizada ou o agente alcance um objetivo (ou deixe de desempenhar um papel). Com o armazenamento do histórico de eventos é possível tentar prever situações no futuro ou até mesmo modificar o mecanismo de adaptação, tornando-o mais preciso. Considera-se que o próprio agente terá um mecanismo para gerenciar os eventos internos e que esse mecanismo (bem como os próprios eventos internos) não será alvo de adaptação.