Model pojęciowy, model danych, model dziedziny systemu

Niemalże każ­de spo­tka­nie pro­jek­to­we, na któ­rym oma­wia­ne są mode­le UML, na każ­dym szko­le­niu na temat UML, poja­wia się pro­blem o któ­rym pisze Ron Ross (wytłusz­cze­nia moje):

Another impli­ca­tion is that con­cept models and logi­cal data models are cle­ar­ly distinct. Unfortunately, many people blur the line betwe­en them. That?s wrong. A con­cept model is abo­ut the meaning of the words you use, and the busi­ness sta­te­ments you make assu­ming tho­se meanings. It?s abo­ut com­mu­ni­ca­tion. A logi­cal data model is abo­ut how you orga­ni­ze what you think you know abo­ut the world so it can be recor­ded and logi­cal­ly mani­pu­la­ted in a sys­te­ma­tic way.I star­ted my care­er in data. It took me as much as 15 years of inten­se work on busi­ness rule sta­te­ments (1990 – 2005) to ful­ly appre­cia­te the dif­fe­ren­ce. But now I am very cle­ar that con­cept models do need to be deve­lo­ped to excru­cia­ting level of deta­il in order to disam­bi­gu­ate the inten­ded busi­ness communication.Most busi­nesses don?t do that today. They jump in at data design (con­cep­tu­al, logi­cal or even phy­si­cal). And they unk­no­win­gly pay a big pri­ce for it. (Źródło: Concept Model vs. Data Model ? Ron Ross on Business Rules)

Generalnie model poję­cio­wy, model danych to skraj­nie róż­ne mode­le. Jeżeli do tego doda­my dys­ku­sje na temat obiek­to­we­go mode­lu dzie­dzi­ny, to na spo­tka­niu mamy nie­mal­że gwa­ran­cje ostre­go sporu.

Widzę dwa głów­ne źró­dła tych pro­ble­mów. Pierwsze to fakt, że w szko­łach wyż­szych nadal kró­lu­je ana­li­za struk­tu­ral­na, a po maco­sze­mu trak­to­wa­na ana­li­za sys­te­mo­wa i obiek­to­wa (obie bazu­ją na kon­cep­cji współ­pra­cu­ją­cych obiek­tów i ope­ru­ją poję­ciem obiekt zaś ter­min” to poję­cie słow­ni­ko­we). Teoria sys­te­mów i opar­ty na niej para­dyg­mat obiek­to­wy są nie­ste­ty trud­ne, bazu­ją w 100% na her­me­ty­za­cji i abs­tra­ho­wa­niu od szcze­gó­łów, a ode­rwa­nie się od szcze­gó­łów więk­szo­ści ludziom przy­cho­dzi z ogrom­nym tru­dem albo nie uda­je się w ogó­le. Drugie to powszech­ne myle­nie kon­tek­stów słów ter­min” (poję­cie) i kon­cep­cja” (pomysł, idea) w lite­ra­tu­rze anglojęzycznej:

con­cept {rzecz.} (też: notion, idea, con­cep­tion, term) poję­cie {n.} Same con­cept, but looking at com­mu­ni­ca­tion dyna­mics in a very dif­fe­rent sphe­re. To samo poję­cie, ale patrząc na dyna­mi­kę komu­ni­ka­cji w zupeł­nie odmien­nej sferze.

con­cept {rzecz.} (też: con­cep­tion, idea) kon­cep­cja {f.} However, we ought to be awa­re that the con­cept of vic­ti­mi­sa­tion requ­ires strong pro­of. Musimy jed­nak być świa­do­mi, że kon­cep­cja repre­sjo­no­wa­nia wyma­ga moc­nych dowodów.

term {rzecz.} (też: notion, idea, con­cep­tion, con­cept) poję­cie {n.} Really cool term: neo­te­ny – the reten­tion of play and juve­ni­le tra­its in adults. Świetne poję­cie – neo­te­nia, zacho­wa­nie u doro­słych mło­dzień­czych cech i chę­ci do zabawy.

