Business Knowledge Blueprints

Ronald G. Ross 

Ronald G. Ross jest auto­rem lub współ­au­to­rem wie­lu opra­co­wań na temat mode­li poję­cio­wych i zarzą­dza­nia wie­dzą . Jest tak­że współ­za­ło­ży­cie­lem Business Rule Solution LLC, oraz współ­twór­cą spe­cy­fi­ka­cji i nota­cji SBVR .

Książka

Najnowsze z powyż­szych opra­co­wań to rodzaj pod­su­mo­wa­nia pew­nej czę­ści dorob­ku autora.

Modele poję­cio­we są czę­sto mylo­ne z pro­jek­to­wa­niem rela­cyj­ne­go mode­lu danych, a bywa gorzej, gdy są utoż­sa­mia­ne z mode­lem dzie­dzi­ny sys­te­mu” w pro­jek­tach doty­czą­cych two­rze­nia apli­ka­cji okre­śla­nych jako„obiektowe”.

Książka trak­tu­je o mode­lach poję­cio­wych, i autor defi­niu­je je jako: 

model poję­cio­wy: upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi

Podstawowym związ­kiem mię­dzy poję­cia­mi (nazwa­mi) jest fakt (pre­dy­kat: zwią­zek zda­nio­twór­czy) łączą­cy poję­cia w popraw­ne i praw­dzi­we zdania. 

Przykład: poję­cia «pies» oraz «listo­nosz» to nazwy słow­ni­ko­we. Połączone fak­tem (pre­dy­ka­tem) two­rzą zda­nie, np.: „ «Pies» szcze­ka na «listo­no­sza» ” (z uwzględ­nie­niem pol­skiej flek­sji, «szcze­ka (na)» to fakt – pre­dy­kat). Jest to zda­nie popraw­ne a tak­że zda­nie praw­dzi­we: jest praw­dą, że pies szcze­ka na listo­no­sza” (to rela­cja), albo: jest moż­li­we, że pies szcze­ka na listo­no­sza” (jest praw­dą to, że to może się to wyda­rzyć). Ważna rzecz: poję­cia to nie sło­wa, to to co opi­su­ją defi­ni­cje tych pojęć (patrz: trój­kąt semio­tycz­nysemio­ty­ka).

Budowanie takich zdań to kon­tro­la (testo­wa­nie) popraw­no­ści mode­lu poję­cio­we­go, test spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści mode­lu poję­cio­we­go. Poprawny model poję­cio­wy (name­spa­ce) to pod­sta­wo­wy waru­nek np. póź­niej­szej spój­no­ści całe­go sys­te­mu zarzą­dza­nia infor­ma­cją (tak­że dany­mi), doku­men­ta­mi (gro­ma­dzą dane), meta­da­ny­mi (opi­su­ją dane). 

Podtytuł książ­ki to: About Vocabulary & Concept Models (O słow­nic­twie i mode­lach poję­cio­wych). Warto wie­dzieć, że zna­ko­mi­ta więk­szość nie­uda­nych pro­jek­tów i wdro­żeń opro­gra­mo­wa­nia to sku­tek błę­dów w mode­lach poję­cio­wych (nazew­nic­two).

Nazewnictwo to nie tyl­ko nazwy doku­men­tów, tabel i pól (ety­kiet danych), to tak­że same dane czy­li nazwy sta­no­wią­ce war­to­ści pól for­mu­la­rzy: nazwy miast, nazwi­ska, nazwy przed­mio­tów, pro­duk­tów, itp. Dawno temu już skoń­czy­ły się cza­sy, gdy kom­pu­te­ry tyl­ko liczy­ły” (to wte­dy powsta­ła idea rela­cyj­ne­go mode­lu danych). Obecnie kom­pu­te­ry prze­twa­rza­ją dane nie będą­ce licz­ba­mi, dane niestrukturalne. 

Zarządzanie wie­dzą to nie są obliczenia.

Autor pisze: akt two­rze­nia danych (zapi­sy­wa­nie infor­ma­cji) to akt komu­ni­ka­cji: to prze­kaz (wia­do­mość) dla przy­szłych czy­tel­ni­ków, odbior­ców tych danych. Dlatego komu­ni­kat (treść), musi (powi­nen) być zro­zu­mia­ły i jed­no­znacz­ny. Jedynym spo­so­bem zagwa­ran­to­wa­nia tego jest popraw­ność uży­te­go zaso­bu pojęć (słow­nic­twa). To wła­śnie jest miej­sce na ana­li­zy i pro­jek­to­wa­nie: naj­pierw mode­li poję­cio­wych a potem mode­li i struk­tur danych. 

Pewną wadą moim zda­niem jest wpro­wa­dze­nie przez auto­ra nowej sym­bo­li­ki dla gene­ra­li­za­cji (budo­wa­nie tak­so­no­mii) w posta­ci pogru­bio­nej linii”. Jednak każ­dy kto zna UML i pozna SBVR, moim zda­niem, bez pro­ble­mu sobie z tym pora­dzi (Visual Paradigm tak wła­śnie zro­bił: gene­ra­li­za­cje na mode­lach fak­tów obra­zo­wa­ne są jako strzał­ki z zamknię­tym gro­tem, zna­ne z UML, podej­ście to opi­su­je Dodatek C do spe­cy­fi­ka­cji SBVR). 

Modele pojęciowe

Modele poję­cio­we są bar­dzo czę­sto mylo­ne z mode­lem pro­ce­sów. Jest to kon­se­kwen­cja sto­so­wa­nia związ­ków skie­ro­wa­nych (aso­cja­cje skie­ro­wa­ne w UML, mode­le poję­cio­we są wyra­ża­ne jako kon­tek­sto­we dia­gra­my klas). Zdanie pies szcze­ka na listo­no­sza” to nie pro­cess (biz­ne­so­wy), to zda­nie spraw­dza­ją­ce popraw­ność uży­tych nazw (pies, listo­nosz) i rozu­mie­nia tych pojęć (komu­ni­kat) oraz praw­dzi­wość zda­nia jako takie­go. Przykład: 

Diagram fak­tów nota­cji SBVR, przy­kład wery­fi­ka­cji pojęć pies i listo­nosz oraz zda­nia pies szcze­ka na listo­no­sza”. (dia­gra­my opra­co­wa­ne z uży­ciem Visual Paradigm).

Powyższy dia­gram zawie­ra dwa poję­cia słow­ni­ko­we: pies, listo­nosz (for­mal­nie powin­ny być tak­że w słow­ni­ku i mieć swo­je jed­no­znacz­ne defi­ni­cje). Górna część dia­gra­mu to gra­ficz­na for­ma, omó­wio­ne­go wyżej, zda­nia pies szcze­ka na listo­no­sza”. Typowe zda­nia to co naj­mniej dwie nazwy połą­czo­ne pre­dy­ka­tem (fak­tem: szcze­ka­nie to fakt). Dolna część dia­gra­mu to zda­nie zbu­do­wa­ne z jed­nej nazwy i pre­dy­ka­tu: Pies szcze­ka”. To tak­że jest popraw­ne zda­nie. Metoda i sys­tem nota­cyj­ny, two­rze­nia mode­li poję­cio­wych (opar­ta na logi­ce pre­dy­ka­tów) zosta­ła opi­sa­na i opu­bli­ko­wa­na jako stan­dard SBVR (patrz tak­że OWL: Web Ontology Language) .

