UNIVERSIDADE CANDIDO MENDES

PÓS-GRADUAÇÃO LATO SENSU

INSTITUTO A VEZ DO MESTRE

Um Método de Consulta

às Permissões, Proibições e Obrigações

de uma Base de Regras de Negócios

Por: Célia Maria Seabra

Orientador

Prof. Marcelo Saldanha

Rio de Janeiro 2009

2

UNIVERSIDADE CANDIDO MENDES

PÓS-GRADUAÇÃO LATO SENSU

INSTITUTO A VEZ DO MESTRE

Um Método de Consulta às Permissões, Proibições e Obrigações

de uma Base de Regras de Negócios

Apresentação de monografia à Universidade

Candido Mendes como condição prévia para a

conclusão do Curso de Pós-Graduação Lato Sensu

em Gestão de Projetos

Por: Célia Maria Seabra

3

AGRADECIMENTOS

A Deus que me deu condições para

chegar ao fim de mais esta jornada. À

minha família e amigos que me

fortaleceram nos momentos difíceis desta

empreitada, e em particular às amigas

Christiane, Mônica e Suélen pelo apoio

mútuo durante o curso.

4

DEDICATÓRIA

Dedico este trabalho à minha mãe, meu

marido e meus filhos Vítor e Eduardo.

5

RESUMO

O mundo de negócios tem manifestado um crescente interesse em Regras de

Negócio(RNs). O modelo de um negócio representa conceitualmente o

ambiente onde um grupo de regras se aplica. O sucesso de uma empresa

depende da importância que se dá as Regras do Negócio da organização. As

RNs podem ser vistas como um controle de acesso do negócio, deixando claro

quais situações são permitidas, proibidas e obrigatórias para a sobrevivência

da empresa. Atualmente, as RNs são de difícil acesso aos homens de negócio,

sendo necessário para isso conhecimento de detalhes técnicos. O método de

consulta às permissões, proibições e obrigações de uma base de RNs não só

permite um maior controle da empresa por parte dos homens de negócio como

também permite a melhoria do desenvolvimento dos sistemas baseados na

base de RNs.

6

METODOLOGIA

A metodologia utilizada nesta monografia é o resultado de pesquisas

atualizadas em livros, artigos e internet e de minha vivência adquirida ao longo

da vida profissional na área de informática, onde convivi em segmentos

relacionados ao desenvolvimento e manutenção de sistemas de informação.

Os conceitos apresentados nesta monografia não esgotam o assunto,

mas, pelo contrário, abrem espaços para novas abordagens, questionamentos

e diferentes formas de abordar o tema relacionado com a regras de negócios.

7

SUMÁRIO

INTRODUÇÃO 08

CAPÍTULO 1 - Estratégias para Enunciado de Regras de Negócio 10 CAPÍTULO 2 - O Método de Consulta 24 CONCLUSÃO 33 ANEXO 35 REFERÊNCIAS BIBLIOGRÁFICAS 40 ÍNDICE 42

FOLHA DE AVALIAÇÃO 43

INTRODUÇÃO

No ambiente empresarial é comum encontrar regras referentes ao

comportamento dos negócios. Essas regras servem para que cada

organização tenha uma maneira padronizada de se comportar perante as

situações cotidianas relacionadas ao negócio que atuam. Tais regras são

conhecidas como Regras de Negócio (RNs). A capacidade de especificar os

requisitos do negócio de forma correta, completa e não ambígua é fundamental

ao sucesso de projetos dos sistemas de software. O objetivo deste trabalho é

apresentar um método de consulta às RNs que possa ser utilizado sem o

auxílio de especialistas e onde as RNs possam ser diretamente executadas.

Não é raro encontrar situações onde um sistema de informação, embora

tecnicamente correto, não satisfaz às necessidades reais do negócio. As

operações nas organizações, podem ser facilitadas com uma clara descrição

dos negócios envolvidos. As RNs são encontradas principalmente no código-

fonte dos sistemas e no interior dos bancos de dados e não há garantia de que

a especificação esteja idêntica ao que foi codificado. O acesso às RNs só é

possível através do conhecimento técnico. O método de consulta proposto

neste trabalho permite o acesso dos homens de negócio às RNs através de

uma solução computacional que envolve a automatização direta das RNs. As

iniciativas dos autores existentes nesta área enfatizam o armazenamento de

regras em um formato textual através de modelos de sentenças mas sem

possibilidade de manuseio computacional da semântica dessas sentenças. O

texto deste trabalho encontra-se estruturado da seguinte forma: além desta

8

9

introdução, no segundo capítulo conceituamos e categorizamos RNs; no

terceito capítulo apresentamos o modelo proposto para o método de consulta

às permissões, proibições e obrigações e no quarto capítulo tecemos as

considerações finais e indicamos futuros trabalhos.

10

CAPÍTULO I

Estratégias para Enunciado de Regras de Negócio

A capacidade de especificar os requisitos do negócio de forma correta,

completa e não ambígua é fundamental ao sucesso de projetos dos sistemas

de software. Não é raro encontrar situações onde um sistema de informação,

embora tecnicamente correto, não satisfaz às necessidades reais do negócio.

Operações nas organizações, tais como fusões, franquias, etc, podem ser

facilitadas com uma clara descrição dos negócios envolvidos. Pode-se dizer

que o modelo do negócio representa conceitualmente o “mundo” onde um

conjunto de RNs se aplica. As RNs devem ser compreendidas por todos os que

convivem dentro desse “mundo”. Assim, o enunciado das RNs torna-se em um

tópico importante tanto para os homens de negócio quanto para os

especialistas em tecnologia de informação.

Regras de Negócio são usualmente definidas sob duas perspectivas: a

do negócio e a dos sistemas de informação.

A perspectiva do negócio aborda o fator humano existente no sistema,

encarando cada regra como uma diretiva com o objetivo de influenciar ou

guiar o comportamento do negócio, apoiando as políticas formuladas em

função das oportunidades e ameaças do ambiente no qual a organização

está inserida [21].

Na perspectiva dos sistemas de informação, “Regras de Negócio são

declarações que definem algum aspecto da estrutura do negócio controlando

11

algum comportamento, representando o conhecimento dos especialistas do

negócio [21]”.

Ainda hoje, encontram-se RNs, na maioria de casos, no código de programas

de sistemas da informação, o que acarreta em dificuldades para compreender,

modelar e atualizá-las. Algumas empresas mantêm suas RNs em um

repositório, mas tal fato não garante que as regras implementadas sejam iguais

às regras documentadas. Idealmente, as regras de negócio deveriam ser

expressas em um formato de fácil leitura e compreensão.

A discussão sobre o enunciado de BRs concentrou-se inicialmente na

escolha de um paradigma e do melhor modelo desse paradigma. Os

esquemas de enunciado das BRs decorrem da escolha de paradigma. De

acordo com essa linha do pensamento, nove alternativas de representação

gráfica do conhecimento foram examinadas como candidatas a metodologia

