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
Top Related