Autor w książ­ce dokład­nie opi­su­je róż­ni­cę mię­dzy mode­lem poję­cio­wym a mode­lem danych: model poję­cio­wy i model danych do róż­ne modele!

Model danych i model poję­cio­wy to nie to samo!

Autor poka­zu­je tak­że zasto­so­wa­nie dia­gra­mów fak­tów do mode­lo­wa­nia ontologii.

Na zakończenie

Słownik jest bar­dzo waż­ny bo sta­no­wi fun­da­ment logi­ki biz­ne­so­wej wyra­żo­nej w posta­ci reguł biz­ne­so­wych (busi­ness rules, patrz arty­kuł z 2015 roku: Reguły biz­ne­so­we, decy­zje i poję­cia). Autor dokład­nie opi­su­je meto­dy two­rze­nia słow­ni­ków i dia­gra­mów fak­tów, w dodat­kach jest omó­wio­ny przy­kład kom­plet­ne­go mode­lu wraz ze słow­ni­kiem. Tu, jako uzu­peł­nie­nie, pole­cam książ­kę prof. Hołówki o logi­ce i two­rze­niu defi­ni­cji pojęć .

Gorąco zachę­cam do lek­tu­ry tej książ­ki, moim zda­niem jest to typo­wa pozy­cja must have” dla każ­de­go ana­li­ty­ka i pro­jek­tan­ta sys­te­mów infor­ma­cyj­nych. Więcej na ten temat napi­sa­łem w 2016 roku w arty­ku­le: Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu.

Literatura

OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
OMG​.org. (2014, September). Ontology Definition Metamodel (ODM).
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building busi­ness solu­tions: busi­ness ana­ly­sis with busi­ness rules. Business Rule Solutions.

Diagram obiektów czyli bottom-up

W toku nie­jed­nej ana­li­zy moż­na spo­tkać się z sytu­acją gdy stan­dar­do­we podej­ście pole­ga­ją­ce na bada­niu doku­men­tów i ana­li­zie zstę­pu­ją­cej (od ogó­łu do szcze­gó­łu, ang. top-down) może być trud­ne lub wręcz nie moż­li­we. Dotyczy to ana­li­zy sys­te­mów sła­bo udo­ku­men­to­wa­nych lub wręcz nie­udo­ku­men­to­wa­nych, gdzie jedy­ne dostęp­ne dane to obser­wa­cja lub rela­cja obser­wa­to­ra (uczest­ni­ka, itp. czy­li rela­cja z dru­giej ręki). Jest to sytu­acja podob­na to serii (pakie­tu) zebra­nych user sto­ry” (w nomen­kla­tu­rze meto­dyk zwin­nych histo­ryj­ki użyt­kow­ni­ka), nie­for­mal­nych rela­cji. Jak ugryźć taką sytuację?

Z pomo­cą przy­cho­dzi poję­cie spe­cy­fi­ka­cji instan­cji w UML, zapew­ne brzmi to strasz­nie ale nie jest tak źle. Cóż to jest ta spe­cy­fi­ka­cja instan­cji? Co mówi spe­cy­fi­ka­cja (UML v.2.5):

9.8 Instances
9.8.1 Summary
InstanceSpecifications repre­sent instan­ces of Classifiers in a mode­led sys­tem. They are often used to model exam­ple con­fi­gu­ra­tions of instan­ces. They may be par­tial or com­ple­te repre­sen­ta­tions of the instan­ces that they cor­re­spond to.

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze tych rze­czy” o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi słowy

dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rzeczy

Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić od dołu” czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez klien­ta”. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le kon­kret­nych sytu­acji” z życia.

Tak więc napi­szę tu kil­ka słów o bar­dzo mało popu­lar­nym dia­gra­mie UML: dia­gra­mie obiek­tów (spe­cy­fi­ka­cje instancji).

InstanceSpecUML25Notation
(źr. UML v.2.5, for­mal 15 – 03-01)

Powyższe przy­kła­dy to mode­le kon­kret­nych sytu­acji: mamy tu (od góry) kon­kret­ną uli­cę, kon­kret­ny adres, dwie oso­by i zwią­zek mię­dzy nimi (ojciec-syn) oraz tak zwa­ną war­tość (nazwa­ne kon­kret­ne war­to­ści to tak­że obiek­ty). Diagram obiek­tów zawie­ra więc prak­tycz­nie wyłącz­nie kon­kret­ne, nazwa­ne byty w opi­sy­wa­nej rze­czy­wi­sto­ści. Prawdę mówiąc bar­dzo wie­le, o ile nie więk­szość, sche­ma­tów blo­ko­wych wyko­ny­wa­nych w tak zwa­nych doku­men­tach biz­ne­so­wych i pre­zen­ta­cjach, to pew­ne nie­for­mal­ne dia­gra­my obiek­tów. Wszędzie tam gdzie na sche­ma­cie blo­ko­wym są kon­kret­nie nazwa­ne uni­kal­ne ele­men­ty łączo­ne róż­ny­mi for­ma­mi linii i strza­łek, moż­na mówić o przed­sta­wie­niu kon­kret­nej zma­te­ria­li­zo­wa­nej” sytuacji.

Typowym przy­kła­dem są sche­ma­ty orga­ni­za­cyj­ne. Poniżej jed­na z wie­lu dostęp­nych w sie­ci Internet struk­tur orga­ni­za­cyj­nych: są to kon­kret­ne nazwy orga­nów (np. Rada Nadzorcza), komó­rek orga­ni­za­cyj­nych i sta­no­wisk, np. jak na poniż­szym diagramie.

źr. http://www.darrwww.hb.pl/pl/1042/Kadra_i_struktura_organizacyjna/
źr. http://​www​.dar​rwww​.hb​.pl/​p​l​/​1​0​4​2​/​K​a​d​r​a​_​i​_​s​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​na/

Powyższy dia­gram do dość powszech­na for­ma doku­men­to­wa­nia struk­tu­ry orga­ni­za­cyj­nej. Poniżej wer­sja tej struk­tu­ry (okro­jo­na) w posta­ci dia­gra­mu obiektów:

Analiza stanu faktycznego_1

Są to dokład­nie te same blocz­ki”, na dia­gra­mie tym (UML, dia­gram obiek­tów) każ­dy ele­ment to instan­cja (kla­sy)”. Na tym eta­pie odwzo­ro­wu­je­my jedy­nie to co wie­my w for­mie jaką zna­my. Kolejny etap to szu­ka­nie zasad i klu­czo­wych dla nich pojęć, skla­sy­fi­ko­wa­nie obiek­tów odwzo­ro­wa­nych na diagramie:

