Gerenciamento Eficiente de Regras de Negócio em LPS

Gerenciamento Eficiente de Regras de Negócio em LPS

Projeto Conceitual de Banco de Dados - PCBD

 

 

 

 

 

Esse tópico tem como propósito introduzir, os principais conceitos inerentes ao Projeto Conceitual de Banco de Dados, seu contexto, os insumos, produtos, ferramentas envolvidas e critérios de qualidade utilizados para a obtenção dos produtos a parir dos insumos, com a utilização de métodos, técnicas e ferramentas e em concordância com os critérios de qualidade inerentes a essa fase.

Projeto Conceitaul de Dados é uma atividade que tem como ponto de partida os Requisitos de Informação e as Regras de Negócio inerentes a um determinado Domínio de Conhecimento (Parcela do Mundo Real, Mini-Mundo ou Domínio de Problema).

Ao interagir com os elementos (entidades, objetos) que constituem o seu Domínio de Conhecimento, o usário (também um objeto) cria conceitos a partir da percepção desses objetos e dos relacionamentos entre eles.

Os objetos de um determinado domínio do conhecimento (mini mundo) estão sujeitos as REGRAS (DE NEGÓCIO), que visam restringir ou controlar (presente), explicar (passado) e prever ou planejar (futuro) o comportamento desses objetos.

O controle desse comportamento é reforçado através da captura de informações (REQUISITOS DE INFORMAÇÃO) sobre as características desses objetos.

As Regras de Negócio e os Requisitos de Informação expressam esses conceitos e que deverão ser identificados no início da fase de Projeto Conceitual de Dados.

 

O Conhecimento Organizacional pode ser definido como um conjunto de Regras de Negócio e um conjunto de Requisitos de Informação.

Esse é o ponto de partida para a execução do Projeto Conceitual de Dados.

Nessa atividade será utilizado como ferramenta (instrumento) de modelagem (projeto) o Modelo Entidade Relacionamento (ou qualquer outro Modelo de Dados Semântico).

A utilização do Modelo Entidade Relacionamento deverá buscar atender a uma série de Critérios Técnicos de Qualidade (Requisitos Técnicos de Projeto Conceitual de Dados).

O produto final dessa atividade é o Modelo Conceitual de Dados (Modelo do Conhecimento Organizacional), o qual é constituido de:

• Diagrama de Entidade e Relacionamento (DER) ou ERA (Entidade Relacionamento e Atributo) modelando o aspecto estrutural do mundo real;
• Regras de Restrição de Integridade (RI) e um conjunto de Regras de Derivação (RD) modelando o aspecto comportamental do mundo real.

Regra de Derivação (Regra de Cálculo, Regra de Inferência)

Regras de Derivação, Cálculo ou Inferência (representam ou modelam Regras de Negócio que estabelecem um estado futuro para os Elementos da Realidade).

Regra de Derivação (Regra de Cálculo, Regra de Inferência) é um tipo de Regra de Negócio que especifica a forma como determinadas informações podem ser obtidas a partir de outras informações já existentes no Banco de Bados, por cálculo ou por inferência.

Regra de Restrição de Integridade

Regras de Restrição de Integridade (representam ou modelam Regras de Negócio que restringem as mudanças de estado atuais dos Elementos da Realidade).

Restrição de Integridade ou Regra de Restrição de Integridade, estabelecem procedimentos ou mecanismos a serem respeitados para que os Processos Organizacionais recebam e produzam Informações Consistentes.

Visam permitir a representação de Regras de Negócio que se não forem respeitadas a consistência (integridade) do Banco de Dados será prejudicada. Em outras palavras, elas proíbem (restringem) a existência de valores de Dados inválidos, estabelecendo, dessa forma e indiretamente, os válidos.

Exemplo: um Cliente não pode fazer Pedidos além do seu Limite de Crédito.

No Modelo Entidade Relacionamento existem os seguintes tipos de Restrição de Integridade com simbologia específica para modelagem de Regras de Restrição de Integridade:

1. Identificação
2. Cardinalidade
3. Repetição
4. Cobertura

Existem Regras de Restrição de Integridade mais complexas que devem ser representadas no Dicionário de Dados. Nesses casos deve-se identificar no DER que conceito está sendo restringido através de uma notação RI-XXX.

Regra de Negócio

Os sistemas de informação abrangem, com freqüência, um grande volume de conhecimento organizacional formalizado.

