Construirea de motoare de reguli de afaceri cu drools - Putere pentru IMM-uri

Unul dintre cele mai uimitoare lucruri despre lucrul în dezvoltarea de software este capacitatea de a lucra în multe industrii diferite - mai ales dacă ești consultant. Cele mai multe abilități de dezvoltare software pe care le învățați în timp ce lucrați într-o industrie sunt direct transferabile către orice număr de alte industrii, companii, proiecte și nișe.

Vorbesc despre subiecte precum designul bazei de date, modelele de design, layout-urile GUI, managementul evenimentelor etc. Apoi, desigur, există subiecte specifice unei anumite industrii, companie sau proiect.

IMM-urile se întâlnesc cu IT, transferul de cunoștințe începe

Aici intervine expertul în materie (IMM). Un IMM va fi de obicei foarte implicat în etapa de proiectare a proiectului.

IMM-ul lucrează în industrie pentru o perioadă lungă de timp, cunoaște limbajul și înțelege logica de afaceri din spatele codificării. IMM-ul poate avea o anumită înțelegere a dezvoltării software, dar acest lucru nu este necesar pentru ca proiectul să reușească.

Pentru multe proiecte, cu excepția cazului în care dezvoltatorul de software are o mare înțelegere a logicii afacerii, finalizarea unei aplicații software de succes va fi relativ dificilă. Timpul care trebuie alocat transferului de cunoștințe va varia foarte mult în funcție de complexitatea proiectului.

Presupunând că se adoptă o abordare agilă și că unul sau mai multe IMM-uri sunt disponibile pe parcursul fazei de dezvoltare a proiectului, transferul de cunoștințe va continua în toate etapele proiectului.

Ce se întâmplă dacă transferul complet de cunoștințe nu este fezabil?

În funcție de industrie și proiect, este posibil ca un IMM să nu poată furniza un transfer complet de cunoștințe.

De exemplu, imaginați-vă dacă IMM-ul este un medic cu 25 de ani de experiență și aveți la dispoziție 6 luni pentru a finaliza un proiect. Sau, imaginați-vă IMM-ul ca un biolog cu 40 de ani de experiență – un astfel de nivel de cunoștințe pur și simplu nu poate fi transferat într-un interval de timp realist pentru proiectele de dezvoltare de software.

Dar dacă zona de cunoștințe este dinamică?

De obicei, software-ul este lansat într-un program stabilit, bazat pe timp sau funcții. Cu toate acestea, regulile de afaceri din unele industrii se schimbă mult mai frecvent.

În multe cazuri, este posibil să nu fie fezabilă lansarea de software atât de des cât este necesar pentru a ține pasul cu schimbările din industrie. Având capacitatea de a externaliza regulile de afaceri în cadrul unui motor de reguli de afaceri poate avea sens în astfel de scenarii. Capacitatea unui proiect de software de a putea rezista schimbărilor va contribui în mare măsură la asigurarea succesului său final pe termen lung.

Când și unde au sens motoarele cu reguli?

Pentru multe proiecte software, este posibil ca transferul complet de cunoștințe să aibă loc și ca logica de afaceri să fie codificată într-un limbaj de calculator precum C# sau Java.

Cu toate acestea, există un subset de proiecte în care nivelul de înțelegere a unui anumit subiect este atât de mare, sau regulile de afaceri sunt supuse unor schimbări atât de mari încât are mai mult sens ca un non-programator să aibă acces direct la logica de afaceri. Acesta este subiectul acestui tutorial; având în vedere acest lucru, să discutăm în profunzime Rules Engines.

Ce este un motor de reguli de afaceri?

Un motor de reguli este un instrument pentru executarea regulilor de afaceri. Regulile de afaceri sunt compuse din fapte și declarații condiționate. Orice afirmație „dacă-atunci” care apare în logica tradițională de afaceri se califică drept regulă de afaceri.

De exemplu: dacă un angajat este bolnav mai mult de 5 zile la rând și nu are un bilet al medicului, atunci trebuie să fie scris. Dacă un asociat de afaceri nu a fost contactat de peste 6 luni și nu a făcut nicio achiziție în acest timp, atunci poate fi timpul să-i trimiteți un e-mail cordial. Dacă un pacient are o temperatură corporală ridicată, probleme de vedere și există antecedente familiale de glaucom, atunci ar putea fi timpul să solicite un RMN suplimentar sau alte teste.

