Uma interface em linguagem natural para a verificação de regras de negócio em bases de dados

Uma interface em Linguagem Natural para a verificação de Regras de Negócio em bases de dados Amanda Varella1, Vinícios Pereira1, Vinicius VonHeld1, Geraldo Zimbrão11, João C. P. da Silva2 1

COPPE/UFRJ – Ilha do Fundão, Rio de Janeiro, Brazil;2DCC/UFRJ,

{varella,vinicios,vonheld,zimbrao}@cos.ufrj.br ,[email protected]

Abstract. The Object Constraint Language (OCL) is a language used together with other UML tools like the class diagram. Its main purpose is to state constraints in a class model. There are also many approaches suggesting the use of OCL to state Business Rules. Although OCL is a declarative language easy to understand, non-programmers can experiment some difficulty in writing OCL expressions. This paper presents Hermes, a Natural Language Processing tool that translates constraints stated in Portuguese into OCL expressions, so that the equivalent SQL query could be faced against the database. Resumo. A Object Constraint Language (OCL) é uma linguagem proposta para ser utilizada em conjunto com outras ferramentas, tais como os diagramas de classe da UML, e que serve para especificar restrições em um modelo de classes. Além disso, existe uma série de abordagens propondo o uso de OCL para a documentação de Regras de Negócio. Embora a OCL seja uma linguagem declarativa e de fácil entendimento, programadores pouco familiarizados com ela podem ter dificuldades ao escrever expressões OCL. Este artigo apresenta a ferramenta Hermes, cujo objetivo é traduzir regras de negócio expressas em português para OCL, de maneira que a consulta equivalente em SQL seja confrontada diretamente com a base de dados.

1. Introdução Um dos grandes problemas nas aplicações de banco de dados é a interface com o usuário. No contexto de BDs relacionais, embora SQL seja uma linguagem de aprendizado relativamente fácil pelos programadores, pessoas que não possuem formação na área de computação podem experimentar uma certa dificuldade em aprendê-la. Para escrever consultas em SQL para uma base de dados, além de dominar SQL é necessário conhecer o esquema da base de dados, o que implica em ter um mínimo de conhecimento do modelo relacional tanto a nível lógico como físico: tabelas, chaves primárias e estrangeiras, junções, implementação de relacionamentos m x n etc. Dito isso, fica evidente a importância de se oferecer acesso aos dados através de interfaces mais amigáveis a pessoas que não dominem SQL, ou que não dominem o esquema do banco de dados. Uma forma de facilitar o uso do banco de dados é através de técnicas de processamento de linguagem natural. A pesquisa no desenvolvimento de interfaces que viabilizem a utilização de técnicas de processamento de linguagem natural para banco de dados é um campo com muito trabalho realizado nos últimos 20 anos. Em

[Androutsopoulos et al. 1995] são apresentados diversas vantagens e desvantagens dessa abordagem. Nesse artigo tratamos um problema de grande importância prática, que é a captura e implementação de restrições e derivações em um modelo de dados. Propomos e implementamos uma ferramenta capaz de, através de técnicas de processamento de linguagem natural, entender sentenças em Português que especifiquem restrições em uma base de dados e transformá-las em consultas em SQL que verifiquem ou garantam que essas restrições serão obedecidas. Em particular, estamos interessados em gerenciar restrições e representá-las em Object Constraint Language (OCL)[OMG1 1997, OMG2 1997]. OCL é uma linguagem proposta para ser utilizada em conjunto com outras ferramentas, tais como os diagramas de classe da UML, e que serve para especificar restrições e derivações em um modelo de classes. Expressões em OCL podem ser traduzidas para consultas em SQL, bem como convertidas em triggers no banco de dados, conforme mostrado em [Demuth and Hussmann 1999, Demuth et al. 2001, Zimbrão et al. 2001,2003]. Em nosso trabalho, OCL funciona como uma linguagem intermediária entre Português e SQL. Este trabalho está organizado como se segue: a seção 2 apresenta a motivação, a seção 3 apresenta a ferramenta Hermes, a seção 4 apresenta alguns exemplos e a seção 5 é a conclusão.