Tal conhecimento é especificado como regras de negócio, definidas por Bell como sendo “declarações que apresentam a maneira de como o negócio está sendo feito, além das diretrizes e restrições com respeito a estados e processos em uma organização”.

Surge com isso a necessidade de se modelar regras de negócio, enfatizando a sua importância em um esquema conceitual, que, segundo Loucopoulos, representa todas as regras que governam o universo de discussão, devendo estar definidas dentro de um esquema conceitual.

A partir desta necessidade, tais regras de negócio têm sido amplamente utilizadas pelas organizações como forma de melhorar a qualidade de seus sistemas.

"Regras de Negócio são todas as regras existentes num sistema de informação, que ditam seu comportamento, suas restrições e validações".

"Regras de negócio definem como o negócio funciona, podem abranger diversos assuntos como políticas, interesses, objetivos, compromissos éticos e sociais, obrigações contratuais, decisões estratégicas,leis e regulamentações entre outros".

"Business rules or business rulesets describe the operations, definitions and constraints that apply to an organization in achieving its goals. For example a business rule might state that no credit check is to be performed on return customers. Others could define a tenant in terms of solvency or list preferred suppliers and supply schedules. These rules are then used to help the organization to better achieve goals, communicate among principals and agents, communicate between the organization and interested third parties, demonstrate fulfillment of legal obligations, operate more efficiently, automate operations, perform analysis on current practices, etc."

Regras de Negócio permitem a especificação de políticas, condições ou procedimentos, dentro de um Domínio de Problema, a serem seguidos pelos Processos Organizacionais, para que uma Organização alcance seus objetivos.

Regras de Negócio propiciam o controle (restrição – presente), o planejamento (previsão – futuro) e a explicação (passado).

A separação das regras de negócio nos sistemas de informação apresenta uma série de vantagens amplamente aceitas na comunidade de sistemas de informação [R97, R98, D00].

Segundo [G97] uma regra de negócio pode ser definida segundo duas perspectivas: a perspectiva do negócio e a perspectiva dos sistemas de informação (SI). Segundo a perspectiva do negócio, uma regra de negócio é uma diretiva destinada a influenciar ou guiar o comportamento do negócio, como suporte à política de negócio que é formulada em resposta a uma oportunidade. Segundo a perspectiva dos sistemas de informação, uma regra de negócio é uma sentença que define ou restringe algum aspecto do negócio. Pretende-se garantir a estrutura do negócio ou controlar a influência do comportamento do mesmo.

Ainda, segundo [D00], as regras de negócio são a solução para o problema da necessidade de se escrever código de forma procedural, podendo-se especificar sistemas apenas de forma declarativa. As regras de negócio, segundo ele, nos permitem automatizar o processamento de negócios.

Como dito em [G97] os métodos tradicionais de análise de sistemas por muito tempo tenderam a negligenciar regras de negócio inerentes aos empreendimentos, preocupavam-se principalmente em modelar a estruturação dos dados utilizados e os processos executados pelos empreendimentos.

Os métodos mais modernos de modelagem de sistemas, principalmente os que dão enfoque a orientação a objetos, já tentam lidar e resolver tais problemas. Isto pode ser visto na proposta de extensão a UML[BRJ97] chamada OCL (Object Constraint Language) em [OCL97] para dar suporte a restrições. Date em [D00] vai mais além dizendo que poderíamos até eliminar o processo de codificação de software simplesmente utilizando uma modelagem de sistemas baseado em regras de negócio com sua frase de impacto “declarative is better the procedural” que significa que é melhor que se defina sistemas apenas de forma declarativa e não procedural como é feito hoje em dia.

Uma forma de se conseguir, ao menos em parte, este objetivo, é a formalização das regras de
negócio em uma base de conhecimento. Uma dificuldade na administração das regras de negócios está no fato de que as bases de conhecimento não devem conter incongruências lógicas. Formalizar as regras de negócio utilizando-se uma linguagem declarativa permite que as mesmas sejam convertidas para uma representação em lógica de primeira ordem, o que irá facilmente permitir que tais incongruências sejam identificadas. Mais do que isso, ao se modificar uma regra, ou acrescentar uma nova, a consistência da base poderá ser testada para a verificação de incongruências, de modo listar as regras conflitantes auxiliando a equipe no trabalho de resolver tais problemas. Além disso, a formalização de parte do conhecimento obtido durante a fase de análise é um grande passo na direção de se gerar código automaticamente.

Bibliografia

1. [D00] Date, C. What not How, The Business Rules Approach to Application
   Development, Addison-Wesley, Reading Massachussets, 2000.
