Um sistema que incorporou um mecanismo de regras já foi VERDADEIRAMENTE bem-sucedido?[fechado]

Question

Nosso sistema (captura de comércio de derivativos de commodities exóticas e gerenciamento de risco) será redesenvolvido em breve.Uma proposta que ouvi é que um mecanismo de regras seja incorporado para tornar mais fácil para os usuários finais (comerciantes de commodities, bastante sofisticados) fazer certas mudanças na lógica de negócios.

Sou um pouco cético em relação aos mecanismos de regras.O agilista que há em mim se pergunta se eles são apenas uma solução técnica para um problema de processo...ou seja.leva muito tempo para nossos desenvolvedores responderem à necessidade de mudança do negócio.A solução para esse problema deveria ser uma abordagem de desenvolvimento mais colaborativa, melhor cobertura de testes e práticas mais ágeis em todos os aspectos.

Ouvir sobre situações em que um mecanismo de regras era realmente uma vantagem (especialmente em um ambiente de negociação) certamente seria útil.

Answer 1

Vi duas aplicações que usaram o mecanismo Blaze Rete da Fair Issac.

Um aplicativo bateu milhares de regras em uma única base de conhecimento, teve terríveis problemas de memória, tornou -se uma caixa preta que poucos entendem. Eu não chamaria isso de sucesso, mas está sendo executado em produção.

Outro aplicativo usou árvores de decisão para representar da ordem de centenas de perguntas em um formulário médico para disposição dos clientes. Foi feito com tanta elegância que os empresários podem atualizar as regras conforme necessário, sem ter que envolver um desenvolvedor. (Ainda precisa ser implantado por um.) Eu chamaria isso de grande sucesso.

Portanto, depende de quão bem o problema é o problema, o tamanho do conjunto de regras, o conhecimento dos desenvolvedores. Meu preconceito é que simplesmente fazer de um mecanismo de regras um único ponto de falha e dumping regras nele provavelmente não é uma boa abordagem. Eu começaria com uma abordagem orientada a dados ou orientada por dados e cultivava isso até que um mecanismo de regras fosse necessário. Eu também me esforçaria para encapsular o mecanismo de regras como parte do comportamento de um objeto. Eu escondia o mecanismo de regras dos usuários e tentava particionar o espaço das regras no modelo de domínio.

Answer 2

Não sei se eu diria que eles são realmente um benefício, mas acho que eles certamente podem ser valiosos. Trabalhei em um sistema por alguns anos no setor de seguros, onde um mecanismo de regras foi empregado com sucesso para permitir que os usuários de negócios criassem regras que determinaram quais políticas eram legais, dependendo do estado.

Por exemplo, se você tivesse que ter um copay em certos estados, ou certas combinações de dedutível e copay não fossem permitidas, nem por considerações do produto ou porque era simplesmente ilegal devido à lei estadual.

O número de estados em que a empresa operava, juntamente com a constante mudança nas regras (trimestralmente), tornaria isso uma prática estonteante de codificação. Mais importante, não está na experiência de um programador. Ele acrescenta comunicação inútil extra, onde o usuário final está descrevendo a regra a ser colocada em vigor a um programador que não é um especialista do setor de seguros como é.

Projetado corretamente, um mecanismo de regras ainda pode ativar um sistema de fluxo de trabalho que permite bons testes. Nesse caso, as regras foram armazenadas em um banco de dados e havia bancos de dados de controle de qualidade e Prod. Assim, os BAs poderiam testar suas regras no controle de qualidade e depois promovê -las para produzir.

Como em qualquer coisa, geralmente é sobre a implementação, e não a técnica real.

Answer 3

Sim, a Microsoft possui um mecanismo de regras de negócios (BRE) no BizTalk que é usado com sucesso há anos. Ouvi dizer que eles tiveram clientes comprar biztalk (muito caro) apenas para o BRE.

Na minha experiência, a praticidade de atualizar um usuário de negócios das regras é fino para nenhuma. Geralmente é preciso uma pessoa técnica para trabalhar o editor de regras de negócios.

Answer 4

Um mecanismo de regra é pouco mais do que algo que executa declarações declarativas. Eles vêm com duas vantagens principais (que eu vejo):

1. Sua lógica de negócios é mantida em um único local, em vez de ser espalhado pelo código do aplicativo. Tecnicamente, um aplicativo bem projetado já deve fazer isso com a arquitetura, independentemente de um mecanismo de regra estar presente ou não.
2. Você precisa se preocupar [menos] sobre dependências entre declarações declarativas. O mecanismo de regra deve ser inteligente o suficiente para decidir o pedido para executar regras com base em dependências. Você pode achar que alguns mecanismos de regra apóiam uma ordem seqüencial de regras em um conjunto de regras ou regras de chamada (grupos de regras) em uma ordem específica, mas isso não está realmente no espírito de programação declarativa. Muitos mecanismos de regra usam RETE (um algoritmo) para decidir quando agendar a execução de declarações declarativas.

Suspeito que a maioria dos motores de regra, se não todos, adicione mais despesas gerais do que se você escrevesse o melhor programa possível que não use um mecanismo de regra. Isso é semelhante à forma como a redação do código na montagem é geralmente mais rápida que um compilador (mas você geralmente não escreve montagem porque é mais conveniente e produtivo usar abstrações de nível superior).

Se você parasse por aqui, provavelmente usaria programadores para manter as regras e usar um mecanismo de regra como uma maneira conveniente de criar uma camada lógica de negócios em seu aplicativo. Alguns motores de regra oferecem algo chamado modelos que permitem definir modelos para regras. A vantagem aqui é que os usuários não técnicos devem ser capazes de escrever suas próprias regras e modificar as regras existentes.

Um mecanismo de regra é mais uma ferramenta no baú da ferramenta que, quando usada corretamente, pode ser valiosa.

Answer 5

O problema com muitos desses mecanismos de regra é a falta de velocidade e o fato de que a substituição ou o aumento das regras pode quebrar as regras de trabalho existentes de maneiras sutis. Portanto, você ainda precisa testar o sistema completamente após cada mudança de regra. Então, você está basicamente apenas trocando uma linguagem de computador por outro - uma com uma base muito menor de usuários. Como outro pôster mencionado, ainda não vi um analista de negócios usar um mecanismo de regra com sucesso. Você precisa de um programador de qualquer maneira.

Answer 6

Eu certamente tenho, mas não posso falar publicamente sobre eles, mas é provável que você tenha interagido com várias vezes este ano;)

Eu vejo isso em 2 campos: os programadores lógicos e os usuários de negócios. Diferentes ferramentas têm como alvo conjuntos diferentes, alguns. Os casos bem -sucedidos de usuários de negócios só funcionaram quando era um subconjunto da lógica e também tinham uma maneira de definir casos de teste e executá -los (e estão preparados para pensar logicamente). Os programadores lógicos são mais raros, mas geralmente podem ser encontrados provenientes de fundos de programação não imperativos (eles também são o tipo de pessoas que acham intuitiva de programação funcional).

Lembre -se do final do dia, mesmo com ferramentas visuais, se você estiver dizendo a um computador para fazer algo que ainda está programando.

Answer 7

Eu trabalho com muitos fornecedores no espaço e uma das grandes coisas disso é que converso com muitos de seus clientes. Então, sim, centenas de empresas têm exatamente Os benefícios que foram prometidos - maior agilidade, melhor colaboração de negócios/TI, conformidade regulatória mais fácil, melhor consistência da tomada de decisão, custos de manutenção mais baixos, tempos mais rápidos no mercado etc.

Repetidas vezes, em todos os principais fornecedores e jogadores de código aberto, vejo isso usado corretamente - para automatizar e melhorar as decisões operacionais de alto volume com muitas regras, regras que mudam muito, regras que interagem de maneiras complexas ou regras com Um conteúdo de alto domínio de negócios - sistemas de gerenciamento de regras de negócios funcionam.

Sério.

Answer 8

Minha experiência é limitada a (i) não muito e (ii) prolog; Mas posso dizer com segurança que um mecanismo de regra pode ajudá -lo a expressar conceitos proposicionais muito mais limpos que o código processual.

Answer 9

Os mecanismos de regras são usados ​​rotineiramente no negócio de seguros.Trabalhei em sistemas com centenas (600) de regras que foram implementadas em um mecanismo de regras.Funcionou muito bem.

Answer 10

Você tem uma classificação de crédito? UMA FICO pontuação, talvez? Isso é Far EUSaac CoRporation, os desenvolvedores do mecanismo de regras do Blaze.

Answer 11

Por um tempo, trabalhei para o projeto de computação distribuído de Peate, que estava desenvolvendo um sistema para o cálculo de dados atmosféricos em larga escala e alto volume. O sistema tinha três partes: o gerenciador de dados, o agendador e o componente de execução do algoritmo. Pode haver qualquer um desses componentes, todos feitos por meio de serviços da Web, mas o que permitia era que diferentes pesquisadores executassem empregos arbitrários contra dados arbitrários e também permitissem que diferentes mecanismos de agendamento fossem conectados à medida que os requisitos foram alterados.

Deixei o projeto antes de chegar muito longe do chão, mas isso parece que poderia se encaixar no cenário e servir como outro exemplo para algum tipo de mecanismo de regras. Dito isto, no entanto, se os desenvolvedores originais ainda serão os que estão fazendo os algoritmos para executar, não consigo ver muito benefício em ter um mecanismo de regra, a menos que ele lidasse com uma sobrecarga substancial que cada regra ou algoritmo incorreria em é o próprio.

Isso parece um pouco mais envolvido do que um simples mecanismo de regra, mas essa arquitetura também pode se aplicar com um mecanismo de regra.