Sistema Multiagentes de Recomendação de Eventos

Transcrição

1 Universidade Federal do Espírito Santo Inteligência Artificial Sistema Multiagentes de Recomendação de Eventos Grupo: André Gustavo Almeida Bernardo Gonçalves Marcel Damásio Rodolfo Gabri Vitória 2007/02

2 Sistema Multiagentes de Recomendação de Eventos Relatório Final apresentado como requisito para a conclusão da Disciplina Inteligência Artificial, ministrada aos alunos dos cursos de Ciência e Engenharia da Computação e do Mestrado em Informática da UFES, por Prof. Dr. Giancarlo Guizzardi e Prof a. Dra. Renata Silva Souza Guizzardi. Sistemas Multiagentes Análise e Projeto usando ARKnowD

3 1 Descrição do Problema Nos dias atuais, a divulgação de eventos ainda é realizada de uma maneira que alguém poderia considerar manual. Enquanto isso, com a possibilidade da Web Semântica, agentes computacionais poderiam então automatizar tal tarefa de maneira a aumentar a eficácia do serviço de divulgação. Esse serviço poderia ser contratado por um organizador de evento, solicitando que seu evento seja recomendado para pessoas potencialmente interessadas no mesmo. Como uma tentativa de tratar o problema citado, este trabalho propõe um sistema multiagentes de recomendação de eventos que se apóia no paradigma de programação orientado a agentes. Este sistema, o Agente Recomendador de Eventos (ARE), pressupõe que os organizadores de evento mantêm um website do mesmo, e que as pessoas-alvo do sistema mantêm websites pessoais e/ou possuem perfil definido em websites de redes sociais. O sistema, assim, mantém uma base de dados atualizada com perfis de pessoas e, para cada evento a ser divulgado, seleciona na base pessoas potencialmente interessadas e recomenda o evento para as mesmas. A Figura 1 apresenta uma visão geral do sistema ARE. Figura 1 Visão geral do sistema multiagentes de recomendação de eventos. Para modelar o domínio tratado, i.e., divulgação de eventos, e modelar o sistema ARE foi utilizada a metodologia ARKnowD, que combina as linguagens Tropos e AORML. Este documento é organizado como segue: a Seção 2 apresenta os requisitos iniciais do sistema expressos na linguagem Tropos; A Seção 3, por sua vez, apresenta os requisitos finais do sistema também expressos na linguagem Tropos; na Seção 4 é introduzido o projeto arquitetural ainda na linguagem Tropos; a Seção 5 então apresenta o projeto arquitetural detalhado se aproveitando do nível mais baixo de abstração da linguagem AORML; finalmente, a Seção 6 conclui este trabalho discutindo a experiência com a abordagem ARKnowD.

4 2 Requisitos Iniciais De acordo com a metodologia de Engenharia de Software com orientação a agentes Tropos, os requisitos iniciais atingem a necessidade de se modelar o universo de discurso onde será inserido o sistema multiagentes proposto. Neste sentido, o modelo de requisitos iniciais aqui apresentado (vide Figura 2) captura as relações de dependência entre os atores básicos deste domínio, isto é, o organizador de um evento, as pessoas-alvo, e o divulgador que faz a ligação entre os dois atores anteriores. Figura 2 Requisitos iniciais. O organizador tem o objetivo de realizar o evento e o desejo de ter seu evento o mais bem divulgado possível. As pessoas, de outro lado, gostariam de receber informações a respeito de eventos de potencial interesse e, portanto, descobrir esses eventos com o mínimo de esforço. A existência ou não de tal interesse pode ser inferida através da análise do perfil da pessoa. Tal perfil deve então ser composto por atributos com boa capacidade preditiva para a inferência citada. Vale ressaltar que a relevância do sistema ARE depende da eficácia na tarefa de recomendação de eventos apenas para pessoas que realmente teria interesse no mesmo. O divulgador deve então consolidar a relação entre organizador de evento e pessoas prestando assim o serviço de divulgação. O desafio do divulgador consiste em acertar quais seriam as pessoas que poderiam se interessar no evento a ser divulgado. Uma vez atingindo essas pessoas, ele pode então atraílas para eventos divulgados. Para divulgar o evento, o divulgador depende do organizador para obter informações do evento necessárias para a divulgação. Ao prestar esse serviço, o primeiro obtém do último a remuneração definida no contrato de prestação do serviço.

