D D: DBS: Esenvolvimento de Uma Plataforma Multiagente Cognitiva para Bancos de Ados Autônomos O Caso Do Itter Plus T G

UNIVERSIDADE FEDERAL DE PERNAMBUCO
GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA
DESENVOLVIMENTO DE UMA PLATAFORMA

MULTIAGENTE COGNITIVA PARA BANCOS DE
DADOS AUTNOMOS: O CASO DO
DBSITTER PLUS
TRABALHO DE GRADUAO
Aluno: Davi Lyuma Anabuki (dla@cin.ufpe.br)

Orientadora: Patrcia Cabral de Azevedo Restelli Tedesco (pcart@cin.ufpe.br)
Setembro de 2006
Resumo
Este Trabalho de Graduao se prope a fazer alteraes na arquitetura do

DBSitter, um sistema multiagente (SMA) desenvolvido para auxiliar os administradores de
banco de dados no gerenciamento e monitorao de Sistemas de Gerenciamento de
Banco de Dados (SGBD), de modo a deix-lo de acordo com os padres da FIPA Foundation for Intelligent Physical Agents. As alteraes realizadas tm o intuito de tornar
o sistema mais interopervel e extensvel, permitindo a comunicao com agentes que
implementem os padres da FIPA com o mnimo de alteraes.
ii
Agradecimentos
Agradeo primeiramente minha famlia, por me dar o suporte necessrio para

que pudesse chegar aonde estou.
Agradeo tambm ao amigo Paulo Maciel, que me ajudou durante esta

caminhada.
Agradeo professora Patrcia, por todo o auxlio, pacincia e confiana,

indispensveis, durante este trajeto.
iii
ndice
1.
Introduo....................................................................................................................... 1
1.1
Objetivo .................................................................................................................. 2
1.2
Metodologia............................................................................................................ 2
1.3
Organizao do Documento ................................................................................... 3
2. Conceitos Bsicos........................................................................................................... 4
2.1. Computao Autnoma .......................................................................................... 4
2.2. Sistemas Multiagente.............................................................................................. 6
2.3. Computao Autnoma, Sistemas Multiagente e SGBD ....................................... 9
2.4
Metodologias de Desenvolvimento para Sistemas Multiagente........................... 10
2.4.1
Estudo de metodologias................................................................................ 11
2.4.2
A metodologia Gaia...................................................................................... 11
2.5
Os padres da FIPA.............................................................................................. 13
2.5.1
A arquitetura abstrata da FIPA ..................................................................... 14
2.5.2
A especificao da estrutura de mensagens.................................................. 15
2.5.3
A especificao da biblioteca de atos de comunicao ................................ 16
2.6
Concluses............................................................................................................ 16
3
Tecnologias utilizadas .................................................................................................. 18
3.1
O framework Jade................................................................................................. 18
4
O DBSitter Plus ............................................................................................................ 21
4.1
Requisitos ............................................................................................................. 21
4.2
A modelagem SMA .............................................................................................. 24
4.3
Experimentos e resultados.................................................................................... 36
4.4
Consideraes finais ............................................................................................. 37
5
Concluses e trabalhos futuros ..................................................................................... 38
5.1
Contribuies........................................................................................................ 38
5.2
Dificuldades.......................................................................................................... 38
5.3
Trabalhos futuros.................................................................................................. 38
Referncias bibliogrficas .................................................................................................... 39
Apndice A Especificao de Requisitos e Diagrama i* .................................................. 44
Apndice B Papis preliminares........................................................................................ 47
Apndice C Modelos de Interaes Preliminares.............................................................. 52
Apndice D Papis definitivos .......................................................................................... 54
Apndice E Modelo de Servios ....................................................................................... 58
iv
1. Introduo
A indstria de Tecnologia da Informao (TI) tem passado por um desenvolvimento

tecnolgico acentuado, com um aumento do poder computacional disponvel para os
usurios crescendo a uma taxa quase exponencial, o que vem a confirmar as previses
de Moore [44]. Esse crescimento tem possibilitado a automao cada vez maior de
tarefas, porm, tem gerado como subproduto um aumento da complexidade dos sistemas,
criando uma demanda cada vez maior por profissionais especializado para manuteno
dos mesmos.
Horn [4] cita como uma alternativa para esta demanda a criao de sistemas que se
auto-gerenciem. Uma das maneiras de atingir este objetivo construir sistemas
autnomos, que inicialmente poderiam ser aplicados a domnios especficos. Nesse
sentido, uma rea que traz grandes desafios a de Banco de Dados. Sendo alguns deles:
(1) o ambiente cada vez mais complexo, devido grande quantidade de variveis que,
em conjunto, afetam o desempenho do Sistema Gerenciador de Banco de Dados (SGBD);
(2) o tratamento de grandes volumes de informao e (3) necessidade de monitorao
constante.
Esse problema foi abordado por Carneiro [1] atravs da formulao do DBSitter, um
sistema multiagente (SMA) para monitorao e gerenciamento de SGBD. Este auxilia o
Administrador de Banco de Dados (ABD) no processo de manuteno do SGBD, atuando
ao encontrar um problema, seja atravs da sugesto de uma soluo ao ABD ou da
aplicao automtica de uma soluo adequada.
Este trabalho se prope a alterar o DBSitter de modo que ele esteja de acordo com a
padronizao adotada pela FIPA para SMA, utilizando a metodologia de desenvolvimento
SMA Gaia durante este processo.
1.1
Objetivo
Este documento tem visa apresentar os resultados obtidos da pesquisa realizada

durante a execuo deste trabalho de graduao, que teve os seguintes objetivos:
1. Reavaliao do problema do DBSitter [1] sob a tica de uma metodologia de
desenvolvimento orientado a agentes;
2. Adequao s normas de SMA sugeridos pela FIPA [13];
3. Prova de conceito atravs da implementao das mudanas sugeridas
utilizando o framework de desenvolvimento de SMA JADE [38].
1.2
Metodologia
Para a realizao deste trabalho foi realizado um estudo do problema abordado pelo
DBSitter, o que incluiu a gerao de um documento de requisitos e a gerao do
diagrama i* [42] do mesmo. Estudamos algumas das metodologias de desenvolvimento
multiagente existentes na atualidade, analisando suas caractersticas, e escolhendo uma
destas para aplicao no problema estudado.
Fizemos tambm um estudo da padronizao sugerida pela FIPA para SMA e

implementamos novos agentes para o DBSitter, de acordo com os padres que
consideramos relevantes, fazendo uso do framework JADE.
1.3
Organizao do Documento
Este documento est organizado da seguinte maneira:
Captulo 2 Apresenta alguns conceitos bsicos, como a noo de computao

autnoma e conceitos de SMA, assim como a relao entre eles. Fazemos tambm uma
breve discusso de algumas metodologias de desenvolvimento de SMA e uma descrio
dos padres adotados pela FIPA relevantes ao nosso estudo.
Captulo 3 Apresenta a tecnologia utilizada durante a implementao dos agentes do

nosso trabalho, o framework Jade.
Captulo 4 Apresenta o nosso trabalho, mostrando o que foi realizado e os resultados

obtidos.
Captulo 5 Apresenta nossas concluses e sugestes para trabalhos futuros.
2. Conceitos Bsicos
Este captulo tem como objetivo abordar os conceitos bsicos diretamente

relacionados ao nosso trabalho. Discutiremos um pouco sobre os conceitos de
computao autnoma e SMA e faremos uma breve discusso sobre o relacionamento
entre eles e de alguns conceitos sobre computao autnoma relacionada a bancos de
dados.
2.1. Computao Autnoma

Sistemas computacionais tm aumentado o seu poder de processamento em uma
escala quase exponencial. Os programas tm sido gerados de maneira a fazer uso desta
capacidad, automatizando cada vez mais tarefas. Entretanto, isso tem gerado o aumento
de complexidade dos sistemas, que necessitam cada vez mais de mo de obra
especializada para realizar sua gerncia e manuteno.
De acordo com Horn em seu manifesto de computao autnoma [4], a indstria de TI

est enfrentando este problema, da complexidade, e uma das maneiras encontradas para
combat-lo atravs da utilizao dos conceitos de computao autnoma.
O princpio da computao autnoma baseado no funcionamento do sistema

nervoso autnomo humano, que controla as funes bsicas do organismo (e.g.: a
respirao e a freqncia dos movimentos cardacos), permitindo que o crebro possa se
concentrar em funes de alto-nvel (e.g.: o destino de nossa caminhada). De maneira
similar, os sistemas computacionais autnomos se propem a permitir que o usurio
possa se concentrar em funes de alto-nvel, enquanto o sistema se encarrega de lidar
automaticamente com as funes bsicas.
O problema da automatizao do gerenciamento de recursos computacionais no

um problema novo [5]. H dcadas os componentes de sistemas e o software utilizado
tm evoludo para lidar com o aumento da complexidade do controle do sistema, do

compartilhamento de recursos e do gerenciamento operacional. A computao autnoma
considerada o prximo passo para lidar com os ambientes distribudos e complexos de
hoje.
Uma amostra da importncia dessa abordagem pode ser vista atravs do enfoque
recente da IBM, com um esforo que pde ser observado atravs da publicao do
manifesto de computao autnoma, onde so identificados os pontos chaves de um
sistema autonmico, e tenta atrair tanto a academia quanto a indstria a participarem
deste esforo.
O manifesto de computao autnoma identifica oito elementos chaves que devem

estar contidos em um sistema autnomo:
1. O sistema deve se conhecer;
2. O sistema deve se configurar e reconfigurar sob diferentes condies;
3. O sistema deve procurar maneiras de otimizar o seu funcionamento;
4. O sistema deve realizar algo alm da recuperao, ele deve estar preparado para
se recuperar de eventos rotineiros e extraordinrios;
5. O sistema deve ser um especialista em auto-proteo;
6. O sistema deve conhecer o ambiente e o contexto, agindo de acordo com os
mesmos;
7. O sistema no pode existir em um ambiente hermtico;
8. O sistema deve antecipar os recursos otimizados necessrios, enquanto mantm
sua complexidade escondida.
Em termos mais prticos, foi identificado por Kephart e Chess [3] que um sistema
autnomo tem como objetivo o auto-gerenciamento, que pode ser obtido atravs de
quatro aspectos, sendo eles: (1) auto-configurao, (2) auto-otimizao, (3) autorecuperao e (4) auto-proteo. Eles tambm identificam que um elemento autnomo
tpico, consiste em um ou mais elementos gerenciados em conjunto por um gerente
autnomo que os controla e representa. As caractersticas desses elementos autnomos,
que so autonomia, proatividade e interao baseada em objetivos so caractersticas de
agentes inteligentes [3] , o que indica a importncia que os conceitos de arquitetura
orientada a agentes podem ter em computao autnoma.
2.2. Sistemas Multiagente