Struktura organizacyjna - model pojeciowy

Powyższy dia­gram to dia­gram fak­tów (spe­cy­fi­ka­cja SBVR/OMG). Jest to model poję­cio­wy, skła­da się z pojęć słow­ni­ka (pojęć biz­ne­so­wych) i fak­tów łączą­cych te poję­cia, na ich pod­sta­wie two­rzo­ne są kla­sy i atry­bu­ty, do któ­rych przy­po­rząd­ko­wy­wa­ne są poszcze­gól­ne obiek­ty mode­lu ana­li­zo­wa­ne­go (dia­gra­mu obiektów):

Struktura organizacyjna - klasyfikacja obiektów

Powyżej obiek­to­wy model Struktury orga­ni­za­cyj­nej po uzu­peł­nie­niu o kla­sy­fi­ka­to­ry (każ­dy obiekt na dia­gra­mie został przy­po­rząd­ko­wa­ny do okre­ślo­nej kla­sy). Teraz moż­na opra­co­wać struk­tu­rę metamodelu:

Struktura organizacyjna - model dziedziny

Powyższy dia­gram to meta­mo­del tego co przed­sta­wia dia­gram obiek­tów (pier­wot­nie poka­za­na struk­tu­ra orga­ni­za­cyj­na). Teraz poja­wia się pyta­nie: co ma wyko­nać pro­gra­mi­sta (o ile takie jest zada­nie). Na tym eta­pie zro­zu­mie­li­śmy czym jest struk­tu­ra orga­ni­za­cyj­na i udo­ku­men­to­wa­li­śmy to, ale nadal nie roz­wią­za­li­śmy pro­ble­mu: jak to zaim­ple­men­to­wać (powyż­sze nie jest żad­nym wyma­ga­niem imple­men­ta­cji dla programisty).

Teraz mamy dwa wyj­ścia (pew­nie są też inne): potrak­to­wać powyż­sze jako meta­mo­del struk­tu­ry orga­ni­za­cyj­nej, użyć go, po uzu­peł­nie­niu o ogra­ni­cze­nia, jako recep­ty” dla fabry­ki struk­tu­ry orga­ni­za­cyj­nej”, uzu­peł­nić o kla­sy two­rzą­ce tę struk­tu­rę (wspo­mnia­ną fabry­kę) i dokoń­czyć model dzie­dzi­ny sys­te­mu”, albo poprze­stać na tym eta­pie, spi­sać regu­ły biz­ne­so­we” i w tej for­mie prze­ka­zać deve­lo­pe­ro­wi (wte­dy on sam musi roz­wią­zać pro­blem meto­dy imple­men­ta­cji). Jedno jest pew­ne: nie jest to abso­lut­nie żaden model danych.

Tak więc ana­li­za od szcze­gó­łu do ogó­łu” cza­sa­mi bywa bar­dzo pomoc­na. Pozwala wyjść od kon­kret­ne­go rze­czy­wi­ste­go sta­nu świa­ta” i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest mode­lem dzie­dzi­ny” jed­nak nim nie jest.

O budowaniu słowników i SBVR

O ana­li­zie poję­cio­wej pisa­łem nie raz, chy­ba pierw­szy raz w krót­kim arty­ku­le Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów ana­li­tycz­nych. Niestety nadal pro­ble­mem więk­szo­ści doku­men­tów, takich jak ana­li­zy i spe­cy­fi­ka­cje, jest ich nie­spój­ność i niejednoznaczność.

W nie­daw­nym arty­ku­le SBVR czy­li regu­ły biz­ne­so­we i słow­nik pisa­łem o dia­gra­mie fak­tów, o regu­łach i o słow­ni­ku pojęć, dzi­siaj co nie­co o poję­ciach (tych ze słow­ni­ka pojęć ;)).

Ostatnia wer­sja spe­cy­fi­ka­cji SBVR v.1.3. z maja tego roku, zawie­ra roz­sze­rzo­ny roz­dział: 8 Linguistic Foundations, 8.1 Things, Meanings, and Expressions, 8.1.1 Semiotic/Semantic Triangle in SBVR Terms roz­po­czy­na­ją­cy się tak:

This sub clau­se intro­du­ces the con­cepts that com­pri­se one leg, ?meaning cor­re­sponds to thing?, of the Semiotic/Semantic Triangle which was first intro­du­ced by Charles Sanders Peirce at the begin­ning of the twen­tieth cen­tu­ry and later by (Ogden and Richards 1923). See ?Ontology, Metadata, and Semiotics? [Sowa].

Semiotic/Semantic Triangle in SBVR Terms
Semiotic/Semantic Triangle in SBVR Terms

The Semiotic/Semantic Triangle is the the­ore­tic basis for SBVR?s lin­gu­istics-based archi­tec­tu­re in gene­ral and for the fun­da­men­tal sepa­ra­tion of repre­sen­ta­tion (expres­sion) from meanings in SBVR?s archi­tec­tu­re. Being a lin­gu­isi­tic-based stan­dard the instan­ces of con­cepts are the things in the uni­ver­se of disco­ur­se, i.e., the world of the orga­ni­za­tion that uses the SBVR Business Vocabulary, and not con­cepts in the SBVR model. (Źródło: SBVR)

Generalnie seman­ty­ka, semio­ty­ka i prag­ma­ty­ka to trzy klu­czo­we ele­men­ty lin­gwi­sty­ki: poję­cie (ter­min) mają­ce swo­ja defi­ni­cję (seman­ty­ka), dalej byty zna­czo­ne przez te poję­cia (poję­cie zna­czy-deno­tu­je to coś”) to semio­ty­ka, oraz wyra­że­nia zawie­ra­ją­ce­go to poję­cie, któ­re nada­je mu kon­tekst (prag­ma­ty­ka). Nauka o tym jak rozu­mie­my zna­ki, semio­ty­ka (sło­wa są tak­że zna­ka­mi), mówi że zna­cze­nie ter­mi­nu wska­zu­je na zbiór rze­czy­wi­stych ele­men­tów (bytów), sło­wo [kot] defi­nio­wa­ne jest jak pewien typ ssa­ka, deno­tu­je wszyst­kie zwie­rzę­ta roz­po­zna­wa­ne przez nas jako koty. Denotacja wyni­ka jed­nak z kon­tek­stu, czy­li tego w jakim oto­cze­niu zna­cze­nio­wym” sło­wo (znak) został uży­ty. Np. kształt trój­kąt” w zeszy­cie do geo­me­trii ozna­cza abs­trak­cyj­ną figu­rę geo­me­trycz­ną, ten sam znak na drzwiach w dłu­gim kory­ta­rzy ozna­cza (spo­dzie­wa­my się tego) męską toa­le­tę. Dlatego sto­su­je się (budu­je się) wyra­że­nia (expres­sion) two­rzą­ce kon­tekst (do ter­mi­nów doda­je się fak­ty z nimi powią­za­ne, co wska­zu­je na kon­kret­ne zna­cze­nie), zawie­ra­ją­ce dany (defi­nio­wa­ny) ter­min (sło­wo), dla dopre­cy­zo­wa­nia zna­cze­nia tego ter­mi­nu (trój­kąt umiesz­cza­ny w zeszy­cie do geo­me­trii, lub trój­kąt umiesz­cza­ny na drzwiach toa­le­ty, wyra­że­nie (w SBVR wor­ding”) umiesz­cza­ny w…” to fakt nada­ją­cy poję­ciu trój­kąt” kontekst).

