Zadaniem docelowym jest zamodelowanie przy pomocy pakietu Drools, procesu ofertowania w przedsiębiorstwie. Poniższy diagram przedstawia uogólniony przepływ czynności w procesie:

Proces ofertowania inicjowany jest wpływającym z zewnątrz dokumentem opisującym zamówienie. Opis przyjmuje bardzo różne formy, od nieformalnego zapytania o zupełnie niezdefiniowanej treści (wartościowy jest jedynie kontakt), aż po wysoko sformalizowane dokumenty opisujące zamówienie w rozbiciu na aspekty merytoryczne, handlowe, formalne, itp. W zapytaniu można wskazać dwa podstawowe wymiary determinujące dalsze działania:

Wymagania formalne określające sposób postępowania ofertowego, np. uniemożliwiające czy ograniczające kontakt z zamawiającym na etapie ofertowym, jak również warunki handlowe przystąpienia do procedury składania oferty.
Poziom wyspecyfikowania przedmiotu zamówienia, np. od takiego, który ledwie sygnalizuje tematykę i nie umożliwia jakiejkolwiek analizy bez akwizycji wymagań, aż po spójne i kompletne przedstawienie przedmiotu, które nie wymaga żadnych dodatkowych informacji do przygotowania oferty.

Proces, który chcemy zamodelować, będzie wspomagał użytkownika w podejmowaniu decyzji podczas trzech głównych etapów przetwarzania zapytania ofertowego:

Analizy formalnej.
Analizy merytorycznej.
Przygotowania oferty właściwej.

Analiza formalna

W pierwszej kolejności wykonywana jest analiza formalna/handlowa, głównie ze względu na sprawdzenie warunków, czy firma w ogóle ma prawo/możliwość realizacji zamówienia wg procedury dostarczonej wraz z zapytaniem ofertowym. Na tym etapie weryfikowane są warunki, takie jak posiadanie odpowiednich uprawnień, posiadanie wymaganych certyfikatów, odpowiednie kwalifikacje firmy, itp.
Negatywne zakończenie tego etapu powoduje automatyczne zakończenie się procesu i zaniechanie dalszego przetwarzania zapytania ofertowego.

Analiza merytoryczna

W przypadku pozytywnej weryfikacji formalnej, zapytanie zostaje skierowane do analizy merytorycznej. Analiza merytoryczna składa się z dwóch faz: wstępna analiza merytoryczna oraz właściwa analiza merytoryczna. Podczas analizy wstępnej określa się, w oparciu o dostępny materiał, czy zamówienie może zostać zrealizowane. Brane są tutaj pod uwagę czynniki takie jak: dostępność zespołów, ryzyko projektowe, atrakcyjność zamówienia, itp. Jeżeli zamówienie jest możliwe do zrealizowania, to wykonywana jest analiza właściwa, podczas której przygotowywany jest kosztorys wykonania oraz część merytoryczna oferty sporządzana w oparciu o opinie i ekspertyzy pracowników działu IT. Jeśli okaże się, że dostarczona w zapytaniu specyfikacja jest niewystarczająca, to podejmowany jest kontakt z klientem (o ile jest możliwy) w postaci telefonu/spotkania/wysłania pytań uszczegóławiających, itp. W przypadku jeżeli kontakt z klientem jest niemożliwy, to zapytanie ofertowe jest odrzucane.

Rezultatem analizy merytorycznej są: koncepcja rozwiązania problemu oraz wstępny kosztorys/wycena.

Przygotowanie oferty właściwej

Rezultaty określone podczas analizy merytorycznej służą jako punkt wyjścia podczas etapu przygotowywania oferty właściwej. Etap ten, realizowany przez dział sprzedaży, ma za zadanie opracowanie ostatecznej wyceny. Ostateczna wycena jest obliczana na podstawie wyceny sporządzonej przez dział IT oraz odpowiednich modyfikatorów związanych między innymi z takimi kwestami jak: atrakcyjność wizerunkowa, merytoryczna, perspektywa współpracy z klientem, itp.

Tak przygotowana oferta przed wysłaniem do klienta musi jeszcze być zatwierdzona przez zarząd, który może wprowadzić dowolne poprawki.

Modelowanie opisanego przykładu będzie obejmowało:

Aspekt regułowy: Zdefiniowanie systemu regułowego wspomagającego użytkownika w procesie podejmowania decyzji na etapach analizy formalnej, merytorycznej i podczas przygotowywania oferty właściwej.
Aspekt procesowy: Zamodelowanie kompletnego procesu opisującego proces przetwarzania zapytania ofertowego w firmie.

Powyższy opis ma za zadanie jedynie wprowadzić w kontekst, w którym umieszczony jest modelowany przykład. Szczegółowe wielkości, atrybuty, współczynniki oraz zależności między nimi opisujące problem będą wprowadzone dopiero na odpowiednim etapie modelowania. Jednak przygotowana propozycja nie jest wiążąca i można swobodnie wprowadzać modyfikacje wg własnego uznania/inwencji.

Zakres części 1.

W pierwszej części zajmiemy się przede wszystkim modelowaniem podstawowych elementów bazy wiedzy (modele faktów, proste reguły) a następnie przejdziemy do budowania aplikacji, która będzie w stanie uruchomić wnioskowanie na zbudowanej bazie wiedzy.
Oprócz podstawowych elementów bazy wiedzy, omówione zostaną także inne aspekty modelowania (tworzenie plików z zasobami, tworzenie pakietów, itp.), które są konieczne do prawidłowego działania i wykorzystania stworzonej bazy wiedzy.
W kontekście przykładu, który docelowo chcemy zamodelować, powyższe aspekty będą obejmowały realizację (pod)procesu podejmowania decyzji na etapie analizy formalnej.

Guvnor - Repozytorium wiedzy

Repozytorium wiedzy dostępne jest pod adresem
http://127.0.0.1:8080/drools-guvnor
W przypadku pojawienia się dialogu logowania należy użyć następujących parametrów:

login: admin
passwd: admin

W lewym panelu mamy dostępnych kilka zakładek:

Browse - przeszukiwanie repozytorium.
Knowledge Bases - zawiera definicję wszystkich pakietów bazy wiedzy i ich elementów - jest to najistotniejsza część.
QA - umożliwia definiowanie i uruchamianie testów.
Package snapshots - zarządzanie skompilowanymi wersjami pakietów.
Administration - administracja repozytorium.

Definiowanie nowego pakietu

Każdy element w repozytorium musi być umieszczony albo w przestrzeni globalnej Global Area albo w jednym z pakietów.
Ponieważ każdy zespół wykonuje te same zadania, istnieje niebezpieczeństwo:
- Konfliktów nazw tworzonych elementów.
- Konfliktów funkcjonalności tworzonych elementów.
Aby ich uniknąć, każdy zespół powinien stworzyć swój własny pakiet w którym będzie tworzył wszystkie elementy.
Aby uniknąć konfliktów w samych nazwach pakietów, do ich stworzenia można użyć np. inicjałów osób w zespole.
Aby stworzyć nowy pakiet przechodzimy na zakładkę Knowledge Bases, wybieramy polecenie Create New ⇒ New Package:
W oknie podajemy nazwę dla nowego pakietu - w miarę możliwości proszę nie używać spacji oraz myślników
Po utworzeniu pakiet powinien pojawić się w drzewie pakietów w lewym panelu.

Tworzenie binarnych wersji pakietów

Aby stworzony pakiet mógł być używany przez silnik Drools Expert, to powinien on zostać skompilowany.
Można stworzyć/skompilować pakiet oraz jego snapshot od razu na początku pracy aby później móc robić już tylko jego uaktualnienia. Ten krok nie jest obligatoryjny na samym początku i można go wykonać później.
W celu stworzenia pakietu należy:
1. kliknąć na pakiet w lewym panelu,
2. przejść w głównym oknie na zakładkę Edit,
3. kliknąć przycisk Build package.
Poprawne skompilowanie pakietu jest potwierdzane pojawieniem się zielonej ikony i komunikatem podobnym do:
```
Package built successfully. Last modified on Wed Oct 24 11:14:10 GMT+200 2012
```
Dobrym rozwiązaniem jest aby nasza przyszła aplikacja, która będzie pobierać binarną wersję pakietu, zawsze pobierała jakiś jego snapshot, zawierający wersję pakietu nadająca się do uruchomienia.
Aby stworzyć snapshot bieżącej wersji pakietu należy:
1. kliknąć przycisk Create snapshot for deployment
2. Za pierwszym razem należy wybrać opcję NEW i podać nazwę snapshotu np. nazwa_pakietu-pkg - w miarę możliwości proszę nie używać spacji.
3. Podczas tworzenia kolejnych snapshotów, obok opcji NEW pojawi się opcja zapisu pod już istniejąca nazwą (z tej opcji będziemy korzystać).

