SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu:

Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR  (Źródło: SBVR)

A dzisiaj kilka słów na temat aneksu:  Annex F – The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty):

1. Pierwszoplanowe, a nie wtórne, wymagania  1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część.
2. Oddzielone od procesów, a nie zawierające się w nich 2.1. Reguły są bezpośrednimi ograniczeniami narzuconymi na funkcjonowanie organizacji jak również mogą stanowić wsparcie dla jej funkcjonowania. 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte. 2.3. Reguły mają zastosowanie ponad i pomiędzy procesami i procedurami. Powinny stanowić jeden spójny organizm, stosowany konsekwentnie w odpowiednich obszarach aktywności biznesowej.
3. Świadomie rozwijana dziedzina wiedzy, nie produkt uboczny 3.1. Reguły budowane są na faktach, a fakty budowane są na koncepcjach wyrażonych poprzez terminy. 3.2. Terminy wyrażają koncepcje biznesowe; fakty dostarczają stwierdzeń odnośnie tych koncepcji , reguły ograniczają oraz wzbogacają te fakty. 3.3. Reguły muszą być wyrażone explicite. Reguły nie stanowią domniemań odnośnie koncepcji, czy faktów. 3.4. Reguły stanowią podstawę tego, co biznes wie o sobie ? to znaczy, podstawę wiedzy biznesowej. 3.5. O reguły powinno się dbać; reguły powinny być chronione oraz zarządzane.
4. Deklaratywne, nie imperatywne 4.1. Reguły powinny być wyrażane deklaratywnie w formie zdań w języku naturalnym dla docelowego odbiorcy biznesowego. 4.2. Jeżeli coś nie może być wyrażone, nie jest regułą. 4.3. Zbiór wyrażeń uznaje się za deklaratywny, gdy wyrażenia w zbiorze nie zależne od jakiegokolwiek uporządkowania. 4.4. Dowolne wyrażenie dotyczące reguł, które wymaga konstrukcji różnych od pojęć i faktów implikuje założenia odnośnie systemowej implementacji. 4.5. Reguła jest różna od jakiegokolwiek zastosowania dla niej zdefiniowanego. Reguła oraz jej zastosowanie powinny być rozważane oddzielnie. 4.6. Reguły powinny być definiowane niezależnie od tego kto, gdzie, kiedy i jak je zastosuje. 4.7. Wyjątki od reguł są wyrażane innymi regułami.
5. Precyzyjnie skonstruowane wyrażenie, nie zlepek wyrazów 5.1. Reguły biznesowe powinny być wyrażane w sposób pozwalający na walidację ich poprawności przez ludzi biznesu. 5.2. Reguły biznesowe powinny być wyrażane w sposób pozwalający na weryfikację ich wzajemnej spójności. 5.3. Logiki formalne, takie jak logika predykatów, są fundamentem dobrze wyrażonych reguł, wykorzystujących terminy biznesowe oraz technologii implementujących reguły.
6. Architektura oparta o reguły, nie mimowolne zastosowanie 6.1. Aplikacja reguł biznesowych jest budowana z myślą o absorpcji stałych zmian reguł biznesowych. Platforma, na której działa aplikacja powinna uwzględniać konieczność wprowadzania ciągłych zmian. 6.2. Bezpośrednie wykonywanie reguł biznesowych ? dla przykładu w silniku reguł biznesowych ? jest lepszą strategią implementacji od przekształcania reguł do postaci proceduralnej. 6.3. System reguł biznesowych musi być w stanie zawsze wyjaśnić powody dochodzenia do określonych wniosków albo podjęcia określonych akcji. 6.4. Reguły są oparte na prawdziwych wartościach. Sposób wyznaczania oraz pielęgnowania prawdziwości reguł jest ukryty przed użytkownikami. 6.5. Związek łączący zdarzenia oraz reguły ma liczność wiele-do-wielu.
7. Procesy ukierunkowane na reguły, a nie programowanie oparte o sytuacje wyjątkowe 7.1. Reguły definiują granicę pomiędzy akceptowanymi i nieakceptowanymi działaniami. 7.2. Reguły często wymagają specjalnej lub selektywnej obsługi wykrytych odstępstw. Taka obsługa odstępstwa jest aktywnością jak wszystkie inne aktywności. 7.3. Obsługa nieakceptowalnych działań powinna być oddzielona od obsługi działań akceptowalnych w celu maksymalizacji spójności oraz zwiększenia liczby wielokrotnego wykorzystania reguł.

Kluczowe elementy manifestu pogrubiłem.

Kolejną ważną rzeczą jest zwrócenie uwagi na bardzo ważną, i w zasadzie oczywistą rzecz: liczba możliwych scenariuszy partii szachów dla człowieka jest niewyobrażalna jednak zasady gry w szachy decydujące o tych scenariuszach mieszczą się na dwóch stronach A4. Podobnie ma się rzecz z większością gier. Czemu o tym piszę? To co się z dnia na dzień dzieje w firmach i organizacjach to kolejne rozgrywki tej samej gry. Reguły są stałe: prawo i wewnętrzne regulacje, liczba możliwych scenariuszy nieskończona… Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą. Polecam punkt 7. manifestu (powyżej). Prosty  przykład: umowa handlowa danej firmy jest ważna, jeżeli jest podpisana przez osoby uprawnione (opis w KRS). W tym momencie wypisywanie (np. na modelach procesów) wszelkich możliwych kombinacji zebrania tych podpisów jest niczym innym jak brnięciem w opisywanie kolejnych możliwych partii szachów. Robienie tego, po pierwsze nie doprowadzi do wypisania wszystkich wariantów (jest ich zbyt wiele), po drugie ewentualne tworzenie na podstawie takiego opisu, oprogramowania, nie doprowadzi do postania sensownego systemu bo będzie z zasady (zbyt wiele kombinacji do opisani) niekompletny.

Pora na SBVR, stanowi on w dużym stopniu sformalizowaną i rozszerzona wersję Manifestu Reguł Biznesowych (autorzy Manifestu są współautorami SBVR, pracują dla OMG).

Czym jest reguła biznesowa? Podam przykład:

Każdy wniosek zakupowy, którego wartość przekracza III próg decyzyjny, musi być kierowany do zatwierdzenia przez członka zarządu, za wyjątkiem zamówień na surowce do produkcji z tytułu zawartych umów.

Popatrzmy na powyższą regułę i diagram nad nią. Kolorem czarnym oznaczono “operatory”, kolorem czerwonym kluczowe pojęcia (koncepty) zaś zielonym “fakty” (czasowniki związane z pojęciami), które łączą logicznie pojęcia. Kluczowe pojęcia to “byty” w biznesowej przestrzeni nazw, wymagające precyzyjnej definicji.

Nie brnąc w szczegóły, wyobraźcie sobie teraz – wiedząc, że rodzajów kosztów  jest bardzo dużo, jak wyglądał by model procesu, mający opisać je wszystkie? A wystarczy na modelu procesu biznesowego użyć pojęcia (nośnik danych w BPMN) Wniosek zakupowy, rolę Członek zarządu, pojęcie Zamówienie, zdefiniowane pojęcie “próg decyzyjny” oraz powołać się na powyższą regułę biznesową, by stworzyć model procesu przyjmowania faktur kosztowych łatwy w percepcji i nie zajmujący więcej niż stronę A4.

Do testowania modelu pojęciowego tworzy się, opisany w specyfikacji SBVR, diagram faktów.  Modele pojęciowe można tworzyć z pomocą diagramu klas notacji UML (patrz tekst Cholerny diagram klas).  Jednak w SBVR diagram faktów to nie jest diagram klas. Diagram faktów opisałem w artykule Reguły biznesowe jako motor... tu tylko wyjaśnię, że diagram faktów to diagram zawierający wyłącznie kluczowe pojęcia słownika pojęć oraz fakty (patrz wyżej kolor zielony) je łączące.

Reguły biznesowe, także jako wymagania, są elementem modeli modelu bezsensowego CIM w MDA:

Na koniec jako przykład model pojęciowy i tekst na bazie którego powstał (analiza opisu spółki giełdowej):