Takimi kon­tek­sta­mi są tak zwa­ne dia­gra­my fak­tów. Są to dia­gra­my, na któ­rych poję­cia zawar­te w słow­ni­ku pojęć, są przed­sta­wia­ne wraz z opi­sem, fak­ta­mi, dopre­cy­zo­wu­ją­cy­mi ich zna­cze­nie poprzez uży­cie w okre­ślo­nym kon­tek­ście. Ten kon­tekst, opi­sa­nie go, w toku ana­li­zy, ma jesz­cze dodat­ko­we zna­cze­nie: pozwa­la sku­pić się wyłącz­nie na tym jed­nym kon­tek­ście, a jest nim kon­tekst TEGO pro­jek­tu. Z zupeł­nie innej stro­ny spo­ty­ka­my się z tym samym pro­ble­mem przy oka­zji mode­lo­wa­nia dzie­dzi­ny sys­te­mu” (lub kom­po­nen­tu) przy oka­zji pro­jek­to­wa­nia kom­po­nen­tów, tak zwa­nych mikro­ser­wi­sów, czy meto­dy­ki i wzor­ca Domain Driven Design. Pojęcie boun­ded con­text” to nic inne­go jak koniecz­ność ogra­ni­cze­nia ana­li­zo­wa­ne­go pro­ble­mu do jed­ne­go kon­tek­stu, wła­śnie dla zacho­wa­nia spój­no­ści i jed­no­znacz­no­ści mode­lu sys­te­mu oraz jego odpo­wie­dzial­no­ści”, sta­no­wią­ce­go wyma­ga­nie np. wobec opro­gra­mo­wa­nia. Model to nic inne­go jak opis mecha­ni­zmu dzia­ła­nia ser­ca każ­de­go sys­te­mu (core domain).

Tworząc opro­gra­mo­wa­nie świa­do­mie dzie­li­my je na kom­po­nen­ty bo zbyt duży (sze­ro­ki) zakres funk­cjo­nal­ny pro­wa­dzi do tego, że nie moż­li­we jest unik­nię­cie nie­jed­no­znacz­no­ści. Jeden popraw­nie zapro­jek­to­wa­ny kom­po­nent obsłu­gu­je wyłącz­nie jeden kon­tekst”, gwa­ran­tu­je to spój­ność pojęć i spój­ność mode­lu dome­ny”. Widać ten pro­blem w zbyt dużych sys­te­mach ERP:

jeże­li chce­my obsłu­żyć np. takie poję­cie jak maszy­na”, to zupeł­nie inne ma to poję­cie zna­cze­nie na liście środ­ków trwa­łych (pozy­cja kosz­to­wa, jed­na z wie­lu, z jej cecha­mi księ­go­wy­mi) a inne na liście wypo­sa­że­nia hali pro­duk­cyj­nej (maszy­na mają­ca cechy kon­struk­cyj­ne i okre­ślo­na przy­dat­ność), oba te byty zacho­wu­ją się” ina­czej w obu tych kon­tek­stach, każ­dy jest powią­za­ny z inny­mi fak­ta­mi w orga­ni­za­cji (kupio­ny okre­ślo­nym kosz­tem, tu nie róż­ni się od kupio­nych usług, oraz jest sma­ro­wa­ny by nie uległ awa­rii, tu jest to ewi­dent­nie zło­żo­ny pod­ze­spół). Tu poja­wia się pro­blem nor­ma­li­za­cji dużych baz danych rela­cyj­nych: pró­ba jed­no­krot­ne­go uży­cia każ­de­go poję­cia (nor­ma­li­za­cja) w wie­lo-kon­tek­sto­wym sys­te­mie, kłó­ci się z wie­lo­ma kon­tek­sta­mi jaki­mi są poszcze­gól­ne modu­ły tema­tycz­ne apli­ka­cji. To dla­te­go jeden znor­ma­li­zo­wa­ny model danych dla duże­go zin­te­gro­wa­ne­go sys­te­mu nigdy nie będzie popraw­ny, zawsze będzie szko­dli­wym kom­pro­mi­sem. Systemy skła­da­ją­ce się z cał­ko­wi­cie odse­pa­ro­wa­nych kom­po­nen­tów (nie współ­dzie­lą żad­nych danych we wspól­nej bazie danych!) są znacz­nie lep­sze w użyciu.

(wię­cej w arty­ku­le Granice kon­tek­stu i mikro­ser­wi­sy)

Jakość biz­ne­so­we­go słow­ni­ka ter­mi­nów wyzna­cza wręcz jakość całej ana­li­zy, a potem pro­jek­tu. Wszelkie nie­jed­no­znacz­no­ści poję­cio­we pro­wa­dzą do nie­jed­no­znacz­no­ści logi­ki tek­stu (opi­su), na pod­sta­wie takie­go tek­stu nie da się stwo­rzyć popraw­nie dzia­ła­ją­ce­go mecha­ni­zmu dzia­ła­nia (np. kodu pro­gra­mu). Pierwszym miej­scem, w któ­rym widać te pro­ble­my są umo­wy i słow­ni­ki pojęć na ich począt­ku. Poprawnie zbu­do­wa­ny słow­nik to czy­sta logi­ka: defi­ni­cje pojęć w słow­ni­ku powin­ny się wza­jem­nie wyklu­czać (zasa­da wyłą­czo­ne­go środ­ka w logi­ce) zaś w ramach jed­ne­go słow­ni­ka (pozio­mu defi­nio­wa­nych pojęć) defi­ni­cje pojęć nie mogą zawie­rać pojęć definiowanych.

…ana­li­za danej dzie­dzi­ny to opra­co­wa­nie jej mode­lu z pomo­cą kon­kret­ne­go sys­te­mu poję­cio­we­go. Czy to łatwe? Niestety nie. Sito jest łatwe w uży­ciu bo jedy­nym kry­te­rium kwa­li­fi­ka­cji jest roz­miar i moż­na to robić mecha­nicz­nie. Analiza tre­ści wyra­żo­nej języ­kiem natu­ral­nym w posta­ci mowy lub pisma jest znacz­nie trud­niej­sza. (Źródło: Trzy zasa­dy, nazy­wa­ne cza­sem naj­wyż­szy­mi pra­wa­mi myśle­nia czy­li czym jest popraw­na ana­li­za | Jarosław Żeliński IT-Consulting)