Tworzenie bazy zasobów

Baza zasobów tzw. ChangeSet, jest to plik zawierający definicję wszystkich zasobów dla danej bazy wiedzy.
Dodawanie zasobów do modułu Drools Expert potrzebnych do kompilacji bazy wiedzy może odbywać się na dwa sposoby:
1. Dodajemy każdy zasób osobno.
2. Dodajemy plik(i) definiujący potrzebne zasoby - ChangeSet.
Przewaga rozwiązania 2. jest dwojaka:
1. nie trzeba rekompilować aplikacji uruchamiającej po każdorazowej zmianie zasobów (nazwa, ilość),
2. plik zasobów może być zdefiniowany i pobrany na/z repozytorium.
Aby utworzyć ChangeSet należy:
- W lewym panelu przejść do zakładki Knowledge bases
- Wybrać Create new ⇒ New Change Set
- W oknie dialogowym:
  1. Wybieramy opcję Create new.
  2. Podajemy nazwę np. nazwa_pakietu-cs - w miarę możliwości proszę nie używać spacji.
  3. Upewniamy się że plik zostanie utworzony w naszym pakiecie:
    1. Zaznaczmy opcję Create in Package.
    2. Wybieramy nazwę naszego pakietu.
  4. Klikamy OK.
Plik został utworzony i wyświetlony został dialog edycji pliku.
W ramach edycji kolejnym krokiem jest zdefiniowanie zasobu do pobrania przez aplikację uruchamiającą.
Do pliku zasobów dodajemy jedynie utworzony wcześniej snapshot pakietu:
1. Ustawiamy kursor pomiędzy tagami <add>…</add>.
2. W lewej części głównego okna klikamy przycisk Package w części Add new <resource> Element.
  Do pliku można dodać także pojedyncze elementy z poszczególnych (innych) pakietów używając do tego celu przycisku Asset.
3. W dialogu, który się pojawi rozwijamy drzewo Packages w celu zaznaczenia stworzonego w poprzednim punkcie snapshot-u.
  Opcja LATEST określa że dodajemy ostatnio skompilowaną wersję pakietu, jednak z wyżej wspomnianych powodów nie będziemy używać tej opcji.
4. Jeżeli wszystko zostało pomyślnie zrobione, to powinien pojawić się wpis podobny do:
```
<resource   source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/package-name/snapshot-name' type='PKG'/>
```
Tak zdefiniowany plik zawiera definicję zasobu w postaci snapshotu binarnej wersji pakietu, który będzie zawierał wszystkie niezbędne elementy do poprawnej kompilacji bazy wiedzy.
Ponieważ w ogólnym przypadku dostęp do repozytorium wymaga autoryzacji, to aby pobrać dodany zasób, aplikacja także musi przejść proces uwierzytelnienia. W tym celu utworzony wpis, należy uzupełnić poprzez określenie danych do autoryzacji. Do tagu resource dodajemy następujące trzy atrybuty i wartości:
1. basicAuthentication='enabled'
2. username='admin'
3. password='admin'
Mając kompletny plik, należy zapisać zmiany: File ⇒ Save and close.

Definiowanie modelu faktów

Aby móc zdefiniować reguły pracujące na konkretnym modelu danych/faktów, należy wcześniej zdefiniować struktury opisujące fakty. Można to zrobić na dwa sposoby:
1. zdefiniować modele przy pomocy interfejsu guvnora, lub
2. wykonać upload klasy POJO (Plain Old Java Object) w postaci pliku jar.
W tej części, wykorzystamy tylko 1. sposób.
Zdefiniujemy dwie grupy typów faktów:
1. Fakty właściwe - fakty/obiekty gromadzące wiedzę w procesie ofertowania.
2. Fakty pomocnicze - fakty/obiekty określające stan procesu ofertowania.

Definiowanie faktów

