O documento descreve uma ferramenta chamada Hermes que traduz restrições de negócio expressas em português para a linguagem OCL de forma a verificar essas restrições em bancos de dados relacionais. O Hermes realiza pré-processamento e validação gramatical antes de gerar expressões OCL equivalentes que podem então ser traduzidas para SQL.

1. 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;2
DCC/UFRJ,
{varella,vinicios,vonheld,zimbrao}@cos.ufrj.br ,jcps@ufrj.br
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

2. [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).

3. 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.

4. 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.

5. 3. Hermes
A arquitetura do sistema Hermes é formada por três módulos, conforme podemos ver na
: (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.
Fig. 1
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

6. 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.

7. 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.

8. 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 <expressões conjuntivas> então
<expressões conjuntivas> senão <expressões conjuntivas>”;
• Expressão Explicativa: composta pela expressão “<expressões conjuntiva> onde
<substantivo> <comparação> <expressão aritmética>”. 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: “<expressão aritmética> <comparação> <expressão
aritmética>”; similar a uma expressão singular com uma comparação explícita;
• Comparação: “<verbo> <núcleo comparativo> <partícula comparativa>”;
• Sintagma nominal: “<substantivo>[<sintagma preposicional> ou <numeral>];
• Sintagma preposicional: “<preposição> <sintagma nominal>“;
• 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.

9. 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,

10. 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:

11. 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 DET
comissão SUBST
SN
do PREP
funcionário SUBST SN
SP
SP
deve EXP_DEVE
ser VERB
menor NUCLCOMP
que PARTCOMP
seu PRONPOSS
salário SUBS
COMPARAÇÃO
EXPRESSÃO
COMPARATIVA
E CONJ
maior NUCLCOMP
que PARTCOMP
100 NUM
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 < funcionario.salario AND
funcionario.comissao > 100
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

12. 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, Prentice-
Hall.
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”. Addison-
Wesley.
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.