BUSINESS RULES ENGINE

Transcrição

1 BUSINESS RULES ENGINE ABSTRACT This content has a proposal to formalization of a written modeling of software construction by using the business rules approach. At the present moment software are made by using the use case approach with posterior description by systems analyst with class, sequence and others diagrams. Unfortunately, the source code has been shown as an approached as the desirable and unable to reflect as a presentable documentation model. The present proposal has the objective the implementations of some intelligent model by using some tool described as Business Rules Engine able to store and learn class content, semantic rules, and describe the intelligence of the proposal systems building, as a result a source code logically representing the best profit of the rules modeling described in your body.

2 The purpose 1. Increased speed of implementation This model allows that new rules or changing rules can be preceded immediately. 2. Management of diversity When the situations where many team or companies around some partner has so much adversity or huge tendencies with eventual transient, it has been adopted measurement of implementations with non conformal in reason of cost or inexistence of technologic perspective. Otherwise, the BR architecture allow different teams to expand yours operation portfolio and quickly to response a new opportunities allowing even the creation and removing of rules in a short transitory time lapse. 3. Auditability Many organizations are unsafe about what exactly yours applications are doing. It can be composed by regulatory requirements promoting prove about that the operations are been proceeded in some appropriated rule. The BR architecture has structure to promote the high accuracy level required for some rule. The practical result is that the organizations can manage and even reduce your general profile. 4. Engineering compliance In traditional development approaching, practical tests are the primary way to have sure that was implemented is in accordance about what was specified. The BR architecture offers the specification ability in your own body and direct implementation over the operation system. The accuracy of the result proves the certain about the expectative result of the system in accord of the original specification.

3 Pag. 3/32 What is Business Rules (BR)? Business rules engine architecture concept definition. It can be sure that the partner investment is promoted by business rules The portfolio must win no less than 10% a year Most of the people have many different concepts about this concept. To say that the statements above are rules do not allow it near of the reality facts. Although it desire to be happen. It is so many hard to imagine a right way that such rules can be implemented. The fact is that s statement are not rules, but an intention or a target. Confusion is also referenced to the statement Business rules engine. If the stream is hot, then it will be used frequently for those who think that can get a particular gain in position or product participation. Some erudite describe BR like: A declaration of state witch defines and compels business aspects. Although reasonable, these declarations do not contemplate a wide definition. It can say that is a dead declaration. It must be in mind that different people understand BR differently. It is very important that someone think about the rule construction and care about the engine of the business rules. These one will be called the BR analyst. It is not unusual to see support analyst inferring directly on database. When it happens frequently, it is clearly signal that the conventional application model didn t stay event near to the collection of the functional specification desired or worst, the project specification was bad written. Business rule are constructed respecting some principle (also called as 2 nd degree business rule or rule s rule). The basic fundamental must respect these following adjective. Atomicity It must avoid the rule duplication.

4 Pag. 4/32 The solution of some question must be unique. It means that it doesn t have more than one rule for the same question. Example: The sales price = the Total Cost + Tax + Profit The sales price = 135% * the Total Cost The Profit >= 10% * Portfolio + 25% the Total Cost The Profit >=Tax Statement 1 : Sample rule In most circumstance, the 1 st and 2 nd rules can get different result. In consequence if the first one is used for charges and the second one is used to calculate tax, the consequence is the catastrophic financial results. But although the 3 rd and 4 th rules can change the result of the 1 st one, your appliance is the Profit rule, and the 1 st rule is the sale rule. Confinement If the rules act as constraint, it typically operate in data groups for that only centain values can be populated. At the previous examples (Statement 1 : Sample rule), rules 1, 3 and 4 belong to the same constraint and your relations are defined by some rule flow. Example: In some hydroelectric environment, a player that uses some specific generator engine can express these energy rules. The total power available for some hydrodynamic environment is: Power available = 9,8 * Stream flow * Net head Where Power available = Electric power + Heat loss + Vibration loss For some specific generator: Heat loss = 10% * Power available