2. [R97] Ross, R. The Business Rules Book: Classifying, Defining, and Modeling Rules
   2nd edition, Business Rule Solutions Inc., Houston Texas, 1997.
3. [R98] Ross, R. Business Rules Concepts, The New Mechanics of Business
   Information Systems, Business Rule Solutions Inc., Houston Texas, 1998.
4. [G97] GUIDE Business Rules Project: Final Report, revision 1.2, October 1997.
5. [BRJ97] Booch, G.; Rumbaugh, J.; Jacobson, I,; “The Unified Modeling Language for
   Object-Oriented Development”, Documentation Set Version, janeiro, 1997.
6. [OCL97] Object Management Group, “Object Constraint Language Specification”, 1
   September 1997.

Conhecimento Organizacional

O mundo real é constituído de fenômenos e regras que refletem nossa necessidade de restringir (controlar-presente), prever (planejar-futuro) e explicar (passado) o comportamento dos objetos (coisas, entidades) do mundo real.

Nossa necessidade de controle sobre o comportamento dos objetos do mundo real é exercido através da “medição” dos valores das características (informações) reais ou abstratas dos objetos do mundo real.

As características (reais/abstratas) de um objeto constituem a sua estrutura.

O Conhecimento Humano é constituído de um Conjunto de Informações e de um Conjunto de Regras de manipulação dessas Informações.

O Conhecimento Organizacional tem como base o Conhecimento dos seus Recursos Humanos,sendo, de forma análoga, constituído de um Conjunto de Requisitos de Informação e de um Conjunto de Regras de Negócio.

Principles of the Business Rules Approach

Business Rules Applied

Agile IT Architecture: A Cycle Approach for Business Rule Development

Agile IT Architecture: A Cycle Approach for Business Rule Development: "The Agile Business Rule Development methodology details all the different activities to develop a rule set, from rule discovery to rule set deployment and maintenance. We can group the set of activities into five groups. Those groups will be used to build an iterative approach to the development:
Rule Discovery
Rule Analysis
Rule Authoring
Rule Validation
Rule Deployment

The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business."

Business Decisions in a Digital Enterprise

Business Decisions in a Digital Enterprise

Excelente Blog !!! Regras de Negócio.

Defining Business Rules ~ What Are They Really? (Abstract and Table of Contents)

Defining Business Rules ~ What Are They Really? (Abstract and Table of Contents)

"Abstract

Systems analysts have long been able to describe enterprises in terms of the structure of the data those enterprises use and the organization of the functions they perform, but have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert them into program code. While rules which are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all.

The GUIDE Business Rules Project was organized in November 1993 to carry out that articulation. This paper, the original report of the GUIDE Business Rules Project (now the Business Rules Group), describes a scheme for understanding the nature of business rules and the categories into which they fall. It presents a formal approach for identifying and articulating the rules that define the structure and control the operation of an enterprise.

Table of Contents

The Table of Contents below is intended for readers who wish to load the document one chapter at a time. You may go to each chapter directly from the Table of Contents below or read the document sequentially, from one chapter to the next.

The document is also available as a PDF format document (approximately 175k).

Introduction
Project Scope and Objectives
Overview of the Paper
The Rationale
A Context for Business Rules
Definition of a Business Rule
Categories of Business Rule
Formalizing Business Rules
The Business Rules Conceptual Model
Formulating Business Rules
The Origins of Business Rules -- the Model
Types of Business Rule
Definitions
Structural Assertions
Terms and Facts
Kinds of Term
Kinds of Fact
Base Facts / Derived Facts
Attribute / Participation / Generalization
Definitions
Action Assertions
Action Assertion Classifications
Action Assertion Classes
Action Assertion Types
Controlling vs. Influencing
Definitions
Derivations
Kinds of Derivation
Definitions
Footnotes & Acknowledgments
Footnotes
Acknowledgments
Appendix A: The Complete Model
Appendix B: How to Read a Conceptual Model
Appendix C: An Extended List of Action Assertion Types
Appendix D: Case Study: EU-Rent Car Rentals
Appendix E: Glossary
Appendix F: Bibliography

Go to... Top of page First chapter BRG Home Page

Copyright ©2001, the Business Rules Group. All rights reserved.

Business Rules Manifesto

Business Rules Solutions - Artigo - Ronald G. Ross

Diretrizes: Regras de Negócios

Regras de Negócios
As regras de negócios são declarações de políticas ou condições que devem ser cumpridas.

