Análise de Motores de Regras

SmartMail| Entidade Promotora: Parceiros:

1/2 Projeto em curso com o apoio de:

22/04/2014

Motores de Regras



Índice

Índice de Figuras .............................................................................................................................. 2

Índice de Tabelas ............................................................................................................................. 4

Introdução ....................................................................................................................................... 5

Modelos de Regras .......................................................................................................................... 6

Motores de Regras .......................................................................................................................... 8

Aproximações dos motores de regras......................................................................................... 9

Forward Chaining .................................................................................................................... 9

Backward Chaining ................................................................................................................ 10

Lógica Difusa .......................................................................................................................... 12

Sistemas de motores de Regras Crisp ........................................................................................... 16

Jess ............................................................................................................................................ 16

Experimentação Prática ........................................................................................................ 17

JBoss/Drools .............................................................................................................................. 21

Experimentação prática ........................................................................................................ 22

Drools.NET ................................................................................................................................. 27

Prolog ........................................................................................................................................ 27


Variantes ............................................................................................................................... 31

Sistemas de motores de Regras Fuzzy .......................................................................................... 33

Fuzzy Jess ................................................................................................................................... 33


FuzzyCLIPS ................................................................................................................................. 38


fuzzyTECH .................................................................................................................................. 47

Experimentação prática ........................................................................................................ 47

jFuzzyLogic ................................................................................................................................. 58



Índice de Figuras

Figura 1: Distribuição de um termo difuso ................................................................................... 14

Figura 2: Termo difuso com aplicação de modificador ................................................................. 15

Figura 3: Consola do Jess pronta a receber comandos ................................................................. 17

Figura 4: Declaração de Variáveis Locais....................................................................................... 18

Figura 5: Declaração de variável Global ........................................................................................ 18

Figura 6: Criação visual de regras .................................................................................................. 22

Figura 7: Exemplo mais complexo de uma regra criada visualmente .......................................... 23

Figura 8: Tabela de Decisão ........................................................................................................... 24

Figura 9: Regras geradas automaticamente da tabela de decisão ............................................... 25

Figura 10: Exemplo de tabela expandida ...................................................................................... 25

Figura 11: Alteração das regras por matriz ................................................................................... 26

Figura 12: Aspeto da consola do SWI-Prolog ................................................................................ 29

Figura 13: Gráfico com os intervalos definidos ............................................................................. 35

Figura 14: Gráfico resultante da query ......................................................................................... 35

Figura 15: Intervalo em forma de triangulo .................................................................................. 36

Figura 16: Intervalo difuso irregular .............................................................................................. 37

Figura 17: Interseção de Intervalos ............................................................................................... 37

Figura 18: União de Intervalos ...................................................................................................... 37

Figura 19: Gráfico do intervalo difuso para “young” .................................................................... 39

Figura 20: Intervalo linear ............................................................................................................. 42

Figura 21: Gráficos das funções S, Z e PI ....................................................................................... 43

Figura 22: Intervalo onde serão aplicados os modificadores ....................................................... 44

Figura 23: Modificador Not ........................................................................................................... 44

Figura 24: Modificador Very .......................................................................................................... 44

Figura 25: Modificador More-or-Less ........................................................................................... 45

Figura 26: Modificador Somewhat ................................................................................................ 45

Figura 27: Modificador Slightly ..................................................................................................... 45

Figura 28: Modificador Intensity ................................................................................................... 45

Figura 29: Modificador de Normalização ...................................................................................... 45

Figura 30: Modificador Extremely ................................................................................................. 45

Figura 31: Projeto vazio ................................................................................................................. 48

Figura 32: Wizard de projeto simples ........................................................................................... 49

Figura 33: Tipo de projeto e número de variáveis ........................................................................ 49



Figura 34: Definição das variáveis e do formato de saída ............................................................ 50

Figura 35: Definição dos blocos de regras .................................................................................... 50

Figura 36: Diagrama obtido ........................................................................................................... 51

Figura 37: Mapeamento da variável difusa 1 ................................................................................ 51

Figura 38: Alteração de um ponto do termo Medium .................................................................. 52

Figura 39: Tabela de regras ........................................................................................................... 52

Figura 40: Mapeamento da variável difusa de saida .................................................................... 53

Figura 41: Diagrama de controlo de grua ..................................................................................... 53

Figura 42: Termos e intervalos difusos do angulo e distância da grua ......................................... 54

Figura 43:Tabela de regras entre distância, angulo e força do motor .......................................... 54

Figura 44: Simulação das regras fuzzy ........................................................................................... 55

Figura 45: Painel de Debug............................................................................................................ 55

Figura 46: Visualização bidimensional das variáveis de entrada e de saída ................................. 56

Figura 47: Visualização tridimensional das variáveis de entrada e de saída ................................ 56

Figura 48: Animação em tempo real com todas as variáveis difusas ........................................... 57

Figura 49: Diagrama de controlo com diversas variáveis e blocos de regras ............................... 57

Figura 50: Servlets com variáveis difusas ...................................................................................... 59



Índice de Tabelas

Tabela 1: Distribuição de dois termos difusos .............................................................................. 13

Tabela 2: Exemplo de tabela de regras ......................................................................................... 24

Tabela 3: Modificadores do FuzzyCLIPS ........................................................................................ 43



Introdução

O presente documento do projecto QREN Smart Mail está enquadrado na sua Actividade 3 -

“Linha de investigação 3 - Modelos de regras evolutivos”. Através deste documento pretende-

se efetuar um levantamento do estado da arte das principais técnicas e abordagens no domínio

dos motores e modelos de regras, assim como de plataformas e / ou frameworks já existentes

que possam servir de guia e de exemplo com as melhores aproximações e abordagens na área.

O objetivo de apreender tal conhecimento e metodologias prende-se com o próprio conceito

do projeto Smart Mail, onde se pretende integrar esses mecanismos no contexto do email, de

forma a incrementar a produtividade, eficiência e inteligência no modo como o email é

utilizado como ferramenta empresarial do dia-a-dia.

O documento terá como estrutura a presente Introdução, seguida de uma análise genérica e

introdutória aos Modelos de Regras. De seguida, será apresentada uma análise ao

funcionamento e às abordagens seguidas pelos Motores de Regras seleccionados para análise.

Por fim, será efetuado um levantamento e experimentação dos principais motores de regras e

ferramentas a eles associados.



Modelos de Regras

De acordo com a atualidade tecnológica, os requisitos de flexibilidade e adaptabilidade que os

sistemas informáticos estão sujeitos, são cada vez maiores. A maior parte dos sistemas

desenvolvidos recorrem a paradigmas de programação convencional, por isso, têm dificuldades

em acompanhar as constantes mudanças de requisitos, ou de se adaptarem às regras reais e

difusas do mundo real. Uma forma de dotar os sistemas com maior flexibilidade é pela

incorporação de modelos de regras.

Os modelos de regras permitem resolver problemas complexos de lógica delimitativa de uma

forma rápida, simples e de uma mais fácil manutenção ou reajuste. A utilização de regras

permite que técnicos de um determinado domínio, mesmo sem formação informática, possam

definir e manter a lógica das regras do sistema. Hoje em dia, os sistemas baseados em modelos

de regras são utilizados em diversas áreas, como por exemplo, a segurança de redes,

telecomunicações, deteção de fraudes, comércio eletrónico, banca, seguros, controlo de

satélites, etc.

Um modelo de regras é simplesmente um sistema que usa regras para derivar conclusões.

Uma regra pode ser vista como uma instrução ou comando que é aplicada a determinada

situação. Regras como ”Responder ao email”, ”Não responder ao email” e outras regras deste

