Język czy notacja czyli co?

Od cza­su do cza­su jestem pyta­ny czy UML, BPMN, itp.. to nota­cje czy języ­ki, a pada­ją nawet pyta­nia czy to meto­dy. Otóż meto­dy na pew­no nie… (np. mamy dwie meto­dy mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: z uży­ciem nota­cji BPMN i nota­cji eEPC). A pozo­sta­łe dwa?

Nie jest to pro­ste. Dzisiaj pój­dę może nie­co na skró­ty dla­te­go wni­kli­wym pole­cam lek­tu­rę przede wszyst­kim na temat semio­ty­ki, logi­ki i rachun­ku zdań.

Język i znaczenie

Na począ­tek kil­ka defi­ni­cji ogól­nych (wszyst­kie sł. j. pol­skie­go PWN):

język
5. ?utrwa­lo­ny spo­łecz­nie zespół zna­ków doty­czą­cych jakichś dzia­łań czło­wie­ka lub wyra­ża­ją­cych jego emo­cje oraz każ­dy układ ele­men­tów rze­czy­wi­sto­ści, któ­re­mu czło­wiek nadał jakąś treść?

Język jest więc okre­ślo­nym zespo­łem norm, są nimi jed­nak nie tyl­ko zna­ki ale tak­że to, co zna­czą i jaką treść nio­są. Wyrażanie emo­cji czy myśli w ogó­le, rzad­ko jest moż­li­we z uży­ciem tyl­ko jed­ne­go zna­ku. Dlatego w toku ich wyra­ża­nia ope­ru­je­my raczej zdaniami:

zda­nie
1. ?myśl wyra­żo­na słowami?
4. log. ?sen­sow­ne wyra­że­nie oznaj­mia­ją­ce pod­le­ga­ją­ce falsyfikacji?

Tu zaczy­na­my powo­li iść w porząd­ko­wa­nie tego o czym piszę. Każde zda­nie (w logi­ce) może być praw­dzi­we lub nie (tau­to­lo­gia jest zda­niem zawsze praw­dzi­wym, czy­li jest zna­ny fakt je fal­sy­fi­ku­ją­cy ale wie­my, że nigdy taki nie wystą­pi). Jeżeli więc, że treść naj­czę­ściej wyra­ża­my sło­wa­mi (a raczej rzad­ko nie jed­nym sło­wem) to zna­czy, że nale­ży umieć odczy­tać zna­cze­nie zło­że­nia wie­lu słów w jed­nym zda­niu. Jak wie­my o zro­zu­mia­ło­ści (zro­zu­mia­łość ozna­cza, że zda­nie ma dla czy­ta­ją­ce­go okre­ślo­ne zna­cze­nie) decy­du­je układ słów w zda­niu, zna­ki inter­punk­cyj­ne itp.

przecinek

Nawet prze­ci­nek ma zna­cze­nie (jest on ele­men­tem języ­ka) w zda­niu złożonym.

Jednoznaczność (zro­zu­mia­łość, zna­cze­nie) zdań jest tak­że efek­tem kontekstu:

kon­tekst
1. ?frag­ment tek­stu potrzeb­ny do dokład­ne­go rozu­mie­nia danych wyra­zów lub wyrażeń?
3. ?zespół jed­no­stek języ­ko­wych, któ­re sta­no­wią oto­cze­nie danej jednostki?
4. ?zespół odnie­sień nie­zbęd­nych do zro­zu­mie­nia utwo­ru lite­rac­kie­go, dzie­ła nauko­we­go itp.?

zakaz dobijania dziobem niejednoznacznoscJeżeli napi­szę Te dwie kro­wy są paskud­ne” to nadal nie ma pew­no­ści o czym mowa. Bez wie­dzy o tym, czy to roz­mo­wa dwóch rol­ni­ków o inwen­ta­rzu, czy też dwóch kole­ża­nek o dwóch innych, nie wie­my. Słowo palant” tak­że ma wię­cej niż jed­no zna­cze­nie i bez kon­tek­stu jego uży­cia nie wie­my o jakie zna­cze­nie cho­dzi (kole­ga czy mało już popu­lar­na gra) :). Bardzo czę­sto to wła­śnie kon­tekst nada­je znaczenie.

Jak widać zro­zu­mie­nie prze­ka­zu nie musi być pro­ste, a komu­ni­ka­cja pro­sta i łatwa (każ­dy kto się choć raz pokłó­cił z powo­du nie­po­ro­zu­mień o tym wie). Kontekstem zaj­mu­je się:

prag­ma­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem są spo­łecz­ne i sytu­acyj­ne warun­ki funk­cjo­no­wa­nia języ­ka oraz cele, jakie mówią­cy chce osią­gnąć przez uży­cie okre­ślo­nych wyra­zów i wyrażeń?

Należy pamię­tać, że zna­cze­nie mają nie tyl­ko poje­dyn­cze sło­wa (zna­ki) ale tak­że ich zło­że­nia („pro­ces biz­ne­so­wy” to jed­no poję­cie ale dwa sło­wa). Innymi sło­wy kon­kret­ne poję­cie może być zapi­sa­ne z uży­ciem jed­ne­go lub wię­cej znaków.

sło­wo
1. ?znak języ­ko­wy mają­cy jakieś znaczenie?

Dlatego zło­że­nie kil­ku zna­ków (słów) tak­że jest zna­kiem (defi­ni­cja sło­wa i słowo/pojęcie przez nią defi­nio­wa­ne, nio­są toż­sa­me zna­cze­nie). Słowo (rozu­mia­ne jako zapis: zło­że­nie liter) moż­na zastą­pić sym­bo­lem gra­ficz­nym (iko­na). O tym traktuje

semio­ty­ka
1. ?ogól­na teo­ria zna­ku w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

w tym:

seman­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem jest ana­li­za zna­czeń wyrazów?
2. ?dział semio­ty­ki zaj­mu­ją­cy się bada­niem związ­ków, jakie zacho­dzą mię­dzy wyra­że­nia­mi języ­ka a przed­mio­ta­mi, do któ­rych się one odnoszą?

syn­tak­ty­ka
2. ?dział semio­ty­ki bada­ją­cy wza­jem­ne sto­sun­ki i wła­ści­wo­ści budo­wy wyra­żeń języ­ka w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