5 Pag. 5/32 Vibration loss = 30% * Power available To maximize the energy, these player use the vibration energy to move the Seed cleaner engine that consume until 50% of the vibration energy. Once that uncertain moment, these seed engine require more energy than the mechanic available. In these case, the rest of the energy become from the electric energy. To be worst, in each plant, the engine provider/characteristics change. It is clear that to stabilize the engineer forces and solve the problem, the player need to balance the different source force. To get it in accordance, the rule power has 3 component results, where the solution became from the only one statement rule sequence. Computations and derivations Computation and derivations are other great business rules class. Some computation rule must get only one response that are almost stored in some attribute field or column. In complex operations, a computation can involve a transformation matrix N x M with n input attributes variable and response a complex number m-dimensional. Interference This is like a calculus that does not populate values into database. It provide response to some type of question with some level of certain. Normally is utilized in process to populate formulary, reports or auditory procedure.

6 Pag. 6/32 Who need B.R. access? In general way everyone that expect that the information is more than a sequence of words, like content information, need BR access. The content information transforms a single word in some action or preposition or subject or adjective or someone else. The consequence of these facts is that some content can create statements, event, actions, consequences and other relations not previously considered. Once that the dynamic relations created by business rules can access new other contents, the content policy manager is another important person in the present scenario. The creation of business rules must be made by someone able to translate the desire in reality. This agent is now known as business rules analyst. Once that all the rules and engine must be organized to be running in accordance of the users needs and your roles, the system administrator is some important agent in the scenario. 1 Agent BR

7 Pag. 7/32 The conceptual definition above to guarantee the agreement must be made by someone that knows the basic concept of content and component of the environment. These agents are called corporate underwriter and has the responsibility to guarantee the integrity of the underwriting guideline. In certain environment, it is necessary to share de responsibility above all site area with different regions. Each region has you own regional manager agent that enter the regional guideline. In these cases, the system administrator also has the responsibility to include interface rules defining the representative entity region and yours border transition or boundary contour. Os Atores Analista de negócio ( Business Analyst) Operadores de sistema ( System Operator ) Consultores ( Consultants ) Tecnólogo de negócio ( Business Knowledge Workers ) Gerente senior de negócio ( Business Senior Managment ) Administradores de TI ( Information Technology Staff ) Programadores ( Programmers ) Erro! Nenhum tópico foi especificado. Erro! Nenhum tópico foi especificado. Quando? Regras conhecidas apriori ; Regras definidas na implementação ; Mudanças de regras em produção ;

8 Pag. 8/32 Integração TOTAL DO SOFTWARE Em casos aonde o domínio do problema do negócio requer uma aplicação de software específico + um grau de funcionalidade da arquitetura do motor de BR, é de significativa vantagem que se possa construir o motor de regra como parte do software aplicativo. A primeira vantagem é de que a aparência ( look and feel) da funcionalidade do motor de regra possa ser similar ao de uma aplicação. Isto ajuda ao usuário a aumentar a sua aceitação no motor de regras fazer disto mais fácil para usuários trabalharem com funcionalidade de motores. A segunda vantagem é que o motor de regra passa a interagir diretamente no database da aplicação. Figura 1 : Relação entre B.R. e o Database da aplicação O motor de regra deve ser capaz de acessar o database da aplicação, ler e escrever. Mas, antes de tudo, deve entender o modelo de dados pelo qual os dados foram construídos para que ele possa trabalhar com os dados que ele contém.

