2007.05_Silniki reguł biznesowych w perspektywie Microsoft Windows Workflow Foundation_[Programowanie .N].pdf

Programowanie

.NET

Michaël Bałuka

Silniki reguł biznesowych w perspektywie

Microsoft Windows Worklow Foundation

macyjnych, można znaleźć sztandarowe po-

jęcia – słowa kluczowe, będące ważnym ele-

mentem marketingowym oraz katalizatorem dalszego

rozwoju. Takim wszechobecnym i powszechnie zna-

nym pojęciem, była ogólnie rozumiana obiektowość.

Z czasem stała się ona standardem na rynku i w dużej

mierze odpowiada za to, iż pomimo rosnącej złożoności

systemów informatycznych, branża rozwija się nieprze-

rwanie. W bieżącym artykule, omówimy inne zagadnie-

nie, które, tak jak obiektowość, także stanowi stały ele-

ment w ofercie dostawców oprogramowania oraz wpły-

wa na standardy na rynku.

Jednym z głównych problemów, z którymi styka się

dzisiejsze oprogramowanie, jest ich rosnący udział we

wsparciu procesów biznesowych oraz związanych z ni-

mi przepływach i tzw. regułach biznesowych. Systemy

nie są już odpowiedzialne tylko za przechowywanie in-

formacji i wspieranie odizolowanych procesów bizneso-

wych. Rozwój informatyzacji zmierza w kierunku całko-

witej integracji kompleksowych systemów IT z szeroko

rozumianą działalnością irmy. Wyobraźmy sobie ope-

ratora telefonii komórkowej, wdrażającego system nali-

czania prowizji dla jego sieci sprzedażowej. Proces na-

liczania prowizji może nie tylko obejmować samo po-

zyskanie klienta, ale także zatrzymanie go w portfelu

abonamentów oraz podsumowanie wysokości świad-

czonych mu usług. Przedstawione tutaj zagadnienia nie

wyczerpują obszarów zastosowań. Reguły i zasady na-

liczania mogą zmieniać się i być rozbudowywane bar-

dzo intensywnie w czasie. Przykład ten obrazuje ska-

lę złożoności stworzenia i utrzymania systemu wspiera-

jącego przepływy i reguły biznesowe w systemach tej

klasy. W tej perspektywie Microsoft zdecydował się

na połączenie ww. pojęć reguł i przepływów bizne-

sowych (ang. Business rules & Worklow ), w jednym

produkcie: Microsoft Windows Worklow Foundation

(MS WWF), wchodzącego w skład .Net 3.0 oraz do-

starczanego jako rozwiązania zintegrowanego wraz

z MS Windows Vista. W niniejszym artykule nie bę-

dziemy jednak omawiać implementacji w MS WWF

przepływów biznesowych. Skupimy się na zastoso-

wanym silniku reguł, a w szczególności:

• na ogólnym zdeiniowaniu pojęcia silnika reguł w per-

spektywie projektowania systemów informatycz-

nych oraz ich wsparcia dla procesów biznesowych,

• na działaniu zastosowanego silnika reguł bizne-

sowych.

Osadzenie reguł biznesowych

poza naszą aplikacją

Zgodnie z deinicją Microsoftu, Business Rules opisu-

ją operacje, deinicje oraz ograniczenia nałożone na

organizację, w celu zrealizowania jej celów. Podczas

projektowania systemu IT dostępne są dwie metody

implementacji ww. reguł. Pierwsza polega w sztyw-

nym zakodowaniu warunków logicznych i formuł ob-

liczeń w samym kodzie aplikacji lub serwisu. Alterna-

tywą do tego podejścia jest osadzenie warunków lo-

gicznych i formuł obliczeń poza kodem, w silniku re-

guł odpowiedzialnym za ich przetwarzanie. Tak jak

będziemy to przedstawiać w dalszej części artykułu,

wybór metody wpływa na cały cykl życia produktu