para a expressão das BRs em [31]. Entretanto, os homens de negócio não

estão familiarizados com o paradigma da representação gráfica para a

descrição de restrições, permissões, obrigações, proibições e outros aspectos

de BRs. Esta seção discute as estratégias baseadas em uma definição textual

para as regras. A seguir serão examinadas as estratégias para enunciado de

BRs dos pontos de vista da legibilidade das regras produzidas e da facilidade

de sua conversão em uma plataforma automatizada. As estratégias são

apresentadas em ordem decrescente de habilidade técnica requerida para

enunciar e compreender as regras.

12

1.1. Linguagem Formal de Propósito Geral

O termo “What Not How” cunhado por C. J. Date [33] enfatiza a natureza

declarativa das RNs e tem servido de base para o seu enunciado. Uma forma

de interpretar esse lema é enunciando RNs em uma linguagem declarativa

visando sua aplicação uma ferramenta de linguagem de propósito geral.

Considera-se para este trabalho as duas linguagens formais mais citadas que

têm sido usadas para implementação de sistemas de RNs: OCL e PROLOG [9]

Object Constraint Language (OCL) consiste em uma linguagem formal

de especificação projetada como uma extensão da Unified Modeling Language

(UML) [6]. A finalidade da OCL é especificar expressões e sua semântica não

contempla a representação de fluxos de controle. OCL lida com objetos e

classes, sendo a restrição seu construto básico. Uma restrição em OCL pode

incluir pré-condições e pós-condições, que definem regras de produção. Os

quantificadores universal e existencial e o operador lógico de implicação da

Lógica de Primeira Ordem (LPO) são transformados em operações. As

operações sobre conjuntos também são permitidas. Estas características

permitem a representação de RNs em OCL. Entretanto, deve-se ressaltar que

a ferramenta OCL não possui uma linguagem, embora alguns tradutores

estejam disponíveis, principalmente em Java [38]. Sendo assim, a

representação e a verificação das regras requer a construção de uma

ferramenta própria.

Baseada no subconjunto da lógica primeira ordem composto pelas

cláusulas de Horn, PROLOG é uma linguagem declarativa e não-proprietária

[14]. PROLOG beneficia-se da expressividade bem definida da LPO,

13

constituindo um instrumento poderoso para a representação do conhecimento.

O fato do motor de inferência do PROLOG ter um comportamento padrão

possibilitou a incorporação de primitivas de controle à linguagem. Estas

características permitiram o mapeamento de raciocínios de segunda ordem

nos programas PROLOG [35, 36]. Os mapeamentos incluem lógica deôntica,

default e temporal e os estudos sobre escopo e complexidade computacional,

enriquecendo ainda mais a expressividade do PROLOG.

Ainda que OCL e PROLOG tenham construtos apropriados para o

enunciado de RNs, a ajuda de um especialista nestas linguagens é essencial.

Isso não significa que as linguagens não possam ser usadas para

representação interna de RNs (note que o OCL pode agir apenas como uma

linguagem intermediária, enquanto PROLOG pode ser cogitado como uma

opção para implementação). Atualmente, os dois paradigmas aparecem como

linguagem de representação interna nas propostas do Business Semantics of

Business Rules (BSBR) sob a apreciação da OMG [45].

1.2. Linguagem de Marcação de Propósito Específico

Se as linguagens formais de propósito geral apresentam dificuldades

técnicas para os homens de negócio enunciarem RNs, uma alternativa pode

ser projetar uma linguagem especialmente com essa finalidade. A maioria, se

não todos, os esforços neste sentido vêem as RNs como metadados [10],

propondo linguagens de marcação. Estas linguagens utilizam a sintaxe da

Extended Markup Language (XML) [4] para definir a semântica das RNs. XML

[39] consiste em uma linguagem relativamente simples que fornece um

mecanismo textual, tags de marcação, para a descrição da semântica dos

14

dados. Existem dois tipos de documentos XML: XML schemata e XML

instances. XML schema define um conjunto de instâncias aceitáveis dos

documentos. Tendo uma estrutura similar às das árvores de parsing usadas na

análise gramatical das linguagens formais, a estrutura em árvore de um

documento XML fornece um mecanismo apropriado para a descrição de RNs.

A semântica da linguagem é definida no XML schema correspondente através

da especificação de elementos e atributos das tags.

RuleML e BRML são as linguagens de marcação mais conhecidas para

enunciado de RNs [15, 43]. RuleML consiste de um produto do The Rule

Markup Initiative que visa padronizar a expressão de RNs em XML. Regras de

Negócio expressas no software IBM CommonRules (BRML) tem uma biblioteca

de componentes Java para apoiar o desenvolvimento de RNs na web. A

adoção de XML como o padrão da comunicação de dados de diversas

plataformas torna apropriada a expressão de RNs com linguagens de

marcação, para compartilhamento de informações na Internet. Assim, estas

linguagens podem ser usadas representar RNs de forma declarativa em

aplicações heterogêneas. Não obstante, a expressão de RNs com linguagem

de marcação ainda requer o auxílio técnico.

1.3. Linguagem Pseudo-Natural

As linguagens mencionadas nas seções anteriores possuem uma

desvantagem em comum: só os especialistas sabem usar. Entretanto, pode-

se aproveitar as vantagens de se ter uma das linguagens analisadas na seção

2.1 como representação interna, e o benefício das linguagens baseadas em um

padrão de comunicação na web (veja a seção 2.2). Uma solução que alia as

15

vantagens e desvantagens mencionadas até o momento seria um subconjunto

"bem-comportado" da linguagem natural para enunciado das RNs, uma

linguagem pseudo-natural.

A impressão de se usar a linguagem natural é conseguida através de um

conjunto de modelos de sentenças, chamado templates. Estes templates são

projetados de modo que capturem a expressividade necessária inerente à

tarefa de enunciar RNs ao mesmo tempo que mantêm a semântica bem

delimitada. O controle sobre o significado de uma sentença gerada a partir de

um template permite sua tradução para uma representação interna. A

validação automatizada da regra traduzida dependerá unicamente da

capacidade de execução da linguagem de representação interna.

Três sistemas de informação (RÉGULA [1, 16], RuleSpeak [7, 8] e o

mapeamento de Martha [38]), assim como as recomendações no livro de Tony

Morgan [25], que sugerem ou usam templates para o enunciado de RNs estão

detalhados na seção 1.6. Uma questão ainda a discutir refere-se à

possibilidade do uso de linguagem natural pura para o enunciado de RNs. Este

é o assunto da próxima seção.

1.4. Linguagem Natural

À primeira vista, pode-se pensar na linguagem natural como a forma

mais direta de se expressar RNs. Entretanto, apesar de sua óbvia

expressividade, muitos problemas podem surgir de seu uso. A grande

quantidade de trabalhos em Processamento de Linguagem Natural, um ramo

da Inteligência Artificial, demonstra as dificuldades de entender e processar

16