9 Pag. 9/32 Antes que o motor de regra possa funcionar, ele deve ser treinado para entender o modelo de dados e estar conectado com a base de dados. O modelo de dados e a base de dados não são a mesma coisa. O modelo lógico não pode ser simplesmente derivado de uma engenharia reversa automática de um database. Alguma coisa que seja freqüentemente postulado como uma solução aonde não exista modelo de dados. O database só conhece nomes físicos de tabelas e colunas. Mas o motor de regra irá inevitavelmente ter que conhecer o nome de negócio de cada entidade. Os relacionamentos são outra questão crucial. Se o database não tiver Foreign keys declarada então não se pode conhecer os relacionamentos aplicados no sistema. Outra vantagem a ser observada é a migração escalonada. Se um motor de regra comercial é adquirido, o trabalho para conectar o motor de regras ao database da aplicação e fazer o motor de regras entender o modelo terá que ser feito por completo antes que as regras sejam implementadas. Isto pode ser uma larga tarefa, dispendiosa e que deverá ser feita em um curto período de tempo. E deverá estar concluída antes das regras definidas. Já, se o motor de regra é parte de uma aplicação, existe uma grande oportunidade para atualizar a mesma por UPGRADE. Por exemplo, implementa-se gradualmente um processo de cada vez.

10 Pag. 10/32 Componentes de um tradutor de regras Business Rules Engine Figura 2 : Componentes do tradutor de regras Business Rules Repository Formado por um conjunto de tabelas que contém informações sobre o modelo físico e lógico da aplicação é o kernel do BR Engine. O modelo físico é composto da base de dados da aplicação, dos seus atributos e relacionamentos. O modelo lógico é composto das entidades de classe representativa que formam o modelo, dos seus atributos, métodos e relacionamentos. É também parte integrante do repositorio as definições de B.R., os processos de negócio e da aplicação processada.

11 Pag. 11/32 Entende-se que os sistemas são formados por dados e metadados. Os dados são as informações que o usuario utiliza e manipula. Os metadados são todas as representações declarativas para os dados. Informações esta que o sistema B.R.E. armazena e manipula. O repositório é uma base de dados que armazena metadados. Uma vez que existem diferentes tipos de metadados, as mesmas são agrupadas por tabelas formando, assim, um repositorio de base de dados de metadados. Application Database Metadata A parte fundamental do repositorio de B.R.E. é a base de dados de metadados da aplicação. Formado por conceitos gerais, suas informações descrevem a estrutura física e lógica da aplicação a que se está referenciando. O BRE deve ter estes conceitos fortemente amarrados para que seja possivel entender a sua estrutura e o consequente acesso aos seus dados fisicos (em uma base de dados) e logicos (em objetos de classe). Business Process A execução de regras exige eventuais encadeamento de tarefas. Para viabilizar o encadeamento, define-se Business Process como sendo a unidade lógica de negócio. Consite em um processo completo que começa com um evento de algum tipo, e termina com a produção de uma saída em responta a algum evento. Pode-se também encadear os processos por meio de batches squeduladas que disparam Business Process. Deve-se salientar que a execução de um processo de negócio pode envolver vários passos ou etapas. Cada etapa é chamada de Business process steps que é um importante elemento construtor no modelo aproximado de B.R.E. definido nesta proposta. Estas são usadas para definir conjuntos ou pacotes que são executadas juntas. O Business Rules Repository precisa capturar os eventos de cada passo do processo que esta sendo executado, decompor em passos, disparar ações definidas nas regras, rotear as ações até que ele termine por completo, controlar a sequencia de eventos e eventualmente gerenciar erros de processos ou de regras. Rule Definitions Neste parte são declarados, armazenados, organizados e gerenciados as definições de regra. São metadados que referenciam elementos lógicos e físicos às regras. Uma vez que as regras podem ser bastante complexas, estabele-se a priori que cada regra está relacionado a uma seqüência de Business Process. Cada regra possui um contexto declarativo informando os objetos que fazem parte da regra e suas eventuais restrições ou origens, uma cláusula condicionante (SE) inferindo uma seqüência de Business Process relacionados entre si por meio de operações booleanas, uma cláusula de resposta positiva (THEN) promovendo uma seqüência de Business Process e uma cláusula de resposta negativa (ELSE) promovendo outra seqüência de Business Process. Cada Rule Definition pode ainda ser cascateável em dois formatos : Decision Table ou Decision Tree.