2. Motivação 2.1. Atenas e o Uso de OCL para Especificação de Restrições O trabalho apresentado aqui se insere no contexto de um sistema maior, o Atenas [Zimbrão et al. 2001, 2003]. A idéia central do Atenas é servir como um sistema gerenciador de regras de negócios, permitindo a sua captura, formalização e implementação. Para o Atenas, todas as restrições sobre o modelo de classes ou sobre o esquema da base de dados devem ser encaradas como regras de negócio, mesmo as mais simples. Regras de negócio muito simples em geral podem ser mapeadas diretamente como restrições no modelo de dados, tais como campos não nulos. O Atenas procura seguir essa estratégia sempre que identifica algum tipo de restrição que pode ser implementado por um mecanismo nativo do SGBD (check constraints, uniques, not null etc). O Atenas portanto é um sistema capaz de lidar com restrições sobre os dados estabelecidas através de expressões em OCL. Uma vez que uma restrição seja estabelecida em OCL, o Atenas é capaz de detectar os eventos na base de dados que podem vir a violar essa restrição, tais como inserção de um registro, alteração do valor de uma coluna ou remoção de um registro. Além disso, o sistema é capaz de gerar o código específico para detectar e impedir violações, dentre outras formas gerando triggers que verificam a validade da restrição nos eventos correspondentes. Tudo isso é feito automaticamente a partir de uma expressão em OCL e do mapeamento entre um modelo de classes e o esquema da base de dados relacional. Além disso, para cada expressão em OCL são mantidas informações sobre a restrição em si, tais como a sua origem, aplicabilidade, histórico, analista que a levantou, eventuais documentos que a regulamentem (legislação, normas internas da empresa etc).

Nesse contexto, o Hermes traduz uma restrição estabelecida em uma sentença em Português e tenta gerar a expressão em OCL que representa essa restrição dentro de um modelo de classes. Caso a expressão seja gerada corretamente o Hermes irá ativar o módulo correspondente do Atenas que irá gerar o código SQL para fazer a avaliação da regra, e prosseguir conforme o usuário decidir: apenas armazenar a expressão OCL gerada, executar uma consulta na base de dados para verificar se algum registro viola a restrição estabelecida, ou ainda gerar o código que passe a verificar a validade da restrição nos eventos correspondentes Há diversas vantagens em utilizar OCL como linguagem para a representação de restrições. Primeiro, viabiliza a captura de restrições nas fases iniciais da análise, quando apenas o esboço de um modelo de classes está disponível, mas já formalizadas em uma linguagem declarativa com regras claras, como é o OCL. Segundo, através da integração com o Atenas, permite a geração de consultas em SQL, bem como de código para a forçar a obediência às restrições. Terceiro, OCL é uma linguagem já adotada como padrão para a especificação de restrições no um modelo de classes proposto pela UML. Quarto, uma série de trabalhos [Demuth e Hussmann 1999, Demuth et al. 2001, Zimbrão et al. 2001, 2003] propõem o uso de OCL para capturar também regras de negócios. Finalmente, a linguagem OCL apresenta um nível de abstração maior do que o oferecido pelo SQL na medida em que a navegação por ponto (dot navigation) esconde do usuário detalhes tais como nomes de chaves primárias e estrangeiras, bem como tabelas de relacionamento m x n. Como vantagem adicional, alguns tipos de alterações no esquema do banco de dados não afetarão as restrições escritas em OCL, tais como alterar nomes de chaves e tabelas para atender a algum padrão de nomes, ou mesmo mudar chaves primárias/estrangeiras. 2.2. Convertendo Restrições de Linguagem Natural para OCL Escrever restrições sobre um modelo de classes usando OCL não é uma tarefa trivial para não programadores pelas mesmas razões já listadas: é necessário ter um conhecimento sobre o modelo de classes; mesmo sendo uma linguagem declarativa OCL não é uma linguagem trivial; OCL é uma linguagem formal com regras de sintaxe e semântica bem distintas da linguagem natural. O sistema Hermes permite que não programadores descrevam restrições usando linguagem natural, em Português, e as transforma em OCL e depois em SQL. No processo eventuais ambigüidades presentes no discurso humano são eliminadas. Há três cenários onde a utilização do Hermes irá apresentar vantagens óbvias. Um cenário seria a formalização de regras de negócio ou restrições durante a etapa de análise, através da captura em linguagem natural e posterior conversão em OCL. A esta altura, não é necessário que o modelo de classes esteja muito estável – de qualquer forma o sistema suporta pequenas evoluções. Quando o modelo estiver mais estável as regras escritas em linguagem natural podem ser então transformadas em OCL, e finalmente quando o modelo relacional estiver pronto elas serão convertidas em código SQL (queries e triggers) para verificarem e manterem a integridade das regras. Dessa forma é possível documentar as regras de negócio nas etapas iniciais da análise, utilizando linguagem natural e estabelecendo as regras com um máximo de independência do modelo de dados de implementação.

