Budowanie silników reguł biznesowych za pomocą Drools — moc dla MŚP

Jedną z najbardziej niesamowitych rzeczy związanych z pracą w tworzeniu oprogramowania jest możliwość pracy w wielu różnych branżach - zwłaszcza jeśli jesteś konsultantem. Większość umiejętności tworzenia oprogramowania, których uczysz się podczas pracy w jednej branży, można bezpośrednio przenieść do dowolnej liczby innych branż, firm, projektów i nisz.

Mówię o takich tematach jak projektowanie baz danych, wzorce projektowe, układy GUI, zarządzanie wydarzeniami itp. Następnie są oczywiście tematy specyficzne dla jednej konkretnej branży, firmy lub projektu.

MŚP spotyka IT, rozpoczyna się transfer wiedzy

W tym miejscu wkracza ekspert merytoryczny (MŚP). MŚP zazwyczaj jest bardzo zaangażowane w etap projektowania projektu.

MŚP działa w branży od dłuższego czasu, zna język i rozumie logikę biznesową stojącą za kodowaniem. MŚP może mieć pewną wiedzę na temat tworzenia oprogramowania, ale nie jest to konieczne do powodzenia projektu.

W przypadku wielu projektów, jeśli programista nie ma doskonałego zrozumienia logiki biznesowej, ukończenie udanej aplikacji będzie stosunkowo trudne. Ilość czasu, jaką trzeba poświęcić na transfer wiedzy, będzie się znacznie różnić w zależności od złożoności projektu.

Zakładając, że przyjęto podejście zwinne i jedno lub więcej MŚP jest dostępnych w fazie rozwoju projektu, transfer wiedzy będzie kontynuowany na wszystkich etapach projektu.

Co się stanie, jeśli pełny transfer wiedzy nie jest możliwy?

W zależności od branży i projektu MŚP może nie być w stanie zapewnić pełnego transferu wiedzy.

Na przykład wyobraź sobie, że MŚP jest lekarzem z 25-letnim doświadczeniem i masz 6 miesięcy na ukończenie projektu. Albo wyobraźmy sobie MŚP jako biologa z 40-letnim doświadczeniem – takiego poziomu wiedzy po prostu nie da się przenieść w realistycznych ramach czasowych w przypadku projektów rozwoju oprogramowania.

Ale co, jeśli obszar wiedzy jest dynamiczny?

Zazwyczaj oprogramowanie jest wydawane według ustalonego harmonogramu opartego na czasie lub funkcjach. Jednak reguły biznesowe w niektórych branżach zmieniają się znacznie częściej.

W wielu przypadkach może nie być możliwe wydawanie oprogramowania tak często, jak jest to konieczne, aby nadążyć za zmianami w branży. Możliwość uzewnętrznienia reguł biznesowych w silniku reguł biznesowych może mieć sens w takich scenariuszach. Zdolność projektu programistycznego do wytrzymania zmian znacznie przyczyni się do zapewnienia jego ostatecznego, długoterminowego sukcesu.

Kiedy i gdzie mechanizmy reguł mają sens?

W przypadku wielu projektów programistycznych możliwe jest, aby miał miejsce pełny transfer wiedzy, a logika biznesowa została zakodowana w języku komputerowym, takim jak C# lub Java.

Istnieje jednak podzbiór projektów, w których zrozumienie konkretnego tematu jest tak duże, lub reguły biznesowe podlegają tak dużym zmianom, że bardziej sensowne jest, aby osoba niebędąca programistą miała bezpośredni dostęp do logiki biznesowej. To jest temat tego samouczka; mając to na uwadze, omówmy szczegółowo Silniki Reguł.

Co to jest silnik reguł biznesowych?

Silnik reguł to narzędzie do wykonywania reguł biznesowych. Reguły biznesowe składają się z faktów i instrukcji warunkowych. Każde stwierdzenie „jeśli-to”, które pojawia się w tradycyjnej logice biznesowej, kwalifikuje się jako reguła biznesowa.

Na przykład: jeśli pracownik jest chory dłużej niż 5 dni z rzędu i nie ma zaświadczenia lekarskiego, należy je wypisać. Jeśli z partnerem biznesowym nie kontaktowano się przez ponad 6 miesięcy i nie dokonał on w tym czasie żadnych zakupów, być może nadszedł czas, aby wysłać mu serdeczną wiadomość e-mail. Jeśli pacjent ma wysoką temperaturę ciała, problemy ze wzrokiem, a w rodzinie występowała jaskra, być może nadszedł czas, aby poprosić o dodatkowe badania MRI lub inne badania.