tipo são constantemente utilizadas nos mais diversos contextos. Utilizando esta definição muito

geral, pode-se pensar que todos os conhecimentos e contextos podem ser traduzido em regras,

o que não é o caso.

Formalmente as regras podem ser representadas por declarações do tipo if then como nas

linguagens tradicionais de programação (C/C++, Basic, Java, etc). Podemos escrever uma regra

(em pseudo código) sobre o envio de um email, da seguinte forma:

IF Emissor importante E Assunto importante

THEN Responder já ao email



É claro que “Emissor importante” e “Assunto importante” é algo bastante subjetivo e que

necessitaria de ser definido com recurso a outras regras / variáveis semânticas, introduzindo o

conceito e a necessidade de ter uma árvore de regras encadeadas entre si, criando assim, a

“inteligência” do sistema.

A componente IF das regras escritas desta forma é normalmente designada por left-hand side

(LHS), predicado ou premissa. Já a parte do THEN designa-se por right-hand side (RHS), ações

ou conclusões.

O domínio ao qual a regra é aplicada é toda a informação disponível na base de conhecimento

do motor de regras.



Motores de Regras

A Inteligência Artificial envolve o estudo das formas do pensamento humano e aplicar esses

comportamentos e abordagens à computação. O aparecimento da Inteligência Artificial

permitiu entender melhor, modelar e resolver problemas no domínio do mundo real. Os vários

ramos da IA aplicam-se a diversas áreas tais como o processamento de linguagem natural,

processamento de visão, robótica, planeamento, mecanismos de aprendizagem e expert

systems (i.e. sistemas periciais em Português).

Os expert systems são um exemplo de sucesso da Inteligência Artificial na resolução de

problemas complexos que recorrem fortemente a motores de regras. São sistemas que

capturam o conhecimento de peritos humanos (experts) nas suas áreas de especialidade e as

replicam tendo como base um conjunto de regras que copiam o comportamento ou decisões

humanas.

Estes sistemas são sempre focados numa área bem definida e específica de conhecimento, não

sendo desenhados para resolver todos os problemas em geral. Nestes sistemas os factos,

observações e hipóteses são representados/manipulados como regras. Estes sistemas também

têm a capacidade de explicarem as suas decisões e de como chegaram a uma conclusão A,

assim como justificar porque a conclusão B foi descartada. Este é um aspeto relevante, visto

permitir aos utilizadores relacionarem-se melhor com o sistema e entenderem como funciona.

O bloco central de um expert system é o motor de inferência. Este pode ser baseado em redes

neuronais, algoritmos genéticos, motores de regras, etc. A área dos motores de regras

apresenta-se como bastante interessante no contexto concreto do email, pois a determinação

e aplicação de regras às diferentes mensagens trocadas de forma automática permite a sua

catalogação e processamento automático.

A possibilidade de inspecção da árvore de decisão permite a interpretação da lógica pericial

mesmo por parte de utilizadores não técnicos.

É importante distinguir motores de regras de expert systems (i.e. sistemas periciais) visto não

serem a mesma coisa. Os motores de regras por si só não são expert systems, mas podem ser

uma parte destes no papel do motor de inferência.



Aproximações dos motores de regras

Nesta secção do presente documento serão apresentadas algumas das aproximações mais

importantes dos motores de regras, fazendo uma análise e distinção em termos de capacidades

e funcionalidades. Inicialmente irão ser apresentados os diferentes métodos de inferência

convencional (forward chaining e backward chaining) que podem ser utilizados pelos motores

de regras. De seguida será apresentado uma abordagem diferente da lógica clássica (i.e. lógica

difusa ou fuzzy logic) que serve para trabalhar com conceitos vagos, imprecisos, ambíguos e

não determinísticos.

Forward Chaining

Nesta abordagem o algoritmo de inferência forward chaining parte de um conjunto de dados

de onde são obtidas algumas conclusões com recurso a regras. De forma iterativa essas

conclusões são adicionadas ao conjunto de dados iniciais, de onde são inferidas novas

conclusões. O processo repete-se iterativamente até se chegar à conclusão final pretendida.

Na literatura é muitas vezes utilizado um mesmo exemplo para representar esta abordagem em

que se pretende determinar a cor do animal Fritz. Nesse exemplo parte-se com os seguintes

dados:

Fritz coaxa

Fritz come moscas

Tweety come moscas

Tweety chilreia

Tweety é amarelo

Onde estão definidas as seguintes regras:

1. If X coaxa e come moscas – Then X é um sapo.

2. If X chilrea e canta – Then X é um canário

3. If X é um sapo – Then X é verde

4. If X é um canário – Then X é amarelo



Desta forma com a abordagem Forward Chaining, partindo dos dados disponíveis e com as

regras anteriores é possível num conjunto de passos lógicos chegar a conclusão pretendida

sobre qual a cor do Fritz.

Assim a regra 1 aplica-se aos dados:

If Fritz coaxa e come moscas

Obtendo-se a conclusão que é adicionada aos dados:

Then Fritz é um sapo.

Com o enriquecimento dos dados iniciais com a conclusão anterior, é então possível aplicar a

regra 3.

If Fritz é um sapo

Concluindo:

Then X é verde

Chegando desta forma a conclusão que satisfaz o objetivo inicial de determinar a cor de Fritz.

No método de inferência forward chaining uma regra é semelhante a uma declaração if-then de

uma linguagem imperativa (como o C/C++, Basic, Java), no entanto, não é utilizada de uma

forma imperativa. Nas linguagens imperativas as declarações if-then são executadas em uma

ordem definida pelo programador. No algoritmo forward chaining a parte then de uma

declaração if-then é executada assim que parte if é satisfeita pelos dados inseridos, o que

resulta em uma ordem de execução menos determinística que nas linguagens imperativas, isto

porque o motor de regras é que decide a ordem pela qual as regras são executadas.

Backward Chaining

Nesta abordagem o processo é um pouco invertido em relação ao Forward Changing. Ao invés

de se partir dos dados para conclusões intermédias que passam a pertencer a esses dados



sucessivamente até à conclusão final. Aqui, no Backward Chaining parte-se da hipótese e tenta-

se suporta-la com recurso aos dados e às regras existentes.

Tendo como exemplo o mesmo cenário utilizado na abordagem Forward Chaining, em que se

pretende determinar qual a cor do Fritz. Neste exemplo parte-se com os mesmos dados:

Fritz coaxa

Fritz come moscas

Tweety come moscas

Tweety chilreia

Tweety é amarelo

E com as mesmas regras:

1. If X coaxa e come moscas – Then X é um sapo.

2. If X chilrea e canta – Then X é um canário

3. If X é um sapo – Then X é verde

4. If X é um canário – Then X é amarelo

No entanto também se inicia com a hipótese que se pretende suportar:

O Fritz é verde.

Assim o algoritmo começa por identificar as regras que concluam e suportem (ou refutem) a

hipótese, nomeadamente as conclusões das regras 3 e 4:

Then Fritz é verde

Then Fritz é amarelo

Neste ponto seria gerada uma árvore de decisão, onde a continuação do processo seguiria

independentemente por cada regra até determinar a qual terá sucesso. Aqui a título de

exemplo ir-se-á expandir apenas o primeiro caso.

Ainda da regra 3, para esta se confirmar tem de ser cumprida a seguinte premissa:



If Fritz é um sapo

Para esta premissa ser cumprida o sistema irá procurar outras regras que a suportem. Havendo

uma equivalência da premissa da regra 3) com a conclusão da regra 1). Dessa forma o sistema

salta para a conclusão da regra 1):

Then Fritz é um sapo

As premissas dessa conclusão são:

If Fritz coaxa e come moscas

