Parser para Fórmulas da Lógica Quantificacional Armazenadas em XML

Parser para Fórmulas da Lógica Quantificacional Armazenadas em XML Bruno Vilar 1, Parcilene Fernandes de Brito 1 1 Curso de Sistemas de Informação Centro Universitário Luterano de Palmas (CEULP/ULBRA) Caixa Postal 160 77.054-970 Palmas TO Brasil {brunovilar,pfb}@ulbra-to.br Abstract. Cloth provers of theorems are applied for the formula test, determining its validity or invalidity. When carrying through the presentation of the necessary steps to the test, has it possibility of assisting in the study of the Quantificacional Logic. The present work has for objective the development of one of the stages of the construction of a Publisher, who precedes the presentation of the stages of test, the validation of the entrance data and creation of a document XML, carried through for parsing. Resumo. Provadores automáticos de teoremas são programas que utilizam regras de inferência para a verificação da validade ou invalidade de fórmulas lógicas. Ao realizar a apresentação dos passos necessários à prova, tem-se a possibilidade de auxiliar no estudo da Lógica Quantificacional. O presente trabalho tem por objetivo o desenvolvimento de uma das etapas da construção de um Editor, que antecede a apresentação das etapas de prova, a validação dos dados de entrada e criação de um documento XML, realizados por um parsing. 1. Introdução Segundo BOYER (1995), provadores de teoremas são programas de manipulação de símbolos que tentam provar uma determinada fórmula aplicando as regras de inferência da lógica. Acrescenta, ainda, que o comportamento do provador de teoremas é determinado em grande parte pela base de dados e pelas centenas de heurísticas de controle de uso das regras de inferência, dos axiomas, das definições e de teoremas previamente provados. A apresentação dos passos executados para a prova de teoremas e fórmulas da Lógica Quantificacional é o objetivo da construção do Editor de Fórmulas. Este editor é previsto como uma ferramenta complementar ao conjunto de funcionalidades do provador Alice, desenvolvido por (BRITO, 2003), servindo como interface entre usuário e Provador. Com isso estará em desenvolvimento uma ferramenta para o auxílio no estudo da Lógica Quantificacional. Entretanto, anteriormente à apresentação dos resultados, é preciso criar as fórmulas, sob o formato de documentos XML, para servir como entrada para o Provador Alice. A necessidade de recebimento de fórmulas, e posterior conversão para documentos XML, determinou a criação de um módulo auxiliar ao Editor, o parser de fórmulas. A criação do parser é o objetivo deste trabalho.

2. Parsers para Lógica Quantificacional Os analisadores sintáticos ou parsers são responsáveis pelo processo de análise sintática de uma sentença, ou seja, pela combinação sucessiva de símbolos a ela pertencentes, com o objetivo de reconhecer sua estrutura sintática, validada por uma gramática. Para realizar essa tarefa, o parser necessita da ajuda de outros dois componentes: um léxico e uma gramática. (GREGHI, 2002) Segundo Sebesta (2003), é comum que parsers realizem, em compiladores, suas tarefas de duas formas distintas, as análises léxica e sintática. Entre os motivos para a separação são citados: I) Simplicidade: Por ser mais complexa do que a análise léxica, a sintática se torna mais simples, e clara de ser entendida, ao ser trabalhada separadamente. II) Eficiência: A separação permite aplicar uma otimização seletiva, ao ser considerado o ganho maior de desempenho, ao melhorar o analisador sintático com relação ao léxico. Trazendo as características observadas na construção de compiladores ao parser em desenvolvimento, procurou-se construir separadamente os processo de análise léxica e sintática. A separação estabelecida por meio do tratamento inicial das informações, através da análise léxica, resultou nos primeiros elementos agrupados em um vetor. Posteriormente trabalhou-se sobre o conjunto de dados resultante, analisando-os sintaticamente, de forma a reconhecer a ordem dos elementos aninhados, com posterior inserção no documento XML. A análise léxica foi desenvolvida com o uso de Expressões Regulares, que atua de forma a reconhecer padrões de caracteres, realizando a separação inicial dos elementos, para que, posteriormente, se desenvolva a análise sintática. A análise sintática foi realizada a partir da estrutura inicial, obtida pela análise léxica, em que cadeias e subcadeias foram inicialmente extraídas da entrada. Ainda que a estruturação seja realizada por intermédio de matrizes, e não diretamente por uma árvore, é realizada uma análise top-down, permitindo que a estrutura da árvore seja montada. Como resultado tem-se, posteriormente, a árvore do documento XML. A gramática, que serve como base para a análise léxica, foi definida pelos elementos que compõem a Lógica Quantificacional, que compreendem literais, variáveis, conectivos lógicos e quantificadores. Os literais são representados pelo conjunto de letras maiúsculas, como P, Q, R e S. As variáveis estão compreendidas entre as letras minúsculas de a a t, podendo obter variações a partir de números, como b¹, b² e etc. Entre os elementos estão os conectivos lógicos, que são: Negação, Conjunção, Disjunção, Condicional e Bicondicional, respectivamente representados por ~, ^, \/, -> e <->. Os quantificadores são dois: Universal e Existencial, cujas respectivas representações são: UNI e EXI. A representação dos elementos é realizada tanto para o parser em desenvolvimento, quanto para o parser existente na API DOM do Java. O primeiro, já