12 Pag. 12/32 A execução de uma rule definition está, por sua vez, encapsuladas em um Package Rule que agupa uma seqüência por meio de uma máquina de estado aonde cada estado executa pelo menos uma regra. O Package Rule é uma ação que define o encadeamento das tarefas. Sua ação é requerida pela ação da aplicação principal que efetua a sua requisição. Seu primeiro estado, ou estado inicial, é o de disparar um processo para carregar os objetos relevantes no Working Memory. Seus estados subseqüentes seguem de acordo com o projeto descrito, realizando em cada estado, uma seqüência de regras. Figura 1 : Project - Package Rule - Rule Flow

13 Pag. 13/32 Figura 2 - Rule Flow

14 Pag. 14/32 Figura 3 - Decision Table

15 Pag. 15/32 Figura 4 - Decision Tree

16 Pag. 16/32 Rules Definition Interface Uma vez definido o Repositório com todos os elementos necessários para representar regras de negócio, deve-se ser criado uma interface capaz de construir e manutenir o repositorio. A interface consiste de um conjunto de telas (forms) que permiter que um usuário possa acessar, definir, implementar, manter e auditar regras. A Interface formada por FORMS permite editar as regras de negócio no repositório de acordo com a visão e a linguagem traduzida para o nível do analista de negócio. É importante considerar que a interface é formada por forms para serem executadas em um ambiente IDE mas também por métodos encapsulados por objetos de classe de

17 Pag. 17/32 interface capaz de permitir a edição e o gerenciamento das regras e do repositório tanto em um ambiente Client Server como em um ambiente J2EE. Executable Business Rules Introduz-se aqui um novo conceito chamado Business Rules Types. Este conceito tem por objetivo agrupar diferentes regras de negócios por similaridade de categoria. Estas categorias são limitados por tipos de regras de negocio. A principio considera-se um tipo de regra. A regra complementar é considerada um tipo de regra de negócio que envolve cálculos. Outro tipo de regra é a derivação. Isto é concebido como sendo uma regra de negócios em que o valor é derivado de outro valor de outra regra. Exemplo Se E E Então o total de gasto do Consumidor no periodo do último ano for maior que $ o Consumidor não atrazou nenhum pagamento o Consumidor efetuou cada pagamento com não mais do que 1 parcela o Status do Consumidor = Platinum Elementos do texto : - AZUL : Adjetivo (Business Rules Types) - Vermelho : Objeto - Amarelo : Método do objeto - Verde : Atributo do objeto - Sublinhado : Valor aplicado ao parametro ou atributo ou subtipo.

18 Pag. 18/32 CLIENTE PGTO PARCELAS Métodos : BOOL PGTO.Atrazou ( cdcliente, cdpgto ) INT PGTO.PagouComParcelas ( cdcliente, cdpgto ) BOOL CLIENTE.GastouNoPeriodo ( DtIni, DtFim ) Embora os metodos aqui apresentador, tanto de categoria de cálculo quanto de derivação, estão vinculados a entidades lógicas ( CLIENTE, PGTO), elas devam ser configuradas como uma Template e agrupadas por categorias podendo ser utilizada em outros negócios totalmente diferente mas que contenham as entidades lógicas representativas aos métodos. O código declarado como Executable Business Rules é formado por um agrupamento de Business Rules Types parametrizado de acordo com os elementos do Repositorio e as regras estabelecidas. Sendo assim, estes métodos podem ser aplicáveis a hospedagem, construção, saúde, previdencia, etc. A desvantagem do uso de um método de negócio particular é que é muito frequente que tipos de negócio sejam específicos no seu domínio próprio. Existem certos termos específicos de negócio que descrevem que regras são executadas. Para isto nomes são declarados a Business Process ( e seus Business Steps) que precisam ser executadas para processar o negócio. Dado que a riqueza de especificações em torno do usuário de negócio, porque devem as regras serem categorizadas de forma a fazer (mais ) sentido para o profissional de TI, e porque deve-se ignorar o caminho que o usuário ve as regras?