informação representada desta forma [36]. A ambigüidade, por exemplo, pode

aparecer decorrente de diversos de fatores [40, 42].

Considere a sentença: “um modelo de carro pode ser solicitado por um

cliente em uma locadora de carros em uma certa data”. O senso comum nos

diz que o objeto solicitado não é o modelo do carro, mas uma instância de um

veículo do modelo especificado. A data referida na sentença parece ser a data

em que o pedido foi feito. Embora isto seja uma informação útil, uma parte

essencial dos dados seria a data em que o carro deve estar disponível para o

cliente na loja. Uma versão mais razoável do exemplo acima seria a seguinte:

um (instância de) carro de um determinado modelo (especificado) pode ser

solicitado em uma determinada data (data1) por um cliente para estar

disponível em uma locadora de carros em uma determinada data (data2).

Estudos em raciocínio do senso comum enfatizam a enorme

complexidade computacional envolvida em seu processamento automatizado

[37]. Dessa forma, defendemos o uso da linguagem pseudo-natural discutido

na seção 1.3 para o enunciado de RNs por consideramos ter a melhor relação

custo/benefício entre a legibilidade e computabilidade controlada.

1.5. Categorização de Regras de Negócio

Esta seção discute os respectivos esquemas do categorização já que

também têm um papel importante no enunciado das RNs.

1.5.1 Categorias do Business Rules Group

The Business Rule Group (BRG) propõe um esquema do categorização

[3] para RNs que vê as regras em parte por uma perspectiva atômica e em

17

parte por uma perspectiva processualista. O foco de algumas categorias está

nas coisas enquanto outras categorias focam em processos. As categorias de

RNs do BRG são: Termos, Fatos, Restrições e Derivações. As Habilitadoras

de Ação são mencionadas na versão original de categorização e serão

consideradas neste texto por serem utilizadas nos trabalhos discutidos na

seção 1.6.

Os termos são definidos como os elementos mais básicos das RNs.

Constituem o dicionário do negócio, sendo relacionados pelos fatos e por

outros tipos de regras. Não há um padrão para a especificação dos termos até

o momento. As Restrições se aplicam aos aspectos dinâmicos do negócio,

restringindo o comportamento da organização, pela especificação do que pode,

deve, não pode e não deve ser feito. As Derivações geram informação nova

através de computação aritmética ou de inferência lógica. A última classe de

RNs do BRG, habilitadoras de ação, contempla a geração de eventos com

regras da forma condição-ação da mesma forma que as regras de produção

[36], encontradas em muitos sistemas especialistas.

1.5.2 Categorias do RuleSpeak/Ruletrack

O esquema de categorização examinado nesta seção deriva de um

sistema de informação produzido pela BR Solutions[7], embora com uma visão

processual das regras. Três macro categorias são oferecidas para RNs:

Rejectors, Producers e Projectors. Rejectors impedem a ocorrência dos

eventos ou de situações que são indesejáveis ao negócio. Producers visam

regras com computação ou inferência. As sub-categorias de Producers são:

Computations e Derivations.

18

Ao regras Projectors criam eventos disparando ações automaticamente.

As Regras de Negócio desta categoria são subdivididas em: Enablers,

Copiers e Executives. Uma regra do tipo enabler tem um dos três efeitos: i)

cria ou apaga instâncias dos dados, ii) ativa ou desativa outras RNs, ou iii)

permite ou proíbe a execução de uma operação ou de um processo. Regras

do tipo Copiers atribuem um valor a um determinado dado, por exemplo um

desconto depois de feriados no preço do aluguel de carros. Por último, regras

Executive determinam as condições sob a qual uma BR deve ser acionada ou

um processo ser executado.

Embora o esquema do categorização de RuleSpeak/RuleTrack não

mencione termos e reagrupe algumas das categorias do BRG original, não

difere significativamente da classificação do BRG. Entretanto uma ênfase

muito mais forte é colocada na visão das RNs como reguladoras da dinâmica

do negócio.

1.5.3 Categorias de Morgan

Em seu livro, Tony Morgan [25] propõe que RNs sejam classificadas

como: Basic Constraints, List Constraints, Classification Rules, Computation

Rules and Enumeration Rules. Esta categorização parece ter sido projetada

sob a perspectiva dos bancos de dados. As Basic Constraints e as List

Constraints restringem o negócio estabelecendo que situações são permitidas,

proibidas, desejáveis ou indesejáveis. Classification Rules determinam

classificações provisórias para os termos no modelo dos fatos. É recomendado

que as classificações permanentes estejam refletidas diretamente no modelo

dos fatos. Computation Rules estabelecem relacionamentos entre termos e

19

modelos de fatos a fim permitir o cálculo de valores. Uma Enumeration Rule

determina o escopo ou o conjunto dos valores para um termo no modelo de

fatos.

1.5.4 Categorização de Weiden

Marcel Weiden [23] propõe categorias de RNs sob o ponto de vista do

negócio. Baseado nos modelos do contexto da metodologia CommonKADS

[19], divide regras em três macro-categorias: Regras Estruturais, Regras

Comportamentais e Regras Gerenciais. Os modelos descrevem visões

complementares de um processo de negócio sem compromisso com uma

plataforma específica de implementação.

A proposta de categorias de Weiden não possui um conjunto dos

templates. Entretanto, os exemplos dados pelo autor colocam a maioria das

regras como restrições, a maior parte na forma de regras de permissões e

obrigações. Vale a pena mencionar que o uso da palavra can parece ter sido

mal empregado pois denota possibilidade em vez da permissão, que parece

ser caso pretendido.

1.6. Templates de Regras de Negócio Sem o auxílio de um especialista, as linguagens formais ou

especializadas mencionadas nas seções 1.1 e 1.2 não podem ser usadas para

a especificação de RNs. Por outro lado, a linguagem natural é muito difícil de

processar, além de ser propícia à interpretação ambígua. Uma solução de

compromisso para o enunciado de RNs que visa conciliar vantagens enquanto

minimiza os inconvenientes destas estratégias consiste de um subconjunto

"bem-comportado" da linguagem natural, uma linguagem pseudo-natural. A

20

idéia é dar ao usuário a impressão de utilizar a linguagem natural através de

um conjunto de sentenças pre-formatadas, chamadas templates, que capturam

a expressividade que os usuários necessitam mas possuem semântica bem

definidas. Controlando o significado de uma BR gerada por um template

possibilita-se que a sentença seja passível de tradução para uma

representação interna.

Esta seção discute três sistemas (RÉGULA [1, 16], RuleSpeak [7, 8] e o

mapeamento de DeSouza [38]), além das recomendações do livro de Tony

Morgan [25] que sugerem templates para o enunciado de RNs. Por questões

de clareza, o detalhamento dos modelos dos templates está descrito no anexo

deste trabalho.

1.6.1 RÉGULA e o mapeamento de De Souza

Ambos os sistemas mencionados nesta seção usaram a versão anterior