Jak MŚP piszą zasady biznesowe?

Zamiast oczekiwać, że MŚP nauczy się Javy, C# lub innego języka programowania, dział IT stworzy dla niego minijęzyk, w którym będzie mógł wyrażać swoje zasady biznesowe. Elementy składowe tych zasad będą składać się z faktów, o które można zapytać. Oto kilka przykładów faktów według branży/obszarów praktyki:

• Zasoby ludzkie: wynagrodzenie, stanowisko, menedżer, lata w firmie
• Medyczne: temperatura, ciśnienie krwi, aktualne leki
• Finansowe: aktualna cena akcji, 52-tygodniowa najwyższa/najniższa cena, wskaźnik P/E, data kolejnej publikacji wyników

Zasadniczo informacje niezbędne do podejmowania decyzji biznesowych muszą być dostępne dla MŚP w sposób uproszczony.

Jak wyglądają te zasady?

W pozostałej części tego samouczka dotyczącego silnika reguł będę używał Drools, otwartego silnika reguł opartego na Javie, który można znaleźć na www.drools.org i jest projektem JBoss. W Drools reguły są napisane w kodzie Java i mają następującą strukturę:

Wyciągi importu znajdują się tutaj:

 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

Drools i pamięć robocza

Drools wykorzystuje koncepcję zwaną pamięcią roboczą.

Kod aplikacji będzie odpowiedzialny za ładowanie odpowiednich faktów do pamięci roboczej, aby MŚP mogły pisać reguły, które odpytują te fakty. Tylko fakty istotne dla logiki biznesowej aplikacji powinny być ładowane do pamięci roboczej, aby utrzymać silnik reguł działający na najwyższych obrotach.

Na przykład, jeśli wniosek określa, czy zatwierdzić klienta do pożyczki, odpowiednie fakty obejmują wynagrodzenie, ocenę kredytową i niespłacone pożyczki. Nieistotne fakty obejmowałyby dzień tygodnia lub płeć.

Ocena zasad

Po załadowaniu pamięci roboczej Drools regułami i faktami, reguły są oceniane zgodnie z „wtedy” częścią ich reguły. Jeśli część „następnie” zostanie oceniona jako prawda, zostanie wykonana część „kiedy” reguły.

Zazwyczaj wszystkie reguły są oceniane jednocześnie, chociaż reguły można grupować i oceniać na podstawie grupy. Część reguły „wtedy” może zmienić zawartość Pamięci Roboczej. Kiedy tak się stanie, Drools ponownie oceni wszystkie reguły, aby sprawdzić, czy któreś z reguł są teraz prawdziwe. Jeśli tak, zostaną wykonane ich części „kiedy”.

Ten rekurencyjny charakter oceny reguł może być błogosławieństwem lub przekleństwem – dlatego reguły należy tworzyć z myślą o tej architekturze.

Strona „jeśli” zasady ślinotok

W Drools fakty są reprezentowane przez obiekty. Można zapytać o istnienie lub nieistnienie typu obiektu. Dodatkowo można odpytywać również atrybuty obiektu.

Oto kilka przykładów:

Sprawdź, czy pracownik zarabia więcej niż 100 000.

 Employee(salary > 100000)

Ustal, czy pacjent ma poziom cholesterolu wyższy niż 200 i przyjmuje Lipitor.

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

Ustal, czy cena akcji mieści się w 1% jej rocznej najwyższej.

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

Łączenie zapytań

Podczas pisania złożonej logiki biznesowej reguły biznesowe mogą łączyć zapytania za pomocą operatorów logicznych AND, OR i NOT oraz zagnieżdżać za pomocą nawiasów.

Na przykład:

Ustal, czy istnieje menedżer zarabiający mniej niż 75 000 USD lub dyrektor zarabiający mniej niż 100 000 USD.

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

Korzystanie z wielu typów obiektów

Wszystkie dotychczasowe przykłady opierały się na jednym typie obiektu, takim jak Pracownik lub Pacjent. Drools pozwala jednak na oparcie zapytań na wielu typach obiektów.

Na przykład:

Sprawdź, czy klient ma wynagrodzenie wyższe niż 50 000 USD i nie złożył wniosku o ogłoszenie upadłości.

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

Strona zasady „wtedy”

Strona „wtedy” reguły określa, co się stanie, gdy w części „kiedy” reguły pojawi się co najmniej jeden wynik.