Zapisując coś: treść, w celu prze­ka­za­nia jej dru­giej oso­bie komu­ni­ku­je­my się:

komu­ni­ka­cja
2. ?prze­pływ infor­ma­cji mię­dzy urzą­dze­nia­mi, np. tele­fo­na­mi lub komputerami?
3. ?prze­ka­zy­wa­nie i odbie­ra­nie infor­ma­cji w bez­po­śred­nim kon­tak­cie z dru­gą osobą?

treść
1. ?to, co jest zawar­te w czy­jejś wypo­wie­dzi; też: to, co prze­ka­zu­je odbior­cy dzie­ło sztu­ki, w prze­ciw­sta­wie­niu do formy?
2. ?to, co sta­no­wi isto­tę, sens czegoś?

Do komu­ni­ka­cji uży­wa­my znaków:

znak
1. ?kształt, któ­re­mu przy­pi­su­je się okre­ślo­ne znaczenie?
2. ?dźwięk, spoj­rze­nie, gest itp. słu­żą­cy do prze­ka­za­nia informacji?

Znak zna­czy, czy­li ma okre­ślo­ne znacz­nie (pamię­ta­my o kon­tek­ście). Znakiem może być wie­le rze­czy (tak­że gest). Znak ma (nie­sie) zna­cze­nie, znak lub ich zło­że­nie tak­że, prze­ka­zu­je okre­ślo­ną treść:

zna­cze­nie
1. ?myśl zawar­ta w czy­jejś wypo­wie­dzi, w czy­imś zacho­wa­niu itp.?
3. ?treść, któ­rej zna­kiem jest wyraz lub wyrażenie?

zna­czyć
1. ?być zna­kiem czegoś?
3. ?umiesz­czać na czymś lub na kimś znak?
4. ?zosta­wiać na czymś znak, ślad?

Na koniec zosta­wi­łem, spor­ne słowo:

nota­cja ?ozna­cze­nie cze­goś umow­ny­mi zna­ka­mi; też: zbiór takich znaków?

Notacja to zbiór zna­ków. Przypomnę też, że język to mie­dzy inny­mi okre­ślo­ny zbiór zna­ków wraz z opi­sem ich zna­czeń (seman­ty­ka) oraz tym, jakie mają zna­cze­nia ich okre­ślo­ne zło­że­nia (syn­tak­ty­ka). Wiemy już, że zna­cze­nie (treść) mają nie tyl­ko poje­dyn­cze sło­wa (to rzad­ko) ale ich kon­kret­ne zło­że­nia (zda­nia). Przekazanie kon­kret­nych, jed­no­znacz­nych tre­ści, poza rzad­ki­mi wyjąt­ka­mi, wyma­ga więc zbu­do­wa­nia kon­kret­nych zdań czy­li zło­żeń słów (zna­ków)”. Innymi sło­wy, nikt chy­ba nie powie, że książ­ka jaką jest słow­nik języ­ka pol­skie­go, wraz z zasa­da­mi gra­ma­ty­ki, to jest język pol­ski”. Język to jed­nak coś wię­cej”. Słowo język jest dość nie­pre­cy­zyj­ne i ozna­cza wręcz pewien zespół norm i spo­so­bów poro­zu­mie­wa­nia się (w tym idio­my, zespo­ły słów mają­ca inne zna­cze­nie niż każ­de z nich z osob­na). Poprawne (sku­tecz­ne) posłu­gi­wa­nie się danym języ­kiem ozna­cza, że adre­sat zro­zu­miał” treść nadaw­cy (mówią­ce­go).

Porządkujemy to wszystko

Zrobiło się cięż­ko :). Poniżej model poję­cio­wy: dia­gram w nota­cji SBVR poka­zu­ją­cy poję­cia i związ­ki mię­dzy nimi. Jednym z klu­czo­wych narzę­dzi w ana­li­zie jest wła­snie ana­li­za poję­cio­wa i budo­wa­nie słow­ni­ka pojęć dla okre­ślo­nej dzie­dzi­ny (tu wię­cej o tym czy jest dia­gram fak­tów opi­sa­ny w nota­cji SBVR).

jezyk-i-notacja-model-pojeciowy

Powyższy model obra­zu­je związ­ki pomię­dzy opi­sa­ny­mi wyżej poję­cia­mi, pre­cy­zu­je tak­że ich zna­cze­nia. Model poję­cio­wy dla danej dzie­dzi­ny (tu mowa o języ­kach i nota­cjach) powi­nien się cecho­wać mię­dzy inny­mi tym, że zna­cze­nia poszcze­gól­nych pojęć powin­ny być roz­łącz­ne, czy­li speł­niać ary­sto­te­le­sow­ską zasa­dę wyłą­czo­ne­go środ­ka” w logi­ce, brzmią­cą: jeże­li coś jest czymś, to nie jest niczym innym”. Dla zacho­wa­nia jed­no­znacz­no­ści zdań, defi­ni­cje pojęć muszą się więc wza­jem­nie wyklu­czać, tak zbu­do­wa­ny słow­nik nazy­wa­my prze­strze­nią nazw” (ang. namespace).

UML i BPMN to język czy notacja?

Skrót UML zawie­ra w sobie sło­wo lan­gu­age” (ang. język). Historycznie tłu­ma­czyć to moż­na tym, że obec­ne 14 typów dia­gra­mów to kon­kret­ne kon­tek­sty oraz narzu­co­ne kon­struk­cje, któ­re moż­na nazwać zda­nia­mi” (widać to szcze­gól­nie w przy­pad­ku dia­gra­mów Przypadków uży­cia czy Rozlokowania). Jednak obec­na spe­cy­fi­ka­cja UML 2.5 porząd­ku­je i to, sło­wo lan­gu­age” w zasa­dzie nie jest w niej sto­so­wa­ne wobec tego co nazwa­no tam mia­nem UML (W zasa­dzie dzi­siaj mogła by nosić nazwę Object-orien­ted Modeling and Notation 🙂 ).

