Un sistema che ha incorporato un motore di regole ha mai avuto un vero successo? [chiuso]

StackOverflow https://stackoverflow.com/questions/206425

  •  03-07-2019
  •  | 
  •  

Domanda

Il nostro sistema (acquisizione di derivati ??di materie prime esotiche e gestione del rischio) verrà presto riqualificato. Una proposta che ho sentito è che verrà incorporato un motore di regole per rendere più semplice agli utenti finali (commercianti di materie prime, così sofisticati) apportare alcune modifiche alla logica aziendale.

Sono un po 'scettico nei confronti dei motori delle regole. L'agilista in me si chiede se siano solo una soluzione tecnica a un problema di processo ... vale a dire. ci vuole troppo tempo perché i nostri sviluppatori rispondano alla necessità di cambiamento dell'azienda. La soluzione a questo problema dovrebbe essere un approccio più collaborativo allo sviluppo, una migliore copertura dei test, pratiche più agili dappertutto.

Sentire parlare di situazioni in cui un motore di regole era davvero un vantaggio (specialmente in un ambiente commerciale) sarebbe sicuramente utile.

È stato utile?

Soluzione

Ho visto due applicazioni che utilizzavano il motore Blaze Rete di Fair Issac.

Un'applicazione ha bloccato migliaia di regole in un'unica base di conoscenza, ha avuto problemi di memoria terribili, è diventata una scatola nera che pochi capiscono. Non lo definirei un successo, ma è in produzione.

Un'altra applicazione ha utilizzato alberi delle decisioni per rappresentare nell'ordine di centinaia di domande su un modulo medico per i clienti disposti. È stato fatto in modo così elegante che gli uomini d'affari possono aggiornare le regole secondo necessità, senza dover coinvolgere uno sviluppatore. (Tuttavia, deve ancora essere distribuito da uno.) Definirei un grande successo.

Quindi dipende da quanto è ben focalizzato il problema, dalle dimensioni del set di regole, dalla conoscenza degli sviluppatori. Il mio pregiudizio è che il semplice fatto di trasformare un motore di regole in un singolo punto di errore e di scaricare regole in esso probabilmente non è un buon approccio. Comincerei con un approccio basato sui dati o sulla tabella e lo svilupperei fino a quando non fosse necessario un motore di regole. Mi impegnerei anche a incapsulare il motore delle regole come parte del comportamento di un oggetto. Nasconderei il motore delle regole agli utenti e proverei a partizionare lo spazio delle regole nel modello di dominio.

Altri suggerimenti

Non so se direi che sono mai stati davvero un vantaggio, ma penso che possano sicuramente essere preziosi. Ho lavorato su un sistema per alcuni anni nel settore assicurativo, dove un motore di regole è stato impiegato con successo per consentire agli utenti aziendali di creare regole che determinavano quali politiche fossero legali, a seconda dello stato.

Ad esempio, se si doveva avere un copay in determinati stati, o determinate combinazioni di franchigia e copay non erano consentite, sia per considerazioni sul prodotto, sia perché era semplicemente illegale a causa della legge statale.

Il numero di stati in cui la società ha operato, insieme al costante cambiamento delle regole (trimestrale) renderebbe questa pratica vertiginosa di codifica. Ancora più importante, non è nelle competenze di un programmatore. Aggiunge ulteriori comunicazioni inutili in cui l'utente finale sta descrivendo la regola da applicare a un programmatore che non è un esperto del settore assicurativo come loro.

Progettato correttamente, un motore di regole può ancora abilitare un sistema di flusso di lavoro che consente buoni test. In questo caso, le regole sono state archiviate in un database e c'erano database di QA e PROD. Quindi i BA potrebbero testare le loro regole nel QA e poi promuoverle in PROD.

Come per qualsiasi cosa, di solito riguarda l'implementazione e non la tecnica reale.

Sì, Microsoft ha un Business Rule Engine (BRE) in BizTalk che è stato usato con successo per anni. Ho sentito che hanno avuto clienti che acquistano BizTalk (molto costoso) solo per BRE.

Nella mia esperienza, la praticità di far aggiornare le regole a un utente aziendale è praticamente nulla. Di solito serve una persona tecnica a lavorare nell'editor delle regole di business.

Un motore di regole è poco più di qualcosa che esegue dichiarazioni dichiarative. Vengono con due vantaggi principali (che vedo):

  1. La logica aziendale viene gestita da un unico punto anziché essere cosparsa nel codice dell'applicazione. Tecnicamente, un'applicazione ben progettata dovrebbe già farlo con l'architettura, indipendentemente dal fatto che sia presente o meno un motore di regole.
  2. Devi preoccuparti [meno] delle dipendenze tra dichiarazioni dichiarative. Il motore delle regole dovrebbe essere abbastanza intelligente da decidere l'ordine di eseguire le regole in base alle dipendenze. Potresti scoprire che alcuni motori di regole supportano un ordinamento sequenziale di regole all'interno di un set di regole o che chiamano set di regole (gruppi di regole) in un ordine particolare, ma questo non è proprio nello spirito della programmazione dichiarativa. Molti motori di regole utilizzano Rete (un algoritmo) per decidere quando pianificare l'esecuzione delle dichiarazioni dichiarative.

Sospetto che la maggior parte, se non tutti, i motori di regole aggiungano più sovraccarico che se dovessi scrivere il miglior programma possibile che non utilizza un motore di regole. Questo è simile al modo in cui scrivere codice nell'assembly è generalmente più veloce di un compilatore (ma di solito non si scrive assembly perché è più conveniente e produttivo usare astrazioni di livello superiore).

Se dovessi fermarti qui, probabilmente useresti i programmatori per mantenere le regole e usare un motore di regole come un modo conveniente per costruire un livello di logica aziendale nella tua applicazione. Alcuni motori di regole offrono qualcosa chiamato modelli che consente di definire modelli per le regole. Il vantaggio qui è che gli utenti non tecnici dovrebbero essere in grado di scrivere le proprie regole e modificare le regole esistenti.

Un motore di regole è un altro strumento nella tua cassetta degli attrezzi che, se usato correttamente, può essere prezioso.

Il problema con molti di questi motori di regole è la mancanza di velocità e il fatto che la sostituzione o il potenziamento delle regole possono violare le regole di lavoro esistenti in modo sottile. Quindi devi ancora testare nuovamente il sistema dopo ogni cambio di regola. Quindi sostanzialmente stai scambiando un linguaggio di computer con un altro - uno con una base di utenti molto più piccola. Come menzionato da un altro poster, devo ancora vedere un analista aziendale utilizzare con successo un motore di regole. Hai comunque bisogno di un programmatore.

Certamente, ma non posso parlarne pubblicamente, ma è probabile che tu abbia interagito con uno più volte quest'anno;)

Lo vedo in 2 campi: i programmatori logici e gli utenti aziendali. Diversi strumenti prendono di mira set diversi, alcuni entrambi. I casi di successo degli utenti aziendali hanno funzionato solo quando era un sottoinsieme della logica e avevano anche un modo per definire i casi di test ed eseguirli da soli (e sono pronti a pensare logicamente). I programmatori di logica sono più rari, ma spesso si trovano che provengono da background di programmazione non imperativi (sono anche il tipo di persone che trovano intuitiva la programmazione funzionale).

Tieni a mente alla fine della giornata anche con strumenti visivi, se stai dicendo a un computer di fare qualcosa che sta ancora programmando.

Lavoro con molti venditori nello spazio e una delle cose grandiose di questo è che posso parlare con molti dei loro clienti. Quindi, sì, centinaia di aziende hanno ottenuto esattamente i vantaggi che erano stati promessi: maggiore agilità, migliore collaborazione business / IT, maggiore conformità normativa, migliore coerenza decisionale, minori costi di manutenzione, tempi di immissione sul mercato più rapidi ecc.

Più e più volte, tra tutti i principali fornitori e i player open source, vedo che usato correttamente - per automatizzare e migliorare le decisioni operative ad alto volume con molte regole, regole che cambiano molto, regole che interagiscono in modi complessi o regole con un contenuto di dominio aziendale elevato - i sistemi di gestione delle regole aziendali funzionano.

Davvero.

La mia esperienza è limitata a (i) non molto e (ii) prolog; ma posso tranquillamente dire che un motore di regole può aiutarti a esprimere concetti proposizionali molto più chiari del codice procedurale.

I motori delle regole vengono abitualmente utilizzati nel settore assicurativo. Ho lavorato su sistemi con centinaia (600) regole che sono state implementate in un motore di regole. Ha funzionato molto bene.

Hai un rating del credito? Un punteggio FICO , forse? Questa è la F aria I saac CO , gli sviluppatori del motore delle regole di Blaze.

Per un po 'ho lavorato per il progetto di calcolo distribuito PEATE che stava sviluppando un sistema per il calcolo di dati atmosferici su larga scala e ad alto volume. Il sistema aveva tre parti: il gestore dei dati, lo scheduler e il componente di esecuzione dell'algoritmo. Potrebbe esserci un numero qualsiasi di questi componenti, tutti eseguiti tramite servizi Web, ma ciò che ha permesso è stato per diversi ricercatori di eseguire lavori arbitrari contro dati arbitrari, e ha anche permesso di collegare diversi meccanismi di pianificazione al variare dei requisiti.

Ho lasciato il progetto prima che fosse troppo lontano da terra, ma sembra che potrebbe adattarsi allo scenario e servire da altro esempio per un qualche tipo di motore di regole. Detto questo, tuttavia, se gli sviluppatori originali continueranno a essere gli stessi a far funzionare gli algoritmi, non vedo troppi benefici nell'avere un motore di regole a meno che non gestisca un notevole sovraccarico che ogni regola o algoritmo dovrebbe sostenere è proprio.

Sembra un po 'più coinvolto di un semplice motore di regole, ma tale architettura potrebbe applicarsi anche a un motore di regole.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top