Tak więc podej­mu­jąc się ana­li­zy, war­to robić to dobrze”, moż­na to nazwać meto­dą nauko­wą i nie będzie w tym prze­sa­dy. Reguły biz­ne­so­we, rygo­ry ich two­rze­nia, słow­nik pojęć, model poję­cio­wy, to wszyst­ko słu­ży popra­wie jako­ści wyni­ków ana­li­zy, doku­men­ta­cji, póź­niej­sze­go pro­jek­tu. Specyfikacja SBVR bar­dzo w tym poma­ga. (o for­ma­li­za­cji mode­li)

Jeżeli mie­li­ście kie­dyś pro­blem z pro­jek­tem, to jest bar­dzo praw­do­po­dob­ne, że jed­ną z klu­czo­wych tego przy­czyn był zły (lub jego brak) model pojęciowy.

Analitycy! Studiujcie logikę 😉

Gdzie są te cholerne szczegóły

Regularnie na moich szko­le­niach oraz w toku pro­jek­tów, dosta­je pyta­nia o wali­da­cje”. Z regu­ły spo­ty­kam spe­cy­fi­ka­cje wyma­gań (albo ocze­ki­wa­nia na takie), zawie­ra­ją­ce zesta­wie­nia doku­men­tów (i for­ma­tek ekra­no­wych), dla każ­de­go zesta­wie­nie pól, dla każ­de­go pola wali­da­cje”. Problem w tym, że:

  • mie­sza­ją się tu tak zwa­ne typy pro­ste danych (zna­ko­we, licz­bo­we, itp.), tak zwa­ne maski” (data, ema­il, itp.), oraz regu­ły biz­ne­so­we (np. wła­ści­wy rabat),
  • z uwa­gi na to, że doku­men­tów jest wie­le, a pola mogą się na nich powta­rzać, powsta­je duża licz­ba powtó­rzo­nych zapi­sów wali­da­cji”, nie­jed­no­krot­nie nie­spój­nych a bywa, że sprzecznych.
  • typy pro­ste oraz regu­ły biz­ne­so­we (logi­ka biz­ne­so­wa) to dwa zupeł­nie inne obsza­ry systemu.

Jak definiować wymagania na walidacje”

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodzaje:

  1. funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej aplikacji),
  2. poza-funk­cjo­nal­ne czy­li cechy jakościowe,
  3. dzie­dzi­no­we czy­li logi­ka biznesowa.

I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? W arty­ku­le Gdzie się reali­zu­ją wyma­ga­nia opi­sa­łem ogól­nie wzo­rzec pro­jek­to­wy MVC. Pomijając sam wzo­rzec, istot­ne jest to, że tak zwa­ne wali­da­cje” są doko­ny­wa­ne w dwóch róż­nych ele­men­tach archi­tek­tu­ry. Tak zwa­ne typy pro­ste danych (np. pole zna­ko­we Nazwisko) są (mogą być) spraw­dzo­ne w momen­cie ich wpro­wa­dza­nia (np. for­mat­ka ekra­no­wa nie przyj­mu­je cyfr w polu nazwi­sko). Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klienta.

Jedną z naj­gor­szych prak­tyk pro­gra­mi­stów jakie spo­ty­kam, jest umiesz­cza­nie logi­ki biz­ne­so­wej (a są nią np. meto­dy nali­cza­nia upu­stów) w for­mu­la­rzach ekra­no­wych. Po pierw­sze pro­wa­dzi to duże­go obcią­ża­nia kodu tych for­ma­tek, po dru­gie przy dużej ilo­ści doku­men­tów (for­ma­tek ekra­no­wych) logi­ka biz­ne­so­wa jest powie­la­na, co pro­wa­dzi do dużych pro­ble­mów z utrzy­ma­niem spój­no­ści spraw­dza­nych reguł biz­ne­so­wych w apli­ka­cji. Po trze­cie pró­by pisa­nia inter­fej­sów (API) do tych apli­ka­cji (np. przyj­mo­wa­nie doku­men­tów wysta­wio­nych poza apli­ka­cją) jest nie­moż­li­we bez kolej­ne­go powie­le­nia logi­ki biz­ne­so­wej w API (jeże­li chce­my wali­do­wać” przyj­mo­wa­ne tą dro­gą dane a z raczej chce­my). Jednym sło­wem masakra.

Sprawdzoną meto­dą sku­tecz­ne­go (spój­ność, kom­plet­ność, nie­sprzecz­ność) zapi­sy­wa­nia wyma­gań dzie­dzi­no­wych (w tym wali­da­cje”) jest wydzie­le­nie w dokumentacji:

  1. słow­ni­ka pojęć
  2. słow­ni­ka reguł biznesowych 
    1. spe­cy­fi­ka­cji tablic decy­zyj­nych jako uzu­peł­nie­nia reguł biznesowych.

Słownik pojęć powi­nien obej­mo­wać wszyst­ko to co stwa­rza ryzy­ko nie­jed­no­znacz­no­ści. Reguły biz­ne­so­we, wraz z tabli­ca­mi decy­zyj­ny­mi (jeże­li są wyma­ga­ne) zebra­ne w jed­nym miej­scu (spe­cy­fi­ka­cja reguł), są niczym innym jak wyma­ga­nia­mi dzie­dzi­no­wy­mi. Tak opra­co­wa­na doku­men­ta­cja ana­li­tycz­na pozwa­la deve­lo­pe­ro­wi na łatwe poru­sza­nie się po doku­men­cie, mamy moż­li­wość wery­fi­ka­cji wyma­gań, ich spój­no­ści i kom­plet­no­ści. Załączając spe­cy­fi­ka­cje wzo­rów doku­men­tów (mock-up’y ekra­nów czy­li for­mat­ki ekra­no­we) każ­dy obszar takie­go wzo­ru albo jest oczy­wi­sty, albo jest zde­fi­nio­wa­ny (jako nazwa) w słow­ni­ku pojęć. Cała nie­try­wial­na logi­ka dzia­ła­nia jest opi­sa­na regu­ła­mi biz­ne­so­wy­mi. Ogólne zasa­dy two­rze­nia takiej dokumentacji:

  1. W toku ana­li­zy opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych zawie­ra­ją­ce wyłącz­nie aktyw­no­ści i ich pro­duk­ty (czy­li pro­ce­sy biz­ne­so­we) i nic ponad to (dodat­ko­we szcze­gó­ły to albo pro­ce­du­ry albo sce­na­riu­sze przy­pad­ków uży­cia, to inne dokumenty).
  2. Na mode­lach pro­ce­sów zazna­cza­my wszyst­kie aktyw­no­ści zwią­za­ne ze sto­so­wa­niem reguł biz­ne­so­wych (kon­wen­cja doku­men­to­wa­nia reguł na mode­lach zale­ży od uży­te­go narzę­dzia CASE). Reguły biz­ne­so­we uzu­peł­nia­my o ewen­tu­al­ne kry­te­ria decy­zyj­ne (np. w posta­ci tablic decyzyjnych).
  3. Równolegle pro­wa­dzi­my słow­nik pojęć dla dokumentacji.
  4. Nie defi­niu­je­my (jako biz­nes, a nawet ana­li­tyk biz­ne­so­wy, zgła­sza­ją­cy wyma­ga­nia) typów pro­stych, one są albo oczy­wi­ste, albo wyni­ka­ją z defi­ni­cji pojęć (w razie wąt­pli­wo­ści pisze­my czym jest nazwi­sko w słowniku).

