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?

Inne artykuły na podobny temat

Komentarze

  1. Mike_R 5 kwietnia 2016 at 13:42

    Nareszcie jakieś dobre-pro­ste wyja­śnie­nie. Dzięki.

  2. Szympans u steru 6 kwietnia 2016 at 09:28

    Czy zatem nale­ża­ło­by wyłą­czyć bazo­da­now­ców z pro­ce­su two­rze­nia wymagań?
    Doświadczenie uczy, że czę­sto są to oso­by postrze­ga­ne jako jed­ne z naj­waż­niej­szych w pro­jek­cie IT. 

    Jakkolwiek uwa­żam, że każ­dy czło­nek zespo­łu jest waż­ny w pro­ce­sie two­rze­nia apli­ka­cji (tak rów­nież mar­ke­tin­go­wiec), to bazo­da­now­cy czę­sto pod­cho­dzą do samych sie­bie tak jak jak przy­kła­do­wo praw­ni­cy… nie ujmu­jąc wszyst­kim praw­ni­kom spo­ra ich część pra­cu­je na opi­nię o bran­ży jako kaście nadę­tych dup­ków z nosa­mi w chmurach.

    • Jaroslaw Zelinski 6 kwietnia 2016 at 09:40

      Ja ich już daw­no wyłą­czy­łem :). Najważniejsze? Kiedyś gdy baza danych sta­no­wi­ła 99% pro­jek­tu imple­men­ta­cji tak.… teraz nie (o ile nie mówi­my o meto­dach struk­tu­ral­nych). Owszem, każ­dy czło­nek zespo­łu jest waż­ny, jed­nak klucz to okre­śle­nie ról w pro­jek­cie i rezy­gna­cja ze zbio­ro­wej odpo­wie­dzial­no­ści. Zwróć uwa­gę, że o jako­ści dzia­ła­nia biblio­te­ki nie decy­du­je sza­fa z kartoteką.… 

      Co do opi­nii … z grzecz­no­ści nie zaprzeczę 😉

  3. pytacz 5 października 2021 at 08:30

    Dzień dobry 🙂 W Enterprise Architect jeśli cho­dzi o mode­lo­wa­nie danych jest tyl­ko jed­na moż­li­wość: nota­cja Barkera (wino­gron­ka), nie ma nota­cji Martina (kurze sto­py). Jeśli chciał­bym przed­sta­wić model danych jako encje + rela­cje (licz­no­ści) to jedy­ny spo­sób w jaki mogę to zro­bić to sko­rzy­stać z dia­gra­mu klas UML. Czy takie podej­ście jest zgod­ne ze sztuką?

    • Jarosław Żeliński 5 października 2021 at 16:03

      Kilka słów ogól­nie tutaj: archi­tek­tu­ra kodu

      To trosz­kę pyta­nie z gatun­ku czy mogę uży­wać, łopa­ty do zabi­ja­nia much bo nie mam stan­dar­do­wej pac­ki na muchy”… ;). Odpowiedź zawsze będzie brzmia­ła: owszem, ale pamię­taj o konsekwencjach.

      Z tak zwa­ną sztu­ką” nie ma to abso­lut­nie nic wspól­ne­go, bo gene­ral­nie zade­kla­ro­wa­nie sto­so­wa­nia nota­cji UML każe użyć do inter­pre­ta­cji takich dia­gra­mów spe­cy­fi­ka­cji UML, a nota­cja ta powsta­ła do cze­go inne­go (o mode­lo­wa­niu danych w UML nie ma ani sło­wa, nie przy­pad­kiem świat ma dia­gra­my ERD i sto­sow­ne nota­cje do mode­lo­wa­nia danych w rela­cyj­nym ich mode­lu). Paradygmat obiek­to­wy jest dale­ki od rela­cyj­ne­go mode­lu danych i towa­rzy­szą­ce­mu mu struk­tu­ral­ne­go para­dyg­ma­tu pro­jek­to­wa­nia oprogramowania. 

      Aby nie brnąć w aka­de­mic­kie meto­dy (dość czę­sto nad­mia­ro­we 😉 ) oraz zaspo­ko­ić i wil­ka i owcę moż­na tak: dekla­ru­je­my, że pro­jek­tu­je­my w UML war­stwę odwzo­ro­wa­nia tabel baz danych z pomo­cą wzor­ców obiek­to­wych acti­ve record (mapo­wa­nie obiekt-rekord) lub acti­ve table (mapo­wa­nie kla­sa-tabli­ca), dekla­ru­je­my też w tym celu pro­sty pro­fil zawie­ra­ją­cy jeden ste­reo­typ «ORM»: ozna­czo­na tym ste­reo­ty­pem kla­sa (i jej atry­bu­ty) będzie wte­dy inte­pre­to­wa­na jako kla­sa imple­men­tu­ją­ca inter­fejs do tabli­cy bazy danych. Najprościej: budu­je­my dia­gram klas ozna­cza­jąc wszyst­kie kla­sy ste­reo­ty­pem «ORM», kla­sy, ich atry­bu­ty i aso­cja­cje mię­dzy kla­sa­mi inte­pre­tu­je­my jako krot­ki, atry­bu­ty i rela­cje mode­lu rela­cyj­ne­go w nota­cji Martina (czę­sto sto­so­wa­ny ste­reo­typ w narzę­dziach wspie­ra­ją­cych ORM, np. Hibernate, to «ORM Pesistable»). Kilka słów o tym tak­że tu: JPA ORM.

      Przykład aka­de­mic­ki takie­go pro­fi­lu opi­sa­no w: Torres, A., Galante, R., & Pimenta, M. (2009). Towards a UML Profile for Model-Driven Object-Relational Mapping. https://​doi​.org/​1​0​.​1​1​0​9​/​S​B​E​S​.​2​0​0​9​.22.

    • Jarosław Żeliński 5 października 2021 at 16:04

      BTW: z tego powo­du coraz wię­cej ludzi na świe­cie powo­li rezy­gnu­je z EA SPARX ;), to sta­re narzę­dzie z wiel­kim dłu­giem tech­no­lo­gicz­nym.. Po dru­gie rela­cyj­ny model danych i SQL powo­li odcho­dzą do lamu­sa ;), pole­cam tek­sty o BigData i NoSQL. 

  4. pytacz 5 października 2021 at 16:30

    Dziękuję za wyja­śnie­nia 🙂 Myślałem, że sko­ro wizu­al­nie dia­gram ERD w nota­cji Martina wyglą­da tak samo jak dia­gram klas (bez metod) to nic w tym złe­go 😉 A mam jesz­cze jed­no pyta­nie. Jaką notacją/notacjami powin­no się posłu­żyć żeby zamo­de­lo­wać trans­for­ma­cję i prze­pły­wy danych (w tym pli­ków z dany­mi) mię­dzy sys­te­ma­mi. Załóżmy: w pierw­szym kro­ku sys­tem X gene­ru­je pli CSV, następ­nie sys­tem Y wyko­rzy­stu­je ten plik, prze­twa­rza te dane, następ­nie sys­tem Z inte­gru­je się z sys­te­mem Y. A za wszyst­ko to dzie­je się w ramach pro­ce­su biz­ne­so­we­go XYZ”. Jak to wszyst­ko zamo­de­lo­wać i jesz­cze powią­zać z procesem…

    • Jarosław Żeliński 5 października 2021 at 16:57

      Wizualne podo­bień­stwo nota­cji to w PowerPoint dzia­ła 😉 … Notacje for­mal­ne to raczej mate­ma­ty­ka 🙂 (nie przy­pad­kiem są tak­że przed­mio­tem norm).

      Co do dru­gie­go pyta­nia: UML (tu jest kil­ka typów dia­gra­mów), w sumie nary­su­ję to ale popro­szę jakiś bogat­szy opis tego pro­ce­su z tymi XYZ, bo gene­ral­nie to IT wspie­ra pro­ces biz­ne­so­wy a nie odwrot­nie ;): któ­re z tych sys­te­mów są wyko­rzy­sty­wa­ne przez ludzi w pro­ce­sie biznesowym.

    • Jarosław Żeliński 5 października 2021 at 17:18

      jak inte­pre­to­wać zda­nie: następ­nie sys­tem Z inte­gru­je się z sys­te­mem Y”, któ­ry sys­tem co tu robi?

  5. Pytacz 5 października 2021 at 18:00

    O super 🙂 załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data.

    Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kursy)

    Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY.

    SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego systemu. 

    Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API.

    Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czytelne?

  6. Pytacz 24 października 2021 at 16:29

    To jesz­cze inny wątek. Napisał Pan: „.. : 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..” – czy­li jeśli mam np. kom­po­nent np. GeneratorFaktur to zgod­nie z obiek­ty­wom para­dyg­ma­tem kogo odpy­tu­ję żeby uzy­skać dane sprze­daw­cy do wysta­wie­nia fak­tu­ry: odpy­tu­ję np. kom­po­nent BazaKlientów z argu­men­tem np. NIP? Dobrze rozumiem?

    • Jarosław Żeliński 24 października 2021 at 20:49

      GeneratorFaktur jako logi­ka two­rze­nia Faktury two­rzy Fakturę. BazaKlientów słu­ży tu (temy Generatorowi) jako źró­dło danych klien­tów, ale to może być APi do usłu­gi GUS, któ­ra na NIP odpo­wia­da dany­mi pod­mio­tu gospo­dar­cze­go. Dane sprze­daw­cy (jest pra­cow­ni­kiem sprze­da­ją­ce­go) wysta­wia­ją­ce­go tę fak­tu­rę pobrał bym z reje­stru pra­cow­ni­ków, na pod­sta­wie jego iden­ty­fi­ka­to­ra bo zakła­dam, że jest zalo­go­wa­ny” więc znam jego iden­ty­fi­ka­tor (to para­metr sesji).

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.