Dove memorizzo le regole aziendali definite dall'utente?

Sono sicuro che tu abbia già visto e forse usato questa funzionalità: ogni client email decente consente a un utente di definire regole di filtro personalizzate selezionando alcuni modelli di regole, aggiungendo alcune condizioni e parametri e poi facendo in modo che le regole vengano eseguite automaticamente ogni volta arriva una nuova email Quindi questo è in realtà un modo posible (di molti ) come implementare un tale sistema.

Quindi sì, non c'è nulla di speciale nell'avere un sistema con regole e regole personalizzate. Tuttavia, vi è una vasta gamma di opzioni e gradi di libertà in questo, a partire da alcune semplici regole parametriche da cui un utente può scegliere fino a un interprete integrato completo, con un linguaggio di programmazione standard o specifico per le regole di implementazione, forse basato su un motore di regole generico.

I gradi di libertà sono in genere correlati allo sforzo di sviluppo e alla pendenza della curva di apprendimento per gli utenti. Quindi non esiste una soluzione adatta a questo, è necessario analizzare la quantità di flessibilità di cui gli utenti hanno bisogno e "più flessibile" non è necessariamente migliore, perché spesso significa "più difficile da imparare". Se i tuoi utenti desiderano una certa flessibilità per la logica di business, scopri quanta flessibilità hanno realmente bisogno e quanto impegno sono disposti a investire per imparare come definire regole e regole complesse da soli.

Ci sarà inevitabilmente un compromesso con questo. Se vuoi offrire all'utente flessibilità illimitata per definire regole complesse al volo, allora quello che devi fare è creare un linguaggio di programmazione specifico per il dominio all'interno della tua applicazione, che richiederà di scrivere qualcosa che possa analizzare questo. Questo non è un lavoro piccolo.

Tuttavia, è possibile che questo livello di controllo sia eccessivo. I tuoi utenti potrebbero accontentarsi di:

1. Definisci attributi (ad es. HAS_5_YEARS_EXPERIENCE o SPEAKS_SPANISH o IS_CONVICTED_FELON)
2. Assegna un numero qualsiasi di questi attributi a ciascun dipendente
3. Specifica le regole personalizzate per ogni reparto (ad esempio REQUIRES: SPEAKS_SPANISH o FORBIDDEN: IS_CONVICTED_FELON)

Questa è un'impresa molto più semplice.

Userei un motore di regole come Drools (Java). I motori di regole hanno fondamentalmente due scopi. Uno: eseguono le regole che hanno memorizzato (cioè determinano a quali dipartimenti appartiene un dipendente). Tqo: forniscono un modo per modificare le regole in fase di esecuzione. I motori di regole sono dinamici per definizione. Sembra che si adatti perfettamente al tuo scenario!

Puoi memorizzare le tue regole in OWL + RDF , uno standard di linguaggio web semantico del W3C. OWL può rappresentare una logica di descrizione (vedi questa presentazione di Ian Horrocks , e "Un semantico web primer "di Grigoris Antoniou, Paul Groth, Frank van Harmelen e Rinke Hoekstra . Consente di definire un'ontologia su dipendenti, dipartimenti e qualifiche professionali e ragionare all'interno di questa ontologia. per definire le proprietà e il significato di queste proprietà, per definire i requisiti dei vari reparti, memorizzare le qualifiche dei dipendenti.

Con una certa conoscenza della rappresentazione della conoscenza puoi cambiare e aggiungere proprietà, cambiare le regole per i dipartimenti, ecc.

Successivamente puoi usare i ragionamenti OWL esistenti (come Apache Jena , OpenLink Virtuoso , negozio RDF AllegroGraph e pellet )

Utilizzando il ragionatore, l'ontologia che hai definito e il tuo database di dipendenti e dipartimenti puoi trovare la classe di impiegati che soddisfano tutte le proprietà richieste per lavorare per il dipartimento x.

All'interno della famiglia di strumenti web semantica esistono i ragionatori OWL, gli archivi tripli RDF (OWL è spesso memorizzato come RDF) e gli editori della knowledge base.

L'utilizzo di un motore di regole come Drools è già stato menzionato.

Lasciare una gran parte della configurazione agli utenti finali presenta un inconveniente tipico rispetto alla manutenzione della programmazione:

• Le modifiche hanno un effetto immediato sul sistema di produzione in corso;
• Il controllo delle versioni è assente;
• Il design è ad-hoc;
• La documentazione è assente;
• Un utente finale non è abituato alla "logica" di un sistema software.

Quindi è richiesto uno sviluppo sufficiente ed estremamente attento.

Crea una progettazione dettagliata, con storie dettagliate: interfacce utente finali.

Solo dopo aver soddisfatto i requisiti tecnici, una concezione tecnica, cerca lo / gli strumento / i corretto / i. Quindi i tempi di sviluppo sono distribuiti proporzionali alle parti del carico di lavoro.

Un avvertimento: non memorizzare dati complessi (centinaia di nodi grafici) in diverse tabelle di database, quando tali dati sono come un documento; memorizzare meglio tali dati come XML in una singola tabella (JAXB). È meglio se si può passare da un grafico all'altro, invece di avere tutto distribuito - anche con JPA.

Un'altra nota: questo software dovrebbe tipicamente assistere nella pianificazione, non necessariamente essere prescrittivo. Il cliente spesso vuole solo ottimizzare, fare cose veloci e imparziali. Ciò significa che le eccezioni manuali dovrebbero probabilmente essere gestite e documentabili.