Validity and ethical considerations

Antes de descrever o modelo conceitual da arquitetura desenvolvida, é preciso dar uma idéia geral das estruturas e mecanismos por ela utilizados. A Figura 3.4 ilustra as principais estruturas definidas na arquitetura K2. Para que os agentes tivessem ciência do contexto no qual estão inseridos, foi necessário fornecer uma infra-estrutura para o gerenciamento das informações contextuais. Na arquitetura definida, três estruturas são responsáveis pela coleta, processamento e distribuição das informações contextuais, conforme descrito a seguir.

Tabela 3.5 – Tipos de eventos internos que podem ocorrer na arquitetura de um agente adaptativo ao contexto.

Tipo de Evento Primitiva Relacionada (com variações) Momento de criação Descrição

add add (BaseStructure, Structure) _{add (BaseStructure, Structure, Parameters)} Ao término da operação de adição Indica que uma nova estrutura foi adicionada a uma estrutura _base. remove remove (BaseStructure, Structure) Ao término da operação de remoção Indica que uma estrutura foi removida de uma estrutura base. update update (BaseStructure, AttributeType, Value) Ao término da operação de _{atualização} Indica que um atributo de uma estrutura base foi atualizado. changeFlow changeFlow(Plan, Action, NextAction) Ao término da operação de mudança _{de fluxo} Indica que o fluxo de ações de um plano foi alterado. executionStart execute (BaseStructure, Structure)

execute (BaseStructure, Structure, Parameters) No início da operação de execução Indica que uma estrutura começou a ser executada. executionEnd execute (BaseStructure, Structure)

execute (BaseStructure, Structure, Parameters) Ao término da operação de execução Indica que terminou a execução de uma estrutura que estava sendo executada. abort abort (BaseStructure, Structure) Ao término da operação de _cancelamento Indica que uma estrutura teve sua execução cancelada. interrupt interrupt (BaseStructure, Structure) Ao término da operação de _{interrupção} Indica que uma estrutura teve sua execução interrompida. resume resume (BaseStructure, Structure) Ao término da operação de reinicio Indica que uma estrutura teve sua execução reiniciada. commitTo commitTo (BaseStructure, Structure) Ao término da operação de _{comprometimento} Indica que o agente começou a desempenhar um papel ou _{está em busca de um objetivo.} block block (BaseStructure, BlockType, Parameter) Ao término da operação de _bloqueamento Indica que um mecanismo do agente foi bloqueado.

unblock unblock (BaseStructure, BlockType) Ao término da operação de _{desbloqueamento} Indica que um mecanismo do agente foi desbloqueado. sendMessage sendMessage (Sender, Recipients, _{MessageSchema, Parameters)} Ao término da operação de envio de _mensagens Indica que uma mensagem foi enviada.

replace replace (BaseStructure, Structure, NewStructure) Ao término da operação de _{substituição} Indica que uma estrutura da estrutura base foi substituída por _{outra estrutura.} goalAchieved *commitTo (Agent, Goal) Ao término do alcance do objetivo Indica que o agente alcançou um objetivo.

contextUpdate *add (Agent, Belief) Ao término da operação de adição de _contexto Indica que houve uma atualização em alguma das _{informações contextuais do contexto corrente do agente.} adaptationDone - Ao término da execução de uma _adaptação Indica que foi realizada uma adaptação no agente.

Os monitores de informações contextuais são responsáveis por capturar informações contextuais de diferentes fontes de informação (tanto de hardware quanto de software). Como exemplos de informações contextuais citam-se: a temperatura de uma sala, a posição de uma pessoa, a variação do câmbio do dólar, entre outros. Há um monitor associado a cada fonte de informação contextual. As variações no contexto percebidas pelos monitores são sinalizadas ao gerente de contexto.

Os gerentes de contexto centralizam o recebimento das atualizações no contexto e as redirecionam para os interpretadores de contexto, que são responsáveis por interpretar os dados coletados a partir dos monitores (o que geralmente resulta em informações em um nível mais alto de abstração). Os gerentes de contexto também são responsáveis pela manutenção da ontologia de contexto da aplicação. Na ontologia, todas as informações contextuais disponibilizadas por determinado gerente de contexto são descritas. Uma aplicação composta por agentes adaptativos ao contexto deve ter ao menos um gerente de contexto, que pode estar vinculado a vários monitores e interpretadores. As informações interpretadas são utilizadas pelos gerentes de contexto para construir o contexto atual de um agente adaptativo ao contexto. É esse agente quem possui um contexto e é alvo de adaptações.

