Costruire motori di regole aziendali con la bava - Potenza per le PMI

Una delle cose più sorprendenti del lavoro nello sviluppo di software è la capacità di lavorare in molti settori diversi, specialmente se sei un consulente. La maggior parte delle abilità di sviluppo software che si apprendono lavorando all'interno di un settore sono direttamente trasferibili a un numero qualsiasi di altri settori, aziende, progetti e nicchie.

Sto parlando di argomenti come la progettazione di database, modelli di progettazione, layout della GUI, gestione degli eventi, ecc. Poi, naturalmente, ci sono argomenti specifici per un particolare settore, azienda o progetto.

La PMI incontra l'IT, inizia il trasferimento delle conoscenze

È qui che entra in gioco l'Esperto in materia (PMI). Una PMI sarà in genere molto coinvolta nella fase di progettazione del progetto.

La PMI ha lavorato nel settore per un lungo periodo di tempo, conosce il gergo e comprende la logica aziendale dietro la codifica. La PMI può avere una certa comprensione dello sviluppo del software, ma ciò non è necessario per il successo del progetto.

Per molti progetti, a meno che lo sviluppatore di software non abbia una grande comprensione della logica aziendale, completare un'applicazione software di successo sarà relativamente difficile. La quantità di tempo da dedicare al trasferimento delle conoscenze varierà ampiamente in base alla complessità del progetto.

Supponendo che venga adottato un approccio agile e che una o più PMI siano disponibili durante la fase di sviluppo del progetto, il trasferimento delle conoscenze continuerà durante tutte le fasi del progetto.

Cosa succede se il trasferimento completo delle conoscenze non è fattibile?

A seconda del settore e del progetto, una PMI potrebbe non essere in grado di fornire un trasferimento completo delle conoscenze.

Ad esempio, immagina se la PMI è un medico con 25 anni di esperienza e hai 6 mesi per completare un progetto. Oppure, immagina la PMI come una biologa con 40 anni di esperienza: un tale livello di conoscenza semplicemente non può essere trasferito in un lasso di tempo realistico per i progetti di sviluppo software.

Ma cosa succede se l'area della conoscenza è dinamica?

In genere, il software viene rilasciato in base a una pianificazione prestabilita in base al tempo o alle funzionalità. Tuttavia, le regole aziendali all'interno di alcuni settori cambiano molto più frequentemente.

In molti casi, potrebbe non essere fattibile rilasciare software tutte le volte che è necessario per stare al passo con i cambiamenti del settore. Avere la capacità di esternalizzare le regole di business all'interno di un motore di regole di business può avere senso in tali scenari. La capacità di un progetto software di resistere al cambiamento contribuirà notevolmente a garantirne il successo finale a lungo termine.

Quando e dove hanno senso i motori delle regole?

Per molti progetti software, è possibile che avvenga il trasferimento completo delle conoscenze e che la logica aziendale sia codificata in un linguaggio informatico come C# o Java.

Tuttavia, esiste un sottoinsieme di progetti in cui la quantità di comprensione di un argomento specifico è così ampia o le regole aziendali sono soggette a così tante modifiche che ha più senso per un non programmatore avere accesso diretto alla logica aziendale. Questo è l'argomento di questo tutorial; con questo in mente, discutiamo in modo approfondito i motori delle regole.

Che cos'è un motore di regole aziendali?

Un motore di regole è uno strumento per l'esecuzione di regole aziendali. Le regole aziendali sono composte da fatti e dichiarazioni condizionali. Qualsiasi istruzione "se-allora" che appare nella logica aziendale tradizionale si qualifica come regola aziendale.

Ad esempio: se un dipendente è in malattia per più di 5 giorni consecutivi e non ha un certificato medico, è necessario scriverlo. Se un socio in affari non è stato contattato per più di 6 mesi e non ha effettuato acquisti durante quel periodo, potrebbe essere il momento di inviargli un'e-mail cordiale. Se un paziente ha una temperatura corporea elevata, problemi di vista e c'è una storia familiare di glaucoma, potrebbe essere il momento di richiedere un'ulteriore risonanza magnetica o altri test.