Sistemas multiagente so, de acordo com Weiss [40], sistemas nos quais vrios
agentes inteligentes interagem, em busca de um conjunto de objetivos ou executam
algum conjunto de tarefas. Nesse contexto, agentes so entidades computacionais,
autnomas, que percebem o ambiente atravs de sensores e atuam sobre ele atravs de
atuadores. Inteligentes indica que os agentes perseguem seus objetivos e executam
tarefas que visam a otimizao de alguma medida de performance. E interagem indica
que os agentes podem ser influenciados por outros agentes ou talvez por humanos na
busca pelos seus objetivos e durante a execuo de suas tarefas.
Wooldridge [41] define agente de uma maneira mais refinada, indicando as seguintes
caractersticas de um agente: (1) so entidades de resoluo de problemas claramente
identificveis, com limites e interfaces bem-definidas; (2) so situados (embutidos) em um
ambiente particular eles recebem entradas de acordo com o estado de seus ambientes
atravs de sensores, e atuam no ambiente atravs de atuadores; (3) so projetados de
modo a executar um objetivo especfico eles tem objetivos particulares para atingir; (4)
so autnomos ou seja, eles tm controle tanto do seus estados internos como de seu
prprio comportamento; (5) so capazes de exibir um comportamento de resoluo de
problemas flexvel, na busca pelos seus objetivos de projeto. Eles precisam ser tanto
reativos (podem responder em tempo hbil s mudanas que ocorrem no seu ambiente)
como proativos (possveis de atuar antecipadamente de acordo com objetivos futuros).
Tanto Wooldridge [41] quanto Weiss [40] concordam que a rea de engenharia de
sistemas orientados a agentes ainda uma rea que no possui um conceito nico e
universal amplamente aceito para agentes. Ou seja, eles tentam se concentrar em
caractersticas que sejam necessrias, mas no suficientes, de modo a poder descartar
sistemas que no sejam claramente orientados a agentes, e poder classificar uma ampla
gama de SMA.
Franklin e Graesser, em [39], fazem uma avaliao de vrios sistemas orientados a

agentes e chegam seguinte formalizao para agentes:
Um agente autnomo um sistema situado dentro de um ambiente, e faz parte

dele, que consegue perceber este e atuar sobre ele, com o passar do tempo, em
busca de seus prprios objetivos, e de tal modo que ele influencie o que vai
perceber no futuro.
J Russell e Norvig, em [43] fazem a seguinte colocao:

A noo de um agente foi concebida para ser uma ferramenta para analisar
sistemas, no para ser uma caracterizao absoluta que divida o mundo em
agentes e no-agentes.
A pesquisa em torno de SMA tem crescido bastante nos ltimos anos, em especial na
rea de Engenharia de Software, na busca de uma metodologia que torne possvel a
adoo desta tecnologia em massa. Weiss [40] define como razes para o crescente
interesse em SMA: (1) as necessidades tecnolgicas e de aplicao, pois SMA oferecem
uma maneira de entender, gerenciar e usar sistemas distribudos de larga escala,
dinmicos, abertos e sem distribuio; (2) a viso natural de sistemas inteligentes
oferecida por SMA.
Alm disso, SMA tm a capacidade de oferecer as seguintes propriedades:
Aumento de velocidade e eficincia;
Aumento de robustez e confiana;
Aumento de escalabilidade e flexibilidade;
Diminuio de custos;
Aumento na velocidade de desenvolvimento e reuso.
Jennings, por sua vez, em [41], cita como caractersticas importantes do

desenvolvimento de SMA: (1) a sua capacidade de decomposio de problemas, (2) a
sua capacidade de abstrao, e (3) a capacidade de lidar com organizaes.
Mas, qual a razo de se utilizar SMA? E quais as suas aplicaes? Como Jennings
descreve em [41], a utilizao de SMA deriva da necessidade de alternativas para o
desenvolvimento de sistemas com um grau de complexidade cada vez mais alto, e o
paradigma de orientao a agentes, fornece mecanismos para decomposio, abstrao
e organizao.
A utilizao de SMA sugere a decomposio do problema em termos de agentes

autnomos, gerando uma representao natural de sistemas complexos que so
invariavelmente distribudos e que invariavelmente tem mltiplos focos de controle.
Em termos de abstrao, SMA oferecem uma abstrao que auxilia a diminuio da

distncia semntica entre as unidades de anlise utilizadas e o problema, existindo uma
correlao clara entre as noes de subsistemas e as organizaes de agentes.
Em termos de organizao, SMA possuem uma representao explcita de

relacionamentos organizacionais e de estrutura, alm de ter mecanismos computacionais
concomitantes para a formao, manuteno e remoo de organizaes. Esse poder de
representao permite uma maior adequao a sistemas complexos.
Huhns [40] cita como outras razes para estudar SMA:
Problemas utilizando SMAS so s vezes mais fceis de entender e mais fceis

de desenvolver, em especial quando o problema distribudo por si s. A
distribuio pode levar a algoritmos que no seriam descobertos atravs de uma
soluo centralizada.
Algumas vezes uma soluo centralizada impossvel, quando os atores

(organizaes) precisam manter as informaes o mais privado possvel.
A informao envolvida necessariamente distribuda e est em sistemas de

informao grandes e complexos nos seguintes sentidos:
1. So geograficamente distribudos;
2. Podem ter vrios componentes;
3. Podem ter um contedo muito grande;
4. Podem ter um escopo muito grande.
De acordo com isso, podemos dizer que SMA podem ter um papel importante no
desenvolvimento futuro de sistemas computacionais. Alm dessas caractersticas, e
essas motivaes, importante tambm salientar que SMA no so simplesmente
sistemas distribudos ou concorrentes. Eles possuem caractersticas prprias [18], como a
autonomia de cada agente, assim como a existncia de interaes de cunho econmico
entre os agentes, que os diferenciam de sistemas puramente distribudos. Sendo que eles
tambm no so simplesmente Inteligncia Artificial (IA), pois existe a importncia do

aspecto social, assim como no so somente teoria dos jogos ou a aplicao de teorias
sociais, mas um misto de ambos.
2.3. Computao Autnoma, Sistemas Multiagente e SGBD

Caractersticas que proporcionem algum grau de independncia da interveno
humana tm aumentado verso aps verso e historicamente os principais SGBD de
mercado j fizeram avanos na rea de automatizao de tarefas desde o final da dcada
de 1970, mas impulsionados pelas preocupaes dos laboratrios de pesquisa da IBM e
pela fora da concorrncia de mercado que isso gerou, apenas recentemente verdadeiras
inovaes vm sendo lanadas como caractersticas de autonomia.
Esses esforos
proporcionariam a criao de um novo conceito, o SGBDA Sistema de Gerenciamento

de Bancos de Dados Autnomo.
Duas iniciativas de pesquisa especficas na linha de autonomia em SGBD vm sendo

conduzidas por dois dos maiores fabricantes de software: o projeto SMART (SelfManaging and Resource Tuning) da IBM para o Banco de Dados DB2 e o projeto
AutoAdmin da Microsoft.
Entretanto, estas duas iniciativas de pesquisa no tm um foco especfico no

desenvolvimento de SGBDA baseado em agentes. Um esforo especfico nesse sentido
pode ser visto no trabalho desenvolvido por Bigus et al [45], Diao et al [46] e Costa e
Lifschitz [48] no desenvolvimento de sintonia para performance. Assim como pode ser
percebido em Carneiro [1, 2].
Lifschitz e Macedo [12] propem uma classificao das arquiteturas de integrao

entre agentes e SGBD, sendo elas: (1) em camadas (layered); (2) integrada (integrated) e
(3) embutida (built-in), conforme representadas na figura 2.1.
Figura 2.1 Arquiteturas para integrao de sistemas multiagente e SGBD - adaptado de [12]
A arquitetura em camadas representa a implementao de um sistema de agentes

que trabalha sobre o SGBD, sem a necessidade de alter-lo. Nesta arquitetura, o agente
funciona de maneira similar a um mediador, que recebe, manipula e traduz as requisies
ao SGBD.
A arquitetura integrada baseada na substituio dos componentes tradicionais

de um SGBD por subsistemas de agentes, onde estes subsistemas precisam apresentar
todas as funcionalidades dos componentes originais do SGBD.
A arquitetura built-in, considera o uso de um SGBD existente, onde os agentes

passam a interceptar chamadas do cdigo do banco, alterando-as. Nesse caso, os
agentes esto embutidos dentro do SGBD, usando os servios existentes fornecidos
pelos componentes do SGBD, enquanto incorporam novas funcionalidade.
Dentro desta classificao, tanto o DBSitter quanto o DBSitter Plus implementam

uma arquitetura baseada em camadas.
2.4
Metodologias de Desenvolvimento para Sistemas

Multiagente
Na seo anterior, comentamos sobre a necessidade da existncia de um esforo

na rea de Engenharia de Software, para que a adoo do paradigma orientado a
agentes pudesse acontecer. Nesta seo, iremos descrever alguns resultados dos
esforos das pesquisas existentes, refletidas nas metodologias de desenvolvimento.
10
De acordo com [17], no existe uma metodologia melhor do que outra, mas
simplesmente metodologias mais adequadas para cada caso. Podemos citar como
exemplo, a existncia de metodologias derivadas da extenso de diagramas de UML [31,
32] que podem ser adequadas ao desenvolvimento de sistemas em equipes que tenham
experincia no desenvolvimento com uso de UML, o que pode facilitar o processo de
transio. Existem metodologias que se baseiam na viso dos agentes como uma
comunidade, dando uma nfase maior comunicao entre os agentes [17], enquanto
outras atuam de maneira a resolver os problemas com foco nos agentes individuais,
sendo o comportamento do grupo uma conseqncia do comportamento dos agentes
individualmente [34, 35].
2.4.1 Estudo de metodologias

Para a escolha da metodologia a ser utilizada neste trabalho, fizemos um breve
estudo das metodologias disponveis. Optamos pela metodologia Gaia devido sua
abordagem top-down, que vislumbra o processo trabalhando com uma abordagem
inicialmente voltada para a organizao, em contraste com metodologias como MaSE
(Multiagente Systems Engineering) [36], cujo comportamento da sociedade de agentes
uma conseqncia do comportamento individual de cada componente.
Ela tambm foi escolhida em detrimento de metodologias que estendem UML,
como MAS-ML ou aUML, devido ao fato das mesmas no possurem o mesmo poder
expressivo em termos de organizao como Gaia.
Outro fato relevante na escolha de Gaia foi a metfora organizacional adotada pela
metodologia, que consideramos se adequar melhor modelagem do problema enfrentado
pelo DBSitter.
2.4.2 A metodologia Gaia

Gaia uma metodologia que tenta definir um mtodo completo e genrico
especificamente moldado para a anlise e o projeto de SMA. Ela d suporte tanto ao nvel
da estrutura do agente individual como da sociedade de agentes no desenvolvimento de
SMA. De acordo com Gaia, SMA so vistos como um nmero de agentes autnomos
11
interativos que vivem em uma sociedade organizada onde cada agente representa um ou
mais papis especficos. Sendo a estrutura do SMA definida em termos de um modelo de
papis. O modelo identifica os papis que os agentes devem representar dentro do SMA
e os protocolos de interao entre os diferentes papis.
A Metodologia Gaia tem seu processo dividido em cinco fases distintas, como
pode ser observado na figura 2.2. A fase de anlise, a fase de projeto de arquitetura e a
fase de projeto detalhado.
A fase de anlise tem como objetivo coletar e organizar as especificaes que