W tej części możemy przewidzieć następujące typy faktów w bazie wiedzy:
1. Fakty określające wiedzę na temat spełnienia/niespełnienia poszczególnych wymagań na etapie analizy formalnej:
  1. Możliwość pozyskania.
  2. Posiadanie wymaganych polis ubezpieczeniowych.
  3. Posiadanie wymaganych certyfikatów.
  4. Posiadanie wystarczającego doświadczenia.
  5. Spełnianie minimalnych wymagań ofertowych.
  6. Występowanie konfliktów z innymi zamówieniami w firmie.
2. Fakty przechowujące wiedzę na temat podjętej decyzji na etapie formalnym.
3. Obiekty/fakty pomocnicze przechowujące wiedzę na temat bieżącego etapu procesu ofertowania.
Jako że wszystkie typy faktów z punktu 1. są między sobą podobne, to można wykorzystać mechanizm dziedziczenia przy pomocy którego zdefiniujemy typ faktu bazowego, a następnie typy dla faktów określających poszczególne czynniki. Umożliwi nam to zmniejszenie liczby reguł do zamodelowania ponieważ jedna reguła (zamiast wielu) będzie obsługiwała wiele typów faktów.
Fakty z punktów 1. i 2. znajdują się na tym samym poziomie abstrakcji i zostaną umieszczone w jednej grupie typów faktów. Fakty z punktu 3. zostaną umieszczone w osobnej grupie typów faktów.
Aby zdefiniować pierwszą grupę typów faktów należy:
1. W zakładce Knowledge bases wybrać polecenie Create New ⇒ New Declarative Model
2. W oknie dialogowym:
  1. Wybieramy opcję Create new:
  2. Podajemy nazwę np. factTypes
  3. Wybieramy opcję Create in Package:.
  4. Upewniamy się że nowa grupa zostanie utworzona w naszym pakiecie - z listy rozwijanej wybieramy nazwę naszego pakietu.
Od razu można także zdefiniować drugą grupę typów faktów wykonując takie same kroki jak w poprzednim punkcie. Nową grupę możemy nazwać np. helperTypes.
Teraz możemy przystąpić do definiowania typów faktów w poszczególnych grupach:
1. Przechodzimy na zakładkę Assets w naszym pakiecie.
2. Rozwijamy listę modeli Model.
3. W wierszu odpowiadającym grupie factTypes klikamy przycisk Open.
4. Otwiera się okno edycji modelu, w którym klikamy przycisk Add new fact type aby dodać nowy typ faktu.
5. Jako pierwszy typ, stworzymy typ bazowy dla innych typów faktów gromadzących wiedzę na temat weryfikacji zapytania ofertowego na poziomie formalnym.
  1. W tym celu, w oknie dialogowym podajemy nazwę nowego typu faktu np. reqsFormal - wymagania formalne.
  2. Klikamy OK.
  3. Kolejnym krokiem jest zdefiniowanie właściwości/pól faktu:
    1. Możemy założyć, że nasz fakt bazowy opisujący weryfikację zapytania ofertowego będzie posiadać następujące pola:
      - Asked - [True/False] - określające czy została udzielona odpowiedź na pytanie związane z danym czynnikiem weryfikacji na poziomie formalnym.
      - Question - [String] - treść pytania.
      - Answer - [True/False] - odpowiedź na pytanie.
      - ProceedAnswer - [True/False] - odpowiedź na pytanie, która pozwala na kontynuowanie przetwarzania oferty.
    2. Aby dodać pola do tworzonego modelu faktu należy:
      1. W Zakładce edycji danej grupy typów faktów rozwinąć definicję danego typu faktu,
      2. kliknąć przycisk Add Field,
      3. uzupełnić formularz wpisując:
        
        nazwę właściwości np. Question, oraz
        
        z rozwijanej listy wybrać typ danych właściwości np. Text.
      4. Wykonując te same kroki należy dodać wszystkie właściwości do modelu faktu.