In che modo le PMI scrivono le regole aziendali?

Invece di aspettarsi che una PMI impari Java, C# o un altro linguaggio di programmazione, l'IT creerà un mini-linguaggio per esprimere le proprie regole di business. Gli elementi costitutivi di queste regole consisteranno in fatti che possono essere richiesti. Alcuni esempi di fatti per settore/settore di attività sono:

• Risorse umane: stipendio, posizione, manager, anni in azienda
• Medico: temperatura, pressione sanguigna, farmaco attuale
• Finanziaria: prezzo attuale delle azioni, prezzo massimo/minimo in 52 settimane, rapporto P/E, data del prossimo rilascio degli utili

In sostanza, le informazioni necessarie per prendere decisioni aziendali devono essere disponibili alla PMI in modo snello.

Che aspetto hanno queste regole?

Per il resto di questo tutorial sul motore di regole, userò Drools, un motore di regole basato su Java open source, che può essere trovato su www.drools.org ed è un progetto JBoss. In Drools, le regole sono scritte come codice Java e hanno la seguente struttura:

Le dichiarazioni di importazione vanno qui:

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Sbavature e memoria di lavoro

Drools utilizza un concetto chiamato Working Memory.

Il codice dell'applicazione sarà responsabile del caricamento di fatti appropriati nella memoria di lavoro in modo che le PMI possano scrivere regole che interroghino questi fatti. Solo i fatti rilevanti per la logica aziendale dell'applicazione devono essere caricati nella memoria di lavoro, al fine di mantenere il motore delle regole in esecuzione alla massima velocità.

Ad esempio, se una domanda sta determinando se approvare un cliente per un prestito, i fatti rilevanti includerebbero lo stipendio, i punteggi di credito e i prestiti in sospeso. I fatti non rilevanti includerebbero il giorno della settimana o il sesso.

Valutazione delle regole

Dopo che Drools Working Memory è stato caricato con regole e fatti, le regole vengono valutate in base alla parte "allora" della loro regola. Se la parte "allora" restituisce true, verrà eseguita la parte "quando" della regola.

In genere, tutte le regole vengono valutate contemporaneamente, sebbene le regole possano essere raggruppate e valutate per gruppo. La parte "allora" della regola può modificare il contenuto della memoria di lavoro. Quando ciò si verifica, Drools rivaluta tutte le regole per vedere se alcune regole ora vengono valutate come true. In tal caso, le loro parti "quando" verranno eseguite.

Questa natura ricorsiva delle valutazioni delle regole può essere una benedizione o una maledizione, quindi le regole devono essere create tenendo presente questa architettura.

Il lato "se" di una regola sbava

In Drools i fatti sono rappresentati da oggetti. È possibile richiedere l'esistenza o la non esistenza di un tipo di oggetto. Inoltre, è possibile eseguire query anche sugli attributi dell'oggetto.

Ecco alcuni esempi:

Determina se un dipendente guadagna più di 100.000.

 Employee(salary > 100000)

Determinare se un paziente ha un livello di colesterolo superiore a 200 e sta assumendo Lipitor.

 Patient(cholesterol > 200, medications.contains(“lipitor”))

Determina se il prezzo di un'azione è entro l'1% del suo massimo annuale.

 Stock(price >= (yearHigh * .99))

Combinazione di query

Quando si scrivono una logica aziendale complessa, le regole aziendali possono combinare le query utilizzando gli operatori booleani AND, OR e NOT e l'annidamento tramite parentesi.

Per esempio:

Determina se c'è un manager che guadagna meno di $ 75.000 o un amministratore che guadagna meno di $ 100.000.

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Utilizzo di più tipi di oggetto

Tutti gli esempi finora sono stati basati su un unico tipo di oggetto, come Impiegato o Paziente. Tuttavia, Drools consente alle query di essere basate su più tipi di oggetti.

Per esempio:

Determina se il cliente ha uno stipendio superiore a $ 50.000 e non ha dichiarato fallimento.

 Customer(salary>50000) AND not exists Bankruptcy()

