Motivac¸˜ao e objetivo

Conceitualmente, os aspectos de arquitetura interna dos agentes de um SMA e os aspectos sociais do SMA (definindo os pap´eis dos agentes bem como seus protocolos de comunicac¸˜ao e interac¸˜ao) s˜ao ortogonais. No entanto, nenhum dos SMA constru´ıdos at´e hoje contempla a complexidade agregada de todos esses aspectos. Na pr´atica, todos podem ser classificados em duas grandes categorias:

• SMA com ˆenfase social, constitu´ıdos por um grande n´umero de agentes internamente sim-

ples, e que interagem dentro de uma sociedade complexa em termos de grupos, pap´eis e protocolos de interac¸˜ao. Esses SMA podem ser vistos como uma extens˜ao de siste- mas distribu´ıdos tradicionais com autonomia de comportamento e protocolos de interac¸˜ao adaptativos, mas sem racioc´ınio sofisticado;

• SMA com ˆenfase cognitiva, constitu´ıdos por um pequeno n´umero de agentes, cada um

sendo internamente complexo, mas que interagem dentro de uma sociedade simples em termos de grupos, pap´eis e protocolos de interac¸˜ao. Esses SMA podem ser vistos como uma extens˜ao situada, reativa, pr´o-ativa e distribu´ıda de sistemas especialistas tradicio- nais, mas sem habilidade social sofisticada.

Essa divis˜ao se explica pela dificuldade de desenvolvimento e execuc¸˜ao de SMA complexos socialmente e cognitivamente. Esses constituem apenas um objetivo que permanece ainda longe de alcance do estado da arte atual. Tal alcance requer a integrac¸˜ao harmoniosa de t´ecnicas para construc¸˜ao de SMA com ˆenfase social e para construc¸˜ao de SMA com ˆenfase cognitiva.