Tak więc język czy nota­cja? To zale­ży od tego czy dana spe­cy­fi­ka­cja” opi­su­je wyłącz­nie sym­bo­le czy też ich okre­ślo­ne, i zale­ca­ne w okre­ślo­nych sytu­acjach, kon­struk­cje oraz ich zna­cze­nie. OMG (chy­ba) sta­ra się to ostat­nio jasno sygna­li­zo­wać: UML to jesz­cze lan­gu­age” ale BPMN to już nota­tion”. Specyfikacja UML zawie­ra okre­ślo­ne, seman­tycz­ne (nazwa­ne) kon­struk­cje, mają­ce okre­ślo­ne zna­cze­nia, zwią­za­ne z kon­kret­ny­mi dia­gra­ma­mi (nazwa dia­gra­mu nada­je kon­tekst uży­tym na nich sym­bo­lom, jest to potrzeb­ne bo pamię­taj­my, że w UML wszyst­ko jest kla­są”). W BPMN nie ma cze­goś takie­go (nawet poję­cie pro­ces biz­ne­so­wy” nie jest czę­ścią BPMN, jest ono zde­fi­nio­wa­ne dopie­ro w Dodatku A jako obja­śnie­nie i dodat­ko­wy kon­tekst, w nota­cji zaś BPMN nie ma sym­bo­lu pro­ces biz­ne­so­wy” 🙂 ). To czy dana spe­cy­fi­ka­cja to tyko opis nota­cji czy tak­że języ­ka, zale­ży więc od kon­kret­ne­go przypadku.

usuwanie dwuznaczosci i niejasnosciNiewątpliwie UML, BPMN, CMMN, SBVR, BMM itp., to wszyst­ko są nota­cje, bo są to spe­cy­fi­ka­cje sym­bo­li, ich zna­czeń oraz okre­ślo­na syn­tak­ty­ka. Natomiast o tym co i jak wyra­ża­ją (i czy w ogó­le ;)) two­rzo­ne z ich pomo­cą dia­gra­my, to już inna kwe­stia… To leży w gestii twór­cy dia­gra­mów. A testem jest mie­dzy inny­mi sku­tecz­ność komu­ni­ka­cji: porów­na­nie tego jaką kon­kret­ną treść chciał prze­ka­zać twór­ca dane­go dia­gra­mu i jaką treść ode­brał czy­ta­ją­cy… Analityk zaczy­na od ana­li­zy poję­cio­wej by unik­nąć nie­jed­no­znacz­no­ści w samym prze­ka­zie. Potem dopie­ro doku­men­tu­je, z uży­ciem mode­li two­rzo­nych z pomo­cą nota­cji, to co zastał oraz pro­jek­tu­je to, co chciał­by by, by powsta­ło spo­sób roz­wią­za­nie pro­ble­mu (tu pole­cam lek­tu­rę arty­ku­łu gdzie pisa­łem o tym, że wyma­ga­nia to pro­jekt).

Niewątpliwie więc wszyst­kie języ­ki pro­gra­mo­wa­nia” są języ­ka­mi: mają skład­nię i każ­de zda­nie coś wyra­ża (rozu­mie to i kole­ga pro­gra­mi­sta i kom­pi­la­tor). Wiele nota­cji jed­nak języ­kiem nie jest. O języ­ku moż­na mówić tyl­ko wte­dy, gdy jest samo­wy­star­czal­ny do wyra­ża­nia okre­ślo­nych myśli i tre­ści, do komu­ni­ko­wa­nia ich. Nie może­my tego raczej powie­dzieć o nota­cjach. Diagramy i mode­le wyko­na­ne z pomo­cą w. nota­cji wyma­ga­ją sto­so­wa­nia np. języ­ka” pol­skie­go, do nada­wa­nia nazw sym­bo­lom i dia­gra­mom, bez cze­go dia­gra­my te były by nie­zro­zu­mia­łe. Uważam więc, że uży­wa­nie wobec nota­cji obli­ga­to­ryj­nie nazwy język, jest poważ­nym nad­uży­ciem… Niektóre nota­cje mają swo­ją wer­sję wyko­ny­wal­ną (tu nawią­zu­je do tego że języ­ki pro­gra­mo­wa­nia są” języ­ka­mi”) o czym nie­daw­no pisa­łem (Analityczne i wyko­ny­wal­ne mode­le) jed­nak pamię­tać, nale­ży nota­cja jako taka nie jest języ­kiem pro­gra­mo­wa­nia”, jest tu raczej for­mą budo­wa­nia mecha­ni­zmu (mode­lo­wa­nie), któ­ry dopie­ro po doda­niu wie­lu para­me­trów (czy­li wpro­wa­dze­niu wie­lu słów” z poza nota­cji) pozwa­la taki model uru­cho­mić”.

Tablice decyzyjne

Po dłu­gich poszu­ki­wa­niach w anty­kwa­ria­tach mam: Tablice decy­zyj­ne . Książka opi­su­je tabli­ce decy­zyj­ne jako narzę­dzie do mode­lo­wa­nia zacho­wa­nia sys­te­mów deterministycznych. 

Tablice te w peł­ni zastę­pu­ją znacz­nie bar­dziej skom­pli­ko­wa­ne drze­wa decy­zyj­ne, mode­lu­ją decy­zję (jej pod­ję­cie) jako jeden fakt a nie zło­żo­ny, kaska­do­wy pro­ces decy­zyj­ny . W dal­szej opis two­rze­nia i czę­ści przy­kła­dy uży­cia takich tablic.

Tablica decyzyjna

Odpowiadając na pyta­nia pod arty­ku­łem Tablice decy­zyj­ne ? fak­ty a nie pro­ce­sy, napi­sa­łem mię­dzy inny­mi, że regu­ła biz­ne­so­wa to nie regu­ła decy­zyj­na. Jeden z czy­tel­ni­ków podał jako przy­kład regu­ły biz­ne­so­wej wybór zwro­tu do osoby:

  • Płeć: męż­czy­zna ? powi­ta­nie: Pan;
  • Płeć: kobie­ta oraz Stan: mężat­ka ? powi­ta­nie: Pani;
  • Płeć: kobie­ta oraz Stan: wol­ny ? powi­ta­nie: Panna;