Tópicos

• Explicação
• Níveis de formalismo
• Categorias de regras de negócios
• Como as regras de negócios são refletidas nos modelos

Explicação

As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Elas podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos.

Níveis de Formalismo

As regras de negócios devem ser expressas rigorosa e formalmente para que sejam uma base para automação. Uma alternativa pode ser o uso da Linguagem de Restrição de Objetos (OCL) conforme especificado na Linguagem Unificada de Modelagem. [RUM98]

Exemplo:

É possível expressar um limite para o tamanho da equipe; por exemplo, menos de dez membros em uma equipe. Com a OCL, é possível definir essa regra de negócio com uma invariante:

context Team inv:

    self.numberOfMembers <= 10

Lembre-se que esse tipo de linguagem formal pode ser difícil de interpretar para muitos dos envolvidos; portanto, é preferível um estilo de linguagem mais natural. É possível definir um conjunto de expressões reservadas que são usadas para definir as regras. Essas expressões poderiam ser as mesmas das definidas em [ODL98]:

• IF
• ONLY IF
• WHEN
• THEN
• ELSE
• IT MUST ALWAYS HOLD THAT
• IS CORRECTLY COMPLETED

Exemplo:

Nessa linguagem menos formal, o exemplo acima poderia ser:

IT MUST ALWAYS HOLD THAT o número dos membros da equipe é menor ou igual a 10.

Categorias de Regras de Negócios

As regras podem ser classificadas de várias formas, embora seja comum separá-las em regras de restrição e de derivação. [ODL98] As categorias podem ser subdivididas posteriormente conforme descrito abaixo:

• Regras de restrição especificam políticas e condições que restringem o comportamento e a estrutura de objetos. 

• Regras de estímulo e resposta restringem o comportamento especificando quando e se as condições devem ser verdadeiras para que o comportamento seja disparado. 
• Regras de restrição de operação especificam as condições que devem ser verdadeiras antes e após uma operação para garantir que a operação seja executada corretamente. 
• Regras de restrição de estrutura especificam políticas ou condições sobre classes, objetos e seus relacionamentos que não podem ser violados. 

• Regras de derivação especificam políticas ou condições para deduzir ou calcular fatos de outros fatos. 

• Regras de dedução especificam que se determinados fatos são verdadeiros, uma conclusão pode ser deduzida. 
• Regras de cálculo derivam seus resultados pela forma de processar algoritmos, uma variante mais sofisticada de regras de dedução. 

Essa classificação de regras de negócios é prática para explicar quais são as regras de negócios, como localizá-las e como trabalhar com elas. Contudo, elas não são um grupo fixo ao qual é necessário fazer referência sempre. Portanto, nosso template de artefato de regras de negócios não mostra essa classificação; é proválvel que no seu projeto haja outros grupos (de domínio, de usuário ou de produto) que merecem ser exibidos.

Como as Regras de Negócios são Refletidas nos Modelos

Uma regra de negócio afeta a aparência do modelo. Ela também pode afetar as atividades de seqüência no diagrama de atividades, além de afetar as associações entre as entidades de negócios. Não é fácil converter algumas regras diretamente para a aparência de um diagrama; elas devem estar presentes em descrições dos elementos de modelos.

Independentemente, é útil mostrar regras de negócios como notas de texto, vinculadas ao elemento de modelo que elas afetam no diagrama.

Também é útil controlar regras de negócios em Atributos de Requisitos, para fins de rastreabilidade e relatório.

Regras de Estímulo e Resposta

Esse tipo de regra de negócio afeta o fluxo de trabalho de um caso de uso de negócios e pode ser rastreada nos casos de uso de negócios aos quais se aplica. É possível mostrar um caminho condicional ou alternativo através do fluxo de trabalho. Se as ações envolvidas são menos significativas, talvez seja suficiente deixar a avaliação da regra de negócio ser incluída em um estado de atividade.

No modelo de objetos de negócios, uma regra desse tipo poderia, por exemplo, afetar a forma como você descreve o ciclo de vida de uma entidade de negócios ou ser parte da descrição de uma operação em um trabalhador de negócio.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

WHEN um Pedido é cancelado

IF um Pedido não é enviado

THEN fechar Pedido.

Essa regra de negócio é refletida mostrando dois caminhos alternativos em um fluxo de trabalho e especificamente usando condições de guarda e decisão em transições de saída.

A regra de negócio nesse caso é convertida em um caminho alternativo através do fluxo de trabalho

Regras de Restrição de Operação