Um outro cenário possível é a existência de dados legados que devem ser filtrados ou avaliados quanto à obediência as regras de negocio ou outras restrições. Como em geral o número de restrições a serem testadas é grande torna-se mais fácil estabelecê-las em linguagem natural. Além disso, as restrições no fundo são as mesmas, independentemente do esquema dos dados. Portanto, elas podem ser estabelecidas uma única vez, testadas contra os dados legados, e o tratamento adequando providenciado. Após a migração para um novo esquema, as mesmas regras são novamente traduzidas para OCL (possivelmente diferente do anterior) e compiladas para o SQL apropriado a nova base. Finalmente, podemos ter também a situação onde um analista de negócios está investigando a validade de determinadas regras de negócio, realizando uma prospecção de conhecimento em uma base de dados já existente. Assim, ao invés de restrições teríamos suposições sobre os dados, tais como “os pedidos com peso acima de 50 kg pagam frete maior que 40,00 reais e o tempo de entrega é maior que 7 dias, onde o tempo de entrega é a data de entrega menos a data do pedido”. Após o analista de domínio ou negócio elaborar uma suposição, o sistema Hermes a transformaria em OCL e depois em SQL, e investigaria a validade da mesma na base de dados, retornando o percentual de registros em acordo ou desacordo com a regra. Embora esse tipo de prospecção seja manual, é um fato geralmente aceito que boas descobertas de conhecimento em bases de dados podem ser realizadas por especialistas do negócio que sabem ou têm uma boa noção do que devem procurar. O escopo do nosso trabalho limita o tipo de discurso a ser interpretado. Primeiro, as restrições são sentenças simples e independentes uma das outras, de modo que não é necessário resolver referências a outras sentenças nem construir um modelo do discurso do usuário. Segundo, é possível estabelecermos uma forma bem limitada de sentenças para definir restrições e que ainda mantenha as características de ser uma linguagem natural. Ou seja, o sistema entende poucos tipos de declarações, mas estas são feitas em Português. De uma forma geral, uma restrição é uma declaração sobre como algo deve ou não ser: “o salário de um empregado não deve ser menor que o salário base de seu cargo”, “o chefe de um projeto deve ser da mesma divisão que o projeto”. Segundo vários autores [Date 2000, Ross, Ronald 1998, 1997, von Halle 2001], restrições não devem ser expressas como algoritmos e sim através do uso de linguagens declarativas. Nesse trabalho estendemos essa diretiva para as sentenças em linguagem natural. A característica declarativa reduz o universo de possibilidades no que diz respeito à maneira como as regras serão explicitadas. O tipo de sentença a ser processada fica com complexidade reduzida, não é necessário por exemplo que o sistema tenha um vocabulário grande de verbos – na atual implementação o Hermes entende apenas o verbo ser em suas diversas conjugações, ou em conjunto com outros verbos em expressões de significado semelhante, como “deve ser”, “não pode ser” etc. Finalmente, por estarmos estabelecendo restrições sobre um modelo de dados, os substantivos das sentenças devem ser necessariamente atributos, relacionamento, tabelas ou outros elementos presentes no esquema dos dados, o que permite eliminar boa parte da ambigüidade normalmente presente nas sentenças em linguagem natural.

3. Hermes A arquitetura do sistema Hermes é formada por três módulos, conforme podemos ver na Fig. 1: (i) pré-processamento, (ii) validação pela gramática de sintagmas e (iii) tradutor para OCL. A fase de pré-processamento é iniciada quando o usuário fornece ao sistema uma sentença que expressa uma restrição escrita em Português, referente a uma determinada base de dados. As palavras e/ou expressões da sentença são substituídas por sinônimos obtidos no dicionário de dados da ferramenta. Novas palavras e/ou expressões são incorporados ao dicionário de dados como novos sinônimos. O processamento é interativo, de forma que o sistema aciona o usuário sempre que for necessário definir um termo novo no dicionário, ou anda para resolver uma ambigüidade. Uma vez que todas as palavras tenham sido identificadas, o sistema passa para a fase de validação. Utilizando uma taxionomia previamente estabelecida, o sistema procura validar a construção da sentença de acordo com a gramática de sintagmas. A classificação de novas palavras nessa taxionomia se dá através da consulta a uma base de conhecimento. Reconhecida a construção sintática da regra, a ferramenta pode simplificá-la e padroniza-la, e passar para a fase de tradução para OCL. Concluída a tradução, o sistema retorna ao usuário a restrição em OCL. Com o aval do usuário, o sistema aciona o Atenas para produzir o SQL correspondente. Nas subseções seguintes, apresentaremos cada uma destas fases de forma mais detalhada.

