Subsistema Interfaces de Representação de Conhecimento

O desenvolvimento do Mecanismo de Inferência começou pela definição das classes e interfaces que compõem o subsistema Interfaces de Representação de Conhecimento. A principal razão para isso é o fato de que esse subsistema é um subsistema não funcional, pois seus componentes não oferecem, de fato, serviços a um cliente, mas sim representam “peças” a partir das quais uma base de conhecimento pode ser construída. Portanto, trata-se de um

subsistema básico, que não depende dos demais subsistemas do mecanismo concreto, os quais, por sua vez, dependem direta ou indiretamente dos componentes oferecidos por ele. As operações apresentadas pelas interfaces de cada um de seus elementos correspondem unica- mente a operações de acesso, que permitem recuperar os atributos que uma implementação concreta dessas interfaces deve possuir. Em outras palavras, essas operações permitem recu- perar as “partes” que compõem cada um dos elementos utilizados na representação de conhe- cimento. Essas “partes” são criadas por fábricas (GAMMA et al., 1995, p.87), a partir da forma de representação que for mais conveniente para o usuário, por exemplo, sentenças em ASCII puro ou em BRML (Business Rules Markup Language) (GROSOF; LABROU, 1999).

Por se trata de um subsistema não-funcional, somente os modelos de conceitos e de classes fazem sentido para esse subsistema.

8.2.1 Modelo de Conceitos

O modelo de conceitos foi criado diretamente da descrição dos elementos sintáticos da lógica de primeira ordem apresentados em 4.3. A Figura 72 apresenta o único diagrama de conceitos que compõe esse modelo.

8.2.2 Modelo de Classes

O modelo de classes foi obtido a partir do modelo de conceitos. Algumas simplifica- ções foram efetuadas com o objetivo de minimizar o número de interfaces que fazem parte do subsistema. Deve-se ter em mente que o modelo de conceitos tem por função o perfeito en- tendimento dos elementos do domínio do problema e que, por outro lado, o modelo de classes especifica as entidades de software que deverão ser implementadas. Portanto, a escolha dos elementos e dos relacionamentos que compõem o modelo de classes deve ser realizada de forma “austera”. A Figura 73 apresenta essas interfaces, explicitando suas operações e seus relacionamentos.

Uma regra é um tipo especial de implicação na qual as sentenças a direita e a esquerda do conectivo são somente conjunções de literais. Compound Connective 1..* 11 Sentence ground : boolean 2 1 2 1 11 Conjunction 11 Negation Atom Constant value Variable name Function name Term 0..* 1..* 0..* terms 1..* 1 Equality Relation 1 1..* 1 Predicate 1..*

Disjunction Implication Equivalence

Rule 1..*

Figura 72: Diagrama de conceitos para o Subsistema Interfaces de Representação de Conhecimento

Observa-se, na Figura 73, que os conceitos Negation, Compound, Connecti- ve, Conjunction, Disjunction, Equivalence, Implication, Atom, Equality, Relation e Function não possuem correspondentes no modelo de classes. Por outro lado,

foi acrescentada uma nova interface: Literal. A interface Sentence é a definida no Subsis- tema Mecanismo Abstrato.

Embora uma regra seja um tipo especial de Compound (Implication), decidiu-se,

por tratar-se de foco primário do desenvolvimento, manter-se somente uma interface própria para ela (Rule). Desse modo, pôde-se eliminar os conceitos Compound e Implication e

nomear as operações de Rule de uma forma mais expressiva para seus usuários. Através des-

sas operações, tem-se acesso direto às suas expressões antecedente e conseqüente, sem permi- tir que o seu conteúdo seja alterado, o que caracteriza uma aplicação do padrão de projeto

Immutable (GRAND, 1998, p. 67). Com relação aos conectivos, assume-se que as expressões

antecedente e conseqüente de Rule estão, implicitamente, ligadas pelo conectivo implica (→)

1..* Rule <<Interface>> consequents 1..* 0..* 1..* 0..* antecedents Sentence <<Interface>> language() : String 1..* terms Term <<Interface>> isConstant() : boolean antecedents() : Literal[] consequents() : Literal[] Constant value() : Object <<Interface>> Variable name() : String <<Interface>> predicate() : Predicate

term(position : int) : Term isGround() : boolean isNegation() : boolean Literal <<Interface>> Predicate <<Interface>> arity() : byte name() : String modifier() : byte 1..* 1 predicate Modifiers <<Interface>> PURE : byte = 0 EVENT : byte = 1 SENSOR : byte = 2 EFFECTOR : byte = 4 TRANSIENT : byte = 8 0..* 0..* modifier EQUAL : string = "="

Figura 73: Classes e Interfaces de uso geral para representação de conhecimento

Com a eliminação de Negation e a generalização de Sentence proveniente do Subsistema Mecanismo Abstrato, os atributos negation e ground foram deixados a cargo

da implementação da interface Literal, que desempenha um papel mais amplo que o con-

ceito Atom, também eliminado. O papel que o conceito Atom desempenharia no software é

exercido por um Literal positivo. A igualdade representada por Equality foi substituída

por um predicado reservado denominado EQUAL, definido na interface Predicate. Os con-

ceitos componentes de Relation, isto é, Term e Predicate, foram transferidos para Lite- ral. A interface Predicate , além de permitir o acesso ao seu nome, através da operação name(), também permite recuperar, por meio de arity(), o número de termos a que o pre-

dicado está associado, e possíveis modificadores de seu significado, através de modifi- ers(). Para reduzir a quantidade de dados a serem transportados para cada predicado, o nú-

mero de termos e o número que representa o modificador foram escolhidos como sendo do tipo byte. A definição dos possíveis modificadores foi estabelecida em uma interface denomi- nada Modifiers, acrescentada ao Subsistema Mecanismo Abstrato por tratar-se de informa-

SENSOR (2), EFFECTOR (4) e TRANSIENT (8). Seus valores foram escolhidos de modo a

permitirem a composição de modificadores.

O conceito Function foi eliminado devido a restrição datalog (GROSOF, 1999), já

descrita em 4.5.6. O conceito Constant foi mantido; porém o parâmetro de retorno de sua

única operação, value(), foi feito o mais genérico possível (Object), para que pudesse

comportar os diversos tipos de constantes. Dessa forma, quando uma instância da classe

Constant corresponder a um símbolo, o parâmetro de retorno deverá ser do tipo java.lang.String, o mesmo ocorrendo quando a instância representar um texto. Se a ins-

tância de Constant corresponder a um número inteiro, o parâmetro de retorno deverá ser do

tipo java.lang.Integer e no caso de um número real, java.lang.Double. A classe do

usuário que implementa a interface Constant deve impor essas restrições. O conceito Variable também foi mantido, como o parâmetro de retorno de sua única operação, na- me(), igual a java.lang.String.