forma a base para o projeto da organizao computacional. Essa fase inclui:
A identificao dos objetivos das organizaes que constituem o sistema como

um todo e seu comportamento global esperado;
O modelo de ambiente
O modelo de papis preliminar
O modelo de interaes preliminar;
As regras que a organizao deve respeitar e enfatizar no seu comportamento

global.
O resultado da fase de anlise consiste em um modelo de ambiente, um modelo

de papis preliminar, um modelo de interaes preliminar e um conjunto de regras
organizacionais, que so utilizadas na fase de projeto.
A fase de projeto de arquitetura, por sua vez, inclui:
A definio da estrutura organizacional do sistema em termos de sua topologia e

regime de controle;
A derivao de padres organizacionais;
A finalizao dos modelos preliminares de papis e de interao.
Uma vez definidos estes artefatos, a fase de projeto detalhado pode ser iniciada, que
engloba:
A definio do modelo de agentes;
A definio do modelo de servios.
12
Figura 2.2 Modelos da metodologia Gaia e seus relacionamentos no processo Gaia adaptado de [17]
2.5
Os padres da FIPA
A FIPA [1] Foundation for Intelligent Physical Agents, uma organizao

internacional, cujo objetivo promover o desenvolvimento da indstria de agentes
inteligentes atravs da publicao de especificaes abertas de desenvolvimento, de
modo a favorecer a interoperabilidade entre agentes e sistemas baseados em agentes.
Durante o nosso estudo, consideramos relevantes os seguintes padres publicados

pela FIPA:
1. FIPA Abstract Architecture Specification A especificao do padro de

arquitetura abstrata da FIPA;
2. FIPA Agent Communication Language (ACL) Message Structure Specification A

especificao da estrutura de mensagens da linguagem de comunicao entre
13
agentes;
3. FIPA Communicative Act Library Specification A especificao de atos de

comunicao.
Ns consideramos estes trs padres importantes, pelo seguintes motivos: o padro

(1) define uma arquitetura multiagente que inclui elementos como um servio de pginas
brancas e um servio de pginas amarelas, que facilitam a descoberta de servios e de
agentes, alm de definirem os elementos bsicos de um sistema, de modo que seja o
mais simples e interopervel quanto possvel. O padro (2), por sua vez, define como
deve ser uma estrutura de mensagens para os agentes, de modo que agentes
implementados em plataformas diferentes possam se comunicar. E o padro (3) define o
tipo de comunicao que pode ser feita pelos agentes, de acordo com a teoria de atos de
fala [40].
2.5.1 A arquitetura abstrata da FIPA

A especificao de arquitetura da FIPA tem como objetivo promover o aumento da
interoperabilidade e do reuso. Para atingir esse objetivo, ela busca identificar os
elementos fundamentais que precisam estar presente nos SMA e os relacionamentos
entre eles, de modo a deixar claro como torn-los interoperveis.
Podemos citar como elementos importantes da especificao de arquitetura abstrata

da FIPA os seguintes elementos:
O diretrio de agentes tambm conhecido como o servio de pginas brancas,

que permite a identificao e comunicao com agentes individualmente;
O diretrio de servios tambm conhecido como o servio de pginas amarelas,

que permite a localizao de agentes que possuam a capacidade de realizar
determinadas tarefas;
A existncia de uma camada de transporte de mensagens de modo a permitir a

comunicao entre os agentes;
A existncia de uma linguagem de comunicao entre agentes de modo que os
14
agentes possam compreender as mensagens trocadas.
Um exemplo da transio do modelo abstrato para uma implementao concreta pode

ser visualizada na figura 2.3.
Figura 2.3 Arquitetura abstrata mapeada para vrias implementaes concretas adaptado de [25]
2.5.2 A especificao da estrutura de mensagens

Uma mensagem FIPA ACL contm um conjunto de um ou mais parmetros de
mensagens. Precisamente quais parmetros so necessrios para uma comunicao
efetiva entre agentes ir variar de acordo com a situao; o nico parmetro mandatrio
em todas as mensagens ACL o performative, que indica qual a performativa que est
sendo enviada. Apesar de que a maioria das mensagens ACL tambm ir conter os
campos sender, indicando o remetente da mensagem, receiver, indicando o destinatrio
da mensagem, e content, que o prprio contedo da mensagem.
O conjunto completo de parmetros das mensagens FIPA ACL pode ser visto na
tabela 2.1. As implementaes tm liberdade para incluir parmetros alm desses
especificados, com a condio que esses parmetros tenham seus nomes precedidos do
prefixo X-.
15
Parmetro
Categoria do parmetro
Performative
Tipo de ato de comunicao
Sender
Participante da comunicao
Receiver
Reply-to
Content
Contedo da mensagem
Language
Descrio do contedo
Encoding
Descrio do contedo
Ontology
Descrio do contedo
Protocol
Controle de conversao
Conversation-id
Reply-with
In-reply-to
Reply-by
Tabela 2.1 Parmetros de mensagens da FIPA ACL adaptado de [24]
2.5.3 A especificao da biblioteca de atos de

comunicao
Esta especificao tem como objetivo descrever uma definio formal da
linguagem de comunicao e seu significado. Enquanto a especificao da estrutura de
mensagem tem como objetivo padronizar a forma das mensagens, a especificao da
biblioteca de atos de comunicao tem como objetivo padronizar o significado delas. Ou
seja, sua inteno de fornecer um ponto de referncia claro e no-ambguo para a
padronizao do significado dos atos comunicativos expressos atravs de mensagens e
protocolos.
2.6
Concluses
SMA ainda um campo de pesquisa com vrios pontos em aberto. Entretanto, tm

se mostrado uma rea bastante promissora, exibindo caractersticas importantes no
desenvolvimento de sistemas. A possibilidade de uma maior abstrao e sua viso quase
natural de sistemas, decompondo-os em unidades de processamento menores so
exemplos que ressaltam a sua importncia. Outra vantagem apresentada a maneira
com que este paradigma trata os conceitos de organizao, em especial devido ao fato
16
dos sistemas estarem se tornando cada vez mais conectados e sistemas distribudos
estarem se tornando um padro nas empresas.
Para que haja esta aceitao, se torna necessrio um desenvolvimento muito forte
na rea de Engenharia de Software para este paradigma, uma preocupao que pode ser
percebida atravs do estudo, desenvolvimento e pesquisa de vrias metodologias para
SMA, que visam preencher esta lacuna. As metodologias abordadas neste trabalho so
apenas algumas de um espectro muito maior de metodologias existentes e em pesquisa.
Por prover uma metfora organizacional, a metodologia Gaia prov uma forma
quase natural de se pensar em SMA, pois podemos pensar nos agentes como uma
organizao. As fases de anlise, projeto de arquitetura e projeto detalhado possuem
artefatos bem definidos que permitem a transio entre elas sem maiores dificuldades.
Entretanto, a fase de elicitao de requisitos uma fase importante no desenvolvimento
de qualquer sistema, multiagente ou no, e pode ser feita de vrias maneiras diferentes.
Gaia peca por no definir mecanismos para esta parte do processo.
No nosso desenvolvimento, tambm percebemos um problema devido ausncia

de uma notao adequada para registrar os artefatos utilizados durante o processo de
aplicao da metodologia. Apesar dos artefatos sugeridos oferecerem informaes
suficientes para a aplicao da metodologia, no so intuitivas, tampouco auxiliaram o
processo.
Para suprir as nossas necessidades, fizemos uso de diagramas de i* para a coleta

de objetivos e de diagramas de UML [48] para registrar informaes de maneira mais
intuitiva, a saber, no registro do protocolo de interaes, usando seus diagramas de
seqncia.
17
3 Tecnologias utilizadas
Neste captulo iremos descrever algumas das tecnologias utilizadas durante o
desenvolvimento do nosso sistema multiagente.
3.1
O framework Jade
Jade, ou Java Agent Development framework (framework para desenvolvimento

de agentes em Java) um framework de desenvolvimento de agentes com o objetivo de
desenvolver SMA e aplicaes que estejam de acordo com os padres da FIPA para
desenvolvimento de agentes inteligentes. Jade composto de dois produtos principais:
uma plataforma para agentes de acordo com os padres da FIPA e um pacote para
desenvolvimento de agentes em Java.
O framework Jade, possui uma srie de ferramentas para facilitar o

desenvolvimento de aplicaes e a administrao da plataforma, sendo elas: um agente
de gerenciamento remoto, RMA (remote management agent) uma plataforma grfica
para gerenciamento e controle da plataforma; o agente dummy, que pode ser utilizado
para a composio de mensagens ACL e envi-las e receb-las entre outros agentes; o
agente sniffer, que permite a captura do trfego gerado entre os agentes; o introspector,
que permite a monitorao do ciclo de um agente, incluindo suas mensagens trocadas e
os comportamentos em execuo; uma interface grfica para o servio de diretrios, DF
(Directory Facilitator), permitindo a visualizao e a alterao da base de conhecimento
do servio de pginas amarelas em tempo de execuo; um Agente de Gerenciamento de
Logs, pemritindo a alterao de configuraes de log em tempo de execuo, e um
agente Proxy, que permite a execuo de um gateway entre uma plataforma Jade e uma
contexo TPC/IP comum.
A plataforma de agentes implementada por Jade, segue o padro de referncia da

FIPA, contendo os elementos bsicos, que so: um sistema de gerenciamento de
agentes, um servio de diretrio e um sistema de transporte de mensagens, conforme
18
ilustrado na figura 3.1.
Esta plataforma no precisa estar necessariamente contida em uma nica

mquina, podendo estar distribuda em mquinas distintas, com sistemas operacionais e
configuraes distintas, sendo necessrio apenas que possam executar uma mquina
virtual Java. Jade permite que exista apenas um Gerenciador de Agentes (AMS Agent
Management System) gerenciando a plataforma, e, no caso de uma plataforma que se
estenda por vrias mquinas, o prprio framework se encarrega de manter a
comunicao entre os containers e a utilizao do AMS, conforme figura 3.2.
Figura 3.1 Arquitetura de referncia para uma plataforma de agentes FIPA adaptado de [27]
Do ponto de vista do programador, a implementao de um agente no framework

Jade feito simplesmente se estendendo a classe agent j existente. Atravs do
mecanismo de herana, os agentes implementados passam a ter as caractersticas
necessrias para poder realizar as interaes bsicas com a plataforma de agentes (que
inclui o registro, configurao, gerenciamento remoto, entre outros). Alm disso, os
agentes herdam tambm um conjunto de mtodos bsicos que podem ser utilizados para
implementar a comportamento do agente (por exemplo, o envio e recebimento de
mensagens, protocolos de interao padres, o registro em vrios domnios, etc.).
Os elementos bsicos de um agente implementado atravs do framework Jade

so: os comportamentos (behaviors), que implementam os comportamentos executados
pelo agente; e a fila de mensagens, que gerencia o envio e o recebimento das
mensagens individualmente de cada agente. A execuo de um agente controlada por
19
um scheduler, ou escalonador, que controla o agendamento da execuo dos behaviors

dos agentes.
Figura 3.2 Plataforma de Agentes JADE, distribuda entre vrios continers adaptado de [26]
20
4 O DBSitter Plus
Nosso trabalho foi composto dos seguintes passos:
1. Coleta de requisitos do problema do DBSitter;