de categorias das regras do BRG como a base de seu trabalho. Eles

compartilham do mesmo conjunto de templates, descrito em [1], que também

baseados nas recomendações do BRG.

RÉGULA [1, 16, 44], inicialmente conhecido como RuleCheck, consiste

em um sistema que fornece não apenas um ambiente para o enunciado de

RNs, mas também traduz em um arquivo PROLOG sua representação interna.

Desta forma as regras podem ser automaticamente integradas a outras partes

de informação bem como simuladas e verificadas contra a base de

conhecimento. O tradutor emprega predicados aritméticos e de primeira ordem

para comparar o valor de um termo com uma constante, para definir a estrutura

de uma fórmula em regras de computação, para definir o valor de um termo e

21

para executar uma ação. Os templates do RÉGULA servirão de base para o

método de consulta proposto no capítulo 3. O mapeamento de [De Souza] faz

uma tradução da regras para OCL. Esta metodologia foi aplicada para capturar

as RNs de uma companhia de petróleo brasileira.

1.6.2 RuleSpeak/Ruletrack

RuleSpeak [7] consiste em uma metodologia para disciplinar o

enunciado de RNs sugerindo um formato apropriado de sentenças. A

metodologia prega que cada regra deve pertencer a uma categoria funcional

que represente a forma como a regra deve reagir aos eventos. Tais categorias

são intrínsecas, permanentes e mutuamente exclusivas. O uso do must, can e

should bem como suas negações é recomendado também. O must é usado na

voz imperativa, preferível ao shall, significando obrigação de fazer. Should é

usado com o sentido de faça-se-possível. May é usado conceder ou negar

permissões. Além disso, recomenda-se que cada sentença inicie com um

assunto explícito, para garantir a clareza. O sistema RuleTrack 3,0 [8] consiste

de uma ferramenta de software para organizar e gerenciar RNs que foram

especificadas de acordo com os padrões da metodologia do RuleSpeak.

Embora haja menção à verificação de regras, não foi encontrada uma

implementação desta verificação até o momento.

Além da enfática recomendação para o uso de um tema explícito nas

sentenças, quase não há recomendações sobre as estruturas que devem

preencher os espaços em branco das palavras-chave que fazem parte dos

templates da metodologia de RuleSpeak.

22

1.6.3 Modelos de Sentença de Morgan

Tony Morgan [25] propõe um conjunto de templates cuja funcionalidade

é fortemente influenciada pela expressividade dos sistemas de bancos de

dados. Embora os termos não sejam mencionados na categorização de

Morgan, são definidos implicitamente no texto como as entidades de negócio,

que consistem nos objetos do negócio visíveis no modelo de fatos e de outros

elementos descritivos.

1.6.4 Comparação dos Conjuntos de Templates

As categorias do BRG e do RuleSpeak/RuleTrack possuem muitas

semelhanças apesar deste último não mencionar termos e fatos. As categorias

de Morgan não classificam fatos como RNs. Neste caso, os fatos devem ser

armazenados em um repositório separado, o que deixa os fatos genéricos sem

representação nas RNs. Os três conjuntos de templates, podem ser vistos

como variantes de uma idéia central. Cada conjunto de formatos das regras

foca mais atenção a um certo ponto, que pode ser percebido pelo nível do

detalhe dedicado ao aspecto em questão. RuleSpeak/RuleTrack enfatizam a

especificação de aspectos dinâmicos do negócio e os templates de Morgan

oferecem muitas facilidades para a especificação dos dados. A proposta do

BRG constitui a menos influenciada de todas. Como muitas das RNs têm uma

função normativa, as três propostas compartilham templates em comum

(categoria de restrições). As áreas de pesquisa que formalizam estes aspectos

são a lógica deôntica e o raciocínio normativo [18].

A possibilidade de tradução automática para uma representação interna

é mostrada no quadro 3. O sistema de RÉGULA ilustra a possibilidade de

23

traduzir RNs em uma linguagem executável: PROLOG. Além disso, a

tradução de RNs para um paradigma bem conhecido dota-as de uma

semântica bem-definida.

Existência de

tradução para

notação formal

ou semiformal

Não há.

Há,

PROLOG (REGULA) e

OCL (mapeamento de

De Souza).

Possibilidade de

tradução

mencionada.

Não há.

Quadro 3: Possibilidade de tradução de templates.

O enunciado e a representação de RNs foram examinados neste

capítulo, onde concluiu-se que uma linguagem formal propósito geral não é

necessária, uma vez ela pode ser usada como linguagem de representação

interna. As linguagens de marcação não impedem a necessidade de

assistência por um profissional de tecnologia de informação. Por outro lado, a

linguagem natural provou tender à ambigüidade e muito difícil de automatizar.

Assim sendo, o uso da linguagem pseudo-natural para o enunciado de RNs

torna-se a alternativa escolhida.

24

CAPÍTULO 2

O MÉTODO DE CONSULTA

Em qualquer organização, existem regras que definem o funcionamento

do negócio. As regras abrangem as políticas da empresa, seus interesses,

seus objetivos e seus compromissos [49]. Freqüentemente os únicos locais em

uma empresa onde se encontram Regras de Negócio são no interior dos

códigos-fonte dos sistemas de informação e dos bancos de dados. Além do

acesso a essas regras ser difícil, não há garantias de que estejam traduzidas

internamente de forma correta e completa. Apesar do crescente aumento de

pesquisas sobre RNs, ainda não existe um consenso sobre sua captura,

representação e manipulação. Em relação à manipulação, uma das questões

existentes diz respeito à consulta das regras na base de Regras de Negócio. O

objetivo deste capítulo é apresentar um método de consulta às permissões,

proibições e obrigações de uma base de regras. O método baseia-se no uso de

templates de consulta em linguagem pseudo-natural que são traduzidos para

uma representação interna que permita criar a ilusão de utilizar a linguagem

natural para fazer consultas a base de RNs. Com auxílio da hierarquia de

classes e das permissões, proibições e obrigações já catalogadas através do

sistema RÉGULA, o método permite tratar as RNs como um controle de acesso

ao negócio.

Mesmo sendo um tema em constante mudança, a proposta de

classificação de Regras de Negócio do BRG[3] é uma das mais utilizadas

atualmente. Suas categorias são representadas pelos tipos de regras: Termos,

25

Fatos, Derivações e Restrições. Os Termos são o elemento mais básico de

uma regra de negócio. Fatos representam as relações entre as entidades ou

entre estas e seus atributos. As Derivações determinam como um

conhecimento ou informação pode ser transformado em outro e finalmente,

Restrições, que restringem aspectos dinâmicos do negócio. Encontra-se em

andamento um estudo que proporá um padrão semântico de RNs do Object

Management Group [46]. O método de consulta apresentado neste capítulo

utiliza o conjunto de templates do sistema RÉGULA e parte do princípio que os

termos do negócio, a hierarquia de classes, as permissões, as proibições e as

obrigações já estão catalogados no mesmo sistema.