Cum scriu IMM-urile reguli de afaceri?

În loc să se aștepte ca un IMM să învețe Java, C# sau un alt limbaj de programare, IT va crea un mini-limbaj pentru ca el sau ea să își exprime regulile de afaceri. Elementele de bază ale acestor reguli vor consta în fapte pentru care pot fi solicitate. Câteva exemple de fapte pe industrie/domenii de practică sunt:

• Resurse umane: salariu, post, manager, ani cu firma
• Medical: temperatura, tensiunea arterială, medicația curentă
• Financiar: prețul actual al acțiunilor, prețul cel mai mare/cel mai mic pe 52 de săptămâni, raportul P/E, data următoarei lansări a câștigurilor

În esență, informațiile necesare pentru a lua decizii de afaceri trebuie să fie disponibile IMM-ului într-un mod eficient.

Cum arată aceste reguli?

Pentru restul acestui tutorial despre motorul de reguli, voi folosi Drools, un motor de reguli open-source bazat pe Java, care poate fi găsit la www.drools.org și este un proiect JBoss. În Drools, regulile sunt scrise ca cod Java și au următoarea structură:

Declarațiile de import merg aici:

 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

Saliva și memoria de lucru

Drools folosește un concept numit Memorie de lucru.

Codul aplicației va fi responsabil pentru încărcarea faptelor adecvate în memoria de lucru, astfel încât IMM-urile să poată scrie reguli care interoghează aceste fapte. Doar faptele relevante pentru logica de afaceri a aplicației ar trebui să fie încărcate în memoria de lucru, pentru a menține motorul de reguli să funcționeze la viteză maximă.

De exemplu, dacă o cerere determină dacă să aprobe un client pentru un împrumut, faptele relevante ar include salariul, scorurile de credit și împrumuturile restante. Faptele nerelevante ar include ziua săptămânii sau sexul.

Evaluarea regulilor

După ce Drools Working Memory a fost încărcat cu reguli și fapte, regulile sunt evaluate în funcție de partea „atunci” a regulii lor. Dacă partea „atunci” este evaluată la adevărat, partea „când” a regulii va fi apoi executată.

De obicei, toate regulile sunt evaluate simultan, deși regulile pot fi grupate și evaluate pe grup. Partea „atunci” a regulii poate schimba conținutul memoriei de lucru. Când se întâmplă acest lucru, Drools va reevalua toate regulile pentru a vedea dacă vreo regulă este acum adevărată. Dacă da, părțile lor „când” vor fi executate.

Această natură recursivă a evaluărilor regulilor poate fi o binecuvântare sau un blestem – așa că regulile trebuie create având în vedere această arhitectură.

Partea „Dacă” a unei reguli de drools

În Drools, faptele sunt reprezentate de obiecte. Existența sau inexistența unui tip de obiect poate fi interogată. În plus, atributele obiectului pot fi, de asemenea, interogate.

Iată câteva exemple:

Stabiliți dacă un angajat câștigă mai mult de 100.000.

 Employee(salary > 100000)

Determinați dacă un pacient are un nivel de colesterol mai mare de 200 și ia Lipitor.

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

Determinați dacă prețul unei acțiuni este în 1% din maximul său anual.

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

Combinarea interogărilor

Când scrieți o logică de afaceri complexă, regulile de afaceri pot combina interogări folosind operatorii booleeni AND, OR și NOT și imbricarea folosind paranteze.

De exemplu:

Stabiliți dacă există un manager care câștigă mai puțin de 75.000 USD sau un director care câștigă mai puțin de 100.000 USD.

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

Utilizarea mai multor tipuri de obiecte

Toate exemplele de până acum s-au bazat pe un singur tip de obiect, cum ar fi Angajat sau Pacient. Cu toate acestea, Drools permite interogărilor să se bazeze pe mai multe tipuri de obiecte.

De exemplu:

Determinați dacă clientul are un salariu mai mare de 50.000 USD și nu a depus faliment.

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

