SmartMail| Entidade Promotora: Parceiros:
1/2 Projeto em curso com o apoio de:
22/04/2014
Motores de Regras
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
Í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
Experimentação Prática ........................................................................................................ 27
Variantes ............................................................................................................................... 31
Sistemas de motores de Regras Fuzzy .......................................................................................... 33
Fuzzy Jess ................................................................................................................................... 33
Experimentação Prática ........................................................................................................ 33
FuzzyCLIPS ................................................................................................................................. 38
Experimentação Prática ........................................................................................................ 38
fuzzyTECH .................................................................................................................................. 47
Experimentação prática ........................................................................................................ 47
jFuzzyLogic ................................................................................................................................. 58
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
Í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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
Í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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
É 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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio 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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
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. 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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
Experimentação Prática
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
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.
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
Experimentação Prática
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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”
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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:
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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”.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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, …).
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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).
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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
SmartMail| Entidade Promotora: Parceiros:
2/2 Projeto em curso com o apoio de:
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.