2.1 Representação Interna das Regras de Negócio

Expressar RNs requer meios de descrever o comportamento humano de

forma completa e correta. A dificuldade encontra-se na representação formal

das diversas situações que uma organização enfrenta diariamente. Atualmente

as RNs encontram-se, na maioria dos casos, no código-fonte dos sistemas e

nos bancos de dados. O mapeamento da RN para o código interno

automatizado não tem relação “um para um” de linhas de código, devido ao

limitado suporte das linguagens de programação e dos SGBDs para este fim.

Por outro lado, a Lógica de Primeira Ordem (LPO) se adequa à representação

da linguagem natural, uma vez que permite representar frases declarativas.

Além disso, possui a facilidade de representação de fatos e regras devido às

suas próprias características intrínsecas. Formalizar as RNs utilizando uma

linguagem declarativa permite que se identifique inconsistências lógicas na

base de conhecimento. O uso da LPO para expressar regras tem como

26

vantagem adicional o fato de existirem linguagens de programação baseadas

em lógica, como o Prolog.

2.2 Templates de Consulta

Em linguagem natural uma sentença de permissão sugere que há

possibilidade de determinada situação ou ação acontecer, mas não há a

obrigatoriedade. Uma obrigação é uma ação que deve acontecer no futuro,

embora não seja possível garantir que esta ação aconteça sempre.

Analogamente, a proibição é a obrigação de que algo não aconteça. [16]

propôs uma linguagem formal através da LPO para representação de RNs.

Entretanto não é possível representar nem manipular sentenças que

expressem permissões, proibições ou obrigações usando a sintaxe e a

semântica da LPO. Com o objetivo de facilitar a captura das RNs e a posterior

consulta, foram propostos templates para captura de RN que mapeiam as

permissões, as proibições e as obrigações. Os templates de captura (13) e (14)

descritos abaixo mapeiam as permissões. é um operador de

comparação (ex: maior, menor, igual, etc) e indica quantidade.

TEM PERMISSÃO PARA (13) TEM PERMISSÃO PARA 1 (14)

Os templates de captura (15),(16) e (17) mapeiam as obrigações.

indica uma preposição qualquer, indica um deteminante (um, uma, o, a,

cada, todo), é um operador de comparação (ex: maior, menor, igual,

etc) e indica quantidade.

DEVE OBRIGATORIAMENTE {} {} (15) DEVE OBRIGATORIAMENTE (16)

1 Este template não será objeto de estudo neste trabalho.

27

DEVE OBRIGATORIAMENTE SER (17)

Os templates de captura (18) e (19) mapeiam as proibições nas RNs.

NÃO TEM PERMISSÃO PARA {} {} (18) NÃO TEM PERMISSÃO PARA (19)

2.3 Consulta às Permissões, Proibições e Obrigações

Internamente o controle de acesso a uma sistema de informação se

traduz em uma lista de permissões baseada nos privilégios dados ao grupo a

qual a conta pertence. No caso das RNs, um mecanismo de controle de acesso

às permissões, obrigações e proibições pode ser estabelecido a partir de

consultas à base de RNs, autorizando ou não certas ações por parte do

analista de negócios.

Consulta/ Resposta

Visão do Negócio em Linguagem

Natural

Analista de Negócio

Representação Interna do Negócio

Módulo de Consulta

I A N M T I E G R Á F V A E C L E

Figura 1. Baseado em fragmento da figura 1-2 de [25]

Homens de negócio não são familiarizados com modelos gráficos para

descrição de permissões, obrigações e proibições. Com as RNs armazenadas

no código-fonte, pode-se consultá-las apenas com o auxílio de um especialista.

Porém, se as consultas forem feitas em um formato o mais próximo da

linguagem natural possível, permitirá o acesso às permissões, proibições e

obrigações do contexto da organização. Na Figura 1, uma pergunta em

português estruturado é digitada. Em seguida, a pergunta é mapeada para a

sua representação interna em PROLOG. A questão é processada com base

28

nas permissões catalogadas através dos templates (13) e (14), e o resultado

obtido é traduzido de volta ao analista de negócio no formato textual padrão.

A pergunta do usuário deve ser feita segundo um dos templates de

consulta expressos a seguir por (20) a (24), onde FAZER indica que a consulta

irá retornar, em caso de sucesso, um verbo ou expressão verbal. Similarmente,

QUEM e O QUE resultarão, em caso de sucesso, um (ou mais) termo(s)

catalogado(s). Os padrões de resposta para a consulta da expressão (13)

possuem formato expresso por (25) e (26).

TEM PERMISSÃO PARA ? (20) QUEM TEM PERMISSÃO PARA ? (21)

TEM PERMISSÃO PARA O QUE? (22)

TEM PERMISSÃO PARA FAZER O QUE? (23)

QUEM TEM PERMISSÃO PARA FAZER O QUE? (24)

RESP: INFELIZMENTE NÃO. (25)

RESP: TEM PERMISSÃO PARA PELA REGRA (26)

Os termos do negócio constituem elementos básicos para

expressão das RNs. Atualmente estão sendo referenciados por [45] como

vocabulário do negócio. Para poder avaliar os subtipos de um termo que se

enquadram em um mesmo tipo de regra de permissão é definida uma

hierarquia de classes. Esta hierarquia é representada por uma associação “é

um subtipo de” entre dois termos do vocabulário. Sua representação interna é

expressa por (27) e a representação interna da permissão é expressa por (28).

elemento(X, termo) :- elemento(X, sub-termo). (27)

permissao(termo1, termo2, verbo, id_regra). (28)

Cada consulta fornece, além da resposta, o número da RN que identifica

a permissão em questão (se ela existir). Caso a implementação deste módulo

29

fosse realizada por um banco de dados relacional comercial, a representação

da herança de permissões pela hierarquia de classes de termos só seria

possível através da catalogação de pares não genéricos de nós pai-filho. O

mecanismo de inferência do Prolog representa naturalmente essa hierarquia de

classes. No método de consulta a inferência é feita sobre as classes dos

termos e não sobre suas instâncias.

2.4 Exemplo de Aplicação do Método

A experimentação do método será realizada futuramente através de um

estudo de caso com o Regulamento Interno do Mestrado do NCE. Para ilustrar

o funcionamento da consulta serão utilizados exemplos de um trancamento de

disciplina simplificado, de um trancamento de matrícula, de uma defesa de

tese. Considera-se que existam subtipos de “aluno”, dentre eles os subtipos

“aluno_graduação” e “aluno_mestrado”. Os alunos têm permissão para solicitar

o trancamento de disciplinas e de matrícula. Os alunos de mestrado têm as

mesmas permissões de aluno_graduação e ainda têm permissão para

defender tese. Por questão de simplifcação, considera-se que os termos já

estão capturados e que as permissões estão catalogadas na base de regras.

Os exemplos a serem apresentados a seguir referem-se unicamente ao

template de permissão expresso por (13). A representação interna dos