Partea „Atunci” a unei reguli

Partea „atunci” a unei reguli determină ce se va întâmpla atunci când există cel puțin un rezultat în partea „când” a regulii.

În Drools, orice poate fi scris în Java poate fi scris în partea „atunci” a regulii. Cu toate acestea, pentru a face regulile mai reutilizabile, este, în general, o idee bună să nu plasați niciun I/O, cod de control al fluxului sau cod de execuție general într-o regulă.

Ca alternativă, partea „atunci” a unei reguli poate fi folosită pentru a modifica Memoria de lucru. O practică obișnuită este inserarea unui fapt în memoria de lucru atunci când o regulă este evaluată ca adevărată.

De exemplu:

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

Cum știm când o regulă a fost evaluată ca fiind adevărată?

După ce toate regulile s-au declanșat, aplicația trebuie să știe care reguli au fost evaluate drept adevărate. Dacă regulile introduc obiecte în memoria de lucru atunci când evaluează adevărat, codul poate fi scris pentru a interoga memoria de lucru pentru acele obiecte.

În exemplul de mai sus, după ce toate regulile au fost declanșate, se poate face o interogare pentru a vedea dacă un obiect LoanApproval() se află în memoria de lucru.

 query "GetLoanApproval " $result: LoanApproval() end

Cum interacționează un motor de reguli de afaceri cu o aplicație?

Aplicațiile tipice conțin logica de afaceri, GUI, I/O și fluxul de cod de control.

De exemplu, o aplicație poate procesa o solicitare de utilizator astfel:

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

Încorporarea unui motor de reguli adaugă câțiva pași acestui proces:

 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

Cum lucrează IMM-urile cu regulile?

Crearea, editarea și ștergerea regulilor

Pentru ca IMM-urile să lucreze cu reguli, vor avea nevoie de o interfață grafică ușor de utilizat. Unele motoare de reguli de afaceri sunt livrate cu o astfel de interfață.

De exemplu, Drools este livrat cu două interfețe grafice pe care le consider ușor de utilizat. Prima seamănă cu o foaie de calcul și permite IMM-urilor să creeze reguli fără a scrie vreodată vreun cod real. A doua GUI permite crearea unei logici de afaceri mai complexe.

Deși ambele GUI-uri pot fi utile pentru introducerea unor condiții simple, ele nu vor funcționa pe măsură ce logica de afaceri devine mai complexă. În acest caz, va trebui să vă creați propria interfață grafică personalizată.

Elemente de GUI personalizat pentru IMM

Pentru ca IMM-urile să funcționeze eficient, luați în considerare crearea unei GUI personalizate cu următoarele capabilități:

• Verificator de sintaxă – un buton de „verificare a sintaxei” poate apela codul Drools pentru a verifica eventualele erori și numerele de linii ale acestora.
• Drag/Drop – în loc să solicite unui IMM să-și amintească obiectele și atributele disponibile, luați în considerare să le oferiți o listă de alegere din care să poată glisa și plasa.
• Interfață web – o interfață client subțire va fi disponibilă pentru IMM-uri fără probleme de distribuție. Acest lucru va fi util, deoarece GUI are nevoie de funcții suplimentare și întreținere generală.
• Rule Tester – având capacitatea de a testa reguli individuale fără a interacționa cu întreaga aplicație va crește foarte mult productivitatea IMM-urilor. Permiteți GUI pentru IMM-uri să determine fapte și apoi să declanșeze reguli individuale.

Unde ar trebui păstrate regulile?

În Drools există de obicei două moduri de a stoca regulile. Drools funcționează de la început cu reguli bazate pe fișiere care vor avea de obicei o extensie .drl.

Acest lucru funcționează bine atunci când numărul de reguli este mic. Pe măsură ce numărul de reguli crește, veți dori să utilizați o bază de date. Stocarea și preluarea regulilor dintr-o bază de date necesită mai multă muncă, dar ar trebui să vă ofere o arhitectură mult mai gestionabilă.

Acest tutorial privind motorul de reguli a atins doar o parte foarte mică din limbajul regulilor Drools. Pentru o descriere completă, vă rugăm să consultați documentația oficială de referință.

