• Nenhum resultado encontrado

3 An´alise e depurac¸˜ao de SMA

3.3 Trabalhos existentes na depurac¸˜ao de SMA

3.3.2 Depurac¸˜ao de SMA baseada em modelo conceitual

Liedekerke e Avouris (Liedekerke & Avouris 2005) apresentam uma t´ecnica para depurac¸˜ao de SMA fundamentada no modelo conceitual do desenvolvedor (MCD), que ´e um caso es- pec´ıfico do termo modelo conceitual do usu´ario (MCU), introduzido em (Moran 1981). O objetivo ´e que o MCU contenha informac¸˜oes sobre o comportamento do sistema do ponto de vista do usu´ario. Esse modelo deve ser utilizado como guia para o desenvolvimento da interface do sistema. De forma an´aloga, os modelos conceituais do desenvolvedor guiam a especificac¸˜ao e implementac¸˜ao das vis˜oes que o desenvolvedor pode obter da ferramenta de depurac¸˜ao. Os poss´ıveis modelos conceituais propostos em (Liedekerke & Avouris 2005) s˜ao descritos a se- guir.

Modelo do dom´ınio: gerencia as propriedades dos problemas, bem como o dom´ınio corres-

pondente a cada um deles. Esse modelo pode ser ´util na execuc¸˜ao de testes e identificac¸˜ao de erros nas implementac¸˜oes dos agentes. Por exemplo, alterar as propriedades de um pro- blema e solicitar aos agentes que tentem resolvˆe-lo ´e uma boa estrat´egia para encontrar erros de implementac¸˜ao;

Modelo do agente: pode assumir a forma estrutural ou comportamental. A estrutural descreve

os componentes que constituem os agentes, e a comportamental enfoca o comportamento dos agentes;

Modelo de distribuic¸˜ao: mostra como as tarefas, recursos, conhecimento e dados s˜ao compar-

tilhados entre os agentes;

Modelo de interac¸˜ao: exibe o fluxo de mensagem entre agentes ou grupo de agentes. As men-

sagens podem ser caracterizadas pelo seu tipo, data e hora de envio, conte´udo, etc.

Modelo de resoluc¸˜ao: concentra-se na resoluc¸˜ao coletiva de problemas. Destaca como um

grupo de agentes conseguiu resolver um problema, ou, em caso de falha, por qual raz˜ao eles n˜ao conseguiram resolver;

Modelo de habilidades e conhecimento: identifica o que os agentes sabem sobre eles mesmos

e sobre suas capacidades em resolver problemas.

Diante dos modelos descritos, algumas vis˜oes do sistema s˜ao definidas e implementadas na ferramenta de depurac¸˜ao. Estas vis˜oes s˜ao descritas abaixo. A Figura 3.12 mostra a relac¸˜ao entre os modelos e as vis˜oes que os materializam.

Vis˜ao do agente: apresenta as informac¸˜oes a respeito de um agente em diversos n´ıveis. O

n´ıvel mais alto mostra o agente como uma caixa-preta capaz de resolver problemas e executar v´arias tarefas. Esse n´ıvel corresponde ao modelo comportamental do agente. N´ıveis mais detalhados se aproximam do modelo estrutural. Por exemplo, um segundo n´ıvel de abstrac¸˜ao mostraria os componentes do agente, que poderiam ser: gerenciador de comunicac¸˜ao (respons´avel por enviar e receber mensagens), controlador de tarefas (aceita ou n˜ao solicitac¸˜ao de resoluc¸˜ao de tarefas) e resolvedor de tarefa (executa as tarefas). Num terceiro n´ıvel seria poss´ıvel ver internamente cada um desses componentes, e assim sucessivamente. Essa vis˜ao concretiza os modelos do agente, habilidades e conhecimento, e da arquitetura;

Vis˜ao de interac¸˜ao: o objetivo dessa vis˜ao ´e permitir a verificac¸˜ao de tipo e conte´udo das men-