19 Pag. 19/32 Porque a arquitetura física foi mal concebida? Porque roda mais rápido? Porque, com a ferramenta disponível (seja database ou datawarehouse) assim não dá pau? Porque o DBA disse que estava fora dos padrões? Claramente, uma aproximação com sucesso de uma regra de negócios devem atender o usuário em primeira mão. Prospecção O problema com o início de uma prospecção de negócio é que não está claro que tipo de regras existem a princípio. É necessário tanto análise quanto desenvolvimento. O analista (Use case analist) procura entender o que o usuário está fazendo e que vocabulário ele usa para descrever seus trabalhos. O desenvolvedor usa estas informações para construir os formulários que definem os tipos de regras de forma a fazer sentido para o usuário. Idealmente um dado tipo de regra pode ser aplicado em diferentes organizações que fazem aquela mesma tarefa mas elas não podem ser relevantes para cada negócio. Codes Generation Routines Black Box process Direct Interpretation of Rules Compiled Programming Languages O processo de geração de código utiliza 3 regras básicas : A. O usuário define a regra em um formato executável; Este modelo é baseado na execução imediata de um processo em uma caixa preta. Exige programação por alguma linguagem. Desaconselhável por sua elevada dependencia de suporte tecnico. Um exemplo prático disto se aplica no gerenciador de Mensagens do Outlook, como visto abaixo.

20 Pag. 20/32 B. O tradutos de regras capturam os metadados; Quando as regras são executadas, o tradutor interpreta os metadados e executam a logica das regras nas informações adquiridas; Nesta aproximação o Business Rules Repository captura as regras do metadado para que o tradutor possa interpretar e criar um codigo executável para os objetos inseridos no Working Memory. O tradutor tem uma rotina para cada tipo de regra por linguagem de programação em que o executável é criado. A vantagem desta implementação é que a implementação de sua execução em DEBUG mode é de baixo custo. A desvantagem é a degradação de sua performance que pode ter um custo significativo em casos de regras muito elaboradas e extensivas. Todavia, extensos volumes de dados estão envolvidos, o tempo de resposta das consultas ao banco de dados é tão elevado que torna despresível a performance do interpretador. Um exemplo prático deste tipo de implementação é a ferramenta Jrules da ILOG.

21 Pag. 21/32 C. O tradutor de regras captura os metadados e usa isto para gerar códigos de programa. Quando as regras são requisitadas, o código é executado. Nesta implementação após a programação das regras e submissão das mesmas ao Repositorio, o usuário, ao imprimir um DEPLOY, as mesmas serão convertidas para um programa que poderá ser eventualmente incorporado ao aplicativo de sua corporação como uma biblioteca de ferramentas ou acessório. A vantagem deste processo é que o codigo, por ser binário, é extremamente rápido e performático. Além disto, por estar totalmente integrado com a solução corporativa com o qual o usuário está acostumado sem exigir a sua alteração, sua aceitabilidade é extremamente maior. A desvantagem é que a implementação de sua execução em DEBUG mode exige um custo de desenvolvimento de custo médio ( cerca de 500 horas ). Outro problema com esta implementação é que pode vir a exigir um custo de integração pós compilação. Em determinados casos, pode não ser totalmente integrada de forma automática. Deve-se considerar que o gerador de código vulnerabiliza a aplicação no que se refere a segurança de execução. Uma vez que o usuário pode recolher os fontes após gerado e copiar e executar em diversas máquinas sem qualquer controle de versionamento ou de licenciamento. Rule Invocation Interface Este modulo implementa a camada de interface entre a aplicação do usuário e do tradutor de regras. Aqui deve-se ter definido todos os formatos e informações relevantes para o entendimento das duas partes envolvidas. De uma forma geral os programas que fizerem acesso ao Business Rules Engine devem conhecer as rotinas para fornecer as informações relevantes, a saber : - Abertura de Sessão : Ao iniciar uma sessão com o Tradutor de regras de negócio, o programa de o faz deve se identificar. Uma vez que o Tradutor de regras de negócio efetua procedimentos de relevante importância ao negócio, seu acesso é restrito a programas autorizados. Esta é uma camada de segurança que permite validar que