Powyższe to zbiór decy­zji podej­mo­wa­nych w odpo­wie­dzi na okre­ślo­ne zda­rze­nie. Takie decy­zje (i regu­ły ich podej­mo­wa­nia) moż­na zapi­sać w posta­ci tabli­cę decy­zyj­nej, powyż­sze nie jest regu­łą biz­ne­so­wą. Regułą biz­ne­so­wą było by: ?w listach adre­so­wa­nych imien­nie zawsze poprze­dza się imię i nazwi­sko oso­by wła­ści­wym zwro­tem grzecz­no­ścio­wym?. Reguły biz­ne­so­we to regu­ły zacho­wa­nia (się) systemu.

Powyższe to sys­tem podej­mo­wa­nia decy­zji o tym, jaki to powi­nien być zwrot. Jest to o tyle istot­ne, że regu­ła biz­ne­so­wa, jako regu­ła zacho­wa­nia, w nie­zmie­nio­nym brzmie­niu może obo­wią­zy­wać np. wszyst­kie oddzia­ły fir­my w innych kra­jach, ale tabli­ca decy­zyj­na to pro­ce­du­ra doko­na­nia wybo­ru wła­ści­we­go zwro­tu, będzie inna dla każ­de­go kra­ju (a kon­kret­nie każ­de­go języ­ka). Poniżej tabli­ca decy­zyj­na dla tego przy­kła­du (dla j.polskiego ;)):

DecyzjaPanPaniPanna

Tablica ta zosta­ła pod­da­na nor­ma­li­za­cji, to jest usu­nię­to waru­nek Jest płci męskiej, gdyż wiersz ten zawie­rał pro­stą nega­cje wier­sza Jest płci żeń­skiej (zakła­da­my, że nie roz­pa­tru­je­my rodza­ju nija­kie­go). Tablica taka (po nor­ma­li­za­cji) jest, jak widać, prost­sza od trzech warun­ków z przy­kła­du opi­so­we­go” sys­te­mu decy­zji. Powyższa tabli­ca jest tabli­ca zupeł­ną (wyszcze­gól­nio­no wszyst­kie kom­bi­na­cje Warunków) wiec moż­na jej użyć do auto­ma­ty­za­cji pro­ce­su np. adre­so­wa­nia kore­spon­den­cji (wię­cej o tym w dal­szej czę­ści). Wersja rów­no­waż­na uprosz­czo­na tej samej tablicy:

TabDecUprZwrot

Proponuję czy­tel­ni­kom same­mu zna­leźć zasa­dę doko­na­ne­go uprosz­cze­nia :). Ciekawe omó­wie­nie i przy­kła­dy tablic decyzyjnych:

Przykład korzy­ści z uży­cia tablic decy­zyj­nych zamiast opisu:

https://​www​.visu​al​-para​digm​.com/​p​r​o​d​u​c​t​/​a​r​t​i​c​l​e​s​/​d​e​c​i​s​i​o​n​-​t​a​b​l​e​-​e​x​p​l​a​i​n​ed/

Reguły biznesowe a reguły decyzyjne

W grud­niu ubie­głe­go roku pisałem:

Bardzo czę­sto spo­ty­kam się z ogrom­ną zło­żo­no­ścią (licz­ba i ich podzia­ły) wyma­gań. Problem tkwi nie raz w tym, że ?naro­sła? przez lata ?ster­ta zarzą­dzeń?, któ­ra zamiast zostać naj­pierw upo­rząd­ko­wa­na, jest ?wprost? trak­to­wa­na jako ?wyma­ga­nia?. Takie podej­ście to krok w stro­nę klę­ski pro­jek­tu. (Reguły biz­ne­so­we ? pro­jekt zabi­ja ich bez­sen­sow­na ilość? ).

W tam­tym tek­ście nie opi­sa­łem jed­nak o róż­ni­cy pomię­dzy regu­łą a decy­zją. Przyszła pora i na to.

Postaram się zwró­cić uwa­gę na to, że mode­lo­wa­nie biz­ne­so­we z peł­nym zro­zu­mie­niem, to nie suchy zapis wie­dzy pozy­ska­nej w roz­mo­wach czy wywia­dach. To dąże­nie do zro­zu­mie­nia. Powyższe poka­zu­je, że jest róż­ni­ca pomię­dzy regu­łą a decy­zją, nawet jeże­li ta dru­ga jest naka­za­na” tą pierw­szą. Czy to ważne?

Wiele firm ma pro­ble­my zarząd­cze nie dla­te­go, że są źle zarzą­dza­ne, ale dla­te­go, że sto­pień zło­żo­no­ści tych firm jest zbyt duży by podej­mo­wać je na wyczu­cie. W obec­nych cza­sach decy­zje muszą być podej­mo­wa­ne w rela­tyw­nie krót­kim cza­sie bo rynek nie cze­ka, jed­nak jakość tych decy­zji nie powin­na być zła. Dlaczego bywa zła? Bo decy­zje są nie raz podej­mo­wa­ne z nie­peł­nym zro­zu­mie­niem sytu­acji. Podejmowana decy­zja, by była moż­li­wie naj­lep­sza, wyma­ga peł­ne­go zro­zu­mie­nia, tego cze­go doty­czy (co chy­ba nie jest dziw­ne). Jeżeli doty­czy fir­my, nie powin­no się podej­mo­wać decy­zji bez peł­ne­go zro­zu­mie­nia poten­cjal­ne­go wpły­wu tej decy­zji na fir­mę. W prze­ciw­nym wypad­ku skut­ki są dość loso­we, czy­li nie zarzą­dza­my a sta­ra­my się zarządzać.

Przytoczony na począt­ku przy­kład doty­czą­cy zwro­tów grzecz­no­ścio­wych, poka­zu­je cien­ką gra­ni­cę pomię­dzy regu­łą a decy­zją. Jak zwy­kle u mnie ;), naj­pierw patrzy­my do słow­ni­ka j.polskiego (PWN):

regu­ła: <zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju>

decy­zja: <posta­no­wie­nie będą­ce wyni­kiem doko­na­nia wyboru>

idzie­my dalej:

zasa­da: <pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, nor­ma postępowania>

wybór: <wybra­nie jed­nej z kil­ku możliwości>