Todas as ações realizadas por/em um agente adaptativo ao contexto são registradas na forma de eventos internos. Observe, na Figura 3.4, que há um repositório de eventos internos na arquitetura do agente adaptativo. Como exemplos de eventos internos citam-se: a adição de uma nova crença, a remoção de um objetivo, a inicialização ou a finalização da execução de um plano, a atualização das pré-condições de uma ação, o comprometimento com o alcance de um objetivo, entre outros. Com os eventos internos, os agentes passam a ter consciência deles próprios (em termos de suas estruturas e comportamentos ativos). Em [Kle08] é dito que consciência é um pré-requisito para a adaptação automática de sistemas e, para se adaptar, um sistema precisa ter consciência de si próprio (autoconsciência) e consciência do ambiente em que está inserido.

Os adaptadores são os elementos responsáveis por observar o histórico de eventos do agente e, quando apropriado, realizar adaptações em sua arquitetura. Os adaptadores são constituídos, basicamente, por um ponto de adaptação e por uma variante. O ponto de adaptação é composto por uma série de eventos que, quando gerados, iniciam o processo de adaptação na arquitetura do agente. Já a variante contém todas as instruções para a realização da adaptação (ela é formada por uma seqüência de primitivas). Os agentes adaptativos ao contexto possuem um repositório de adaptadores.

Figura 3.4 – Visão geral das principais estruturas da arquitetura K2.

O repositório de adaptadores de um agente pode ser expandido durante a sua execução de maneira manual ou automática (baseada em aprendizado multiagentes). A expansão de maneira manual requer a interação com usuários ou desenvolvedores para o cadastramento de novos adaptadores em tempo de execução. Já para expandir o repositório de adaptadores de maneira automática, foram definidos alguns mecanismos que permitem a busca e o compartilhamento de adaptadores entre os agentes.

O mecanismo de aquisição de adaptadores pode ser inicializado por dois motivos: (i) para substituir adaptadores obsoletos ou insuficientes (com base em avaliações de desempenho do agente); ou (ii) para buscar adaptadores para atingir um objetivo de forma mais satisfatória em determinado contexto. Na verdade, em ambos os casos o agente precisa procurar por novos adaptadores para melhor atingir os seus objetivos. A Figura 3.5 apresenta, de forma esquemática, alguns aspectos da execução do mecanismo citado. Como pode ser observado na figura, dentro do mecanismo de aquisição de adaptadores são executadas duas atividades. Inicialmente, as informações sobre a necessidade de adaptadores são encaminhadas à atividade “capturar”, que então as encapsula em uma mensagem para envio aos outros agentes adaptativos ao contexto do sistema. Depois de certo tempo, são verificadas as respostas recebidas para a solicitação, a fim de identificar os adaptadores compartilhados pelos outros agentes. Tal

verificação é feita na atividade “aplicar”. Depois de selecionado e aplicado um adaptador, esse é armazenado no repositório de adaptadores do agente.

Quando um agente adaptativo ao contexto envia uma solicitação de adaptadores, todos os agentes que recebem tal solicitação verificam seus repositórios em busca de adaptadores compatíveis com a necessidade descrita. Se existir algum adaptador compatível, é feito seu envio ao agente solicitante. A verificação dos adaptadores compatíveis e seu envio são tarefas realizadas pelo mecanismo de distribuição de adaptadores, cujo funcionamento é ilustrado na Figura 3.6. Conforme indicado na figura, sempre que é recebida uma mensagem de solicitação de adaptadores, é iniciada a execução da atividade “distribuir”. Se forem encontrados adaptadores compatíveis (como é o caso do cenário ilustrado), é enviada uma mensagem de “entrega” de adaptadores ao agente solicitante.

Figura 3.5 – Modelo esquemático do processo de aquisição de novos adaptadores. Por fim, um agente adaptativo ao contexto é capaz de avaliar o seu próprio desempenho (avaliar os resultados atingidos depois do alcance de um objetivo). Assim, ele pode identificar quando os adaptadores disponíveis não estão contribuindo para o

alcance de bons resultados, adquirindo novos adaptadores para a sua substituição. Esta estratégia é baseada no comportamento humano: quando não estamos obtendo bons resultados trabalhando de uma determinada maneira, buscamos melhorar ou mudar nossa maneira de trabalhar a fim de alcançar melhores resultados.

Figura 3.6 – Modelo esquemático do processo de distribuição de adaptadores.