22 Pag. 22/32 programa está executando qual regra, auditar e registrar as regras que o programa está executando para um eventual rastreamento de tarefas. - Objetos a serem tratados: O programa que for acessar o Tradutor de regras de negócio deve fornecer os objetos que estarão sujeito a tratamento. Tais objetos são armazenados no repositório de regras em uma área conhecida como agenda e posteriormente disponibilizado para consulta após a execução das regras no Working Memory. Após a execução das regras os objetos excluidos pelas regras não são removidos da Agenda pois eles podem satisfazer a outras regras que eventualmente possam ser executadas em outro momento. Isto significa que se o usuário deve administrar os objetos que foram inseridos na Agenda, podendo removê-los se necessário. Formatos : Os objetos podem serem inseridos nos seguintes formatos : Objetos lógicos de classes java que tem por superclasse java.lang.object ; Collection de objetos lógicos de classes java que tem por interface java.util.collection ; Objetos lógicos ou físicos em formato SOAP ou CORBA ;

23 Pag. 23/32 - Sub-tipos selecionados : Alguns critérios de seletividade aplicaveis em regras são comumente obtidos em formulários em que o usuário seleciona, digita ou especifica algum critério. Estas informações são declaradas com sub-tipos para o Tradutor devendo ser inseridas e alimentadas na Agenda. Uma vez que as mesmas estão referenciadas a algum objeto, os seus formatos de insersão segue o mesmo dos objetos supra-mencionados. - Regras a serem executadas : As regras são agrupadas em pacotes e seus nomes identificados por unicidade, dando assim um formato de identificação único. Desta forma as regras são referenciadas e executadas. A sua execução pode ser realizada de duas formas: Execução interativa ou execução em batch. O primeiro formato permite que se efetue uma requisição de um pacote de regras e aguardar o resultado da mesma para pós-processamento. O segundo formato, muito comum em tarefas extensivas noturnas em ambientes de produção são as execuções em batch ( seguindo as regras de serialização e squedules). A fins de se atender a um grupo de usuários ortodoxos os formatos dos arquivos podem seguir modelos de arquivos de textos pontuais. - Obtendo os resultados : Uma vez executada as regras, os seus resultados podem ser obtidos diretamente por uma sequencia de codigos de status pré-estabelecidos que os processo que executam retornam ou por meio da obtenção dos objetos do Working-Memory contendo em seu interior atributos que eventualmente foram tratados em seus interiores. A fins de se viabilizar a integração com outros ambientes e atender a execução em batch, os objetos do Working Memory assim como o resultado da execução de um Package Rule podem ser escritos em arquivos de disco em formato SOAP ou CORBA.

24 Pag. 24/32 Exemplo J2EE : <jsp:usebean id="eurentinstance" class="rent.eurent" scope="session" /> <jsp:usebean id="customer" class="rent.customer" scope="session" /> <jsp:usebean id="rentalcontract" class="rent.rentalcontract" scope="session" /> <% String rulesetid= "/CRMProjectRuleApp/CustomerLoyalty"; // get stateless rulesession instance IlrStatelessRuleSession rulesession = null; try { rulesession = IlrManagedRuleSessionProvider.getProvider().createStatelessRuleSession(); } catch (ilog.rules.bres.session.ilrrulesessioncreationexception cx) { cx.printstacktrace(); } // pass eurentinstance as "in" parameter of the stateless session. IlrRuleSessionHelper helper = new IlrRuleSessionHelper(); helper.addparameter("eurentinstance", eurentinstance); // execute rules and handle results IlrRuleExecutionResult res = rulesession.executerules(rulesetid, null, helper.getjavaclassresolver(this), helper.getparameters()); %> <%= RuleAppController.getResults(euRentInstance, rent.customer.gold) %>

25 Pag. 25/32 Administrative Tools Repository Rules Set: Edita/Visualiza regras que são usadas em cada processo Working Memory View: Ver colunas/atributos em entidades físicas/logicas que são atualizadas por B.R. Dependency Rules Flow : Ver dependencias entre regras em um mesmo passo do processo de negocio Atribute Rules View: Visualiza que regras um dado atributo/coluna está usando Package RuleSet: Edita/Visualiza todas as regras definidas para um particular tipo de regra (package rule)