informatycznego: od sprzedaży, wykorzystując silnik

reguł jako argument marketingowy; dalej przy zdei-

niowaniu wymagań zachowując na uwadze możliwo-

ści i ułomności każdej z metody; w oczywisty sposób

na projektowaniu architektury i samej implementacji

przyszłego systemu IT; a także podczas fazy utrzy-

mania oprogramowania i drobnych jego ewolucjach.

Tak jak wspomnieliśmy wcześniej, silnik reguł jest

oprogramowaniem, które wspiera operacje związa-

ne z regułami biznesowymi. Bezpośrednią i oczywi-

stą konsekwencją jego zastosowania jest wydziele-

nie granicy pomiędzy tymi regułami a resztą kodu.

To proste stwierdzenie dobrze podsumowuje meto-

dologię właściwą silnikom reguł. Reguły powinny być

niezależnymi bytami udostępnianymi naszej aplika-

cji. Można w tym wypadku:

Autor jest absolwentem Polsko–Japońskiej Wyższej

Szkoły Technik Informacyjnych oraz analitykiem sys-

temowym w irmie Altkom Akademia S.A. Uczestniczy

przy tworzeniu systemów IT dla zagranicznych klientów,

głównie z branży ubezpieczeniowej. Występuje często

w roli analityka biznesowego czy też konsultanta. Bę-

dąc programistą z zamiłowania, pasjonuje się zagadnia-

nimi związanymi z technologią i architekturą systemów

informacyjnych oraz ich efektywnego wykorzystania do

spełnienia oczekiwań klienta.

Kontakt z autorem: michael.baluka @altkom.pl

• łatwo nimi zarządzać, ponieważ nie są rozloko-

wane po całym projekcie w niezliczonej liczbie

modułów i procedur,

• zastosować automatyczne testy przed urucho-

mieniem produkcji, ponieważ reguły nie są w ża-

den sposób związane z interfejsem użytkownika,

• dynamicznie zmieniać reguły bez ponownej kom-

pilacji źródeł czy też ponownego uruchomienia

oprogramowania, ponieważ nie stanowią inte-

gralnej części naszego skompilowanego kodu,

www.sdjournal.org Software Developer’s Journal 05/2007

N a każdym etapie rozbudowy systemów infor-

Windows Worklow Foundation

• traktować podczas implementacji silnik reguł jako czarną

skrzynkę i skupić się na przekazywaniu danych wejścio-

wych oraz przedstawieniu wyników jej działania,

• zbudować narzędzia, które umożliwiają tworzenie i edycję

reguł, przez osoby nie będące programistami, czy to anali-

tyków po stronie dostawcy czy też ekspertów biznesowych

po stronie klienta,

• szybciej reagować na zachodzące zmiany w biznesie

klienta, w dużym stopniu bez włączenia programistów

w proces ewolucji oprogramowania,

Omawiany przez nas produkt, wypada w tym kontekście

dużo lepiej. Za pomocą wchodzącego w skład środowiska de-

weloperskiego .Net 3.0 – graicznego edytora, nauka przebie-

ga błyskawicznie. Sama edycja reguł przebiega intuicyjnie

i dla analityka nie stanowi żadnego problemu. Wymaga jedy-

nie podstaw algebry Boola i znajomości samego prostego al-

gorytmu wykonywania reguł. Podczas edycji reguł nie ma tu

miejsca na pracę z C#, jak widać na Rysunku 1.

Nie oznacza to jednak, iż wdrożenie MS WWF nie wymaga

pracy programistycznej po stronie naszej aplikacji. MS WWF

jest częścią samego .Net framework 3.0. Z poziomu Visual Stu-

dio atrybuty i metody są dostępne w edytorze graicznym, do-

piero po wykonaniu odpowiedniej pracy programistycznej, któ-

rą mój kolega z irmy Altkom Akademia S.A. Marcin Sulecki opi-