2. Aplicao da metodologia escolhida, Gaia;
3. Desenvolvimento de um prottipo.
Para a coleta de requisitos do problema do DBSitter, utilizamos a metodologia i*,

validando os resultados obtidos com profissionais da rea de Banco de Dados. Uma vez
coletados estes requisitos, passamos aplicao da metodologia Gaia, e a gerao dos
artefatos relacionados por ela. Por ltimo, implementamos um prottipo atravs da
utilizao dos artefatos gerados.
4.1
Requisitos
A metodologia de desenvolvimento de SMA Gaia, no prev nenhum mecanismo

para coleta de requisitos, pressupondo que os mesmo j esto definidos antes da sua
aplicao. Em [17], sugerida a utilizao de mtodos de coleta de requisitos utilizados
atualmente, como casos de uso, ou a metodologia i*, visto que eles tem como objetivo,
no a identificao de objetos do sistema, mas dos objetivos do mesmo.
A escolha dos diagramas i* [42] se deu pelas caractersticas do mesmo se

adequar nossa necessidade. Os diagramas i* possuem como caracterstica a coleta de
objetivos atravs de uma forma grfica.
O processo utilizado para a gerao dos diagramas i* podem ser observados no

apndice A, onde descrito a identificao dos atores envolvidos no sistema e o caminho
seguido at a definio do xaADB. Como nosso trabalho tem como foco a aplicao da
metodologia Gaia, ns apresentamos o Diagrama de Raciocnio estratgico, figura 4.1,
onde so apresentados os objetivos do DBSitter.
21
Figura 4.1 Diagrama de objetivos do xaADB
22
Podemos ver no centro da figura 4.1 o objetivo principal do sistema que prover
mecanismos de resoluo autnoma de falhas, e a sua decomposio em subobjetivos e
tarefas. Os subobjetivos necessrios para a proviso de mecanismos de resoluo
autnoma de falhas so: a coleta de informaes; o monitoramento de estados, a soluo
de problemas de operacionalizao do SGBD; a correo de problemas fsicos e
estruturais do SGBD, a correo de problemas de conectividade; o controle de problemas
do Sistema Operacional (SO), a correo de problemas de objetos lgicos do SGBD e a
notificao de eventos, como pode ser observado no diagrama. Por sua vez, cada
subobjetivo foi decomposto nas tarefas necessrias para atingir este subobjetivos,
caracterizados pelos hexgonos a eles ligados. Segue abaixo uma descrio dos
subobjetivos:
Correo de problemas de objetos lgico do SGBD pode ser alcanado atravs:

da sugesto da soluo para problemas de objetos lgicos, assim como da
correo de problemas de objetos lgicos. Este ltimo inclui a execuo de
desfragmentao de tabelas e ndices, a correo da corrupo de tabelas e
ndices, o particionamento de tabelas e ndices, o dimensionamento de rea de
tabela e ndices, a correo de problemas de bloqueio e a autorizao de acesso a
operaes de objetos.
Controle de problemas de SO, pode ser atingido atravs da execuo das tarefas:
sugesto de soluo de problemas de SO e da correo de problemas de SO.
Este ltimo pode ser decomposto nas seguintes tarefas: correo de problemas de
interao entre SGBD e SO; execuo de autorizao de acesso; inicializao do
SGBD e correo de problemas de memria.
Correo de problemas de conectividade pode ser atingido atravs da execuo

das seguintes tarefas: sugesto para soluo de problemas de conectividade e
correo de problemas de conectividade. Este ltimo composto das tarefas:
identificao de problemas de conectividade e correo de problemas de
conectividade.
Correo de problemas fsicos e estruturais do SGBD pode ser alcanado atravs
23
das tarefas: sugesto de soluo de problemas fsicos e estruturais do SGBD e da

correo de problemas fsicos e estruturais. Este ltimo pode ser decomposto nas
tarefas: identificao e correo de problemas de estrutura de arquivos e da
redefinio de tamanho de rea reservada ao SGBD.
Soluo de problemas de operacionalizao do SGBD pode ser obtido atravs das

tarefas: sugesto de solues de operacionalizao e da correo de problemas
de operacionalizao. Este ltimo pode ser decomposto nas tarefas: adequao
interna de memria, adequao de parmetros de rotinas de backup e restore do
SGBD e na tarefa adequao de parmetros do SGBD.
Monitorar estados realizado atravs da tarefa de monitorao de estados,

enquanto o objetivo notificar eventos pode ser realizado atravs da tarefa notificar
eventos, que pode ser decomposta em gerao de registro de eventos, gerao
de consultas e envio de e-mail.
Coletar informao pode ser realizado atravs das tarefas de uso das regras e
polticas e da permisso de configurao. A permisso de configurao pode ser
dividida nas subtarefas permisso de configurao pelo usurio, coleta de
percentual de acertos e erros e coleta de casos de falha e soluo. A permisso
de configurao pelo usurio pode ser subdivida novamente nas tarefas
configurao de polticas, configurao de regras e configurao de acesso a
SGBD e SO.
4.2
A modelagem SMA
Uma vez definido os requisitos, passamos modelagem atravs da metodologia

Gaia. Como descrito pela metodologia, iniciamos pelo processo de anlise, identificando
potenciais suborganizaes, descrevemos o ambiente atravs dos recursos que sero
utilizados pelo nosso sistema, criamos um modelo de papis preliminar, baseado nas
habilidades necessrias, identificamos as interaes entre os papis atravs do modelo
de interaes preliminar e por ltimo identificamos regras gerais de relacionamentos entre
24
papis, entre interaes e entre interaes e papis que seriam melhor capturadas
atravs de regras organizacionais.
Durante o processo de definio de suborganizaes, identificamos que algumas

pores do sistema exibiam um comportamento especificamente orientado para a
realizao dos mesmos subobjetivos, agrupando-os nas seguintes suborganizaes:
Suborganizao de Deteco e Correo de Problemas
Suborganizao de Notificaes e Registros
Suborganizao de Aprendizagem e Sugesto
Figura 4.1 Diagrama de suborganizaes do xaADB
Aps isto, passamos a descrever o ambiente. Gaia sugere tratar o ambiente em

termos computacionais, descrevendo os recursos aos quais o nosso sistema precisa ter
acesso para poder atingir os seus objetivos. Em sua forma mais simples pode ser visto
como uma lista de recursos, associados com um nome simblico e caracterizados pelos
tipos de aes que os agentes podem realizar sobre eles. Para organizar melhor este
processo, optamos por agregar os recursos de acordo com as suborganizaes que
foram identificadas.
25
Recursos da suborganizao de Deteco e Correo de problemas:

o
Informaes sobre polticas organizacionais;
So informaes contidas na base de conhecimento que regem o

comportamento dos agente.
Informaes sobre regras de negcio;
So informaes contidas na base de conhecimento, indicando, por

exemplo, que determinados agentes apenas podem entrar em
execuo fora do horrio comercial.
Informaes sobre o sistema operacional;
So as informaes extradas do SO, e.g.: processos em

execuo.;
Estados do banco de dados;
So informaes de estado do banco extradas atravs de

consultas aos dicionrios de dados (catlogos do SGBD);
Registros de log do SGBD;
So os arquivos de registros de aes e erros do SGBD

monitorado.
Base de conhecimento com aes de correo de falhas e estatsticas de

aes realizadas;
a base de conhecimento onde vo estar registrados os sintomas

e as aes de correo para cada caso de falha.
Recursos da suborganizao Notificaes e Registros:

o
Informaes sobre polticas organizacionais;

comportamento dos agente. E.g.: Apenas o agente notificador pode
enviar alertas para o usurio final.
Log de aes;
O local onde vo estar armazenadas as informaes das aes

realizadas pelo DBSitter Plus.
26
Recursos da suborganizao Aprendizagem e Sugesto:

o
Base de conhecimento sobre polticas organizacionais;

comportamento dos agente. E.g.: Apenas o agente aprendiz
autorizado a manipulao de escrita na base de conhecimento.
Base de conhecimento sobre regras de negcio;
So informaes contidas na base de conhecimento, indicando, por

exemplo, que determinados agentes apenas podem entrar em
execuo fora do horrio comercial.
Base de conhecimento com aes de correo de falhas e estatsticas de

aes realizadas.
a base de conhecimento onde vo estar registrados os sintomas

e as aes de correo para cada caso de falha.
Para a identificao dos papis do nosso sistema, detectamos todas as

habilidades necessrias para a execuo dos nossos objetivos, e transformamos essas
habilidades em papis. Gaia define papis como sendo compostos de quatro atributos
bsicos: responsabilidades, permisses, atividades e protocolos.
Responsabilidades so os atributos chave, relacionados a um papel e determinam

sua funcionalidade. Responsabilidades so classificadas em dois tipos: Liveness e Safety.
Liveness diz o que o papel agrega de til ou positivo ao sistema. Deve descrever
atividades que um agente que implemente o papel deve desempenhar sob determinadas
condies ambientais. Safety diz o que o papel deve prevenir ou desautorizar para que
nada de ruim ou indesejado acontea ao sistema. Assegura que um estado aceitvel em
ocorrncias mantido durante o ciclo de execuo.
Para que as Responsabilidades sejam atendidas, um papel deve estabelecer um

conjunto de permisses. As permisses representam o que o papel est permitido a fazer
e quais recursos pode acessar. E atividades so tarefas que um papel realiza sem ter que
interagir com outro agente. Protocolos so padres especficos de interao, por exemplo,
determinado tipo de leilo.
27
Com isso, identificamos os seguintes papis preliminares em nosso sistema:
Detector de erros de estruturas de controle de SGBD

o
Responsvel pela monitorao das estruturas de controle do

SGBD;
Detector de erros de estruturas fsicas de SGBD;

o
Detector de erros de estruturas lgicas de SGBD;

o
Responsvel pela atuao no estado da rede;
Notificador
o
Responsvel pela monitorao do estado da rede;
Corretor de falhas de Rede;

o
Responsvel pela atuao no estado do SO;;
Detector de erros de Rede;

o
Responsvel pela monitorao do estado do SO;
Corretor de falhas de S.O.;

o
Responsvel pela atuao nas estruturas lgicas do SGBD;
Detector de erros de S.O.;

o
Responsvel pela atuao nas estruturas fsicas do SGBD;
Corretor de falhas de estruturas lgicas de SGBD;

o
Responsvel pela atuao nas estruturas de controle do SGBD;
Corretor de falhas de estruturas fsicas de SGBD;

o
Responsvel pela monitorao das estruturas lgicas do SGBD;
Corretor de falhas de estruturas de controle de SGBD;

o
Responsvel pela monitorao das estruturas fsicas do SGBD;
Responsvel pela notificao de erros ao ABD;
Aprendiz
o
Responsvel pelo aprendizado do sistema;
Na tabela 4.1, podemos verificar o modelo sugerido por Gaia para armazenamento
das informaes contidas nos papis.
28
Papel: MonitorControlDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar constantemente os estados das estruturas e controle do