Il lato "allora" di una regola

Il lato "allora" di una regola determina cosa accadrà quando c'è almeno un risultato nella parte "quando" della regola.

In Drools, tutto ciò che può essere scritto in Java può essere scritto nella parte "allora" della regola. Tuttavia, per rendere le regole più riutilizzabili, è generalmente una buona idea non inserire alcun I/O, codice di controllo del flusso o codice di esecuzione generale all'interno di una regola.

In alternativa, la parte "allora" di una regola può essere utilizzata per modificare la memoria di lavoro. Una pratica comune consiste nell'inserire un fatto nella memoria di lavoro quando una regola viene valutata come vera.

Per esempio:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

Come facciamo a sapere quando una regola è stata valutata come vera?

Dopo che tutte le regole sono state attivate, l'applicazione deve sapere quali regole sono state valutate come vere. Se le regole inseriscono oggetti nella memoria di lavoro quando valutano true, il codice può essere scritto per interrogare la memoria di lavoro per quegli oggetti.

Nell'esempio precedente, dopo che tutte le regole sono state attivate, è possibile eseguire una query per verificare se un oggetto LoanApproval() è nella memoria di lavoro.

 query "GetLoanApproval " $result: LoanApproval() end

In che modo un motore di regole aziendali interagisce con un'applicazione?

Le applicazioni tipiche contengono logica aziendale, GUI, I/O e flusso di codice di controllo.

Ad esempio, un'applicazione può elaborare una richiesta dell'utente in questo modo:

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

L'incorporamento di un motore di regole aggiunge alcuni passaggi a questo processo:

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

Come funzionano le PMI con le regole?

Creazione, modifica ed eliminazione di regole

Affinché le PMI possano lavorare con le regole, avranno bisogno di una GUI di facile utilizzo. Alcuni motori di regole aziendali vengono forniti con tale interfaccia.

Ad esempio, Drools viene fornito con due GUI che trovo facili da usare. Il primo assomiglia a un foglio di calcolo e consente alle PMI di creare regole senza mai scrivere alcun codice vero e proprio. La seconda GUI consente di creare logiche di business più complesse.

Sebbene entrambe queste GUI possano essere utili per l'immissione di condizioni semplici, non funzioneranno poiché la logica aziendale diventa più complessa. In tal caso dovrai creare la tua GUI personalizzata.

Elementi della GUI personalizzata per le PMI

Affinché le PMI funzionino in modo efficace, prendere in considerazione la creazione di una GUI personalizzata con le seguenti funzionalità:

• Verifica sintassi: un pulsante "verifica sintassi" può chiamare il codice Drools per verificare possibili errori e i loro numeri di linea.
• Trascina/rilascia – invece di richiedere a una PMI di ricordare gli oggetti e gli attributi a sua disposizione, considera di offrire loro un elenco di selezione da cui possono trascinare e rilasciare.
• Interfaccia Web: un'interfaccia thin client sarà disponibile per le PMI senza problemi di distribuzione. Ciò sarà utile poiché la GUI necessita di funzionalità aggiuntive e manutenzione generale.
• Rule Tester: avere la possibilità di testare singole regole senza interfacciarsi con l'intera applicazione aumenterà notevolmente la produttività delle PMI. Consenti alla GUI della PMI di determinare i fatti e quindi attivare le singole regole.

Dove dovrebbero essere archiviate le regole?

In Drools ci sono in genere due modi per memorizzare le regole. Drools funziona immediatamente con regole basate su file che di solito hanno un'estensione .drl.

Funziona bene quando il numero di regole è piccolo. Con l'aumentare del numero di regole, ti consigliamo di utilizzare un database. L'archiviazione e il recupero delle regole da un database richiede più lavoro, ma dovrebbe darti un'architettura molto più gestibile.

Questo tutorial sul motore delle regole ha toccato solo una piccola parte del linguaggio delle regole di Drools. Per una descrizione completa si prega di consultare la documentazione ufficiale di riferimento.