W Drools wszystko, co można napisać w Javie, można napisać w części „wtedy” reguły. Jednakże, aby reguły były bardziej przydatne do ponownego użycia, ogólnie dobrym pomysłem jest nie umieszczanie w regule żadnych operacji wejścia/wyjścia, kodu kontroli przepływu ani ogólnego kodu wykonawczego.

Alternatywnie, część „wtedy” reguły może być użyta do modyfikacji pamięci roboczej. Powszechną praktyką jest wstawianie faktu do pamięci roboczej, gdy reguła jest oceniana jako prawdziwa.

Na przykład:

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

Skąd wiemy, kiedy reguła została oceniona jako prawdziwa?

Po uruchomieniu wszystkich reguł aplikacja musi wiedzieć, które reguły zostały ocenione jako prawdziwe. Jeśli reguły wstawiają obiekty do pamięci roboczej, gdy oceniają wartość true, można napisać kod w celu zapytania pamięci roboczej o te obiekty.

W powyższym przykładzie po uruchomieniu wszystkich reguł można wykonać zapytanie, aby sprawdzić, czy obiekt LoanApproval() znajduje się w pamięci roboczej.

 query "GetLoanApproval " $result: LoanApproval() end

W jaki sposób silnik reguł biznesowych współdziała z aplikacją?

Typowe aplikacje zawierają logikę biznesową, GUI, I/O i przepływ kodu sterującego.

Na przykład aplikacja może przetwarzać żądanie użytkownika w następujący sposób:

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

Osadzenie silnika reguł dodaje kilka kroków do tego procesu:

 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

Jak MŚP pracują z Regułami?

Tworzenie, edycja i usuwanie reguł

Aby MŚP mogły pracować z zasadami, będą potrzebowały przyjaznego dla użytkownika interfejsu GUI. Niektóre silniki reguł biznesowych są dostarczane z takim interfejsem.

Na przykład Drools jest dostarczany z dwoma GUI, które uważam za przyjazne dla użytkownika. Pierwszy przypomina arkusz kalkulacyjny i umożliwia MŚP tworzenie reguł bez pisania rzeczywistego kodu. Drugi GUI umożliwia tworzenie bardziej złożonej logiki biznesowej.

Chociaż oba te interfejsy GUI mogą być pomocne przy wprowadzaniu prostych warunków, nie będą działać, ponieważ logika biznesowa stanie się bardziej złożona. W takim przypadku będziesz musiał stworzyć swój własny, niestandardowy GUI.

Elementy niestandardowego GUI dla MŚP

Aby MŚP działały efektywnie, rozważ utworzenie niestandardowego GUI z następującymi możliwościami:

• Sprawdzanie składni – przycisk „sprawdź składnię” może wywołać kod Drools w celu sprawdzenia ewentualnych błędów i ich numerów linii.
• Przeciągnij/Upuść – zamiast wymagać od MŚP zapamiętania dostępnych dla nich obiektów i atrybutów, rozważ zaoferowanie im listy wyboru, z której można je przeciągać i upuszczać.
• Interfejs sieciowy – interfejs cienkiego klienta będzie dostępny dla MŚP bez obaw o dystrybucję. Przyda się to, ponieważ GUI wymaga dodatkowych funkcji i ogólnej konserwacji.
• Rule Tester – możliwość testowania poszczególnych reguł bez łączenia się z całą aplikacją znacznie zwiększy produktywność MŚP. Pozwól interfejsowi graficznemu MŚP ustalać fakty, a następnie uruchamiać poszczególne reguły.

Gdzie należy przechowywać reguły?

W Drools są zazwyczaj dwa sposoby przechowywania reguł. Drools działa od razu z regułami opartymi na plikach, które zwykle mają rozszerzenie .drl.

Działa to dobrze, gdy liczba reguł jest niewielka. Wraz ze wzrostem liczby reguł będziesz chciał korzystać z bazy danych. Przechowywanie i pobieranie reguł z bazy danych wymaga więcej pracy, ale powinno zapewnić znacznie łatwiejszą w zarządzaniu architekturę.

Ten samouczek dotyczący silnika reguł dotknął tylko bardzo małej części języka reguł Drools. Pełny opis znajduje się w oficjalnej dokumentacji referencyjnej.