Ważna rzecz. Decyzje o tym jaki­mi typa­mi danych ope­ru­je apli­ka­cja, to decy­zje deve­lo­pe­ra (pro­gra­mi­sty). Moim zda­niem pro­gra­mi­sta żąda­ją­cy w wyma­ga­niach poda­nia mu typów danych, jest nie­ukiem albo leni­wym sabo­ta­ży­stą (uży­cie – wybór typów danych, w tym typów zło­żo­nych, to decy­zje i kom­pe­ten­cje developera!).

Poniżej opi­sa­ne ele­men­ty umiesz­czo­ne na jed­nym sche­ma­cie blokowym:

Logika biznesowa

Tak więc, war­to roz­wa­żyć sto­so­wa­nie reguł biz­ne­so­wych i słow­ni­ków pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to spraw­dzo­na i bar­dzo przy­dat­na tech­ni­ka ana­li­zy i doku­men­to­wa­nia logi­ki biz­ne­so­wej. Polecam tak­że stro­nę The Business Rules Group i zamiesz­czo­ny tam Manifest Reguł Biznesowych. Tworzenie mon­stru­al­nych doku­men­tów wyma­gań, zawie­ra­ją­cych dzie­siąt­ki razy powie­la­ne wali­da­cje” pro­wa­dzi do wie­lu kło­po­tów z utrzy­ma­niem spój­no­ści i kom­plet­no­ści takich spe­cy­fi­ka­cji. Pomijam już ich uciąż­li­wą obję­tość. Jako mate­riał dla pro­gra­mi­sty są one wte­dy trud­ne w uży­ciu, do tego skła­nia­ją do naj­gor­szych prak­tyk, jaki­mi jest mię­dzy inny­mi umiesz­cza­nie logi­ki biz­ne­so­wej w kodzie for­ma­tek ekranowych.

Na koniec pole­cam książ­kę Building Business Solutions poświę­co­na temu zagadnieniu.

klient, CRM, wróg, sprzedaż, wróg

Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

Niedawno jeden z arty­ku­łów zakoń­czy­łem akapitem:

Pierwszy etap ana­li­zy biz­ne­so­wej to mię­dzy inny­mi opra­co­wa­nie biz­ne­so­we­go słow­ni­ka pojęć (model poję­cio­wy)… (Słownik pojęć biz­ne­so­wych: naj­bar­dziej pod­sta­wo­we wyma­ga­nie).

Nie każ­da jed­nak ana­li­za to ana­li­za, któ­rej celem jest opi­sa­nie wyma­gań i pro­jek­to­wa­nie opro­gra­mo­wa­nia. Jednak każ­da ana­li­za pro­ble­mu, pro­wa­dzo­na jako ana­li­za sys­te­mo­wa, ma usta­lo­ne eta­py postępowania:

  1. for­mu­ło­wa­nie problemu,
  2. opra­co­wa­nie mode­lu ana­li­zo­wa­ne­go zja­wi­ska (w tym dowód jego poprawności!),
  3. wykry­cie i testo­wa­nie wariantów,
  4. ana­li­za wyni­ków i rekomendacje,
  5. pro­jek­to­wa­nie rozwiązania.

Powyższe to, opar­te na kla­sycz­nej ana­li­zie sys­te­mo­wej, postę­po­wa­nie. Dzisiaj sku­pię się głów­nie na punk­cie opra­co­wa­nie mode­lu” gdyż bazą do jego two­rze­nia jest wła­śnie słow­nik pojęć. 

Jak nie raz tu pisa­łem, mode­le two­rzo­ne są z uży­ciem nota­cji. Notacja to sys­tem poję­cio­wy, pew­na prze­strzeń nazw (ang. name­spa­ce). Notacje mogą być gra­ficz­ne, wte­dy każ­de poję­cie ma przy­po­rząd­ko­wa­ny okre­ślo­ny uni­kal­ny sym­bol, two­rzo­ne z nich kon­struk­cje to dia­gra­my, będą­ce odpo­wied­ni­kiem zdań (popraw­ny dia­gram coś mówi”). Tak więc tyle krót­kie­go wprowadzenia.

Gdzie te słowniki?

Pierwszym eta­pem ana­li­zy sys­te­mo­wej jest zde­fi­nio­wa­nie pro­ble­mu, ten jest zwią­za­ny zawsze z okre­ślo­nym przed­mio­tem. Przedmiot ana­li­zo­wa­ny – sys­tem – musi mieć ści­śle okre­ślo­ne gra­ni­ce oraz jed­no­znacz­ny opis będą­cy mode­lem tego sys­te­mu. Aby taki opis mógł powstać, jak się zapew­ne już domy­śla­my, musi­my dys­po­no­wać zbio­rem jed­no­znacz­nych pojęć go opi­su­ją­cych – musi­my mieć ade­kwat­ną do pro­ble­mu i jego dzie­dzi­ny prze­strzeń nazw. Model sys­te­mu to jed­no­znacz­na defi­ni­cja tego czym jest i jak się zacho­wu­je (jak reagu­je na bodź­ce). Opis taki wyko­na­ny języ­kiem natu­ral­nym, nie nada­je się do ana­li­zy, język natu­ral­ny nie jest for­mal­ną prze­strze­nią nazw, i z regu­ły nie pozwa­la na jed­no­znacz­ne opi­sa­nie cze­goś (w złym mode­lu poję­cio­wym zna­cze­nia pojęć nie pokry­wa­ją całej prze­strze­ni, nakła­da­ją się).

przestrzen nazw