(źr. http://​pl​.bab​.la/​s​l​o​w​n​i​k​/​a​n​g​i​e​l​s​k​i​-​p​o​l​s​k​i​/​c​o​n​c​ept)

Do tego docho­dzą nota­cje i cza­sa­mi wręcz nie zro­zu­mie­nie ich seman­ty­ki i zasto­so­wa­nia. W oma­wia­nym obsza­rze od lat są sto­so­wa­ne dwie, od nie­daw­na trzy notacje:

  1. dia­gram związ­ków encji (naj­po­pu­lar­niej­sze nota­cje to Crow?s Feet” czy­li kurze stop­ki 🙂 i jej wer­sja zwa­na, nota­cją bar­ke­ra (Barker’s nota­tion, ERD, ang. Entity Relationship Diagram)
  2. dia­gram klas nota­cji UML (ang. Unified Modeling Language)
  3. dia­gram fak­tów (ang. SBVR, Semantics Of Business Vocabulary And Rules)

Pierwszy słu­ży do two­rze­nia mode­li w para­dyg­ma­cie rela­cyj­nym na trzech pozio­mach ogól­no­ści, wszyst­kie trzy są mode­la­mi danych (a nie pojęć):

  1. Conceptual data model
  2. Logical data model
  3. Physical data model

Diagram klas w nota­cji UML słu­ży do two­rze­nia modeli:

  1. poję­cio­wych (wszyst­kie dia­gra­my klas w spe­cy­fi­ka­cjach OMG to mode­le poję­cio­we opi­su­ją­ce seman­ty­ką i syn­tak­ty­kę danej notacji),
  2. mode­li obiek­to­wych (dia­gram obiek­tów) i ich meta­mo­de­li (dia­gram klas), są to tak zwa­ne mode­le dzie­dzi­ny sys­te­mu (logi­ka, mecha­nizm dzia­ła­nia apli­ka­cji, przed­się­bior­stwa, każ­de­go sys­te­mu w rozu­mie­niu teo­rii systemów),
  3. mode­li struk­tu­ry kodu apli­ka­cji (dia­gram klas).

Od nie­daw­na mamy nota­cje SBVR a w niej dia­gram Fact dia­gram”. Jest to dia­gram (nie jest to dia­gram klas UML, ale dia­gra­mu klas UML moż­na użyć by go zastą­pić) repre­zen­tu­ją­cy w for­mie gra­ficz­nej słow­nik pojęć i jest to spe­cy­ficz­ny model poję­cio­wy, opar­ty na tak zwa­nych związ­kach opar­tych na fak­tach (aso­cja­cje repre­zen­tu­ją tu fak­ty, któ­re kon­tek­sto­wo koja­rzą dane dwa poję­cia np. doku­ment opi­su­je zda­rze­nie, pod­kre­śle­nia wska­zu­ją na poję­cia ze słow­ni­ka (są w nim zde­fi­nio­wa­ne) o sło­wo pisa­ne kur­sy­wą to fakt, któ­ry je kon­tek­sto­wo koja­rzy (mode­le fak­tów to nie są ontologie).

Modele danych (np. dia­gra­my ERD) to struk­tu­ry poka­zu­ją­ce orga­ni­za­cję danych (infor­ma­cji). Mogą być na dużym pozio­mie abs­trak­cji w posta­ci wstęp­ne­go pomy­słu”, mogą być wypra­co­wa­nym mode­lem i mogą być mniej lub bar­dziej kom­pro­mi­so­wym pla­nem implementacji.

Obiektowy para­dyg­mat oraz ogól­na teo­ria sys­te­mów zakła­da­ją, że wszyst­ko to co obser­wu­je­my to pew­na więk­sza lub mniej­sza zło­żo­ność opi­sa­na jako skoń­czo­na licz­ba współ­pra­cu­ją­cych ele­men­tów (lub ich klas). Każdy ele­ment ma okre­ślo­ne cechy, każ­dy w okre­ślo­ny spo­sób reagu­je na bodź­ce z oto­cze­nia. Całkowitą zło­żo­ność wyzna­cza licz­ba tych ele­men­tów i pro­sto­ta lub jej brak, reak­cji na bodź­ce. Doskonale tłu­ma­czy to meta­fo­ra K.Poppera o zega­rach i chmurach:

Generalnie pro­blem zło­żo­no­ści ład­nie opi­sał Karl Popper, w swo­im dzie­le Wiedza Obiektywna meta­fo­rą ?o chmu­rach i zega­rach?. To co obser­wu­je­my, sys­tem, może być tak zło­żo­ne, że ilość obiek­tów i ich wza­jem­nych oddzia­ły­wań będzie zbyt duża, by moż­li­we było stwo­rze­nie mode­lu (teo­ria wyja­śnia­ją­ca zacho­wa­nie) takie­go sys­te­mu, pozwa­la­ją­ce­go na prze­wi­dy­wa­nie zacho­wa­nia takiej zło­żo­no­ści. Są jed­nak sys­te­my, któ­rych natu­ra na to pozwa­la, ich model jest moż­li­wy do stwo­rze­nia, takie sys­te­my są prze­wi­dy­wal­ne w 100%. Metaforą sys­te­mu nie­prze­wi­dy­wal­ne­go jest chmu­ra, a prze­wi­dy­wal­ne­go zegar. Oczywiście jest nie­skoń­cze­nie wie­le sys­te­mów o natu­rze gdzieś pomię­dzy chmu­ra­mi i zega­ra­mi. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting)

Elementy sys­te­mu mają swo­je cechy (ukry­te: her­me­ty­za­cja) a uze­wnętrz­nia­ją wyłącz­nie reak­cje na bodź­ce (żąda­nia). W efek­cie sys­tem żyje” ale nie jest bazą danych”. UML i dia­gram klas, w tym wypad­ku, mode­lu­je współ­pra­cu­ją­ce obiek­ty a nie bazę danych”. To, że taka baza (każ­da for­ma utrwa­la­nia danych) fizycz­nie ist­nie­je (jest two­rzo­na) to wyłącz­nie sku­tek potrze­by jaką jest zapa­mię­ta­nie sta­nu sys­te­mu (apli­ka­cji).

Niewątpliwie jed­nak dia­gram klas UML nie jest mode­lem danych, i nie słu­ży do mode­lo­wa­nia danych… 

Model kom­po­nen­tu sys­te­mu, opi­su­ją­cy mecha­nizm jego dzia­ła­nia (logi­kę) to tak zwa­ny model dzie­dzi­ny” czy­li obiek­to­wy model sys­te­mu opi­su­ją­cy (mode­lu­ją­cy) mecha­nizm jego dzia­ła­nia. Owszem, apli­ka­cja może słu­żyć do zarzą­dza­nia duży­mi i zor­ga­ni­zo­wa­ny­mi zbio­ra­mi danych ale to to samo co zespół ludzi – sys­tem współ­pra­cu­ją­cych obiek­tów mają­cych – każ­dy – wie­le cech – zarzą­dza­ją­cy biblio­te­ką: Ci ludzie i ich cechy to nie baza danych” a ukry­te do ich wia­do­mo­ści cechy i umie­jęt­no­ści, dostęp­ne dla innych wyłącz­nie pod warun­kiem zada­nia pyta­nia i woli odpo­wie­dzi na nie, ci ludzie mogą zarzą­dzać” jakimś zbio­rem danych. 

Dlatego ubo­le­wam, gdy oso­by będą­ce nauczy­cie­la­mi aka­de­mic­ki­mi, tre­ne­ra­mi pro­wa­dzą­cy­mi szko­le­nia czy auto­ra­mi wie­lu uczo­nych” blo­gów, publi­ku­ją pomy­sły o mode­lo­wa­niu danych z uży­ciem UML… co nie ma nic wspól­ne­go z UML.

O SBVR, mode­lach poję­cio­wych i dia­gra­mie fak­tów pisa­łem w arty­ku­le SBVR czy­li regu­ły biz­ne­so­we i słow­nik. Kwestie dia­gra­mów klas opi­sa­łem mię­dzy inny­mi w arty­ku­le Cholerny dia­gram klas i w Czym jest a czym nie jest model dzie­dzi­ny. Jeśli zaś cho­dzi o to czym nie jest dia­gram ERD pisa­łem przy oka­zji Wiedza po stu­diach? Zostaliście oszukani?