Fig. 1 Arquitetura da ferramenta

3.1. Dicionário de Dados Todas as palavras ou expressões presentes em uma restrição devem estar relacionadas a elementos que tenham significados no modelo de classes. Para isso, o sistema conta com uma descrição desse modelo de classes, que representa o contexto onde as restrições serão estabelecidas: é o dicionário de dados da ferramenta. Esse dicionário

será armazenado em um arquivo XML (eXtensible Markup Language). Esse arquivo é divido em quatro partes principais: • Classes: onde são armazenadas os nomes das classes e seus atributos; • Relacionamentos: onde são armazenados os nomes dos relacionamentos existentes entre as diversas classes; • Sinônimos do Domínio: onde são armazenados palavras ou expressões referentes estritamente ao modelo do banco de dados, que possuem correspondência com nomes de classes, atributos, relacionamentos, etc; • Sinônimos permanentes: onde são armazenadas palavras que possuem valores semânticos próprios e independentes do modelo do banco de dados em questão, como verbos, pronomes, etc. No dicionário de dados, há palavras que representam nomes de entidades, de seus atributos, de relacionamentos, etc. Estas serão chamadas palavras primitivas ou com significados primitivos. Outros sinônimos podem não ter significados primitivos, mas podem estar relacionados com uma palavra primitiva. Dessa forma, todas as palavras ou expressões contidas no dicionário devem ser primitivas ou estar relacionadas com palavras primitivas. 3.2. Pré-processamento Para o sucesso das camadas subseqüentes é necessário que cada palavra ou expressão tenha significado no contexto do modelo de dados descrito no dicionário. Esta primeira camada é responsável por encontrar, nos grupos de sinônimos do domínio ou permanentes do dicionário de dados, palavras ou expressões que não possuam significado primitivo no modelo, mas que sejam sinônimos de palavras primitivas. Por exemplo, a palavra “funcionário” será substituída pelo sinônimo “TFuncionario” ou a expressão “data de aniversário” pelo sinônimo “dt_aniversario”, se essas correspondências existirem no dicionário. Para o caso de uma palavra possuir dois ou mais significados, o sistema recorre ao usuário para que este defina qual o significado desejado no contexto da sentença. Quando uma palavra é a primeira de uma ou mais expressões, o pré-processamento analisa as próximas palavras para certificar-se de que a expressão é completa. Se nenhuma das seqüências existentes é encontrada completa o sistema considera as palavras separadamente, não formando nenhuma expressão. Caso uma palavra não seja encontrada no dicionário, o usuário tem a opção de: (i) indicar um sinônimo; (ii) transformá-la em uma expressão, concatenando-a a palavras vizinhas na frase e dando significado a expressão; ou (iii) simplesmente ignorá-la, o que significará que esta palavra é primitiva e por isso deverá ser classificada na próxima camada. Para os casos em que o usuário define um significado, este é armazenado em uma estrutura que simula o XML do dicionário de dados. Estes valores serão inseridos no dicionário de dados apenas quando todo o processo de tradução for concluído sem qualquer problema. Este artifício, usado também em outras camadas, minimiza a possibilidade do usuário adicionar sinônimos com significados equivocados no dicionário.