Mamy bazę poję­cio­wą. Można więc napi­sać, że regu­ła biz­ne­so­wa to usta­lo­na zasa­da postę­po­wa­nia, zaś decy­zja biz­ne­so­wa to doko­na­nie wybo­ru jed­nej spo­śród zna­nych moż­li­wo­ści wybo­ru. Nie jest to to samo, co, mam nadzie­ję, obra­zu­je przy­kład ze zwro­ta­mi grzecz­no­ścio­wy­mi. Tak więc obli­ga­to­ryj­ne uży­wa­nie zwro­tów grzecz­no­ścio­wych to obo­wią­zu­ją­ca zasa­da – regu­ła biz­ne­so­wa (zacho­wa­nie). Wybór wła­ści­we­go zwro­tu spo­śród zna­nych moż­li­wych, to decy­zja o wybo­rze. Może być ona wyni­kiem wie­dzy posia­da­nej lub udo­ku­men­to­wa­nej (w posta­ci np. tabli­cy decyzyjnej).

Proszę zwró­cić uwa­gę, że jeże­li regu­ła decy­zyj­na nie jest oczy­wi­sta to war­to ją narzu­cić” w fir­mie, wte­dy wybór wła­ści­we­go zwro­tu jest już ele­men­tem pew­nej wie­dzy fir­mo­wej. Tę wie­dzę jed­nak moż­na posia­dać lub nie. Jeżeli tyl­ko ist­nie­je ryzy­ko wybo­ru (przez np. pra­cow­ni­ków) złej for­my grzecz­no­ścio­wej, to nale­ży ją wła­śnie z góry narzu­cić (tabli­ca decy­zyj­na czy­li wie­dza udo­ku­men­to­wa­na). W przy­pad­ku imple­men­to­wa­nia tego mecha­ni­zmu, np. w sys­te­mie CRM, musi­my tę wie­dzę udo­ku­men­to­wać w spo­sób jed­no­znacz­ny, a do takich wła­śnie spo­so­bów nale­ży narzę­dzie jakim jest tabli­ca decyzyjna.

Analiza firmy

Po co się robi ana­li­zy biz­ne­so­we orga­ni­za­cji? Nie po to by zapi­sać set­ki stron! Analizę pro­wa­dzi­my by zro­zu­mieć te ana­li­zo­wa­ne orga­ni­za­cje. Po co? By następ­ne podej­mo­wa­ne decy­zje byłe mniej ryzy­kow­ne, bar­dziej świa­do­me. Taką decy­zją jest wpro­wa­dze­nie zmia­ny orga­ni­za­cyj­nej, okre­śle­nie wyma­ga­nia na opro­gra­mo­wa­nie, zawar­cie nowej umo­wy anga­żu­ją­cej zaso­by orga­ni­za­cji, wie­le innych.

Podejmijmy pró­bę upo­rząd­ko­wa­nia opi­sa­nych tu pojęć:

reguły a decyzje i procesy

Diagram ten (tzw. dia­gram fak­tów dla sys­te­mu poję­cio­we­go, słu­ży mię­dzy inny­mi do testo­wa­nia spój­no­ści sys­te­mu poję­cio­we­go – prze­strze­ni nazw) poka­zu­je (mam nadzie­ję jasno) poję­cia i wią­żą­ce je fak­ty (kształ­to­wa­nie, two­rze­nie cze­goś itp. to fak­ty zwią­za­ne z tymi poję­cia­mi). Zaznaczyłem dodat­ko­wo linię podzia­łu (kre­ska prze­ry­wa­na) pomię­dzy tym co jest opi­sem (mode­lem) pro­ce­su (spe­cy­fi­ka orga­ni­za­cji) oraz tym cze­go ocze­ku­je się od zaan­ga­żo­wa­nych zaso­bów. Nietrudno się domy­ślić, że regu­ły biz­ne­so­we to zasa­dy orga­ni­za­cyj­ne, spe­cy­ficz­ne dla niej. Decyzje to pra­ca ludzi, któ­rzy tych zasad muszą prze­strze­gać a decy­zje te muszą, w związ­ku z tym, być podejmowane.

Obecnie nie raz pla­nu­je­my auto­ma­ty­za­cję wybra­nych czyn­no­ści. Na czym ona pole­ga? Na tym, że tam gdzie regu­ły decy­zyj­ne moż­na opi­sać w posta­ci zupeł­nej (zna­my wszyst­kie moż­li­we sytu­acje i przy­po­rząd­ko­wu­je­my im kon­kret­ne decy­zje – [[tabli­ca decy­zyj­na zupeł­na]]), moż­na sobie pozwo­lić na zastą­pie­nie czło­wie­ka maszy­ną. Tą maszy­ną może być oczy­wi­ście np. kom­pu­ter i odpo­wied­nie oprogramowanie.