exemplos será a seguinte:

elemento(X, aluno) :- elemento(X, aluno_graduacao).

elemento(X, aluno) :- elemento(X, aluno_mestrado).

permissao(aluno, trancamento_de_disciplina, solicitar, r1).

permissao(aluno, trancamento_de_matrícula, solicitar, r2).

permissao(aluno, tese, defender, r3).

30

Seja uma consulta para verificar se aluno de mestrado tem

permissão para solicitar trancamento de disciplina. A hierarquia de classes

possibilita avaliar que os subtipos de “aluno” se enquadram nas permissões

referentes a “aluno”, em especial “aluno_mestrado” herda a permissão

concedida a “aluno” para “solicitar” “trancamento de disciplina”. A expressão

(34) mostra a consulta, que utiliza o template (20), referente à expressão (13),

cuja resposta é dada por (35).

aluno_mestrado tem permissão para solicitar trancamento_de_disciplina? RESP: ALUNO_MESTRADO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1. 35)

O exemplo da consulta (36) verifica quem tem permissão para

solicitar trancamento_de_disciplina. No processamento da consulta serão

checados todos os elementos que possuem permissão catalogada para

solicitar trancamento_de_disciplina. A consulta utiliza o template (21), referente

à expressão (13), cuja resposta é dada por (37).

quem tem permissão para solicitar trancamento_de_disciplina? RESP: ALUNO_MESTRADO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1.

ALUNO_GRADUAÇÃO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1.

37)

A consulta (38) verifica o que um aluno de mestrado tem

permissão para solicitar. “Aluno_mestrado” herda as permissões concedidas a

“aluno” para “solicitar” algo. A consulta utiliza o template (22), referente à

expressão (13), cuja resposta é dada por (39).

Aluno_mestrado tem permissão para solicitar o_que? RESP: ALUNO_MESTRADO TEM PERMISSÃO PARA SOLICITAR

31

TRANCAMENTO_DE_MATRÍCULA PELA REGRA r2,

ALUNO_MESTRADO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1.

39)

Na consulta (40) verificam-se quais as permissões de um aluno

de mestrado. Serão checadas todas as permissões catalogadas na base de

regras herdadas de aluno. A consulta utiliza o template (23), referente à

expressão (13), cuja resposta é dada por (41).

Aluno_mestrado tem permissão para fazer o_que? RESP: ALUNO_MESTRADO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_MATRÍCULA PELA REGRA r2, ALUNO_MESTRADO TEM

PERMISSÃO PARA SOLICITAR TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1,

ALUNO_MESTRADO TEM PERMISSÃO PARA DEFENDER TESE PELA REGRA r3.

41)

Finalmente, a consulta (42) é a mais genérica. Serão verificadas

todas as permissões catalogadas na base de regras. A consulta utiliza o

template (24), referente à expressão (13), cuja resposta é dada por (43).

quem tem permissão para fazer o_que? RESP: ALUNO TEM PERMISSÃO PARA SOLICITAR

TRANCAMENTO_DE_MATRÍCULA PELA REGRA r2, ALUNO TEM PERMISSÃO PARA

SOLICITAR TRANCAMENTO_DE_DISCIPLINA PELA REGRA r1, ALUNO TEM

PERMISSÃO PARA DEFENDER TESE PELA REGRA r3.

43)

Este capítulo apresentou uma técnica de consulta às permissões a uma

base de regras que tem como característica básica extrair da base de RNs as

regras catalogadas simulando para o usuário uma linguagem próxima da

natural. O método é composto por três partes: uma lista de permissões,

proibições e obrigações; a representação da hierarquia de classes de termos

do negócio e um programa em linguagem Prolog. O uso deste método

32

representa um avanço no sentido de tornar o conhecimento do negócio preciso

através do acesso às RNs.

33

CONCLUSÃO

Este trabalho apresentou um método de consulta às permissões,

proibições e obrigações de uma base de Regras de Negócio. Freqüentemente

encontra-se sistemas de informação que embora funcionem não correspondem

à especificação do usuário. As RNs são encontradas principalmente no código-

fonte dos sistemas e no interior dos bancos de dados. Um outro aspecto é que

não há garantia de que a especificação esteja identica ao que foi codificado. A

consulta às RNs neste ambiente por parte dos homens de negócio só é

possível com a ajuda de especialistas.

O que se espera é que homens de negócio possam ter acesso às RNs

em uma linguagem que entendam e que as RNs estejam representadas

internamente em uma linguagem diretamente executável. Com o método de

consulta é possível acessar as RNs através de uma linguagem bem próxima da

linguagem natural (linguagem pseudo-natural) na forma de templates de

consulta. A representação interna em Prolog se adequa bem à expressão das

RNs por ser baseada na LPO e por representar frases declarativas.

Os estudos preliminares sugerem a ausência de referências

bibliográficas a sistemas que permitam a consulta automatizada a permissões,

proibições e obrigações. Trabalhos correlatos deverão ser divulgados após a

conclusão da apreciação da OMG sobre propostas para a definição semântica

de RNs [46].

Como contribuições podemos citar, além do controle preciso da empresa

por parte dos homens de negócio, a diminuição dos recursos usados no

desenvolvimento de sistemas que utilizem a base de RNs da empresa, bem

34

como, a diminuição dos episódios de manutenção devido à especificações mal-

definidas ou mal-interpretadas. Embora sempre haja chance de ocorrerem

equívocos na representação do conhecimento, um risco que qualquer

modelagem também corre, a eliminação de passos intermediários certamente

minimizará erros.

O uso da linguagem pseudo-natural nos templates de consulta acarreta

uma expressividade limitada na formulação de perguntas à base de Regras de

Negócio. A extensão desta expressividade dependerá da evolução do método

em versões futuras.

Dentre os tópicos de pesquisa futuros estão a verificação parcial de

consistência das RNs, especialmente entre permissões, obrigações e

proibições. A simulação de RNs integrada com os processos do negócio, a

construção de um assistente de definição de termos e o estudo das vantagens

e desvantagens de adotar categorias de Weiden são tema das pesquisas em

andamento.

35

ANEXO

Neste anexo encontra-se o detalhamento dos templates dos três

sistemas (RÉGULA [1, 16], RuleSpeak [7, 8] e o mapeamento de DeSouza

[38]), e do livro de Tony Morgan [25]. A fim organizar e resumir a apresentação

dos templates, algumas convenções usadas no resto deste anexo são

apresentadas no quadro 2.

Quadro 2. Convenções de Templates de regras [25].

Elemento Definição

descreve um determinante para o tema da regra. Pode ser uma artigo (o(s), a(s), um(uns), uma(s)) ou um quantificador (cada, todos(as), etc).

, descreve uma entidade do negócio, como um objeto do modelo de fatos, um papel, ou uma propriedade de um objeto. verbo no infinitivo. qualquer preposição.

descreve o comportamento que deve ocorrer com o negócio ou um relacionamento que deve ser aplicado. qualquer termo comparativo (maior, menor, igual,etc).