banco de dados alvo, monitorando processos do SGBD no S.O., em arquivos de logs (traces)
de SGBD ou realizando consultas em dicionrios de dados. Caso solicitado, ele ir se
comunicar com outros papis que requisitem informaes, passando dados sobre o estado
atual da estruturas monitoradas do banco.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
MonitoringDB,
registerServiceDirectory
Reads DBState
// O estado do banco de dados
Reads OSState
// O estado dos processo do SO
MONITORCONTROLDB = registerServiceDirectory.((ReceiveInfRequest . ProccessInfRequest .
AnswerInfRequest) | (MonitoringDB))
Ter acesso completo ao servidor, incluindo aos processos que esto sendo executados pelo
SO, processos do SGBD e ao SGBD alvo.
Tabela 4.1 - Detector de erros de estruturas de controle de SGBD
No apndice B, podemos encontrar o modelo de papis com a descrio completa de

todos os papis identificados na fase de anlise.
Aps identificados os papis preliminares, passamos a identificar o modelo de

interaes preliminares, que descreve os relacionamentos entre os papis. Ns
identificamos a seguinte lista preliminar de interaes:
ReceiveInfRequest,
o
AnswerInfRequest,
o
A comunicao utilizada para extrair informaes dos detectores.
A comunicao utilizada para enviar informaes dos detectores.
AskForInformation,
o
A comunicao utilizada para requisitar informaes de status dos

detectores.
ReceiveInformation,
o
ReceiveRequest,
o
A comunicao utilizada para o recebimento de informaes de status.
A comunicao utilizada para requisitar uma atuao.
AnswerRequest,
o
A comunicao utilizada para retornar o status de uma requisio de

atuao.
ReceiveEpisodeFeedback,
o
A comunicao utilizada para receber feedback dos episdios de correo.
29
Nome do Protocolo:
ReceiveInfRequest
Iniciador:
Todos atuadores
Parceiro:
Todos detectores
Descrio:
Mensagens utilizada para extrair informaes dos
detectores.
Entrada:Requisio para
informao.
Sada:
Erro ou msg com status do
objeto monitorado.
Tabela 4.1 - Exemplo de definio preliminar de protocolo
Na tabela 4.1, podemos verificar o modelo sugerido por Gaia para o

armazenamento das informaes do protocolo de interaes. A lista completa dos
protocolos de interaes preliminares pode ser vista no apndice B.
Uma vez identificados os agentes e os protocolos, passamos a capturar as regras

organizacionais, que so relacionamentos entre papis, entre protocolos e entre papis e
protocolos. As regras organizacionais so como as responsabilidades individuais de cada
agente, entretanto, aplicadas organizao como um todo. Ou seja, podemos ter regras
de liveness, que indicam como a organizao deve se comportar com o passar do tempo,
e regras de safety, que so regras que capturam as invariantes do sistema.
PassarInformacoes(Monitor) EnviarEmailDeNotficacao(Notificador)
Uma vez cumpridas estas tarefas, passamos fase de projeto, onde iremos fazer
uso das informaes coletadas. Enquanto na fase de anlise nosso foco estava na
compreenso do que o SMA dever fazer, na fase de projeto comeamos a tomar
decises sobre as caractersticas finais do SMA.
De acordo com Gaia [17], para determinar a melhor escolha do projeto de

estrutura organizacional, deve-se considerar a influncia de fatores como: regime de
controle (particionamento de trabalho, especializao de trabalho, modelos baseados em
mercado, etc), complexidade computacional e de coordenao, regras organizacionais,
influencia da organizao no mundo real e simplicidade. A topologia (e.g.: centralizada,
coleo de plataformas (peers), hierrquica, hierrquica multinvel, topologias compostas
30
complexas, topologias em redes hbridas) ento selecionada baseado nos pesos para
cada um desses fatores.
Essa escolha influenciar sobremaneira todas as fases subseqentes do projeto,
sendo portanto uma etapa crtica no processo. Esta anlise deve ter em mente respeitar
as regras organizacionais levantadas e minimizar a distncia para a organizao do
mundo real.
Por se adequar melhor ao problema em questo, escolhemos a estrutura
organizacional de topologia hierrquica, onde um lder assume as responsabilidades de
coordenao. A figura 4.2 apresenta a organizao escolhida. Essa deciso
corroborada com a inteno de utilizao do mtodo de coordenao de agentes PGP
(Partial Global Planning), onde agentes setoriais possuem planos locais de resoluo de
atividades, mas devem respeitar as diretrizes de um plano global seguido por todos de
maneira cooperativa e determinado por um agente coordenador.
Figura 4.2 Topologia da estrutura organizacional hierrquica
Aps a escolha do modelo organizacional, passamos ao refino do modelo de

papis. Como evoluo dos papis preliminares foi criado o papel de Coordenador de
Atividades. Os papis de Detector e Corretor de erros setoriais, por possurem
percepes similares e atribues complementares, foram fundidos em papis Monitores,
que englobam as suas responsabilidades. Apenas o papel de coordenador tem habilidade
de solicitar alterao na base de conhecimento. O papel Aprendiz teve sua capacidade
expandida para gerente de conhecimento.
Abaixo segue uma descrio sucinta dos papis definitivos concebidos e uma
descrio formal dos papis segundo os padres da metodologia Gaia encontra-se listada
no Apndice D.
31
Monitor de estruturas de controle de BD

o
Juno dos papis preliminares detector e corretor de erros de estruturas

de controle de BD;
Monitor de estruturas fsicas de BD

o

fsicas de BD;
Monitor de estruturas lgicas de BD

o

lgicas de BD;
Monitor de SO
o
Monitor de rede
o
Juno dos papis preliminares detector e corretor de erros de rede;
Notificador
o
Juno dos papis preliminares detector e corretor de erros de S.O.;
No houve alterao em relao ao papel preliminar;
Gerente de Conhecimento
o
Expanso das responsabilidades do papel preliminar, que passa a assumir

uma funo de wrapper de toda a base de conhecimento. o nico papel a
interagir com a base de conhecimento para escrita. Atende aos outros
papis por meio de solicitao.
Coordenador
o
Criado esse papel para realizar a coordenao de todo o processo de

identificao, correo, notificao e registro de feedback de atuao para
os diversos erros ocorridos nas suborganizaes de deteco e correo
de falhas (estruturas de controle de SGBD, lgicas de SGBD, fsicas de
SBBD,
S.O. e Redes). Tambm se responsabiliza pela concepo de
todos os planos para correo de episdios de erro e gerenciamento de

tarefas que envolvam a perticipao de mais de um agente.
Partindo do modelo de interaes preliminar, e luz do novo modelo de papis

pode-se formatar o modelo de interaes definitivo.
32
Exibimos abaixo, na Figura 4.3, um diagrama de interao concebido nos moldes

do diagrama de seqncia Unified Modelling Language (UML). Este diagrama exibe o
modelo de interao do caso de falha implementado na prova de conceito desenvolvida.
diagrama
exibido
descreve
atividade
de
correo
de
falha
de
dimensionamento de memria compartilhada no BD Oracle. Para solucionar a falha, o

papel monitor de estruturas de controle deve passar seu plano parcial de resoluo para o
papel coordenador junto com a informao do acontecimento de episdio de falha. O
papel coordenador em seguida deve consultar regras de negcio e a base de
conhecimento (encapsulada em um papel) para montar o plano global de resoluo.
Para resolver o episodio, o agente monitor deve seguir o plano global e seu plano
parcial. Para tanto, deve solicitar ao papel monitor de BD para que retire o BD do ar. Esse
papel deve confirmar que h um plano prevendo retirada de BD do ar nas condies
correntes. Uma vez confirmado e o BD fora do ar, o agente monitor de estrutura de
controle altera o arquivo de configurao do BD aumentando a memria disponvel e em
seguida solicita que o papel monitor de BD recoloque o BD no ar.
Uma checagem de efetividade deve ser feita e esse feedback repassado ao

agente coordenador que por sua vez registrar o episdio e resultado na base de
conhecimento.
Com isto, finalizamos a fase de projeto e passamos para a fase de projeto

detalhado, onde iremos definir o modelo de agentes e o modelo de servios.
33
Figura 4.3 Modelo de interao representado atravs de diagrama de seqncia UML
34
O modelo de agentes detalha que agentes iro desempenhar quais papis, assim
como a quantidade de instncias deles. J o modelo de servios, como o prprio nome
sugere, tem como objetivo identificar os servios associados a cada agente.
Podemos observar na Figura 4.4, como os papis sero desempenhados por

agentes.
Monitor falhas BD
Monitor estr.
controle DB *
Monitor estr.
lgicas *
Monitor estr.
controle BD
Monitor estr.
lgicas BD
Monitor estr.
fsicas *
Monitor estr.
fsicas BD
Coordenador 1
Gerente
de conhecinento 1
Notificador 1
Monitor S.O. *
Coordenador
Ger. de
conheciment
Notificador
Monitor S.O.
Monitor Rede *
Monitor
Rede
Legenda:
Tipos de Agente
*: zero ou mais instncias de agentes
Papis
Figura 4.4 Modelo de Agentes
35
Na Tabela 4.2, podemos verificar alguns dos servios identificados. O apndice E

contm a lista dos servios implementados pelo nosso estudo de caso.
Servio
Resoluo de episdio de falha
Registro de feedback
Entradas
Identificao do plano global
Sadas
Pr-condies
Status de realizao concluda /

Medida de efetividade
Autorizao do coordenador
Identificao do tipo de falha e

medida de eficincia do episdio
Status de realizao concluda
Ps-condies
Feedback coletado
Feedback coletado
-
Tabela 4.2 Exemplo de Modelo de servios
4.3
Experimentos e resultados
Desenvolvemos, como prova de conceito, uma implementao dos agentes

Agente Shared Pool, Agente Monitor de Banco de Dados, Repositrio de Conhecimento e
Agente Coordenador.
Atravs da utilizao da plataforma JADE, geramos classes que implementam

cada um dos agentes identificados. Estes agentes tem seus comportamementos
implementados atravs de behaviors. Durante o desenvolvimento fizemos uso dos
artefatos gerados para orientar o desenvolvimento, em especial dos diagramas de
seqncia e dos modelos de papis definitivos. Estes nos auxiliaram a identificar os
comportamentos dos agentes.
Atravs da ferramente sniffer disponvel na plataforma JADE, monitoramos a

comunicao, verificando que a mesma ocorreu da forma esperada. O comportamento
dos agentes atuadores, Agente Shared Pool e Agente Monitor de Banco de Dados,
tambm ocorreu corretamente, sendo monitorados atravs da ferramenta introspector.
O mecanismo de coordenao est sendo objeto de estudo de uma pesquisa em

andamento, de tal modo que apenas implementamos uma simulao do seu
funcionamento, visto que no o objeto principal de nosso trabalho.
Consideramos ser o caso de uso implementado bastante representativo, visto que

contempla comunicao entre agentes monitores entre si e com o coordenador, registro
36
de execues e utilizao da base de conhecimento.
Atravs desse experimento, pudemos comprovar o auxlio gerado por um processo

de desenvolvimento de SMA, alm de comprovar a viabilidade de implementao do
nosso estudo do DBSitter.
4.4
Consideraes finais
A nossa implementao do DBSitter Plus, propiciou a adequao aos padres da