Proszę zwró­cić tak­że uwa­gę na to, że linia podzia­łu pomię­dzy pro­ce­sa­mi a zaso­ba­mi to tak­że linia podzia­łu pomię­dzy pro­ce­sa­mi a ich imple­men­ta­cją. Podział zna­ny już z poniż­sze­go dia­gra­mu (źr. http://​www​.bptrend​sas​so​cia​tes​.com/):

Na zakończenie

Analiza biz­ne­so­wa orga­ni­za­cji poprze­dza­ją­ca np. wdro­że­nie nowe­go opro­gra­mo­wa­nia, powin­na pole­gać na wyko­na­niu audy­tu i upo­rząd­ko­wa­niu reguł decy­zyj­nych oraz opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych by je zwe­ry­fi­ko­wać. Drugi krok to oce­na, jakiej wie­dzy ocze­ku­je­my od ludzi (ich umie­jęt­no­ści i wie­dza). Dokumentujemy ją z oba­wy przed błę­dem ludz­kim”. Tu zwra­cam uwa­gę na to, że wyma­ga­niem na opro­gra­mo­wa­nie może być tabli­ca decy­zyj­na, jeże­li pla­nu­je­my auto­ma­ty­za­cję jakiejś czyn­no­ści. Proces biz­ne­so­wy nie jest wyma­ga­niem, to co naj­wy­żej kon­tekst wyko­ny­wa­nych czynności.

Know-how

Swego cza­su, w arty­ku­le o mode­lo­wa­niu pro­ce­sów biz­ne­so­wych napi­sa­łem, że:

Biznesowy know-how ? naj­cen­niej­szą rzecz w fir­mie. I po to war­to wyko­nać ana­li­zą biz­ne­so­wą: poznać i udo­ku­men­to­wać swo­ją prze­wa­gę czy­li fir­mo­we know-how. (Modelowanie biz­ne­so­we c.d. ? know-how, gdzie ono jest?).

Jednym z klu­czo­wych ele­men­tów owe­go know-how jest wła­śnie wie­dza będą­ca wyni­kiem zbie­ra­ne­go doświad­cze­nia. Znajomość swo­jej histo­rii i wycią­ga­ne z niej wnio­ski to bar­dzo czę­sto wie­dza o tym, któ­re decy­zje jakie skut­ki dla fir­my przy­nio­sły. Kolekcjonowanie tej wie­dzy to nic inne­go jak budo­wa­nie i kon­ser­wo­wa­nie” tablic decy­zyj­nych. Typowym przy­kła­dem takich pil­nie strze­żo­nych tablic są sys­te­mu sco­rin­go­we ban­ków i ubez­pie­czy­cie­li, sys­te­my oce­ny wia­ry­god­no­ści kon­tra­hen­tów i wie­le innych. Nie nale­ży zapo­mi­nać, że sys­te­my decy­zyj­ne wyma­ga­ją okre­śle­nia reguł (biz­ne­so­wych) mówią­cych kie­dy je stosować.

Jeszcze o systemach

Dla przy­po­mnie­nia przy­to­czę pro­stą defi­ni­cje systemu:

System ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). Z uwa­gi na fakt, że wyod­ręb­nie­nie wszyst­kich ele­men­tów przy­na­le­żą­cych do sys­te­mu bywa w prak­ty­ce nie­kie­dy bar­dzo trud­ne, dla­te­go do bada­nia sys­te­mów wyko­rzy­stu­je się ich uprosz­czo­ne mode­le. Elementy przy­na­le­żą­ce do jed­ne­go sys­te­mu nie mogą jed­nak sta­no­wić jed­no­cze­śnie ele­men­tów przy­na­leż­nych do inne­go sys­te­mu (na pod­sta­wie: Bertalanffy, L. von, Ogólna teo­ria sys­te­mów. Podstawy, roz­wój, zasto­so­wa­nia. PWN, Warszawa 1984).

Tu, orga­ni­za­cje, bada­nym sys­te­mem są zaso­by i tre­ści jakie są w nich prze­twa­rza­ne czy­li wza­jem­nie powią­za­ni ludzie, maszy­ny i doku­men­ty. Organizacje np. na ryn­ku, to tak­że sys­tem, sys­tem nad­rzęd­ny, któ­ry tak­że nale­ży rozu­mieć. Ten mode­lu­je­my jed­nak na eta­pie ana­li­zy stra­te­gii np. ryn­ko­wej. Po co to wszyst­ko? Poprawny model zbu­do­wa­ny sfor­ma­li­zo­wa­ny­mi meto­da­mi to narzę­dzie podej­mo­wa­nia decy­zji, tym lep­szych im lep­szy model.

Nie jest to, mode­lo­wa­nie, łatwe jak widać. Wymaga, poza samą umie­jęt­no­ścią ana­li­zy i sfor­ma­li­zo­wa­ne­go jej doku­men­to­wa­nia, tak­że duże­go doświad­cze­nia oraz zna­jo­mo­ści i rozu­mie­nia pro­ce­su zarzą­dza­nia orga­ni­za­cją. Tam gdzie dana orga­ni­za­cja jest pod­mio­tem ryn­ko­wym, tak­że zasad rzą­dzą­cych rynkiem.

Najważniejsze w tym jest to, że samo udo­ku­men­to­wa­nie cze­goś np. na pod­sta­wie czy­je­goś opi­su, bez spraw­dze­nia czy opis jest jed­no­znacz­ny, nie ma w nim sprzecz­no­ści i czy jest zupeł­ny (opi­su­je wszyst­ko), nie nie­sie żad­nej war­to­ści, a nie raz nawet wpro­wa­dza w błąd.

TabliceDecyzyjnePWN1971

(UWAGA! Artykuł to część mojej pra­cy nauko­wej, wszel­kie pra­wa do jego tre­ści są zastrze­żo­ne, wni­kli­wym ana­li­ty­kom do poczy­ta­nia: Solomon L. Pollack, Harry T. Hicks, Jr, William J. Harrison: Tablice decy­zyj­ne, PWN Warszawa 1975).

Literatura

Vasilecas, O., & Smaizys, A. (2007). Business Rule Based Configuration Management and Software System Implementation Using Decision Tables. Local Proceedings of ADBIS, 2007, 27 – 37.
Pollack, S. L., Hicks, H. T., & Harrison, W. J. (1975). Tablice decy­zyj­ne. PWN.
Vanthienen, J. A. N., & Dries, E. (1992). Developments in deci­sion tables: Evolution, appli­ca­tions and a pro­po­sed stan­dard. DTEW Research Report 9227.
Vanthienen, J., & Wets, G. (1992). Mapping Decision Tables to Expert System Shells: An Implementation in AionDS. Onderzoeksrapport 9228.

Ten straszny diagram klas

(aktu­ali­zo­wa­ny 2020) Gdybym miał oce­nić sta­ty­stycz­nie dia­gram klas opi­sy­wa­ny w książ­kach o UML , pro­jek­tach jakie widu­ję nie tyl­ko w pra­cach stu­den­tów, to powie­dział bym, że jest jakiś pro­blem z nimi. Dlaczego? Pokaże to, co moim zda­niem jest chy­ba nie tak. Szczególnie jak ktoś uwa­ża, że dia­gram klas do model danych co wprost pro­wa­dzi do antyw­zor­ca obiek­to­we­go o nazwie ane­micz­ny model dzie­dzi­ny ?*?Ten arty­kuł to kon­ty­nu­acja poprzed­nie­go arty­ku­łu o mode­lach dzie­dzi­ny sys­te­mu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszyst­kim ana­li­za to nie pro­jekt, powin­na poka­zać obiek­tyw­ny stan fak­tycz­ny. Druga rzecz, o tym już nie­któ­rzy zapo­mi­na­ją: wyni­kiem ana­li­zy jest doku­men­ta­cja zro­zu­mie­nia, tak więc model ana­li­tycz­ny nie może być mode­lem poka­zu­ją­cym stan po uprosz­cze­niach. To powi­nien być model rze­czy­wi­sto­ści z nanie­sio­ny­mi, zasto­so­wa­ny­mi lokal­nie, ogra­ni­cze­nia­mi i uprosz­cze­nia­mi. Innymi sło­wy: dla fabry­ki spodni budu­je­my kom­plet­ny model czło­wie­ka (mane­kin) z komen­ta­rzem, że tu w uży­ciu jest część od pasa w dół a nie wma­wia­my niko­mu, że w tej fabry­ce czło­wiek skła­da sie wyłącz­nie z bio­der i nóg. W prze­ciw­nym wypad­ku, przy­szła roz­bu­do­wa sys­te­mu będzie co naj­mniej problematyczna.