Que já não necessitam de ser suportadas por outras regras, pois são diretamente suportadas

pelos dados disponíveis. Dessa forma, a cadeia de hipóteses/premissas fica terminada e

constatada a premissa inicial que o Fritz é verde.

Alguns sistemas baseados em regras, especialmente o Prolog e seus derivados, suportam

backward chaining. Um sistema backward chaining é orientado ao objetivo (começando com

uma conclusão que o motor de regras tenta satisfazer). Num sistema deste tipo, as regras são

também declaração if-then, mas neste caso o motor tenta ativamente chegar ao objetivo de

uma regra (parte then). Se a parte if de uma regra apenas for parcialmente cumprida, o motor

poderá concluir que provar o objetivo de uma outra regra (sub objectivo) poderá fazer com que

a primeira regra seja totalmente cumprida, caso conclua isto, este vai tentar chegar ao objetivo

da segunda regra, podendo esta ter os seus próprios sub objetivos (sub goals). Este processo

continua até que o objetivo inicial seja comprovado, ou não existam mais sub objetivos,

concluindo-se assim que a regra não se verifica.

Lógica Difusa

No mundo real, longe da computação, existe muito conhecimento que não é determinístico,

sendo impreciso, incerto e ambíguo. A lógica difusa ou fuzzy remete para uma área onde se

tenta computar e processar esses dados não determinísticos.

O raciocínio humano frequentemente envolve informação imprecisa (fuzzy), que geralmente

tem origem em conceitos humanos não exatos e associações a experiências semelhantes em

vez de idênticas. Nos sistemas baseados em lógica clássica onde existem apenas dois valores



possíveis – numa lógica binária (i.e. verdadeiro/falso, sim/não, 0/1) é difícil responder a

algumas questões, visto não terem respostas completamente verdadeiras ou completamente

falsas. Os humanos, porém conseguem normalmente dar respostas satisfatórias a este tipo

questões.

A falta de clareza (fuzziness) ocorre quando o limite de uma informação não se encontra bem

definido. Por exemplo, palavras como jovem, idoso; alto, baixo; bom, mau; quente e frio

representam conceitos difusos. Não existe um valor quantitativo que defina o termo ”jovem”.

Para algumas pessoas, alguém como a idade de 25 anos é considerado jovem, para outros 35 é

considerado jovem. O conceito ”jovem” não tem um limite bem definido. Na maior parte dos

casos pode-se dizer que a idade limite de 1 ano é definitivamente considerada jovem e a idade

limite de 100 anos é definitivamente considerada não jovem. Porém a idade de 35 anos tem

alguma possibilidade de ser considerada jovem, bem como de ser considerada não jovem,

dependo do contexto.

Uma idade tem sempre alguma possibilidade de ser considerada jovem bem como de ser

considera idosa, como é possível de observar na tabela seguinte.

Tabela 1: Distribuição de dois termos difusos

Idade Termo Difuso

“jovem” Termo Difuso

“idoso”

25 1.0 0.0

30 0.8 0.2

35 0.6 0.4

40 0.4 0.6

45 0.2 0.8

50 0.0 1.0

Contrariamente à lógica clássica, que trabalha com objetos cujo grau de associação a um

conjunto pode ser claramente descrito como pertencente ou não pertencente, em lógica difusa

um elemento pode pertencer parcialmente a vários conjuntos, com um certo grau de

associação. O grau de associação ao conjunto é normalmente representado por valores de 0 a 1

como é observável na tabela anterior, onde 0 significa que não pertence ao conjunto e 1

significando pertence completamente ao conjunto.

Por exemplo na Figura 1 é mostrada a distribuição do grau de associação das diferentes idades

para o termo difuso jovem. Ai é observável que para as idades entre 0 e 25, o grau de



associação é 1 (definitivamente jovem) e entre as idades de 25 a 50 o grau de associação

decresce (idades com alguma possibilidade de serem consideradas jovens).

Figura 1: Distribuição de um termo difuso

A distribuição de um grau de associação de um conceito difuso como “de certa forma jovem”

ou “muito jovem” podem ser obtida aplicando operações aritméticas especificas a distribuição

de “jovem”, denominando-se de modificadores. Por exemplo, a distribuição do grau de

associação do conceito difuso “de certa forma jovem” pode ser calculado pela raiz quadrada

dos valores da distribuição de “jovem” representado na Figura 2.



Figura 2: Termo difuso com aplicação de modificador

Em que a curva de probabilidade passa a decrescer menos no inicio, mas depois cai mais

abruptamente.



Sistemas de motores de Regras Crisp

Neste capítulo serão analisados alguns sistemas já existentes de motores de regras e que

podem ser aplicados em diversos domínios, pois trabalham com regras e não com domínios

concretos.

Jess

O Jess pode ser visto como um motor de regras. No entanto, também pode ser visto como uma

linguagem de programação, devido às regras e restrições por ele utilizadas terem uma sintaxe

própria, daí o nome também remeter para essa linguagem.

O Jess é totalmente desenvolvido em JAVA para assegurar questões de compatibilidade multi

sistema. Foi desenvolvido por Ernest Friedman-Hill dos Sandia National Labs e a primeira versão

foi desenvolvida em 1995.

O Jess é um super conjunto da linguagem já existente CLIPS, uma linguagem especifica para

motores de regras e expert systems que foi desenvolvido em 1985. O Jess sendo um super

conjunto dessa linguagem, quer dizer que a estende e que a melhora com mais comandos e

ferramentas.

Embora o CLIPS seja completamente Open Source, tal não é o caso do Jess. Este é gratuito para

fins educacionais e académicos, mas necessita de uma licença para ser utilizado em contexto

comercial.

Este motor de regras suporta os métodos de inferência backward chaining e forward chaining.

Permite trabalhar com lógica clássica bem como com lógica difusa. O Jess pode ser utilizado de

modo autónomo (standalone) – como aplicação específica, na forma de uma consola/shell ou

até integrado com qualquer aplicação de Java. No modo autónomo é também possível

trabalhar com objetos Java.



Experimentação Prática

O software utilizado nesta experimentação, assim como os ficheiros de configuração, código e

regras, encontra-se nas pastas de recursos do QREN Smart Mail.

Nos testes efetuados com esta plataforma utilizou-se a versão standalone por via de consola do

próprio Jess. Desta forma evita-se criar um programa Java funcional que integre as

funcionalidades da API do Jess. Utilizando a consola ficamos focados na vertente principal e

mais relevante - estudar e experimentar o Jess.

A versão utilizada para testes é a 7.1p2. A consola do Jess tem simplesmente o seguinte apeto:

Figura 3: Consola do Jess pronta a receber comandos

Na consola podem ser inseridos comandos para carregar e executar as rotinas e os programas.

Neste caso é também possível observar uma mensagem a dizer que a aplicação vai expirar (tal

deve-se ao facto de ser uma aplicação comercial e de se estar a utilizar para efeitos de teste e

demonstração).

Os principais comandos da consola são:

(batch ficheiro.clp) Carrega e executa o programa no ficheiro.clp

(exit) Sai e fecha a consola