Decyzji o użyciu silnika reguł nie należy podejmować pochopnie. Chociaż silnik reguł sprawi, że Twoja aplikacja będzie bardziej rozszerzalna przez MŚP, jej tworzenie, testowanie i wdrażanie stanie się również bardziej skomplikowane. Dodatkowe uwagi dotyczące tego tematu można znaleźć w poniższych wskazówkach.

Teraz możemy przystąpić do pokazania Wam czegoś bardziej interesującego – prostego, rzeczywistego przykładu Drools w akcji, w przypadku użycia, który większość czytelników bloga Toptal powinna uznać za znajomy.

Używanie Drools w prawdziwym scenariuszu

Toptal, wiodący dostawca wysokiej klasy talentów w zakresie rozwoju oprogramowania, obecnie korzysta z oprogramowania do śledzenia kandydatów, aby przeprowadzać kandydatów do pracy przez różne etapy procesu rekrutacji. Oto uproszczony wizualny schemat blokowy tego procesu:

Obecnie logika biznesowa decydująca o tym, czy kandydat będzie kontynuował proces rekrutacji, została na stałe zakodowana w oprogramowaniu. Za każdym razem, gdy dział kadr musi zmienić logikę biznesową, musi zaangażować dział IT. Chcieliby mieć możliwość bezpośredniej zmiany sposobu działania ich oprogramowania.

Oprogramowanie do śledzenia kandydatów zostanie zmodyfikowane, aby uruchamiać reguły dostarczane przez HR w każdym punkcie decyzyjnym procesu rekrutacji. Dział HR będzie miał obiekt „Kandydat”, który będzie reprezentował kandydata do pracy, którego status został właśnie zmieniony przez wstępny wpis, ukończenie egzaminu online lub szereg różnych czynników. Obiekt Kandydata będzie miał pola do reprezentowania doświadczenia, wyników testów, wyników rozmów kwalifikacyjnych itp.

Poniższy przykład przedstawia uproszczony zestaw zasad do rozważenia. Nie został wdrożony, to tylko prosty przykład składający się z czterech powiązanych ze sobą zasad:

• Przesłane -> Testowanie
• Testowanie -> Wywiad
• Wywiad -> Projekt
• Projekt -> Zatrudnienie

Przesłane -> Testowanie

W oparciu o bieżące potrzeby klienta dział HR chciałby napisać regułę, która określi, czy kandydat powinien zostać zaplanowany na testy 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

Testowanie -> Wywiad

Po tym, jak kandydat przystąpił do egzaminu online, należy ocenić jego wynik. HR chciałby mieć kontrolę również nad tą zasadą. Egzamin online sprawdza zdolność kandydata do zrozumienia teorii tworzenia oprogramowania, rozwiązywania problemów i składni. Dział HR chciałby zdecydować, jaki zestaw wyników pozwoli kandydatowi wziąć udział w rozmowie kwalifikacyjnej.

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

Wywiad -> Projekt

Rozmowa techniczna przetestuje zdolność kandydata do mówienia o swoim doświadczeniu, odpowiadania na pytania dotyczące rozwiązywania problemów oraz sprawdza ogólną zdolność komunikowania się. HR napisze regułę, która decyduje o pozytywnym wyniku rozmowy technicznej.

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

Projekt -> Zatrudnienie

Jeśli kandydat pomyślnie przejdzie rozmowę techniczną, otrzyma projekt programistyczny off-line. Zgłoszą projekt, który zostanie oceniony pod kątem kompletności, architektury i GUI.

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

Jak widać, nawet ten podstawowy przykład oferuje szereg możliwości dla HR i może usprawnić działania. Fakt, że dział HR mógłby zmieniać zasady bez konieczności angażowania w proces działu IT, nieuchronnie oszczędziłby czas i przyspieszył proces weryfikacji.

Ponieważ zasady można zmieniać w locie, dział HR miałby również znacznie większą elastyczność. Na przykład HR może rozszerzyć lub ograniczyć proces selekcji poprzez ustawienie różnych parametrów.

Jeśli jest zbyt wielu kandydatów, którzy zaznaczą wszystkie właściwe pola, poprzeczkę można podnieść w ciągu kilku minut, zmniejszając w ten sposób liczbę kandydatów. Alternatywnie, jeśli w ramach procesu uzyska się niewielu kandydatów spełniających wszystkie wymagania lub nie będzie ich wcale, dział HR może zdecydować się na zmniejszenie lub porzucenie niektórych standardów, skupiając się na bardziej odpowiednich umiejętnościach, aż odpowiednia liczba kandydatów spełni wymagania.