Produkt ana­li­zy prze­ka­zu­je infor­ma­cję o tym co zasta­no, opi­su­je poję­cia i regu­ły jakie nimi rzą­dzą. Tak na praw­dę, opi­sać fir­mę (orga­ni­za­cję) to zna­czy stwo­rzyć listę pojęć jaki­mi się w niej ope­ru­je (jaki­mi moż­na ją opi­sać) i regu­ły jakie ogra­ni­cza­ją swo­bo­dę uży­cia (funk­cjo­no­wa­nia) tych pojęć. Model poję­cio­wy (ich spe­cy­fi­ka­cja) to seman­ty­ka sys­te­mu, ogra­ni­cze­nia swo­bo­dy ich wza­jem­ne­go koja­rze­nia to syn­tak­ty­ka, i na koniec dzie­dzi­no­we ogra­ni­cze­nie swo­bo­dy ich uży­cia to prag­ma­ty­ka. Wkrada się tu tak­że przy­dat­ne poję­cie jakim jest entro­pia czy­li mia­ra nie­upo­rząd­ko­wa­nia. Tak więc mamy sys­tem pojęć, jego entro­pia (sto­pień nie­upo­rząd­ko­wa­nia) jest ogra­ni­czo­na syn­tak­ty­ką i prag­ma­ty­ką spe­cy­ficz­ną dla dzie­dzi­ny i miej­sca (orga­ni­za­cji). Co to ozna­cza dla ana­li­zy przedwdrożniowej?

Jednym z celów tej ana­li­zy jest odkry­cie i zapi­sa­nie wie­dzy o pod­mio­cie infor­ma­ty­zo­wa­nym”. Jak ją zapi­sać? Ano wła­śnie tak: zbu­do­wać listę pojęć i wska­zać opi­sa­ne ogra­ni­cze­nia. Doskonałym narzę­dziem do tego jest dia­gram klas (odra­dzam dia­gram ERD, moż­na go póź­niej zbu­do­wać w opar­ciu o model poję­cio­wy, jeże­li zaj­dzie taka potrze­ba, ale nie nale­ży tych dwóch mode­li sto­so­wać zamien­nie). Diagram klas opi­su­ją­cy taki sys­tem poję­cio­wy to tak zwa­na prze­strzeń poję­cio­wa (name­spa­ce) . Jak to wygląda:

Diagram klas, taksonomia

Od razu uwa­ga: powyż­szy dia­gram jest nad­mia­ro­wy, w real­nym pro­jek­cie bym tego tak nie nary­so­wał, ale po kolei.???

Podstawowe poję­cia (seman­ty­ka) ana­li­zo­wa­ne­go sys­te­mu to kla­sy ozna­czo­ne nie­bie­skim kolo­rem. Bardzo czę­sto zda­rza się, że pew­ne poję­cia moż­na lub nale­ży pokla­sy­fi­ko­wać, by prze­ka­zać infor­ma­cję o ist­nie­niu tej kla­sy­fi­ka­cji. Diagram ten moż­na wiec uzu­peł­nić na dwa spo­so­by: sto­su­jąc tak zwa­ne super­kla­sy (uogól­nie­nie, zebra­nie kil­ku wspól­nych cech) oraz tak zwa­ne ste­reo­ty­py, czy­li zna­cząc dodat­ko­wo kla­sy. Klasa uogól­nia­na nazy­wa­na jest spe­cja­li­za­cją. Na powyż­szym dia­gra­mie Zamówienie (spe­cja­li­za­cja) jest spe­cy­ficz­nym rodza­jem Dokumentu (uogól­nie­nie) a każ­dy doku­ment to coś będą­ce­go jakąś tre­ścią np. na papie­rze. Zamówienie jed­nak jest tak­że «obiek­tem biz­ne­so­wym», utrwa­lo­nym i zro­zu­mia­łym poję­ciem (bytem) w fir­mie, do cze­goś kon­kret­ne­go służy.

Jest pew­na seman­tycz­na róż­ni­ca pomię­dzy super-kla­są a ste­reo­ty­pem, gdyż uwa­żam, że tych pojęć nie moż­na sto­so­wać zamien­nie. Super-kla­sa poka­zu­je, że pew­ne byty są uogól­nia­ne (mają one jakieś wspól­ne cechy zebra­ne w tym uogól­nie­niu) i uogól­nie­nie to – jako poję­cie – jest sto­so­wa­ne w roz­mo­wie”. Stereotyp wska­zu­je na pew­ne ist­nie­ją­ce i istot­ne (chce­my to zako­mu­ni­ko­wać w doku­men­ta­cji) roz­róż­nie­nie pomię­dzy poję­cia­mi jed­nak nie jest ono sto­so­wa­ne w roz­mo­wie”. Można więc uznać, że poję­cie Dokument funk­cjo­nu­je w roz­mo­wie” na rów­ni z poję­ciem Zamówienie choć jest to poję­cie (Dokument) abs­trak­cyj­ne. Nie ist­nie­je coś takie­go jak ogól­ny doku­ment” ale poję­cie to jest powszech­nie sto­so­wa­ne w fir­mach, abs­trak­cje takie ozna­cza­my pisząc nazwę takiej kla­sy kur­sy­wą. Można tak­że powie­dzieć, że Zamówienie jest «obiek­tem biz­ne­so­wym» (coś istot­ne­go, uży­wa­ne­go) jed­nak raczej nikt nie uży­wa tego poję­cia na co dzień. Ten ste­reo­typ infor­mu­je czy­tel­ni­ka ana­li­zy, że to coś istot­ne­go (jakimś kontekście).

