Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl 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 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))