26 Pag. 26/32 Relacionamento entre o Sistema (Aplicativos) e o codigo gerado pelo Business Rules Engine O código gerado contém um conjunto de operações que efetuam as regras que foram estabelecidas dentro das condições de contorno apresentadas. Uma vez que o BRE gerou o codigo relacionado ao negócio, é necessário que o mesmo seja anexado ao sistema do cliente, pois a aplicação por si só não é auto-suficiente. Figura 3 : Relacionamento com a aplicação do Sistema principal A interação entre as duas partes define o resultado final da solução aproximada. Por ser um código anexo a aplicação do cliente, é possível que seja feito implementações parciais desde que seja respeitado a fronteira do código automático que não deve ser manipulado pelo cliente sob pena de comprometer as execuções corretas das regras e o controle de versão.

27 Pag. 27/32 MODELAGEM DOS DADOS APPLICATION DATABASE METADATA A palavra Metadata significa a representação de dados que diz algo sobre os dados do negócio. Os modelos de dados são tipicamente construido com base em conceitos de teoria de banco de dados relacional. Na prática isto significa que uma informação é desmenbrada em pedaços e cada pedaço da informação é agrupada junto com informações similares. E os agrupamentos podem compartilhar pedaços comuns de informação. Estes objetos são descobertos, identificados, classificados, gravados e estruturados em um desenho de um processo chamado modelagem de dados que é parte ciencia e parte arte. É parte ciencia porque existem regras específicas na construção das entidades e parte arte porque requer a extração das partes corretas e completas do usuário ( o que não é tão fácil ). Atributos e Entidades Campo e coluna Tabela ou Entidade Relacionamento ( Pai x Filho ) - Cardinalidade ; - Subtipos ou sub-domínios ; Caminho

28 Pag. 28/32

29 Pag. 29/32 COMPONENTES DO SISTEMA O BRE é um sistema complexo que possue um módulo principal chamado Business Rules Engine Framework. Erro! Nenhum tópico foi especificado. Figura 4 : Software Application Approach Este módulo tem por função básica gerenciar outros módulos verificando sua presença, recursos disponíveis e versão, carregar/descarregar da memória quando necessário, gerenciar linguagem e framework, gravar objetos e versionar projetos e regras. Os módulos que se desmembram do mesmo são : Database Designer Este módulo tem por finalidade editar, popular e gerenciar o Application DataBase Metadata com os dados das tabelas físicas do sistema a ser analisado. É uma ferramenta que possui as funções semelhantes ao IRWIN, porém suas entidades são : - Grupamento de tabelas; - Tabelas; - Colunas (campos); - Relacionamentos; - Caminhos; Possuem tanto o modelo físico quanto o lógico. É relevante que tenha capacidade de importar arquivos em formato CVS e XML no formato do IRWIN v4.1 e que possa fazer engenharia reversa no DataBase do sistema. Business Designer Este módulo é responsável pela importação das entidades representativas dos objetos do tipo java (*.class) e dos layout dos documentos XML SOAP/CORBA. Após a importação, o módulo deve permitir que o usuário possa facilmente editar a tradução dos objetos para nomes lógicos. Deve-se permitir que o usuário possa também criar os caminhos entre objetos. Form Designer