5 3 Requisitos Finais A partir dos requisitos iniciais, os requisitos finais incluem o sistema multiagentes proposto no domínio tratado. Assim, o sistema ou substitui a função de um ator humano (o caso deste trabalho) ou desempenha uma função até então inexistente no domínio. Dessa forma, o modelo apresentado na Figura 3 captura a relação do sistema ARE com o mundo externo, isto é, com os atores já introduzidos na definição dos requisitos iniciais. Figura 3 Requisitos finais. O sistema ARE assume objetivos dos atores pessoa e organizador, Receber informações de eventos e Divulgar evento, respectivamente. Em contrapartida, o ARE depende desses atores para obter os recursos Website pessoal e Perfil em site de relacionamento do ator pessoa, e Url do website do evento do ator organizador. Para atingir o objetivo Divulgar evento, o sistema ARE o decompõe em três objetivos (vide Figura 3) que são atingidos pelas tarefas (i) Extrair informações do website do evento, (ii) Extrair e armazenar informações de pessoa e (iii) Selecionar perfis baseado em evento. O objetivo Receber informações de eventos, do ponto de vista do ator pessoa é atingido pelo objetivo Recomendar eventos para as pessoas do ponto de vista do sistema. Este objetivo, por sua vez, é atingido pelas tarefas Enviar recomendação por e Enviar recomendação por SMS. Por fim, o objetivo Buscar pessoas com interesses em comum

6 constitui uma funcionalidade extra associada a agentes externos ao sistema. Ele, portanto, pode ser atingido através do objetivo de Contactar outros agentes. Embora essa funcionalidade tenha sido incorporada no modelo de requisitos finais, ela não será contemplada no projeto arquitetural. 4 Projeto Arquitetural No projeto arquitetural o sistema multiagentes ARE é decomposto em atores que representam os módulos do sistema. Conforme mostrado no diagrama de dependência estratégica da Figura 4, o ARE é composto dos atores Analisador de evento, Núcleo do sistema e Recomendador de evento. Figura 4 Projeto arquitetural de dependência estratégica. No diagrama de razão estratégica mostrado na Figura 5, o ator Núcleo do sistema é então decomposto nos atores Buscador de pessoas e Sintetizador de resultados.

7 Figura 5 Projeto arquitetural de razão estratégica. Conforme mostrado na Figura 5, o diagrama de razão estratégica apresenta uma visão interna do ator sistema ARE, fornecendo assim uma intuição do seu funcionamento. Ao organizador de evento contratar o serviço do sistema ARE, o ator Analisador de evento extrai informações do website do evento mantido pelo organizador. Enquanto isso, o ator Buscador de informações de pessoas extrai e armazena informações de pessoa a partir de ambos website pessoal e perfil em site de relacionamento. Ele então atualiza uma base de dados com os perfis das pessoas. Essa tarefa é realizada de tal forma a se aproveitar dos atributos de maior potencial de predição do perfil de uma pessoa. Assim, o ator Sintetizador de resultados, a partir de informações estruturadas do evento, varre a base de dados selecionando pessoas potencialmente interessadas no evento. Ao final dessa tarefa de seleção de perfis baseado em evento, o ator Sintetizador de resultados permite que o Recomendador de eventos envie a recomendação do evento para as pessoas selecionadas. Esse objetivo é atingido pela tarefa Enviar recomendação por e/ou Enviar recomendação por SMS. 5 Projeto Detalhado

8 A metodologia ARKnowD propõe o uso da linguagem AORML para modelagem do projeto detalhado do sistema a ser desenvolvido. Foram selecionados então algumas tarefas e atores capturados nos modelos Tropos para serem refinados através do uso de AORML. A seguir são apresentados diagramas AORML de agentes, de seqüência de interações (ISD), de padrão de interações (IPD), e de quadros de interações (IFD). 5.1 Diagramas de Agentes Os diagramas de agentes aqui apresentados representam (i) a transformação automática do modelo Tropos de projeto arquitetural para um esqueleto do diagrama de agentes AORML (vide Figura 6), e (ii) o diagrama de agentes AORML já completo explorando os construtores da linguagem AORML (vide Figura 7). Figura 6 Diagrama de agentes automático.

9 Figura 7 Diagrama de agentes completo. 5.2 Diagramas de Seqüência de Interações (ISD s) Seguindo o fluxo de execução do sistema, o agente humano Administrador do ARE insere através do agente artificial Analisador de eventos a url do evento a ser divulgado. Existem duas possíveis seqüências de interações para a execução de tal tarefa. No caso normal (vide Figura 8), a url do novo evento é inserida, as informações relevantes a respeito do evento são extraídas e um arquivo xml é gerado. O evento é então enviado ao agente Sintetizador de resultados, que responde com um ack. No caso de exceção (vide Figura 9), em contraste, após tentativas frustradas de acessar o website, o Analisador de eventos solicita ao Administrador uma confirmação da url do website.