3.3. Análise Gramatical A segunda camada de processamento está representada por uma gramática de constituintes imediatos (PSG ou phrase structure grammar) [Gazdar et al. 1985]. Esse tipo de gramática é livre de contexto e modela a estrutura sintática das frases em termos de seus constituintes. Por exemplo, uma frase (F) é formada pelos constituintes: sintagma nominal (SN) e sintagma verbal (SV). O sintagma nominal é um agrupamento de palavras que tem como núcleo, ou elemento principal, um substantivo. O substantivo representa uma classe gramatical. De forma análoga temos o sintagma verbal. A gramática implementada baseia-se nos conceitos básicos propostos pela lingüística computacional, onde adaptou-se as regras gramaticais para formatos tipicamente utilizados para expressar regras de negócios. Para auxiliar no processo de criação de regras e manutenção da gramática foi utilizado o programa TPLY [Graef], que é um porte do Yacc para Pascal – cabe dizer aqui que a ferramenta foi implementada em Pascal. No próprio compilador é necessário que o nível léxico e o nível sintático estejam especificados em dois arquivos diferentes. Em um nível mais abstrato, estes dois arquivos representam duas subcamadas do sistema: a análise no nível léxico (a classificação de cada termo ou expressão) e a análise sintática (aplicação de regras gramaticais aos termos da frase). 3.3.1. Nível Léxico. O nível léxico é a primeira subcamada da camada de sintagmas. Em uma gramática tradicional, cada token é representado pela própria palavra. No caso de linguagens de programação, o token “if” é o primeiro token de uma regra que formará uma expressão condicional “if...then...else”, e só poderá constar nas regras que possuírem o token “if”. Na gramática de sintagmas, os tokens são agrupados por classificações. As regras são formadas por elementos classificadores, e um mesmo token pode ser representado por várias palavras. As palavras: casa, cachorro e flor são, na verdade, o token ‘substantivo’, que será usado nas regras de sintagmas nominais entre outras regras. Esse tipo de abordagem é chamada de etiquetagem ou POS tagging [Jurafsk e Martin 2000, Sant’Anna 2000]. Para que o nível sintático possa traduzir as regras de maneira adequada, cada palavra ou expressão deve estar devidamente classificada. Porém, como se trata de linguagem natural, ambigüidades podem ocorrer, uma mesma palavra ou expressão pode possuir várias classificações. O desafio do processo de etiquetagem reside exatamente na resolução dessas ambigüidades. Os algoritmos para etiquetagem fundamentam-se em dois modelos mais conhecidos: os baseados em regras [Jurafsk e Martin 2000] e os estocásticos [Jurafsk e Martin 2000]. Os algoritmos baseados em regras, como o nome o diz, fazem uso de bases de regras para identificar a categoria de um certo item léxico. Neste caso, novas regras vão sendo integradas à base à medida que novas situações de uso do item vão sendo encontradas. Os algoritmos baseados em métodos estocásticos costumam resolver as ambigüidades através de treinamento e aprendizagem, marcado corretamente (muitas vezes através de esforço manual), calculando a probabilidade que uma certa palavra ou item léxico terá de receber uma certa etiqueta em um certo contexto. O etiquetador de Brill (1995), bastante conhecido na literatura, faz uso de uma combinação desses dois modelos.

Nosso trabalho utiliza os dois métodos na classificação dos itens léxicos. Embora o conjunto de regras seja fixo, definido na gramática, novas regras podem ser mapeadas para as regras existentes através do pré-processamento, fazendo com que o conjunto de possibilidades de tradução seja bastante amplo. Semelhante ao conceito de processo estocástico, foi utilizado um sistema de pontuação, que atribui pontos de acordo com a classificação de cada palavra ou expressão, baseando-se na ordem em que os termos aparecem. 3.3.2. Nível Sintático. Nas fases anteriores de processamento, todas as palavras e expressões da regra de negócio foram substituídas por algum termo que tem um significado definido no domínio do problema. Cada um desses termos recebeu uma classificação léxica. Baseado em uma gramática, estabelecida para definir regras de combinações entre as classificações léxicas, será feita a análise sintática das regras de negócio. A gramática desenvolvida para este trabalho foi baseada nas gramáticas de constituinte imediato, onde seus constituintes são chamados de sintagmas. Cada constituinte é uma parte da sentença, que são classificadas em partes cada vez menores, até que cada palavra da frase (token) tenha uma classificação gramatical. Assim, os seguintes padrões de frases são aceitos pela gramática: • Expressão Singular: Formada por uma frase simples e pode ser uma comparação explícita (“o salário do funcionário é igual a 1000”) ou implícita (“o salário do funcionário é 1000”); • Expressões conjuntivas: expressões singulares separadas pelas conjunções ‘e’ ou ‘ou’. • Expressão Condicional: composta pela expressão “se então senão ”; • Expressão Explicativa: composta pela expressão “ onde ”. A segunda parte da expressão (a partir de substantivo) representa a computação do resultado de uma expressão aritmética em uma variável (o substantivo, sem significado no domínio). • Expressões adjetivas: representadas ou por um adjetivo ou por uma oração adjetiva (introduzida por um pronome relativo), ambos após um sintagma nominal; • Expressão aritmética: formada por operandos (sintagmas nominais e funções) separados por operadores; ou simplesmente formada por um sintagma nominal; • Expressão comparativa: “ ”; similar a uma expressão singular com uma comparação explícita; • Comparação: “ ”; • Sintagma nominal: “[ ou ]; • Sintagma preposicional: “ “; • Substantivo: valor de atributo, atributo, classe ou variável. • Numeral: valor de atributo; • Pronome pessoal: pode aparecer no lugar de algum sintagma nominal, referindo-se a outro já mencionado. • Pronome possessivo: posicionados antes de um substantivo, referindo-se a um sintagma nominal já mencionado; • Termo de Negação: o termo “não” deve aparecer antes de verbo. Como em toda gramática livre de contexto, essas classificações são hierárquicas, ou seja, uma expressão contém expressões menores dentro dela. Com essa gramática é possível captar um considerável conjunto de regras de diferentes tipos de negócios.