Para facilitar a construc¸˜ao de SMA com ˆenfase social, v´arias metodologias e ferramentas j´a foram propostas. Exemplos de metodologias s˜ao Tropos (Giunchiglia et al. 2002), GAIA (Wooldridge et al. 2000) e Prometheus (Padgham & Winikoff 2002). Em (Sudeikat et al. 2004) e (Tveit 2001) algumas metodologias e comparac¸˜oes entre elas s˜ao apresentadas. Exemplos de ferramentas s˜ao Jack (Busetta et al. 1999), JADE (Bellifemine et al. 2003) e Zeus (Nwana et al. 1999), discutidas na sec¸˜ao 3.3. Por outro lado, atualmente existe uma carˆencia de trabalhos relacionados `a engenharia de SMA com ˆenfase cognitiva. Esse fato foi constatado na an´alise feita por Damasceno (Damasceno 2003) sobre o desenvolvimento de v´arios times de futebol simulado, que geralmente s˜ao constru´ıdos de maneira ad-hoc.

Nesse contexto, o projeto MaracatuRFC surge com o intuito de aplicar e desenvolver tecno- logias e t´ecnicas de engenharia de software na construc¸˜ao de SMA com ˆenfase cognitiva. Para tal foi adotado como desafio a construc¸˜ao de um time de futebol de robˆos simulado. At´e o pre- sente momento as ac¸˜oes realizadas foram a escolha e aplicac¸˜ao de linguagens para modelagem e implementac¸˜ao, a elaborac¸˜ao e aplicac¸˜ao de um processo de desenvolvimento, e a construc¸˜ao de uma vers˜ao simples do time MaracatuRFC. Essas ac¸˜oes s˜ao destacadas nas sec¸˜oes a seguir.

4.2

Tecnologias

Nesta sec¸˜ao s˜ao brevemente apresentadas as tecnologias selecionadas e que est˜ao sendo aplicadas no projeto MaracatuRFC.

4.2.1

UML e OCL

UML (Unified Modeling Language) (Booch et al. 2000) ´e uma linguagem para a elaborac¸˜ao da estrutura de projetos de software orientado a objetos. Ela pode ser empregada para a visua- lizac¸˜ao, especificac¸˜ao, construc¸˜ao e documentac¸˜ao de artefatos que descrevam sistemas com- plexos de software. UML unifica v´arios m´etodos e formalismos, e por essa raz˜ao tem sido amplamente adotada pela comunidade de engenharia de software como linguagem padr˜ao de modelagem. Algumas das vantagens do uso de UML s˜ao:

• ´E um padr˜ao aberto;

• Suporta todo o ciclo de vida do software;

• ´E baseada na experiˆencia e necessidades da comunidade de software;

• ´E suportada por diversas ferramentas.

UML fornece doze tipos diferentes de diagramas, que podem ser agrupados em trˆes cate- gorias, s˜ao elas:

Diagramas estruturais: digrama de classe, diagrama de objeto, diagrama de componente, e

diagrama de implantac¸˜ao;

Diagramas de comportamento: diagrama de caso de uso, diagrama de seq¨uˆencia, diagrama

de atividade, diagrama de colaborac¸˜ao, e diagrama de estado;

Diagramas de gerenciamento de modelo: diagramas de pacotes, diagramas de subsistemas,

e diagrama de modelos.

Contudo, por se tratar de uma linguagem informal, os diagramas de UML n˜ao s˜ao sufici- entes para gerar especificac¸˜oes claras e precisas. Torna-se necess´ario ent˜ao descrever restric¸˜oes (ou especificac¸˜oes) adicionais sobre as entidades do modelo. Essas restric¸˜oes servem para ex- pressar alguma condic¸˜ao semˆantica que deve ser preservada. Para descrever essas restric¸˜oes alguns projetistas fazem uso de linguagem natural, todavia, linguagem desse tipo n˜ao ´e ade- quada porque ´e amb´ıgua e imprecisa.

No intuito de resolver essa situac¸˜ao surge OCL (Object Constraint Language) (Warmer & Kleppe 1999), uma linguagem semi-formal, n˜ao amb´ıgua, definida pela OMG, e parte inte- grante da linguagem UML. Dentre as principais caracter´ısticas de OCL est˜ao clareza e facili- dade de uso. Essa linguagem permite descrever restric¸˜oes sobre pr´e-condic¸˜ao e p´os-condic¸˜ao de operac¸˜oes e m´etodos, assim como restric¸˜oes invariantes, cujo objetivo ´e descrever condic¸˜oes que devem ser sempre verdade para todas as instˆancias de classes, tipos ou interfaces. OCL in- corpora construtores da l´ogica dos predicados e construtores de linguagens algor´ıtmicas em uma sintaxe orientada a objetos inspirada nas linguagens mais divulgadas, como Java e C++. Por´em, OCL ´e apenas uma linguagem de especificac¸˜ao, e que n˜ao pode ser utilizada para operac¸˜oes com efeitos colaterais, como por exemplo, trocar ou excluir valores de objetos, isto ´e, OCL n˜ao ´e uma linguagem de programac¸˜ao, ´e apenas uma linguagem para especificar restric¸˜oes.

O uso de UML associado a OCL torna poss´ıvel, por exemplo, a criac¸˜ao de geradores de c´odigo tendo como entrada os modelos e as especificac¸˜oes/restric¸˜oes e como sa´ıda programas fontes em linguagem de programac¸˜ao. A Figura 4.20 mostra um exemplo de modelo UML com o uso de OCL para expressar invariantes.

Figura 4.20: Exemplo de modelo UML com uso de OCL

No contexto do projeto MaracatuRFC, UML e OCL s˜ao as linguagens utilizadas para mo- delar e projetar os aspectos estruturais e comportamentais dos agentes/jogadores do time de futebol de robˆos simulado.

4.2.2

Transaction Frame Logic

Transaction Frame Logic (TFL) ´e uma linguagem que une trˆes extens˜oes ortogonais da programac¸˜ao em l´ogica, s˜ao elas:

HiLog (Chen, Kifer & Warren 1993), que fornece sintaxe concisa e expressiva para programa-

qualquer s´ımbolo l´ogico com qualquer seq¨uˆencia finita de argumentos. Isso permite, por exemplo, usar vari´aveis como func¸˜oes, predicados e f´ormulas atˆomicas, assim como usar termos complexos no papel de func¸˜oes e predicados, e tamb´em f´ormulas atˆomicas como argumento destes;

Transaction Logic (Bonner & Kifer 1994), que fornece semˆantica declarativa em l´ogica de

Horn para operac¸˜oes dinˆamicas n˜ao-monotˆonicas, como por exemplo, atualizac¸˜oes da base de fatos e regras (e.g. operadores assert e retract), assim como fornece semˆantica para construtores imperativos como if-then-else e loops (repeat, while, etc);