Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Orquestração de Serviços por Meio de Agentes de Software no Domínio de Vida Ambiente-Assistida Vinicius Uriel Cardoso Nunes Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Orientador Prof. Dr. Vander Ramos Alves Brasília 2009

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Bacharelado em Ciência da Computação Coordenador: Prof. Dr. Marcus Vinicius Lamar Banca examinadora composta por: Prof. Dr. Vander Ramos Alves (Orientador) CIC/UnB Prof. a Dr. a Célia Ghedini Ralha CIC/UnB Prof. a Dr. a Genaína Nunes Rodrigues CIC/UnB CIP Catalogação Internacional na Publicação Nunes, Vinicius Uriel Cardoso. Orquestração de Serviços por Meio de Agentes de Software no Domínio de Vida Ambiente-Assistida / Vinicius Uriel Cardoso Nunes. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Vida Ambiente-Assistida, 2. Arquitetura Orientada a Serviços, 3. Sistemas Multi-Agentes CDU 004 Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Orquestração de Serviços por Meio de Agentes de Software no Domínio de Vida Ambiente-Assistida Vinicius Uriel Cardoso Nunes Monografia apresentada como requisito parcial para conclusão do Bacharelado em Ciência da Computação Prof. Dr. Vander Ramos Alves (Orientador) CIC/UnB Prof. a Dr. a Célia Ghedini Ralha CIC/UnB Prof. a Dr. a Genaína Nunes Rodrigues CIC/UnB Prof. Dr. Marcus Vinicius Lamar Coordenador do Bacharelado em Ciência da Computação Brasília, 3 de Dezembro de 2009

4 Agradecimentos Gostaria de agradecer ao meu orientador, professor Vander Alves, pela dedicação, companheirismo e cumplicidade demonstrados durante a realização deste trabalho. Vander, sinto que além de um bom orientador, encontrei um amigo. Agradeço à minha namorada Paulinha por todos os momentos em que esteve presente. Paulinha, obrigado por ter ficado sempre por perto mesmo quando minha cabeça estava tão distante. A sua presença me encoraja a enfrentar os desafios. Agradeço ao meu amigo Zabufeira pelos momentos em que me atrapalhou puxando papo no GTalk e pelas dicas com o Latex. Sem dúvida, esses momentos foram indispensáveis para a conclusão deste trabalho e para que eu pudesse relaxar depois de algumas horas de concentração. Agradeço à minha família por terem cuidado de mim enquanto eu pensava no meu trabalho. Mãe, obrigado pelos cafés e pelos lanches no final da noite. Lucas, obrigado pelos dias em que me divertiu. Agradeço aos meus amigos mais próximos pelos momentos de descontração no e- mail e pelos happy hours de sexta à noite. A todos, muito obrigado. iv

5 Resumo Soluções em vida ambiente-assistida são inerentemente complexas. Durante o desenvolvimento de soluções nesse domínio frequentemente surgem desafios tecnológicos. Em especial, os desafios relacionados à Engenharia de Software podem requerer a combinação de diversas estratégias de modelagem e implementação de software. O EMERGE, projeto de pesquisa nesse domínio, propõe a combinação de sistemas multi-agentes com os estilos arquiteturais SOA (software-oriented architecture) e EDA (Event-driven architecture) objetivando abstrações que facilitem a modelagem do problema e aumento da flexibilidade de manutenção e evolução de sistemas nesse domínio. No entanto, a implementação de tal combinação ainda não foi realizada. Neste contexto, este trabalho de graduação abordará algumas questões relacionadas à combinação de sistemas multi-agentes com arquitetura orientada a serviços nesse domínio. Em particular, a contribuição essencial deste trabalho é mostrar a viabilidade de tal integração em nível de implementação. A modelagem e a implementação dessa integração se basearam nos documentos de especificação e de projeto do EMERGE. Palavras-chave: Vida Ambiente-Assistida, Arquitetura Orientada a Serviços, Sistemas Multi-Agentes v

6 Abstract Solutions in assisted ambient living domain are inherently complex. Developing such solutions often brings technological challenges, especially software engineering challenges, which may require a combination of several modeling and implementation strategies. EMERGE, an ambient assisted living project, proposes a combination of MAS (multi-agent systems), SOA (service-oriented architecture), and EDA (event-driven architecture) to promote an abstraction easing system modeling, and an increasing flexibility to maintain and evolve systems in this domain. However, the implementation of such combination has not been accomplished yet. In this context, this undergraduate project addresses some issues related to the combination of SOA and MAS in this domain. In particular, the key contribution of this work is to show the viability of such integration at the implementation level. The modeling and the implementation of this integration have been based on the specification and design documents of the EMERGE project. Keywords: Ambient Assisted Living, Service-Oriented Achitecture, Multi-Agents Systems vi

7 Dedicatória Aos meus pais. vii

8 Sumário 1 Introdução Objetivos Organização do trabalho Descrição do Problema Domínio: Vida Ambiente-Assistida (VAA) EMERGE Requisitos funcionais Arquitetura do sistema Escopo do trabalho Fundamentação Teórica Sistemas Multi-Agentes Agentes de Software Agentes Inteligentes Arquitetura de Agentes Comunicação Coordenação Java Agent DEvelopment (JADE) Arquitetura Orientada a Serviços (SOA) Arquitetura orientada a serviços Open Services Gateway Initiative (OSGi) BMPN (Business Process Modeling Notation) Símbolos utilizados Metodologia Estratégia de pesquisa Identificação de Serviços Levantamento Identificação Templates utilizados Metodologia de Modelagem dos Agentes Introdução Análise Projeto: Projeto Arquitetural Projeto : Projeto Detalhado viii

9 5 Análise e Projeto Modelagem dos Serviços Levantamento Identificação Modelagem dos Agentes Análise Projeto : Projeto Arquitetural Projeto : Projeto detalhado Modelo de Serviços Modelo Visual Arquitetura e Implementação Arquitetura Proposta Tipos de Componentes Componentes de Infra-estrutura Tecnologias Utilizadas Arquitetura Interna dos bundles Estrutura Interna dos bundles Visão Geral Modelo de Dados Barramento de Contexto Páginas amarelas Implementação dos serviços OSGi Bundles de Serviços Serviço Confirmar Emergência Serviços Detectar Alarme e Detectar Emergência Serviço Detectar Desvio Serviço Avisar envio de notificação ao centro de despacho ou serviço sócio-médico Serviços Enviar Dados Despacho e Enviar Dados SSM Implementação dos agentes JADE Bundles de Agentes Troca de mensagens Comportamentos Agente EmergencyAgent Agente ElderlyAgent Cenário de execução: Detectar emergência aguda Avaliação dos Resultados e Conclusão Resultados Conclusão Trabalhos Futuros Trabalhos Relacionados Referências 108 ix

10 Lista de Figuras 2.1 Projeto EMERGE (adaptado de Gross et al. (2009)) Fluxo de atividades: Desvios de longo prazo (adaptado de Gross et al. (2009)) Diagrama de caso de uso: Detectar desvios de longo prazo (adaptado de Gross et al. (2009)) Fluxo de atividades: Emergência aguda (adaptado de Gross et al. (2009)) Diagrama de caso de uso: Detectar emergência aguda (adaptado de Gross et al. (2009)) Subsistemas EMERGE (Gross et al., 2009) EMERGE Home subsystem (Gross et al., 2009) Visão conceitural do Service Hub (Gross et al., 2009) Arquitetura do Service Hub (Gross et al., 2009) Agente de Software (adaptado de Weiss (1999)) Agente Reativo Agente BDI (adaptado de Weiss (1999)) Agente em Camadas (adaptado de Weiss (1999)) Pilha de Comunicação da FIPA Ciclo de vida dos agentes JADE (adaptado de Bellifemine (2007)) Arquitetura Orientada a Serviços Estrutura de diretórios de um bundle Ciclo de vida de um bundle (OSGi, 2009b) Gateways BPMN Atividades BPMN Eventos BPMN Pool BPMN Setas BPMN Representação GAIA, adaptado de (Zambonelli et al., 2003) Fluxo de Atividades do EMERGE Estrutura Organizacional Serviços e agentes modelados Plataformas utilizadas Estrutura interna dos bundles Visão geral do sistema x

11 6.4 Hierarquia de composição da ontologia Estrutura de herança da ontologia Tela de confirmação ou cancelamento de emergência Tela de informação sobre o envio de uma notificação Protocolo PedirConfirmacao Protocolo EnviarNotificacao Cenário Detectar emergência aguda xi

12 Lista de Tabelas 4.1 Tabela de Serviços Candidatos Tabela de Serviços Atômicos Consolidados Tabela de Serviços Compostos Consolidados Operadores para expressões liveness Regras Organizacionais Modelo de Papéis Descrição das Atividades Protocolos de Interação Modelo de Agentes Modelo de Serviços Serviços Candidatos Serviços Atômicos Consolidados Regras Organizacionais Modelo de Interações : Protocolos Papel: Assistente Pessoal Atividades : Assistente Pessoal Papel : Assistente de Emergência Atividades : Assistente de Emergência Modelo de Agentes Modelo de Serviços (GAIA) xii

13 Lista de Códigos 3.1 Exemplo de agente JADE Exemplo de comportamento JADE Exemplo de Threaded Behaviour Compartilhando a referência do DataStore Adicionando informações ao DataStore Recuperando informações do DataStore Exemplo de troca de mensagens Exemplo de conceito JADE Exemplo de predicado JADE Exemplo de ontologia JADE Exemplo MANIFEST.MF Exemplo de publicação de serviço Exemplo de descoberta de serviço Exemplo de um MANIFEST.MF MANIFEST.MF Bundle AALOntology MANIFEST.MF Bundle ContextBus MANIFEST.MF Bundle ConfirmEmergencyService MANIFEST.MF Bundle DetectEmergencyService MANIFEST.MF Bundle DetectLongTermDeviationService NotificationType.java Bundle InformNotificationSentService MANIFEST.MF Bundle InformNotificationSentService MANIFEST.MF Bundle SendEmergencyDataService MANIFEST.MF Bundle SendLongTermDataService StartAgent.java xiii

14 Capítulo 1 Introdução Estudos demográficos apontam um aumento no percentual da população idosa no Brasil e no mundo. Essa população idosa é constituída por pessoas com mais de sessenta anos de idade (ONU, 2001; Camarano, 2002). Junto com o envelhecimento surgem doenças e deficiências típicas da idade, o que aumenta a demanda por serviços de saúde para essa população e, consequentemente, aumenta os custos para a sociedade e para os governos (Nehmer et al., 2006). Nesse contexto, soluções escaláveis e automatizadas para melhorar a qualidade de vida dessas pessoas são muito relevantes. Essas soluções devem ser capazes de auxiliar as pessoas em suas atividades diárias e detectar situações de emergência prontamente. A tecnologia de ambientes inteligentes tem se mostrado promissora para resolver esse tipo de problema, entretanto ainda não há uma solução considerada adequada para o problema (Nehmer et al., 2006). A Vida Ambiente-Assistida (VAA) é a área que estuda esse problema. Soluções nesse domínio são típicamente compostas por dispositivos de hardware e software e por um conjunto de serviços integrados para prover assistência adequada à pessoa assistida (Becker et al., 2008a). O EMERGE (EMERGE, 2009) é um projeto nesse domínio que visa detectar, prevenir e prever situações de emergência. Esse projeto propõe o uso de vários sensores embutidos na residência da pessoa assistida que são responsáveis por capturar diversos dados do ambiente que são processados por um sistema de software instalado também na residência. Esse sistema de software é que realiza as atividades de prevenção, previsão e detecção de emergência. Essas atividades são realizadas com base nos diversos dados coletados pelos sensores que são cruzados com uma base de dados de conhecimento médico por meio da qual o sistema identifica padrões de situações de emergência Além de identificar as situações de emergência, o sistema deve ser capaz de tratá-las adequadamente. O EMERGE possui uma parte do sistema dedicada a tomar decisões e dar o devido encaminhamento para essas situações. Por exemplo, o sistema deve ser capaz de acionar as equipes de emergência ao detectar que a pessoa assistida sofreu um acidente doméstico. O EMERGE propõe uma especificação da arquitetura e dos requisitos desse sistema. Esse software seria uma combinação de um sistema multi-agentes (MAS) com os estilos arquiteturais SOA (service-oriented architecture) e EDA (event-driven 1

15 architecture) (Becker et al., 2008b). Segundo o documento de arquitetura do projeto, a modelagem dos agentes para representar os diversos stakeholders do sistema traria benefícios do ponto de vista de manutenção, evolução e gerenciamento do sistema. Esses benefícios seriam propiciados pela abstração provida pelo sistema multi-agentes, uma vez que esses sistemas visam modelar o problema de maneira semelhante à realidade. A arquitetura orientada a serviço traria flexibilidade para alteração dos componentes já que a descrição dos serviços por meio de interfaces torna os componentes da solução menos acoplados. A arquitetura orientada a eventos traria flexibilidade para a expansão do sistema, já que novos componentes não precisariam ter dependências diretas com os demais componentes, bastando apenas utilizar os eventos de interesse disponíveis no ambiente (Becker et al., 2008b). Entretanto, a combinação dessas diversas tecnologias (MAS, SOA, EDA) ainda não foi implementada. Neste trabalho será realizada uma proposta de implementação combinando sistemas multi-agentes com SOA. Essa implementação se restringirá à parte do sistema responsável pelo encaminhamento das situações de emergência. Ao final serão apresentados os resultados empíricos resultantes do estudo de viabilidade desse problema. 1.1 Objetivos Objetivo geral Estudo de viabilidade do sistema EMERGE combinando sistemas multi-agentes com arquitetura orientada a serviços. Objetivos específicos Modelar parte do projeto EMERGE. Implementar o sistema modelado explorarando a combinação de sistemas multi-agentes com arquitetura orientada a serviços. Realizar um estudo de viabilidade relativo à combinação dessas tecnologias. 1.2 Organização do trabalho Este trabalho está dividido nos seguintes capítulos: Descrição do Problema (Capítulo 2): nesse capítulo será apresentado o domínio, parte da documentação do projeto EMERGE relevante para esse trabalho e a delimitação do escopo da modelagem e implementação. Fundamentação Teórica (Capítulo 3): nesse capítulo serão abordados os conceitos envolvidos na execução do trabalho. Serão apresentados os conceitos utilizados relativos a arquitetura orientada a serviços e a sistemas multiagentes. Além disso serão apresentadas também as tecnologias utilizadas na implementação. 2

16 Metodologia (Capítulo 4): esse capítulo apresenta a estratégia de pesquisa utilizada, o método utilizado para modelagem dos serviços e a metodologia utilizada para modelagem dos agentes. Análise e Projeto (Capítulo 5): nesse capítulo serão apresentados os artefatos resultantes da modelagem dos serviços e dos agentes. Arquitetura e Implementação (Capítulo 6): esse capítulo apresenta a arquitetura e a implementação do protótipo. Avaliação dos Resultados e Conclusão (Capítulo 7): exposição dos resultados observados na modelagem e implementação e as considerações finais sobre o trabalho realizado. 3

17 Capítulo 2 Descrição do Problema Este capítulo descreve o problema que motivou a implementação apresentada neste trabalho. Inicialmente é dada uma visão geral do domínio, em seguida será apresentado o projeto EMERGE nesse mesmo domínio. São apresentados apenas os casos de uso e as funcionalidades do projeto considerados relevantes para este trabalho. Ao final do capítulo será apresentada a delimitação do escopo da implementação. 2.1 Domínio: Vida Ambiente-Assistida (VAA) O processo de envelhecimento da população tem se intensificado na última década nos países industrializados (Camarano, 2002; ONU, 2001). As despesas com saúde para os governos e para a sociedade têm aumentado devido à necessidade de tratamento constante para as pessoas idosas. Com o passar do tempo a vida social dessas pessoas e as atividades diárias ficam cada vez mais comprometidas, o que diminui a qualidade de vida dessas pessoas (Nehmer et al., 2006). A vida ambiente-assistida é uma solução de ambiente inteligente que visa propiciar melhor qualidade de vida para essas pessoas e reduzir os custos com saúde. Essas soluções são compostas por dispositivos e serviços para auxiliar as atividades diárias da pessoa assistida (Becker et al., 2008a; Nehmer et al., 2006). Tipicamente essas soluções prestam serviços classificados em: Tratamento de emergências: serviços responsáveis por prevenir, prever e detectar emergências. Melhoria na autonomia das pessoas assistidas: serviços que permitem que a pessoa assistida não necessite de algum auxílio anteriormente prestado por outra pessoa. Conforto: os demais serviços são considerados serviços tais como serviços de logística ou de entretenimento. A natureza do problema exige que essas soluções apresentem características tais como (Becker et al., 2008a): 4

18 A solução deve permitir que seus serviços sejam customizados para atender às necessidades da pessoa assistida. A solução deve ter custo baixo. A solução deve ser eficiente do ponto de vista da utilização dos recursos (largura de banda de comunicação, consumo de energia, etc.). A solução deve ser extensível e adaptável para que possa atender prontamente as novas necessidades da pessoa assistida que possam surgir. O sistema deve levar em consideração os fatores de usabilidade associados ao perfil da pessoa assistida e deve ser capaz de se comunicar proativamente com a pessoa assistida. A solução deve ser confiável, sendo capaz de resistir ao uso indevido, à indisponibilidade de componentes. Além disso a solução não deve causar danos à saúde e integridade da pessoa assistida. O sistema deve ser compreensível aos seus usuários finais, especialmente no que diz respeito às informações apresentadas. 2.2 EMERGE O EMERGE é um projeto em vida ambiente-assistida que tem por objetivo detectar situações de emergências agudas e prevenir situações de emergência (EMERGE, 2009). Uma emergência aguda é uma situação de emergência que não pode ser prevenida. Por meio de dispositivos embutidos no ambiente, o sistema coleta dados sobre as atividades diárias da pessoa assistida tais como frequência de uso do banheiro, numero de refeições, quantidade de horas de sono, etc. Além disso o sistema é capaz de coletar outros dados tais como sinais vitais, localização da pessoa dentro de sua residência e quedas. Por meio do histórico dos dados das atividades diárias da pessoa, o sistema consegue detectar desvios no comportamento e notificar o médico da família e os parentes. Em situações de emergência aguda, o sistema envia notificações para o serviço médico de despacho de emergências. Esse serviço é responsável por confirmar as situações de emergência, encaminhar as emergências para as equipes de atendimento médico de emergência e por acionar serviços de apoio social (Becker et al., 2008a). A seguir será apresentada a lista de funcionalidades do sistema EMERGE, incluindo aquelas já mencionadas anteriormente. São elas (Becker et al., 2008b): Detectar atividades da vida diária. Detectar funções fisiológicas. Supervisionar dados vitais e medicação. Detectar desvios de longo prazo. 5

19 Enviar notificações para o serviço sócio-médico ao detectar desvios de longo prazo. Possibilitar que o serviço sócio-médico se comunique com a pessoa assistida. Detecção automática de emergências agudas Possibilitar o acionamento manual de um alarme de emergência. Possibilitar que um alarme seja cancelado. Notificar o enfermeiro (caso a pessoa assistida possua um em sua casa, ou more em um asilo) ou o centro de despacho de emergências médicas. Possibilitar que o enfermeiro ou centro de despacho se comuniquem com a pessoa assistida. O sistema possui vários usuários desempenhando papéis diferentes. A seguir, serão apresentados cada um desses papéis (Becker et al., 2008b): Pessoa Assistida: esse é o papel desempenhado pela pessoa que está sendo monitorada pelo sistema. O sistema não deve requerer nenhuma habilidade especial dessa pessoa e deve permitir que ela peça ajuda diretamente. Médico de emergência: médico acionado pelo centro de despacho médico para socorrer a pessoa assistida em caso de emergência. O sistema informa a esse médico detalhes sobre a causa da emergência, a saúde o paciente e local da residência. Enfermeiro (na casa ou no asilo): caso a pessoa assistida viva em um asilo ou tenha um enfermeiro a disposição em sua residência, este será o primeiro a receber os alarmes de emergência aguda ou de desvios de longo prazo. Centro de despacho: essa central recebe os alarmes de emergência aguda, interpreta-os e aciona as equipes necessárias. Serviço sócio médico: essa central recebe os alarmes de desvios de longo prazo e decide quem deve ser acionado para prestar assistência à pessoa assistida. Médico da família: esse médico é informado pelo serviço sócio-médico quando ocorre um desvio de longo prazo. Rede social: a rede social é formada pela família, vizinhos e amigos e são acionados pelo serviço sócio médico em algumas situações de desvios de longo prazo para que possam ser tomadas as medidas preventivas. Técnico: responsável técnico pelo sistema, o sistema deve prover ferramentas adequadas para que o técnico possa monitorá-lo. A Figura 2.1 apresenta uma visão do sistema representando os participantes, algumas funcionalidades e os subsistemas. A figura apresenta a pessoa assistida em sua casa. Essa casa é equipada por vários sensores que compõem uma rede de 6

20 sensores. Os dados desses sensores são então agregados em situações mais representativas no contexto pelos perceptores. As situações detectadas pelos perceptores são então repassadas à camada de detecção de emergência que decidirá se as situações informadas representam algum tipo de emergência de acordo com sua base de informações. Tal base pode ser personalizada pelo médico da família de acordo com as particularidades de saúde da pessoa assistida. A camada de interação é responsável por gerir as interações com o usuário e por tomar decisões de acordo com o tipo de evento encaminhado pela camada de detecção de emergências. As emergências e os desvios são encaminhados para o serviço sócio-médico ou centro de despacho, serviços externos à casa da pessoa assistida. Figura 2.1: Projeto EMERGE (adaptado de Gross et al. (2009)) Requisitos funcionais Nesta seção serão apresentados alguns dos requisitos funcionais do sistema, os casos de uso associados, os fluxos de atividades e um possível cenário para cada fluxo. Nesta seção serão abordados apenas os requisitos funcionais correspondentes aos cenários utilizados neste trabalho. Detectar desvios de longo prazo Um desvio de longo prazo é uma deterioração do estado de saúde da pessoa assistida. Essa deterioração pode ser tanto física quanto psicológica. A detecção desses eventos é feita por meio de comparação de dados de atividades da vida diária coletados historicamente com os dados mais recentes. 7

21 Cenário 1: Detecção de desvios de longo prazo A pessoa assistida pega um resfriado, devido a isso se sente indisposta e sem ânimo para realizar suas atividades diárias, acaba ficando mais reclusa e menos ativa. O sistema detecta que a pessoa já não sai de casa com a mesma frequência de uma semana atrás, passa a maior parte do dia deitada na cama ou no sofá e não tem se alimentando direito. Diante dessas evidências, o sistema envia uma notificação de desvio de longo prazo para o serviço sócio-médico, que por sua vez encaminha a situação ao médico da família, responsável pela pessoa assistida, que examina a pessoa e prescreve a devida medicação. Fluxo de atividades A Figura 2.2 apresenta o fluxo de atividades associado à detecção de desvios de longo prazo. Nesse fluxo estão representadas apenas as atividades realizadas pelo sistema e pelo serviço sócio-médico. Figura 2.2: Fluxo de atividades: Desvios de longo prazo (adaptado de Gross et al. (2009)) Casos de uso A Figura 2.3 apresenta o modelo de casos de uso envolvidos na detecção de desvios de longo prazo. Os casos de uso representados pelas elipses escuras indicam a necessidade de uma interface gráfica. As setas de include indicam que o caso de uso apontada pela seta faz parte do caso de uso de onde a seta parte. 8