Porém, é necessário atentar para aspectos da linguagem natural que a diferencia das linguagens formais. Dois desses aspectos foram considerados nesse trabalho: supressão de termos (tipicamente elipses e zeugmas) e referências anafóricas. Além disso, é necessário padronizar o formato de cada parte da sentença para facilitar o processo de tradução. Assim, é corriqueira a supressão no texto de palavras ou expressões, que são identificáveis por terem sido citadas anteriormente no discurso, ou através de afixos de outras palavras do texto. Duas afirmações sobre um mesmo sujeito podem ser feitas, bastando apensas separas tais afirmações por uma conjunção e escrevendo o sujeito apenas uma vez, na primeira oração. Segundo Renkema (1993), anáfora é uma referência a um termo empregado anteriormente no discurso. Uma anáfora envolve um antecedente e um termo anafórico. Termo anafórico e antecedente são co-referentes. Ao processo de determinação do antecedente de um termo anafórico denominamos resolução ou cálculo. No caso de referências de uma parte do discurso a outra, tem-se geralmente duas etapas: (i) identificação de um termo ou expressão que se refere a outro; (ii) localização do termo (ou expressão) a que o primeiro se refere. A gramática formulada para este projeto se propõe aceitar algumas expressões com termos suprimidos e reconhecer os pronomes. Tanto os termos suprimidos quanto o antecedente da anáfora devem ter sido explicitamente citados anteriormente na regra de negócio. Em um processamento adicional a analise sintática, o sistema “preenche as lacunas” dos termos suprimidos e substitui os pronomes pelos termos a que eles se referem (seus antecedentes). Em expressões conjuntivas, a partir da segunda expressão singular, pode-se suprimir a parte inicial da mesma, até o verbo ou até a comparação. Neste caso, o sistema assumirá que todos os termos suprimidos podem ser copiados da expressão anterior, que deve ser uma expressão comparativa completa. Após a cópia desses termos suprimidos, essa expressão se tornará completa e poderá servir de base para a cópia da próxima expressão, que eventualmente pode ter também termos suprimidos. A resolução anafórica se baseia no contexto imediato (termos próximos) e também pode usar o contexto geral (domínio) para “desempatar” a escolha de candidatos. Para cada termo anafórico encontrado, o sistema faz uma busca por sintagmas nominais ou preposicionais antecedentes a este termo. No caso de mais de um encontrado, verifica-se no modelo do domínio (através do dicionário de dados) qual antecedente possui relacionamento com o termo anafórico. Também é feita uma verificação para saber se há relação no domínio entre o termo anafórico e o antecedente (atributos de classes, ou relacionamentos, por exemplo). A resolução anafórica só será efetivada se houver relação entre os termos. Por outro lado, se for encontrado mais de um termo relacionado, temos uma ambigüidade que deve ser resolvida com uma pergunta ao usuário. 3.4. Tradutor para OCL Antes de iniciar a efetiva tradução para OCL, a sentença precisa estar formatada para um padrão entendido pelo tradutor. Na etapa de resolução anafórica e determinação de termos suprimidos, parte dessa formatação foi efetuada. Nesse padrão, cada expressão da frase precisa estar no formato de uma expressão comparativa. Sendo assim,