10 Figura 8 ISD Extrair informações do website do evento (caso normal). Figura 9 ISD Extrair informações do website do evento (caso exceção).

11 Ao receber a mensagem EnviarEvento do agente Analisador de eventos, o agente Sintetizador de resultados define o perfil do evento a partir do arquivo evento.xml. Tal perfil engloba informações como data e local de realização, duração, artistas envolvidos, organizador, dentre outras. O Sintetizador de resultados então acessa e varre o banco de dados de perfis de pessoas selecionando perfis de pessoas que casem com o perfil do evento. Depois de realizadas essas tarefas, o Sintetizador de resultados envia uma mensagem para o Recomendador de eventos contendo o arquivo evento.xml juntamente com um arquivo ps.xml contendo os elementos (tags) de cada pessoa selecionada para o evento. A Figura 10 apresenta o ISD para o procedimento recém descrito. Figura 10 ISD Selecionar Perfis baseado em evento. Assim que o agente Recomendador de eventos recebe a mensagem RecomEvento do agente Sintetizador de resultados, cria-se um compromisso do primeiro para o segundo, que somente será eliminado através da mensagem InfoRecoms também do primeiro agente para o segundo, contendo dados de envio dos s (e.g., data/hora do envio). Para cumprir sua função, o Recomendador de eventos cria informação html para geração de cada . Os s são então enviados por broadcast através da mensagem recompor para os servidores de das pessoas. O agente recomendador ainda verifica com os servidores de se os s foram realmente enviados 1. No caso de sucesso (vide Figura 11), o Recomendador de eventos envia a mensagem InfoRecoms, com o 1 Essa checagem não envolve a verificação se os s foram recebidos, mas apenas se foram enviados.

12 parâmetro msg=dados_dos_ s, que elimina seu compromisso com o agente Sintetizador de resultados. No caso de exceção (vide Figura 12), o agente recomendador informa o sintetizador da ocorrência de erro (InfoRecoms com msg=erro_ ) e, portanto, da impossibilidade dos s terem sido enviados. Figura 11 ISD Enviar Recomendação por (caso normal). Figura 12 ISD Enviar Recomendação por (caso exceção).

13 5.3 Diagramas de Quadros de Interações (IFD s) O diagrama de quadro de interações sintetiza todas as interações entre dois agentes. A seguir a Figura 13 e a Figura 14 apresentam os IFD s para as interações entre os agentes Analisador de eventos e Sintetizador de resultados, bem como entre este último e o agente Recomendador de eventos, respectivamente. Figura 13 IFD das interações entre Analisador de eventos e Sintetizador de resultados. Figura 14 IFD das interações entre Sintetizador de resultados e Recomendador de eventos. 5.4 Diagramas de Padrão de Interações (IPD s) O diagrama de padrão de interações modela o comportamento interno de um determinado agente, representando as regras que definem o comportamento reativo desse agente.

14 No diagrama mostrado na Figura 15 é apresentado o comportamento interno do Analisador de eventos. Ao receber a url do website do evento inserida pelo agente Administrador, o Analisador de eventos envia informações estruturadas do evento ao Sintetizador de resultados crendo na existência de tal website, mantido pelo agente Organizador. Figura 15 IPD Analisador de eventos. A Figura 16, por sua vez, exibe o IPD do agente Sintetizador de resultados. Ao receber um novo evento enviado pelo Analisador de eventos, aquele envia para o Recomendador de eventos o evento recebido e as pessoas que são potencialmente interessadas no mesmo. Figura 16 IPD Sintetizador de resultados.

15 Por fim, a Figura 17 mostra o IPD do agente Recomendador de eventos. Este agente realiza a recomendação do evento em questão para as pessoas selecionadas pelo Sintetizador de resultados. O agente de recomendação crê na existência dos objetos Mensagem de resposta do servidor e Informações do evento em html. Figura 17 IPD Recomendador de eventos.