FIPA, facilitando extenses do mesmo ou da sua comunicao com outros SMA que
tambm implementem os padres da FIPA.
Durante o desenvolvimento, verificamos a validade da utilizao de uma

metodologia de desenvolvimento SMA, inclusive devido ao fato que documentamos
nossas decises atravs dos artefatos da mesma, permitindo sua reutilizao.
37
5 Concluses e trabalhos futuros
5.1
Contribuies
Atravs deste trabalho, aumentamos a compatibilidade do DBSitter, atravs da sua

adequao s padronizaes da FIPA.
Para tanto revisamos os conceitos originais
atravs da modelagem do projeto utilizando a metodologia GAIA, especfica para SMA.

Comprovamos a viabilidade da implementao das novas caractersticas, atravs
do desenvolvimento, com o framework JADE, de um caso representativo de resolucao
automtica de falha em SGBD.
5.2
Dificuldades
Algumas das dificuldades encontradas durante o desenvolvimento deste trabalho

se referem utilizao da notao da metodologia GAIA e da reutilizao de cdigo
existente. Em relao metodologia GAIA, percebemos a falta da especificao de uma
fase de requisitos, e fizemos uso da modelagem i*. Alm disso, sentimos a necessidade
da utilizao de diagramas mais expressivos para o processo, adotando diagramas
existentes em UML. Em relao reutilizao de cdigo, a nossa proposta para alterao
da padronizao dos agentes, gerou uma mudana no modelo de comunicao que
inviabilizou o reaproveitamento de uma parcela significativa do cdigo existente.
5.3
Trabalhos futuros
Como trabalhos futuros, poderamos citar o desenvolvimento de prottipos para

diferentes verses de SGBD, com por exemplo o PostgresSQL, mySQL ou SQLServer.
Desenvolvimento de novos casos de resoluo de falha, com diferentes graus de

complexidade, assim como a utilizao de diferentes implementaes para o mecanismo
de coordenao.
38
Referncias bibliogrficas
[1] Carneiro A., "DBSitter: Um Sistema Inteligente para Gerenciamento de SGBD", 2005
[2] Carneiro A., Passos R., Belian R., Costa T., Tedesco P., Salgado A. C, "DBSitter: An
Intelligent Tool for Database Administration", 2004
[3] Kephart, J.O., Chess, D. M., The vision of autonomic computing, disponvel em:
http://www.research.ibm.com/autonomic/research/papers/AC_Vision_Computer_Jan_2003.pdf,
acesso em 01/10/2006.
[4] Horn, P., Autonomic Computing: IBMs Perspective on the State of Information
Technology, disponvel em:
http://www.research.ibm.com/autonomic/manifesto/autonomic_computing.pdf, acesso em
01/10/2006.
[5] Ganek, A. G., Corbi T. A., "The Dawning of Autonomic Computing Era", 2003
[6] Johnston-Watt, Duncan, "Under New Management: Autonomic Computing is

Revolutionizing The Way We Manage Complex Systems", 2006
[7] Lin, P., MacArthur, A., Leaney, J., Defining Autonomic Computing
- A Software
Engineering Perspective
[8] IBM, "An Architectural blueprint for Autonomic Computing", 2006
[9] Koehler, J., Giblin C., Gantenbein, D., Hauser R., "On Autonomic Computing
Architectures", 2003
[10] Elnaffar, S., Powley W., Benoit D., Martin P., "Todays DBMSs: How autonomic are
they?, 2003
[11] Lifschitz, S. and Macdo, J. (2004). Agent-based Databases and Parallel Join Load
39
Balancing, chapter 6, pages 6988. Sistemas de Informacon e Ingeniera de Software:

Temas Selectos - Editora Centro Estudios Informatica, Univ. Simon Bolivar (Merida)
Venezuela.
[12] Lifschitz, Design and Implementation of a Global Self-tuning architecture

[13] Foundation for Intelligent Physical Agents FIPA, disponvel em: http://www.fipa.org,
acesso em 01/10/2006.
[14] White, S.R. Hanson, J.E. Whalley, I. Chess, D.M. Kephart, J.O., "An architectural
approach to autonomic computing", 2004
[15] Murilo Juchem, M;
Bastos R. M., Engenharia de Sistemas Multiagentes: Uma
Investigao sobre o Estado da Arte, 2001
[16] Wagner, G., "The Agent-Oriented-Relationship Metamodel:Towards a Unified View of

The State and Behavior", 2003
[17] Zamborelli, F.; Jennigs N. R.; Wooldridge, M., Developing Multiagent Systems: The
Gaia Methodology", 2003
[18] Wooldridge M., "An Introduction to MultiAgent Systems"
[19] Moratis P., Petraki E., Spanoudakis N., Engineering JADE Agents with the Gaia
Methodology, 2003
[20] Wooldridge M., Jennings, N. R.. Pitfalls of Agent-Oriented Development
[21] Jennings, N. R., Agent-based computing: promise and perils
[22] Lin, P., MacArthur, A., Leaney, J., Defining autonomic Computing: a software
engineering perspective
40
[23] Foundation for Intelligent Physical Agents FIPA, FIPA Communicative Act Librarry
Specification - SC00037J
[24] Foundation for Intelligent Physical Agents FIPA, FIPA ACL Message Structure
Specification - SC00061G
[25] Foundation for Intelligent Physical Agents FIPA, FIPA Abstract Architecture
Specification - SC00001L
[26] JADE Administrator's Guide, disponvel em: http://jade.cselt.it, acesso em

01/10/2006.
[27] JADE Programmer's guide, disponvel em: http://jade.cselt.it, acesso em 01/10/2006.
[28] Nikraz, M., Caire, G. Bahri, P. A., A methodology for the analysis and design of multiagent systems using JADE
[29] Jennings, N. R., Wooldridge, M., Applications of intelligent agents
[30] Moraitis, P., Spanoudakis, N. I., Combining Gaia and JADE for multi-agent systems
development
[31] Bauer, B., Mller, J. P., Odell, J., Agent UML: A formalism for specifying multiagent
interaction
[32] Odell, J., Parunak, H. V. D., Bauer, B., Extending UML for agents
[33] Silva, V. T., Lucena, C. J. P., MAS-ML: A multi-agent system modeling language
[34] Wagner, G., The agent-object-relationship metamodel: towards a unified view of state
and behavior
[35] Wagner, G., Taveter, K., Towards radical agent-oriented software engineering
processes based on AOR modeling
41
[36] DeLoach, S. A., Analysis and design using MaSE and agentTool
[37] Padgham, L. Winikoff, M., Prometheus: A pragmatic methodology for engineering

intelligent agents
[38] Java Agent DEvelopment Framework, disponvel em: http://jade.cselt.it, acesso em

01/10/2006.
[39] Franklin, S. and Graesser, A., Is it an Agent, or just a Program? : A Taxonomy for
Autonomous Agents, 1995.
[40] Weiss, G., Multiagent Systems: A modern approach to distributed artificial intelligence
The MIT Press, 1999.
[41] Jennings, N. R., On agent-based software engineering.
[42] Yu, E. S. K., Towards Modelling and Reasoning Support for Early-Phase
Requirements Engineering
[43] Russell , Norvig, Artificial Intelligence, a Modern Approach

[44] Moore, Gordon E.: Cramming more components onto integrated circuits Electronics,
Volume 38, Number 8, April 19, 1965
[45] J. P. Bigus, J. L. Hellerstein, T. S. Jayram, e M. S. Squillante. Auto tune: A generic

agent for automated performance tuning. In Proceedings of the International Conference
and Exhibition on the Pratical Application of Intelligente Agents and Multi-Agent Systems
(PAAM), pginas 33 - 52. 2000.
[46] Y Diao, J. L. Hellerstein, S. Parekh, e J. P. Bigus. Managing web server performance

with autotune agents. IBM Systems Journal, 42 (1): 136 - 149, 2003.
42
[47] J. A. F. Macdo. Agent-based DMBSs study. Tese de mestrado, Departamento de

Informtica, Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio), 2000
[48] R. L. C. Costa e S. Lifschitz. Index self-tuning and agent-based databases. In

Proceedings of the Latin-American Conference on Informatics (CLEI), pginas 76,
Abastracts Proceedings. 2002.
[49] UML Resource Page, disponvel em: http://www.uml.org/, acesso em 01/10/2006.
[50] Silva, M. J., Sarmento, L. C. M., Modelagem de um Sistema Multiagentes utilizando

TROPOS, disponvel em: http://www.cin.ufpe.br/~in1096/2006-1/, acesso em 01/10/2006.
[51] Maciel, P. R. M., Robertson Novelino Ferraz, R. N., Utilizando a Metodologia GAIA
para Modelagem do Sistema Arquitetural xaADB, disponvel em:
http://www.cin.ufpe.br/~in1096/2006-1/, acesso em 01/10/2006.
43
Apndice A Especificao de Requisitos e Diagrama i*

Seguem abaixo os diagramas gerados durante a especificao de requisitos do
xaADB. Na figura A.1, podemos observar o diagrama de atores. Os atores identificados
so cliente e dba, e este diagrama tem identificados suas interdependncias e seus
objetivos pessoais. O cliente tem o objetivo de Aperfeioar o Gerenciamento de Dados e o
objetivo soft de Diminuir Custos. O cliente depende do dba para alcanar o objetivo de
Administrar Dados e os objetivos soft Eficiencia na Administrao de Dados e Manter
Bom Nvel Continuidade Servios. O dba depende do cliente para melhorar a qualidade
do trabalho.
Figura A.1 Diagrama de atores
A figura A.2 mostra a anlise do raciocnio do cliente. Durante o processo anlise

de requisitos, concluiu-se que o objetivo Aperfeioar Gerenciamento de Dados pode ser
alcanado atravs do plano Avaliar Solues e que este plano contribui positivamente
para Melhorar a Qualidade do Trabalho.
44
Figura A.2 Diagrama de objetivos do ator Cliente
A figura A.3 mostra a anlise do raciocnio do dba. Concluiu-se que o objetivo

Administrar os Dados pode ser alcanado tanto com o objetivo Automatizar Tarefas
com o uso de SMA quanto com o objetivo Administrao Convencional. Tambm se
considerou que Automatizar as Tarefas com o uso de SMA contribui positivamente para
Manter Bom Nvel Continuidade Servios. Um meio para operacionalizar o objetivo
Automatizar as Tarefas com o uso de SMA Usar sistema xaADB. Automatizar as
Tarefas com o uso de SMA contribui mais positivamente na Eficincia na Administrao
de Dados que a Administrao Convencional.
Figura A.3 Diagrama de objetivos do ator dba
45
Figura A.4 Diagrama de atores estendido
Na figura A.4 podemos ver o Diagrama de atores (stakeholders) ou Diagrama de

Dependncia estratgica (SD) estendido com o ator xaADB representando o sistema que
ser modelado. Neste diagrama, podemos perceber a incluso do ator xaADB
representando o sistema que ser modelado e identificou as dependncias dos outros
atores da organizao em relao a ele. Podemos ver na figura A.4 que o ator dba
depende do ator xaADB para alcanar o objetivo de Prover mecanismos de resoluo
autnoma de falhas e que este atende aos objetivos soft de Flexibilidade, Preciso,
Confiabilidade, Segurana e Portabilidade. J o ator Cliente depende do ator xaADB
para alcanar os objetivos soft de Diminuir Custos e Maior Continuidade Servios.
46
Apndice B Papis preliminares
Apresentamos a seguir os papis preliminares identificados durante a fase de