suje w bieżącym numerze Software'u, w artykule poświęconym

implementacji WWF. W skrócie praca ta, polega na zaimple-

mentowaniu klasy, która będzie deiniowała strukturę danych,

na której operować będzie silnik reguł. Natomiast tym, co znaj-

dzie się poza kodem naszej aplikacji, będzie cała logika wyko-

rzystywania tej struktury. Stanowi to siłę omawianego przez

nas narzędzia. Jeżeli nie są wymagane nowe atrybuty czy też

metody, praca programistyczna nie jest wymagana. Cała praca

projektowania reguł odbywa się z poziomu edytora graicznego

silnika reguł. Silnik odpowiada także za izyczne wykonywanie

zaprojektowanych reguł; oczywiście po wczesniejszym urucho-

mieniu tego procesu kodem z naszej aplikacji. Dokładny przy-

kład jest dostępny w artykule Marcina.

Silnik reguł wpływa na jakość produktu programistycznego na

wszystkich etapach jego cyklu życia. Umożliwia efektywne za-

rządzanie regułami biznesowymi, jednolite standardy projek-

towania, miarodajne testowanie danych wynikowych, szybszą

i mniej kosztowną reakcję na potrzeby klienta. Silniki reguł jed-

nak nie tylko posiadają wartość dodaną do obecnych standar-

dów. Umożliwiają także wprowadzenie, w typowym oprogramo-

waniu wspierającym procesy operacyjne organizacji, zagadnień

zwykle związanych ze sztuczną inteligencją. Mowa tu np. o za-

gadnieniu z dziedziny wydobywania wiedzy ( Data mining ) zwa-

nym wnioskowaniem w przód ( forward chaining ). To pojecie jest

odwrotne do wnioskowania wstecz ( backward chainin g), znane-

go z sieci neuronowych. Znaczy to, iż nie budujemy aksjomatów

na podstawie już znanych wyników, tylko tworzymy nowe zdania

logiczne, na podstawie istniejącej bazy faktów i aksjomatów. In-

aczej mówiąc, nie wychodzimy od wyników, tak jak w przypadku

sieci neuronowych, tylko od znanych nam reguł w celu zbudo-

wania bardziej złożonego modelu. W zależności od zastosowa-

nych algorytmów takie podejście umożliwia:

Czym są Reguły?

Każda reguła składa się z:

• określenie, ręcznie lub automatycznie, relacji i priorytetów

zachodzących pomiędzy poszczególnymi regułami oraz

detekcję ewentualnych konliktów,

• wykonywanie reguł w zaprojektowanym kontekście całych

kolekcji obiektów źródłowych zależnych od siebie, zwany-

mi faktami.

• warunku logicznego,

• podstawowej akcji w przypadku spełnienia warunku lo-

gicznego,

• alternatywnej akcji (może być pusta) w przypadku braku

spełnienia tego warunku.

Prosty i skuteczny silnik reguł

Microsoft zdecydował się na zaimplementowanie jedynie pierw-

szego z dwóch ww. aspektów, rezygnując z podejścia opartego

na faktach. Dokładny opis algorytmu wdrażającego to podejście,

znajdziemy w artykule mojego kolegi z irmy Altkom Akademia

– Mariusza Kaczora. Artykuł dotyczy silnika reguł Drools i został

opublikowany bieżącym numerze. W produkcie Microsoftu, za-

stosowanie reguł nie wiąże się z załadowaniem kolekcji obiektów

źródłowych do tak zwanej pamięci roboczej ( working memory ),

tylko z przetwarzaniem pojedynczego obiektu wejściowego wraz

z jego zmiennymi. W niniejszym artykule skupimy się na zaim-

plementowanym algorytmie przetwarzania pojedynczego obiek-

tu, za pomocą zależnych od siebie reguł. Zanim jednak rozpisze-

my dokładnie algorytm, warto zastanowić się nad konsekwencja-

