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].

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ę 😉