6. Po stworzeniu faktu bazowego, można zdefiniować pozostałe fakty bazujące na nim:
  1. W naszym przypadku fakty pochodne nie będą zawierały żadnych nowych pól, zostaną utworzone tylko w celu użycia odpowiednich typów w regułach - ułatwi to późniejszą (ewentualną) rozbudowę.
  2. Aby stworzyć fakt pochodny postępujemy dokładnie tak samo jak w przypadku tworzenia zwykłego faktu i dodatkowo oprócz określenia nazwy typu faktu, wybieramy także typ który chcemy rozszerzyć/dziedziczyć. W naszym przypadku będzie to typ stworzony w poprzednim punkcie.
  3. W ten sposób tworzymy przynajmniej 6 nowych typów określających wspomniane czynniki analizy formalnej (podane nazwy są przykładowe):
    1. reqsFormalAcquisition - możliwość pozyskania.
    2. reqsFormalInsurance - posiadanie wymaganych polis ubezpieczeniowych.
    3. reqsFormalCertificates - posiadanie wymaganych certyfikatów.
    4. reqsFormalExperience - posiadanie wystarczającego doświadczenia.
    5. reqsFormalMinExpectations - spełnianie minimalnych wymagań ofertowych.
    6. reqsFormalConflicts - występowanie konfliktów z innymi zamówieniami w firmie.
7. Po stworzeniu faktów pochodnych, powinniśmy stworzyć jeszcze jeden typ faktu w tej grupie, który opisywałby decyzję podjętą po analizie formalnej określającą w sposób zero-jedynkowy czy procedura dalszego przetwarzania zapytania powinna być kontynuowana:
  1. Tworzymy nowy fakt o nazwie np. formalDecision, który posiada tylko jedno pole o nazwie np. Decision będące typu True/False.
8. Po stworzeniu wszystkich typów w tej grupie, kompletna lista faktów powinna przypominać poniższą:
9. Aby zakończyć pracę nad tą grupą faktów, zapisujemy zmiany wybierając File ⇒ Save and close.
10. Teraz możemy zdefiniować fakty w drugiej grupie helperTypes:
  1. W analogiczny sposób proszę zdefiniować następujący typ faktu:
11. Ten typ faktu będzie przechowywał informację na temat aktualnego etapu procesu przetwarzania zapytania. Tymczasowo będzie on służył do wymuszenia częściowego porządku/sekwencji uruchamiania reguł. W przyszłości typ ten zostanie usunięty, a jego funkcjonalność zastąpiona modelem procesu.
12. W naszym przykładzie pole state będzie typu Text i będzie posiadało skończoną, ściśle określoną dziedzinę. Dlatego, możemy zdefiniować dla tego pola listę dozwolonych wartości. Lista ta uchroni nas także przed błędnym zdefiniowaniem wartości - możliwe opcje będą wybierane z rozwijanej listy.
13. Aby stworzyć listę enumerowaną należy:
  1. W lewym panelu wybrać Create New ⇒ New Enumeration.
  2. W oknie dialogowym:
    - wybieramy opcję Create new,
    - podajemy nazwę np. sthuc-enums,
    - wybieramy opcję Create in Package:
    - upewniamy się że obiekt zostanie utworzony w naszym pakiecie.
  3. W przypadku starej wersji interfejsu, gdzie pojawia się pole edycji, po utworzeniu obiektu, w oknie edycji wpisujemy taki tekst:
```
'State.state' : ['initial', 'formal']
```
  4. W przypadku nowej wersji interfejsu, gdzie wypełniamy wartości w kolumnach Fact, Field oraz Context uzupełniamy:
    - Fact: State
    - Field: state
    - Contex: ['initial', 'formal']
  5. Zapisujemy zmiany: File ⇒ Save and close.

Definiowanie prostych reguł

Mając zdefiniowane fakty możemy przystąpić do definiowania reguł.
W razie potrzeby należy zdefiniować inne potrzebne typy faktów.
Potrzebne nam będą cztery reguły:
1. Reguła inicjalizująca bazę wiedzy poprzez dodanie nowych faktów.
2. Reguła odpowiedzialna za zadanie pytań użytkownikowi, pobranie odpowiedzi i aktualizację bazy wiedzy.
3. Reguła generująca decyzję że dane zapytanie ofertowe może przejść do kolejnego kroku analizy.
4. Reguła generująca decyzję że dane zapytanie ofertowe powinno zostać odrzucone.
Najpierw zdefiniujemy regułę inicjalizująca bazę wiedzy:
1. W lewym panelu wybieramy: Create New ⇒ New Rule.
2. W oknie dialogowym:
  1. wybieramy opcję Create new,
  2. wpisujemy nazwę reguły np. initial,
  3. z listy Type (format) of rule: wybieramy Business Rule (Guided Editor),
  4. wybieramy opcję Create in package
  5. upewniamy się że reguła zostanie utworzona w naszym pakiecie - wybieramy z listy rozwijanej nazwę naszego pakietu.
3. Pojawia się okno dialogowe:
  1. Ponieważ jest to reguła inicjalizacyjna, która powinna zostać uruchomiona bezwarunkowo zaraz na początku, nie definiujemy jej części warunkowej, tylko decyzyjną:
    1. Klikamy przycisk PLUS w sekcji THEN.
    2. Pojawia się nam okno dialogowe z możliwością wyboru typu akcji jaką chcemy dodać do reguły. Zawartość tego okna zmienia się w zależności o kontekstu, typu zdefiniowanych faktów, itp. Jeżeli okno nie zawierałoby żądanych opcji to używając Add free form drl możemy zdefiniować je ręcznie.
    3. W naszym przypadku chcemy, aby reguła inicjalizacyjna dodała do bazy wiedzy po jednym fakcie gromadzącym wiedzę na temat poszczególnych czynników weryfikacji na poziomie formalnym. Aby dodać pierwszy fakt wybieramy:
      1. Insert fact reqsFormalAcquisition… - lub inny fakt (pochodny).
      2. Klikamy OK.
      3. W części decyzyjnej naszej reguły pojawia się pierwsza pozycja. Podczas dodawania nowego faktu możemy określić wartości pól tego faktu. My chcemy aby pole:
        
        Asked było równe false jako że jeszcze pytanie dotyczące danej kwestii nie było jeszcze zadane użytkownikowi.
        
        ProceedAnswer było równe wartości umożliwiającej dalsze przetwarzanie zapytania ofertowego.
        
        Question przyjęło wartość pytania skierowanego do użytkownika.
      4. Tak więc aby określić wartości tych pól:
        
        Klikamy na nowo dodaną pozycję w części decyzyjnej
        
        W oknie, które się pojawiło wybieramy pole którego wartość chcemy ustawić.
        
        Pole Bound variable pozostawiamy puste.
        
        W definicji akcji pojawia się nazwa wybranego pola. Teraz należy jeszcze określić wartość pola. W tym celu klikamy symbol ołówka znajdującego się na prawo przy nazwie pola i w oknie dialogowym klikamy przycisk Literal value umożliwiający definicję wartości przy pomocy stałej. (Przycisk Formula umożliwia zdefiniowanie wartości przy pomocy zmiennej lub całego wyrażenia).
        
        W przypadku pola Asked wybieramy z listy rozwijanej wartość false.
        
        W przypadku pola Question wpisujemy pytanie np. Czy istnieje możliwość pozyskania [true/false] - proponuje się pominąć znak zapytania na końcu.
    4. W analogiczny sposób dodajemy pozostałe fakty, które będą pytać użytkownika o spełnienie wymagań (powinno ich być w sumie 6).
    5. Na końcu należy dodać fakt pomocniczy State opisujący że część inicjalizacyjna się zakończyła poprzez ustawienie pola state na wartość formal.
    6. Definicja gotowej reguły powinna wyglądać mniej więcej tak:
4. Aby zapisać i zakończyć pracę nad regułą wybieramy File ⇒ Save and close.
Druga reguła, którą należy zdefiniować będzie miała za zadanie wyświetlić pytania i pobrać na nie odpowiedzi:
1. Tworzymy nową regułę o nazwie np. reqsFormalFill.
2. Reguła powinna zostać uruchomiona jeżeli spełnione są następujące warunki:
  1. Istnieje fakt typu State gdzie pole state jest równe formal,
  2. Istnieją fakty typu reqsFormal (lub pochodnego), na które użytkownik jeszcze nie odpowiedział (pole Asked równe false).
3. Jeżeli w bazie wiedzy istnieją fakty, które spełniają powyższe warunki to dla każdego takiego faktu reguła powinna:
  1. wyświetlić pytanie,
  2. pobrać odpowiedź,
  3. zmodyfikować fakt dla którego została uruchomiona.
4. Teraz przystąpimy do stworzenia takiej reguły. W tym celu:
  1. Dodajemy pierwszy warunek: Istnieje fakt typu State gdzie pole state jest równe formal.
    1. Klikamy przycisk PLUS w sekcji WHEN,
    2. w poznanym już oknie dialogowym mamy teraz inną zawartość. Wybieramy z niej opcję State…,
    3. klikamy OK.
    4. W części warunkowej pojawia się nowa pozycja: There is a State:.
    5. Klikamy na nowo powstały warunek i nowym oknie dialogowym, w polu Add a restriction on a field wybieramy pole state.
    6. Nazwa nowego pola została dodana do warunku:
    7. Z listy rozwijanej wybieramy operator equal to, a następnie
    8. w znany już sposób definiujemy wartość ograniczenia.
  2. W ten sam sposób dodajemy warunek: Istnieją fakty typu reqsFormal (lub pochodnego), na które użytkownik jeszcze nie odpowiedział (pole Asked równe false).
  3. Reguła zostanie uruchomiona dla każdego faktu typu reqsFormal (lub pochodnego), który później musi zostać zmodyfikowany. Aby móc jakoś odnieść się do instancji faktu dla którego reguła została uruchomiona musimy zapisać go w jakiejś zmiennej. W tym celu w formularzu modyfikacji warunku ustawiamy nazwę zmiennej w polu Variable name:
  4. Kompletna część warunkowa reguły powinna przypominać:
  5. Teraz możemy przystąpić do zdefiniowania części decyzyjnej.
  6. Pierwszą akcją jest wyświetlenie pytania dla użytkownika - interakcja z użytkownikiem będzie się odbywać przy pomocy konsoli - w tym celu jako pierwszą akcję wybieramy Add free form drl….
    1. W polu, które się pojawi wpisujemy kod w języku java:
      System.out.println(r.Question + "?");
      
      Dzięki zmiennej r w której zapisaliśmy instancję faktu dla której reguła jest uruchomiona, możemy teraz odnieść się do pola przechowującego treść pytania i wyświetlić je użytkownikowi.
  7. Drugą akcją jest pobranie odpowiedzi od użytkownika i zapisanie jej w instancji faktu. W tym celu podobnie jak w poprzednim punkcie dodajemy akcję Add free form drl… i polu wpisujemy:
```
java.io.InputStreamReader rd = new java.io.InputStreamReader(System.in);
java.io.BufferedReader bfr = new java.io.BufferedReader(rd);
java.lang.Boolean val = Boolean.valueOf(bfr.readLine());
r.setAnswer( val );
```
  8. Ostatnią akcją jest zmodyfikowanie wartości pola Asked w instancji faktu na wartość true - użytkownik już udzielił odpowiedzi na pytanie. W tym celu
    1. dodajemy nową akację Modify r…
      Pytanie: (czym różni się od akcji Change field values of r…?),
    2. określamy pole i jego nową wartość.
  9. Kompletna reguła powinna przypominać:
Trzecia i czwarta reguła są uruchamiane gdy jest już wiadomo jakie ma być dalsze postępowanie w procesie przetwarzania oferty:
- reqsFormalOK: Oferta może być dalej przetwarzana jeżeli odpowiedź na wszystkie pytania była zgodna z ProceedAnswer.
- reqsFormalFail: Oferta nie może być dalej przetwarzana jeżeli odpowiedź na przynajmniej jedno pytanie nie była zgodna z ProceedAnswer.
Reguła reqsFormalOK jest uruchamiana gdy proces przetwarzania oferty powinien być kontynuowany tzn. gdy spełnione są następujące warunki (proszę zdefiniować samodzielnie):
1. Istnieje fact typu Sate którego wartość pola state jest równa formal.
2. Nie istnieje żaden fakt typu reqsFormal (lub pochodnego), który spełniałby jeden z poniższych warunków:
  1. Pole Asked jest równe false.
  2. Pole Asked jest równe true oraz Answer nierówne ProceedAnswer.
Reguła reqsFormalFail jest uruchamiana gdy proces przetwarzania oferty nie powinien być kontynuowany. Regułę proszę zdefiniować samodzielnie.
W części decyzyjnej obydwóch reguł należy dodać nowy fakt do bazy faktów, który mówi o decyzji podjętej na etapie analizy formalnej. W tym celu proszę dodać fakt typu formalDecision ustawiając odpowiednio pole Decision na:
- true jeżeli fakt jest dodawany przez regułę reqsFormalOK
- false jeżeli fakt jest dodawany przez regułę reqsFormalFail
W obu regułach proszę także zdefiniować akcję wyświetlającą na konsoli informację o decyzji po analizie formalnej. Dodatkowo reguła reqsFormalFail powinna wyświetlić powód odrzucenia oferty w postaci pytania na które udzielono niezgodnej odpowiedzi.