mi uproszczenia wnioskowania w przód, o podejście oparte na

faktach. Na pewno ujmą jest ograniczona zdolność wnioskowa-

nia samego silnika. Zbudowanie kolekcji reguł, rozwiązującej zło-

żone problemy bez jawnego określania wszystkich reguł, wyda-

je się być zadaniem dla innego produktu niż MS WWF. Jednak,

w większości sytuacji biznesowych, nie potrzebujemy sztucznej

inteligencji, tylko możliwości łatwego zapisu prostych, ale licz-

nych i zagnieżdżonych, reguł biznesowych.

Wyżej wymienione elementy są oparte o klasy obiektów, ich

atrybuty oraz metody, wyspecyikowane w kodzie naszej aplika-

cji, w warstwie odpowiedzialnej za komunikację z silnikiem reguł.

Oznacza to, iż projektując reguły odwołujemy się bezpośrednio

Rysunek 1. Edycja reguł

Software Developer’s Journal 05/2007

www.sdjournal.org

Programowanie

.NET

do zmiennych, funkcji i procedur w kodzie naszej aplikacji. Istot-

nym elementem jest to, że w kodzie powinny być umiejscowio-

ne tylko te sprawdzenia logiczne i obliczenia, będące atomowymi

cegiełkami dla projektowanych reguł biznesowych. Inaczej mó-

wiąc, cegiełki te nie powinny być uzależnione od zmian w samym

biznesie odbiorcy oprogramowania. Model współpracy pomiędzy

naszą aplikacją a silnikiem reguł, powinien dążyć, w miarę możli-

wości, do odzwierciedlenia zmian w biznesie odbiorcy wyłącznie

po stronie silnika, bez ingerencji w naszą aplikację. Oczywiście

cel ten jest wyłącznie wytyczną i nie jest możliwy do zaspokoje-

nia w rzeczywistych warunkach, gdzie nieprzewidziane zmiany,

mogą mieć wpływ na samą deinicję klas obiektów biznesowych.

Prawdziwym celem jest ograniczenie takich zmian, budując jak

największą część logiki naszej aplikacji w oparciu o silnik reguł.

Same reguły są przechowywane w tak zwanym zestawie

reguł ( Ruleset ) i uruchamiane jako jedną całość w kontekście

pojedynczego obiektu wejściowego. Wewnątrz zestawu, każda

reguła posiada własny priorytet, który istotnie wpływa na se-

kwencję jej wykonania względem innych reguł. Zmiana priory-

tetu może zmienić nie tylko sekwencję wykonania reguł ale też

liczbę tych wykonań. Priorytet bardzo mocno wpływa na wy-

nik działania silnika. Z kolei wynikiem tym jest zmodyikowany

obiekt wejściowy, zgodnie z zaprojektowanymi regułami.

• Proces trwa, dopóki wszystkie reguły nie zostaną wykona-

ne przynajmniej raz .

Diagram przedstawiający algorytm znajduje się na Rysunku 2.

Algorytm polega, w pierwszym kroku, na zbudowaniu począt-

kowej listy aktywnych reguł, a następnie na iteracyjnym ich

wykonywaniu względem:

• przypisanego priorytetu między samymi regułami,

• hierarchii pomiędzy powstającymi kolejnymi listami zawie-

rającymi reguły.

W każdej iteracji, po wykonaniu akcji bieżącej reguły, poten-

cjalnie budowana jest podrzędna lista powiązanych reguł. Ta-

ka podlista zostanie utworzona w przypadku, gdy zostanie wy-

kryta przynajmniej jedna reguła wymagająca ponownej walida-

cji. W tym wypadku zawieszane jest wykonywanie reguł z listy

nadrzędnej, a sterowanie przechodzi na nową listę. Jej reguły

są uruchamiane w taki sam sekwencyjny sposób (uzależniony

od priorytetu). Po wykonaniu wszystkich reguł z podlisty, algo-