Esse tipo de regra de negócio geralmente é convertida em precondições e pós-condições de um fluxo de trabalho ou em um caminho condicional ou alternativo em um fluxo de trabalho. Ele também pode ser uma meta de desempenho ou alguma outra regra não comportamental que deve ser rastreado nos casos de uso de negócios aos quais ela se aplica.

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

Enviar Pedido ao Cliente

ONLY IF O cliente tiver um endereço de entrega.

A regra de negócio é convertida em um caminho alternativo no fluxo de trabalho

Exemplo:

Um outro exemplo de regra de restrição de operação é:

IT MUST ALWAYS HOLD THAT

Todas as pesquisas do cliente devem ser respondidas dentro de 24 horas do seu recebimento

Essa regra de negócio seria convertida em uma meta de desempenho de um caso de uso de negócios. Consulte a seção sobre Meta de Desempenho em Diretrizes: Caso de Uso de Negócios.

Regras de Restrição de Estrutura

Esse tipo de regra de negócio afeta as relações entre instâncias de entidades de negócios. Elas são expressas pela existência de uma associação entre duas entidades de negócios; às vezes como uma multiplicidade na associação. 

Exemplo:

Em uma organização de gerenciamento de pedidos, é possível encontrar a seguinte regra:

IT MUST ALWAYS HOLD THAT

um Pedido se refere a 1 Produto no mínimo.

Essa regra de negócio é convertida em uma associação com a multiplicidade de 1..*.

Regras de Dedução

Geralmente, as regras de dedução parecem semelhantes aos tipos de regra de estímulo e resposta, de restrição de operação ou de restrição de estrutura; a diferença é a existência de algumas etapas que precisam ser atingidas para chegar à conclusão. A regra implica um método que precisa ser refletido em um estado de atividade do fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou entidade de negócios.

Exemplo:

Talvez você tenha definido a seguinte regra para determinar o status de um cliente:

Um Cliente é um Bom Cliente IF AND ONLY IF

as faturas não pagas enviadas a esse Cliente têm menos de 30 dias.

Essa regra de negócio corresponde a um caminho alternativo através do fluxo de trabalho, e o método prescrito será parte da atividade Avaliar Cliente

Regras de Cálculo

As regras de cálculo são diferentes das regras de dedução; a diferença é que o método é mais formal e semelhante a um algoritmo. Assim como as regras de dedução, esse método precisa ser rastreado em uma atividade no fluxo de trabalho e eventualmente em uma operação em um trabalhador de negócio ou uma entidade de negócios.

Exemplo:

Uma regra de cálculo pode especificar cálculo de valor:

O preço líquido de um Produto IS COMPUTED AS FOLLOWS

preço do produto * (1+porcentagem de imposto/100).

A avaliação do preço líquido poderia ser parte da atividade Enviar Pedido quando você prepara a cobrança a ser enviada com o pedido. Nesse modelo de objetos de negócios, essa regra é convertida em associações e operações.

Essa regra precisa ser refletida como um método na operação de cálculo do preço líquido, mas também implica a necessidade de relacionamentos entre classes no modelo. 

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process   

OCL - Object Constraint Language

ATENAS: Um Sistema Gerenciador de Regras de Negócio

Principles of the Business Rule Approach

Principles of the Business Rule Approach

Banco de Dados – Um Contexto Mais Abrangente

1. Data Base (Banco de Dados)
2. OLTP: On Line Transaction Processing
3. Data Warehouse: que inclui ETC (Extração transformação e carga)
4. Data Mart
5. OLAP - On-Line Analytical Processing
6. Data Mining
7. Business Rules
8. Knwoledge Management (KM) - Gestão do Conhecimento
9. Business Process Management (BPM)
10. Business intelligence

Organização - Regras

"Na definição clássica de Douglass North, prêmio Nobel de Economia de 1993, instituições são as regras do jogo. Constituem as restrições criadas para moldar a interação humana e estruturar incentivos para ações de natureza política, social ou econômica. Limitam o arbítrio dos governantes. As crenças da sociedade constituem parte do processo, pois determinam escolhas e promovem avanços nas instituições. O êxito das economias capitalistas deve muito à evolução mental e à compreensão dos fenômenos econômicos."

Fato Associativo (Propositivo, Assertivo) - Proposição - Asserção

Fato Associativo, Proposição ou Asserção é um Fato que envolve um Conceito Associativo e 2 ou mais Conceitos.

Fato Associativo é uma Regra de Definição.