Decizia de a utiliza un motor de reguli nu trebuie luată cu ușurință. În timp ce un motor de reguli va face aplicația dvs. mai extensibilă de către IMM-uri, va deveni și mai complicat de dezvoltat, testat și implementat. Pentru considerații suplimentare cu privire la acest subiect, vă recomandăm să consultați următoarele îndrumări.

Acum putem continua să vă arătăm ceva mai interesant – un exemplu simplu din viața reală de Drools în acțiune, într-un caz de utilizare pe care majoritatea cititorilor de bloguri Toptal ar trebui să-l găsească familiar.

Folosind drools într-un scenariu din viața reală

Toptal, un furnizor de top de talent de dezvoltare software de nivel înalt, utilizează în prezent software-ul de urmărire a solicitanților pentru a-i duce pe candidații la locuri de muncă prin diferite etape ale procesului de angajare. Iată o diagramă vizuală simplificată a acestui proces:

În prezent, logica de afaceri pentru a decide dacă un solicitant va continua procesul de angajare a fost codificată în software. De fiecare dată când Resurse Umane trebuie să schimbe logica afacerii, trebuie să aibă IT implicat. Ei ar dori să aibă capacitatea de a schimba direct modul în care funcționează software-ul lor.

Software-ul de urmărire a solicitantului va fi modificat pentru a rula regulile furnizate de HR la fiecare punct de decizie din procesul de angajare. HR va avea un obiect „Candidat” care va reprezenta un solicitant de locuri de muncă al cărui statut tocmai a fost modificat de o intrare inițială, finalizarea unui examen online sau o serie de factori diferiți. Obiectul Candidat va avea câmpuri pentru a reprezenta experiența, scorurile testelor, scorurile la interviu etc.

Următorul exemplu prezintă un set simplificat de reguli care trebuie luate în considerare. Nu a fost implementat, este doar un exemplu simplu format din patru reguli interconectate:

• Trimis -> Testare
• Testare -> Interviu
• Interviu -> Proiect
• Proiect -> Angajare

Trimis -> Testare

Pe baza nevoilor actuale ale clienților, HR ar dori să scrie o regulă care să determine dacă un candidat ar trebui programat pentru testare 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

Testare -> Interviu

După ce candidatul a susținut examenul online, punctajul acestuia trebuie evaluat. HR ar dori să aibă control și asupra acestei reguli. Examenul online testează capacitatea candidatului de a înțelege teoria dezvoltării software, rezolvarea problemelor și sintaxa. HR ar dori să decidă ce combinație de scoruri va permite unui candidat să fie luat în considerare pentru un interviu tehnic.

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

Interviu -> Proiect

Un interviu tehnic va testa capacitatea candidatului de a vorbi despre experiența sa, de a răspunde întrebărilor de rezolvare a problemelor și le va testa capacitatea de a comunica în general. HR va scrie regula care determină un punctaj de trecere pentru interviul tehnic.

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

Proiect -> Angajare

Dacă un candidat a promovat interviul tehnic, i se va oferi un proiect de programare off-line. Ei vor depune proiectul și va fi evaluat pentru completitudine, arhitectură și GUI.

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

După cum puteți vedea, chiar și acest exemplu de bază oferă o serie de posibilități pentru HR și poate eficientiza operațiunile. Faptul că HR ar putea modifica regulile fără a fi nevoie să implice IT în proces ar economisi, inevitabil, timp și ar accelera procesul de screening.

Deoarece regulile pot fi schimbate din mers, departamentul de resurse umane ar avea, de asemenea, mult mai multă flexibilitate. De exemplu, HR ar putea extinde sau restrânge procesul de selecție prin stabilirea unor parametri diferiți.

Dacă există prea mulți candidați care bifează toate căsuțele potrivite, ștacheta ar putea fi ridicată în câteva minute, reducând astfel numărul de candidați. Alternativ, în cazul în care procesul generează puțini sau deloc candidați care îndeplinesc toate cerințele, HR poate alege să reducă sau să renunțe la unele dintre standarde, concentrându-și atenția către abilități mai relevante până când un număr adecvat de candidați îndeplinesc cerințele.