descreve um relacionamento entre termos identificados no modelo de fatos. descreve uma lista de .

,, parâmetros numéricos.

descreve qualquer valor , não necessariamente numérico, que tenha significado para o negócio.

descreve o procedimento a ser usado para chegar a um resultado, normalmente usando combinações de termos variáveis identificáveis no modelo de fatos.

descreve a definição de um termo no modelo de fatos. descreve uma lista de valores.

RÉGULA e o mapeamento de De Souza Termos são definidos por um texto livre, como mostrado pela expressão r1.

is (r1)

Modelos de sentença para fatos são mostrados pelas expressões r2, r3 e r4.

may (r2)

36

may (r3)

is of

Existem três possibilidades de construir , veja expressões r3.1, r3.2

e r3.3.

is an attribute of (r3.1)

is an element of (r 3.2)

is a subset of (r 3.3)

Os templates para restrições são representados pelas expressões r4 a r8.

must (r4)

must {} {} (r5)

may not {} {} (r6)

may not (r7)

must be (r8)

Há um template para regras de derivação do tipo conputation (r9), e outro para

regras de derivação do tipo derivação lógica (r10). Habilitadores de ação são

representados pelo template r11.

is computed by (r9)

if , then is considered to be in (r10)

if , then execute (r11)

RuleSpeak/Ruletrack

Os templates para rejectors são compostos pelo uso das seguintes

palavras-chaves: …must…; …may ...only if…; may … not…; ….must…no…;

…may…; … may… no … e ...must… no… .

37

As Producer Rules são dos tipos: computation e derivation. Os templates

para a regras de computação usam o operador de igualdade (...=...) ou a

palavra-chave ... deve ser computado como... . Os templates para Derivation Rules

usam a palavra-chave ...is... ou a expressão ...must be considered ...if... .

Os templates para Projectors (enablers, copiers e executives) têm finalidades

muito específicas. Muitas recomendações são dadas para a escrita das regras

nesta categoria. A criação de informação por um enabler pressupõe que ela

não existia antes. Se os dados puderem ser identificados, então a regra em

questão será um copier. Os templates de Projector são: ... must (not) be enforced, se

o tema da regra for outro (chamado também regra da exceção); ... must be

created/deleted, se o tema da regra for uma parte de dados; ... must be

enabled/disabled, se o tema da regra for um processo ou um procedimento.

Regras do tipo copier realizam atribuição de valores utilizando as

seguintes palavras-chaves: ...must be set to... e ...must be displayed...(where and

how). Os templates de executives são: ...must be executed e ...must be fired. O

Template ...must be fired deve ser usado com cautela uma vez que regras não

devem referenciar eventos. A categoria executive indica que regra deve ser

disparada primeiro em resposta a um evento em caso de haver mais de uma

regra para o evento.

Além da enfática recomendação para o uso de um tema explícito nas

sentenças, quase não há recomendações sobre as estruturas que devem

preencher os espaços em branco das palavras-chave que fazem parte dos

templates da metodologia de RuleSpeak.

38

Modelos de Sentença de Morgan Basic constraint são de dois tipos, r12 e r13:

(must|should) [not] [(if|unless) ]

(r12)

may( only if ]) | (not)

(r13)

List constraint tem duas variantes, r14 and r15:

(must|should) [not] [(if|unless) at least [and not

more than ] of the following is true:

(r14)

(may only if) | (may not if) at least

[and not more than ] of the following is true:

(r15)

Novamente, existem duas possibilidades para expressar classification rules, r16

e r17.

is [not] defined as [if|unless) ]

(r16)

must [not] be considered as [if|unless) ]

(r17)

Computation é expressa como em r18 or r19.

is defined as

(r18)

=

(r19)

39

Finalmente, os templates de enumeration rules são representados pela

expressão r20.

must be chosen from the following [open| closed] enumeration: (r20)

40

BIBLIOGRAFIA

[40] ALLEN, J. F. Natural language Understanding, Benjamim Cummings, 1995. [13] BRATKO, I Prolog Programming for Artificial Intelligence - 2nd edition, Addison-Wesley, 1990. [21] BUSINESS Rules Group What is a business rule?, 1999. Disponível na web, em http://www.businessrulesgroup.org/brgdefn.htm em 18/06/2003. [19] COMMONKADS http://www.commonkads.uva.nl/frameset-commonkads.html [1] CORREA, Sérgio M RuleCheck – Uma ferramenta para catálogo e administração de Regras de Negócio. UFRJ/IM/NCE, Maio, 2002. [16] CORREA, Sérgio Moraes Representação em Regras de Negócio em Lógica de primeira Ordem: revisão e experiência. UFRJ, 2002. [33] DATE, C. J.What Not How: The Business Rule Approach to Application Development, Addison-Wesley, 2000.

[49] DAVENPORT, T. H. (1992) Process Innovetion: Reengineering Work Through Information Technology, Harvard Business School Press. [38] DE SOUZA, M. G. Uma abordagem de Regras de Negócio baseada em Linguagem Natural estruturada, Msc.Thesis Instituto de Matemática/Núcleo de Computação Eletrônica-Universidade Federal do Rio de Janeiro, 2002. [50] DIAS, Felipe et al. (2004) Um Ambiente para Modelagem organizacional Baseado em Regras de Negócios, I Simposio Brasileiro de Sistemas de Informação, PUC/RS, Porto Alegre, Out/2004. [5] FRANCESCONI, Milton Padrões XML para gerenciamento de Processos de Negócio, 2002. Trabalho Final de MBA Informática. USP/FEA/FIA. Disponível em http:// www.imageware.com.br/MBA_MF.pdf

[45] HALL, J. (2004) "Business Semantics of Business Rules, " Business Rules Journal, Vol. 5, No. 3 (Mar. 2004), URL: http://www.BRCommunity.com/a2004/ b182.html [31] HERBST, H., KNOLMAYER, G., MYRACH, T., SCHLESINGER, M. The specification of business rules: a comparison of selected methodologies, A.A. Verijn-Stuart, T.-W. Olle (Eds.), Methods and Associated Tools for the Information System Life Cycle, Amsterdam, 1994, pp. 29-46. IFIP Working Group 8.1 Conference CRIS 94, University of Limburg, Maastricht, 1994. [43] IBM CommonRules 1.0 Alpha Release, http://www.research.ibm.com /rules/commonrules-overview.html [35] MAREK, V. W., TRUSZCZYNSKI, M. Nonmonotonic Logic: Context-Dependent Reasoning, Springer-Verlag, 1993. [44] MORGADO, G. P. Gerenciador de Regras de Negócio do RÉGULA, submitted to 18th Brazilian Symposium on Software Engineering, Instituto de Matemática/Núcleo de Computação Eletrônica-Universidade Federal do Rio de Janeiro, 2004. [25] MORGAN, Tony Business Rules and Information Systems. Ed. Addison-Wesley, 2002.