anlise de Gaia.
Detector de erros de estruturas de controle de SGBD
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar constantemente os estados das estruturas e controle do

banco de dados alvo, monitorando processos do SGBD no S.O., em arquivos de logs (traces)
de SGBD ou realizando consultas em dicionrios de dados. Caso solicitado, ele ir se
comunicar com outros papis que requisitem informaes, passando dados sobre o estado
atual da estruturas monitoradas do banco.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
MonitoringDB,
Reads DBState
Reads OSState
SO, processos do SGBD e ao SGBD alvo.
Detector de erros de estruturas fsicas de SGBD

Papel: MonitorPhysicalDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar constantemente os estados das estruturas fsicas do banco
de dados alvo em arquivos de logs (traces) de SGBD, realizando consultas em dicionrios de
dados e verificando estados de estruturas de memria em disco (via S.O.). Caso solicitado,
ele ir se comunicar com outros papis que requisitem informaes, passando dados sobre o
estado atual do banco.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
MonitoringDB,
Reads DBState
Reads OSState
// O estado dos processo e reas do SO
MONITORPHYSICALDB = registerServiceDirectory.((ReceiveInfRequest . ProccessInfRequest .
SO, reas de memria em disco e ao SGBD alvo.
47
Detector de erros de estruturas lgicas de SGBD

Papel: MonitorLogicalDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar constantemente os estados das estruturas lgicas do

banco de dados alvo em arquivos de logs (traces) de SGBD ou realizando consultas em
dicionrios de dados. Caso solicitado, ele ir se comunicar com outros papis que requisitem
informaes, passando dados sobre o estado atual do banco.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
ReceiveInformation,
MonitoringDB,
Reads DBState
Reads OSState
// O estado dos processos e reas do SO
MONITORLOGICALDB = registerServiceDirectory.((ReceiveInfRequest . ProccessInfRequest .
AnswerInfRequest) | (MonitoringDB) | (ReceiveInformation))
SO, reas de memria e dicionrio de dados do SGBD alvo.
Corretor de falhas de estruturas de controle de SGBD

Papel: HealingDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes que visam recuperar o estado do banco de dados e aes de
correo de falhas. Eventualmente, tambm poder requisitar informaes de outros agentes.
ReceiveRequest,
ProccessRequest,
AnswerRequest,
AskForInformation,
ReceiveInformation,
SendEpisodeFeedback,
HealingDB,
Reads KnowlodgeBase // l estratgias de correo de problemas
Changes DBState
// Realiza operaes no SGBD
HEALINGDB = registerServiceDirectory ( (ReceiveRequest.ProccessRequest.AnswerRequest) |
(HealingDB) | (AskForInformation) | (ReceiveInformation) | (SendEpisodeFeedback))
Ter acesso completo ao servidor, incluindo aos processos que esto sendo executados pelo SO
e ao SGBD alvo.
Corretor de falhas de estruturas fsicas de SGBD

Papel: HealingDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
ReceiveRequest,
ProccessRequest,
AnswerRequest,
AskForInformation,
ReceiveInformation,
HealingDB,
Changes DBState
e ao SGBD alvo.
48
Corretor de falhas de estruturas lgicas de SGBD

Papel: HealingDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
ReceiveRequest,
ProccessRequest,
AnswerRequest,
AskForInformation,
ReceiveInformation,
HealingDB,
Changes DBState
e ao SGBD alvo.
Detector de erros de SO
Papel: MonitorSO
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar os estados do Sistema Operacional, atravs da aquisio

de informaes em variveis de ambiente, processos e reas de armazenamento. Ir se
comunicar com papis que requisitem informaes sobre os estados do monitorados.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
MonitoringOS,
Reads OSState
// estado do S.O.
Changes OSState // operaes de alterao de elementos do S.O.
MONITOROS = registerServiceDirectory ( (ReceiveRequest . ProccessRequest .
AnswerRequest) | (MonitoringSO))
Ter acesso completo aos recursos do sistema operacional
Corretor de falhas de SO
Papel: HealingSO
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes que visam recuperar o estado de elementos do S.O.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
AskForInformation,
ReceiveInformation,
HealingOS,
Changes SO State
// Realiza operaes no S.O.
HEALINGSO = registerServiceDirectory (
(ReceiveInfRequest.ProccessInfRequest.AnswerInfRequest) | (HealingSO) |
(AskForInformation) | (ReceiveInformation) | (SendEpisodeFeedback))
Ter acesso completo aos recursos do sistema operacional.
49
Detector de erros de rede

Papel: MonitorNetwork
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir monitorar os estados da rede de comunicao, atravs da aquisio

de informaes em variveis de ambiente, processos, portas etc. Ir se comunicar com papis
que requisitem informaes sobre os estados do monitorados.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
MonitoringNetwork,
Reads OSState
// estado do S.O.
Changes OSState // operaes de alterao de elementos do S.O.
MONITORNETWORK = registerServiceDirectory ( (ReceiveRequest . ProccessRequest .
AnswerRequest) | (MonitoringNetwork))
Corretor de falhas de rede

Papel: HealingNetwork
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes que visam recuperar o estado de elementos da rede de
comunicao.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
AskForInformation,
ReceiveInformation,
HealingNetwork,
Changes SO State
// Realiza operaes no S.O.
HEALINGNETWORK= registerServiceDirectory (
(ReceiveInfRequest.ProccessInfRequest.AnswerInfRequest) | (HealingNetwork) |
(AskForInformation) | (ReceiveInformation) | (SendEpisodeFeedback))
Ter acesso completo aos recursos do sistema operacional.
Notificador
Papel: Notifier
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes de interface entre o sistema e os usurios finais. Informaes
coletadas de outros papis sero registradas em base de dados apropriada e/ou enviadas para
os usurios finais.
ReceiveInformation,
RegisterInformation,
Changes LogBase
// registra eventos
NOTIFIER = registerServiceDirectory (SendInformation | RegisterInformation |
ReceiveInformation)
Ter acesso base de registro de eventos.
50
Aprendiz
Papel: Learner
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes de aprendizagem, registrando na base de conhecimento novos

casos percebidos, registros de casos pelo usurio, coleta de feedback do usurio e acertos de
casos usados.
ReceiveEpisodeFeedback, // recebe feedback dos episodios de correcao
RegisterFoultCase,
Changes KnoledgeBase
// registra casos de falha
// registra episdios de correo
LEARNER = registerServiceDirectory (ReceiveEpisodeFeedback)
Ter acesso base de conhecimento
51
Apndice C Modelos de Interaes Preliminares
Apresentamos a seguir as interaes preliminares identificadas durante a fase de

anlise de Gaia.
ReceiveInfRequest
Nome do Protocolo:
ReceiveInfRequest
Iniciador:
Todos atuadores
Parceiro:
Todos detectores
Descrio:
Mensagens utilizada para extrair informaes dos
detectores.
Entrada:Requisio para
informao.
Sada:
Erro ou msg com status do
objeto monitorado.
AnswerInfRequest
Nome do Protocolo:
AnswerInfRequest
Iniciador:
Todos detectores
Parceiro:
Todos atuadores
Descrio:
Mensagens utilizada para enviar informaes dos
detectores.
Entrada:Informao sobre falha.
Sada:
ok, msg recebida.
AskForInformation
Nome do Protocolo:
AskForInformation
Iniciador:
Todos corretores
Parceiro:
Todos corretores
Descrio:
Mensagens utilizada para troca de informaes entre
detectores. Usada para complementao de diagnsticos.
Entrada: tipo da informao

desejada.
Sada:
ok, msg registrada para envio.
52
ReceiveInformation
Nome do Protocolo:
ReceiveInformation
Iniciador:
Todos corretores
Parceiro:
Todos corretores, notificador
Descrio:
Mensagens utilizada para troca de informaes entre
detectores ou entre detectores e notificador. Usada para
complementao de diagnsticos (detectres) ou para
repassar msg para usurios finais (notificador).
Entrada: Informao sobre

status do SGBD, S.O. ou rede.
Sada:
ok, msg recebida.
ReceiveRequest
Nome do Protocolo:
ReceiveRequest
Iniciador:
Todos atuadores
Parceiro:
Todos atuadores
Descrio:
Mensagen utilizada para solicitao de atuao.
Entrada: Requisio para

atuao. Identificao da
atuao desejada.
Sada:
ok, msg registrada para envio.
AnswerRequest
Nome do Protocolo:
AnswerRequest
Iniciador:
Todos atuadores
Parceiro:
Todos atuadores
Descrio:
Mensagen aviso de status de atuao.

realizao da tuao.
Sada:
ok, msg recebida.
ReceiveEpisodeFeedback
Nome do Protocolo:
ReceiveEpisodeFeedback
Iniciador:
Todos corretores
Parceiro:
Aprendiz
Descrio:
Mensagens utilizada para enriquecimento da base de
conhecimento sobre resultados das atuaes.

efetividade de episdio de
atuao.
Sada:
ok, msg recebida.
53
Apndice D Papis definitivos
Monitor de estruturas de controle de SGBD

Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir:

- monitorar constantemente os estados das estruturas e controle do banco de dados alvo,
monitorando processos do SGBD no S.O., em arquivos de logs (traces) de SGBD ou realizando
consultas em dicionrios de dados. Caso solicitado, ele ir se comunicar com outros papis
que requisitem informaes, passando dados sobre o estado atual da estruturas monitoradas
do banco.
- executar aes que visam recuperar o estado das estruturas de controle do banco de dados
e aes de correo de falhas.
- notificar papel coordenador sobre falhas, aes e resultados.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
QueryKB // consulta base de conhecimento
Notify,
AskForInformation,
ReceiveInformation,
HealingDB,
MonitoringDB,
Reads DBState
Reads OSState
Changes DBState
AnswerInfRequest) | (MonitoringDB) || (HealingDB) | (AskForInformation) |
(ReceiveInformation) | QueryKB | Notify )
SO, processos do SGBD e ao SGBD alvo. Ter acesso base local de conhecimento.
54
Monitor de estruturas fsicas de SGBD

Papel: MonitorPhysicalDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir:

- monitorar constantemente os estados das estruturas fsicas do banco de dados alvo em
arquivos de logs (traces) de SGBD, realizando consultas em dicionrios de dados e verificando
estados de estruturas de memria em disco (via S.O.). Caso solicitado, ele ir se comunicar
com outros papis que requisitem informaes, passando dados sobre o estado atual do
banco.
- Esse papel ir executar aes que visam recuperar o estado do banco de dados e aes de
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
AskForInformation,
ReceiveInformation,
Notify,
HealingDB,
MonitoringDB,
Reads DBState
Reads OSState
// O estado dos processo e reas do SO
Changes DBState
MONITORPHYSICALDB = registerServiceDirectory.((ReceiveInfRequest . ProccessInfRequest .
AnswerInfRequest) | (MonitoringDB) | | (HealingDB) | (AskForInformation) |
(ReceiveInformation) | QueryKB | Notify)
SO, reas de memria em disco e ao SGBD alvo Ter acesso base local de conhecimento.
Monitor de estruturas lgicas de SGBD