citado, foi definido por Expressões Regulares, tendo prevista a utilização do gerador de parsers JavaCC (JAVACC, 2003) em trabalhos futuros. O segundo tem como base a DTD definida por (BRITO, 2003), permitindo uma nova verificação sintática do documento gerado. 3 Editor para fórmulas da Lógica Quantificacional O trabalho em desenvolvimento pretende dar continuidade à criação de uma ferramenta que permita o estudo da Lógica Quantificacional através da prova de fórmulas e da apresentação de suas etapas. Com o término da construção do Provador Alice, está prevista sua unificação com o Editor, incluindo seu parser. Entretanto, a unificação deverá ser realizada preservando modularidade e baixo acoplamento, obtidos pela separação das classes e passagem de informações apenas pela criação e leitura dos documentos XML. A estrutura proposta é apresentada na próxima seção. 3.1 Estrutura do Editor Figura 1. Proposta da arquitetura entre Editor e Provador Alice. A Figura 1 apresenta a estrutura proposta entre o Provador Alice e o Editor. Através da figura é evidenciada a atual etapa do Editor que está em construção: o parser de fórmulas. A seqüência apresentada sugere o percurso realizado entre a utilização da interface pelo usuário, até a apresentação dos resultados. O processo é iniciado com a entrada dos valores pelo usuário (#1). A interface deverá permitir, ao usuário, inserir fórmulas de duas formas: I) digitação: entrada de caracteres pelo teclado, seguindo as convenções do conjunto de elementos apresentados em uma legenda. II) composição visual: a partir de elementos drag and drop, dispostos em um menu, a exemplo de editores de imagem. Ao ter a fórmula submetida (#2), o Editor utiliza o parser para verificar a validade da fórmula e, caso seja possível, criar o documento XML (#3). Se a criação do documento for realizada com sucesso, o Editor poderá passar execução para o Provador Alice (#4). A transição entre Editor e Provador pode ocorrer sem que o segundo saiba da existência do primeiro, pois, de acordo com a estrutura criada, basta que seja apresentada uma fórmula bem formada, representada em um documento XML, que a execução do Provador pode ocorrer. Conforme os passos realizados pelo provador, o documento deverá ser lido (#5) e, a partir da árvore montada em memória, deverão ser aplicados métodos para

refinamento e prova. Com a finalização destes procedimentos, a execução retorna ao Editor (#6), que deverá exibir o resultado obtido através da representação de uma árvore, além de permitir que sejam exibidos os passos necessários ao resultado. Entretanto, para que seja possível realizar o processo inverso de execução, com Alice enviando os resultados ao Editor, será preciso determinar uma saída padrão ao primeiro, de forma que o Editor possa interpretá-la sem a troca direta de informações com o Provador. Esta saída seria semelhante à entrada do Provador, constituída de um arquivo XML, cuja estrutura é previamente estabelecida por um esquema. Dessa forma, a árvore gerada em memória e os passos, utilizados para a refutação ou prova, seriam armazenados em um documento XML. O Editor voltaria à execução, podendo apresentar os resultados ao usuário. 3.2 Armazenamento de Fórmulas em Documentos O provador Alice tem como objetivo realizar a prova de teoremas quantificacionais, através da manipulação de fórmulas armazenadas em documentos XML. A manipulação é realizada por meio da API DOM do Java, pela qual o documento é armazenado em memória e seus elementos, representados por nós, são dispostos no formato de árvore. Ao ter acesso a árvore gerada, o provador procura encontrar situações em que é possível aplicar um conjunto de refinamentos desenvolvidos. Tais refinamentos procuram diminuir o número de ramificações da árvore e eliminar elementos repetidos ou ramos em que forem encontradas contradições. O armazenamento das fórmulas em documento, e sua posterior recuperação, é possível pela estrutura definida pela DTD. Esta forma de estruturação permite definir os elementos existentes e suas possibilidades de ocorrência e repetição, estabelecendo um meio de representação de fórmulas quantificacionais. A Figura 2 apresenta a DTD utilizada pelo provador Alice para a representação das fórmulas. <!ELEMENT ARG (PREM*, CONC)> <!ELEMENT PREM (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT CONC (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT VAR (#PCDATA)> <!ELEMENT LNOM (#PCDATA)> <!ELEMENT PRED (#PCDATA)> <!ELEMENT LPRED (PRED,(VAR* LNOM*), (VAR* LNOM*))> <!ELEMENT COND (ANT, CONS)> <!ELEMENT BIC (ANT, CONS)> <!ELEMENT DISJ (ANT, CONS)> <!ELEMENT CONJ (ANT, CONS)> <!ELEMENT ANT (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT CONS (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT PRIM (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT SEG (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT UNI (LPRED COND DISJ CONJ BIC UNID EXI)> <!ELEMENT EXI (LPRED COND DISJ CONJ BIC UNID EXI)> <!ATTLIST LPRED ID CDATA #IMPLIED> <!ATTLIST LPRED NEG CDATA #IMPLIED> <!ATTLIST COND ID CDATA #IMPLIED> <!ATTLIST COND NEG CDATA #IMPLIED> <!ATTLIST BIC ID CDATA #IMPLIED> <!ATTLIST BIC NEG CDATA #IMPLIED> <!ATTLIST CONJ ID CDATA #IMPLIED> <!ATTLIST CONJ NEG CDATA #IMPLIED> <!ATTLIST DISJ ID CDATA #IMPLIED> <!ATTLIST DISJ NEG CDATA #IMPLIED> <!ATTLIST UNI ID CDATA #IMPLIED> <!ATTLIST UNI NEG CDATA #IMPLIED> <!ATTLIST EXI ID CDATA #IMPLIED> <!ATTLIST EXI NEG CDATA #IMPLIED> Figura 2. DTD definida por (BRITO, 2003)

A DTD prevê como elemento raiz Argumento (ARG), que pode conter zero ou mais ocorrências de uma Premissa (PREM) e, obrigatoriamente, uma conclusão (CONC). Tanto premissa, caso exista, quanto conclusão, devem conter um dentre os seguintes elementos: Letra Predicativa (LPRED), Condicional (COND), Disjunção (DISJ), Conjunção (CONJ), Bicondicional (BIC), Universal (UNI) e Existencial (EXI). Letra Predicativa é formada por um Predicado (PRED) e dois elementos, cada um podendo ter zero ou mais ocorrências de uma Variável (VAR) ou Letra Nominal (LNOM). O Condicional é formado por dois elementos, antecedente (ANT) e conseqüente (CONS). Ambos podem conter qualquer um dos sete elementos listados anteriormente, que constituem os elementos existentes na linguagem quantificacional. Assim como o Condicional (COND), os elementos Bicondicional (BIC), Conjunção (CONJ) e Disjunção são formados por dois elementos, que podem ser quaisquer dos sete elementos citados. Entretanto, os elementos são representados por Primeiro Termo (PRIM) e Segundo Termo (SEG). Os elementos quantificadores Universal (UNI) e Existencial (EXI) são compostos por um elemento, que, de acordo com o padrão estabelecido pelos elementos anteriores, pode ser: Letra Predicativa, Condicional, Disjunção, Conjunção, Bicondicional, Universal e Existencial. 4. Etapas para a Definição do Parser As etapas que antecedem a prova das fórmulas, pelo provador Alice, e sua apresentação, prevista no Editor, são a entrada dos valores por parte do usuário e, a partir destas, a criação de documentos XML. Ainda que sejam estabelecidos recursos de validação, e a inserção dos elementos esteja disponível a partir da seleção de itens pré-existentes no Editor, não é possível garantir a integridade das fórmulas ou identificar de imediato cada elemento. Tais problemas estabelecem a necessidade de criação de uma etapa intermediária, entre Editor e Provador, a de realização do parsing dos valores de entrada. Esta etapa deve ser capaz de analisar os valores recebidos, verificar a conformidade destes com os elementos pertencentes ao vocabulário, reconhecer elementos e regras para, então, realizar a criação do documento XML. A estrutura do parser foi definida de forma que as ações de reconhecimento e extração fossem realizadas por regras. Estas foram criadas pelos recursos oferecidos pelo pacote java.util.regex, que oferece métodos que trabalham com Expressões Regulares. Estas regras, assim como diferentes formas de representação dos elementos, foram agrupadas de modo a permitir que novos elementos possam ser inseridos sem alterar a estrutura da ferramenta. A criação do parser desenvolvido envolveu as seguintes etapas: Definição dos elementos que compõem as fórmulas; Composição de uma fórmula contendo a formalização de todas as possíveis ocorrências; Extração dos elementos reconhecidos nos valores de entrada; Tratamento dos elementos para posterior utilização;

Inserção dos elementos no documento XML. 4.1 Definição dos elementos que compõem as fórmulas: Para cada elemento existente no vocabulário, cuja utilização estivesse prevista no trabalho, foi criada uma constante e definido um valor inteiro que o identificasse. Determinada a presença do elemento, criou-se uma estrutura para o armazenamento do conjunto de dados necessários ao reconhecimento, extração e representação deste. A Figura 3 exibe a estrutura criada. Figura 3. Estrutura com os recursos oferecidos para a manipulação dos elementos. 4.2 Composição de uma fórmula contendo a formalização de todas das possíveis ocorrências A partir da definição das fórmulas de cada elemento, criou-se um único valor contendo todas as representações, associadas por conjunções, como forma de identificar os elementos existentes nas entradas (Figura 4). Figura 4. Unificação das fórmulas criadas. Organizados os padrões para o reconhecimento dos elementos, foi criado o método que obtém uma extração inicial. O método é aplicado sobre cada sentença, como o resultado da separação das premissas, caso existam, e conclusão. A separação resultante permite uma recuperação superficial, alcançando elementos entre parênteses e sentenças, que podem constituir elementos aninhados ou individuais. Neste método a recuperação de um único elemento é possível apenas quando este representa uma premissa completa. 4.3 Extração dos elementos reconhecido nos valores de entrada Na Figura 5 é apresentado o método separar, que realiza a distinção inicial dos elementos. O processo de separação é iniciado pela utilização do método matcher. Este método é chamado a partir de uma instância de Pattern, que constitui as expressões definidas pela seção 4.2, e recebe como parâmetro o espaço de busca. Estes valores são

respectivamente representados por _sentença e entrada. Como retorno tem-se uma instância do objeto Matcher. Com o objeto retornado é possível manter um laço de repetição, verificando ocorrência de um elemento a partir das fórmulas, através do método find, e recuperar o valor encontrado, por meio do método group. Os valores recuperados são armazenados em um vetor, cuja utilização está prevista em um novo processo de extração, referenciado ao final do método. Figura 5. Extração inicial dos elementos Como resultado da primeira extração, têm-se os valores que podem possuir elementos aninhados, conforme exemplo apresentado na figura 6. Figura 6. Exemplo de elementos recuperados a partir da primeira extração 4.4 Tratamento dos elementos para posterior utilização Para recuperar tanto elemento externo, quanto elementos aninhados, a partir dos valores inseridos no vetor, é utilizado o método analisarelementoexterno (Figura 7). O método recebe como parâmetro o índice de velementos, correspondente à premissa a ser trabalhada. A partir do índice recebido, é recuperado vinterno, permitindo que cada elemento seja acessado. A princípio, o elemento trabalhado tem seus parênteses externos retirados, caso existam, e, em seguida, é determinada a expressão que o representa (existente em OPERADORES), a partir do retorno do método getoperador (Figura 8). Depois de reconhecido, o elemento é retirado de vinterno, sendo que em seu lugar é colocada a representação do elemento, com o número de negações que possuía anteriormente. Com a inserção da representação do elemento é verificado se o elemento atual é uma variável ou outro elemento. Sendo variável, seu valor é armazenado. Caso contrário, é utilizado o método split a partir do elemento, passando como parâmetro a expressão que representa o operador em si. Dessa forma são retornados em um vetor, apenas os elementos, sem o operador. Cada elemento retornado é inserido em vinterno.

Figura 7. Método para realizar o restante da separação dos elementos. O método getoperador tem como entrada o elemento apresentado na fórmula. Ao realizar uma comparação, através do método matches, de que este elemento está de acordo com a fórmula apresentada em OPERADORES, é descoberto o elemento do vocabulário a qual ele pertence. A Figura 8 apresenta o método. Figura 8. Método que identifica o elemento e retorna a posição de seu operador. 4.5 Inserção dos elementos no documento XML Ao término do método separar, e as consecutivas execuções de separarelementoexterno, tem-se os elementos separados e identificados, apresentando o operador a que representa e suas respectivas negações. A partir dessa organização, é iniciada a montagem do documento. Na Figura 9 é mostrado o método montardocumento. O processo é iniciado com a instanciação da classe Documento, que provê os métodos para a inserção de cada elemento em um documento XML, sobre as definições da DTD citada na seção 3.2. Cada vinterno, que corresponde a uma premissa ou conclusão, é recuperado de velementos. Os elementos do vetor interno passam a ser recuperados, e o elemento a que representam são novamente identificado, através do método getoperadordescricao. Identificado o operador, é realizada a chamada do método correspondente ao elemento, para sua inserção no documento.

Figura 9. Método que permite relacionar os elementos extraídos ao método correspondente a sua inserção na árvore Ao término da geração do documento XML é possível verificar se a fórmula é bem formada, através do parser da API DOM. O documento é validado a partir da DTD. Como resultado da validação, são interpretadas as mensagens da API DOM, apresentando, através do Editor, as mensagens de erro ao usuário, caso existam. 5. Considerações Finais O trabalho realizado envolveu a construção de um parser para fórmulas da Lógica Quantificacional, como uma etapa intermediária na construção de um Editor para a construção de fórmulas em documentos XML e a apresentação das etapas de prova. O parser trabalhado foi dividido nas etapas de análise léxica e sintática. Tanto a definição da léxica, quanto parte da gramática, foram definidas por Expressões Regulares. A utilização deste recurso permitirá, como trabalho futuro, o uso do gerador de parsers JavaCC, sobre o qual podem ser definidas a léxica, a partir de Expressões Regulares, e a gramática, no formato BNF. Além da finalização do parser, estão previstas modificações que permitirão criar um ambiente de aprendizado para a Lógica Quantificacional. Entre as modificações estão: A exibição das etapas de prova de forma compreensível aos alunos iniciantes, demonstrando as regras utilizadas, que deverá ser enviada pelo Provador Alice ao Editor; A criação da interface para que seja admitida a entrada de valores pelo usuário, através de elementos visuais ou por digitação.

6. Referências BOYER, M. Kaufmann B.; MOORE, J.S. The Boyer-Moore Theorem Provers and It s Interactive Enhancement. Computers and Mathematics with Applications, Vol. 29, No. 2, pp. 27-62. BRITO, P. F. (2003) Dedução Automática por Tableaux Estruturada em Xml, Dissertação de Mestrado UFSC. CARINGI, A. M. (2002) PROJAVA: Um tradutor de Prolog para Java, Trabalho de Conclusão de Curso Universidade Católica de Pelotas. GREGHI, J. G. (2002) Projeto e Desenvolvimento de uma Base Dados Lexicais do Português, Dissertação de Mestrado USP. JAVACC (2003) Java Compiler Compiler The Java Parser Generator, https://javacc.dev.java.net/, Setembro. SEBESTA, R. W. Conceitos de linguagens de programação. 5 ed. Porto Alegre:Bookman, 2003.