30 Pag. 30/32 Este modulo é responsável pela construção dos formulários e organizar os objetos de forma a permitir a sua criação em diferentes ambientes/linguagens. É constituido dos seguintes módulos : - Form Designer Wizard for Business Rules Analyst; Este modulo é constituido de uma interface capaz de construir /editar formulários constituindo seus elementos de entidades ou objetos sem qualquer recursos de layout. É também capaz de criar regras da categoria formulário relacionados a eventos do tipo { OnShow, OnFocus, OnExit, OnEnter, OnClick, OnBblClick } para cada um dos objetos criados. Considera-se o formulário como um objeto também, assim como os sub-formulários que a ele pertencem. Ele deve ter inteligencia para criar os links entre entidades automaticamente, carregar o RuleTypesManager para construção de regras, armazenar e organizar os dados; - Form Designer HTML Loader Este é um método poderoso capaz de ler arquivos em formato HTML, capturar os objetos relevantes e seus links para outras páginas e automaticamente construir objetos do tipo FORM no FormDesigner com vinculos abastratos e definições em branco; - Form Designer for Web Designer Este modulo embora tenha a mesma cara que a interface anterior, possui recursos gráficos visuais a fins de tratar os objetos criados na interface anterior. Não tem permissão para alterar as regras ou remover objetos; - Form Designer for Data Annalist Este modulo permite que o analista de dados possa relacionar os atributos e objetos lógicos e físicos, criando assim uma intergidade lógica/física nos elementos cosntruidos. - X-Object Interface translator Este modulo é responsável pela definição dos objetos envolvidos em uma Package Rule. Ele deve ser capaz de implementar um conjunto de classes de interface ou um objeto no formato XML encapsulando os dados envolvidos. Quando o formulario for gerado pelos módulos do FormDesigner, o xobject não é requerido pois o próprio FormDesigner já gera o xobject Interface necessário para a chamada da regra. Este modulo também é responsável pela construção de um Framework que permita popular campos de formulários a partir um documento XML recebido do Business Rule Engine, devendo ser capaz de gerar um documento XML no formato de um objeto de

31 Pag. 31/32 classe conhecida pelo Business Rules Repository e executar um Package Rule específico a fins de resolver o documento. Business Rules Repository Trata-se do Kernel da arquitetura da aplicação. Embora este modulo não tenha ação interativa direta com o usuário, ele deve ser definido com conceitos claros e bem distintos e padronizados a fins de que não haja re-escrita do código posteriormente. É constituido dos seguintes componentes : - Application Data Base Metadata ; - Rule Definition; - Decision Tree/ Decision Table; - Business Process; Definições conceituais São módulos que integram a ferramenta na contrução do objeto final de uso, a saber, o código fonte e seus elementos. É dividido nos seguintes módulos : - Rule invocation interface; - Code generation routines; São processos que tem por finalidade ler o Repositorio e construir o codigo. - Executable business rules; São formado por formulários, classes, processos e arquivos de configuração e adcionais requerido pela linguagem e arquitetura requerida. Rules Type Manager/Deploy Este modulo é constituido de duas partes distintas. Uma parte fixa, e portanto sem intervenção do desenvolvedor de Business Rules, pré-determinada, que efetua o tratamento de regras básicas e extendidas. A segunda parte efetua o tratamento de regras programáveis sendo armazenadas e editaveis em uma Template Package Library do desenvolvedor de Business Rules. As categorias extendidas compreendem : - Math Pack (LOG, COS,SIN,FACT,INT,MIN,MAX,SUM,MOD,PI,ROUND, ); - Logical Pack (EXIST, NOT, ); - Financial Pack (Rate, Media, PPV, ProRata, )

32 Pag. 32/32 - Date Pack ( NumDays, TodayDate, Now, Yesterday, Time, Second, ) Ela tem uma participação importante no Code Generation Routines pois é responsável em dar a forma as funções que executarão as regras que foram escritas. O Manager deste módulo é um sub-item do Rule Definition Interface, para editar o Template Package Library do desenvolvedor de Business Rules. O Deploy deste módulo está no Code Generation Routines e tem a função de compilar os dados ro Repositorio com os Rules Types e construir o código executável. Rule Definition Interface Sua principal tarefa é permitir a edição e construção das regras. Sejam elas de forms de negócio ou físicas. Para que seja possível a construção, ela deve ter acesso a todos os outros módulos a fins de poder instanciar os objetos pertinentes a medida que o analista de negócio (usuário) for construindo as regras. Administrative TOOLS As ferramentas administrativas tem por objetivo depurar os processos que foram construidos ou executados. Sua importancia é extremamente relevante tanto para no momento de desenvolvimento das regras de negócio quanto no momento de auditoria das regras executadas em produção.