Tak więc do opra­co­wa­nia mode­lu wyma­ga­na jest nota­cja. Skąd ja wziąć? Jak ją wybrać? Jak widać, nota­cja musi być dosto­so­wa­na do dzie­dzi­ny pro­ble­mu. Notacje stan­dar­do­we, z regu­ły, są dość ogól­ne gdyż muszą zacho­wy­wać pew­ną uni­wer­sal­ność. Notacje stan­dar­do­we są dzie­dzi­no­we i tu dzie­dzi­ną tą jest okre­ślo­ny para­dyg­mat. Najbardziej zna­ny­mi nota­cja­mi sto­so­wa­ny­mi w ana­li­zie sys­te­mo­wej z obsza­ru zarzą­dza­nia i sys­te­mów infor­ma­cyj­nych są UML i BPMN. UML repre­zen­tu­je para­dyg­mat obiek­to­wy mówią­cy, że świat skła­da się ze współ­pra­cu­ją­cych obiek­tów mają­cych okre­ślo­ne cechy i moż­li­wo­ści (umie­jęt­no­ści). BPMN repre­zen­tu­je para­dyg­mat pro­ce­so­wy mówią­cy, że świat to zacho­dzą­ce w cza­sie pro­ce­sy two­rze­nia lub prze­kształ­ca­nia rze­czy­wi­sto­ści (nale­ży jed­nak dodać, że UML to tak­że dia­gra­my dyna­mi­ki sys­te­mu, mają­ce zwią­zek z para­dyg­ma­tem pro­ce­so­wym, nie nale­ży jed­nak mylić tego z poję­ciem pro­ces biznesowy”).

Poza tymi dwo­ma nota­cja­mi (moim zda­niem głów­ny­mi) mamy wie­le innych, spe­cy­ficz­nych dla okre­ślo­nych dzie­dzin i para­dyg­ma­tów, sys­te­mów poję­cio­wych (np. BMM czy SBVR).

Tak więc każ­da ana­li­za, powin­na być poprze­dzo­na wybo­rem nota­cji, któ­re zosta­ną w niej uży­te. Na pew­nym okre­ślo­nym pozio­mie abs­trak­cji wystar­czą poję­cia dostęp­ne w nota­cjach stan­dar­do­wych. Nie raz może się jed­nak zda­rzyć, że ana­li­za pro­ble­mu doty­ka szcze­gó­łów, któ­rych roz­róż­nia­nie nie jest moż­li­we z pomo­cą stan­dar­do­wej nota­cji. Każdy kon­kret­ny pro­blem ma swo­je kon­kret­ne śro­do­wi­sko dzie­dzi­no­we, może się zda­rzyć, że bar­dziej szcze­gó­ło­we niż uni­wer­sal­ne nota­cje. Wtedy nale­ży roz­sze­rzyć zasto­so­wa­ną nota­cję (prze­strzeń poję­cio­wą). Rozszerzanie to jed­nak wyma­ga prze­strze­ga­nia pew­nej zasa­dy: roz­sze­rze­nie to może pole­gać wyłącz­nie na zastę­po­wa­niu sta­rych” pojęć zesta­wem ich spe­cja­li­za­cji („sta­re” poję­cie sta­je się abs­trak­cją) oraz zestaw takich spe­cja­li­za­cji tak­że musi sta­no­wić lokal­ną prze­strzeń nazw. Taka dodat­ko­wa prze­strzeń nazw nazy­wa się pro­fi­lem nota­cji. Tworzenie pro­fi­li jest dość trud­nym zaję­ciem z uwa­gi na wymóg zacho­wa­nia opi­sa­nych for­ma­li­zmów prze­strze­ni poję­cio­wych (pro­fil tak­że musi mieć okre­ślo­na seman­ty­kę i syn­tak­ty­kę, któ­ra to nie może koli­do­wać z tą w nota­cji bazowej).

I tu docho­dzi­my do sed­na: aby stwo­rzyć pro­fil nota­cji – co cza­sa­mi bywa nie­zbęd­ne dla jako­ści ana­li­zy – nale­ży naj­pierw zbu­do­wać słow­nik pojęć z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu, spraw­dzić czy zasto­so­wa­na nota­cja pozwa­la na roz­wią­za­nie posta­wio­ne­go pro­ble­mu z uży­ciem stan­dar­do­wej wer­sji nota­cji. Bez takie­go słow­ni­ka ana­li­za może być nie­wy­ko­ny­wal­na, albo jej jakość będzie bar­dzo niska – czy­taj: uży­cie jej wyni­ków będzie bar­dzo ryzykowne.

Takie pro­fi­le ma np. nota­cja BPMN w celu prze­cho­dze­nia z mode­li abs­trak­cyj­nych na wyko­ny­wal­ne, stan­dar­do­wo ope­ru­je się np. jed­nym poję­ciem czyn­ność, jeże­li potrzeb­ne jest ich roz­róż­nia­nie, prze­cho­dzi­my na sto­so­wa­nie sym­bo­li ozna­czo­nych jako czyn­ność ode­bra­nia komu­ni­ka­tu, czyn­ność wysła­nia komu­ni­ka­tu, czyn­ność manu­al­na, itp.. Dla nota­cji UML powsta­ło wie­le pro­fi­li np. dla kon­kret­nych języ­ków pro­gra­mo­wa­nia i ich środowisk.

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Pisząc recen­zję książ­ki Modelowanie biz­ne­so­we napi­sa­łem, że kom­plet­ny model orga­ni­za­cji to:

słow­nik pojęć (Glossary), model struk­tu­ry orga­ni­za­cyj­nej, regu­ły biz­ne­so­we (spe­cy­fi­ka­cja) oraz model pro­ce­sów biz­ne­so­wych korzy­sta­ją­cy z trzech poprzed­nich. Całość sta­no­wi dopie­ro kom­plet­ny model organizacji.

W Listopadzie ubie­głe­go roku tak­że pisa­łem o mode­lo­wa­niu struk­tu­ry organizacyjnej.

Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem. Są do tego ?prost­sze? narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku arty­ku­łu. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Są wido­ki by ten brak został uzu­peł­nio­ny. OMG pra­cu­je nad for­mal­nym meta­mo­de­lem ([[Organisation Structure Metamodel]]) do mode­lo­wa­nia struk­tur orga­ni­za­cyj­nych. Specyfikacja jesz­cze nie zosta­ła opu­bli­ko­wa­na, jest na eta­pie RFP, ale mamy przecieki :).

Ogólnie szkie­let tego meta­mo­de­lu ma nastę­pu­ją­cą postać:

Profil Organisation Structure Metamodel

Powyższy dia­gram przed­sta­wia pro­fil czy­li model poję­cio­wy, któ­ry może słu­żyć do budo­wy dia­gra­mu struk­tu­ry orga­ni­za­cyj­nej. Powyższe poję­cia to sys­tem ste­reo­ty­pów, czy­li znacz­ni­ków”. Przykładowy sche­mat struk­tu­ry orga­ni­za­cyj­nej z uży­ciem tych ste­reo­ty­pów mógł­by mieć poniż­szą postać (dia­gram więk­sze są dzie­lo­ne na pod­rzęd­ne struktury):

Model Struktury Organizacyjnej