Wpłata jest zda­rze­niem, jed­nak zda­rze­nie to coś, co na co dzień nie jest trak­to­wa­ne jako rów­no­praw­ne sło­wo” w biz­ne­sie. Dlatego w tym przy­pad­ku w mode­lu użył­bym tyl­ko ste­reo­ty­pu «zda­rze­nie», by wska­zać, że jest to coś inne­go niż «obiekt biz­ne­so­wy» ale już nie użył bym, abs­trak­cyj­nej super­kla­sy Zdarzenie. Jeżeli jed­nak w toku pro­jek­to­wa­nia (etap po ana­li­zie) uzna­my, że chce­my prze­twa­rzać dane o tych zda­rze­niach zapro­jek­tu­je­my dla sys­te­mu kla­sę Zdarzenie.

Obiektem biz­ne­so­wym jest jed­nak Dowód Wpłaty (tak na praw­dę repre­zen­tu­je on to zda­rze­nie ale nie jest to toż­sa­me poję­cie: stwier­dze­nie wpła­ty nie jest dowo­dem wpła­ty). Te niu­an­se są bar­dziej oczy­wi­ste (mam nadzie­ję :)) na przy­kła­dzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu tak­że ewi­dent­nie, że Klient jest wyłącz­nie Osobą.

Diagram ten zawie­ra tak­że pew­ne regu­ły biz­ne­so­we (ogra­ni­cze­nia entro­pii, czy­li swo­bo­dy). Są to liczeb­no­ści nanie­sio­ne na sko­ja­rze­nia (aso­cja­cje), linie łączą­ce kla­sy. Zaznaczono np. że Sprzedawca może mieć pod opie­ką klien­tów, tak­że żad­ne­go, jed­nak klient musi mieć i tyl­ko jed­ne­go opie­ku­na. Brak linii łączą­cej dwie kla­sy świad­czy zaś o tym, że nie ogra­ni­cza­ją się one nawza­jem w żaden spo­sób np. Wpłaty w żaden spo­sób nie wpły­wa­ją na Sprzedawcę i odwrot­nie. Istnieje jedy­nie pośred­ni zwią­zek mówią­cy, że moż­na sko­ja­rzyć Wpłatę ze Sprzedawcą, ele­men­tem koja­rzą­cym jest Faktura i jest ona tak­że kon­tek­stem tego sko­ja­rze­nia: Faktura jest pro­duk­tem pro­ce­su Sprzedaży, za któ­ry odpo­wia­da Sprzedawca. To jest powód, dla któ­re­go model pro­ce­sów powi­nien tak­że powstać jako jeden z pro­duk­tów takiej ana­li­zy bo to on zawie­ra tę wła­śnie informację.

Model dziedziny to projekt

A teraz model dzie­dzi­ny, przy­to­czę dia­gram uży­ty w poprzed­nim artykule:

Diagram klas, model dziedziny systemu

Jak widać jest pomię­dzy nimi istot­na róż­ni­ca. Jej źró­dłem jest to, że tak­so­no­mia to model poję­cio­wy zaś model dzie­dzi­ny (w rozu­mie­niu Model z wzor­ca MVC) to opis prze­twa­rza­nia. Przede wszyst­kim model dzie­dzi­ny nie zawie­ra pojęć abs­trak­cyj­nych. Dlaczego? No bo ich nie zapi­su­je­my i nie prze­twa­rza­my :)! Po dru­gie pew­ne poję­cia znik­nę­ły z mode­lu (Klient, jest akto­rem) bo Klient nie jest prze­twa­rza­ny, ale dane klien­ta będą atry­bu­ta­mi (nie zazna­czo­no) Zamówienia: jest on tu, Klient, zama­wia­ją­cym. Czytaj wię­cej o two­rze­niu i testo­wa­niu mode­lu dzie­dzi­ny.

Tak więc war­to zwró­cić uwa­gę na to, że dia­gram klas dia­gra­mo­wi nie rów­ny, to samo narzę­dzie może posłu­żyć do dwóch róż­nych celów w tej samej doku­men­ta­cji. Widać tak­że (mam nadzie­ję), że pró­ba poka­za­nia na jed­nym dia­gra­mie zarów­no sys­te­mu pojęć jak i spo­so­bu ich prze­twa­rza­nia, jako infor­ma­cji w sys­te­mach infor­ma­tycz­nych, jest raczej błęd­nym podej­ściem. Wydaje mi się, że podej­mo­wa­nie takich prób świad­czy o nie­zro­zu­mie­niu róż­ni­cy pomię­dzy sys­te­mem poję­cio­wym a mode­lem prze­twa­rza­nia infor­ma­cji. W szcze­gól­no­ści gdy doty­czy to sys­te­mów obiektowych.

Programistom pole­cam tak­że te stro­ny.


  1. ?*?
    https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​A​n​e​m​i​c​D​o​m​a​i​n​M​o​d​e​l​.​h​tml
  2. ???
    w 2015 roku zmie­ni­ła się spe­cy­fi­ka­cja UML, usu­nię­to poję­cie dzie­dzi­cze­nia i agre­ga­cji, suge­ru­ję uzu­peł­nić wie­dzę wpi­sa­mi, któ­re powsta­ły po 2015 roku. 

Źródła

Zelinski, J. (2020) Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).
Fowler, M. (1997) Analysis pat­terns: reu­sa­ble object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-orien­ted softwa­re engineering).
Usman, M. et al. (2017) Taxonomies in softwa­re engi­ne­ering: A Systematic map­ping stu­dy and a revi­sed taxo­no­my deve­lop­ment method’, Information and Software Technology, 85, pp. 43 – 59. Available at: https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​1​7​.​0​1​.​006.
Stevens, P. (2007) UML Inżynieria opro­gra­mo­wa­nia. Translated by I. Jakóbik. Gliwice: Helion.
Booch, G., Rumbaugh, J. and Jacobson, I. (2002) UML prze­wod­nik użyt­kow­ni­ka. dru­gie wyda­nie. Warszawa: WNT (inży­nie­ria oprogramowania).