comparações implícitas de expressões singulares precisam ser explicitadas. Existem dois casos de explicitação de comparações. O primeiro é quando o lado direito da comparação representa o valor de um atributo e o segundo caso é quando ele representa um atributo do tipo boolean. O sistema verifica se este termo é um atributo do sintagma que compõe o outro lado da comparação. Se for, ele é considerado um atributo do tipo boolean. Senão, o termo é considerado valor de um atributo, que é o sintagma que está sendo comparado. Por exemplo, temos a comparação com um valor: “O status do funcionário é sênior” – se “sênior” não for um atributo de “status do funcionário”, a sentença se torna “o status do funcionário é igual a sênior”. Já no caso em que “sênior” é um atributo de “funcionário”, a sentença se torna: “o (atributo) sênior de funcionário é igual a true”. As expressões adjetivas já tiveram seus pronomes relativos substituídos por seus antecedentes na etapa de resolução anafórica. Essas expressões representam condições para um determinado sintagma nominal antecedente. Assim, elas devem ser reposicionadas na sentença para formarem uma expressão condicional. Por exemplo, “O salário do funcionário sênior é maior que 1000” se torna “Se o (atributo) sênior de funcionário é igual a true então o salário do funcionário é maior que 1000.” Finalmente a tradução para OCL propriamente dita é feita, tendo como entrada a frase em português pré-formatada. Para essa etapa, foi construído um segundo parser, utilizando-se também a ferramenta TPLY. O tradutor reconhece e traduz os padrões: • Sintagmas nominais e preposicionais representam classes, atributos e relacionamentos entre eles, sendo então mapeados para os mesmos. • Substantivos (quando não são atributos, classes ou variáveis) e numerais são valores de atributos; • Comparações são substituídas por seus símbolos matemáticos; Chamaremos essa parte da expressão OCL de expressão singular traduzida (EST). De fato, uma expressão em OCL deve possuir no mínimo uma EST para ter um significado. • Nas expressões aritméticas, operadores e funções são substituídos por seus símbolos matemáticos ou pelo nome das funções definidas em OCL; • Nas expressões conjuntivas, as conjunções ‘e’ e ‘ou’ são substituídas por ‘AND’ e ‘OR’, respectivamente; Representaremos o conjunto de uma ou mais EST´s por [EST]+. • Expressões condicionais são transformadas em expressões no padrão: [“EST]+ implies [EST]+”, ou “If [EST]+ then [EST]+ else [EST]+”; • As expressões explicativas são transformadas em expressões no padrão: “Let variável = expressão aritmética in [expressão condicional ou [EST]+ ]”; • O usuário deve determinar o contexto inicial de onde será feita a navegação – ou seja, irá escolher uma classe para começar a especificar uma restrição.

4. Exemplo Completo de Tradução: Utilizaremos nessa seção um modelo de classes simples, onde existem as classes Funcionário e Empresa, e um relacionamento Funcionários entre Empresa e Funcionário, indicando os funcionários que trabalham em uma determina empresa. O exemplo seguira o seguinte modelo:

1. Sentença original; 2. Após pré-processamento; 3. Após análise léxica e sintática, representado em tabelas que mostrarão a classificação hierárquica das sub-expressões da regra; 4.Após completar termos suprimidos, resolver anáforas e reescrever expressões adjetivas; 5. Regra em OCL. 4.1. Exemplo: Empresa 1. A comissão total do funcionário deve ser menor que seu salário e maior que 100. 2. A comissao do funcionario deve ser menor que seu salario e maior que 100. 3. Classificação na Tabela 1 após a análise léxica e sintática. Tabela 1. Classificação das palavras e expressões. A comissão do funcionário deve ser menor que seu salário E maior que 100

DET SUBST PREP SUBST EXP_DEVE VERB NUCLCOMP PARTCOMP PRONPOSS SUBS CONJ NUCLCOMP PARTCOMP NUM

SN SP SN

SP EXPRESSÃO COMPARATIVA COMPARAÇÃO

COMPARAÇÃO

EXPRESSÃO CONJUNTIVA

4. A comissao do funcionario deve ser menor que o salario do funcionario e a comissao do funcionario deve ser maior que 100. 5. context Empresa inv: funcionario.comissao > 100

funcionario.comissao

<