Papel: MonitorLogicalDB
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel preliminar ir:

- monitorar constantemente os estados das estruturas lgicas do banco de dados alvo em
arquivos de logs (traces) de SGBD ou realizando consultas em dicionrios de dados. Caso
solicitado, ele ir se comunicar com outros papis que requisitem informaes, passando
dados sobre o estado atual do banco. Eventualmente, tambm poder requisitar informaes
de outros agentes.
- executar aes que visam recuperar o estado do banco de dados e aes de correo de
falhas. Eventualmente, tambm poder requisitar informaes de outros agentes.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
AskForInformation,
ReceiveInformation,
Notify,
HealingDB,
MonitoringDB,
Reads DBState
Reads OSState
// O estado dos processos e reas do SO
Changes DBState
MONITORLOGICALDB = registerServiceDirectory.((ReceiveInfRequest . ProccessInfRequest .
AnswerInfRequest) | (MonitoringDB) | HealingDB) | (AskForInformation) |
(ReceiveInformation) | QueryKB |Notify)
SO, reas de memria e dicionrio de dados do SGBD alvo. Ter acesso base local de
conhecimento
55
Monitor de SO
Papel: MonitorSO
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety

- monitorar os estados do Sistema Operacional, atravs da aquisio de informaes em
variveis de ambiente, processos e reas de armazenamento. Ir se comunicar com papis
que requisitem informaes sobre os estados monitorados.
- executar aes que visam recuperar o estado de elementos do S.O.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
AskForInformation,
ReceiveInformation,
Notify,
HealingOS,
MonitoringOS,
Reads OSState
// estado do S.O.
Changes OSState
// operaes de alterao de elementos do S.O.
Reads KnowlodgeBase // l estratgias de correo de problemas.
MONITOROS = registerServiceDirectory ( (ReceiveRequest . ProccessInfRequest
.AnswerRequest) | (MonitoringSO) | (HealingSO) | |(AskForInformation) |
(ReceiveInformation)) | QueryKB | Notify)
Monitor de rede
Papel: MonitorNetwork
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety

- monitorar os estados da rede de comunicao, atravs da aquisio de informaes em
variveis de ambiente, processos, portas etc. Ir se comunicar com papis que requisitem
informaes sobre os estados do monitorados.
- executar aes que visam recuperar o estado de elementos da rede de comunicao.
ReceiveInfRequest,
ProccessInfRequest,
AnswerInfRequest,
Notify,
AskForInformation,
ReceiveInformation,
HealingNetwork,
MonitoringNetwork,
Reads OSState
// estado do S.O.
Changes OSState
// operaes de alterao de elementos do S.O.
MONITORNETWORK = registerServiceDirectory ( (ReceiveRequest . ProccessInfRequest .
AnswerRequest) | (MonitoringNetwork) | (HealingNetwork) | (AskForInformation) |
(ReceiveInformation) | QueryKB | Notify)
Notificador
Papel: Notifier
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes de interface entre o sistema e os usurios finais. Informaes
coletadas de outros papis sero registradas em base de dados apropriada e/ou enviadas para
os usurios finais.
SendInformation,
ReceiveInformation,
RegisterInformation,
Changes LogBase
// registra eventos
NOTIFIER = registerServiceDirectory (SendInformation | RegisterInformation |
ReceiveInformation)
Ter acesso base de registro de eventos.
56
Gerente de Conhecimento
Papel: KnowledgeManager
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir executar aes de aprendizagem, registrando na base de conhecimento novos

casos percebidos, registros de casos pelo usurio, coleta de feedback do usurio e acertos de
casos usados, repassados pelo papel coordenador e tambm dever inferir conhecimento
atravs de similaridade.
ReceiveEpisodeFeedback, // recebe feedback dos episdios de correo
RegisterFoultCase,
InferCaseSolution,
Changes KnoledgeBase
KNOWLEDGEMANAGER = registerServiceDirectory (ReceiveEpisodeFeedback) |
InferCaseSolution | RegisterFoultCase)
Ter acesso base de conhecimento.
Coordenador
Papel: Coordinator
Descrio
Protocolos e
Atividades
Permisses
Responsabilidades
Liveness
Safety
Esse papel ir coordenar a ao dos outros papis, elaborando planos globais de resoluo de
falhas e a participao e seqncia de cada papel (planos parciais). Alm disso, ele se
responsabilizar pelo seguimento de normas organizacionais e regras de negcio (contexto),
que comporo restries s resolues dos planos (e.g. restries de horrio).
O papel tambm se responsabilizar pela orientao dos papis Notificador e Gerente de
Conhecimento, os autorizando a realizar modificaes nas suas respectivas bases de dados.
SendInformation,
ReceiveInformation,
ReceiveEpisodeFeedback, // recebe feedback dos episodios de correcao
Notify,
RegisterServiceDirectory,
CreatePlan,
Reads KnoledgeBase
COORDINATOR = RegisterServiceDirectory (ReceiveEpisodeFeedback | CreatePlan |
SendInformation | ReceiveInformation | Notify)
Ter acesso base de conhecimento
57
Apndice E Modelo de Servios
Segue abaixo a lista de modelos de servios utilizados na nossa implementao.
Servio
Resoluo de episdio de falha
Registro de feedback
Entradas
Identificao do plano global
Sadas
Pr-condies
Status de realizao concluda /

Medida de efetividade
Autorizao do coordenador
Identificao do tipo de falha e

medida de eficincia do episdio
Status de realizao concluda
Ps-condies
Feedback coletado
Servio
Registro de Execuo
Notificao de Alerta
Entradas
Identificao do tipo de falha.
Sadas
Identificao do tipo de falha, agente

atuador e dados da atuao (horrio,
plano globAL, etc)
Status de registro efetuado
Pr-condies
Execuo concluda
Ps-condies
Msg formatada para envio ao

usurio.
Falha sem atuao automtica
cadastrada.
-
Servio
Elaborao de Plano Global
Recuperao de plano parcial
Entradas
Informaes sobre tipo de falha,
Sadas
Informaes sobre tipo de falha,

plano local de resoluo,
Regras de negcio e polticas
organizacionais.
Plano global de resoluo;
Pr-condies
Identificao de falha;
Plano parcial de execuo /

indicao de falha apenas para
alerta;
Identificao de falha;
Ps-condies
Registro do plano Global.
Feedback coletado
58
Datas e assinaturas
10 de outubro de 2006.
________________________________________
Patrcia Cabral de Azevedo Restelli Tedesco
(Orientadora)
________________________________________
Davi Lyuma Anabuki
(Orientando)
59

D D: DBS: Esenvolvimento de Uma Plataforma Multiagente Cognitiva para Bancos de Ados Autônomos O Caso Do Itter Plus T G

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

D D: DBS: Esenvolvimento de Uma Plataforma Multiagente Cognitiva para Bancos de Ados Autônomos O Caso Do Itter Plus T G

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO

DESENVOLVIMENTO DE UMA PLATAFORMA

Aluno: Davi Lyuma Anabuki (dla@cin.ufpe.br)

Este Trabalho de Graduao se prope a fazer alteraes na arquitetura do

Agradeo primeiramente minha famlia, por me dar o suporte necessrio para

Agradeo tambm ao amigo Paulo Maciel, que me ajudou durante esta

Agradeo professora Patrcia, por todo o auxlio, pacincia e confiana,

A indstria de Tecnologia da Informao (TI) tem passado por um desenvolvimento

Este documento tem visa apresentar os resultados obtidos da pesquisa realizada

Fizemos tambm um estudo da padronizao sugerida pela FIPA para SMA e

Este documento est organizado da seguinte maneira:

Captulo 2 Apresenta alguns conceitos bsicos, como a noo de computao

Captulo 3 Apresenta a tecnologia utilizada durante a implementao dos agentes do

Captulo 4 Apresenta o nosso trabalho, mostrando o que foi realizado e os resultados

Captulo 5 Apresenta nossas concluses e sugestes para trabalhos futuros.

Este captulo tem como objetivo abordar os conceitos bsicos diretamente

2.1. Computao Autnoma

De acordo com Horn em seu manifesto de computao autnoma [4], a indstria de TI

O princpio da computao autnoma baseado no funcionamento do sistema

O problema da automatizao do gerenciamento de recursos computacionais no

tm evoludo para lidar com o aumento da complexidade do controle do sistema, do

O manifesto de computao autnoma identifica oito elementos chaves que devem

2.2. Sistemas Multiagente

Franklin e Graesser, em [39], fazem uma avaliao de vrios sistemas orientados a

Um agente autnomo um sistema situado dentro de um ambiente, e faz parte

J Russell e Norvig, em [43] fazem a seguinte colocao:

Alm disso, SMA tm a capacidade de oferecer as seguintes propriedades:

Aumento de velocidade e eficincia;

Aumento de robustez e confiana;

Aumento de escalabilidade e flexibilidade;

Aumento na velocidade de desenvolvimento e reuso.

Jennings, por sua vez, em [41], cita como caractersticas importantes do

A utilizao de SMA sugere a decomposio do problema em termos de agentes

Em termos de abstrao, SMA oferecem uma abstrao que auxilia a diminuio da

Em termos de organizao, SMA possuem uma representao explcita de

Huhns [40] cita como outras razes para estudar SMA:

Problemas utilizando SMAS so s vezes mais fceis de entender e mais fceis

Algumas vezes uma soluo centralizada impossvel, quando os atores

A informao envolvida necessariamente distribuda e est em sistemas de

tambm no so simplesmente Inteligncia Artificial (IA), pois existe a importncia do

2.3. Computao Autnoma, Sistemas Multiagente e SGBD

proporcionariam a criao de um novo conceito, o SGBDA Sistema de Gerenciamento

Duas iniciativas de pesquisa especficas na linha de autonomia em SGBD vm sendo

Entretanto, estas duas iniciativas de pesquisa no tm um foco especfico no

Lifschitz e Macedo [12] propem uma classificao das arquiteturas de integrao

A arquitetura em camadas representa a implementao de um sistema de agentes

A arquitetura integrada baseada na substituio dos componentes tradicionais

A arquitetura built-in, considera o uso de um SGBD existente, onde os agentes

Dentro desta classificao, tanto o DBSitter quanto o DBSitter Plus implementam

Metodologias de Desenvolvimento para Sistemas

Na seo anterior, comentamos sobre a necessidade da existncia de um esforo

2.4.1 Estudo de metodologias

2.4.2 A metodologia Gaia

A fase de anlise tem como objetivo coletar e organizar as especificaes que

A identificao dos objetivos das organizaes que constituem o sistema como

O modelo de papis preliminar

O modelo de interaes preliminar;

As regras que a organizao deve respeitar e enfatizar no seu comportamento

O resultado da fase de anlise consiste em um modelo de ambiente, um modelo

A fase de projeto de arquitetura, por sua vez, inclui:

A definio da estrutura organizacional do sistema em termos de sua topologia e

A derivao de padres organizacionais;