d) Aula 11 - Clarion: Controlando o WorldServer3D

Aula 11 - Clarion: Controlando o WorldServer3D

Objetivo:

O objetivo da aula é utilizar a arquitetura cognitiva Clarion para controlar uma criatura artificial no WorldServer3D, de modo análogo ao que foi feito com o SOAR.
Para tanto, é necessário entender o funcionamento do Clarion, e desenvolver uma instância da arquitetura Clarion para controlar a criatura.

Relatório de Atividades:

• Atividade 1: Teste 1 - A criatura deve buscar todas as jóias designadas em seu leaflet e deve parar depois disso.
• Atividade 2: Teste 2 - Duas criaturas devem competir para buscaras jóias que lhes foram delegadas. A primeira delas será a criatura com o controlador desenvolvido em SOAR na aula 7. A segunda será a criatura com o controlador usando o Clarion.

Atividade 1:

Implementação 1 -> versão comentada do código.

O código foi todo dividido e comentado.Esta versão é temporária já que estou melhorando aspectos relacionados a encapsulamento e Orientação a Objetos.
Versão 1 -> SimulationCLARION_Renato_Borelli_v1.zip

Versão 1 - Executável ->Release_Renato_Borelli_v1_exe.zip

Regras fixas são declaradas e as ações são determinadas por dois níveis diferentes:

ACS, Action Centered System ->

Determina ações através de regras pré-estabelecidas em forma de conhecimento. Devem prover um comportamento elaborado e baseado no conhecimento refinado (Top). Utilizado para ações relacionadas a andar, andar em direção a alimento ou comida, comer e pegar jóias.

MS, Motivation System ->

Determina ações menos elaboradas e, supostamente, mais rápidas. Provê capacidade reativa, instinto primitivo, ligado a emergências ou sobrevivência(Bottom). Utilizada para a situação emergente de se evitar um acidente, ou seja, evitar colisão com a parede.

Observações:

- O projeto ClarionDEMO, mesmo em sua versão original, induz a uma programação que utiliza muito pouco das vantagens da Orientação a Objetos: encapsulamento, herança e representação fiel ao “business”. Parece uma mistura muito pouco organizada de uma série de métodos. Algumas classes não possuem nomes adequados e assumem tarefas inapropriadas.

- A plataforma Clarion, com certeza, é uma boa proposta. Mas se integrou muito fortemente à própria linguagem C#, chegando ao ponto de explicar seus detalhes através da linguagem, não pelos conceitos da arquitetura. Faltam conceitos mais claros e detalhados no ponto de vista da arquitetura, com esquemas gráficos. A biblioteca não é organizada/documentada de forma intuitiva, deixando claro que não assumiu como framework a arquitetura proposta. Há um excesso de programação “a La Microsoft”, com métodos de nomes enormes, pouco encapsulamento e hierarquia. Ficaria melhor, no meu ponto de vista, com mais um nível de encapsulamento e abstração adotando uma organização e framework integrado aos conceitos da arquitetura. A programação e organização da plataforma na linguagem .NET fica tão desvantajosa que não justifica sua utilização pela ausência do pattern "Business Delagate" na plataforma Java. Observo ainda que tal pattern é um conceito da plataforma J2EE/SOA e, se não existente na biblioteca na época, poderia certamente ser implementada em código.

- Um exemplo claro em que a plataforma Clarion não segue a própria arquitetura em sua organização. De acordo com a figura abaixo, a arquitetura Clarion concebe a existência de 4 blocos básicos:
# Action Centered System (ACS).
# Non-Action Centered System (NACS).
# Motivation System (MS).
# Meta-Cognitive Subsystem.

Na implementação em código desta arquitetura, estes 4 blocos se fundem em uma série de métodos, todos no mesmo nível, no mesmo pacote. Não existe uma classe ACS, nem mesmo uma interface ACS, que seria mais interessante. Nem para nenhum dos outros módulos. Tudo parece ser orientado a procedimentos.

A arquitetura Clarion também concebe algumas formas básicas de aprendizado, utilizando os módulos ACS (explícito e implícito), NACS (explícito e implícito) isoladamente ou de forma cruzada (colaborativa). Também há a possibilidade da utilização conjunta do sistema de motivacional, MS, e de monitoramento, MCS, conforme a figura abaixo.
# Top Level.
# Bottom Level.
# Top-Down.
# Bottom-Up.

Porém, não existe uma interface especializada em aprendizado, nem mesmo uma classe “Aprendizado”, ou "Conhecimento", nada que guie a sequência de chamadas dos métodos e a atribuição de parâmetros. Qualquer desenvolvedor que queira utilizar esta plataforma, estará fazendo sempre do início, uma coleção enorme de métodos, guiada por textos, com poucas figuras sobre a arquitetura, que também não serviriam para orientar na codificação, como já comentamos. Comparar desempenhos de implementações diferentes, utilizando formas de aprendizado e parâmetros diferentes pode ser uma tarefa bastante complicada, pela ausência de "patterns" para estas implementações e pela extrema volatilidade de tipos de códigos que poriam surgir.