Kilka słów komen­ta­rza. Szkieletem każ­dej takiej struk­tu­ry jest sys­tem komó­rek orga­ni­za­cyj­nych. Ta część z regu­ły nie budzi wąt­pli­wo­ści i nie stwa­rza pro­ble­mów, do cza­su gdy zacho­wu­je drze­wia­stą struk­tu­rę (każ­dy ma tyl­ko jed­ne­go prze­ło­żo­ne­go). Problemem poja­wia się, gdy zaczy­na­my mówić o kom­pe­ten­cjach, rolach i funk­cjach osób zaj­mu­ją­cych poszcze­gól­ne sta­no­wi­ska i pró­bie mode­lo­wa­nie funk­cjo­no­wa­nia organizacji.

Typowym pro­ble­mem, z jakim spo­ty­kam się poma­ga­jąc two­rzyć lub audy­tu­jąc mode­le pro­ce­sów biz­ne­so­wych czy np. ana­li­zy cią­gło­ści dzia­ła­nia, jest mapo­wa­nie ról w pro­ce­sach na struk­tu­rę orga­ni­za­cyj­ną oraz zarzą­dza­nie kompetencjami.

Mamy tu do czy­nie­nia z pro­ble­mem jakim jest to, że jed­ną rolę w pro­ce­sie może peł­nić wie­le osób (sta­no­wisk). Klasyką jest np. to, że fak­tu­rę może wysta­wić nie tyl­ko Fakturzysta ale np. każ­dy pra­cow­nik dzia­łu księ­go­wo­ści i dyr. sprze­da­ży. Porażką mode­la­rza” będzie nary­so­wa­nie dia­gra­mu, na któ­rym będzie, dla każ­de­go z powyż­szych sta­no­wisk, dedy­ko­wa­ny tor w pro­ce­sie i jakaś logi­ka bra­mek” poka­zu­ją­ca kie­dy kto wysta­wi tę fak­tu­rę. Z dru­giej stro­ny z regu­ły nie­praw­dą jest, że nikt poza fak­tu­rzy­stą nie może wysta­wić fak­tu­ry. Wystarczy jed­nak stwo­rzyć blo­czek” Rola lub Kompetencje (zależ­nie od sytuacji)->Wystawianie fak­tur i sko­ja­rzyć z wła­ści­wy­mi sta­no­wi­ska­mi, a blo­czek ten dopie­ro mapo­wać na role w pro­ce­sach. Uzyskamy dzię­ki temu praw­dziw­szy” model, uzy­sku­je­my moż­li­wość jed­no­znacz­ne­go mapo­wa­nia (śla­do­wa­nie: «tra­ce») ele­men­tów struk­tu­ry orga­ni­za­cyj­nej na model pro­ce­sów biz­ne­so­wych, być może na model dzie­dzi­ny. Możliwe sta­nie się testo­wa­nie popraw­no­ści modelu.

Praktycznie żaden dia­gram struk­tu­ry orga­ni­za­cyj­nej, jaki moż­na spo­tkać w doku­men­tach więk­szo­ści firm i spół­ek, nie nada­je się do nicze­go poza ilu­stro­wa­niem doku­men­tów w jakich jest umiesz­cza­ny. Nie ma w tym nic złe­go, do cza­su gdy nie docho­dzi do ana­li­zy funk­cjo­no­wa­nia takiej organizacji.

Ktoś zapy­ta: po co te zaba­wy, komu to prze­szka­dza? Odpowiedź jest pro­sta: dia­gram, któ­ry nie pozwa­la na ana­li­zę zależ­no­ści, ana­li­zę wpły­wu, testo­wa­nie jed­no­znacz­no­ści nie jest żad­nym mode­lem, nie jest przy­dat­ny do ana­li­zy. Można nim co naj­wy­żej ład­nie zilu­stro­wać doku­men­ty ale na pew­no nie nada­je się do ana­li­zy a przy­po­mnę, że:

nauka mówi dość jasno: aby prze­wi­dy­wać reak­cje bada­ne­go przed­mio­tu nale­ży zro­zu­mieć jak funk­cjo­nu­je i opra­co­wać jego model. Po dro­dze nale­ży udo­wod­nić, praw­dzi­wość modelu.

Zaś:

Samo utwo­rze­nie map (bo nie mode­li) w posta­ci dia­gra­mów z pomo­cą wywia­dów, sesji warsz­ta­to­wych i obser­wa­cji, da pro­dukt podob­ny do zdję­cia lot­ni­cze­go rze­ki: wie­my któ­rę­dy pły­nie, ale kom­plet­nie nie rozu­mie­my dla­cze­go aku­rat tak.

Tak więc, jeże­li ana­li­za ma posłu­żyć wdro­że­niu jakie­go­kol­wiek opro­gra­mo­wa­nia czy zmian orga­ni­za­cyj­nych, to pomo­gą nam w tym tyl­ko mode­le a nie obraz­ki”…

Na kon­fe­ren­cjach i forach toczą się sta­le dys­ku­sje na ten temat. Większość firm dorad­czych, infor­ma­tycz­nych oraz ich ana­li­ty­cy bro­nią tezy, że celem ana­li­zy jest zebra­nie infor­ma­cji w posta­ci doku­men­tów i zesta­wień. Niestety takie doku­men­ty są kom­plet­nie nie­przy­dat­ne, mają war­tość nagra­nia (patrz wyżej zdję­cie lot­ni­cze), nie da się na ich posta­wie wycią­gać żad­nych pozwa­la­ją­cych na dowo­dze­nie ich słusz­no­ści, wnio­sków nie licząc może oce­ny este­ty­ki edytorskiej.

Wiele się pisze o tym, że mode­lo­wa­nie słu­ży do doku­men­to­wa­nia pro­jek­tów. Otóż nie. Do doku­men­to­wa­nia pro­jek­tów słu­ży ryso­wa­nie, mode­lo­wa­nie słu­ży do pro­wa­dze­nia ana­liz poprzez testy mode­li, symu­la­cje i ana­li­zę sce­na­riu­szy. (Sabotaż doku­men­ta­cyj­ny).

Niewątpliwą zale­tą takiej pisa­nej obraz­ko­wej ana­li­zy” jest to, że nie wyma­ga ona abso­lut­nie żad­nych kom­pe­ten­cji poza umie­jęt­no­ścią komu­ni­ka­cji. Takim ana­li­ty­kiem może być nie­mal­że każ­dy (łatwa rekru­ta­cja, niski koszt), ale czy taki jest cel ana­liz poprze­dza­ją­cych pro­jek­ty, war­te set­ki tysię­cy zło­tych a nie raz miliony?

Na zakoń­cze­nie dodam, że naj­gor­szym spo­so­bem jaki znam i jaki nie­ste­ty czę­sto spo­ty­kam, na mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej, jest uży­cie dia­gra­mu klas lub dia­gra­mu przy­pad­ków uży­cia i mode­lo­wa­nie z zasto­so­wa­niem dzie­dzi­cze­nia (klas lub aktorów).

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie i sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Na zakoń­cze­nie pole­cam cie­ka­wy arty­kuł na temat mode­lo­wa­nia ról w opro­gra­mo­wa­niu.