funcionario.salario

AND

5. Conclusão Neste artigo apresentamos uma ferramenta de processamento de linguagem natural para a captura e documentação de restrições em um modelo de classes e objetos usando a linguagem OCL, o Hermes. A ferramenta está dentro de um sistema maior, o Atenas, que possui uma arquitetura que suporta a captura de restrições (e Regras de negócio) nas etapas iniciais da análise, e garante a independência entre regras de negócio e a aplicação conforme sugerido por diversos autores. O Hermes diminui o trabalho para codificar uma restrição na medida em que permite o uso de linguagem natural para estabelecê-la, e consegue produzir uma restrição em OCL equivalente. Após, a expressão em OCL é traduzida para uma consulta em SQL que pode ser utilizada para validar os dados, respondendo à pergunta “quantos registros violam esta regra”, ou ainda ser utilizada para gerar triggers nos eventos apropriados que verificam se alguma alteração nos dados está violando uma determinada restrição. Por ser um módulo independente do Atenas, pode ser utilizada também como uma interface mais amigável para validar dados ou minerar conhecimento em bases já existente. Devido ao fato da ferramenta ser capaz de entender um escopo bem reduzido

de sentenças, ou seja, apenas sentenças que especifiquem restrições sobre um modelo de classes e objetos, é possível ter um aproveitamento alto na interpretação do discurso em linguagem natural ao mesmo tempo em que a implementação da ferramenta é mantida relativamente simples.

6. Referências: Androutsopoulos, G. D. Ritchie, P. Thanisch (1995) “Natural Language Interfaces to Databases” An Introduction, Journal of Natural Language Engineering, vol.1, no.1, Cambridge University Press. Brill, E. (1995) “Transformation-based error-driven learning and natural language processing: a case study in part-of-speech tagging”. Computational Linguistics, 21(4), 543-566. Date,C. J. (2000) “What not How: The Business Rules Approach to Application Development”. Addison-Wesley longman Inc. Demuth, B. e Hussmann, H. (1999) “Using OCL Constraints for Relational Database Design”. UML'99 2nd Intl. Conf. UML, Fort Collins, CO, USA. Demuth, B. Hussmann, H. and Loecher, S. (2001) “OCL as a specification language for business rules in database applications”. UML'01, 4th Intl. Conf UML, Toronto, Canada. Gazdar, G., Klein, E. Pullum, G. and SAG, I. (1985) “Generalized Phrase Structure Grammar”. Basil Blackwell. Graef, Albert. “TPLY: Turbo Pascal Lex/Yacc”. Free software available online at http://www.musikwissenschaft.uni-mainz.de/~ag/tply. Jurafsk, D., Martin, J. (2000) “Speech and Language Processing”. New Jersey, PrenticeHall. Object Management Group (1997) “Object Constraint Language Specification”. Object Management Group (1997) “UML 1.1 Specification”, OMG documents ad970802–ad0809. Renkema, Jan. (1993) “Discourse studies: an introductory textbook”. Amsterdam: John Benjamins. 224 p. Richters, Mark and Gogolla, Martin. (1998) “On formalizing the UML object constraint language OCL”. In Proc. of 17th Int. Conf. Conceptual Modeling (ER'98). LNCS vol. 1507. Ross, Ronald G. (1998) “Business Rule Concepts”. Business Rule Solutions Inc. Ross, Ronald G. (1997) “The Business Rule Book: Classifying, Defining and Modeling Rules”. Database Research Group, Boston, MA. Sant’Anna, Victor Martins. (2000) “Cálculo de Referências Anafóricas Pronominais Demonstrativas na Língua Portuguesa Escrita”. Porto Alegre. Vieira, Strube (2001) “Lingüística computacional: princípios e aplicações” von Halle, Barbara. (2001) “Building a Business Rule System, Part 1”. Data Management Review, Faulkner & Gray. Warmer, J. B. and Kleppe, A. G. (1999) “The object Constraint Language”. AddisonWesley. Zimbrão, G., et al. (2001) “ATENAS: Um Sistema Gerenciador de Regras de Negócio”, Publicado na Seção Técnica de Ferramentas do XV Simpósio Brasileiro de Engenharia de Software, Rio de Janeiro, Brasil. Zimbrão, G., et al. (2003) “Enforcement of Business Rules in Relational Databases Using Constraints”. SBBD 2003, Manaus: 129-141.