sagens trocadas, bem como a vaz˜ao de mensagens dos agentes (quantas mensagens saem e quantas entram). Essa vis˜ao pode mostrar um gr´afico onde no eixo X est˜ao dispostos os agentes, e no eixo Y a vaz˜ao de mensagens, assim o desenvolvedor pode ter uma id´eia de quanto os agentes se comunicam. Essa vis˜ao concretiza o modelo de interac¸˜ao;

Vis˜ao de cooperac¸˜ao: essa vis˜ao representa as dependˆencias est´aticas e dinˆamicas entre os

agentes. Uma dependˆencia est´atica ´e caracterizada pela relac¸˜ao potencial entre os agentes, por exemplo, um agente A precisa resolver tarefas que outros agentes sabem e podem ajud´a-lo a resolver. No momento em que A consegue que um deles lhe ajude, fica ent˜ao estabelecida uma relac¸˜ao dinˆamica, que dura at´e que a tarefa seja resolvida. Um exemplo de visualizac¸˜ao para essas relac¸˜oes ´e representar os agentes como grafos, as relac¸˜oes est´aticas como arestas tracejadas, e as relac¸˜oes dinˆamicas como arestas cont´ınuas. Essa vis˜ao concretiza o modelo de distribuic¸˜ao;

Vis˜ao de tarefas do dom´ınio: a resoluc¸˜ao de problemas de um dom´ınio pode ser vista atrav´es

de uma decomposic¸˜ao hier´arquica de tarefas que precisam ser executadas para que a soluc¸˜ao seja alcanc¸ada. Atrav´es dessa vis˜ao os problemas podem ser gerenciados, sendo poss´ıvel, por exemplo, alterar suas propriedades. Al´em disso, essa vis˜ao permite ver o processo de cooperac¸˜ao para resoluc¸˜ao de tarefas, analisar a performance coletiva dos agentes, e caso um agente falhe, ´e poss´ıvel identificar a influˆencia dessa falha no processo geral. Essa vis˜ao concretiza os modelos do dom´ınio e de resoluc¸˜ao.

A implementac¸˜ao das vis˜oes ´e feita atrav´es da inserc¸˜ao de um agente no SMA, o agente do desenvolvedor (AD). Ele recebe os fluxos de informac¸˜oes de teste e depurac¸˜ao dos demais

Figura 3.12: Relac¸˜ao entre modelos e vis˜oes (adaptado de (Liedekerke & Avouris 2005)) agentes da sociedade e os interpreta de acordo com a vis˜ao selecionada pelo desenvolvedor. Uma vis˜ao geral da arquitetura do SMA resultante ´e apresentada na Figura 3.13. Note que a arquitetura resultante ´e inspirada na id´eia proposta em (Joyce et al. 1987) de separar detecc¸˜ao e coleta da informac¸˜ao da an´alise e visualizac¸˜ao.

Figura 3.13: Arquitetura do SMA com a inserc¸˜ao do AD (adaptado de (Liedekerke & Avouris 2005))

O problema no trabalho de Liedekerke e Avouris ´e que ele n˜ao descreve como o processo de coleta pode ser implementado. As vis˜oes s˜ao fundamentais para que o desenvolvedor possa compreender o funcionamento do SMA. Contudo, provavelmente o processo de coleta ´e o mais complicado de se implementar porque ´e necess´ario inserir no agente alguns mecanismos para capturar informac¸˜oes. Onde e como esses mecanismos ser˜ao inseridos ´e uma decis˜ao importante que depende de ponderac¸˜ao a respeito de alguns fatores, como por exemplo, a arquitetura do agente, linguagem utilizada para implementac¸˜ao, etc. O fato dessa tarefa n˜ao ser realizada adequadamente pode acarretar alguns efeitos colaterais, como por exemplo, o processo de coleta pode tornar o agente muito lento, e num ambiente de cooperac¸˜ao essa perda de performance

pode afetar o cen´ario de depurac¸˜ao do SMA.