rytm wraca do nadrzędnego potoku. Oczywiście możliwy jest

większy poziom zagnieżdżenia. Każda podlista podczas itera-

cyjnego przetwarzania jej reguł, może być rozszerzona w da-

nym kroku o kolejną podlistę. Podsumowując - silnik wykonuje

w kolejności wszystkie reguły zgodnie z nadanym priorytetem,

w każdym kroku sprawdzając czy wykonana reguła mogła spo-

wodować naruszenie spójności uprzednio wykonanych reguł.

Opisana tutaj procedura jest domyślną i podstawową me-

todą rozwiązywania zbioru reguł przez silnik zaimplemento-

wany w MS WWF. Została jednak wzbogacona o dwa pozio-

my ręcznego sterowania wykonywaniem reguł. Pierwsze z nich

polega na jawnym zdeiniowaniu powiązań pomiędzy regułami.

W tym wypadku, można zdeiniować, iż reguła A będzie po-

nownie sprawdzana, jeżeli reguła B wykona odpowiednią akcję.

W tym kontekście można ustawić tryb pracy zestawu reguł na

domniemany ( implicit ) lub jawny ( explicit ). Tryb jawny wyłącza

całkowicie opisane wcześniej wnioskowanie w przód. Silnik bę-

dzie w tym wypadku korzystał wyłącznie z jawnie zdeiniowa-

nych powiązań. Z kolei tryb domniemany włącza wnioskowanie

w przód. Drugim poziomem ręcznego sterowania wykonywa-

niem reguł, polega na określaniu dla każdej konkretnej reguły,

czy może ona zostać ponownie wykonana w sytuacji, gdy silnik

wykryje powiązanie z inną regułą. Te dwa poziomy pozwalają

skorzystać z wiedzy eksperckiej człowieka w oparciu (lub nie)

o wnioskowanie w przód. Bardziej szczegółowy opis implemen-

tacji oraz działania samego algorytmu opisał w bieżącym nu-

merze Software'u, Marcin Sulecki w artykule poświęconym za-

gadnieniom implementacyjnym.

Zajrzyjmy pod maskę

Kroki algorytmu wykonania reguł wyglądają następująco:

• Zbudować listę aktywnych reguł posortowaną względem

ich priorytetów.

• Uruchomić kolejną regułę w bieżącej liście.

• Wykonać akcje zdeiniowane w regule zgodnie z jej warun-

kami ( Then/Else ).

• Stworzyć podlistę reguł do ponownego sprawdzenia. Li-

sta będzie zawierać reguły, które posiadają w warunku lo-

gicznym, wartości zmienione przez akcję wykonaną w kro-

ku [3]. Lista będzie posortowana względem priorytetów re-

guł. Przejść do przetwarzania stworzonej nowej podlisty.

• Znaleźć kolejną regułę o najwyższym priorytecie w aktual-

nie przetwarzanej listy

• Jeżeli bieżąca lista nie została w całości przetworzona po-

wrócić do kroku [2].

��

Podsumowanie

MS Windows Worklow Foundation, chociaż nie spełnia wszyst-

kich założeń silnika reguł, może okazać się łatwym do wdroże-

nia rozwiązaniem, odpowiednim w najczęściej spotykanych sy-

tuacjach biznesowych. W połączeniu z obsługą przepływów

biznesowych oraz faktem, że jest on za darmo dołączany do

MS Windows Vista, produkt ten posiada bez wątpienia silne

atuty umożliwiające zaistnienie na rynku. Niezależnie jednak

od wyboru samego rozwiązania, zagadnienie silników reguł

stało się istotnym elementem na rynku, które trudno pominąć

chociażby z przesłanek czysto marketingowych. n

��

Rysunek 2. Diagram działania silnika MS WWF

www.sdjournal.org Software Developer’s Journal 05/2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: