SBVR to spe­cy­fi­ka­cja opi­su­ją­ca two­rze­nie mode­li poję­cio­wych, słow­ni­ków pojęć i reguł biz­ne­so­wych. Aktualną wer­sje spe­cy­fi­ka­cji moż­na pobrać tu:

Semantics Of Business Vocabulary And Rules (SBVR)The cur­rent ver­sion is found at Formal Versions Of SBVR (Źródło: SBVR)

A dzi­siaj kil­ka słów na temat anek­su: Annex F – The Business Rules Approach i związ­ku mode­li poję­cio­wych z regu­ła­mi biz­ne­so­wy­mi. Aneks zawie­ra wyciąg klu­czo­wych punk­tów Manifestu Reguł Biznesowych (klu­czo­we punkty):

1. Pierwszoplanowe, a nie wtór­ne, wyma­ga­nia 1.1. Reguły są pierw­szo­pla­no­wy­mi oby­wa­te­la­mi świa­ta wyma­gań. 1.2. Reguły są klu­czo­we dla mode­li biz­ne­so­wych oraz tech­no­lo­gicz­nych, sta­no­wiąc jed­no­cze­śnie ich auto­no­micz­ną część.
2. Oddzielone od pro­ce­sów, a nie zawie­ra­ją­ce się w nich 2.1. Reguły są bez­po­śred­ni­mi ogra­ni­cze­nia­mi narzu­co­ny­mi na funk­cjo­no­wa­nie orga­ni­za­cji jak rów­nież mogą sta­no­wić wspar­cie dla jej funk­cjo­no­wa­nia. 2.2. Reguły nie są pro­ce­sa­mi ani pro­ce­du­ra­mi. Nie powin­ny być w nich zawar­te. 2.3. Reguły mają zasto­so­wa­nie ponad i pomię­dzy pro­ce­sa­mi i pro­ce­du­ra­mi. Powinny sta­no­wić jeden spój­ny orga­nizm, sto­so­wa­ny kon­se­kwent­nie w odpo­wied­nich obsza­rach aktyw­no­ści biznesowej.
3. Świadomie roz­wi­ja­na dzie­dzi­na wie­dzy, nie pro­dukt ubocz­ny 3.1. Reguły budo­wa­ne są na fak­tach, a fak­ty budo­wa­ne są na kon­cep­cjach wyra­żo­nych poprzez ter­mi­ny. 3.2. Terminy wyra­ża­ją kon­cep­cje biz­ne­so­we; fak­ty dostar­cza­ją stwier­dzeń odno­śnie tych kon­cep­cji , regu­ły ogra­ni­cza­ją oraz wzbo­ga­ca­ją te fak­ty. 3.3. Reguły muszą być wyra­żo­ne expli­ci­te. Reguły nie sta­no­wią domnie­mań odno­śnie kon­cep­cji, czy fak­tów. 3.4. Reguły sta­no­wią pod­sta­wę tego, co biz­nes wie o sobie ? to zna­czy, pod­sta­wę wie­dzy biz­ne­so­wej. 3.5. O regu­ły powin­no się dbać; regu­ły powin­ny być chro­nio­ne oraz zarządzane.
4. Deklaratywne, nie impe­ra­tyw­ne 4.1. Reguły powin­ny być wyra­ża­ne dekla­ra­tyw­nie w for­mie zdań w języ­ku natu­ral­nym dla doce­lo­we­go odbior­cy biz­ne­so­we­go. 4.2. Jeżeli coś nie może być wyra­żo­ne, nie jest regu­łą. 4.3. Zbiór wyra­żeń uzna­je się za dekla­ra­tyw­ny, gdy wyra­że­nia w zbio­rze nie zależ­ne od jakie­go­kol­wiek upo­rząd­ko­wa­nia. 4.4. Dowolne wyra­że­nie doty­czą­ce reguł, któ­re wyma­ga kon­struk­cji róż­nych od pojęć i fak­tów impli­ku­je zało­że­nia odno­śnie sys­te­mo­wej imple­men­ta­cji. 4.5. Reguła jest róż­na od jakie­go­kol­wiek zasto­so­wa­nia dla niej zde­fi­nio­wa­ne­go. Reguła oraz jej zasto­so­wa­nie powin­ny być roz­wa­ża­ne oddziel­nie. 4.6. Reguły powin­ny być defi­nio­wa­ne nie­za­leż­nie od tego kto, gdzie, kie­dy i jak je zasto­su­je. 4.7. Wyjątki od reguł są wyra­ża­ne inny­mi regułami.
5. Precyzyjnie skon­stru­owa­ne wyra­że­nie, nie zle­pek wyra­zów 5.1. Reguły biz­ne­so­we powin­ny być wyra­ża­ne w spo­sób pozwa­la­ją­cy na wali­da­cję ich popraw­no­ści przez ludzi biz­ne­su. 5.2. Reguły biz­ne­so­we powin­ny być wyra­ża­ne w spo­sób pozwa­la­ją­cy na wery­fi­ka­cję ich wza­jem­nej spój­no­ści. 5.3. Logiki for­mal­ne, takie jak logi­ka pre­dy­ka­tów, są fun­da­men­tem dobrze wyra­żo­nych reguł, wyko­rzy­stu­ją­cych ter­mi­ny biz­ne­so­we oraz tech­no­lo­gii imple­men­tu­ją­cych reguły.
6. Architektura opar­ta o regu­ły, nie mimo­wol­ne zasto­so­wa­nie 6.1. Aplikacja reguł biz­ne­so­wych jest budo­wa­na z myślą o absorp­cji sta­łych zmian reguł biz­ne­so­wych. Platforma, na któ­rej dzia­ła apli­ka­cja powin­na uwzględ­niać koniecz­ność wpro­wa­dza­nia cią­głych zmian. 6.2. Bezpośrednie wyko­ny­wa­nie reguł biz­ne­so­wych ? dla przy­kła­du w sil­ni­ku reguł biz­ne­so­wych ? jest lep­szą stra­te­gią imple­men­ta­cji od prze­kształ­ca­nia reguł do posta­ci pro­ce­du­ral­nej. 6.3. System reguł biz­ne­so­wych musi być w sta­nie zawsze wyja­śnić powo­dy docho­dze­nia do okre­ślo­nych wnio­sków albo pod­ję­cia okre­ślo­nych akcji. 6.4. Reguły są opar­te na praw­dzi­wych war­to­ściach. Sposób wyzna­cza­nia oraz pie­lę­gno­wa­nia praw­dzi­wo­ści reguł jest ukry­ty przed użyt­kow­ni­ka­mi. 6.5. Związek łączą­cy zda­rze­nia oraz regu­ły ma licz­ność wiele-do-wielu.
7. Procesy ukie­run­ko­wa­ne na regu­ły, a nie pro­gra­mo­wa­nie opar­te o sytu­acje wyjąt­ko­we 7.1. Reguły defi­niu­ją gra­ni­cę pomię­dzy akcep­to­wa­ny­mi i nie­ak­cep­to­wa­ny­mi dzia­ła­nia­mi. 7.2. Reguły czę­sto wyma­ga­ją spe­cjal­nej lub selek­tyw­nej obsłu­gi wykry­tych odstępstw. Taka obsłu­ga odstęp­stwa jest aktyw­no­ścią jak wszyst­kie inne aktyw­no­ści. 7.3. Obsługa nie­ak­cep­to­wal­nych dzia­łań powin­na być oddzie­lo­na od obsłu­gi dzia­łań akcep­to­wal­nych w celu mak­sy­ma­li­za­cji spój­no­ści oraz zwięk­sze­nia licz­by wie­lo­krot­ne­go wyko­rzy­sta­nia reguł.

Kluczowe ele­men­ty mani­fe­stu pogrubiłem.

Kolejną waż­ną rze­czą jest zwró­ce­nie uwa­gi na bar­dzo waż­ną, i w zasa­dzie oczy­wi­stą rzecz: licz­ba moż­li­wych sce­na­riu­szy par­tii sza­chów dla czło­wie­ka jest nie­wy­obra­żal­na jed­nak zasa­dy gry w sza­chy decy­du­ją­ce o tych sce­na­riu­szach miesz­czą się na dwóch stro­nach A4. Podobnie ma się rzecz z więk­szo­ścią gier. Czemu o tym piszę? To co się z dnia na dzień dzie­je w fir­mach i orga­ni­za­cjach to kolej­ne roz­gryw­ki tej samej gry. Reguły są sta­łe: pra­wo i wewnętrz­ne regu­la­cje, licz­ba moż­li­wych sce­na­riu­szy nie­skoń­czo­na… Czemu więc słu­żą żmud­ne wywia­dy, warsz­ta­ty, burze mózgów w toku ana­liz firm? Zaryzykuję, tezę, że nicze­mu nie słu­żą. Polecam punkt 7. mani­fe­stu (powy­żej). Prosty przy­kład: umo­wa han­dlo­wa danej fir­my jest waż­na, jeże­li jest pod­pi­sa­na przez oso­by upraw­nio­ne (opis w KRS). W tym momen­cie wypi­sy­wa­nie (np. na mode­lach pro­ce­sów) wszel­kich moż­li­wych kom­bi­na­cji zebra­nia tych pod­pi­sów jest niczym innym jak brnię­ciem w opi­sy­wa­nie kolej­nych moż­li­wych par­tii sza­chów. Robienie tego, po pierw­sze nie dopro­wa­dzi do wypi­sa­nia wszyst­kich warian­tów (jest ich zbyt wie­le), po dru­gie ewen­tu­al­ne two­rze­nie na pod­sta­wie takie­go opi­su, opro­gra­mo­wa­nia, nie dopro­wa­dzi do posta­nia sen­sow­ne­go sys­te­mu bo będzie z zasa­dy (zbyt wie­le kom­bi­na­cji do opi­sa­ni) niekompletny.

Pora na SBVR, sta­no­wi on w dużym stop­niu sfor­ma­li­zo­wa­ną i roz­sze­rzo­na wer­sję Manifestu Reguł Biznesowych (auto­rzy Manifestu są współ­au­to­ra­mi SBVR, pra­cu­ją dla OMG).

Czym jest regu­ła biz­ne­so­wa? Podam przykład:

Każdy wnio­sek zaku­po­wy, któ­re­go war­tość prze­kra­cza III próg decy­zyj­ny, musi być kie­ro­wa­ny do zatwier­dze­nia przez człon­ka zarzą­du, za wyjąt­kiem zamó­wień na surow­ce do pro­duk­cji z tytu­łu zawar­tych umów.

Popatrzmy na powyż­szą regu­łę i dia­gram nad nią. Kolorem czar­nym ozna­czo­no ​„ope­ra­to­ry”, kolo­rem czer­wo­nym klu­czo­we poję­cia (kon­cep­ty) zaś zie­lo­nym ​„fak­ty” (cza­sow­ni­ki zwią­za­ne z poję­cia­mi), któ­re łączą logicz­nie poję­cia. Kluczowe poję­cia to ​„byty” w biz­ne­so­wej prze­strze­ni nazw, wyma­ga­ją­ce pre­cy­zyj­nej definicji.

Nie brnąc w szcze­gó­ły, wyobraź­cie sobie teraz – wie­dząc, że rodza­jów kosz­tów jest bar­dzo dużo, jak wyglą­dał by model pro­ce­su, mają­cy opi­sać je wszyst­kie? A wystar­czy na mode­lu pro­ce­su biz­ne­so­we­go użyć poję­cia (nośnik danych w BPMN) Wniosek zaku­po­wy, rolę Członek zarzą­du, poję­cie Zamówienie, zde­fi­nio­wa­ne poję­cie ​„próg decy­zyj­ny” oraz powo­łać się na powyż­szą regu­łę biz­ne­so­wą, by stwo­rzyć model pro­ce­su przyj­mo­wa­nia fak­tur kosz­to­wych łatwy w per­cep­cji i nie zaj­mu­ją­cy wię­cej niż stro­nę A4.

Do testo­wa­nia mode­lu poję­cio­we­go two­rzy się, opi­sa­ny w spe­cy­fi­ka­cji SBVR, dia­gram fak­tów. Modele poję­cio­we moż­na two­rzyć z pomo­cą dia­gra­mu klas nota­cji UML (patrz tekst Cholerny dia­gram klas). Jednak w SBVR dia­gram fak­tów to nie jest dia­gram klas. Diagram fak­tów opi­sa­łem w arty­ku­le Reguły biz­ne­so­we jako motor... tu tyl­ko wyja­śnię, że dia­gram fak­tów to dia­gram zawie­ra­ją­cy wyłącz­nie klu­czo­we poję­cia słow­ni­ka pojęć oraz fak­ty (patrz wyżej kolor zie­lo­ny) je łączące.

Reguły biz­ne­so­we, tak­że jako wyma­ga­nia, są ele­men­tem mode­li mode­lu bez­sen­so­we­go CIM w MDA:

Na koniec jako przy­kład model poję­cio­wy i tekst na bazie któ­re­go powstał (ana­li­za opi­su spół­ki giełdowej):