Wykład 5

Informatyzacja przedsiębiorstw
WYKŁAD
dr inż. Piotr Zabawa
IBM/Rational Certified Consultant
[email protected]
wersja 0.1.0
07.10.2010
Wykład 5
Techniki pracy
w środowisku Jboss Drools
Wstęp
Podobnie jak w każdej pracy o charakterze informatycznym
niemal nigdy nie udaje się opracować gotowego
rozwiązania od razu bezbłędnie.
Dlatego Drools oferuje szereg rozwiązań ułatwiających
testowanie, poszukiwanie błędów i ich naprawianie.
Należy wziąć dodatkowo pod uwagę fakt, że język reguł
biznesowych jest językiem deklaratywnym mającym swoją
specyfikę. Poprawianie błędów jest szczególnie trudne.
Zagadnienia
•
•
•
•
•
•
Testy jednostkowe z mockowaniem
Testy integracyjne
Testy akceptacyjne
Pisanie scenariuszy testowych
Wykonywanie scenariuszy testowych
Statyczna analiza reguł
Zagadnienia
• Specyficzne techniki
– Rete Tree View
– Debug event listener
– Komentowanie fragmentów warunków reguł
– Wykorzystanie System.out w konsekwencjach reguł
– Podgląd kodu źródłowego klasy generowanej dla
konsekwencji reguły
– Wstrzykiwanie System.out do warunków reguł z
wykorzystaniem mvel
Testy jednostkowe
W testach jednostkowych chodzi o przetestowanie reguły w
oderwaniu od całego otoczenia – testujemy poprawność
samej reguły a nie np. usług, z których ona korzysta.
Aby móc zastosować takie podejście należy skorzystać z
bibliotek mockujących, np. jMock. Biblioteka ta
umożliwia wykonanie klasy, która zastępuje usługę
rejestrując wywołania jej metod (nazwa metody, ilość
wywołań, czas wywołania, kolejność wywołań).
Testy jednostkowe reguł
Testem jednostkowym powinien zostać pokryty każdy
warunek reguły. Jeśli warunek nie jest spełniony, to test
powinien nie przejść (fail). Takie podejście umożliwia
dokonywanie refaktoryzacji reguł z ograniczonym
ryzykiem naruszenia dotychczasowej ich funkcjonalności.
Test powinien uwzględniać brak dostępnego faktu, na którym
działa reguła, dostępność jednego faktu, wielu faktów w
sesji.
Testy jednostkowe workflow
Testy jednostkowe dla procesów powinny być podzielone na
dwie części:
• Testy definicji procesu (w bazie wiedzy tylko zasób *.rf)
• Testy reguł
Test definicji procesu powinien testować każdy węzeł
procesu w celu sprawdzenia prawidłowości rozpływu
sterowania. Szczególny nacisk należy położyć na
sprawdzenie każdej gałęzi procesu oraz na sprawdzanie
warunków w poszczególnych węzłach.
Testy integracyjne reguł/procesów
Są to testy wyższego poziomu niż jednostkowe. Testują one
całą bazę wiedzy i sprawdzają współpracę pomiędzy
regułami. W odróżnieniu od testów jednostkowych nie
stosujemy mockowania, bo chodzi nam właśnie o działanie
na poprawnie zainicjowanych obiektach.
W tym rodzaju testów w zastosowaniu do workflow nie
testujemy osobno definicji procesu a osobno reguł lecz oba
elementy łącznie.
Testy akceptacyjne reguł
Są to systemowe testy black-box’owe wykonywane przed
przekazaniem systemu klientowi. Ich zbiór może być
wyspecyfikowany jako jeden z elementów wymagań
(testujemy zgodność działania systemu właśnie z
wymaganiami). Specyfikacja takiego testu systemowego
obejmuje:
• Określenie wymaganych dla testu wpisów
konfiguracyjnych systemu
• Określenie wymaganych dla testu danych wejściowych
• Określenie spodziewanych danych wyjściowych
Testy akceptacyjne reguł
Istnieje szereg narzędzi ułatwiających implementowanie
testów akceptacyjnych. Jednym z nich jest Framework for
Integrated Test (FIT). Przechowuje on specyfikację testów
w dokumentach typu doc lub rtf. Podejście to zastosowano
w Drools i jest ono dostępne przez Guvnor, a więc są
dedykowane do użytku dla analityków biznesowych.
Testy akceptacyjne reguł
Kroki w Guvnor:
• Załadowanie pakietu reguł biznesowych
• Import modelu oraz brakujących pakietów/bibliotek
• Utworzenie scenariusza testowego (sekcje GIVEN i
EXPECT dla każdego testu oraz przycisk More… dla
kolejnych testów) – do dyspozycji informacja o polach i
ich typach wydobyta z testowanej klasy
• Wykonanie scenariusza testowego (przycisk Run scenario)
– pokazuje się pasek sukcesu, podsumowanie, log audytu
• Wykonanie wszystkich scenariuszy
Testy akceptacyjne reguł
Możliwość wykonania tych testów z zewnątrz poprzez ich
URL. Może to mieć duże znaczenie w przypadku
zastosowania serwera automatycznych buildów
(continuous integration server).
Statyczna analiza reguł
Pisanie testów jest czynnością niezwykle żmudną. Dlatego
lepiej jest korzystać z możliwości automatyzowania tego
procesu.
Jedną z takich możliwości oferuje właśnie analiza statyczna
reguł. Jednym z elementów Drools jest drools-verifier,
który używa własnych reguł do analizowania reguł
użytkownika. Jest zintegrowany z Guvnor.
Statyczna analiza reguł
Kroki w Guvnor:
• Wskazanie pakietu reguł
• Uruchomienie analizy
• Ręczna analiza wyników (błędy, ostrzeżenia, uwagi)
Pakiet ten jest nowy w Drools i wewnętrzne reguły analizy
będą stopniowo uzupełniane.
Specyficzne techniki
Wymieniono je wcześniej. Tutaj zostaną poruszone niektóre z
nich.
Specyficzne techniki
Wymieniono je wcześniej. Tutaj zostaną poruszone niektóre z
nich.
Event listeners
Inaczej zwane callback handlers mają wiele zastosowań:
• Audyty
• Debugowanie
• Wyprowadzanie funkcjonalności poza reguły(np. metoda
afterActivationFired w AgendaEventListener do tworzenia
Messages i Report)
Event listeners
W Drools są następujące event listenery:
1. org.drools.event.rule.WorkingMemoryEventListener –
nasłuch zdarzeń w sesji z bazą więdzy
(insert/update/retract faktu)
2. org. drools.event.rule.AgendaEventListener – nasłuch
zdarzeń w agendzie sesji z bazą wiedzy (create/cancel
activation, before/after activation fired, agenda group
pop/push)
Event listeners
3. org.drools.event.knowledgebase.KnowledgeBaseEventLis
tener – nasłuch zdarzeń w bazie wiedzy
(dodawanie/usuwanie pakietów, reguł, funkcji,
lock/unlock)
4. org.drools.event.process.ProcessEventListener –
nasłuchiwanie zdarzeń instancji procesu (before/after
process started/completed,…)
Jest wiele wersji tych listenerów, m.in. Wypisująca do
konsoli, przeznaczona do dziedziczenia.
Debugowanie reguł
Drools Eclipse plugin oferuje możliwość debugowania
konsekwencji reguł w pliku reguł. Możliwości takie jak w
debugingu Java i w Guvnor (widoki Audit, Working
Memory, Agenda, Global Data, Process Instance).
Możliwość logowania do pliku w celu analizy off-line
zdarzeń (tylko zdarzeń?).
Debugowanie procesu
Drools Eclipse plugin oferuje dodatkowe widoki do
debugowania procesu:
• Process Instances (pokazuje wszystkie instancje
procesów)
• Process Instance (pokazuje grafową reprezentację procesu
i aktualny węzeł)
Aby aktywować te widoki należy ustawić breakpoint w
metodzie beforeNodeTriggered klasy
ProcessEventListener (wejście przez proces) albo w
konsekwencji reguły (wejście przez regułę).
Analiza generowanego kodu
Kompilator Drools w czasie kompilacji pliku reguł generuje
wiele klas Java. Klasy te są zapisywane w RAM, jednak
można je przekierować do pliku:
• -Ddrools.dump.dir=„target/dumpDir”
•
KnowledgeBuilderConfiguration configuration =
KnowledgeBuilderFactory.
newKnowledgeBuilderConfiguration();
configuration.setOption(DumpDirOption.
get(new File(„target/dumpDir”)));
Można przeprowadzić szczegółową analizę kodu i zobaczyć
jaki kod jest naprawdę wykonywany.
Wykorzystanie możliwości mval
Można tymczasowo tylko w celu debugowania wstrzyknąć
do warunków reguły dodatkowy kod, np.
dialect „mvel”
when
Account ( eval(System.out.println(„matched”); balance>1))