La decisione di utilizzare un motore di regole non dovrebbe essere presa alla leggera. Mentre un motore di regole renderà la tua applicazione più estensibile per le PMI, diventerà anche più complicato da sviluppare, testare e distribuire. Per ulteriori considerazioni su questo argomento, potresti voler rivedere le seguenti linee guida.

Ora possiamo procedere a mostrarti qualcosa di un po' più interessante: un semplice esempio reale di Drools in azione, in un caso d'uso che la maggior parte dei lettori del blog Toptal dovrebbe trovare familiare.

Usare le sbavature in uno scenario di vita reale

Toptal, un fornitore leader di talenti di alto livello nello sviluppo di software, attualmente utilizza il software di monitoraggio dei candidati per accompagnare i candidati attraverso le varie fasi del processo di assunzione. Ecco un diagramma di flusso visivo semplificato di questo processo:

Attualmente, la logica aziendale per decidere se un candidato continuerà nel processo di assunzione è stata codificata nel software. Ogni volta che le risorse umane devono cambiare la logica aziendale, devono coinvolgere l'IT. Vorrebbero avere la possibilità di cambiare direttamente il modo in cui il loro software funziona.

Il software di monitoraggio dei candidati verrà modificato per eseguire le regole fornite dalle risorse umane in ogni punto decisionale del processo di assunzione. Le risorse umane avranno un oggetto "Candidato" che rappresenterà un candidato il cui stato è appena stato modificato da un'iscrizione iniziale, dal completamento di un esame online o da una serie di fattori diversi. L'oggetto Candidato avrà campi per rappresentare l'esperienza, i punteggi dei test, i punteggi dei colloqui, ecc.

L'esempio seguente presenta un insieme semplificato di regole da prendere in considerazione. Non è stato distribuito, è solo un semplice esempio composto da quattro regole interconnesse:

• Inviato -> Test
• Test -> Intervista
• Intervista -> Progetto
• Progetto -> Assunzione

Inviato -> Test

Sulla base delle attuali esigenze del cliente, le risorse umane vorrebbero scrivere una regola che determinerà se un candidato deve essere programmato per i test online.

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

Test -> Intervista

Dopo che il candidato ha sostenuto l'esame online, il suo punteggio deve essere valutato. Anche le risorse umane vorrebbero avere il controllo su questa regola. L'esame online verifica la capacità di un candidato di comprendere la teoria dello sviluppo software, la risoluzione dei problemi e la sintassi. Le risorse umane vorrebbero decidere quale combinazione di punteggi consentirà a un candidato di essere considerato per un colloquio tecnico.

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

Intervista -> Progetto

Un colloquio tecnico metterà alla prova la capacità di un candidato di parlare della propria esperienza, di rispondere a domande sulla risoluzione dei problemi e metterà alla prova la sua capacità di comunicare in generale. Le risorse umane scriveranno la regola che determina un punteggio di superamento per il colloquio tecnico.

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

Progetto -> Assunzione

Se un candidato ha superato il colloquio tecnico, gli verrà assegnato un progetto di programmazione off-line. Presenteranno il progetto e sarà giudicato per completezza, architettura e GUI.

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

Come puoi vedere, anche questo esempio di base offre una serie di possibilità per le risorse umane e può semplificare le operazioni. Il fatto che le risorse umane possano modificare le regole senza dover coinvolgere l'IT nel processo farebbe inevitabilmente risparmiare tempo e accelererebbe il processo di screening.

Poiché le regole possono essere modificate al volo, il dipartimento delle risorse umane avrebbe anche molta più flessibilità. Ad esempio, le risorse umane potrebbero espandere o limitare il processo di selezione impostando parametri diversi.

Se ci sono troppi candidati che spuntano tutte le caselle giuste, l'asticella potrebbe essere alzata in pochi minuti, riducendo così il numero di candidati. In alternativa, se il processo produce pochi o nessun candidato che soddisfa tutti i requisiti, le risorse umane possono scegliere di ridurre o abbandonare alcuni standard, spostando l'attenzione su competenze più rilevanti fino a quando un numero adeguato di candidati soddisfa i requisiti.