22 Figura 2.3: Diagrama de caso de uso: Detectar desvios de longo prazo (adaptado de Gross et al. (2009)) Descrição dos casos de uso A seguir será apresentada uma breve descrição de cada caso de uso representado no diagrama: Detectar desvios de longo prazo: um desvio de longo prazo é disparado quando ocorre alguma mudança no estado de saúde da pessoa assistida. Em particular quando há alterações nos padrões de atividades diárias, dados vitais, funções psicossociais. Persistir dados de desvios de longo prazo: os dados enviados no relatório de desvios de longo prazo devem ser salvos. Estabelecer conexão com o serviço sócio-médico: o sistema estabelece a conexão com o serviço sócio-médico para permitir que o relatório seja enviado e para que o serviço sócio-médico possa estabelecer comunicação com a pessoa assistida. Enviar notificação e relatório de saúde: o sistema envia uma notificação e o relatório de saúde da pessoa assistida para o serviço sócio-médico. O conteúdo desse relatório não foi definido pelo projeto EMERGE. Informar à pessoa assistida que dados foram enviados: o sistema notifica a pessoa assistida, por meio de um display, que uma notificação de desvio de longo prazo foi enviada para o serviço sócio-médico. Detectar emergência aguda Uma emergência aguda é um evento de emergência que não pode ser previsto ou prevenido. O sistema é capaz de identificar situações de emergência aguda auto- 9

23 maticamente. Além disso, a pessoa assistida pode pedir ajuda ativamente por meio do acionamento de botões de emergência espalhados pela casa e pode cancelar um evento de emergência acionado por ela ela mesma ou detectado automaticamente pelo sistema. Cenário 2: Detecção de emergência aguda A pessoa assistida acorda e vai ao banheiro tomar banho. No momento em que estava saindo do banheiro, a pessoa assistida escorrega no chão úmido e cai ao chão. Nessa queda, a pessoa assistida bate a cabeça e permanece inconsciente. O sistema detecta a queda pela combinação de vários dados coletados pelos diferentes sensores. Diante dessa situação, o sistema pede que a pessoa assistida confirme a emergência em um determinado intervalo de tempo; após o término desse período, o sistema continuou sem resposta da pessoa assistida o que o faz considerar a emergência confirmada. Prontamente, o sistema envia um alarme de emergência aguda para o centro de despacho. Fluxo de atividades A Figura 2.4 apresenta o fluxo de atividades desde a detecção da emergência até o envio da notificação de emergência ao centro de despacho. Casos de uso A Figura 2.5 apresenta o modelo de casos de uso relativo à detecção de emergência aguda. Os casos de uso representadas pelas elipses escuras indicam a necessidade de uma interface gráfica. As setas de include indicam que o caso de uso apontado pela seta faz parte do caso de uso de onde parte a seta. Descrição dos casos de uso A seguir será apresentada uma breve descrição de cada um dos casos de uso representados no diagrama da Figura 2.5: Detectar Emergências automaticamente: as situações de emergências agudas são detectadas pelo Home Subsystem quando ocorrem situações de queda, imobilidade ou valores críticos de dados vitais. Salvar dados da emergência: o sistema grava todas as informações capturadas pelos sensores que estão relacionadas à emergência. Informar a pessoa assistida que uma emergência foi detectada: o sistema se comunica com a pessoa assistida por meio de áudio, por um display ou por ambos. Pedir confirmação da emergência: o sistema pede que a pessoa assistida confirme ou cancele a emergência. Se a pessoa assistida não deseja confirmar a emergência, ela deve explicitamente cancelar a emergência, caso contrário a emergência será confirmada. 10

24 Figura 2.4: Fluxo de atividades: Emergência aguda (adaptado de Gross et al. (2009)) Estabelecer conexão com a central de despacho: caso a pessoa assistida possua um enfermeiro, essa conexão se dará com os dispositivos do enfermeiro local. Caso a pessoa não possua tal apoio, a conexão será feita entre o Home Subsystem e o centro de despacho. Essa conexão é utilizada para enviar os dados e para estabelecer um canal de comunicação com a pessoa assistida. Enviar alarme e dados da emergência: o Home Subsystem envia o alarme e os dados para o responsável (o enfermeiro ou o centro de despacho). Informar a pessoa assistida que um alarme foi enviado: o Home Subsystem informa a pessoa assistida que a notificação e os dados foram enviados para o centro de despacho. Esse aviso pode ser feito por um display, ou por meio de som ou por ambos. Disparar alarme manualmente: a pessoa assistida pode ativar o alarme manualmente através de botões espalhados pela residência. 11

25 Figura 2.5: Diagrama de caso de uso: Detectar emergência aguda (adaptado de Gross et al. (2009)) Cancelar Alarme: sempre que ocorre uma situação de emergência aguda o sistema pede confirmação à pessoa assistida. Essa confirmação ou cancelamento deve ser feito dentro de um intervalo de tempo pré-determinado; caso contrário o sistema considera a emergência confirmada Arquitetura do sistema O projeto EMERGE propõe uma arquitetura formada por diversos subsistemas distribuídos para auxiliar a pessoa assistida. O principal subsistema é o Home. Esse subsistema fica fisicamente instalado na casa da pessoa assistida e é responsável pela coleta dos dados, detecção de emergência e desvios de longo prazo, comunicação com a pessoa assistida e envio de dados aos demais subsistemas. A Figura 2.6 apresenta uma visão geral dos subsistemas e dos papéis que interagem com cada subsistema. Repare que nessa figura os subsistemas com o estereótipo «variant» são opcionais e são empregados em determinadas configurações de instalação. Segue a abaixo uma breve descrição de cada um dos subsistemas: Home: subsistema implantado na casa da pessoa assistida, responsável por detectar e encaminhar as emergências e os eventos de longo prazo. Possui interfaces com o subistema Dispatch, SMSC e CareGiver para enviar as respectivas notificações e estabelecer canais de comunicação. Na Figura 2.6 a pessoa assistida está representada pelo ator Assisted Person. Dispatch: subsistema responsável por receber alarmes de emergências agudas e por estabelecer um canal de comunicação com a pessoa assistida no subsistema Home. De forma análoga, esse subsistema oferece uma interface para 12

26 Figura 2.6: Subsistemas EMERGE (Gross et al., 2009) se comunicar com o subsistema CareGiver. Esse subsistema possui interface de comunicação com o subsistema EDoc para encaminhar a emergência às equipes de suporte e com o SMSC no caso da emergência precisar de auxílio da equipe do serviço sócio-médico. Este subsistema é utilizado pela equipe da centro de despacho. CareGiver: subsistema para tecnologia móvel (PDAs, smartphones etc.) utilizado pelo enfermeiro (de casa ou do asilo) para receber os dados e as notificações de emergências agudas e desvios de longo prazo. Esse subsistema deve fornecer uma interface de comunicação via áudio como o subsistema Home. Na Figura 2.6 o enfermeiro está representado pelo ator caregiver. SMSC: subsistema responsável por receber a notificação e os dados de desvios de longo prazo por meio da interface com o subsistema Home. Além disso possui interface com o subsistema Dispatch para receber requisições para a equipe sócio-médica ou para pedir auxílio da equipe de emergência caso o 13

27 desvio de longo prazo exija. Esse subsistema é utilizado pela equipe do serviço sócio-médico. EDoc: subsistema para tecnologia móvel. Este sistema é utilizado pelas equipes de médicos e paramédicos. Este subsistema possui uma interface de comunicação para receber as tarefas do subsistema Dispatch. Essas tarefas possuem os dados relacionados à emergência. PC: uma máquina comum utilizada para receber notificações relacionadas aos subsistemas e com uma interface de gerenciamento. NotificationClient: subsistema externo capaz de receber e enviar mensagens e e mails. Arquitetura do Home Subsystem O subsistema Home é o principal subsistema da solução. É responsável por detectar e encaminhar os eventos, além de disponibilizar interfaces para interação direta com a pessoa assistida. A Figura 2.7 apresenta os subsistemas que compõe o subsistema Home. Nessa figura estão representadas as interações implícitas, aquelas feitas por meio de dispositivos de interface com o usuário (UIDevice), e explícitas, aquelas feitas por meio dos sensores (Sensor). Figura 2.7: EMERGE Home subsystem (Gross et al., 2009) Segue abaixo uma breve descrição de cada subsistema: Gateway: subsistema que conecta o subsistema Home aos demais subsistemas apresentados anteriormente (Dispatch, CareGiver, SMSC). Essas conexões são realizadas via internet ou GSM. 14

28 Sensor: dispositivo que mede valores e os converte em sinais. São os diversos sensores espalhados no ambiente. SensorNodeGateway: subsistema concentrador que recebe os sinais dos sensores (Sensor) e os encaminha ao ServiceHub. UIDevice: subsistema que provê interfaces com o usuário. Por exemplo, sons, displays e botões. ServiceHub: subsistema responsável por realizar a agregação dos dados percebidos pelos sensores, avaliar as informações obtidas por meio desses sensores, detectar situações de emergência e tomar providências. Dentre os componentes citados acima, apenas o ServiceHub será detalhado pois é o componente de maior relevância para a realização do trabalho (ver escopo 2.3). ServiceHub Este subsistema concentra a lógica de detecção e de tratamento dos desvios de longo prazo e das emergências agudas. Dentro desse subsistema os dados coletados pelos sensores são agregados em informações cada vez mais significativas até que se chegue a situações que exigem tratamento especial, tais como desvios e emergências. A Figura 2.8 apresenta uma visão conceitual do funcionamento do ServiceHub. A visão conceitual está dividida em camadas. As camadas mais altas apresentam um nível mais alto de abstração das informações. Enquanto a camada mais baixa lida com valores numéricos provenientes dos sensores, a camada mais alta lida com eventos de alto nível provido pela agregação e busca de padrões nesses dados. Por exemplo, uma combinação de dados numéricos denotando movimentação e posicionamento da pessoa assistida dentro da casa podem levar o sistema a detectar uma situação de queda. Essa situação seria então encaminhada para a camada mais alta que é responsável por planejar e tomar decisões. As setas como estereótipo «DataFlow» indicam o fluxo das informações partindo da funcionalidade de onde a seta parte e chegando a funcionalidade para onde a seta aponta. Repare que em determinadas situações, o fluxo pode se dar diretamente entre as funcionalidades Sensing e Controlling para que o sistema possa reagir de maneira mais imediata. A seguir estão detalhadas cada uma das funcionalidades conceituais apresentadas na Figura 2.8: Sensing: monitora o ambiente e a pessoa que vive nele através de sensores, fornecendo valores numéricos. Perception: agrega os valores dos diferentes sensores em valores simbólicos. Além disso, essa funcionalidade é capaz de fundir valores de diferentes sensores como estratégia para melhorar a precisão dos sensores. Os valores simbólicos representam situações elementares do ambiente. Identification: detecta padrões nas situações elementares fornecidas e desvios desses padrões. Essa camada identifica as situações de alto nível tais como emergências e desvios de longo prazo. 15

29 Figura 2.8: Visão conceitural do Service Hub (Gross et al., 2009) Planning: realiza o planejamento com base nas situações apresentadas e nos objetivos do sistema. Decide que tipo de assistência deve ser adotada e realiza as operações necessárias para prover essa assistência. Controlling: decompõe os comandos em ações simples e em seguida os converte em valores numéricos. Acting: interagem com o ambiente por meio de valores numéricos que controlam atuadores. Arquitetura do ServiceHub A arquitetura proposta pelo projeto EMERGE utiliza sistemas multi-agentes (Seção 3.1) na implementação das funcionalidades de identificação e planejamento. Essa decisão ajuda a administrar a complexidade inerente aos sistemas de vida ambiente-assistida já que os stakeholders e o ambiente podem ser modelados de forma mais próxima possível à realidade. Essa abordagem facilita a tomada de decisões por meio de analogias com o mundo real. Por exemplo, facilita a resposta de 16

30 questões tais como: O sistema deveria fornecer tais dados aos médicos de emergência? (Becker et al., 2008b). A arquitetura proposta pelo sistema EMERGE é uma combinação de sistemas multi-agentes com os estilos arquiteturais orientados a servições (SOA) e orientado a eventos (EDA). A arquitetura orientada a serviços (Seção 3.2) permite que os componentes sejam implementados de maneira pouco acoplada facilitando a alteração e evolução do sistema. A arquitetura orientada a eventos (Event-driven architecture) propõe uma interação de maneira publish-subscribe entre os componentes por meio da produção e reação a eventos. Um evento representa uma mudança significativa no contexto (Becker et al., 2008b). A arquitetura orientada a eventos facilita a comunicação de muitos para muitos (n:m) por meio do mecanismo de publishsubscribe para os eventos, aumentando a capacidade de adaptação e expansão do sistema. A Figura 2.9 apresenta uma visão lógica dos tipos de componentes que compõe a arquitetura do ServiceHub. Em seguida, será dada uma breve descrição de cada um desses componentes. Figura 2.9: Arquitetura do Service Hub (Gross et al., 2009) Aggregator: estes componentes capturam informações do ContextBus e agregam em informações com um nível maior de abstração e as lançam de volta ao ContextBus. Esses componentes implementam a funcionalidade de Perception do modelo conceitual. Assistant: estes componentes são os agentes do sistema multi-agentes do EMERGE. Os Assistants agem em nome de alguém tomando decisões dentro do sistema. Os agentes são autônomos e não são invocados por nenhum outro componente, detém a responsabilidade sobre suas próprias ações no sistema. Os Assistants trabalham com informações de mais alto nível disponíveis no ContextBus. Esses componentes representam as funcionalidades de Identification ou Planning do modelo conceitual. 17

31 ContextBus: barramento de comunicação que permite acesso às informações de contexto por meio de eventos. Nesse componente são publicadas as informações cruas dos sensores e posteriormente as informações de alto nível provenientes dos agregadores. Os diversos componentes se registram nesse barramento a espera de eventos de interesse. Quando o evento de interesse é publicado, o barramento avisa todos os assinantes que se registraram a espera de tal evento. Controller: componente utilizado para administrar e comandar os demais dispositivos do sistema. I/O Device: componentes que agem e monitoram o ambiente, inclusive de maneira direta com o usuário. Por exemplo, o sistema de som para comunicação com a pessoa asssitida. InteractionBus: esse componente representa o componente que permite a troca de dados de interação. O subistema de interação é responsável pelas interfaces com o usuário (som, displays, luzes, etc.). Sensor (Hardware/Software): representam os sensores que capturam dados numéricos e os lançam no ContextBus. Service: componentes autônomos que disponibilizam funções de negócio ou funcionalidades técnicas. 2.3 Escopo do trabalho Este trabalho tem por objetivo testar a viabilidade da combinação de sistemas multi-agentes com arquitetura orientada a serviços para a implementação de parte do sistema EMERGE. Nessa arquitetura, o principal benefício do uso de sistemas multi-agentes é fornecer uma abstração de modelagem do problema em que os componentes são rastreados diretamente para os stakeholders. Essa abstração facilita a implementação das decisões tomadas no mundo real. Por exemplo, decisões que envolvem as responsabilidades de cada stakeholder ou informações que podem acessar. A arquitetura orientada a serviços, por sua vez, torna o sistema mais modular e flexível uma vez que os serviços são desacoplados de suas implementações por meio de suas interfaces. O escopo deste trabalho se restringe à implementação da funcionalidade Planning do modelo conceitual do Service Hub. Esta funcionalidade é implementada por agentes que representam entidades do mundo real (stakeholders) e é responsável pela tomada de decisões em situações de emergência. Essas decisões desencadeiam a chamada de diversos serviços para o tratamento da emergência. Dessa forma, esse escopo contempla a interação entre agentes e serviços bem como o mapeamento entre agentes e stakeholders. Os cenários considerados mais relevantes para a funcionalidade de Planning foram os de detecção de desvios de longo prazo e de emergências agudas apresentados nesta seção. Para a implementação dessa funcionalidade foram implementados componentes do tipo Assistant, Service, ContextBus e I/O Device. 18

32 Capítulo 3 Fundamentação Teórica Neste capítulo serão abordados os principais conceitos relacionados a sistemas multi-agentes e SOA, além disso na seção de cada um desses conteúdos serão apresentadas também as tecnologias utilizadas neste trabalho. A primeira parte deste capítulo faz uma introdução à sistemas multi-agentes, em seguida será apresentada a plataforma JADE, utilizada no desenvolvimento dos agentes. A segunda parte aborda os conceitos relacionados a arquitetura orientada a serviços e em seguida será apresentada a plataforma OSGi, utilizada para implementar os serviços. 3.1 Sistemas Multi-Agentes Nesta seção serão apresentados os principais conceitos relacionados a sistemas multi-agentes. O início da seção apresenta os conceitos e as caracterísitcas dos agentes; em seguida, são apresentadas algumas arquiteturas de agentes e ao final são apresentadas questões típicas de sistemas multi-agentes tais como coordenação, comunicação e interação na sociedade de agentes Agentes de Software Não há uma definição única para agentes (Bellifemine, 2007; Weiss, 1999), porém podemos dizer que todas as definições concordam que agentes são componentes de software autônomos (Weiss, 1999). Agentes de software são considerados autônomos, pois estes operam sem necessidade de intervenção direta de humanos ou outro software, suas ações no meio e seu estado interno estão sob seu próprio controle. Frequentemente agentes são modelados de forma a representar pessoas, papéis específicos, funcionários e até mesmo organizações, agindo em nome deles (Stegan, 2006). Agentes cumprem seus objetivos através de comportamentos e interagem com outros componentes de software de forma indireta, através do meio, capturando informações pelos sensores e alterando o meio com seus atuadores (Figura 3.1). Agentes podem também interagir uns com os outros de forma direta por meio de um método de comunicação. Por exemplo, troca de mensagens (Bellifemine, 2007). 19

33 Figura 3.1: Agente de Software (adaptado de Weiss (1999)) Agentes podem ser reativos, observando os estímulos que ocorrem no meio e agindo de acordo com cada um deles. Agentes podem ser proativos, agindo no meio em busca de seus objetivos independentemente de estímulos externos. Apesar de um agente poder trabalhar de maneira solitária, é mais comum que este trabalhe juntamente com outros agentes no mesmo meio compondo sistemas multi-agentes ou comunidade de agentes. Nesses sistemas os agentes podem ter complexas interações diretas (por meio de envio de mensagens) e/ou indiretas (interferindo no meio) e podem até mesmo trabalhar em prol de objetivos conflitantes ou concorrentes Agentes Inteligentes Agentes inteligentes são ditos os agentes de software capazes de trabalhar em meios não determinísticos. Um meio não determinístico é aquele que apresenta uma ou mais das características abaixo (Weiss, 1999): Inacessível: as informações atualizadas não estão disponíveis a todo momento; Incerto: as ações do agente não tem um efeito pré-determinado no ambiente; Contínuo: o meio é composto por infinitos estados. Agentes inteligentes reagem de maneira flexível, adaptando suas ações às variações do meio. Um agente inteligente alcança tal flexibilidade por meio das seguintes características: Reatividade: ao perceber uma mudança o agente manifesta uma resposta que mais se adéque aos objetivos para o qual foi projetado. Proatividade: os agentes inteligentes agem proativamente buscando alcançar seus objetivos. Habilidade social: agentes inteligentes são capazes de se comunicar para satisfazer seus objetivos. Essa comunicação pode ser feita com diversas finalidades: obter informações, fornecer informações, dar ordens, etc. É interessante notar que essas informações podem não ser sempre confiáveis, um agente pode estar inserido em um meio hostil onde a informação recebida pode ter sido fornecida com o simples intuito de desinformar os demais agentes (Weiss, 1999). Um agente que sempre fornece informações confiáveis é dito um agente confiável. Ainda com relação à comunicação um agente que 20

34 recebe uma ordem não precisa necessariamente cumpri-la já que, como dito anteriormente, o agente é responsável pelo seu estado interno. Um agente que sempre realiza as tarefas que lhe são requisitadas é chamado de benevolente (Weiss, 1999). Agentes podem também apresentar características típicas de inteligência artificial como a capacidade de raciocinar para tomar decisões e capacidade de aprender, alterando a forma como reage e age no meio por meio de experiências anteriores Arquitetura de Agentes A arquitetura interna dos agentes define a forma como seus mecanismos de decisão são implementados. Esses mecanismos podem ir desde de um modelo simples estímulo-resposta, a elaborados modelos de raciocínio (Bellifemine, 2007). Cada arquitetura apresenta um modo de implementar os comportamentos dos agentes, as quatro principais arquiteturas são (Weiss, 1999; Bellifemine, 2007): Agentes baseados em lógica: O agente toma decisões por meio de deduções lógicas Agentes reativos: O agente toma decisões por meio de um mapeamento direto entre estímulo e resposta. Agentes BDI (Beliefs, Desires, Intentions): O agente toma decisões combinando as informações representadas por suas crenças, desejos e intenções. Agentes em camadas (Híbridos): Os agentes apresentam comportamento ativo e reativo, as decisões são tomadas por múltiplas camadas de software, cada uma representando um nível de abstração. A seguir será detalhada cada uma dessas arquiteturas. Agentes Baseados em Lógica Agentes baseados em lógica utilizam-se de símbolos lógicos para representar o meio e seus comportamentos desejados. Por meio de deduções lógicas a partir dessas representações o agente emite suas ações a fim de cumprir os objetivos para o qual foi projetado (Weiss, 1999). Uma das dificuldades desse tipo de agente é uma precisa representação do meio através de símbolos lógicos o que pode requerer um grande esforço. Outro ponto negativo é que a manipulação desses símbolos a fim de desencadear as ações podem ser demorada, portanto inútil (Bellifemine, 2007). Agentes Reativos Devido às dificuldades apresentadas o modelo lógico foi alvo de críticas e uma nova arquitetura foi proposta, uma arquitetura puramente reativa, onde cada evento percebido pelos sensores está diretamente mapeado para ações. Brooks (Brooks, 1991) defende que o meio não precisa ser representado simbolicamente e não é necessário raciocínio simbólico para que um agente manifeste um comportamento 21

35 inteligente (Weiss, 1999). Para Brooks o comportamento inteligente é resultante da interação de vários comportamentos simples. A arquitetura de Brooks possui as seguintes características: As entradas são diretamente mapeadas para respostas. Uma mesma entrada pode mapear múltiplas respostas. Caso haja múltiplas respostas para uma entrada, as respostas são classificadas em ordem de prioridade por meio de camadas hierárquicas, onde as camadas mais baixas representam os comportamentos com maior prioridade para emitir respostas. Os comportamentos são implementados por meio de máquinas de estado. A Figura 3.2 mostra um exemplo simples de um agente que representa um robô explorador. Esse robô deve explorar um terreno coletando rochas e levando de volta à base. Os comportamentos mais acima na hierarquia são os de menor prioridade. Figura 3.2: Agente Reativo Agentes BDI Agentes BDI (Beliefs, Desires, Intentions) é uma das arquiteturas mais populares no desenvolvimento de agentes inteligentes (Bellifemine, 2007), é baseado na tradição filosófica que busca entender o raciocínio prático (Weiss, 1999). Na teoria do raciocínio prático, o processo de decidir que metas devem ser alcançadas é chamado deliberação, e o que é feito para alcançar estas metas é chamado 22

36 de processo meio-fim. Um agente BDI toma decisões por meio da manipulação das seguintes informações: Crenças (Beliefs): Representação da informação que o agente tem acerca do seu meio. Desejos (Desires): Determina que opções são possíveis para o agente agir. Essas opções são baseadas nas crenças e nas intenções do agente. Intenções (Intentions): As intenções representam as metas atuais do agente para satisfazer um desejo escolhido. Nessa arquitetura, as intenções desempenham um papel fundamental influenciando todo o processo de decisão. O processo meio-fim é determinado pelas intenções. A intenção determina como o agente irá agir para alcançar as metas associadas a um determinado desejo. As intenções restringem o processo de decisão. Ao escolher uma determinada intenção o agente não poderá ter uma intenção que seja contraditória (de acordo com suas crenças) à primeira. As intenções são persistentes. Um agente não desiste de suas intenções até que consiga decidir, de acordo com suas crenças, que a intenção está cumprida, ou ela nunca poderá ser cumprida, ou que ela não é mais necessária. Dessa forma o agente reconsidera suas intenções de tempos em tempos para confirmar o alinhamento de suas intenções com seus desejos. É necessário que essa atividade de reconsideração seja realizada de maneira a não atrapalhar o funcionamento do agente pois, se por um lado ela é necessária para que o agente não trabalhe por uma intenção desnecessária, por outro ela pode evitar que o agente realize suas intenções. As crenças no futuro são influenciadas pelas intenções. Se o agente pretende alcançar determinada meta no futuro o processo de raciocínio considerará que essa meta terá sido alcançada no futuro. Um agente BDI tipicamente apresenta os seguintes componentes: Um conjunto de crenças representando informações acerca do meio. Uma função de revisão das crenças. Essa função recebe como entrada os dados coletados do meio e as crenças atuais do agente. Uma função geradora de opções. Essa função fornece ao agente suas opções atuais (seus desejos). Um conjunto de opções representando os desejos atuais do agente. Uma função de deliberação para determinar as intenções do agente baseandose nas suas crenças, seus desejos e suas intenções atuais. Um conjunto de intenções representando as intenções atuais do agente. Uma função de seleção de ação. Essa função determina a ação que o agente irá tomar baseada no conjunto de intenções. A Figura 3.3 representa a interação entre os divervos componentes em uma arquitetura BDI. 23

37 Figura 3.3: Agente BDI (adaptado de Weiss (1999)) Agentes em camadas Ao projetar agentes com comportamentos reativos e proativos é comum que essas classes de comportamentos sejam separadas em subsistemas distintos que por sua vez são subdivididos em camadas hierarquicamente dispostas que interagem umas com as outras (Weiss, 1999). De modo geral há duas abordagens (Figura 3.4) para disposição dessas camadas no que se refere ao fluxo de controle através das camadas. Camadas horizontais: cada camada está diretamente ligadas aos sensores e aos atuadores. Camadas verticais: temos uma camada ligada aos sensores e uma camada ligada aos atuadores, a informação capturada flui através dessas camadas de maneira hierárquica até a emissão de uma resposta pelos atuadores. Camadas horizontais simplificam o projeto do agente, pois cada comportamento novo pode ser representado por uma nova camada. Porém nessa abordagem várias camadas podem emitir sugestões de comportamentos simultaneamente, o que pode causar inconsistências nas ações do agente. Para resolver esse problema o agente precisa de uma função de mediação para decidir entre as n possíveis sugestões de resposta, o que pode requerer uma função de mediação. Supondo que cada camada possa emitir m sugestões de ação e que o agente possua n camadas, no pior caso seria m n combinações a serem consideradas pela função de mediação o que pode gerar gargalos no processo de decisão do agente. 24

38 Figura 3.4: Agente em Camadas (adaptado de Weiss (1999)) No modelo vertical de uma passagem, o controle sobe através das camadas até que seja emitida uma ação pela camada mais acima. No modelo vertical de duas passagens, o controle atravessa as camadas até chegar na camada mais alta (primeira passagem) e depois volta descendo camada a camada até que a resposta seja gerada na camada mais baixa (segunda passagem). Em ambos os casos o número de interações entre as camadas é reduzido se comparado ao modelo horizontal. A desvantagem é que o agente se torna menos tolerante a falhas. A falha de uma única camada pode afetar todo o funcionamento do agente (Weiss, 1999) Comunicação Agentes podem se comunicar, a comunicação é uma parte integrante dos sensores e dos atuadores dos agentes. Essa capacidade é especialmente importante em sistemas multi-agentes onde os diversos agentes precisam trocar informações para alcançar seus objetivos. Para que a comunicação possa ser estabelecida é necessário que os agentes entendam a mesma linguagem. Existem diversas linguagens disponíveis para sistemas multi-agentes (Bellifemine, 2007), dentre as principais podemos citar KQML 1 (Mayeld et al., 1996) e FIPA ACL 2 (FIPA, 2002a). A primeira linguagem amplamente aceita para agentes foi KQML (Bellifemine, 2007) desenvolvida na década de 90 nos Estados Unidos, sua principal característica é a separação da semântica do protocolo de comunicação da semântica da mensagem, pois está última é intimamente dependente do domínio da aplicação. Para expressar o conhecimento de domínio a KQML utiliza a linguagem de lógica de primeira ordem chamada KIF 3 (Genesereth and Fikes, 1992; Weiss, 1999). 1 Acrônimo para Knowledge Query and Manipulation Language 2 FIPA (FOUNDATION FOR INTELLIGENT, PHYSICAL AGENTS) FIPA é uma associação internacional para estabelecer padrões relacionados às tecnologias de agentes de software. Fundada em 1996, é uma organização sem fins lucrativos formada por membros da indústria e do meio acadêmico. ACL é um acrônimo para (Agent Communication Language), a FIPA ACL é a linguagem de comunincação entre agentes proposta pela FIPA. 3 KIF Knowledge Interchange Format 25

39 Hoje a linguagem mais usada e estudada é a FIPA ACL, suas principais características são a possibilidade de utilizar diferentes codificações para expressar o conteúdo das mensagens e protocolos de interação pré-definidos para estabelecer conversação entre agentes (Bellifemine, 2007). FIPA ACL (FIPA Agent Content Language) A FIPA ACL é baseada na teoria dos atos de fala (speech acts), nessa teoria filosófica a linguagem não se restringe a fazer declarações mas também realiza ações. Uma mensagem muitas vezes não é apenas uma informação ou uma questão, a mensagem em si pode representar uma ação. Por exemplo, ao pronunciar uma sentença um juiz não está apenas informando a sentença mas também está praticando a ação de sentenciar o acusado. Para fins computacionais os atos de fala são classificados em assertivos, diretivos, comissivos, permissivos, proibitivos, declarativos e expressivos. A FIPA ACL define vários atos de fala, dentre os mais importantes podemos citar (FIPA, 2003): agree: utilizado pelo agente destinatário para informar ao agente rementente que concorda em realizar determina ação. inform: utilizado quando um agente rementente deseja comunicar ao agente destinatário uma informação que acredita ser verdadeira. request: utilizado quando um agente rementente solicita ao agente destinatário que realize alguma ação. not understood: utilizado quando o agente destinatário deseja avisar ao agente remetente que não conseguiu entender o conteúdo da mensagem. refuse: utilizado para negar ao agente rementente que é possível realizar a ação requisitada. De acordo com a especificação da FIPA, todo agente deve ser capaz de receber qualquer ato de fala e responder pelo menos com uma mensagem de not understood. A troca de vários atos de fala em uma sequência pré-estabelecida é chamada de interação (Weiss, 1999). Essas interações são estabelecidas por meio de protocolos de interação, além dos atos de fala a FIPA ACL provê uma série de protocolos de interação. A FIPA ACL não determina qual deve ser a estrutura interna de cada mensagem porém, provê especificações para algumas linguagens para expressar o conteúdo das mensagens, tais como FIPA-SL (FIPA, 2002b), FIPA-KIF (FIPA, 2001a) e FIPA-RDF (FIPA, 2001b), essas linguagens são chamadas de linguagens de conteúdo (Content Languages). Uma mensagem FIPA ACL pode fazer referência a uma ontologia, um modelo conceitual específico da aplicação para definir os conceitos e as relações entre eles, por meio da qual a mensagem pode ser compreendida. Para que dois agentes possam se comunicar é necessário que compartilhem a mesma ontologia. 26

40 Figura 3.5: Pilha de Comunicação da FIPA A Figura 3.5 apresenta as camadas da pilha de comunicação definida pela FIPA, onde as camadas mais acima são as camadas de maior nível de abstração. Além das características já apresentadas da FIPA ACL a pilha de comunicação da FIPA apresenta mais duas camadas: a de codificação e a de transporte. A camada de codificação determina como a mensagem será transportada, a FIPA define vários formatos tais como XML 4, cadeia de caracteres (strings) e binária (bit-efficient). A camada de transporte por sua vez representa o meio pelo qual a mensagem será transportada, a FIPA definiu protocolos de transporte de mensagens para os protocolos IIOP 5, WAP 6 e HTTP Coordenação Os agentes se comunicam para cumprir suas metas ou para contribuir para que as metas do sistema como um todo sejam alcançadas. Quando o cumprimento dessas metas exige o compartilhamento de tarefas pelos agentes, algum mecanismo de coordenação deve ser utilizado para manter a coerência do sistema (Weiss, 1999). Chamamos coerência o quão bem um sistema de agentes se comporta como uma unidade. Uma sociedade de agentes pode ser coordenada por vários motivos, entre eles podemos citar os seguintes (Bellifemine, 2007): As metas dos agentes podem causar conflitos entre suas ações. As metas dos agentes podem ser interdependentes. 4 Acrônimo para Extensible Markup Language, formato de marcação de texto 5 O OMG (Object Management Group) existe para criar padrões para objetos distribuídos interoperáveis cuja principal especificação é a Common Object Request Broker Architecture (CORBA). GIOP (General Inter-ORB Protocol) é o padrão de mensagens do CORBA. A combinação de TCP/IP com GIOP é chamada IIOP (Internet Inter-ORB Protocol) (Curtis, 2009). 6 Acrônimo para Wireless Application Protocol, protocolo criado para comunicação wireless 7 Acrônimo para Hiper Text Transfer Protocol, protocolo criado para troca de arquivos HTML sobre TCP/IP 27

41 Agentes podem ter diferentes capacidades e conhecimentos. As metas de um agente podem ser alcançadas rapidamente se cada agente trabalhar em uma delas. Agentes podem interagir de maneira competitiva ou cooperativa. Cooperação é a coordenação de agentes não antagônicos e negociação é o nome utilizado a coordenação de agentes competitivos ou egoístas. Há várias abordagens conhecidas para estabelecer coordenação entre agentes, dentre elas podemos citar a estruturação organizacional, contract net, planejamento multi-agente, negociação, descritas a seguir. Estruturação organizacional (Organizational structuring) A abordagem de estruturação organizacional se baseia na noção de que os agentes desempenham papéis no sistema para resolver parte do problema e que, ao conhecer esses papéis, os demais agentes têm mais insumo para tomar suas decisões de interação. Essa noção é aplicada na estruturação das organizações que determinam papéis, relações de autoridade, processos de comunicação. Esse é um modelo de coordenação por cooperação. Nesse modelo cada agente está associado a um conjunto de tarefas que pode realizar. Pode-se atribuir prioridades às tarefas tanto para o agente priorize as atividades mais importantes relacionadas ao papel que desempenha como para permitir algum grau de sobreposição de tarefas para tornar o sistema de agentes mais tolerante a falhas. Assim como em organizações humanas, o agente não precisa estar ciente de todos os demais participantes. Um agente deve saber que tarefas deve desempenhar, que informações deve enviar e para quem e que informações deve receber e de quem. Em termos práticos essa abordagem consiste em uma decomposição do problema por meio de uma definição de papéis com suas respectivas atribuições e hierarquia. A modelagem de estruturas organizacionais pode ser uma tarefa complicada exigindo iterações incrementais até que o modelo convirja de modo a solucionar o problema proposto e superar possíveis questões de performance introduzidas pela ineficiência da estrutura organizacional (Weiss, 1999). Contract Net Contract net é um protocolo de coordenação para agentes cooperativos. Esse mecanismo é baseado na forma como funcionam os contratos de negócio. Esse protocolo resolve o seguinte problema: dada uma determinada tarefa, um agente gestor precisa definir o agente empreiteiro mais adequado para realizá-la. Esse mecanismo define um protocolo de interação por meio do qual o agente gestor pode oferecer as tarefas e os agentes empreiteiros podem assumí-las. Supondo uma comunidade de agentes com um agente gestor, um problema não resolvido e vários agentes capazes de resolver tal problema, o protocolo ocorre da seguinte maneira (Weiss, 1999): 28

42 1. O agente gestor anuncia que tem uma tarefa a ser realizada. 2. Recebe as respostas enviadas pelos agentes empreiteiros e as avalia. 3. Escolhe um agente para realizar a tarefa. 4. Recebe e avalia os resultados. Na perspectiva dos agentes empreiteiros o protocolo é visto da seguinte maneira: 1. O agente empreiteiro recebe um anúncio de uma tarefa a ser realizada. 2. Avalia se é capaz de resolver essa tarefa. 3. Envia uma oferta para o agente gestor. 4. Se a oferta for aceita, realiza a tarefa e retorna os resultados. Planejamento Multi-Agente O problema de coordenação entre os agentes pode ser visto como um problema de elaboração de um plano. Elaborar um plano consiste em decompor o problema em subproblemas, alocar esses subproblemas para os outros agentes, receber as soluções parciais dos problemas e sintetizá-las em um resultado final. A atividade planejar o trabalho conjunto dos agentes, por si só, é um problema que os agentes são capazes de resolver. O planejamento multi-agente pode ser feito de forma centralizada por meio de um agente que recebe os planos dos demais agentes, elimina as inconsistências e os conflitos, sintetiza um plano, e o distribuí de volta aos agentes. No planejamento multi-agente distribuído, os agentes enviam seus planos uns aos outros e realizam independentemente o trabalho de eliminar os conflitos e em seguida redistribuem seus planos, até que todos os planos dos agentes não possuam mais conflitos (Weiss, 1999). Negociação Negociação é um protocolo de interação para coordenar agentes com objetivos diferentes. Negociação é nome que se dá ao processo em que um ou mais agentes com objetivos diferentes tomam uma decisão conjunta, nesse processo os agentes envolvidos primeiramente informam seus posicionamentos e caso estes sejam conflitantes, os diversos agentes fazem concessões ou procuram soluções alternativas até que se chegue a um acordo. Uma negociação deve estabelecer uma linguagem por meio da qual os agentes possam conversar, um protocolo de interação para coordenar a troca de mensagens, e um algoritmo de decisão. O algoritmo de decisão é responsável por determinar as posições do agente, as concessões que este pode fazer, as soluções alternativas, e o critério utilizado para aceitar um acordo. Idealmente uma negociação deve atingir os seguintes objetivos (Weiss, 1999): 29

43 Eficiência: Agentes não devem desperdiçar recursos para chegar a um acordo. Simplicidade: O mecanismo de negociação deve gastar pouco poder computacional e onerar pouco tráfego na rede. Estabilidade: Os agentes não devem ter incentivos a descumprir as estratégias acordadas. Distribuição: O mecanismo não deve requerer que a decisão seja tomada de forma centralizada. Simetria: O mecanismo não deve ser tendencioso de forma a dar prioridade a um ou outro agente Java Agent DEvelopment (JADE) JADE é uma plataforma distribuída para desenvolvimento de agentes. Seu objetivo é fornecer funcionalidades de middleware independentes de domínio para facilitar a construção de aplicações que usem a abstração de agentes. A abstração de agentes proposta pela plataforma possui as seguintes caracterísicas: Os agentes são autônomos: cada agente possui sua própria thread de execução e é responsável pelo seu ciclo de vida. Os agentes são desacoplados: a comunicação entre os agentes se dá por meio da troca de mensagens, qualquer agente pode enviar ou receber mensagens de qualquer outro agente do sistema. A comunidade dos agentes é par-a-par (peer-to-peer): qualquer agente pode ser descoberto pelos demais agentes da plataforma, dessa forma todos os agentes podem se comunicar diretamente. Arquitetura A plataforma JADE é formada por um ou mais contêineres distribuídos e em cada contêiner reside um conjunto de agentes. Um desses contêineres é chamado de contêiner principal e representa toda a plataforma, os demais contêineres devem se associar ao contêiner principal. O contêiner principal é responsável pela tabela global de agentes, que armazena os registros de todos os agentes da plataforma, e pela tabela de contêineres, que armazena os registros de todos os contrêinres associados à plataforma e por hospedar dois agentes especiais da plataforma: AMS (Agent Management System) e o DF (Directory Facility). AMS: Agente responsável por gerenciar toda a plataforma incluindo o ciclo de vida dos agentes, além de manter o serviço de páginas brancas (white pages): serviço de descoberta dos agentes; a descoberta é feita por meio do identificador do agente (AID). Todo agente precisa se registrar junto ao AMS para obter seu AID (Agent ID). 30

44 DF: Esse agente implementa o serviço de páginas amarelas. Por meio desse serviço os agentes podem registrar uma descrição dos serviços que prestam para que estes possam ser descobertos pelos demais agentes. Além desses dois agentes cada contêiner JADE deve fornecer um serviço de transporte de mensagens ou MTS (Message Transport Service). Esse serviço faz parte da especificação da FIPA e é utilizado em todas as trocas de mensagens, sejam elas dentro da plataforma ou para outras plataformas. As trocas de mensagens são feitas por meio do protocolo MTP (Message Transport Protocol). Por meio desse padrão a plataforma JADE pode interoperar com outras plataformas (não JADE). Esse protocolo é padronizado pela FIPA e pode ser transportado por vários outros protocolos, dentre os diversos protocolos podemos citar HTTP e IIOP. Por padrão a plataforma JADE inicia o serviço de transporte de mensagens utilizando MTP sobre HTTP. Para comunicações internas à plataforma JADE é utilizado o protocolo proprietário IMTP (Internal Message Transport Protocol), esse protocolo é implementado sobre Java RMI (Remote Method Invocation) ou sockets TCP. Agentes JADE Um agente JADE é um componente sujeito ao ciclo de vida de agentes da plataforma e que possui um conjunto de comportamentos. Por meio dos comportamentos os agentes podem enviar mensagens, ler mensagens, interagir com o meio ou realizar atividades internas. Todo agente JADE é uma subclasse da classe abstrata jade.core.agent. Essa classe fornece vários métodos já implementados e alguns métodos que podem ser sobrescritos para customizar o ciclo de vida do agente. Dentre os métodos mais importantes podemos citar: setup: esse método é utilizado para realizar a inicialização do agente. dodelete: esse método é utilizado para desativar o agente. takedown: nesse método devem ser realizadas as operações de encerramento do agente (liberar recursos, etc). Após a execução do método setup o agente muda para o estado ativo. Nesse estado, o agente irá executar seus comportamentos até que todos tenham sido concluídos ou até que seja chamado o método dodelete. Um comportamento é uma subclasse da classe abstrata jade.core.behaviours.behaviour. Essa classe possui vários métodos utilitários já implementados e alguns métodos que devem ser sobrescritos. Dentre os métodos mais importantes dessa classe podemos citar: done: esse método retorna um valor booleano indicando se o comportamento já encerrou ou não. Quando um comportamento é encerrado, este é removido do conjunto de comportamentos do agente. 31

45 action: esse método é executado pelo agente enquanto o método done não retornar o valor booleano verdadeiro, o que indica que o comportamento foi encerrado. onstart: esse método é executado na inicialização do comportamento. Esse método é executado apenas uma vez e isso ocorre imediatamente antes da primeira chamada ao método action do comportamento. onend: esse método é chamado imediatamente após o método done retornar verdadeiro. É utilizado para realizar operações de limpeza e liberação de recursos. Um comportamento pode ser adicionado ao conjunto de comportamentos do agente durante a execução do método setup ou posteriormente por outro comportamento. Para adicionar um comportamento é utilizado o método addbehaviour da classe Agent que recebe como parâmetro o comportamento a ser adicioado. O agente alterna a invocação dos métodos action dos comportamentos até que todos tenham sido finalizados ou até o agente ser encerrado. Uma característica importante é que agente JADE é responsável por escalonar seus comportamentos. O escalonamento é feito por meio de um algoritmo roundrobin não preemptivo. Ou seja, quando o agente invoca o método action de um comportamento, só poderá invocar o método action do próximo comportamento da sequência após o término da invocação do comportamento anterior. Cada agente é executado em sua própria thread e todos os comportamentos são executados nessa mesma thread. A Figura 3.6 ilustra o ciclo de vida dos agentes JADE e as listagens 3.1 e 3.2 apresentam exemplos de um agente e de um comportamento respectivamente. O agente da Listagem 3.1 apenas adiciona o comportamento HelloBehaviour ao seu conjunto de comportamentos. O comportamento apresentado na Figura 3.2 escreve uma mensagem na saída padrão em dois passos: na primeira execução do método action escreve uma parte da frase e na segunda escreve o restante. Após a execução dos dois passos o comportamento é dado como concluído pela condição expressa no método done. Listagem 3.1: Exemplo de agente JADE (... ) public class HelloWorldAgent extends Agent { protected void setup ( ) { addbehaviour (new HelloBehaviour ( ) ) ; } Listagem 3.2: Exemplo de comportamento JADE (... ) public class HelloBehaviour extends Behaviour { 32

46 Figura 3.6: Ciclo de vida dos agentes JADE (adaptado de Bellifemine (2007)) private static final int STEP1 = 0; private static final int STEP2 = 1; private int step = public void action ( ) { switch ( step ) { case STEP1: System. out. print ( " Hello " ) ; step ++; break ; case STEP2: 33

47 } } System. out. println ( " World! " ) ; step ++; break public boolean done ( ) { return step > STEP2; } } Comportamentos A API da plataforma JADE possui alguns tipos pré definidos de comportamentos, todos eles são subclasses jade.core.behaviours.behaviour. Esses comportamentos pré-definidos vão desde comportamentos que definem padrões de execução até comportamentos compostos utilizados para compor comportamentos em comportamentos mais complexos. Nesta seção serão apresentados apenas aqueles que foram utilizados neste trabalho. Behavior: classe genérica de comportamento. Essa classe é utilizada para implementar comportamentos que se encerram sob determinada condição. Muitas vezes é implementado como um conjunto de passos que são executados em sequência e ao final o comportamento é encerrado. A classe abstrata que o representa é jade.core.behaviours.behaviour. A Listagem 3.2 apresenta um exemplo de implementação utilizando essa superclasse. CyclicBehaviour: essa classe abstrata é uma subclasse de Behaviour com o método done sobrescrito para retornar sempre falso. É utilizado para comportamentos que se repetem indefinidamente enquanto o agente estiver em execução. É representado pela classe jade.core.behaviours.cyclicbehaviour. OneShotBehaviour: essa classe abstrata é uma subclasse de Behaviour com o método done sobrescrito para retornar sempre verdadeiro. É utilizado para implementar comportamentos que executam uma única vez e terminam. É representado pela classe jade.core.behaviours.oneshotbehaviour. Threaded Behaviours: devido ao caráter não preemptivo do escalonador de comportamentos dos agentes JADE o agente pode ficar congelado caso algum comportamento execute alguma operação muito demorada ou fique em espera por longos períodos. Esse tipo de situação pode ser resolvido lançando uma thread java diretamente do método action de um comportamento; entretanto a plataforma Jade provê um meio mais elegante de lançar um comportamento numa thread dedicada: através da classe jade.core.behaviours.threadedbehaviourfactory. 34

48 Essa classe encapsula o comportamento em uma thread através do método wrap que retorna um objeto do tipo Behaviour. Esse objeto lança a thread do comportamento assim que o comportamento é adicionado ao agente por meio do método addbehaviour. A Listagem 3.3 apresenta um exemplo de uso dessa classe; no exemplo apresentado, um comportamento lança outro comportamento em uma thread dedicada. Outra particularidade desse exemplo é o uso do atributo myagent da superclasse Behaviour. Esse atributo fornece uma referência ao agente em que o comportamento foi adicionado. Listagem 3.3: Exemplo de Threaded Behaviour (... ) public class FooBehaviour extends OneShotBehaviour { public void action ( ) { ThreadedBehaviourFactory t b f = new ThreadedBehaviourFactory ( ) ; Behaviour threadedbehaviour = t b f. wrap (new HelloBehaviour ( ) ) ; super. myagent. addbehaviour ( threadedbehaviour ) ; } Compartilhamento de informações Eventualmente pode ser necessário compartilhar informações entre os diversos comportamentos de um agente. Isso pode ser feito utilizando a classe DataStore. Todo comportamento possui um método getdatastore que retorna um objeto do tipo DataStore. Para que dois comportamentos possam compartilhar informações, basta que os dois compartilhem a mesma instância do objeto DataStore; esse objeto funciona como uma área de memória compartilhada. O objeto DataStore é um mapa onde podem ser adicionados objetos indexados por um objeto chave. As Listagens 3.4, 3.5 e 3.6 apresentam um exemplo de como o DataStore pode ser utilizado para compartilhar informações. Listagem 3.4: Compartilhando a referência do DataStore (... ) public class HelloWorldAgent extends Agent protected void setup ( ) { OneBehaviour one = new OneBehaviour ( ) ; OtherBehaviour other = new OtherBehaviour ( ) ; //Compartilhando a mesma instância one. setdatastore ( other. getdatastore ( ) ) ; addbehaviour ( one ) ; addbehaviour ( other ) ; } 35

49 } Listagem 3.5: Adicionando informações ao DataStore (... ) public class OneBehaviour extends OneShotBehaviour { public void action ( ) { this. getdatastore ( ). put ( " message ", " Shared data! " ) ; } Listagem 3.6: Recuperando informações do DataStore (... ) public class OtherBehaviour extends Behaviour { } private boolean done = false public void action ( ) { String msg = ( String ) getdatastore ( ). get ( " message " ) ; i f (msg!= null ) { System. out. println (msg ) ; done = true ; } public boolean done ( ) { return done ; } Troca de mensagens A troca de mensagens entre os agentes JADE se dá de maneira assíncrona. Cada agente possui uma fila de mensagens; sempre que uma mensagem chega, o agente é notificado; entretanto, o agente pode checar a chegada de mensagens ativamente também. As mensagens trocadas entre os agentes JADE seguem o padrão de mensagens definidos pela FIPA ACL. Além do conteúdo a mensagem carrega várias outras informações, dentre as quais podemos citar: sender: remetente receivers: os detinatários (podem ser vários). 36

50 performative: O ato de fala (Seção 3.1.4) language: a linguagem utilizada para expressar o conteúdo ontology: a ontologia utilizada para definir a semântica do conteúdo conversation-id: id de conversação identifica as mensagens de uma mesma sequência de troca de mensagens. Para enviar uma mensagem o comportamento utiliza o método send disponível no atributo myagent da superclasse Behaviour. Esse método recebe como parâmetro uma mensagem FIPA ACL representada pela classe jade.lang.acl-.aclmessage. A Listagem 3.7 apresenta um exemplo de preenchimento e envio de uma mensagem. No exemplo apresentado o comportamento envia uma mensagem e aguarda uma resposta. Para que o comportamento não bloqueie o agente ou desperdice recursos checando a chegada da resposta, foi utilizado o método block. Esse método fará com que o método action só seja invocado novamente quando chegar uma mensagem para o agente. Outro ponto interessante nesse código é o uso da classe jade.lang.acl.messagetemplate que é utilizada para criar filtros simples para o recebimento das mensagens; no exemplo abaixo, o método receive só vai retornar as mensagens que satisfizerem a condição do filtro, que nesse caso é possuir um determinado id de conversação. Listagem 3.7: Exemplo de troca de mensagens (... ) public class SendMessageBehaviour extends Behaviour { private s t a t i c final int SENDING_MESSAGE = 0; private s t a t i c final int WAITING_REPLY = 1; private int step = 0; private String conversationid = null public void action ( ) { / Codec para linguagem fipa s l / SLCodec f i p a s l = new SLCodec ( ) ; / registrando linguagem e ontologia / myagent. getcontentmanager ( ). registerontology ( OntologiaExemploOntology. getinstance ( ) ) ; myagent. getcontentmanager ( ). registerlanguage ( f i p a s l ) ; switch ( step ) { case SENDING_MESSAGE: / O contrutor recebe uma constante representando o campo performative. / ACLMessage message = new ACLMessage ( ACLMessage.INFORM) ; / Criando uma r e f e r e n c i a ao id do agente destinatário. / AID receiver = new AID( " HelloWorldAgent ", AID.ISLOCALNAME) ; message. addreceiver ( receiver ) ; / preenchendolinguagem e o n t o l o g i a usadas na mensagem / 37

51 message. setlanguage ( f i p a s l. getname ( ) ) ; message. setontology ( OntologiaExemploOntology.ONTOLOGY_NAME) ; / Criando conteúdo da mensagem / Pessoa pessoa = new Pessoa ( ) ; pessoa. setnome ( " João " ) ; pessoa. setendereco ( " Endereço do João " ) ; SofreuAcidente acidente = new SofreuAcidente ( ) ; acidente. setvitima ( pessoa ) ; acidente. setcausa ( " atropelamento " ) ; try { myagent. getcontentmanager ( ). f i l l C o n t e n t ( message, acidente ) ; } catch ( CodecException e ) { //tratar erro } catch ( OntologyException e ) { //tratar erro } myagent. send ( message ) ; conversationid = message. getconversationid ( ) ; step ++; break ; case WAITING_REPLY: ACLMessage reply = myagent. receive ( MessageTemplate. MatchConversationId ( conversationid ) ) ; / Se a resposta não chegar, o comportamento f i c a r á bloqueado até que s eja informado sobre a chegada de alguma mensagem. / i f ( reply == null ) { this. block ( ) ; return ; } SofreuAcidente outroacidente = null ; try { outroacidente = ( SofreuAcidente ) myagent. getcontentmanager ( ). extractcontent ( reply ) ; System. out. println ( outroacidente. getcausa ( ) ) ; } catch ( UngroundedException e ) { //tratar erro } catch ( CodecException e ) { //tratar erro } catch ( OntologyException e ) { //tratar erro } } step ++; break ; public boolean done ( ) { return step > WAITING_REPLY; 38

52 } } Linguagens de Conteúdo e Ontologias Apesar de ser possível enviar qualquer objetou ou texto como conteúdo da mensagem, o mais indicado é que sejam enviadas mensagens aderentes ao padrão da FIPA ACL. Essa linguagem provê uma maneira de expressar informações por meio de sentenças de acordo com as características semânticas da mensagem. A FIPA ACL define que uma mensagem é formada pela combinação de predicados e termos: Termos (terms): um termo pode ser tanto um elemento concreto quanto um elemento abstrato que faz parte do universo dos agentes. Os termos podem ser classificados em conceitos e primitivos. Primitivos (primitives): são elementos mais básicos tais como inteiros e strings. Conceitos (concepts): são entidades compostas por primitivos e que representam uma informação mais complexa. Em geral são enviados dentro de ações de agentes ou predicados pois não possuem semântica intrínseca. Exemplo de um conceito chamado Context e que possui um atributo chamado AlarmCause cujo valor é Fall representado pela linguagem de conteúdo FIPA-SL: (Context :AlarmCause Fall") Ações de agentes (agent actions): conceitos que representam ações que podem ser desempenhadas por agentes. Normalmente são utilizados em mensagens que utilizam o ato de fala REQUEST. Agregações (aggregates): representam agregações de termos, por exemplo uma lista. Identifying referential expressions (IRE) : Expressões que identificam um termo ou vários termos que satisfazem um predicado. Variáveis (variables): expressões usadas em consultas utilizadas para denotar termos cujo valor não é conhecido. predicados (predicates): expressões que carregam alguma informação sobre o universo dos agentes. Um predicado pode ser verdadeiro ou falso. Um predicado pode envolver conceitos. O exemplo abaixo apresenta um predicado que carrega o objeto Emergency representado pela linguagem de conteúdo FIPA-SL. (EmergencySent (Emergency :emergencydata (EmergencyRelatedData :context (Context :AlarmCause Fall")))) Nesse exemplo, o predicado está afirmando que uma emergência foi enviada e contém o conceito que representa a emergência que foi enviada. 39

53 Para definir a semântica dos predicados e termos utilizados na aplicação é necessário definir uma ontologia. Essa ontologia deve ser informada na mensagem para que o agente receptor saiba a que ontologia se referem os termos e predicados utilizados na mensagem. Para escrever a mensagem é utilizada alguma linguagem de conteúdo. A linguagem utilizada para codificar o conteúdo da mensagem é informada pela própria mensagem. Nos exemplos acima foi utilizada a FIPA-SL. A plataforma JADE oferece mecanismos para definição da ontologia por meio de classes Java e codificação e decodificação de mensagens representadas por objetos Java. A ontologia do sistema pode ser definida por meio de classes que representam as entidades do sistema e essas classes podem ser codificadas utilizando um codificador correspondente à linguagem de conteúdo escolhida e enviadas para outro agente por meio de uma mensagem. O agente receptor por sua vez, conhecendo a linguagem de codificação e a ontologia informadas na mensagem, é capaz de decodificar a mensagem e transformá-la de volta em objetos. A seguir será apresentado como construir uma ontologia e como codificar e decodificar uma mensagem. Ontologias JADE A ontologia é definida por um conjunto de classes representando as entidades da ontologia (termos e predicados) e uma classe responsável por definir as restrições da ontologia. Os termos primitivos são representados pelos tipos da linguagem java: int, String, float, etc. As entidades da ontologia são definidas por meio de classes com as seguintes propriedades: Seus atributos são encapsulados e acessíveis via método. Esses métodos seguem o padrão de nomenclatura Java ( get e set ). Possuem um contrutor público e sem parâmetros. Essas classes implementam a interface de marcação correspondente ao tipo de termo que representa. Entre essas interfaces podemos citar: jade.content-.predicate, jade.content.concept, jade.content.agentaction. A Listagem 3.8 mostra um exemplo de uma classe que implementa um conceito e a Listagem 3.9 apresenta um exemplo de uma classe que implementa um predicado. Listagem 3.8: Exemplo de conceito JADE (... ) public class Pessoa implements Concept { private String nome ; public void setnome ( String value ) { this. nome = value ; } 40

54 public String getnome ( ) { return this. nome ; } private String endereco ; public void setendereco ( String value ) { this. endereco = value ; } public String getendereco ( ) { return this. endereco ; } } Listagem 3.9: Exemplo de predicado JADE (... ) public class SofreuAcidente implements Predicate { } private String causa ; public void setcausa ( String value ) { this. causa = value ; } public String getcausa ( ) { return this. causa ; } private Pessoa vitima = null ; public Pessoa getvitima ( ) { return vitima ; } public void setvitima ( Pessoa p ) { vitima = p ; } A classe que define a ontologia é implementada como sublcasse da classe abstrata jade.content..ontology e em geral é implementada utilizando o padrão de projeto singleton. No construtor da classe que define a ontologia, são invocados vários métodos definidos na superclasse Ontology responsáveis por construir a estrutura da ontologia. Nessa estrutura são definidas as classes que representam os predicados e os termos (conceitos, ações de agentes, etc.), a forma como essas classes são compostas, os campos que compõem cada uma dessas classes, e as restrições dos atributos (unicidade, obrigatoriedade, etc). A Listagem 3.10 apresenta um exemplo de implementação de uma ontologia. Essa classe exemplo e as classes apresentadas anteriormente nas Listagens 3.8 e 3.9 foram geradas utilizando a ferramenta Protégé, um editor de ontologias gra- 41

55 tuito e de código aberto, e (Protégé, 2009) e o plug-in para essa mesma ferramenta chamado Ontology Bean Generator (Aart, 2009). Por meio dessa ferramenta a ontologia pode ser toda desenhada e o trabalho de implementar as classes correspondentes a essa ontologia é delegado ao plug-in gerador. Listagem 3.10: Exemplo de ontologia JADE (... ) public class OntologiaExemploOntology extends jade. content. onto. Ontology { public s t a t i c final String ONTOLOGY_NAME = " OntologiaExemplo " ; private static R e f l e c t i v e I n t r o s p e c t o r introspect = new R e f l e c t i v e I n t r o s p e c t o r ( ) ; private s t a t i c Ontology theinstance = new OntologiaExemploOntology ( ) ; public static Ontology getinstance ( ) { return theinstance ; } public s t a t i c final String SOFREUACIDENTE_VITIMA = " vitima " ; public s t a t i c final String SOFREUACIDENTE_CAUSA = " causa " ; public s t a t i c final String SOFREUACIDENTE = " SofreuAcidente " ; public s t a t i c final String PESSOA_ENDERECO = " endereco " ; public s t a t i c final String PESSOA_NOME = " nome" ; public static final String PESSOA = " Pessoa " ; private OntologiaExemploOntology ( ) { super (ONTOLOGY_NAME, BasicOntology. getinstance ( ) ) ; try { // adding Concept ( s ) ConceptSchema pessoaschema = new ConceptSchema (PESSOA) ; add ( pessoaschema, br. c i c. jade. ontologia. Pessoa. class ) ; // adding Predicate ( s ) PredicateSchema sofreuacidenteschema = new PredicateSchema ( SOFREUACIDENTE) ; add ( sofreuacidenteschema, br. c i c. jade. ontologia. SofreuAcidente. class ) ; // adding f i e l d s pessoaschema. add (PESSOA_NOME, ( TermSchema) getschema ( BasicOntology. STRING), ObjectSchema. OPTIONAL) ; pessoaschema. add (PESSOA_ENDERECO, ( TermSchema) getschema ( BasicOntology. STRING), ObjectSchema. OPTIONAL) ; sofreuacidenteschema. add (SOFREUACIDENTE_CAUSA, ( TermSchema) getschema ( BasicOntology. STRING), ObjectSchema. OPTIONAL) ; sofreuacidenteschema. add (SOFREUACIDENTE_VITIMA, pessoaschema, ObjectSchema.MANDATORY) ; } } catch ( java. lang. Exception e ) { e. printstacktrace ( ) ; } 42

56 } Por meio da composição desses objetos é possível criar mensagens aderentes ao padrão FIPA-ACL. Utilizando as classes apresentadas como exemplo nesta seção podemos compor uma mensagem instanciando um objeto do tipo SofreuAcidente e associando um objeto do tipo Pessoa no seu campo vitima. Porém, para que essa mensagem seja transmitida a outro agente é preciso converter esses objetos e enviá-los dentro de uma mensagem FIPA-ACL. Isso pode ser feito utilizando serialização de objetos Java, convertendo os objetos para XML ou qualquer outro formato que o outro agente possa converter de volta para objetos. Entretanto, a FIPA-ACL sugere o uso de uma codificação por meio de strings(cadeias de caracteres) que, além de ser independente de plataforma, facilita a visualização e o entendimento das mensagens por humanos. Essa linguagem é chamada FIPA-SL. A seguir um exemplo da representação do exemplo anterior codificado em FIPA-SL: ((SofreuAcidente atropelamento (Pessoa :nome "João":endereco- "endereço do João"))) Linguagens de Conteúdo As linguagens de conteúdo fornecem formas de representação para o conteúdo mensagem. A plataforma JADE oferece dois codecs (componente para codificação e decodificação) para transformar as mensagens: SLCodec: representado pela classe jade.content..lang.sl.slcodec, codifica os objetos definidos por uma ontologia em strings no formato especificado pela FIPA-SL e decodifica uma mensagem nesse formato de volta para objetos java. LEAPCodec: representado pela classe jade.content..lang.leap.leap- Codec, codifica os objetos definidos por uma ontologia em um formato de bytes binários. É indicado para uso em ambientes com recursos computacionais limitados. Para realizar a codificação do conteúdo de uma mensagem é necessário utilizar a classe jade.content..contentmanager. Por meio dessa classe, o agente pode registrar as ontologias e as linguagens de conteúdo que utiliza bem como invocar métodos para a codificação das mensagens representadas por objetos definidos pelas classes da ontologia. Todo agente possui uma instância desse objeto que pode ser obtida a partir do método getcontentmanager implementando pela superclasse jade.core.agent. O agente pode registrar as ontologias e as linguagens de conteúdo que irá utilizar por meio dos métodos registerontology e registerlanguage respectivamente. Um agente pode registrar múltiplas linguagens de conteúdo e múltiplas ontologias. Para definir qual linguagem de conteúdo e ontologia será utilizada para realizar as conversões das mensagens são utilizados os campos language e ontology da mensagem. O agente que codifica ou decodifica a mensagem deve ter registrado previamente em sua instância do objeto ContentManager a ontologia e o codec referenciados 43

57 pela mensagem. As operações de codificação e decodificação são realizadas pelos seguintes métodos da classe ContentManager: fillcontent: converte de objeto para a linguagem de conteúdo escolhida. Recebe como parâmetro uma mensagem com o nome do codec e da ontologia preenchidos nos campos language e ontology respectivamente e o objeto que representa a mensagem que se deseja enviar. Esse método preenche o campo content da mensagem passada como parâmetro. extractcontent: converte da linguagem de conteúdo para objeto. Recebe como parâmetro a mensagem que terá o conteúdo convertido e retorna um objeto do tipo ContentElement que pode sofrer coerção para os tipos jade-.content..predicate, jade.content..agentaction ou jade.content..ire. A Listagem 3.7 apresenta um exemplo de um agente que envia uma mensagem contendo o predicado SofreuAcidente e espera como resposta a mesma mensagem. A mensagem é codificada utilizando a classe SLCodec e a ontologia utilizada é a OntologiaExemplo. 3.2 Arquitetura Orientada a Serviços (SOA) Nesta seção serão abordados os principais conceitos relacionados à arquitetura orientada a serviços. Nessa arquitetura as aplicações são construídas por meio da combinação de um conjunto de serviços. Esses serviços são desacoplados dos consumidores por meio de suas interfaces permitindo maior flexibilidade na construção das aplicações. A tecnologia escolhida para implementação, publicação e utilização dos serviços foi a plataforma OSGi. Essa é uma plataforma não distribuída que apresenta um modelo de componentes em que o modelo de interação entre esses componentes foi projetado por meio de serviços. A primeira parte apresenta o conceito de serviços utilizados nesse trabalho, como se dá o ciclo de vida de publicação e consumo desses serviços e alguns conceitos auxiliares relevantes para este trabalho. A seguir será apresentada a plataforma OSGi detalhando a implementação do ciclo de vida dos serviços nessa plataforma Arquitetura orientada a serviços O componente básico desse estilo arquitetural é o serviço. Um serviço é um componente que encapsula uma funcionalidade de negócio e por meio de uma interface que pode ser publicada, descoberta e utilizada de maneria pouco acoplada (Papazoglou, 2003). A interface do serviço descreve as capacidades que o serviço suporta. As capacidades representam as funções de negócio que o serviço implementa. Essas capacidades são chamadas operações quando implementadas por um Web-Service, e são chamadas de métodos quando são implementadas por um componente (Erl, 2008). 44

58 A arquitetura orientada a serviços define três papéis que interagem por meio de operações de publicação, descoberta e ligação. A publicação consiste em disponibilizar a interface publicamente para que os demais papéis possam saber da existência do serviço e de sua especificação. A descoberta do serviço consiste em buscar definições de serviços em um repositório compartilhado que encapsule a funcionalidade desejada. A ligação consiste em estabelecer uma interação direta entre o consumidor do serviço e sua real implementação por meio de sua interface. Os papéis definidos por essa arquitetura são (Papazoglou, 2003): Provedor do serviço: implementa um componente de software acessível por meio de uma interface bem definida É responsável por publicar a interface desse serviço no catálogo de serviços (registry) e por executar as capacidades disponibilizadas nessa interface. Catálogo de serviços (registry): responsável por manter a lista de serviços disponíveis. Esse catálogo deve permitir que os provedores de serviço publiquem as interfaces de seus serviços e as informações necessárias para invocar o serviço. Além disso, esse catálogo deve permitir que os consumidores de serviço façam buscas em seu catálogo e consigam recuperar as informações necessárias para fazer a ligação direta com o provedor de serviços. Consumidor de serviço: esse papel realiza buscas no catálogo de serviços e obtém as informações necessárias para realizar a operação de ligação e invocar alguma capacidade definida na interface do serviço. A Figura 3.7 apresenta os papéis e as operações realizadas entre eles. Figura 3.7: Arquitetura Orientada a Serviços Nessa arquitetura as funcionalidades de negócio são expostas por meio de serviços e recombinadas de diferentes formas para resolver diferentes problemas de negócio. Essas funcionalidades de negócio podem ser necessárias para diferentes processos de negócio permitindo que um serviço previamente implementado seja utilizado (Erl, 2008). Granularidade Em arquitetura orientada a serviços, o termo granularidade é utilizado para descrever o nível de detalhamento do serviço e de suas capacidades. 45

59 A granularidade de um serviço é determinada pela abrangência da funcionalidade de negócio que encapsula. Um serviço é dito de granularidade grossa quando implementa funcionalidades de negócio de alto nível, e possui granularidade fina quando implementa funcionalidades menos representativas no negócio, ou seja, funcionalidades de mais baixo nível. A granularidade de capacidades se refere ao nível de detalhe das capacidades providas na interface de um serviço. A granularidade de uma capacidade é classificada em fina e grossa de maneira análoga aos serviços (Erl, 2008). Composição de serviços Serviços podem ser compostos para criar serviços de mais alto nível, ou seja, serviços de granularidade grossa. Essa atividade consiste em criar um componente que desempenha um duplo papel na arquitetura: esse componente consome serviços que utiliza para implementar um serviço de mais alto nível e publica esse serviço agindo como um provedor de serviços (Papazoglou et al., 2007). Orquestração e Coreografia Nesta arquitetura os processos de negócio são implementados por meio da combinação de serviços em uma ordem pré-determinada. A atividade invocar esses serviços em uma determinada ordem de acordo com a lógica do processo de negócio é chamado de orquestração (Papazoglou et al., 2007). Essa atividade pode requerer que a invocação ou não de um serviço seja realizada por meio de um fluxo de decisão baseado no resultado de uma invocação anterior, por exemplo. A definição das interações entre processos de negócio orquestrados por diferentes participantes (organizações ou empresas distintas) é chamado de coreografia (Papazoglou et al., 2007) Open Services Gateway Initiative (OSGi) OSGi é um sistema de componentes dinâmicos para Java. Essa plataforma permite a instalação, remoção e atualização de componentes sem precisar reiniciar a aplicação (OSGi, 2009a). Para diminuir o acoplamento e permitir que esses componentes se comportem de maneira dinâmica, a plataforma foi projetada utilizando uma arquitetura orientada a serviços. Dessa forma os componentes podem publicar e descobrir serviços prestados por outros componentes por intermédio da plataforma em tempo de execução. Esses componentes são chamados de bundles. As funcionalidades da plataforma podem ser divididas nas seguintes camadas: Ambiente de execução: o ambiente de execução é determinado pelo profile java utilizada, por exemplo J2SE e J2ME. Camada de módulos: essa camada define as políticas de carregamento de classes. A especificação do OSGi possui uma definição rígida de como deve funcionar esse classloader permitindo que as classes necessárias a um módulo possam ser oriundas de diversos classpaths. Esse classloader permite que os diversos bundles compartilhem classes. 46

60 Camada de ciclo de vida: camada que gerencia o ciclo de vida dos bundles. Essa camada controla a instalação, remoção, inicialização, atualização e o encerramento dinâmico dos bundles. Esse ciclo de vida será abordado nesta seção. Camada de serviços: camada gerencia o service registry da plataforma. O modelo de serviços propostos pelo OSGi permite que os diversos bundles interajam de maneira não acoplada por meio de invocação de serviços, esse desacoplamento corrobora com o caráter dinâmico da plataforma. Essa camada participa na publicação, busca e ligação dos serviços. Camada de segurança: essa camada esta implementada ao longo das demais camadas. Seu modelo é baseado no modelo de segurança Java 2. Bundle Os bundles são a unidade de modularização do OSGi; suas principais características são as seguintes: São a única forma de disponibilizar aplicações Java na plataforma OSGi e são compostos por classes java e recursos (imagens, html, etc.). Podem importar ou exportar pacotes para os demais bundles. Podem publicar serviços na plataforma para que sejam consumidos por outros bundles e vice-versa. São disponibilizados por meio de arquivo JAR. Esse arquivo contém as classes javas e os recursos e um arquivo de configuração chamado MANIFEST.MF. O arquivo MANIFEST.MF descreve quais pacotes o bundle requer e quais provê para a plataforma OSGi além dos parâmetros necessários para inicialização e instalação do bundle. Um diretório OSGI-OPT utilizado para armazenar documentação adicional. Esse diretório pode ser utilizado para disponibilizar o código fonte do bundle, por exemplo. Esse diretório pode ser removido pela plataforma para diminuir o uso de espaço em disco. Ao ser ativado o bundle passa a disponibilizar serviços e/ou pacotes para os demais bundles da plataforma. A Figura 3.8 apresenta estrutura de diretórios de um arquivo JAR representando um bundle. A Listagem 3.11 apresenta um exemplo de um arquivo MANIFEST.MF. Esse arquivo possui as seguintes diretivas: Bundle-ManifestVersion: indica a versão da especificação OSGi para o arquivo MANIFEST.MF. Bundle-Name: nome curto utilizado para nomear o bundle. Deve ser um nome human-readable (que pode ser lido por pessoas) e pode conter espaços. 47

61 Bundle-Activator: Nome completo qualificado da classe que implementa a interface BundleActivator, utilizada no ciclo de vida do bundle. Bundle-SymbolicName: juntamente com a versão do bundle representa um identificador único dentro da plataforma. Bundle-Version: versão do bundle. Import-Package: pacotes requeridos pelo bundle que devem estar disponíveis na plataforma. Opcionalmente pode ser informada a versão que se deseja importar. Export-Package: pacotes do bundle que serão disponibilizados na plataforma. Listagem 3.11: Exemplo MANIFEST.MF Bundle ManifestVersion : 2 Bundle Name: ContextBus Bundle Activator : br. unb. c i c. aal. bundle. StartService Bundle SymbolicName : ContextBus Bundle Version : Import Package : org. osgi. framework ; version=" ", br. unb. c i c. aal. ontology Export Package : br. unb. c i c. aal. contextbus Figura 3.8: Estrutura de diretórios de um bundle Ciclo de vida dos bundles O ciclo de vida dos bundles é regido pela camada de ciclo de vida e é composto pelos seguintes estados: Installed: o bundle assume esse estado após ser instalado na plataforma. Um bundle só pode ser instalado por outro bundle ou de alguma maneira específica de implementação. A instalação de um bundle é persistente e atômica: 48

62 Persistente: deve permanecer instalado nas diversas inicializações da plataforma OSGi e da máquina virtual Java. Atômica: a plataforma deve voltar ao estado anterior à tentativa de instalação caso ocorra alguma falha. Após a instalação do bundle é criado um objeto do tipo Bundle que o representa na plataforma, esse objeto é utilizado para realizar as operações de mudança de estado do bundle (start, stop, update/refresh e uninstall). Resolved: o bundle transita para esse estado ao ter o método update invocado no bundle que o representa na camada de ciclo de vida. A transição para esse estado é concluída quando as dependências necessárias são resolvidas com sucesso. A resolução de dependências incluem resolução de dependências de código nativo e de bundles requeridos e pacotes importados pela diretiva Import-Package. Starting: Após ter suas dependências resolvidas o bundle pode transitar para esse estado por meio da invocação do método start. A ordem em que os bundles são inciados pode ser definida por meio do serviço start level. Esse serviço define níveis de funcionamento para a plataforma, o nível de funcionamento da plataforma é chamado start level ativo. O start level é um valor numérico crescente onde os serviços associados aos menores valores são iniciados antes dos serviços de maior valor. Não se pode determinar a ordem em que serão iniciados múltiplos bundles associados a um mesmo start level. Active: a ativação de um bundle consiste em executar o método start da classe do bundle que implementa a interface BundleActivator. Essa classe é especificada no arquivo MANIFEST.MF por meio da diretiva Bundle-Activator. Essa diretiva é opcional; caso não seja encontrada, o bundle transita para o estado Active diretamente; caso contrário, a transição é finalizada após o retorno do método start do BundleActivator. A Listagem 3.11 apresenta um exemplo de uso dessa diretiva. Um bundle pode ser configurado para iniciar de maneira tardia; essa inicialização é chamada lazy activation. Caso esteja configurado para executar inicialização tardia o bundle transita para o estado Active mesmo sem ter o método start do seu BundleActivator invocado; nesse caso o método start será invocado quando a primeira classe desse bundle precisar ser carregada pelo OSGi. Stopping: ao ser invocado o método stop do objeto Bundle, o bundle transita para esse estado. Caso o bundle tenha sido ativado por meio do seu BundleActivator, o método stop dessa mesma interface será invocado para desalocar os recursos alocados no método start. Enquanto está neste estado, o bundle continua fornecendo seus pacotes exportados aos bundles que os utilizam. Uninstalled: o bundle transita para esse estado após a invocação do seu método uninstall. Ao ser desinstalado o bundle deixa de prover todos os recursos à plataforma. 49

63 O método update de um objeto Bundle pode ser invocado a qualquer momento e esse método irá reinstalar o bundle no sistema. Após concluída a instalação a plataforma irá transitar o bundle de volta ao estado em que estava antes da invocação do método update. A Figura 3.9 apresenta as mudanças de estados de um bundle e os comandos que desencadeiam cada mudança de estado. Figura 3.9: Ciclo de vida de um bundle (OSGi, 2009b) Exportação e importação de pacotes A importação e a exportação de pacotes são feita pelas diretivas Import-Package e Export-Package respectivamente (Listagem 3.11). Caso alguma dependência não seja resolvida o bundle permanecerá no estado Installed. Essas diretivas são opcionais. Bunlde Activator A classe que implementa essa interface é invocada durante a inicialização de um bundle. Para que essa classe seja encontrada o bundle precisa informar no arquivo MANIFEST.MF o nome completo qualificado dessa classe por meio da diretiva Bundle-Activator. Essa diretiva é opcional. O BundleActivator possui dois métodos: start: utilizado para registrar serviços, lançar threads e alocar recursos do sistema. stop: utilizado para encerrar as threads lançadas e liberar os recursos do sistema utilizado. 50

64 Ambos os métodos recebem uma referência do tipo org.osgi.framework.- BundleContext. Essa interface disponibiliza vários métodos que podem ser utilizados para interagir com a plataforma. Publicação, descoberta e ligação de serviços As operações relacionadas a serviços são realizadas programaticamente. Um serviço em OSGi é composto por uma interface Java, uma implementação e um conjunto de metadados opcionais para descrever o serviço. Para registrar ou buscar um serviço é preciso obter uma instância de um objeto do tipo org.osgi.framework.bundlecontext. Essa interface disponibiliza métodos para registrar, buscar e ligar métodos. Dentre os diversos métodos providos os seguintes são relevantes para esse trabalho: registerservice: este método é utilizado para registrar os serviços na plataforma OSGi (publish). Esse método recebe como parâmetro o nome da interface para o serviço, uma implementação para o serviço, e um objeto do tipo java.util.dictionary contendo os metadados associados ao serviço. Geralmente os serviços providos por um bundle são registrados durante a execução do método start de seu BundleActivator. getservicereference: este método é utilizado para realizar a busca de um serviço (discover), recebe como parâmetro o nome da interface do serviço e retornar um objeto do tipo org.osgi.framework.servicereference. getservice: este serviço é utilizado para fazer a ligação do serviço (bind). A ligação do serviço consiste em obter uma referência à uma instância do serviço. Esse método recebe como parâmetro um objeto do tipo org.osgi.- framework.servicereference e retorna um objeto genérico java.lang-.object. Esse objeto pode sofrer coerção para o tipo da interface do serviço que representa. As Listagens 3.12, 3.13 apresentam exemplos de uso dos métodos apresentados. A Listagem 3.12 apresenta o BundleActivator de um bundle que publica um serviço definido pela interface br.unb.cic.msg.service.messageservice. A Listagem 3.13 apresenta a implementação desse serviço. Nessa implementação é feita a descoberta e o bind de um serviço representado pela interface br.unb.cic.ui.service.uiservice disponibilizado por outro bundle. A Listagem 3.14 apresenta o arquivo MANIFEST.MF do bundle apresentado. Listagem 3.12: Exemplo de publicação de serviço (... ) public class A c t i v a t o r implements BundleActivator { public void s t a r t ( BundleContext context ) throws Exception { context. r e g i s t e r S e r v i c e ( MessageService. class. getname ( ), new MessageServiceImpl ( context ), null ) ; } 51

65 public void stop ( BundleContext c o n t e x t ) throws Exception { } } Listagem 3.13: Exemplo de descoberta de serviço public class MessageServiceImpl implements MessageService { private BundleContext context = null ; public MessageServiceImpl ( BundleContext context ) { this. context = context ; } public void showguimessage ( String msg) { ServiceReference r e f = context. getservicereference ( UIService. class. getname ( ) ) ; UIService uiservice = ( UIService ) context. getservice ( r e f ) ; uiservice. showmessage (msg ) ; context. ungetservice ( r e f ) ; } Listagem 3.14: Exemplo de um MANIFEST.MF Bundle ManifestVersion : 2 Bundle Name: HelloWorldServiceBundle Bundle SymbolicName : HelloWorldServiceBundle Bundle Version : Bundle Activator : br. unb. c i c. osgi. Activator Import Package : org. osgi. framework ; version=" ", br. unb. c i c. ui. service Export Package : br. unb. c i c. msg. service 3.3 BMPN (Business Process Modeling Notation) Nesta seção serão apresentados brevemente alguns dos símbolos da notação BPM utilizados neste trabalho. A apresentação dos símbolos se restringe à sintaxe de cada um Símbolos utilizados Os símbolos da notação BPM utilizados neste trabalho são (OMG, 2009): Gateways: utilizados para realizar desvios no fluxo de atividades. Atividades: representam as atividades do fluxo. Eventos: representam a ocorrência de eventos no decorrer do fluxo. Pools: representam delimitações de escopo de um fluxo de atividades. Por exemplo, podem delimitar organizações, participantes, departamentos de uma empresa etc. 52

66 Setas: utilizadas para ligar as atividades do fluxo ou para estabelecer comunicação com fluxos de outro pool. Gateways Esse símbolo é utilizado para determinar o caminho percorrido em um fluxo. O gateway é representado por um losango e pode conter símbolos que especifiquem a sintaxe do controle de fluxo. A Figura 3.10 apresenta as duas variações utilizadas neste trabalho. O gateway exclusivo siginifica que apenas um dos caminhos originados a partir desse gateway serão percorridos. O gateway paralelo indica que todos os caminhos originários desse gateway serão percorridos simultâneamente. Figura 3.10: Gateways BPMN Atividades Esse símbolo é utilizado para representar as atividades do fluxo. Esse símbolo é representado por um retângulo e pode conter símbolos que especifiquem a natureza ou o funcionamento da atividade. As três variações utilizadas neste trabalho são: atividades gerais, atividades humanas e atividades em loop. Atividades gerais representam atividades de qualquer natureza; neste trabalho são utilizadas para representar atividades automáticas ou semi-automáticas. Atividades humanas são utilizadas para representar atividades que são realizadas puramente por humanos, sem auxílio de um sistema. Por fim, as atividades em loop representam atividades que se mantém em execução repetidas vezes após a passagem do fluxo por essa atividade. A Figura 3.11 apresenta os símbolos utilizados para cada uma dessas atividades. Figura 3.11: Atividades BPMN Eventos Representam acontecimentos dentro do fluxo de processo. Os eventos podem representar o início do fluxo, o fim do fluxo ou acontecer durante o fluxo de atividades. 53

67 A Figura 3.12 apresenta os símbolos utilizados para representar os três tipos de deventos utilizados neste trabalho. Figura 3.12: Eventos BPMN Pools Utilizadas para delimitar o escopo de execução de um fluxo de atividades. Esse símbolo pode ser utilizado para delimitar organizações, divisões de uma organização ou até mesmo participantes distintos de um fluxo de atividades. A Figura 3.13 apresenta o símbolo utilizado para representar um pool. O fluxo de atividades se dá dentro de um pool. Figura 3.13: Pool BPMN Setas As setas são utilizadas para representar transições entre atividades ou entre as atividades e outro símbolo BPM (por exemplo, um gateway). A seta contínua é utilizada para ligar elementos dentro de um mesmo pool. A seta pontilhada é utilizada para ligar atividades de um pool com atividades de outro pool. Em geral, representa troca de mensagens. A Figura 3.14 apresenta as setas utilizadas. Figura 3.14: Setas BPMN 54

68 Capítulo 4 Metodologia Neste capítulo serão apresentadas as metodologias utilizadas neste trabalho. A metodologia de trabalho descreve o tipo de estudo realizado neste trabalho e quais foram as atividades desempenhadas em sua execução. Em seguida são apresentadas as metodologias utilizadas na modelagem dos serviços e dos agentes (Seções 5.1 e 5.2 ). A primeira parte do capítulo descreve a estratégia de pesquisa utilizada; em seguida, são apresentados o método para identificação de serviços e a metodologia para modelagem dos agentes. Serão apresentados também os templates utilizados para a modelagem dos serviços e dos agentes. No capítulo 5 serão apresentados os artefatos resultantes da aplicação das metodologias. 4.1 Estratégia de pesquisa Este trabalho é um estudo empírico. Esse estudo é classificado como um estudo de viabilidade in virtuo (Vitor Pires Lopes, 2009). Esse tipo de estudo tem por objetivo verificar se é possível extrair resultados úteis do trabalho realizado. Nesse tipo de estudo a eficácia da idéia proposta pode ser avaliada, mas não em contraponto às demais alternativas. Assim, nesses estudos a proposta é posta em prática e são avaliados os resultados obtidos. Caso esses resultados sejam úteis e o tempo gasto em sua obtenção seja viável, a pesquisa pode evoluir para um estudo observacional. Caso alguma das duas respostas tenha sido negativa, a idéia da pesquisa é refinada e o processo é realizado novamente (Shull et al., 2001; Vitor Pires Lopes, 2009). Num estudo in virtuo, o ambiente é todo controlado por humanos e as análises são feitas por simulação. Dada as características do tipo de estudo realizado, a hipótese do trabalho é: A implementação de um sistema de detecção de emergências no domínio de vida ambiente-assistida por meio da combinação de sistemas multi-agentes com arquitetura orientada a serviços é uma solução viável. O objetivo desse trabalho é fazer uma implementação de parte do sistema proposto no projeto EMERGE (Seção 2.3). O proposta é modelar um sistema multiagentes dentro do escopo escolhido em que os recursos disponíveis aos agentes são 55

69 os serviços, ou seja, o meio é modelado como um conjunto de serviços. Esses serviços são utilizados pelos agentes para realizar as ações que são desencadeadas a partir de eventos de emergência. Dessa forma os agentes são os responsáveis pela orquestração dos serviços disponíveis na aplicação. Devido às características do estudo, os serviços implementados realizam apenas simulações, já que a implementação da lógica completa do serviço não é o foco do trabalho. 4.2 Identificação de Serviços A metologia utilizada é baseada em um método de identificação de serviços a partir da modelagem de processos de negócio (Azevedo et al., 2009). Antes da execução do método é necessário levantar algumas informações necessárias tais como escopo da identificação dos serviços e modelos de processo utilizados. Assim, a metodologia foi dividida em duas fases: 1. Levantamento: nesta fase serão levantadas as informações necessárias à execução da fase de identificação. 2. Identificação: nesta fase o método de identificação de serviços será aplicado com base nas informações levantadas na fase anterior. Essas fases serão detalhadas a seguir e ao final do capítulo serão apresentados os templates para as informações levantadas Levantamento O processo de identificação começa a partir de uma demanda de implementação. Essa demanda define o escopo da identificação de serviços. Após a definição do escopo é necessário que seja feita a modelagem dos processos de negócio; essa modelagem consiste na produção de alguns artefatos, dentre os quais os seguintes foram considerados relevantes para este trabalho (Azevedo et al., 2009): Modelo de processos: representação dos macroprocessos do negócio e dos seus respectivos fluxos de atividades. Modelo de atividades: modelo de processos refinados explicitando, para cada atividade, os responsáveis, as informações utilizadas, as regras e requisitos de negócio. Neste trabalho, essa fase consistirá em refinar os modelos de negócio apresentados no documento de requisitos do EMERGE (Gross et al., 2009). 56

70 4.2.2 Identificação Com o escopo definido e com as informações levantadas a fase de identificação irá identificar os serviços candidatos avaliando padrões de workflow, regras de negócio e requisitos de negócio presentes na modelagem dos processos. Um serviço candidato é uma representação não implementada de um serviço. Um serviço candidato pode ser implementado como serviço ou como parte de uma aplicação. Estes serviços podem ser classificados de acordo com sua natureza da seguinte maneira (Azevedo et al., 2009): Serviços de negócio: serviços que representam regras de negócio. Serviço de dados: serviços responsáveis por realizar operações de manipulação de dados (inserção, alteração, exclusão e consulta). Serviços utilitários: serviços que implementam padrões recorrentes nos processos de negócio. O método de identificação dos serviços é subdividido nas seguintes etapas: 1. Seleção das atividades. 2. Identificação e classificação dos serviços candidatos. 3. Consolidação dos serviços candidatos. A seguir serão descritas cada uma dessas etapas. Seleção das atividades Nesta etapa serão selecionadas as atividades do modelo de processos que podem se tornar serviços candidatos. Serão selecionadas todas as atividades que não sejam puramente humanas, ou seja, aquelas que são realizadas ou apoiadas por um sistema (Azevedo et al., 2009). Identificação e classificação dos serviços candidatos Os serviços são identificados analisando as atividades selecionadas de acordo com uma série de heurísticas. Essas heurísticas podem ser classificadas em semânticas e sintáticas. As heurísticas semânticas identificam serviços candidatos com base nos requisitos e regras de negócio, as heurísticas sintáticas identificam serviços candidatos reconhecendo alguns padrões na estrutura do workflow. A seguir são detalhadas cada uma das heurísticas (Azevedo et al., 2009): 1. Regra de negócio: um serviço candidato dever ser identificado por meio de uma regra de negócio. 2. Requisito de negócio: um serviço candidato pode ser identificado por meio de um requisito de negócio. 57

71 3. Atividades sequênciais: um serviço candidato deve ser identificado por meio de um conjunto de atividades sequênciais. 4. Atividades paralelas: um serviço candidato deve ser identificado a partir da divisão do fluxo em um conjunto de atividades paralelas cuja saídas são sincronizadas posteriormente em um mesmo ponto, unificando novamente o fluxo de atividades. 5. Atividades exclusivas: um serviço candidato deve ser identificado a partir de uma condição que direciona o fluxo para apenas uma das várias alternativas. Os possíveis fluxos devem chegar a um mesmo ponto reunificando o fluxo ou chegar a um evento final. 6. Atividades opcionais: idêntica à heurística anterior, porém a condição pode direcionar o fluxo par uma ou mais das várias alternativas. 7. Atividades em loop: um serviço candidato deve ser identificado a partir de uma estrutura do workflow que possa ser executada repetidas vezes. 8. Recepção de mensagens: um serviço candidato deve ser identificado a partir de uma atividade que recebe mensagens de uma atividades de outros modelos de processos. 9. Envio de mensagens: um serviço candidato deve ser identificado a partir de uma atividade onde várias mensagens são enviadas para outras atividades. Consolidação dos serviços candidatos A etapa de consolidação consiste nas seguintes atividades: Eliminar serviços duplicados Associar o serviço candidato às atividades que lhe deram origem.(atividades do modelo de processo) Identificar granularidade e dependência entre os serviços Os serviços candidatos devem ter suas relações de dependência documentadas; essa informação é utilizada para avaliar a granularidade dos serviços. Serviços que não fazem uso de nenhum outro serviço são ditos atômicos ou de granularidade fina e os serviços que invocam outros serviços são chamados de serviços compostos ou de granularidade grossa. Identificação de serviços utilitários Os serviços identificados a partir de atividades recorrentes no fluxo de processo devem ser marcados como serviços utilitários, podendo ser utilizados novamente em outros contextos que realizem as mesmas atividades Templates utilizados Os modelos a seguir foram propostos para exibir as informações resultantes da identificação dos serviços candidatos. Esses templates consistem em tabelas com 58

72 uma única linha em que a semântica de cada coluna é apresentada pelas sentenças entre os sinais «e». Serviço Heurística Atividades Observações «nome do serviço» «heurística que o «atividades do «informações adicionais» identificou» workflow que compõe o serviço» Tabela 4.1: Tabela de Serviços Candidatos A Tabela 4.1 descreve os serviços candidatos identificados mapeando-os às atividades que os criaram e às heurísticas que levaram à sua identificação; adicionalmente podem ser feitas observações que se mostrarem relevantes durante a fase de identificação. Serviço Atômico (ID) «identificador único do serviço» Serviço Atômico (Nome) «nome serviço atômico» do Parâmetros de Entrada «descrição das entradas» Operação «operações disponibilizadas pelo serviço» Parâmetros de Saída «descrição das saídas» Tabela 4.2: Tabela de Serviços Atômicos Consolidados A Tabela 4.2 é utilizada para descrever serviços atômicos consolidados, ou seja, serviços que não dependem de nenhum outro serviço, serviços de granularidade fina. A Tabela 4.3 apresenta as informações resultantes da fase de consolidação para serviços compostos, ou serviços de processos, ou ainda serviços de granularidade grossa. 4.3 Metodologia de Modelagem dos Agentes Nesta seção será apresentada metodologia GAIA. Primeiramente será dada uma visão geral da metodologia e em seguida será detalhada cada uma das fases que a compõe. Os templates utilizados são apresentados ao longo de toda seção, esses templates seguem o mesmo formato dos templates apresentados na Seção Introdução Para a modelagem dos agentes que irão compor a solução foi escolhida a metodologia GAIA: GAIA é uma metodologia de propósito geral, idependente da natureza do problema, baseada na metáfora de organizações em que (Zambonelli et al., 2003): 59

73 Serviços Compostos (ID) «identificador único do serviço» Serviços Compostos (Nome) «nome serviço» do Função Operação Serviço «as funções são as operações que estarão presentes na interface do serviço de processo» «nessa coluna serão listadas as operações utilizadas pelo serviço de processo para prover suas funções» «as operações listadas na coluna ao lado estarão relacionadas a seus respectivos serviços por meio dessa coluna» Tabela 4.3: Tabela de Serviços Compostos Consolidados Um sistema de software é concebido como uma instanciação computacional de grupos de interação e indivíduos autônomos (agentes). Cada agente desempenha um ou mais papéis, ou seja, o agente tem um conjunto bem definido de responsabilidades ou metas no contexto do sistema como um todo. Tais metas podem ser altruístas (contribuem para o objetivo global da aplicação) ou oportunistas (quando o agente persegue seus próprios interesses). Através das interações os agentes cumprem seus papéis no sistema. Interações ocorrem de acordo com padrões e protocolos definidos pelos papéis e ajudam a caracterizar a estrutura da organização e a posição do agente nela. A evolução das atividades, execuções autônomas e interações determinam o cumprimento das metas da aplicação. Sistemas simples podem ser modelados como sendo uma única organização. Quando a complexidade do sistema aumenta os princípios de modularidade e encapsulamento sugerem uma divisão da organização em diversas sub-organizações, com alguns agentes podendo pertencer à múltiplas organizações simultaneamente (Zambonelli et al., 2003). A complexidade de coordenação dos agentes é reduzida por meio da estrutura organizacional já que cada agente precisa conhecer apenas seus objetivos e com quem deve interagir para alcançá-los, não é necessário que conheça todos os agentes da comunidade (Seção 3.1.5)(Zambonelli et al., 2003). Sistemas multi-agentes tipicamente estão inseridos em um meio; o meio é composto por entidades e recursos que o agente pode precisar controlar ou consumir para cumprir suas metas. O meio pode ser composto por elementos físicos tais como entidades e dados, ou virtuais tais como aplicações, sistemas de bancos de 60

74 dados e serviços. A modelagem do meio é importante para que as demais atividades de projeto, etretanto a metodologia GAIA não propõe uma método geral para realizar essa atividade, pois essa é uma atividade ligada à natureza do problema (Zambonelli et al., 2003). A Figura 4.1 ilustra os conceitos apresentados. Figura 4.1: Representação GAIA, adaptado de (Zambonelli et al., 2003) Neste trabalho a meotodologia GAIA foi adotada por ser uma metodologia livre de contexto da aplicação, por dar liberdade na modelagem do meio e por trazer a abstração de papéis. Essas características são importantes para a modelagem dos agentes no sistema proposto pelo EMERGE já que a documentação disponível está classificada por stakeholder, por papel dentro do sistema, e que a liberdade de modelagem do meio facilitará a integração da modelagem dos agentes e dos serviços. GAIA é dividida nas seguintes fases: Análise O objetivo dessa fase é coletar requisitos e especificações para o sistema por meio de um modelo do meio, modelos preliminares de papéis e de interação e um conjunto de regras organizacionais para cada sub organização que compõe o sistema. Projeto: Projeto Arquitetural Nessa fase serão tomadas decisões baseadas nos requisitos levantados na fase de análise, os modelos de interação e de papéis serão completados e a estrutura organizacional será definida. Projeto: Projeto Detalhado Nessa fase serão definidos os modelos de agentes e de serviços 1. A seguir serão detalhadas cada uma dessas fases. 1 Vale ressaltar que os serviços a que a metodologia se refere não são necessariamente os serviços identificados na modelagem dos serviços(seção 5.1), esse é um conceito próprio dentro da metodologia GAIA. 61

75

76 Propriedades que devem ser sempre cumpridas para que seja mantido um estado aceitável ( Para que nada de mal aconteça ) (Zambonelli et al., 2003). Propriedades liveness Propriedades que devem ser cumpridas caso algum evento específico aconteça ( Alguma coisa boa ocorre ) (Zambonelli et al., 2003). As permissões são representadas por meio de uma lista de recursos e permissões associadas para cada agente. As propriedades safety são representadas por uma lista de predicados, expressos sobre variáveis definidas na lista de permissões do agente (Zambonelli et al., 2003). Exemplo: tempo_de_espera_para_confirmação_de_emergência < 30 segundos As propriedades liveness definem potenciais trajetórias de execução através de várias atividades e protocolos associados com o papel. As atividades de um papel são as ações do agente que podem ser tomadas sem a interação com outros agentes. Os protocolos definem a forma como os agentes podem interagir uns com os outros (Wooldridge et al., 2000). Os protocolos e as atividades são combinados através do uso dos operadores apresentados na Tabela 4.4 para determinar a ordem em que eles ocorrem formando expressões liveness, nessas expressões as atividades são sublinhadas para diferenciá-las dos protocolos e os parênteses são utilizados para fazer agrupamentos. Exemplo: AssistentePessoal = (EnviarNotificacao.InvocarAvisarNotificação) ω No exemplo acima, o papel AssistentePessoal participa do protocolo Enviar- Notificacao e em seguida executa a atividade InvocarAvisarNotificacao. Esse fluxo ocorre indefinidamente, o que é indicado pelo ω. Operador Intepretação x.y x seguido de y x y Se x ou y ocorrer x* x ocorre zero ou mais vezes x+ x ocorre 1 ou mais vezes x ω x ocorre indefinidamente [x] x é opcional x y x e y intercalados (paralelamente) Tabela 4.4: Operadores para expressões liveness 63

77 Modelo de Interações Preliminar Para descrever um padrão de interação, que na metodologia GAIA é chamado de protocolo, são utilizados os seguintes atributos: Nome do protocolo: breve descrição textual. Iniciador: o papel responsável por inciar o protocolo. Parceiro: o papel com o qual o iniciador interage. Entradas: informações utilizadas pelo papel iniciador. Saídas: informações providas pelo parceiro do protocolo. Descrição: descrição textual explicando o objetivo do protocolo e as atividades de processamento inclusas em sua execução. As informações apresentadas acima descrevem os protocolos de maneira conceitual. O foco nesse modelo é representar o propósito da interação ao invés do ordenamento preciso das mensagens; entretanto, detalhes (incluindo sequência e formato de mensagens ) podem ser acrescidos ao modelo. Assim como o modelo de papéis, esse é um modelo preliminar pois algumas informações somente poderão ser levantadas quando a estrutura da organização for definida. Regras organizacionais Os modelos preliminares de papéis e de interações são levantados sem que se tenha definido qualquer estrutura organizacional previamente. Porém, há algumas relações entre os papéis, entre os protocolos e entre papéis e protocolos que são melhor representadas por regras organizacionais. Na metodologia GAIA, as regras organizacionais são vistas como responsabilidades da organização como um todo, e como tal, podem ser classificadas da mesma maneira que as responsabilidades dos papéis: em propriedades liveness e safety. Propriedades liveness definem como se dá a dinâmica da organização, representam regras invariantes que devem ser respeitadas ao longo da vida da organização. As regras organizacionais são utilizadas posteriormente na fase de desenho, como forma de restringir as possíveis implementações da estrutura da organização. Devido a suas similaridades, regras organizacionais liveness e safety são representadas por meio dos mesmos formalismos utilizados para descrever as propriedades liveness e safety dos papéis (Wooldridge et al., 2000). A Tabela 4.5 apresenta o formato utilizado para representar as regras organizacionais Projeto: Projeto Arquitetural Estrutura Organizacional A definição da estrutura organizacional é uma fase crítica na modelagem do sistema multi-agentes pois terá impacto em todas as atividades subsequentes. A estrutura é definida pela escolha da topologia e do regime de controle. 64

78 Tipo da Regra Descrição Objetivo «liveness ou safety» «nome ou descrição da «objetivo da regra ou regra organizacional» descrição detalhada» Tabela 4.5: Regras Organizacionais A topologia de uma organização determina as relações de autoridade entre os papéis. Quando a organização é composta por poucos papéis, os custos de coordenação entre os agentes é baixo e a organização pode ser composta por um conjunto de agentes em que, apesar de possuírem metas diferentes, tem a mesma autoridade dentro da organização. Quando a organização é grande, os custos de coordenação são maiores e uma topologia hierárquica é mais indicada já que cada papel estará livre das atividades de coordenação pois estas serão assumidas pelo agente líder. Em organizações maiores ainda, pode ser necessário estabelecer uma hierarquia de vários níveis. A topologia escolhida deve ser a mais simples possível capaz de tratar a complexidade computacional e de coordenação entre os agentes (Wooldridge et al., 2000). O regime de controle determina como será feita a divisão das tarefas entre os agentes. A divisão das tarefas pode ser feita por meio de um regime de partição da carga de trabalho ou por meio de um regime de especialização da carga de trabalho. No primeiro caso, vários agentes desempenham o mesmo papel e proveem os mesmos serviços, o que é indicado quando um grande número de tarefas similares precisam ser realizadas. No segundo caso, cada agente desempenha um papel, o que é indicado quando o trabalho consiste em poucas tarefas complexas. Ao definir a estrutura organizacional, é preciso considerar as regras organizacionais levantas na fase de análise. Regras que restringem um papel a ser desempenhado por um único agente por vez, por exemplo, afetam diretamente a escolha do regime de controle; uma outra regra poderia ainda afetar a escolha da topologia. Complementação dos Modelos de Interação e Papéis Uma vez definida a estrutura organizacional, os modelos preliminares de papéis e de interações podem ser completados. Com a estrutura organizacional em mãos é possível definir que papéis irão interagir e que protocolos deverão ser executados. A atividade de complementação dos modelos consiste nas seguintes atividades (Wooldridge et al., 2000): Definir todas as atividades em que um papel estará envolvido, bem como suas responsabilidades liveness e safety. Definir papéis organizacionais definir os papéis que surgiram durante a fase de definição da estrutura organizacional e que não foram identificados anteriormente. Exemplo: um agente que coordena as atividades de dois outros agentes consolidando os resultados do trabalho desses agentes. Completar a definição dos protocolos requeridos pela aplicação especificando que papéis irão participar do protocolo. 65

79 Definir protocolos organizacionais definir os protocolos cuja identificação foi derivada da adoção da estrutura organizacional. A Tabela 4.6 apresenta o formato do modelo de papéis, esse modelo é utilizado na fase de análise e posteriormente enriquecido na fase de desenho. A Tabela 4.7 detalha as atividades do papel. A Tabela 4.8 apresenta o formato do modelo de interações descrevendo os protocolos com detalhes tais como os papéis de que participam, as entradas e as saídas do protocolo (Moraitis et al., 2003; Zambonelli et al., 2003). Papel Descrição Responsabilidades liveness Responsabilidades safety Permissões Protocolos e Atividades «nome do papel» «breve descrição» «expressões de propriedades liveness» «expressões de propriedades safety» «lista dos recursos e das permissões associadas» «lista dos protocolos e atividades do agente» Tabela 4.6: Modelo de Papéis Nome «nome da atividade» Descrição «descrição da atividade» Tabela 4.7: Descrição das Atividades Nome do protocolo «nome do protocolo» Iniciador (es) Receptor (es) «papéis que inciam o protocolo» «papéis que participam do protocolo» Entradas Saídas Descrição «mensagens «mensagens «descrição que inciam finais, conclusão do pro- o protocolo» do pósito do protocolo» protocolo» Tabela 4.8: Protocolos de Interação Projeto : Projeto Detalhado Definição do Modelo de Agentes O modelo de agentes consiste de uma tabela que mapeia os agentes aos papéis. De modo geral, cada agente será mapeado para um papel, porém alguns papéis po- 66

80 dem vir a ser desempenhado por mais de um agente de acordo com as restrições impostas pela estrutura organizacional. Um mesmo agente pode vir a desempenhar vários papéis desde que isso não altere a eficiência organizacional nem viole a estrutura organizacional. A Tabela 4.9 apresenta o formato de representação do modelo de agentes. Papel Agente(s) Justificativa «nome do papel» «agentes que desempenham «breve justificativa para o papel» a escolha (opcional)» Tabela 4.9: Modelo de Agentes Definição do Modelo de Serviços O modelo de serviços identifica os serviços associados a cada agente 2. Um serviço é definido como um bloco coerente de atividades que o agente desempenhará, tais serviços não são necessariamente disparados por requisições externas. Os serviços que compõe um agente são derivados da lista de atividades, responsabilidades, propriedades liveness e dos papéis que implementa. Em última instância, haverá pelo menos um serviço para cada atividade paralela que o agente desempenha. Para cada serviço é necessário identificar suas entradas e saídas, pré e pós condições. A Tabela 4.10 apresenta o formato utilizado para representar estas informações. Agente Serviço Precondições «nome do «serviços «précondições agente» identificados» de cada serviço» Póscondições «póscondições de cada serviço» Entrada «descrição das Entradas» Saída «descrição das saídas» Tabela 4.10: Modelo de Serviços 2 Mais uma vez, vale lembrar que esses serviços não são os serviços identificados na Seção

81 Capítulo 5 Análise e Projeto Neste capítulo serão apresentados os resultados da modelagem dos serviços e dos agentes do sistema EMERGE de acordo com as metodologias apresentadas no capítulo 4. A primeira parte deste capítulo aborda a modelagem dos serviços, a segunda parte apresenta a modelagem dos agentes. Em ambas as partes as seções estão organizadas de acordo com as etapas de suas respectivas metodologias. 5.1 Modelagem dos Serviços Nesta seção serão apresentados os artefatos produzidos durante a aplicação da metodologia de identificação e modelagem dos serviços. Os artefatos apresentados nesta seção se limitam a representar as informações necessárias para a identificação dos serviços dentro do escopo delimitado para produção do trabalho, ou seja, os serviços identificados estão limitados ao fluxo de processo do Home Subsystem e da Pessoa Assistida (Seção 2.3). A seguir serão descritas as atividades realizadas em cada etapa da metodologia. Essas atividades estão organizadas da mesma maneira em que foram apresentadas na Seção Levantamento Durante a fase de preparação os fluxos de processos dos cenários escolhidos como escopo do trabalho foram detalhados contemplando algumas informações do modelo de atividades tais como papéis, requisitos e regras de negócio. Para realizar esse detalhamento foram utilizadas as informações dos cenários e dos casos de uso (Seção 2.2). O fluxo de processo foi detalhado utilizando os símbolos da notação BPMN 1. A seguir são listados algumas informações relevantes acerca do representação do processo na notação BPMN: Cada pool representa um participante do fluxo de processos. Um participante pode ser uma pessoa, um sistema ou um grupo de pessoas. 1 Acrônimo para Business Process Modeling Notation, notação para representação de fluxos de processo de negócio (Seção 3.3). 68

82 As pools Centro de despacho e Serviço sócio-médico estão presentes para representar a troca de mensagens entre os participantes. A pessoa assistida foi representada numa pool separada para explicitar suas interações com Home Subsystem. 69

83 Figura 5.1: Fluxo de Atividades do EMERGE

84 5.1.2 Identificação Seleção das atividades Nesta fase, são selecionadas as atividades automáticas e as atividades assistidas pelo sistema. Dentro do escopo desse trabalho isso significa desprezar as atividades do fluxo de processo do Pessoa Assistida e considerar as atividades do processo associadas ao Home SubSystem. Identificação dos serviços candidatos Nesta etapa, as atividades selecionadas do fluxo de processo detalhado serão avaliadas de acordo com as heurísticas apresentadas na Seção Essas heurísticas consideram a semântica do serviço (Heurísticas 1 e 2) e a estrutura do fluxo de processo (padrões no workflow) para identificar os serviços. Um mesmo subconjunto de atividades do processo pode ser identificado por mais de uma heurística. Para resolver esse problema, as atividades são avaliados primeiramente pelas heurísticas 1 e 2 (semântica) e somente depois pelas heurísticas baseadas em padrões de workflow (as demais). Os serviços candidatos identificados estão apresentados na Tabela 5.1. Consolidação dos Serviços Durante a etapa de consolidação os serviços candidatos foram refinados. Este refinamento é feito por meio dos quatro passos apresentados na Seção 4.2.2: Eliminação de Serviços duplicados: nesta etapa não foi detectada a duplicação de nenhum serviço identificado. Associar os serviços candidatos às atividades que lhes deram origem: informação já apresentada na Tabela 5.1 Identificar granularidade e dependência entre os serviços candidatos: essas informações serão preenchidas nas tabelas de serviços atômicos e compostos. Identificar serviços utilitários: não foram identificados serviços candidatos Nenhum serviço composto foi identificado, portanto será apresentado apenas a Tabela 5.2 com os serviços atômicos consolidados. 71

85 Tabela 5.1: Serviços Candidatos Serviço Heuristica Atividades obs Avisar envio de notificação Requisito de negócio (2) Avisar o idoso acerca da notificação Pessoa assistida deve sempre ser avisada sobre envio de dados Detectar Alarme Requisito de negócio(2) Detectar Alarme Pessoa assistida pode disparar o alarme manualmente Confirmar Emergência Enviar Alarme e Dados para o Serviço Sócio-Médico Detectar Emergência Enviar Alarme e Dados para o centro de despacho Detecar Desvios de Longo Prazo Atividades sequenciais (3) Emitir aviso de que o sinal foi disparado Confirmar Emergência Aguardar Confirmação Atividades sequenciais (3) Armazenar informações do desvio de longo prazo Enviar Notificação para o serviço sócio-médico Atividades em loop (7) Detectar emergência Atividades sequenciais (3) Armazenar informações da emergência Enviar Alarme e Dados para o Centro de Despacho Atividades em loop (7) Detectar Desvios de Longo Prazo 72

86 Tabela 5.2: Serviços Atômicos Consolidados Serviço Atômico (ID) Serviço Atômico (Nome) Operação Parâmetros de Entrada ConfirmarEmergencia Confirmar Emergência ConfirmarEmergencia Dados da Emergência DetectarAlarme Detectar Alarme DetectarAlarme nenhum nenhum DetectarEmergencia Detectar Emergência DetectarEmergencia nenhum nenhum DetectarDesvio Detectar Desvios de Longo Prazo AvisarEnvioNotificacao Avisar envio de notificação ao centro de despacho ou serviço sócio-médico EnviarDadosDespacho Enviar Alarme e Dados para o centro de despacho EnviarDadosSSM Enviar Alarme e Dados para o Serviço Sócio- Médico DeterctarDesvios nenhum nenhum AvisarNotificacao Mensagem a ser exibida SalvarDados, EnviarAlarme Dados da Emergência Aguda SalvarDados, EnviarAlarme Dados da Emergência de Desvio de Longo Prazo Parâmetros de Saída sim/não nenhum nenhum nenhum 73

87 5.2 Modelagem dos Agentes Nesta seção, serão apresentados os artefatos produzidos durante a aplicação da metodologia de modelagem do sistema multi-agentes (Seção 4.3). Os artefatos apresentados nesta seção se limitam a representar as informações necessárias para a modelagem dos agentes dentro do escopo delimitado para a realização deste trabalho. Os documentos utilizados como insumos para a execução da metodologia de modelagem dos agentes foram os documentos de requisitos de sistema e de arquitetura do projeto EMERGE (Gross et al., 2009; Becker et al., 2008b) Análise Esta seção está dividida conforme as etapas da metodologia GAIA descrita na Seção 4.3. Os termos meio e ambiente são utilizados como sinônimos na modelagem dos agentes. Organizações O sistemas foi modelado como uma única organização responsável por identificar situações de emergência e encaminhar prontamente as informações. Nenhuma divisão nessa organização se mostrou necessária, o escopo escolhido para o estudo do problema possui objetivos bem definidos e não apresenta as características sugeridas como indicadores para a subdivisão da organização (Seção 2.3). Modelo do Ambiente O ambiente será modelado como um conjunto de serviços. Os agentes cumprem seus objetivos através do comsumo (ou invocação) de cada um desses serviços. Os serviços que compõe o meio estão listados na Tabela 5.2. Modelo de papéis preliminar Foi identificado um papel preliminar para cada stakeholder envolvido no escopo desse trabalho, mais especificamente a pessoa assistida e a parte do Home SubSystem responsável pela detecção e tratamento de emergências. Assistente Pessoal: agente responsável por representar a pessoa assistida no sistema. Esse agente é consultado sempre que os demais agentes precisam de alguma informação sobre a pessoa assistida. Assistente de Emergência: agente responsável por tomar as providências previstas pelo sistema quando um evento de emergência é detectado. As informações levantadas nesta fase compreendem que recursos do ambiente (serviços) cada papel pode utilizar, suas responsabilidades e suas atividades. Essas informações estão nas Tabelas 5.5 e 5.7. Tais tabelas serão revisitadas na etapa de complementação desse modelo para realização de ajustes e acréscimo de informações. 74

88 Modelo de interação preliminar O fluxo de atividades da Figura (Seção 5.1) apresenta os papéis e suas atividades desde a detecção de um evento de emergência (emergência aguda ou desvio de longo prazo) até o fim do tratamento do evento culminando no envio da emergência ao centro de despacho ou serviço sócio-médico, ou a confirmação de um falso positivo. As interações identificadas e representadas de maneira preliminar foram identificadas com base no fluxo de atividades, nos casos de uso e nos cenários apresentados no documento de requistos do EMERGE (Gross et al., 2009). As interações são as seguintes: Pedir confirmação: interação entre o assistente pessoal e o assistente de emergência quando o agente de emergência detecta um evento de emergência que precisa ser confirmado. Enviar notificação: caso alguma informação seja enviada ao Serviço de Despacho ou ao Serviço Sócio-Médico pelo assistente de emergência, este deve informar ao assistente pessoal sobre o envio de informações Informações mais detalhadas sobre o modelo de interação podem ser encontradas na Tabela 5.4, que posteriormente será enriquecida com mais detalhes na etapa de complementação do modelo de interação. Regras organizacionais Utilizando as informações levantadas nas etapas anteriores e nas informações apresentadas nos documentos do projeto EMERGE, foi possível identificar as regras organizacionais apresentadas na Tabela 5.3 (Gross et al., 2009; Becker et al., 2008b). Tipo da Regra Descrição Objetivo De sobrevivência Confirmar a Emergência com a pessoa assistida Sempre que um agente enviar informações para fora do Home SubSystem o assistente pessoal deve ser avisado Tabela 5.3: Regras Organizacionais Projeto : Projeto Arquitetural Estrutura Organizacional A estrutura organizacional é definida por sua topologia e pelo regime de controle. A meotodologia GAIA sugere que a topologia seja sempre a mais simples possível que seja capaz de lidar com a complexidade de coordenação e de computação; sugere 75

89 ainda que para sistemas com poucos agentes é mais fácil adotar uma topologia de um único nível, onde todos os agentes possuem a mesma autoridade, ou seja, não há hierarquia entre os agentes. O regime de controle adotado foi o de especialização de workload, pois workloads compostos por poucas atividades complexas tem menor custo de coordenação utilizando esse tipo de regime (Zambonelli et al., 2003). A Figura 5.2 representa a estrutura organizacional. Figura 5.2: Estrutura Organizacional Complementação dos modelos de interação e de papéis Em posse da estrutura organizacional, o modelo de papéis preliminares pode ser validado e complementado. Por se tratar de uma estrutura organizacional muito simples, os modelos de papéis não sofreram alterações desde o levantamento preliminar. Os modelos de papéis, de interações e de atividades completos estão representados pelas tabelas 5.5, 5.6, 5.7, 5.8 e 5.4. Vale lembrar que, nas expressões de responsabilidades dos agentes, as atividades são sublinhadas e os protocolos não (Seção 4.3.2) Projeto : Projeto detalhado Modelo de Agentes O Tabela 5.9 apresenta e justifica o mapeamento entre os agentes e os papéis que serão despenhados por cada um deles Modelo de Serviços De acordo com a metodologia GAIA, serviços podem ser levantados como sendo cada comportamento paralelo do agente. O modelo de serviços foi definido tomando 76

90 Nome do protocolo Iniciador (s) Receptor (es) Entradas Saídas Descrição PedirConfirmacao Emergency Assitant Personal Assistant Pedido de Confirmação, com algumas informações sobre a emergência. EnviarNotificacao Emergency Assistant Personal Assistant Mensagem informando que dados sobre emergência ou desvio de longo prazo foram enviados. Resposta positiva ou negativa ao pedido de confirmação O Emergency Assistant troca mensagens com o personal assistant objetivando confirmar a emergência para prosseguir com o tratamento da emergência. Nenhuma Ao enviar um aviso ao centro de despacho ou ao serviço sócio médido o Emergency Assistant avisa o Personal Assistant que tais dados foram enviados. Tabela 5.4: Modelo de Interações : Protocolos 77

91 Papel Descrição Resp. de sobrevivência Resp. de segurança Permissões Protocolos e Atividades Assistente Pessoal Representa a pessoa assistida (PedirConfirmacao.InvocarConfirmarEmergência.PedirConfirmacao) ω (EnviarNotificacao.InvocarAvisarNotificação) ω TempoConfirmarEmergencia < 20s ConfirmarEmergência (consumo), AvisarNotificação (consumo) PedirConfirmacao, ConfirmarEmergência, InvocarAvisarNotificação, InvocarConfirmarEmergência, EnviarNotificacao Tabela 5.5: Papel: Assistente Pessoal Nome InvocarAvisarNotificação InvocarConfirmarEmergência Descrição Invoca o serviço AvisarNotificação disponível no ambiente Invoca o serviço confirmar emergência. Tabela 5.6: Atividades : Assistente Pessoal Papel Descrição Resp. de sobrevivência Resp. de segurança Permissões Protocolos e Atividades Assistente de Emergência Representa o sistema, monitorando eventos de emergência (InvocarDetectarAlarme InvocarDetectarEmergencia) ω.pedirconfirmacao.[invocarenviardadosdispatcher.enviarnotificacao] (InvocarDetectarDesvios) ω.invocarenviardadosssm.enviarnotificacao TempoConfirmarEmergencia < 30s (Larga Margem de delay em relação ao Assistente Pessoal) DetectarAlarme (consumo), DetectarEmergencia (consumo), DetectarDesvio (consumo), EnviarDadosDispatcher (consumo), EnviarDadosSSM (consumo) PedirConfirmacao, EnviarNotificacao, InvocarEnviarDadosSSM, InvocarDetectarAlarme, InvocarDetectarEmergencia, InvocarEnviarDadosDispatcher, InvocarDetectarDesvios Tabela 5.7: Papel : Assistente de Emergência 78

92 Nome InvocarEnviarDadosSSM InvocarDetectarAlarme InvocarDetectarEmergencia InvocarEnviarDadosDispatcher InvocarDetectarDesvios Descrição Invoca o serviço EnviarDadosSSM disponível no ambiente Invoca o serviço DetectarAlarme Invoca o serviço DetectarEmergencia Invoca o Serviço EnviarDadosDispatcher Invoca o Serviço DetectarDesvios Tabela 5.8: Atividades : Assistente de Emergência Agente Papel Justificativa ElderlyAgent AssistentePessoal Esse agente desempenha um único papel para que haja uma separação de responsabilidades mais evidentes facilitando a introdução de mais agentes à comunidade EmergencyAgent AssistenteEmergencia Esse agente desempenhará um único papel pelos mesmos motivos do AssistentePessoal Tabela 5.9: Modelo de Agentes cada responsabilidade de sobrevivência paralela como um serviço. Por exemplo, o papel Assistente Pessoal apresentado na Tabela 5.5 possui a seguinte expressão para representar suas responsabilidades de sobrevivência: (PedirConfirmacao.InvocarConfirmarEmergência.PedirConfirmacao) ω (EnviarNotificacao.InvocarAvisarNotificação) ω Observe que essa expressão possui duas responsabilidades paralelas, o que pode ser evidenciado pela presença do operador (Tabela 4.4 na Seção 4.3), cada uma dessas responsabilidades foi mapeada como um serviço na Tabela A Tabela 5.10 apresenta o modelo de serviços. 5.3 Modelo Visual A Figura 5.3 representa os agentes modelagem e suas relações com os serviços, tal como modelado na lista de recursos das Tabelas 5.7 e

93 Figura 5.3: Serviços e agentes modelados 80

94 Papel Serviço Pre-condições Pós-condições Entrada Saída Assistente Tratar Emergência Aguda de emergência cia aguda Ocorrer um evento Evento de emergen- de Emergencia aguda Assistente Pessoal Tratar Desvio de Longo Prazo Confirmar Emergência Avisar Pessoa Assistida sobre o envio de dados Ocorrer um evento de desvio de longo prazo Receber uma mensagem requisitando confirmação de emergência Receber Mensagem com a informação de que dados foram enviados para o centro de despacho. Emergencia informada ou não e o evento não será tratado novamente Desvio informado, o evento não será tratado novamente Confirmar a emergencia em no máximo 30 segundos Evento de desvio de longo prazo mensagem requisitando confirmação de emergência nenhuma Mensagem com a informação de que dados foram enviados para o centro de despacho. Envio de notificação da Emergencia ao centro de despacho caso ela seja confirmada Envio de notificação da desvio de longo prazo ao serviço sócio médico Emergência confirmada ou cancelada pela pessoa assitida Confirmar recebimento da mensagem Tabela 5.10: Modelo de Serviços (GAIA) 81

95 Capítulo 6 Arquitetura e Implementação No capítulo 5 foram apresentadas as modelagens dos agentes e dos serviços. Conforme apresentado na metodologia de trabalho (Seção 4.1), os resultados das duas modelagens serão utilizados na implementação para compor uma solução única. A modelagem dos dados foi realizada na fase de desenvolvimento. Neste capítulo será apresentado um modelo de dados e a ontologia que o define. Por meio da ontologia, a semântica dos objetos pode ser preservada ao longo das camadas (serviços e agentes). Além disso, é importante a definição da ontologia para a troca de mensagens entre os agentes, garantindo também a semântica das informações entre os agentes. O início deste capítulo apresenta a arquitetura geral do sistema, o modelo de componentes, uma visão geral da implementação, o modelo de dados e outras características comuns aos agentes e aos serviços. Ao final será apresentada a implementação dos serviços e dos agentes. 6.1 Arquitetura Proposta A arquitetura proposta é uma combinação dos estilos arquiteturais orientado a serviços e sistemas multi-agentes em que os serviços representam o meio com o qual os agentes podem interagir. O sistema é composto vários componentes imersos em um ambiente que permite a interação entre eles. O sistema cumpre sua função pela interação entre os diferentes componentes Tipos de Componentes Foram definidos três tipos de componentes: Componentes de serviços: disponibilizam serviços no ambiente da aplicação. Componentes de recursos: disponibilizam entidades, APIs ou qualquer outro recurso que o sistema necessite. Componentes agentes: encapsulam os agentes que compõem o sistema. 82

96 Os componentes de serviço podem depender de serviços e/ou recursos disponibilizados por outros componentes, porém não devem depender de nenhum agente. Os componentes de recurso não agem no ambiente, são componentes estáticos utilizados apenas para resolver dependências de recursos pelo meio. Os agentes disponibilizados no ambiente podem depender de serviços, de outros agentes e de recursos disponibilizados por outros componentes. Os agentes interagem uns com os outros de maneira indireta, manipulando o meio pela invocação de serviços publicados pelos componentes de serviço, ou de maneira direta via troca de mensagens. Assim podemos ver o sistema multi-agentes como uma unidade orquestrando os serviços disponibilizados no ambiente para cumprir os objetivos da aplicação Componentes de Infra-estrutura O sistema possui alguns componentes particulares que são utilizados como componentes auxiliares pelos demais: Ontologia: todos os componentes compartilham o mesmo modelo de dados baseado numa mesma ontologia. Esse modelo é disponibilizado no ambiente através de um componente de recurso. O modelo de dados compartilhado permite fluxo das informações e a integração entre os componentes de diferentes estilos arquiteturais sem a necessidade de conversão de dados (Seção 6.3). Barramento de contexto: conforme proposto na arquitetura do EMERGE (Seção 2.2.2), o sistema deve contar com um barramento de contexto onde os eventos do sistema serão publicados, esse barramento foi modelado como uma estrutura de tópicos (publish-subscribe) que pode ser acessado por um serviço. Para maiores detalhes sobre a implementação desse componente (Seção 6.4). Páginas amarelas de serviços (registry): Serviço para publicação de serviços no ambiente. Esse serviço permite buscas no catálogo de serviços e permite a realização da ligação entre um serviço provido e seus consumidores. Este serviço é provido pelo ambiente Tecnologias Utilizadas Para a implementação da arquitetura proposta, foram utilizadas a plataforma OSGi (Seção 3.2.2) e a plataforma JADE (Seção 3.1.6). O contêiner da plataforma JADE foi instalado no ambiente OSGi como um bundle e os agentes interagem com a plataforma JADE por meio de serviços OSGi disponibilizados por esse bundle. Os diversos componentes apresentados foram implementados como bundles do OSGi: os serviços foram implementados como serviços OSGi; os agentes JADE foram encapsulados em bundles OSGi. A Figura 6.1 apresenta as plataformas utilizadas para implementar o sistema. As Seções 6.6 e 6.7 detalham cada um desses componentes. 83

97 6.1.4 Arquitetura Interna dos bundles Os bundles de agente e de serviços utilizam internamente uma arquitetura em camadas, as seguintes camadas são obrigatórias a esses bundles: Camada de integração: camada responsável por publicar o serviço no ambiente OSGi, Camada de negócio: esta camada contém as interfaces dos serviços publicados, as implementações dessas interfaces e classes auxiliares relacionadas à lógica de negócio do serviço. Dependendo dos requisitos atendidos por cada bundle, podem ser encontradas ainda as camadas de: Apresentação: nesta camada estão as implementações das telas utilizadas no trabalho. Persistência: nesta camada ficam as classes relacionadas à persistência do bundle caso seja necessário Estrutura Interna dos bundles Os bundles implementados neste trabalho possuem algumas padronizações em sua estrutura interna de disposição de arquivos de configuração, pacotes e diretórios. Foram definidos alguns nomes de pacotes padronizados para armazenar classes relacionadas às camadas de integração, apresentação e persistência. São eles: br.unb.cic.aal.bundle : esse pacote e seus subpacotes possuem as classes relacionadas à camada de integração. Exemplo: classes de inicialização do bundle. br.unb.cic.aal.util : contém as classes utilitárias do bundle. Figura 6.1: Plataformas utilizadas 84

98 br.unb.cic.aal.ui.util: contém as classes utilitárias da camada de apresentação. br.unb.cic.aal.ui: esse pacote e seus subpacotes contém as classes releacionadas à camada de apresentação. br.unb.cic.aal.persistence: esse pacote e seus subpacotes contêm as classes relacionadas à camada de persistência. Os demais subpacotes de br.unb.cic.aal são considerados da camada de negócio. Caso o bundle precise de algum parâmetro configurável, esse deve ser definido no arquivo config.properties armazenado no diretório raiz cada bundle. As mensagens exibidas pelo sistema são configuráveis por meio do arquivo de mensagens chamado messages.properties presente no diretório raiz de cada bundle. Recursos estáticos tais como imagens e sons devem ser armazenados no diretório resources de cada bundle ou um subdiretório deste. Vale ressaltar que o único diretório obrigatório é o diretório META-INF, pois neste estará contido o arquivo MANIFEST.MF, exigido pela plataforma OSGi para a implantação dos bundles (Seção 3.2.2), os demais diretórios e pacotes apresentados só estarão presentes caso sejam relevantes ao bundle que o contém. Por exemplo, um bundle que não possui camada de apresentação certamente não terá o pacote br.unb.cic.aal.ui em sua estrutura interna. A Figura 6.2 apresenta a estrutura interna descrita nessa seção. Figura 6.2: Estrutura interna dos bundles 85

99 6.2 Visão Geral A Figura 6.3 apresenta uma visão geral do sistema com seus componentes, interações e dependências entre eles. Os diversos componentes apresentados nessa figura serão apresentados neste capítulo. Essas informações são apresentadas da seguinte maneira: As setas tracejadas representam os protocolos entre os agentes apresentados na Seção As setas pontilhadas ligam um conjunto de componentes a um componente específico. Essas setas representam dependências. Por exemplo, os agentes dependem dos serviços da plataforma JADE. As setas contínuas representam invocações de serviços. A seta sai do consumidor e chega ao serviço. Quando a seta possui ponta dupla, indica que a invocação do serviço é assíncrona, ou seja, a resposta do serviço se dá via call back. Os retângulos com bordas arredondadas representam bundles de serviços. O retângulo de borda quadrada (por exemplo, AALOntologyResource) representa um bundle de recurso. Os ícones de pessoas representam os bundles de agentes. 6.3 Modelo de Dados A modelagem dos dados foi feita de acordo com o modelo de dados do sistema apresentado no do documento de requisitos do EMERGE (Capítulo 4. System Data (Gross et al., 2009)) onde os dados são definidos e classificados de acordo com sua relevância para cada stakeholder do sistema. Como os objetos de uma ontologia JADE seguem o padrão Java Beans, tais objetos podem ser utilizados diretamente como as entidades para as diversas camadas do sistema. O modelo de dados apresentados na documentação do EMERGE foi mapeado como conceitos na ontologia do JADE. Além dos conceitos do sistema, foram mapeados predicados, eventos e ações dos agentes. Segue abaixo uma caracterização de cada um dos tipos de dados: Conceitos (Concept): representam as entidades do sistema, o modelo de dados. Predicados (Predicate): neste trabalho os predicados são utilizados exclusivamente na comunicação entre os agentes quando o objetivo da comunicação é fornecer informações. Eventos (Event): os eventos mapeados representam eventos de alto nível no sistema; o evento já vem preenchido com todos os conceitos associados à ocorrência do evento. Os eventos são publicados no barramento de contexto (Seção 2.2.2). Os eventos foram modelados como conceitos na ontologia JADE. 86

100 Figura 6.3: Visão geral do sistema 87

101 Ações de agentes (Agent Action): as ações dos agentes são utilizadas exclusivamente na comunicação entre agentes quando o objetivo da comunicação é uma requisição de ação ou uma ordem. As ações dos agentes são conceitos na ontologia JADE. As restrições e as relações entre os elementos da ontologia são determinados pela classe AALOntology. Uma única instância dessa classe é utilizada em toda a aplicação, o que é garantido pelo uso do padrão de projeto singleton utlizado na implementação (Gamma et al., 1995). O uso desse padrão de projeto na classe de ontologia é considerado uma boa prática já que essa classe é apenas um objeto descritivo que não guarda estado (Bellifemine, 2007). Para a representação da ontologia foi utilizada a ferramenta Protégé, um editor de ontologias gratuito e open source (Protégé, 2009). Para a criação dos objetos que representam a ontologia foi utilizado o plug-in Ontology Bean Generator do Protégé (Aart, 2009). A Figura 6.5 apresenta a visão da hierarquia de herança da ontologia. Os conceitos filhos de SystemDataSection representam os tipos dos atributos (propriedades) dos conceitos SystemData, que por sua vez representam os tipos dos atributos utilizados nos eventos conceitos filhos de Event. A Figura 6.4 representa essa hirarquia de composição dos principais conceitos da ontologia. Figura 6.4: Hierarquia de composição da ontologia As classes geradas a partir da ontologia foram disponibilizadas no ambiente OSGi por meio do bundle AALOntology. A Listagem 6.1 apresenta o arquivo MA- NIFEST desse bundle; observe que as dependências relativas à bibliotecas java, JADE ou OSGi não serão estão presentes. Repare ainda que esse MANIFEST não possui a diretiva Bundle Activator, ou seja, é um bundle de recursos. Listagem 6.1: MANIFEST.MF Bundle AALOntology Manifest Version : 1. 0 Bundle Name: AAL Ontology Export Package : br. unb. c i c. aal. ontology Import Package : (... ) Bundle SymbolicName : AALOntologyResourceBundle Bundle Version :

102 Figura 6.5: Estrutura de herança da ontologia

103 6.4 Barramento de Contexto O barramento de contexto apresentado na Seção foi implementado por meio de um serviço OSGi. A interação com o barramento de contexto se dá de uma maneira publish-subscribe; os interessados em um determinado tipo de evento se increvem no tópico que recebe tais eventos. Um tópico é uma fila de mensagens volátil onde objetos podem ser adicionados. Cada tópico é destinado a receber um determinado tipo de evento. O barramento de contexto possui tópicos fixos e tópicos configuráveis. Os tópicos não podem ser removidos e estão sempre disponíveis no barramento. O barramento implementado possui os seguintes tópicos fixos: Emergency: tópico destinado a receber os eventos de emergência aguda. LongTermDeviation: tópico destinado a receber os eventos de desvio de longo prazo. All: os assinantes desse tópico recebem todos os eventos enviados ao barramento de contexto. O barramento permite ainda que tópicos adicionais sejam criados ou removidos e permite a listagem de todos os tópicos disponíveis no barramento. Para que os assinantes de um tópico sejam avisados é necessário que o serviço de barramento faça um chamada à cada elemento da lista de assinantes desse tópico. Para que que o barramento faça essa chamada é necessário que os assinantes implementem a interface Consumer disponibilizada pelo barramento. O barramento de contexto é implementado pelo bundle de serviço ContextBus. O acesso às operações de publicação, assinatura e listagem dos tópicos é feita por meio do serviço disponibilizado por esse mesmo bundle. A Listagem 6.2 apresenta uma versão resumida do arquivo MANIFEST do bundle que disponibiliza esse serviço. O arquivo apresentado não possui as informações de versão do componente nem do arquivo. O único pacote exportado por esse bundle contém a interface do serviço de acesso ao barramento e a interface Consumer mencionada anteriormente. Listagem 6.2: MANIFEST.MF Bundle ContextBus Bundle Name: ContextBus Bundle Activator : br. unb. c i c. aal. bundle. StartService Bundle SymbolicName : ContextBus Import Package : (... ), br. unb. c i c. aal. ontology Export Package : br. unb. c i c. aal. contextbus 6.5 Páginas amarelas O serviço de páginas amarelas é responsável por desacoplar a localização real do serviço de quem o consome. O modelo de interação entre componentes no ambiente OSGi é feito por meio de serviços. Devido a isso a plataforma já disponibiliza alguns 90

104 componentes típicos em uma arquitetura orientada a serviços, tais como os serviços de páginas brancas e de páginas amarelas. Este trabalho utiliza o serviço de páginas amarelas disponibilizado pela plataforma OSGi. Todo serviço é disponibilizado, buscado ou ligado por intermédio desse serviço de páginas amarelas. A Seção apresenta com mais detalhes essas operações. 6.6 Implementação dos serviços OSGi Esta seção apresenta a implementação dos serviços modelados na Seção 5.1. Conforme apresentado na seção de arquitetura (Seção 6.1 ) os serviços foram implementados como serviços OSGi (Seção 3.2.2). Para cada serviço modelado serão apresentadas as camadas que o compõe, as interfaces que publica, as dependências relativas aos demais componentes e os detalhes de implementação relevantes. Por breviedade, as dependências relacionadas às plataformas utilizadas (JADE e OSGi) serão omitidas na apresentação dos arquivos MANIFEST. Além disso, informações como versão do arquivo e dos componentes também serão omitidas. A ausência de informação nos arquivos serão representadas por (...) Bundles de Serviços Os bundles de serviço possuem as seguintes características comuns: A maioria dos serviços apresentados nesta seção dependem da ontologia apresentada na seção 6.3. Essa dependência pode ser verificada pela presença do pacote br.unb.cic.aal.ontology na diretiva Import-Package de seus respectivos arquivos MANIFEST Todos os serviços apresentados nessa seção possuem apenas um pacote na diretiva Export-Package de seus respectivos arquivos MANIFEST. Esse é o pacote que contém as interfaces dos serviços publicados por cada bundle. Todos possuem uma classe de ativação OSGi StartService na camada de integração. Essa classe de ativação é responsável por registrar os serviços com o ambiente de execução Serviço Confirmar Emergência O serviço Confirmar Emergência recebe como parâmetro um objeto do tipo Emergency (Seção 6.3) e apresenta uma interface à pessoa assistida pedindo confirmação da emergência dentro de um dado período de tempo (por exemplo, 20 segundos). Caso a pessoa assistida confirme a emergência ou o tempo para confirmação se esgote, o serviço deverá confirmar a emergência. Caso a pessoa assistida cancele a emergência dentro do período dado o serviço não confirma a emergência. Este serviço foi implementado pelo bundle ConfirmEmergencyService. A Listagem 6.3 apresenta o arquivo MANIFEST deste bundle. Este bundle possui uma 91

105 camada de apresentação responsável por exibir uma tela por meio da qual a emergência pode ser confirmada ou cancelada (Figura 6.6). Figura 6.6: Tela de confirmação ou cancelamento de emergência Listagem 6.3: MANIFEST.MF Bundle ConfirmEmergencyService Bundle Name: ConfirmEmergencyService Bundle SymbolicName : ConfirmEmergencyService Bundle Activator : br. unb. c i c. aal. bundle. StartService Import Package : (... ), br. unb. c i c. aal. ontology Export Package : br. unb. c i c. aal. service. e l d e r l y. confirmation Serviços Detectar Alarme e Detectar Emergência A função dos dois serviços é monitorar o barramento de contexto esperando o surgimento de um evento de emergência aguda. Não foi modelado um evento específico para alarme manual, devido a isso a funcionalidade do serviço de detecção de alarme é satisfeita pela a implementação do serviço de detecção de emergência apenas. Este serviço utiliza o padrão Observer (Gamma et al., 1995) para avisar seus observadores de maneira síncrona quando da ocorrência de um evento de emergência aguda. Este serviço é implementado pelo bundle DetectEmergencyService. A Listagem 6.4 apresenta seu arquivo MANIFEST. Esse bundle importa o pacote do barramento de contexto além do pacote de ontologia. Esse pacote importado contém a interface do serviço que provê acesso ao barramento de contexto e à interface Consumer, cuja implementação é exigida pelo serviço do barramento de contexto para que se possa realizar o call back às classes que monitoram eventos. Listagem 6.4: MANIFEST.MF Bundle DetectEmergencyService Bundle Name: DetectEmergencyService Bundle SymbolicName : DetectEmergencyService Bundle Activator : br. unb. c i c. aal. bundle. StartService Import Package : (... ) br. unb. c i c. aal. ontology, 92

106 br. unb. c i c. aal. contextbus Export Package : br. unb. c i c. aal. service. emergency. detection Serviço Detectar Desvio Este serviço monitora os eventos de desvios de longo prazo ( LongTermDeviation, Seções 6.3 e 2.2.1) no barramento de contexto. Da forma análoga ao serviço de Detecção de Emergência, este serviço faz uso do padrão observer e avisa de maneira síncrona todos os seus observadores assim que surge um evento de desvio de longo prazo (Gamma et al., 1995). Este serviço foi implementado pelo bundle DetectLongTermDeviationService, a Listagem 6.5 apresenta o arquivo MANIFEST deste bundle. Ainda de forma análoga ao serviço de detecção de emergência, este bundle importa o pacote do barramento de contexto para consumir o serviço disponibilizado pelo barramento. Listagem 6.5: MANIFEST.MF Bundle DetectLongTermDeviationService Bundle Name: DetectLongTermDeviationService Bundle SymbolicName : DetectLongTermDeviationService Bundle Activator : br. unb. c i c. aal. bundle. StartService Import Package : (... ) br. unb. c i c. aal. ontology, br. unb. c i c. aal. contextbus Export Package : br. unb. c i c. aal. service. l t d. detection Serviço Avisar envio de notificação ao centro de despacho ou serviço sócio-médico Ao ser invocado, este serviço exibe uma interface informando a pessoa assistida sobre informações enviadas. Essa informação tem dois destinos possíveis: serviço sócio-médico ou centro de despacho. Este serviço foi implementado pelo bundle InformNotificationSentService. A Listagem 6.7 apresenta o arquivo MANIFEST deste bundle. Repare que este bundle não tem dependência com os demais bundles do sistema. Este bundle posssui uma camada de apresentação contendo a tela para informação sobre envio de dados. A Figura 6.7 mostra um exemplo dessa tela. Além da interface do serviço, o pacote exportado contém uma enumeração listando as possíveis mensagens de informação. A Listagem 6.6 apresenta o código dessa enumeração. Listagem 6.6: NotificationType.java Bundle InformNotificationSentService public enum NotificationType { Dispathcer, SMSC } Listagem 6.7: MANIFEST.MF Bundle InformNotificationSentService 93

107 Figura 6.7: Tela de informação sobre o envio de uma notificação Bundle Name: InformNotificationService Bundle SymbolicName : InformNotificationService Bundle Activator : br. unb. c i c. aal. bundle. StartService Import Package : (... ) Export Package : br. unb. c i c. aal. service. e l d e r l y. n o t i f i c a t i o n Serviços Enviar Dados Despacho e Enviar Dados SSM O serviço Enviar Dados Despacho é responsável por persistir os dados relacionados à emergência e em seguida encaminhar esses dados para o serviço de despacho. De forma análoga, o serviço Enviar Dados SSM irá persistir os dados e enviá-los ao serviço sócio-médico. Cada um desses serviços é implementado por um bundle. O serviço Enviar Dados Despacho é implementado pelo bundle SendEmergencyDataService (Listagem 6.8). Por sua vez, o serviço Enviar Dados SSM é implementado pelo bundle SendLongTermDataService (Listagem 6.9). Os dois bundles possuem camada de persistência. Os dados são persistidos em arquivos e o diretório onde esses arquivos serão persistidos pode ser configurado no arquivo config.properties do bundle de cada serviço. O envio dos dados ao centro de despacho e ao serviço sócio-médico é simulado por meio da escrita de uma mensagem no console do OSGi (saída padrão). Em uma implementação real essa comunicação poderia ser feita via internet ou por rede de telefonia móvel (GSM, por exemplo). Listagem 6.8: MANIFEST.MF Bundle SendEmergencyDataService Bundle Name: SendEmergencyDataService Bundle SymbolicName : SendEmergencyDataService ; singleton := true Bundle Activator : br. unb. c i c. aal. bundle. StartService Export Package : br. unb. c i c. aal. service. emergency. send Import Package : (... ) br. unb. c i c. aal. ontology Listagem 6.9: MANIFEST.MF Bundle SendLongTermDataService Bundle Name: SendLongTermDataService Bundle SymbolicName : SendLongTermDataService ; singleton := true 94

108 Bundle Activator : br. unb. c i c. aal. bundle. StartService Export Package : br. unb. c i c. aal. service. l t d. send Import Package : (... ) br. unb. c i c. aal. ontology 6.7 Implementação dos agentes JADE Nesta seção serão apresentadas as implementações dos agentes na plataforma JADE. A primeira parte apresenta o encapsulamento dos agentes em bundles OSGi; em seguida, serão apresentadas as trocas de mensagens entre os agentes especificando os tipos (Seção 3.1.6), o formato e os possíveis sequenciamentos das mensagens (conversações). Por último, serão apresentados os detalhes de implementação de cada agente Bundles de Agentes Para que os agentes JADE sejam implantados dentro do ambiente OSGi de maneira integrada, o contêiner da plataforma JADE deve ser instalado no ambiente OSGi encapsulado em um bundle. Dessa forma, os agentes podem ser instalados no ambiente OSGi por meio de bundles e registrados no contêiner JADE por meio de um serviço OSGi. Os bundles de agentes possuem as seguintes características comuns: Todos os agentes utilizam a ontologia, ou seja, todos possuem o pacote br-.unb.cic.aal.ontology na diretiva Import-Package de seus respectivos arquivos MANIFEST. Todos possuem uma classe de ativação OSGi StartAgent na camada de integração. Essa classe de ativação é responsável por registrar os agentes na plataforma JADE. Cada agente é implementado por uma classe subclasse de AALAgent, classe abstrata presente no pacote br.unb.cic.aal.agent. Essa classe abstrata provê métodos para armazenar os objetos de configuração dos agentes e o objeto de comunicação com o ambiente OSGi (BundleContext, Seção 3.2.2). As classes que representam os agentes ficam dentro do pacote br.unb.cic-.aal.agent.impl. As classes que representam os comportamentos dos agentes ficam dentro do pacote br.unb.cic.aal.behaviour (Behaviours, Seção 3.1.6). Todos os bundles de agentes possuem o parâmetro agent.name em seu arquivo config.parameters. Esse parâmetro fornece o nome que será utilizado para registrar o agente no contêiner JADE. A Listagem 6.10 apresenta o código da classe StartAgent, onde o serviço OSGi provido pelo bundle do contêiner JADE é utilizado para registrar um agente nesse contêiner. Primeiramente é obtida uma instância do serviço JadeRuntimeService; 95

109 em seguida, o método acceptnewagent é invocado com o nome do agente e sua instância passados como parâmetro. Esse método retorna um objeto do tipo AgentController que fornece o método start por meio do qual a thread de execução do agente é iniciada. Listagem 6.10: StartAgent.java package br. unb. c i c. aal. bundle ; import jade. osgi. s ervice. runtime. JadeRuntimeService ; import jade. wrapper. AgentController ; import org. o s g i. framework. BundleActivator ; import org. osgi. framework. BundleContext ; import org. o s g i. framework. ServiceReference ; import br. unb. c i c. aal. agent. impl. ElderlyAgent ; import br. unb. c i c. aal. u t i l. ConfigParameters ; public class StartAgent implements BundleActivator public void s t a r t ( BundleContext context ) throws Exception { //Obtendo uma instância do s e r v i ç o de r e g i s t r o JADE String jrsname = JadeRuntimeService. class. getname ( ) ; ServiceReference jrsref = context. getservicereference ( jrsname ) ; JadeRuntimeService j r s = ( JadeRuntimeService ) context. getservice ( jrsref ) ; // Instanciando o agente e re gi str an do o na plataforma JADE ElderlyAgent elderlyagent = new ElderlyAgent ( context ) ; AgentController ac = j r s. acceptnewagent ( ConfigParameters. getinstance ( ). getconfig ( ConfigParameters.AGENT_NAME), elderlyagent ) ; } // Iniciando o agente ac. s t a r t ( ) ; public void stop ( BundleContext c o n t e x t ) throws Exception { } Troca de mensagens Nesta seção serão apresentadas os formatos e os sequenciamentos das mensagens trocadas entre os agentes. Foram utilizadas as informações do modelo de interações apresentado na Tabela 5.4 da Seção 5.2 juntamente com a estrutura organizacional apresentada nessa mesma seção. Para cada protocolo será apresentado um exemplo, a sequencia, os dados trocados (predicados, conceitos e ações) e a natureza das mensagens (Seção 3.1.4). Protocolo PedirConfirmacao Este protocolo tem início quando o papel Assistente de Emergência detecta um evento de emergência ( Emergency, Seção 6.3), seja ele proveniente de detecção automática ou 96

110 de alarme manual. Nesse momento o Assistente de Emergência solicita ao agente que desempenha o papel de Assistente Pessoal que realize a ação de confirmar a emergência junto à pessoa assistida. Assim que a resposta da confirmação da emergência estiver disponível o Assistente Pessoal informa ao Assistente de Emergência se a emergência foi ou não confirmada. A seguir será detalhado o protocolo com os atos de fala (Seção 3.1.4) e os objetos da ontologia utilizados. No protocolo abaixo a letra E representa o Assistente de Emergência e a letra P representa o Assistente Pessoal. 1. E: Inicia o protocolo fazendo uma solicitação a P e muda do estado REQUEST_- CONFIRMATION para o estado WAITING_REPLY (nesse estado, o agente aguarda a resposta de sua solicitação). Ato de fala: REQUEST Conteúdo: ação ConfirmEmergency. Essa ação contém o evento Emergency 2. P: Recebe solicitação para a ação ConfirmEmergency, confirma a emergência e envia a resposta a E. Ato de fala: INFORM Conteúdo: predicado EmergencyConfirmed, informando se a emergência foi ou não confirmada. 3. E: Recebe a resposta, sai do estado WAITING_REPLY e encerra o protocolo. A Figura 6.8 ilustra o protocolo. Figura 6.8: Protocolo PedirConfirmacao Protocolo EnviarNotificacao Este protocolo tem início quando o Assistente de Emergência envia dados relacionados a eventos de emergência ( Emergency ) ou de desvios de longo prazo ( LongTermDeviation ). Após o envio dos dados o Assistente de Emergência deve informar ao Agente Pessoal sobre o envio e sobre o tipo de dado enviado. O envio e o tipo de dado são informados pelo envio dos seguintes predicados nas mensagens: EmergencySent: informa que foram enviados dados do evento de emergência ao centro de despacho. 97

111 LongTermDeviationSent: informa que foram enviados dados do evento de desvio de longo prazo ao serviço sócio-médico. A seguir será detalhado o protocolo com os atos de fala (Seção 3.1.4) e os predicados utilizados. No protocolo abaixo a letra E representa o Assistente de Emergência e a letra P representa o Assistente Pessoal. 1. E: Inicia o protocolo após o envio das informaçoes ao serviço sócio-médico ou ao centro de despacho. Ato de fala: INFORM Conteúdo: predicado EmergencySent ou LongTermDeviationSent 2. P: Recebe a informação Conteúdo: predicado EmergencyConfirmed, informando se a emergência foi ou não confirmada. A Figura 6.9 ilustra o protocolo. Figura 6.9: Protocolo EnviarNotificacao 6.8 Comportamentos Conforme apresentado na Seção 3.1.6, os agentes implementados utilizando a plataforma JADE agem conforme descrito nas classes que representam comportamentos (behaviours). Dessa forma, os artefatos produzidos durante a modelagem devem ser utilizados para implementar os comportamentos JADE. Os principais artefatos utilizados foram as tabelas de descrição dos papéis, o modelo de agentes e modelo de serviços (Tabelas 5.5,5.7, 5.9 e 5.10). O modelo de agentes foi utilizado para definir o nome do agente e o papel que representa no sistema. O modelo de serviços foi utilizado como informação complementar às expressões liveness apresentadas nas tabelas de cada papel para modelar os comportamentos dos agentes. As expressões safety foram utilizadas para determinar restrições de funcionamento e implementação dos comportamentos dos agentes. Cada propriedade liveness dos papéis foi subdivida e cada porção da expressão resultante dessa divisão foi utilizada para implementar um comportamento. Para cada porção paralela em uma expressão liveness foi implementado um comportamento paralelo. Exemplo: (InvocarDetectarAlarme InvocarDetectarEmergencia) ω.pedirconfirmacao.[invocarenviardadosdispatcher.enviarnotificacao] (InvocarDetectarDesvios) ω.invocarenviardadosssm.enviarnotificacao 98

112 Com base nessa expressão podem ser identificados dois comportamentos paralelos. O primeiro executará as atividades e protocolos representados pela primeira parte da expressão: (InvocarDetectarAlarme InvocarDetectarEmergencia) ω.pedirconfirmacao.[invocarenviardadosdispatcher.enviarnotificacao] E o segundo comportamento executará as atividades e protocolos descritos por: (InvocarDetectarDesvios) ω.invocarenviardadosssm.enviarnotificacao Conforme apresentado na Seção 3.1.6, a plataforma escalona a execução de comportamentos paralelos de forma não-preemptiva, ou seja, o comportamento não é interrompido até que retorne do seu método action. Dessa forma, um comportamento muito demorado, ou que faça operações que bloqueiam o comportamento por um tempo grande ou indeterminado, (por exemplo: comportamentos que executam os protocolos) não deve ser escalonado pela plataforma JADE, pois os demais comportamentos poderiam passar longos períodos sem oportunidade de serem executados. Para resolver esse problema foi utilizado o ThreadedBehaviour, classe que envelopa (wrapper) o comportamento e o lança em uma thread dedicada, propiciando um paralelismo preemptivo. Para identificar quando um comportamento deve ser ou não executado em uma thread dedicada foram analisadas as seguintes características: Comportamento participa de uma conversação: caso o comportamento precise inciar um protocolo e esperar pela resposta do outro participante. Comportamento dura um tempo indeterminado: caso o comportamento consuma serviços que aguardam a interação humana (a pessoa assistida por exemplo). Por exemplo, o primeiro comportamento do exemplo anterior inicia o protocolo Pedir- Confirmacao, o que implica que esse comportamento deve aguardar o recebimento de uma resposta por parte do outro participante. Dessa forma esse comportamento foi subdividido em mais dois comportamentos; a seguir estão apresentadas as expressões resultantes: 1. (InvocarDetectarAlarme InvocarDetectarEmergencia) ω 2. PedirConfirmacao.[InvocarEnviarDadosDispatcher.EnviarNotificacao] O comportamento representado pela segunda expressão tem sua execução vinculada à execução do primeiro comportamento. A primeira parte da expressão desse comportamento executa repetidamente enquanto a segunda parte executa apenas uma vez para cada execução do primeiro. Assim, o segundo comportamento é lançado em uma thread ao final da execução do comportamento. Os exemplos utilizados nesta seção são relativos às expressões livness do papel Assistente de Emergência. Nas seções a seguir serão apresentados os agentes, seus comportamentos e o tipo de comportamento JADE (CyclicBehaviour, OneShotBehaviour, etc.) utilizado para implementar cada um deles. 99

113 6.8.1 Agente EmergencyAgent Este agente implementa o papel Assistente de Emergência (Tabela 5.7). O bundle que o encapsula é o EmergencyAgentBundle. Este agente cumpre seus objetivos participando de protocolos e consumindo serviços. A sequência de invocação dos serviços e a participação nos protocolos é determinada pelos comportamentos do agente. Conforme exemplificado na Seção 6.8, os comportamentos foram implementados por meio das expressões liveness do agente. Os exemplos da Seção 6.8 demonstram como foram separadas as porções das expressões para cada comportamento deste agente. A seguir, serão detalhados cada um desses comportamentos. Os nomes dos comportamentos são os nomes das classes que os implementam. MonitorAcuteEmergencyBehaviour Esse comportamento foi identificado pela separação da expressão liveness em porções executadas em paralelo e em seguida pela separação da expressão por protocolos que iniciam conversações. A expressão que representa esse comportamento indica que este deve monitorar eventos de emergência, sejam eles oriundos do alarme manual ou da detecção automática, e em seguida executar o restante da expressão que foi implementado como um comportamento em thread dedicada. A expressão que o representa é: (InvocarDetectarAlarme InvocarDetectarEmergencia) ω Para executar essa tarefa, este comportamento consome o serviço DetectEmergency- Service (Seção 6.6.3) e aguarda o call back desse serviço informando a ocorrência de um evento de emergência aguda. Caso ocorra tal evento, o comportamento lança o comportamento RequestConfirmationBehaviour em uma thread dedicada, compartilhando com este o objeto que representa o evento. Este comportamento executa paralelamente com os demais e é executado repetidas vezes. Devido a isso esse comportamento foi implementado utilizando a superclasse Cyclic- Behaviour (Seção 3.1.6). RequestConfirmationBehaviour Esse comportamento foi identificado devido à utilização do protocolo PedirConfirmacao que consiste em uma conversação. Conforme apresentado na Seção 6.8 comportamentos que participam de uma conversação devem ser implementados em uma thread dedicada. Esse agente realiza os seguintes passos: 1. Recupera o evento de emergência. 2. Envia uma mensagem ao agente ElderlyAgent pedindo confirmação do evento de emergência (protocolo PedirConfirmacao ). 3. Aguarda a resposta. Essa resposta deve chegar dentro de 30 segundos; essa regra foi extraída das propriedades safety do Assistente de Emergência. 4. Caso receba uma mensagem cancelando a emergência dentro do intervalo de 30 segundos, a emergência é cancelada; caso contrário, é confirmada. 5. Caso a emergência seja confirmada, este comportamento executa o serviço EmergencyDataForwardService (6.6.6). 100

114 6. O comportamento envia uma mensagem ao agente ElderlyAgent (protocolo EnviarNotificacao ) caso a emergência tenha sido confirmada. A expressão que o representa é dada por: PedirConfirmacao.[InvocarEnviarDadosDispatcher.EnviarNotificacao] Este comportamento executa uma única vez para cada thread lançada e possui dois estados: 1. Pedindo confirmação (REQUEST_CONFIRMATION). 2. Aguardando resposta (WAITING_REPLY). Este comportamento foi implementado como subclasse de Behaviour e é encerrado quando o último estado também é encerrado. MonitorLongTermDeviationBehaviour Este comportamento monitora eventos de desvios de longo prazo, envia os dados ao serviço sócio médico e envia uma mensagem ao agente ElderlyAgent informando sobre o envio das informações. Esse comportamento é descrito pela seguinte expressão: (InvocarDetectarDesvios) ω.invocarenviardadosssm.enviarnotificacao Essa porção da propriedade liveness do Assistente de Emergência representa uma execução em paralelo (separada da outra porção pelo operador ). Esse serviço não tem nenhuma operação que leve um tempo indeterminado nem participa de protocolos que envolvem conversações (envio e aguardo de mensagens). Este comportamento foi implementado como subclasse de CyclicBehaviour, pois uma parte do comportamento precisa estar em constante execução e o restante do comportamento só é executado após a detecção de um evento de desvio de longo prazo Agente ElderlyAgent Este agente desempenha o papel Assistente Pessoal. Esse papel tem um comportamento tipicamente reativo, sua expressão liveness possui duas porções paralelas, cada uma delas representa um estado de espera em algum protocolo, ou seja, nos dois casos o agente está esperando a chegada de uma determinada mensagem para reagir. Conforme apresentado na Tabela 5.5 da Seção 5.2 a expressão liveness desse agente é: (PedirConfirmacao.InvocarConfirmarEmergência.PedirConfirmacao) ω (EnviarNotificacao.InvocarAvisarNotificação) ω Conforme apresentado na Seção 6.8, essa expressão deve ser quebrada em duas porções utilizando o símbolo de paralelismo como separador. Em seguida, a primeira metade deve ser subdividida devido à chamada a um serviço que aguarda interação humana ( Confirmar Emergência,Seção 6.6.2). Abaixo estão as duas metades e suas subdivisões: PedirConfirmacao InvocarConfirmarEmergência.PedirConfirmacao EnviarNotificacao.InvocarAvisarNotificação A seguir, serão apresentados cada um dos comportamentos que representam essas expressões. Os nomes dos comportamentos representam os nomes das classes que os implementam. 101

115 ReceiveConfirmationRequestBehaviour Este comportamento é responsável por aguardar a chegada de uma mensagem do protocolo PedirConfirmacao e em seguida lançar o comportamento ConfirmEmergencyBehaviour em uma thread dedicada envelopando-o em um ThreadedBehaviour. Esse comportamento se repete indefinidamente, portanto é implementado como subclasse de CyclicBehaviour. ConfirmEmergencyBehaviour Esse comportamento é responsável por confirmar a emergência e enviar a resposta de volta ao agente que enviou a mensagem de requisição de confirmação. Esse comportamento é composto pelos seguintes passos: 1. Invocar o serviço Confirmar Emergência (Seção 6.6.2). Esse serviço recebe como parâmetro o tempo máximo que irá aguardar pela interação com o usuário. 2. Após a confirmação ou cancelamento ou término do tempo máximo, a resposta é enviada de volta ao remetente da mensagem. Esse comportamento é implementado como sublcasse de OneShotBehaviour, ou seja, executa uma vez e é encerrado. InformAssistedPersonBehaviour Este comportamento aguarda chegada de uma mensagem do protocolo EnviarNotificacao, em seguida invoca o serviço Avisar envio de notificação ao centro de despacho ou serviço sócio-médico de acordo com conteúdo da mensagem. Apesar desse serviço interagir com o usuário, ele não aguarda que o usuário forneça alguma informação, é um serviço meramente informativo, portanto não necessita que a expressão seja subdividida para que uma parte seja executada em thread separada. Este comportamento foi implementado como subclasse de CyclicBehaviour. 6.9 Cenário de execução: Detectar emergência aguda A Figura 6.10 apresenta um diagrama de sequência de chamada entre os componentes (serviços, agentes e componentes de infra-estrutura). A execução começa a partir do registro de um evento de emergência no barramento de contexto. No diagrama apresentado na Figura 6.10 a execução começa a partir de uma chamada originada no barramento de contexto informando o serviço de detecção de emergência sobre o surgimento de um evento de emergência aguda. O cenário ilustrado por esse diagrama é o cenário apresentado na Seção Repare que as chamadas que não bloqueiam a execução não possuem a representação do retorno. 102

116 Figura 6.10: Cenário Detectar emergência aguda 103