16 6 Avaliação da Experiência 6.1 Uso da Metodologia ARKnowD (Tropos+AORML) A metodologia ARKnowD contempla as fases de análise (incluindo engenharia de requisitos) e projeto de software orientado a agentes. A inclusão de conceitos como agentes, objetivos, crenças e outros já nessas fases do desenvolvimento por certo contribui no sentido de forçar o desenvolvedor a pensar em tais conceitos. Assim, os sistemas desenvolvidos atingiriam o knowledge level proposto por Allen Newell. A experiência que vivenciamos, no entanto, ficou um pouco prejudicada por não termos tido chance de verificar/comprovar tais benefícios na fase de codificação. Talvez por conta ainda de um baixo grau de amadurecimento das linguagens utilizadas (Tropos e AORML), fica uma impressão de que há um pouco de ruído no meio de primitivas de linguagem, de fato, relevantes. As seguir são discutidas as linguagens Tropos, AORML, bem como a combinação das duas linguagens Tropos A linguagem Tropos parece 2 possuir um grau razoável de ambigüidade. Seja em função de sobrecargas como delegação e dependência na mesma primitiva de linguagem, seja pela falta de critérios mais objetivos para definição de objetivos, sub-objetivos, planos, etc, sentimos dificuldade ou mesmo, em alguns momentos, desestímulo na modelagem de requisitos iniciais e finais. Uma outra questão que ficou para nós é: até que ponto é válido a modelagem de uma organização inteira para somente depois inserir o sistema? Achamos válido sim a inserção de alguns atores em determinados contextos, mas em outras situações achamos que isso gera um overhead desnecessário. A nossa opinião é de que é necessária uma boa dose de bom senso para medir o quê vale a pena ser modelado em requisitos iniciais e finais AORML A linguagem AORML nos proporcionou uma maior convicção no sentido dos objetos de captura/modelagem serem claramente relevantes para o processo de desenvolvimento. Por outro lado, acreditamos que a sintaxe da linguagem tem muito a melhorar. Tal sintaxe é demasiadamente complicada. Não obstante haver muitas primitivas de linguagem distintas, a morfologia dos construtores da linguagem é muito parecida (e.g., mudar a linha de tracejada para tracejada com bolinhas para denotar um conceito diferente), confundindo assim, a absorção dos elementos da linguagem. À parte a questão da sintaxe, ficamos muitas vezes questionando se algumas aplicações da linguagem (e.g., um determinado diagrama) seriam realmente adequadas ainda em fase de projeto, não por achar irrelevante, mas talvez por 2 Considerando que nossa experiência com a linguagem limita-se a uma experiência de desenvolvimento, não nos sentimos à vontade para afirmar nossas opiniões com a mesma convicção de uma experiência de pesquisa, i.e., de maior profundidade, por exemplo, confrontando várias linguagens. O mesmo vale para AORML.

17 serem de baixo nível de abstração. Esse tipo de dúvida, porém, em geral se mostrou impertinente à medida em que avançava o amadurecimento a respeito do sistema e da importância de descrevê-lo com precisão Tropos + AORML A transformação de Tropos para AORML foi suave, e não causou muito impacto nos modelos Tropos. As mudanças que foram se fazendo necessárias nos modelos Tropos denotaram, de fato, questões pertinentes que passaram despercebidas na modelagem Tropos. Mesmo assim, acreditamos que um maior amadurecimento da metodologia ARKnowD, por exemplo, gerando uma linguagem única, permitiria um desenvolvimento com mais qualidade. Acreditamos que tal amadurecimento envolve necessariamente um amadurecimento das duas linguagens utilizadas bem como uma evolução no entendimento das questões que elas se propõem a tratar, independentemente de linguagem. 6.2 Uso das Ferramentas de Modelagem A) TAOM4E Primeiramente, vale ressaltar que encontramos dificuldade em instalar o plugin TAOM4E no ambiente Eclipse utilizando o procedimento descrito no site dos desenvolvedores. Conseguimos finalmente instalar o plugin corretamente através do seu download diretamente pelo Eclipse. Tivemos problema ao salvar os modelos tropos. A ferramenta não salva os modelos tropos corretamente. Para salvar com segurança, tivemos de criar um novo modelo, copiar o conteúdo do modelo atualizado para o novo e então renomear o novo modelo. Esta foi a maneira que encontramos para sanar o problema. No mais, a ferramenta TAOM4E apresenta estabilidade e permitiu um desenvolvimento eficaz dos modelos. B) MS Visio com Template AORML O MS Visio é uma boa ferramenta, sobretudo por permitir a modificação do template de maneira ágil e fácil. No entanto, o MS Visio apresenta bugs graves relacionados à modificação do conteúdo textual dos elementos de desenho. Tais bugs tornaram o desenvolvimento de diagramas AORML um transtorno na medida em que ISD s, IFD s e IPD s constituem diagramas refinados e que exigem modificações com alguma freqüência. Somente na fase final do desenvolvimento, conseguimos descobrir a causa dos bugs: a tentativa do Visio de corrigir idioma. Para haver estabilidade, é necessário desativar a opção Verificar ortografia ao digitar no menu Ferramentas -> Opções - > Ortografia. Uma vez resolvido esse problema, o MS Visio oferece apoio apropriado ao desenvolvimento de diagramas AORML.