(facts Apresenta os factos carregados em memória

(rules Apresenta as regras carregadas em memória

(run) Corre o programa atual

(reset) Faz reset a memória



Nota: os comandos são sempre envolvidos em parenteses: “(comando)”

Os ficheiros com as rotinas para o Jess tem a extensão .clp e devem conter três componentes

principais:

fact-list e instance list: essencialmente são os dados e factos que são dados como certos

no contexto da aplicação

knowledge-base: são todas as regras que vão utilizadas pelo motor de regras

inference engine: é o motor de regras propriamente dito

A nível de variáveis essas podem ser declaradas tanto num ficheiro (.clp) ou diretamente na

consola, existindo dois tipos, as variáveis locais e globais. De seguida são apresentados alguns

exemplos de declaração para a criação de variáveis locais com recurso ao comando (bind):

Figura 4: Declaração de Variáveis Locais

Neste exemplo é declarada uma variável numérica simples, uma lista de valores, e uma classe

de Java.

A declaração de variáveis globais é semelhante, mas com recurso ao comando (defglobal)

Figura 5: Declaração de variável Global

A definição de funções pode ser vista no exemplo seguinte:

Neste caso a função myMath recebe três argumentos e efetua a divisão entre os primeiros dois

e soma o resultado ao terceiro argumento. Há a salientar que é utilizada a notação Polanesa em



que os operadores surgem primeiro que os valores. De seguida é apresentado um exemplo de

chamada a essa função com o retorno do resultado.

Os factos no Jess são vistos como dados que são considerados como certos e que podem ser

utilizados na resolução de regras. Existem dois tipos principais de factos, os ordenados e os

desordenados. Os factos ordenados são simples listas de conceitos, como por exemplo:

Neste caso foram criados factos, com o comando (assert), para a condição estado do tempo e o

facto para o estado do tempo, para o dia de hoje.

Os factos que já estão definidos podem ser consultados a qualquer altura com recurso ao

comando (facts):

Os factos desordenados são estruturas semelhantes às estruturas do C (i.e. structs), que podem

ser vistos como versões mais básicas e simplificadas de Objetos. No exemplo seguinte é

apresentada a declaração de uma disciplina:

Para criar uma instância desse facto basta:

Consultando agora todos os factos do programa com o comando (facts), obtemos:



Para definir uma regra que utilize outras regras, os factos ou variáveis utiliza-se o comando

(defrule). De seguida é apresentado um exemplo simples da criação de uma regra:

Nesta está definida uma regra que inicia o processo de ir almoçar caso se tenha fome. Embora

o Jess aceite a definição desta regra, o conceito “fome” e “ir_almoçar” teriam também de ser

definidos como regras, factos ou variáveis.

Da mesma forma que existe o comando (facts) para apresentar os factos inseridos no sistema,

aqui também pode ser utilizado o comando (rules) para listar as regras já definidas, como por

exemplo:



JBoss/Drools

Quando se fala do motor de regras JBoss é equivalente a falar do Drools, pois essa componente

do JBoss não é mais do que uma versão do Drools transformada em produto empresarial. O

Drools encontra-se assim integrado tanto no produto JBoss Enterprise BRMS e no JBoss Rules

em vertentes comerciais. No entanto também se encontra na versão Community do JBoss. O

motor do Drools é totalmente open source e gratuito, ao contrário do Jess que tem sempre

uma licença paga associada.

O JBoss/Drools é um dos mais diretos concorrentes do Jess, sobretudo porque tem tido um

grande suporte da comunidade e evoluído bastante a nível de interfaces gráficas. O facto de ser

open source também tem ajudado nesse processo evolutivo. Em muitos aspetos é semelhante

ao Jess, pois o seu motor baseia-se no RETE, o mesmo do Jess e também suporta o standart API

JSR 94 à semelhança do Jess. Também suporta tanto uma abordagem em Forward Chaining ou

em Backward Chaining na resolução dos problemas de regras.

Daqui em diante iremo-nos referir a esta aplicação simplesmente por Drools, pois a nossa

análise será focada nele e não no JBoss devido a este ser de cariz comercial e haver uma maior

dificuldade no acesso às ferramentas para experimentação.

No Drools existe um conjunto de sub-ferramentas para funcionalidades distintas. Essas

ferramentas são:

Drools Workbench

Drools Expert

Drools Fusion

jBPM

OptaPlaner

O Drools Workbench é uma interface gráfica que permite gerir e controlar as restantes

ferramentas de uma forma integrada, enquanto o Drools Expert é o motor de regras

propriamente dito. Estas duas ferramentas são as que têm mais interesse para este estudo. As



restantes aplicações, embora menos importantes, são o Drools Fusion para a criação e gestão

de eventos computacionais e processos. O jBPM é destinado a processos e workflows

integrados com regras. Por fim o OptaPlanner é destinado a criação automática de planos e

workflows.

Experimentação prática


regras, encontra-se nas pastas de recursos do QREN Smart Mail. Tendo em conta que criar

cenários complexos de regras é um processo moroso, em muitos casos a experimentação foi

baseada em dados exemplos já inseridos na plataforma.

Recorrendo ao Workbench, a grande vantagem desta ferramenta é a possibilidade de definir

regras e cenários complexos com diversas regras de uma forma gráfica e mais intuitiva para o

utilizador com menos conhecimentos técnicos de informática.

Figura 6: Criação visual de regras

Na Figura 6, é apresentado um exemplo de um ecrã onde é possível criar e editar regras para o

sistema. Do lado direito é possível identificar três áreas, “extends” caso esta regra seja uma

sub-regras ou caso especial de outra regra já existente, a parte do “when” onde são definidos

os parâmetros que fazem despoletar a regra e por fim o “then” com as ações da regra. Já do

lado direito é possível visualizar um conjunto de controlos que permitem alterar a ordem dos

parâmetros, assim como, adicionar novas cláusulas ou restrições. Ainda na Figura 7, é

apresentado outro exemplo mais complexo.



Figura 7: Exemplo mais complexo de uma regra criada visualmente

Tanto o JBoss como Drools têm outra funcionalidade visual para a modelação de um cenário

complexo de regras. Essa ferramenta é designada de tabela de decisão.

Imagine-se o cenário em que se quer transformar em regras a Tabela 2. Essa tabela tem as

condições de atribuição de dias de férias aos trabalhadores de uma empresa de acordo com a

sua idade e com o seu horário laboral. O que é representado na tabela é algo relativamente

simples e intuitivo de ser compreendido, mas que seria bastante moroso e complicado de ser

implementado por via convencional de regras baseadas em if-then. Na tabela essencialmente

cada combinação/célula teria de ser representada implicando uma sequência enorme de if-

then.



Tabela 2: Exemplo de tabela de regras

Na interface gráfica é possível criar um motor de regras baseado numa tabela de decisão, o que

simplifica muito estes cenários, em que a própria tabela pode ser representada diretamente na

aplicação, que o sistema cria e estrutura automaticamente as regras para representar todas as

hipóteses condicionais.

Figura 8: Tabela de Decisão

Na Figura 8 é apresentado um exemplo simples em que as colunas são as diversas variáveis, e

em cada linha estão parametrizadas essas variáveis de modo a cada uma representar uma

condição. Neste exemplo apenas estão definidos diferentes intervalos para os valores da idade.

Ao mesmo tempo que o utilizador define estas regras na tabela, a aplicação trata do seu

mapeamento automático para o código equivalente, como é visível na Figura 9.



Figura 9: Regras geradas automaticamente da tabela de decisão

O topo da tabela de decisão pode ser estendido e permitir a inserção de clausulas mais

complexas em cada coluna, permitindo também uma leitura mais rápida, como visível na Figura

10

Figura 10: Exemplo de tabela expandida



As regras podem ainda ser redefinidas de uma forma extremamente ágil com recurso à vista de

matriz. No exemplo da Figura 11, continuamos a ter as variáveis e regras parciais no topo, no

entanto são apresentadas 8 regras finais distintas, com diferentes combinações das colunas.

Essas combinações são facilmente alteráveis. Caso essas alterações fossem efetuadas ao nível

do código, iria ser um processo bastante moroso e com propensão a erros devido à grande

complexidade e quantidade de if-then envolvidos.

Figura 11: Alteração das regras por matriz



Drools.NET

Como já foi introduzido, o JBoss e o Drools são essencialmente a mesma aplicação, com

pequenas diferenças mas partilhando as mesmas bases e os mesmos motores. No entanto, é de

salientar que existe o designado de Drools.NET, que é essencialmente um wrapper da versão

open source do Drools. Este wrapper migra as suas funcionalidades para tecnologia .NET e tem

as mesmas funcionalidades base e hierarquia de API. Dessa forma, facilmente se consegue

integrar essas funcionalidades em ambiente .NET.

Não será efetuada uma análise em profundidade a esta ferramenta por ser uma

reimplementação do Drools já anteriormente analisado.

O software do Drools.NET, assim como os ficheiros de configuração, código e regras, encontra-

se nas pastas de recursos do QREN Smart Mail.

Prolog

O Prolog é uma linguagem de programação declarativa que surgiu pela primeira vez em 1972.

No entanto, tal idade não significa que está ultrapassada ou desatualizada, pelo contrário é

bastante utilizada em áreas como o processamento de língua natural e em muitos campos da

inteligência artificial.

O Prolog é orientado a factos, regras e restrições, o que o torna um motor de regras puro por

excelência. O Prolog só resolve os seus problemas de regras com recurso à abordagem

Backward Chaining, mas isso não é restrição nenhuma, pois os problemas que são resolvido por

Forward Chaining também o são por Backward Chaining. A única desvantagem que pode daí

advir, é que se torna um pouco mais confuso, à perceção da resolução dos problemas, para

utilizadores menos experientes com a lógica inversa do Backward Chaining.






Na experimentação prática utilizou-se o SWI-Prolog simplesmente por ser uma das variantes

com interface mais limpa e com mais documentação e comunidade, o que facilitou todo o

processo. No entanto, todos os testes efetuados podiam ser realizados em qualquer plataforma

de Prolog. Para mais detalhes consultar as Variantes de Prolog na secção seguinte deste

documento.

Para ser possível trabalhar com o Prolog é necessário criar um programa com um conjunto de

regras e factos como ponto de partida.

O programa criado, a titulo de exemplo, tem um conjunto de regras que indicam as

preferências gastronómicas do Nuno e da Vera.

Num primeiro bloco adicionaram-se regras com factos sobre os tipos de comidas que o Nuno e

a Vera gostam:

No entanto essas regras apontam para outras regras (tipos de comida), como por exemplo a

comida indiana. Só as primeiras duas e as últimas duas regras é que apontam para factos

terminais. Assim sendo é necessário definir essas regras de segunda ordem:

Desta forma os “tipos de comida” ficam definidos com factos terminais. Não sendo necessário

definir mais sub regras, pois todos os dados, direta ou indiretamente, convergem para factos.



Tendo o ficheiro criado com as regras de Prolog (encontra-se nas pastas de recursos do QREN

Smart Mail com o nome de “gostos.pl”) é então possível iniciar o SWI-Prolog (visível na Figura

12) sobre esta base de conhecimento.

Figura 12: Aspeto da consola do SWI-Prolog

Aqui, podem ser realizadas querys básicas sobre as preferências do Nuno, chamando a regra

“likes” e passando como atributos a pessoa e a comida, o sistema responde true ou false

consoante a sua base de conhecimento e de factos:

O mesmo é possível realizar sobre os tipos de comida indiana, mas havendo só um argumento

nesta regra:



Também é possível listar os tipos de comida indiana, nesse caso, em vez de se passar um

argumento válido, passa-se uma incógnita “X”, e o sistema devolve todas as condições que

satisfaçam o facto de ser comida indiana:

O mesmo pode ser realizado sobre a regra “likes”, em que se passa uma incógnita no segundo

argumento, de seguida são apresentados os resultados para o caso vera e nuno:

No caso da Vera apenas existia um facto direto que foi prontamente apresentado, já no caso do

Nuno, as respostas apresentadas não se referem a outras regras como comida indiana, chinesa,

etc, mas sim aos factos elementares que são obtidos por essas regras (comida indiana, chinesa,

etc).

Ainda é possível para a função “likes” passar duas incógnitas nos argumentos, nessa situação o

sistema irá dar todas as combinações possíveis de acordo com os factos que foram definidos no

ficheiro com os factos e as regras:



Onde se pode observar que aparecem extensivamente todos os gostos do Nuno e da Vera, que

neste caso é apenas um.

Variantes

Existem diversas variantes de aplicações e plataformas onde é possível trabalhar com Prolog.

As principais e mais difundidas são o GNU Prolog e o SWI-Prolog.

O GNU Prolog é uma das ferramentas mais antigas nesta área e essencialmente é uma consola

que permite executar ficheiros de Prolog e depois efetuar consultas sobre essas regras e

clausulas. O GNU Prolog também oferece uma ferramenta de debugging interativa que permite

detetar erros, mas também permite executar a passo-e-passo o fluxo de resolução de uma

query.

Já o SWI-Prolog é muito semelhante ao GNU Prolog, com destaque para o debugger que aqui é

uma ferramenta gráfica e mais apelativa para os utilizadores menos experientes.

Ambas as ferramentas são desenvolvidas em C e comportam-se como interpretadores que

processam o código Prolog e o compilam nativamente, dependendo do sistema onde são

executados. Ambas as ferramentas são open source e gratuitas.



Ainda se destaca a ferramenta JLog que é uma reimplementação de um interpretador de Prolog

mas feita em Java. Com esta ferramenta, é possível executar programas com regras de Prolog

num ambiente JAVA.

O passagem do Prolog para outras plataformas não se fica pelo JAVA, também é possível utiliza-

lo em ambeientes .NET, recorrendo por exemplo ao C# Prolog ou ao Prolog .NET. Estas

bibliotecas/ferramentas também são interpretadores de Prolog que permitem a interação por

via de consola, mas que também permitem embutir as funcionalidades e capacidades do Prolog

em qualquer programa desenvolvido em ambiente .NET.



Sistemas de motores de Regras Fuzzy

Fuzzy Jess

O Fuzzy Jess como o nome indica é uma variante do Jess destinada a ser aplicado em contextos

não determinísticos de logica difusa.

Essa variante Jess é obtida por via do NRC FuzzyJ Toolkit, mais simplesmente conhecido por

FuzzyJ que foi desenvolvido pelo Institute for Information Technology do National Research

Council of Canada e à semelhança do Jess é gratuito para utilização académica, mas com licença

paga para utilização comercial, isso até à versão 1.2. Na versão 2.0 o software passou a ser de

domínio publico e open source sobre a licença “Mozila Public Licence V2.0”.

O FuzzyJ Toolkit não é mais do que um conjunto de classes e métodos disponíveis em

lingauagem JAVA que permitem adicionar ao Jess a capacidade de lidar com conceitos difusos,

variáveis, termos, factos e regras. Apenas quando se adicionam as classes do FuzzyJ Toolkit ao

Jess, é que se passa a designar de Fuzzy Jess.

O desenvolvimento do FuzzyJ/Fuzzy Jess foi baseado na extensão FuzzyCLIPS desenvolvida para

o sistema CLIPS.




Na experimentação prática iniciou-se por explorar os conceitos mais simples, nomeadamente

as variáveis semâmticas, que agora são definidas por intervalos ao invés de valores discretos.

Como cenário de testes foi utilizado um hipotético sistema com o objetivo de regular

automaticamente a temperatura e o fluxo de água baseado em regras difusas. As linhas de

código que vão ser apresentadas e analisadas de seguida, são inseridas em ficheiros clp, o



mesmo tipo de ficheiros de instruções utilizado pelo Jess “normal” (i.e. “crisp” e ser recurso a

modelação “fuzzy”).

Inicialmente define-se a variável temperatura, onde se atribui o nome e o intervalo (0 - 100) e

ainda a unidade. Destaque para o tipo declarado “FuzzyVariable”.

De seguida, essa variável necessita de ser parametrizada de modo a tornar-se difusa. Com esse

propósito são definidos arrays de intervalos, onde são definidas as condições “quente” e “fria”:

Para a intervalo Hot e Cold existem duas variáveis, nomeadamente X e Y. A componente X

representa os valores que se vão sobrepor à escala de temperatura (0-100), enquanto a

variável Y representa a sua intensidade normalizada, ou seja, Hot a 27 graus será

subjetivamente “pouco quente”, enquanto Hot a 35 graus será “bastante quente”, sendo linear

essa variação entre o intervalo de 25 a 35 graus.

Para a definição de Cold ocorre o mesmo, mas de forma inversa, ou seja, 5 será “muito frio”,

enquanto 15 será “pouco frio”.

Estes intervalos ainda têm de ser associados à variável de temperatura “temp” anteriormente

definida:

Tanto o intervalo difuso “Hot” e “Cold” foram definidos explicitamente, no entanto, o Fuzzy

Jess permite definir outros intervalos implicitamente à custa de outros. De seguida é

apresentado um exemplo onde é efetuada a criação do intervalo “Medium” para a temperatura

compreendida entre o “Hot” e o “Cold”, sendo efetuado com recurso a uma expressão

linguística:

Para se ter uma melhor perceção visual sobre os conjuntos já definidos sobre a temperatura é

apresentado um gráfico que os ilustra:



Figura 13: Gráfico com os intervalos definidos

Com estes intervalos definidos já é possível efetuar algumas consultas simples, como por

exemplo, qual o intervalo que satisfaz a condição “frio e muito quente”, para tal basta inserir na

consola essa pesquisa sendo devolvido o intervalo que lhe obedece:

O resultado obtido parece confuso, mas não passa de uma listagem de pares ordenados na

forma (Y,X), onde o primeiro valor representa a intensidade e o segundo a sua posição ao longo

do eixo XX, que neste caso, corresponde à temperatura. Esse mesmo conjunto de pares

ordenados mapeado para um gráfico obtém aproximadamente:

Figura 14: Gráfico resultante da query



No entanto, os intervalos que foram definidos foram sempre de transição retilínea e linear, o

que pode não ser suficiente para modular casos mais complexos de lógica difusa. Para

contornar essa limitação o Fuzzy Jess tem um conjunto de classes que podem ser utilizadas

para modelar exemplos mais complexos. Baseando-se tanto em formas primitivas como na

união e interceção entre elas.

Uma dessas classes mais simples passa pela definição de triângulos, onde se utiliza a classe

triangleFuzzySet, como se pode observar no exemplo seguinte:

Em que cada valor indica a posição (XX) de cada vértice. Com esta especificação seria possível

definir uma variável difusa com o seguinte formato:

Figura 15: Intervalo em forma de triangulo

É ainda possível definir formas completamente irregulares, para isso basta definir dois arrays

paralelos, um para os valores de Y e outro para valores de X, e por fim declarar um “FuzzySet”

construído com esses dois arrays, como apresentado no exemplo seguinte:

A visualização gráfica desta variável difusa irregular seria algo aproximadamente da seguinte

forma:



Figura 16: Intervalo difuso irregular

Sobre diferentes variáveis fuzzy irregulares, ainda é possível, aplicar operações de união e de

interseção recorrendo ao código seguinte:

O efeito dessas operações pode ser observado nas imagens seguintes, respetivamente:

Figura 17: Interseção de Intervalos

Figura 18: União de Intervalos



FuzzyCLIPS

O FuzzyCLIPS é uma extensão do sistema de regras CLIPS que permite trabalhar com regras de

lógica difusa. O sistema CLIPS por sua vez foi o que serviu de base para o desenvolvimento do

Jess e do Fuzzy Jess já anteriormente analisados neste documento.

Tanto o CLIPS como o FuzzyCLIPS são completamente open source e gratuitos para uso

educacional ou científico.

A sigla do CLIPS significa “C Language Integrated Production System” e foi desenvolvido

inicialmente para a NASA em 1985 com o objetivo de ser uma linguagem para o

desenvolvimento de “expert systems”. O nome original deste projeto era “NAIL” sigla de

“NASA's AI Language”.

Embora a linguagem utilizada no CLIPS tenha uma sintaxe própria e relativamente de alto nível,

o funcionamento interno do motor do CLIPS é todo desenvolvido em C. Ainda assim, o

utilizador comum do CLIPS não necessita de saber programar em C.

O CLIPS pode executar de forma autónoma através de uma simples consola consumindo

ficheiros .clp com instruções CLIPS, ou então, pode ser utilizado embutidos noutros programas

desenvolvidos em C.


Para os testes efetuados foi utilizada a versão 6.10 do FuzzyCLIPS. O software utilizado nesta

experimentação, assim como os ficheiros de configuração, código e regras, encontra-se nas

pastas de recursos do QREN Smart Mail.

A experimentação prática iniciou-se por explorar os conceitos mais simples, nomeadamente as

variáveis que são definidas por intervalos ao invés de valores discretos. As linhas de instruções

que vão ser apresentadas e analisadas de seguida são inseridas em ficheiros clp, o mesmo tipo

de ficheiros de instruções utilizado pelo CLIPS convencional.



Recorrendo a um exemplo já utilizado anteriormente, pretende-se definir a variável difusa de

idade. Para tal é necessário definir um intervalo que o conceito novo e velho é absoluto, e áreas

de transição. Para tal, utiliza-se o seguinte código CLIPS:

Onde é declarada a variável “age” e os conceitos que atuam sobre ela, nomeadamente “young”

e “old”. Na definição do conceito “young” são indicados dois extremos de intervalos em que o

primeiro valor representa o eixo XX e o segundo o eixo do YY. Para o primeiro intervalo, o

primeiro valor é a posição (idade) até onde é “absolutamente” novo (25) e o segundo valor é a

probabilidade de ser novo. Já o segundo intervalo indica a posição (idade) a partir do qual

jamais será considerado novo (50) com probabilidade zero. Desta forma, está explicitamente

indicado dois intervalos, até onde é novo com probabilidade 1, e a partir de onde, a

probabilidade de ser novo é zero. Implicitamente também está definida a zona de transição (de

25 a 50), em que a probabilidade de ser novo vai decrecer linearmente.

O mesmo acontece para a definição do termo “old”, onde são definidos explicitamente os

intervalos de probabilidade 1 e zero e implicitamente é definido o intervalo de transição.

A título de exemplo fica o gráfico linear da componente “young”:

Figura 19: Gráfico do intervalo difuso para “young”



No Fuzzy CLIPS também é possível definir regras com grau de incerteza, o que pode ser

bastante útil nos contextos de logica difusa. Essas regras, ao contrário das variáveis, podem ser

aplicadas em diferentes contextos e acabam por ter uma maior expressividade. De seguida é

apresentado um exemplo para uma regra que define a probabilidade/grau de incerteza de uma

ave voar:

Como é possível observar, a linguagem CLIPS é muito verbosa, assemelhando-se bastante à

língua natural. No exemplo é indicado que o fator da regra (Conditional Factor) é de 0,95. Assim

a regra indica que se o animal for do tipo ave, há uma probabilidade de 95% de este voar. A

mesma regra num cenário de logica binária convencional, baseado em if/then, iria ter uma

cláusula simples em que se o animal fosse uma ave, iria voar. Desta forma consegue-se

observar que as regras difusas são mais adaptativas ao mundo real.

As regras no Fuzzy CLIPS podem ter três tipos diferentes de acordo com o seu grau de

“fuzzyness”, esses tipos são o CRISP Rule, FUZZY-CRISP Rule e FUZZY-FUZZY Rule.

No primeiro caso de CRISP Rule, é apresentado o seguinte exemplo constituído por uma regra e

seguido de um facto que é evocado nessa mesma regra:



A regra define (assert) a condição de fraca iluminação/escuro, tendo duas premissas, uma de

incerteza para esse facto de estar escuro (declare (CF 0.7)) e outra premissa, que é o

interruptor da luz estar desligado. No entanto, essa premissa é um facto que é definido fora da

regra, tendo também um grau de incerteza na sua definição (light_switch off CF 0.8).

Nestas sisuações o Fuzzy CLIPS resolve estas condições (regras de incerteza com factos de

incerteza) de uma forma algébrica muito simples, que poderia ser representada da seguinte

forma:

CF=CFr * CFf

Onde CFr é o fator condicional da regra e CFf o fator condicional do facto. Assim inquirindo o

sistema sobre a condição “illumination level dark” o sistema responde que o fator condicional

(global) dessa regra é:

Que é simplesmente o valor condicional global da regra e que é obtido pela multiplicação dos

dois fatores condicionais que a compõem.

No tipo de regras FUZZY-CRISP, a regra vai ter uma componente de incerteza que é a parte

CRISP e vai ter um facto. Ao contrário do exemplo anterior que também era CRISP, aqui vai ser

um facto FUZZY, obtendo-se assim uma regra hibrida com uma condicionante que é um facto

de incerteza determinístico, e com outro facto assente em lógica difusa. De seguida é

apresentado um exemplo que representa estas regras e condições hibridas:

Como é observável continua a haver a componente CRISPY de incerteza da regra (declare(CF

0.7), no entanto o outro facto em que a regra assenta (fuzzy-fact fact2) já é definido em lógica

difusa.



Por fim o terceiro tipo de regras do FuzzyCLIPS é o tipo designado de FUZZY-FUZZY e como o

nome indica, aqui toda a regra é assente e pressupostos difusos. Tanto os pressupostos como a

conclusão/resposta da regra, que também tem um output difuso. Sendo apresentado de

seguida um exemplo:

Esta regra assenta apenas num facto difuso (temperature hot), e como resultado, também

apresenta uma ação difusa (temp_change little)). Tanto o “hot” como o “little” são factos

difusos com um intervalo probabilístico associado.

Os intervalos difusos normalmente definidos no Fuzzy CLIPS são transições lineares, como já

tinham sido apresentado:

Figura 20: Intervalo linear

No entanto é possível definir outras formas para os limites destes intervalos difusos.

Recorrendo às funções Z, PI e S e tornar assim os intervalos difusos menos lineares na região de

transição. Para melhor compreender o que cada função faz, é apresentado de seguida um

exemplo gráfico de cada:



Figura 21: Gráficos das funções S, Z e PI

A nível de código CLIPS, para aplicar estes comportamentos aos intervalos é bastante simples,

como é visível observar no exemplo seguinte, onde são definidos três intervalos, cada um com

a sua função:

É possível observar que os intervalos receberam parâmetros extras, no caso do “cold” recebeu

o “z”, no “OK” recebeu o “PI” e por fim no “hot” recebeu o parâmetro “s”. Dessa forma os três

intervalos terão transições como as assinaladas nos gráficos anteriores em vez de serem

simplesmente lineares.

Outra funcionalidade interessante que o Fuzzy CLIPS apresenta para a manipulação de

intervalos difusos é a capacidade de aplicar modificadores. Os modificadores de um intervalo

aplicam sobretudo alterações do valor Y do intervalo. Sendo esta outra forma de fazer com que

os intervalos difusos não seja simplesmente lineares e que possam tomar outras formas. De

seguida é apresentada uma tabela resumo desses modificadores:

Tabela 3: Modificadores do FuzzyCLIPS

Nome do Modificador Alteração

not 1-Y

very Y^2

somewhat Y^0,333

more-or-less Y^0,5



extremely Y^3

intensify Y^2 if Y in [0 – 0,5] 1-2(1-Y)^2 if Y in [0,5 - 1]

norm

slightly

De seguida será apresentada uma representação gráfica de cada modificador para uma melhor

perceção dos mesmos.

Figura 22: Intervalo onde serão aplicados os modificadores

Figura 23: Modificador Not

Figura 24: Modificador Very



Para chamar estes modificadores basta evocar o seu nome na declaração do intervalo. No

código seguinte é apresentado um exemplo de como aplicar uma dessas transformações.

Figura 25: Modificador More-or-Less

Figura 26: Modificador Somewhat

Figura 27: Modificador Slightly

Figura 28: Modificador Intensity

Figura 29: Modificador de Normalização

Figura 30: Modificador Extremely



Neste exemplo o intervalo “cold” e “hot” são definidos de forma convencional, no entanto, o

intervalo “freezing” é definido com a transformação do intervalo “cold”, neste caso o

transformador utilizado foi o “extremely”.



fuzzyTECH

O fuzzyTECH é uma ferramenta inicialmente desenvolvida em ambiente académico, mas que

posteriormente passou a ser comercializado pela empresa alemã INFORM. Embora seja uma

ferramenta proprietária estão disponíveis versões de demonstração com a limitação de não se

poder guardar as alterações efetuadas nos projetos. No entanto, mesmo com esta limitação, é

possível analisar e estudar as funcionalidades e a abordagem.

O software em si é um motor de regras difusas, no entanto, ao contrário das ferramentas já

analisadas que se resumiam a ser simples bibliotecas, esta aplicação tem uma forte

componente de simulação gráfica e de controlo em sistemas reais, com a mais-valia de recorrer

a lógica difusa. A necessidade de desenvolver este sistema deveu-se ao facto de muitos

sistemas de controlo baseados em lógica clássica não serem suficientemente adaptativos e

elásticos às realidades que se pretendia modular e controlar. Em que a decisão baseada em

regras booleanas não era suficiente. Por exemplo controlar uma válvula de pressão ou a

velocidade de um motor não pode ser binário, tudo ou nada, tem de haver um comportamento

progressivo e adaptativo.

Esta ferramenta é utilizada nas mais diversas áreas que envolvam automação e controlo de

sistemas. Muitas vezes a aplicação está conectada a sistemas de controlo que permitam efetuar

ações, como por exemplo ligar e desligar interruptores, regulação de válvulas e acesso a

sensores. As áreas onde é utilizado vão desde o controlo de gruas, incineradores, de caldeiras,

de controlo climático de edifícios, controlo de geradores eólicos e solares, controlo de águas

pluviais e de águas residuais, prensas, etc.

Experimentação prática

Esta ferramenta para além de ter uma linguagem própria para definir termos, regras e

conceitos difusos, à semelhança das aplicações analisadas anteriormente, possui ainda uma

componente gráfica bastante forte, onde é possível analisar graficamente a flutuação das

diversas variáveis difusas e obter assim uma visualização diferente de um “ecossistema” difuso.

Essas variáveis podem, inclusivamente, ser analisadas em tempo real numa sequência de fluxo

temporal.



Numa primeira análise foi construído um modelo muito simplista a título de exemplo.

Posteriormente, numa segunda fase foram analisados modelos exemplo já existentes muito

mais complexos e detalhados.

Ao abrir a ferramenta (Figura 31) apenas é apresentado o editor vazio. No entanto do lado

esquerdo já é possível visualizar uma árvore de estruturação do projeto, com especial destaque

para os Inputs e Outputs do sistema dentro do grupo de variáveis. Essas variáveis são difusas,

tanto as de entrada como as de saída.

Figura 31: Projeto vazio

Embora a criação de regras e variáveis difusas possa ser definida diretamente num ficheiro de

código, como nas aplicações já analisadas, neste ambiente é possível ainda efectuar grande

parte dessa definição e modelação por via da interface gráfica.

A maneira mais fácil de se começar é iniciando o Wizard (Figura 32) e seguir um conjunto de

passos mais ou menos intuitivos.

O primeiro passo (Figura 33, à esquerda) é onde se define se o projecto tem inicio com base

num conjunto de regras já existentes num outro projecto, ou se é criado de raiz.

No passo seguinte (Figura 33, à direita) é definido o número de variáveis de entrada, neste caso

duas, o número de variáveis intermédias, neste caso nenhuma e também onde se define o

número de entradas e de saída, neste caso uma. Para cada tipo de variável (entrada, intermédia

e saída) é possível definir o número de intervalos (termos) para esse tipo de variáveis. Cada

intervalo da variável terá de estar associado a um termo linguístico (ex: Low, muito, pouco, …).



Figura 32: Wizard de projeto simples

Figura 33: Tipo de projeto e número de variáveis

Na Figura 34 (à esquerda) é onde podem ser atribuídos nomes às variáveis, o intervalo de

amplitude e novamente o número de termos, assim, como a designação para esses termos. Já

na Figura 34 (à direita), é onde se define o tipo de output para conectar a dispositivos físicos de

controlo – tal não sendo relevante para a nossa experimentação.



Figura 34: Definição das variáveis e do formato de saída

Figura 35: Definição dos blocos de regras

Por fim na Figura 35 é onde se define o número de blocos de regras (i.e. neste caso simples vai-

se criar apenas um bloco).

Concluindo o wizard, é então apresentado o diagrama da Figura 36, que representa as duas

variáveis de entrada (in1, in2), o bloco de regras e a variável de saída (out1).



Figura 36: Diagrama obtido

No diagrama, efetuando um duplo clique numa das variáveis de entrada surge o que é

representado na Figura 37, onde low, medium e high são os termos difusos anteriormente

definidos para a variável 1.

Figura 37: Mapeamento da variável difusa 1

Do lado esquerdo podem ser selecionados os diferentes termos, enquanto que no lado direito,

na representação gráfica surge um conjunto de pontos que permite que esses termos sejam

alterados e reajustados. Tal é visualizado na Figura 38.



Figura 38: Alteração de um ponto do termo Medium

Voltando ao diagrama do projeto, se efetuarmos um duplo clique no bloco de regras (RB1)

aparece a tabela de regras associadas ao comportamento das diversas variáveis de entrada e ao

consequente comportamento para a variável de saída.

Figura 39: Tabela de regras

Cada linha representa uma regra e como é possível de observar as regras estão baseadas nos

termos difusos anteriormente referidos. O mapeamento de regras foi definido



automaticamente, mas é possível ao utilizador alterar as regras já existentes, remover ou

adicionar novas regras.

Por fim, no diagrama principal do projeto, se for efetuado duplo clique na variável de saída

(out1) é apresentado outro quadro semelhante ao das variáveis de entrada como visível na

Figura 40.

Figura 40: Mapeamento da variável difusa de saida

Aqui existem mais termos do que nas variáveis de entrada, nomeadamente cinco, mas o

funcionamento é o mesmo, permitindo ajustes / modelação manual.

Esta ferramenta dispõe de funcionalidades avançadas de visualização da interação entre as

diversas variáveis e regras difusas. Para as analisar não vai ser utilizado o exemplo anterior, por

ser muito simples e pouco expressivo. O exemplo que vai ser utilizado é aplicado no controlo e

automação de gruas que transportam objetos do ponto X ao ponto Y. Neste cenário, também

existem apenas duas variáveis de entrada, a distância que se encontra do objetivo e o angulo

do cabo que segura o objeto transportado pela grua. Como variável de saída e de controlo é a

intensidade do motor que faz mover a grua. O desafio deste problema tem a ver com o facto de

quanto mais longe estiver mais rápido se quer meter o motor a funcionar, só que essas

acelerações, têm de ser contidas e controladas de acordo com o angulo do cabo da grua de

modo a evitar perder o controlo.

Figura 41: Diagrama de controlo de grua



Figura 42: Termos e intervalos difusos do angulo e distância da grua

Figura 43:Tabela de regras entre distância, angulo e força do motor

Na Figura 42 são apresentados os intervalos difusos e os seus diferentes termos para as

variáveis de entrada. Na Figura 43 é apresentada a tabela das regras que operam sobre essas

variáveis.

Este exemplo apresenta ainda uma simulação que permite observar o funcionamento das

regras em tempo real como apresentado na Figura 44. Nesta imagem e no seu canto inferior

direito também é possível observar os valores em tempo real das variáveis envolvidas.

Existe também um painel de Debug (Figura 45) em que com um slider é possível alterar o valor

das variáveis de entrada e ver o valor obtido pela variável de saída.



Figura 44: Simulação das regras fuzzy

Figura 45: Painel de Debug

Existem ainda modos de visualização avançada entre as variáveis difusas de entrada e de saída,

como visível na Figura 46 e na Figura 47, onde facilmente é possível observar em tempo real a

relação causa efeito entre as diversas variáveis envolvidas. Na primeira de uma forma

bidimensional com um gráfico para cada variável. Na segunda visualização, já é de forma

tridimensional e com todas as variáveis agregadas.



Figura 46: Visualização bidimensional das variáveis de entrada e de saída

Figura 47: Visualização tridimensional das variáveis de entrada e de saída

Exemplos muito mais complexos podem ser modulados como o caso seguinte, que retrata o

controlo de uma caldeira de geração de vapor. Aqui estão envolvidas diversas variáveis de

entrada, de saída e diversos blocos de regras para controlar este sistema complexo. Como é

possível visualizar na Figura 48 e na Figura 49 é um caso muito mais complexo, mas ainda

assim, bem modulado com recurso a variáveis e regras difusas.



Figura 48: Animação em tempo real com todas as variáveis difusas

Figura 49: Diagrama de controlo com diversas variáveis e blocos de regras



jFuzzyLogic

O jFuzzyLogic é uma biblioteca open source desenvolvida em Java e é destinada a implementar

motores de regras difusos, assim como definir regras e executar acções de decisão sobre as

mesmas.

Tenta-se distinguir de outras bibliotecas semelhantes por anunciar que implementa o standard

de FCL (Fuzzy Control Languange) IEC 61131 Part 7, um standard criado para normalizar

linguagem de controlo baseadas em lógica difusa.

Como é apenas uma biblioteca, as suas funcionalidades não funcionam por si só, tem de ser

embutido num programa em JAVA que faça a inicialização e chamada dos seus métodos e

objectos.

A definição das variáveis e termos difusos não é feita na sintaxe de JAVA mas sim numa sintaxe

própria definida pelo standard anteriormente referido.

De seguida da é apresentado um exemplo de declaração de uma variável assim como dos seus

termos:

A sintaxe é bastante semelhante às linguagens anteriormente analisadas, em que primeiro é

definida a variável em si, e posteriormente os termos com recurso a pontos bidimensionais

para definir a forma e amplitude de cada termo difuso.

A biblioteca ainda têm algumas funcionalidades básicas para criar applets para desenhar essas

variáveis e respectivos termos. Na Figura 50 são apresentados alguns exemplos dessas

visualizações. O código analisado anteriormente referente a variável “Service” pode também

ser visualizado no canto superior direito da mesma figura.



Figura 50: Servlets com variáveis difusas

Documents

Análise de Motores de Regras