[46] OMG (2004) “Business Semantics of Business Rules Request For Proposal”. http: //www.omg.org/docs/br/03-03-03.pdf

http://www.businessrulesgroup.org/brgdefn.htmhttp://www.imageware.com.br/MBA_MF.pdfhttp://www.brcommunity.com/a2004/%20b182.htmlhttp://www.brcommunity.com/a2004/%20b182.htmlhttp://www.research.ibm.com/

41

[39] OMG - Object Management Group http://www.omg.org. [10] PERKINS, Alan " Business Rules Are Meta Data", Business Rules Journal, Vol. 3, No. 1, (Jan. 2002), URL: http://www.BRCommunity.com/ a2002/b097.html [37] RICH, E., KNIGHT, K. Artificial Intelligence, McGraw-Hill, 1991. [8] RNS RuleTrack. Business Rule Solutions, LLC. Disponível em http:// www.RNsolutions.com/ [7] ROSS R., LAM, Gladys RuleSpeak Sentence Templates. Business Rule Solutions, LLC. Copyright, provided courtesy of RNS, 2001. [15] Rule Markup Language. The Rule Markup Initiative, 2000. Disponível em http://www.dfki.uni-kl.de/ruleml. [36] RUSSEL, S. Norvig, P. Artificial Intelligence: a Modern Approach, Prentice Hall, 2003. [14] SCHACHER, Markus "Business Rules in Prolog," Business Rules Journal, Vol. 3, No. 10 (Outubro 2002), URL: http:// www.BRCommunity.com/ a2002/b118.html. [9] SEABRA, C., SILVEIRA D., CRUZ P., LIMA P., SCHMITZ E. Análise Comparativa das Formas de Representação de Regras de Negócio. Apresentado no XXXVIII CLADEA. Lima, Peru. Outubro, 2003. [3] The Business Rules Group. Defining Business Rules - What Are They Really? Final Report, revision 1.3, 2000. [4] THORPE, Margaret Business Rule Exchange - the Next XML Wave, Internationales Congress Centrum, Berlim, 2001. [6] UML Versão 2.0 Disponível em http://www.omg.org. [23] WEIDEN, M., HERMANS, L., SCHREIBER, G., ZEE, S. Classification and Representation of Business Rules. European Business Rules Conference, 2002. [18] WIERINGA,R. J., MEYER, J.-J.Ch. Applications of deontic logic in computer science: A concise overview, In J.-J.Ch. Meyer and R.J. Wieringa, editors, Deontic Logic in Computer Science: Normative System Specification, pages 17-40. Wiley, 1993. Disponível para ftp em 93-DeonticApplications.ps.Z. [42] YAROWSKY, D. Word-sense disambiguation using statistical models of Roget's categories trained on large corpora, In: Proceedings of COLING-92, pp 454-460, Nantes, 1992.

http://www.brsolutions.com/http://www.brsolutions.com/http://www.dfki.uni-kl.de/rulemlhttp://%20www.brcommunity.com/%20a2002/b118.htmlhttp://%20www.brcommunity.com/%20a2002/b118.htmlhttp://www.omg.org/ftp://ftp.cs.vu.nl/pub/roelw/93-DeonticApplications.ps.Z

42

SUMÁRIO

AGRADECIMENTOS ......................................................................................... 3

DEDICATÓRIA .................................................................................................. 4

RESUMO ............................................................................................................ 5

METODOLOGIA ................................................................................................ 6

SUMÁRIO .......................................................................................................... 7

INTRODUÇÃO ................................................................................................... 8

CAPÍTULO I ..................................................................................................... 10

ESTRATÉGIAS PARA ENUNCIADO DE REGRAS DE NEGÓCIO ................ 10

1.1. LINGUAGEM FORMAL DE PROPÓSITO GERAL ............................................... 12 1.2. LINGUAGEM DE MARCAÇÃO DE PROPÓSITO ESPECÍFICO .............................. 13 1.3. LINGUAGEM PSEUDO-NATURAL ................................................................. 14 1.4. LINGUAGEM NATURAL ............................................................................... 15 1.5. CATEGORIZAÇÃO DE REGRAS DE NEGÓCIO ................................................. 16 1.5.1 Categorias do Business Rules Group .............................................. 16 1.5.2 Categorias do RuleSpeak/Ruletrack ................................................ 17 1.5.3 Categorias de Morgan ...................................................................... 18 1.5.4 Categorização de Weiden ............................................................... 19

1.6. TEMPLATES DE REGRAS DE NEGÓCIO ........................................................ 19 1.6.1 RÉGULA e o mapeamento de De Souza ......................................... 20 1.6.2 RuleSpeak/Ruletrack ........................................................................ 21 1.6.3 Modelos de Sentença de Morgan ..................................................... 22 1.6.4 Comparação dos Conjuntos de Templates ...................................... 22

CAPÍTULO 2 .................................................................................................... 24

O MÉTODO DE CONSULTA ........................................................................... 24

2.1 REPRESENTAÇÃO INTERNA DAS REGRAS DE NEGÓCIO ................................. 25 2.2 TEMPLATES DE CONSULTA ......................................................................... 26 2.3 CONSULTA ÀS PERMISSÕES, PROIBIÇÕES E OBRIGAÇÕES ............................. 27 2.4 EXEMPLO DE APLICAÇÃO DO MÉTODO ......................................................... 29

CONCLUSÃO .................................................................................................. 33

ANEXO ............................................................................................................. 35

BIBLIOGRAFIA ............................................................................................... 40

FOLHA DE AVALIAÇÃO ................................................................................. 43

43

FOLHA DE AVALIAÇÃO

Nome da Instituição:

Título da Monografia:

Autor:

Data da entrega:

Avaliado por: Conceito:

Rio de JaneiroAGRADECIMENTOSDEDICATÓRIARESUMOMETODOLOGIASUMÁRIOINTRODUÇÃOCAPÍTULO IEstratégias para Enunciado de Regras de Negócio1.1. Linguagem Formal de Propósito Geral1.2. Linguagem de Marcação de Propósito Específico1.3. Linguagem Pseudo-Natural1.4. Linguagem Natural1.5. Categorização de Regras de Negócio1.5.1 Categorias do Business Rules Group1.5.2 Categorias do RuleSpeak/Ruletrack1.5.3 Categorias de Morgan1.5.4 Categorização de Weiden

1.6. Templates de Regras de Negócio1.6.1 RÉGULA e o mapeamento de De Souza1.6.2 RuleSpeak/Ruletrack1.6.3 Modelos de Sentença de Morgan1.6.4 Comparação dos Conjuntos de Templates

CAPÍTULO 2O MÉTODO DE CONSULTA2.1 Representação Interna das Regras de Negócio2.2 Templates de Consulta2.3 Consulta às Permissões, Proibições e Obrigações2.4 Exemplo de Aplicação do Método

CONCLUSÃOANEXOBIBLIOGRAFIAFOLHA DE AVALIAÇÃO