Czym jest a czym nie jest tak zwany model dziedziny systemu

UML 2.4.1. Superstructure - the taxonomy od structure and behavior diagram
Taksonomia dia­gra­mów UML

Ten arty­kuł to kon­ty­nu­acja wąt­ku roz­po­czę­te­go wpi­sem o mode­lu dzie­dzi­ny i dia­gra­mie klas, jed­nak inna jest inten­cja. Wśród wie­lu listów i pytań od stu­den­tów i pra­cu­ją­cych już ana­li­ty­ków, na temat UML, regu­lar­nie poja­wia się pyta­nie o dia­gram klas i mode­lo­wa­nie tak zwa­nej dzie­dzi­ny sys­te­mu. Gdy odpo­wia­dam czę­sto poja­wia się zarzut, a tam napi­sa­no, że…”.

Ten arty­kuł to mię­dzy inny­mi chęć zwró­ce­nia uwa­gi na to, że w sie­ci i wie­lu książ­kach nie­ste­ty mamy nie mało tak zwa­nej pseu­do­wie­dzy… Z zasa­dy nie oce­niam tre­ści innych stron, jed­nak trud­no zigno­ro­wać coś, co ktoś poda­je jako przy­kład w roz­mo­wie ze mną. Cytat, któ­ry przy­to­czy­łem w dal­szej czę­ści (jaw­nie poda­ne źró­dło), pocho­dzi z cyklu arty­ku­łów jakie uka­za­ły się w piśmie Software Developer Journal, umiesz­czo­ne­go na publicz­nej stro­nie WWW ich auto­ra, tre­ne­ra pro­wa­dzą­ce­go szko­le­nia z UML.

Artykuł ten dedy­ku­ję mię­dzy inny­mi każ­de­mu kto podej­mu­je decy­zję o szko­le­niu, w jakiej fir­mie i u jakie­go trenera.

Na pyta­nia o to, czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu” moż­na odpo­wie­dzieć pod warun­kiem wcze­śniej­sze­go zde­fi­nio­wa­nia poję­cia dzie­dzi­na sys­te­mu”. Bez tej defi­ni­cji wszel­kie dywa­ga­cje o mode­lo­wa­niu dzie­dzi­ny sys­te­mu” są nie­ste­ty bez­przed­mio­to­we (i bez sensu).

Pewien foru­mo­wicz, po lek­tu­rze kil­ku zna­le­zio­nych stron WWW zapytał:

Czy może­cie mi wytłu­ma­czyć co ozna­cza­ją poję­cia model dzie­dzi­ny” oraz model kon­cep­tu­al­ny”? Czy model dzie­dzi­ny zawie­ra tak­że dia­gram kon­cep­tu­al­ny klas?

Cóż, pro­blem defi­ni­cji pojęć. Uporządkujmy to co nie­co. Wpisanie hasła dzie­dzi­na sys­te­mu” do Google daje nie­ste­ty tak róż­ne infor­ma­cje, nie raz sprzecz­ne, że wyłu­ska­nie z tego praw­dy” dla począt­ku­ją­ce­go jest nie­mal­że nie­moż­li­we (nie­ste­ty tu uwi­dacz­nia się wada Internetu jako źró­dła wie­dzy”). Zróbmy to więc jak nale­ży ;), celo­wo uży­wam WIKI, bo to popu­lar­ne dar­mo­we źró­dło wie­dzy, ale zazna­czam, że cytu­je to co znam i wiem, że ma potwier­dze­nie w tra­dy­cyj­nej lite­ra­tu­rze naukowej.

Definicja poję­cia system:

System (stgr. ??????? sys­te­ma ? rzecz zło­żo­na) ? 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ść) (System ? Wikipedia, wol­na ency­klo­pe­dia).

Myślę, że tej defi­ni­cji nie trze­ba komen­to­wać. Kilka słów o poję­ciu dzie­dzi­na”. To bar­dzo nie­for­tun­ne tłu­ma­cze­nie sło­wa doma­in, bo model dzie­dzi­ny to w ory­gi­na­le doma­in model. Tu cho­dzi o dome­nę a nie dzie­dzi­nę (te sło­wa w j.polskim mają jed­nak nie­co inne znaczenie).

Domena (domi­nium) ? kate­go­ria sys­te­ma­tycz­na wyż­sza od kró­le­stwa, sto­so­wa­na w kla­sy­fi­ka­cji bio­lo­gicz­nej (Domena (bio­lo­gia) ? Wikipedia, wol­na ency­klo­pe­dia).

Domena to poję­cie mają­ce rodo­wód w bio­lo­gii, podob­nie zresz­tą jak teo­ria sys­te­mów” 🙂 i odno­si się do sys­te­ma­ty­zo­wa­nia cze­goś (kla­sy­fi­ko­wa­nia, stąd tak­że poję­cie klasa).

Pojęcie dzie­dzi­ny: dzie­dzi­na rela­cji, log. zbiór wszyst­kich przed­mio­tów pozo­sta­ją­cych w danej rela­cji do co naj­mniej jed­ne­go przed­mio­tu. (Encyklopedia PWN) ma swo­je odzwier­cie­dle­nie w mode­lu rela­cyj­nym baz danych i ana­li­zie struk­tu­ral­nej. To, co w meto­dach struk­tu­ral­nych bywa nazy­wa­ne mode­lem dzie­dzi­ny, to wła­śnie rela­cje pomię­dzy przed­mio­ta­mi (byta­mi). Jest to tak zwa­ny model poję­cio­wy (ang. con­cep­tu­al model to model poję­cio­wy, tu bazy danych, a nie kon­cep­cyj­ny w rozu­mie­niu pomysł na…”) wyra­ża­ny dia­gra­mem ERD (ang. Entity Relationship Model) i opi­su­ją­cy struk­tu­ry danych.

W para­dyg­ma­cie obiektowym:

Object-orien­ted pro­gram­ming (OOP) is a pro­gram­ming para­digm that repre­sents con­cepts as objects” that have data fields (attri­bu­tes that descri­be the object) and asso­cia­ted pro­ce­du­res known as methods. […] An object-orien­ted pro­gram may be vie­wed as a col­lec­tion of inte­rac­ting objects, as oppo­sed to the conven­tio­nal model, in which a pro­gram is seen as a list of tasks (sub­ro­uti­nes) to per­form. (Object-orien­ted pro­gram­ming – Wikipedia, the free encyc­lo­pe­dia).

W wol­nym tłu­ma­cze­niu: obiek­to­wy para­dyg­mat pro­gra­mo­wa­nia to repre­zen­to­wa­nie pojęć w posta­ci obiek­tów”, mają­cych atry­bu­ty (dane opi­su­ją­ce obiekt) oraz powią­za­ne pro­ce­du­ry, nazy­wa­ne meto­da­mi. Program obiek­to­wy nale­ży postrze­gać jako kolek­cję współ­dzia­ła­ją­cych obiek­tów, w prze­ci­wień­stwie do kon­wen­cjo­nal­ne­go mode­lu pro­gra­mo­wa­nia, gdzie wyłącz­nie” pro­gram to lista pole­ceń (zadań, pod­pro­gra­mów) [przyp. mój] ope­ru­ją­cych na okre­ślo­nym zesta­wie danych (baza danych).

Tak więc w para­dyg­ma­cie obiek­to­wym doma­in model, czy­li model dzie­dzi­ny”, to kolek­cja obiek­tów repre­zen­tu­ją­cych mode­lo­wa­ny pro­blem. Innymi słowy:

obiek­to­wy model dzie­dzi­ny sys­te­mu to zestaw pojęć repre­zen­tu­ją­cych przed­mio­ty z dane­go obsza­ru poję­cio­we­go (np. han­del i sprze­daż, pro­duk­cja kabli, itp.), zawie­ra­ją­cy dla każ­de­go przed­mio­tu opis jego cech i pro­ce­dur jakie może wykonać.

Taka kolek­cja współ­pra­cu­ją­cych obiek­tów, to przede wszyst­kim owe obiek­ty i ich meto­dy (umie­jęt­no­ści). Ich cechy są ukry­te wewnątrz nich, nie są przed­mio­tem współ­dzia­ła­nia, bo współ­dzia­ła­nie pole­ga komu­ni­ko­wa­niu się obiek­tów mię­dzy sobą a nie prze­twa­rza­niu danych, któ­re jako takie nie wystę­pu­ją w tym paradygmacie.

Ale podob­no pro­gram kom­pu­te­ro­wy słu­ży do prze­twa­rza­nia danych! 

Hm… tyl­ko wte­dy, gdy patrzy­my na biz­nes jak na zbie­ra­nie danych. Sprzedaż moż­na postrze­gać jako prze­twa­rza­nie danych o trans­ak­cjach sprze­da­ży”, moż­na jed­nak też postrze­gać ją jako ope­ro­wa­nie na obiek­tach biz­ne­so­wych takich jak: pro­duk­ty, zamó­wie­nia i fak­tu­ry”. Jest to dia­me­tral­na róż­ni­ca. Tu inte­re­su­je nas przede wszyst­kim to, że obiek­ty takie jak Produkt, zmie­ni­ły wła­ści­cie­la, obiekt Zamówienie jest mate­ria­li­za­cją tego cze­go ocze­ku­je zama­wia­ją­cy, zaś Faktura mate­ria­li­za­cją fak­tu doko­na­nia tej sprze­da­ży. Dane takie jak, cena, ilość, poda­tek, to tyl­ko cechy tych obiek­tów, któ­re są nie­zbęd­ne by te trans­ak­cje zosta­ły prze­pro­wa­dzo­ne w spo­sób pra­wi­dło­wy i kon­tro­lo­wa­ny. Proszę zwró­cić uwa­gę na to, że celem kupu­ją­ce­go samo­chód jest ten­że samo­chód słu­żą­cy do swo­bod­ne­go podró­żo­wa­nia, a nie prze­two­rze­nie jego ceny, podat­ku, cię­ża­ru i nume­ru sil­ni­ka”. Użytkownikowi samo­cho­du potrzeb­ne są dwa obiek­ty: Samochód i jego DowódRejestracyjny.

Tyle teo­rii”. Jaki pro­blem miał ów foru­mo­wicz? Ano taki, że np. na stro­nie jed­nej z dość zna­nych firm szko­le­nio­wych, zna­lazł coś takie­go w arty­ku­le o UML i mode­lo­wa­niu obiektowym:

Zwróćmy uwa­gę, że na mode­lu dzie­dzi­ny nie umiesz­cza­my klas imple­men­tu­ją­cych logi­kę apli­ka­cji, jej inter­fejs użyt­kow­ni­ka czy war­stwę dostę­pu do danych. Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. Dzięki temu dia­gram jest pro­sty i powi­nien być zro­zu­mia­ły tak­że dla klien­ta nie mają­ce­go przy­go­to­wa­nia tech­nicz­ne­go i nie zain­te­re­so­wa­ne­go szcze­gó­ła­mi imple­men­ta­cji sys­te­mu. […] Model dzie­dzi­ny jest ele­men­tem ana­li­zy sys­te­mo­wej, uka­zu­ją­cym biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi. W dużych pro­jek­tach może on obej­mo­wać kil­ka­set klas. Decydując się na jego stwo­rze­nie, nie pozwa­la­my, aby istot­ne decy­zje mery­to­rycz­ne były podej­mo­wa­ne ad-hoc w trak­cie imple­men­ta­cji. (Diagramy klas – model dzie­dzi­ny i pro­jekt apli­ka­cji).

Cały ten aka­pit, jego oce­nę, pozo­sta­wiam teraz czy­tel­ni­kom (nie­ste­ty ten cykl arty­ku­łów zawie­ra błęd­ne przy­kła­dy mode­li i błęd­ne opi­sy struk­tu­ry obiek­to­we­go kodu pro­gra­mu). To, co celo­wo wytłu­ści­łem to nie­ste­ty fun­da­men­tal­ny błąd w powyż­szym tek­ście: obiek­to­wy model dzie­dzi­ny to abso­lut­nie nie są struk­tu­ry danych i zależ­no­ści mię­dzy nimi.

Forumowicz: Coraz więk­szy mętlik w gło­wie. Wcześniej mia­łem do czy­nie­nia tyl­ko z dia­gra­mem związ­ków encji. Teraz nawet nie bar­dzo widzę róż­ni­cę pomię­dzy nim a dia­gra­mem klas.

No nie­ste­ty, mając za sobą tek­sty jak powyż­szy, nie dzi­wię się. Model w posta­ci dia­gra­mu ERD to wła­śnie owe struk­tu­ry danych i zależ­no­ści pomię­dzy nimi”, ale nie ma to abso­lut­nie nic wspól­ne­go ani z dia­gra­mem klas ani z obiek­to­wym para­dyg­ma­tem. Różnica jest fundamentalna:

- ERD to dia­gram opi­su­ją­cy dane i tyl­ko dane (tu nie wie­my nawet do cze­go one słu­żą bo ta wie­dza jest w funkcjach)

- obiek­to­wy model dzie­dzi­ny to dia­gram klas (UML) obra­zu­ją­cy wyłącz­nie role (obiek­ty mają cel ist­nie­nia, ich atry­bu­ty są ich pry­wat­ną wła­sno­ścią, nie widać ich)

Forumowicz: Piszesz, że dia­gram klas w mode­lu dzie­dzi­ny opi­su­ję logi­kę apli­ka­cji a jak to się ma do defi­ni­cji dia­gra­mu klas któ­ra mówi, że jest to sta­tycz­ny opis struk­tu­ry sys­te­mu. Skoro jest to model sta­tycz­ny to raczej nie poka­zu­je zachowania.

Logika sys­te­mu to nie dyna­mi­ka dzia­ła­nia a zestaw reguł dzia­ła­nia, są one zawar­te w meto­dach klas. Reguły są sta­tycz­ne, dyna­micz­ne są zacho­wa­nia czy­li odpo­wiedź na bodź­ce. Dynamika sys­te­mu to współ­dzia­ła­nie obiek­tów reali­zu­ją­cych jakieś zło­żo­ne zada­nie (to mode­lu­je­my dia­gra­mem sekwen­cji). Model sta­tycz­ny to kolek­cja obiek­tów wraz z opi­sem ich cech i metod jakie reali­zu­ją, czy­li wła­śnie model dzie­dzi­ny sys­te­mu wyra­żo­ny dia­gra­mem klas. Przywołując meta­fo­rę Fowlera, gra w sno­oke­ra to kule i fizy­ka ich ruchu oraz zasa­dy gry. Statyczny model sno­oke­ra moż­li­wy do poka­za­nia jako dia­gram klas to mię­dzy inny­mi kla­sa kula, któ­ra ma ope­ra­cje ude­rze­nie z para­me­tra­mi siła ude­rze­nia i kie­ru­nek oraz atry­bu­ty śred­ni­ca i masa. Czym jest tu dyna­mi­ka? Ona poja­wia się jako opis ude­rze­nia kijem w kulę… Czy model dzie­dzi­ny to jest model sta­tycz­ny struk­tu­ry opro­gra­mo­wa­nia? Tak, bo fun­da­men­tem para­dyg­ma­tu obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia jest to, że pro­gram obiek­to­wy to imple­men­ta­cja (odwzo­ro­wa­nie w kodzie) obiek­to­we­go mode­lu dzie­dzi­ny sys­te­mu. Odpowiedziałem forumowiczowi:

Model sta­tycz­ny to coś jak Ty i Twoi kole­dzy dla otoczenia:

- masz kon­kret­ną rolę (np. murarz), po tym moż­na iden­ty­fi­ko­wać Twoje umie­jęt­no­ści i wie­dzę, wia­do­mo co potra­fisz i jak o to popro­sić (wyko­nu­jesz kon­kret­ne pole­ce­nia opi­sa­ne w Twojej umo­wie o pra­cę – to Twoje metody),

- nikt w pra­cy nie wie ile masz lat, jaki masz nastrój, itp. więc dane” (two­je cechy) nie mają zna­cze­nia (są chro­nio­ne, dostęp­ne są wyłącz­nie w dzia­le HR), zna­cze­nie mają tyl­ko Twoje umie­jęt­no­ści, i to, że jako kon­kret­ny murarz masz imię i nazwi­sko, po któ­rym moż­na Cię iden­ty­fi­ko­wać na budowie.

Gdzie logi­ka biz­ne­so­wa? Ty wiesz jak muro­wać, znasz zasa­dy bez­pie­czeń­stwa, w razie potrze­by dosta­niesz pro­ce­du­rę dzia­ła­nia reali­za­cji np. spe­cy­ficz­nej ścia­ny. Poprawny i kom­plet­ny Model dzie­dzi­ny (doku­men­to­wa­ny dia­gra­mem klas) to kla­sy repre­zen­tu­ją­ce zarów­no mura­rza zawie­ra­ją­ce – meto­dy – pro­ce­du­ry dzia­ła­nia czy­li logi­kę biznesową.

Wyobraź sobie Twoje CV, co jako Ty ofe­ru­jesz? Swoja metry­kę? Nie. To co potra­fisz bo zgod­nie z pra­wem nawet Twoja płeć nie ma zna­cze­nia. Nie zmie­nia to fak­tu, że tecz­ka CV pra­cow­ni­ków fir­my to jej model sta­tycz­ny orga­ni­za­cji… Gdyby dia­gram klas słu­żył do tego co ERD nie było by dia­gra­mu klas…;).

Skąd się bie­rze taka sku­tecz­ność metod obiek­to­wych (o ile są pra­wi­dło­wo sto­so­wa­ne)? Metody struk­tu­ral­ne to roz­kła­da­nie pro­ble­mu biz­ne­so­we­go na oddzie­lo­ne od sie­bie dane i pro­ce­du­ry ich prze­twa­rza­nia. Informacje o obiek­tach rze­czy­wi­stych są tra­co­ne w tych meto­dach. Model rela­cyj­ny danych to model, w któ­rym utra­co­no wie­le infor­ma­cji, np. nie da się z mode­lu rela­cyj­ne­go odtwo­rzyć np. fak­tu­ry nie wie­dząc jak ona wyglą­da. Do wydru­ku fak­tu­ry potrzeb­ne jest zapy­ta­nie, któ­re wycią­gnie z bazy danych wła­ści­we dane i pro­ce­du­ra któ­ra wła­ści­wie je sformatuje.

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) świat” w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) dru­kuj”. Ale to temat na inny wpis :).

W kwe­stii obiek­to­we­go para­dyg­ma­tu pole­cam na począ­tek, poza stro­ną www​.omg​.org, książ­ki pre­kur­so­rów OOAP: Booch Grady, Rumbaugh James, Jacobson Ivar, oraz Eda Yourdona Analiza Obiektowa.

Inne artykuły na podobny temat

Komentarze

  1. Sławomir Sobótka 18 lutego 2013 at 10:57

    Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. Dzięki temu dia­gram jest pro­sty i powi­nien być zro­zu­mia­ły tak­że dla klien­ta nie mają­ce­go przy­go­to­wa­nia tech­nicz­ne­go i nie zain­te­re­so­wa­ne­go szcze­gó­ła­mi imple­men­ta­cji systemu.”

    LOL
    A może po pro­stu dome­na nie jest pro­sta” i model musi mieć postać taką jak mieć musi…

    W tym miej­scu na sce­nie powin­na poja­wić się Barbie con­sul­tant” ze swą nie­śmier­tel­ną kwe­stią: Analysis is hard, let’s go shopping”.

    Ale na poważnie:
    – zapis metod w nota­cji UML może być nie­zro­zu­mia­ły, dla­te­go nie trze­ba się go po pro­stu trzy­mać – cho­dzi o wyra­że­nie odpowiedzialności
    – zagu­bio­nym adep­tom moż­na zasu­ge­ro­wać nastę­pu­ją­cą radę: nale­ży zasta­no­wić się jaki jest cel two­rze­nia dane­go arte­fak­tu? W zdro­wej orga­ni­za­cji powin­no być to zro­zu­mie­nie i prze­ka­za­nie wie­dzy. Czy dia­gram rze­czow­ni­ków i powią­zań poję­cio­wym pomię­dzy nimi jest wystar­cza­ją­cy do głę­bo­kie­go zro­zu­mie­nia dyna­mi­ki i prze­ka­za­nia tej wiedzy?

    • Jarek Żeliński 18 lutego 2013 at 20:51

      ja zawsze mówię: na począ­tek sta­re dobre kar­ty CRC :), w kla­sie wystar­czy nazwać ope­ra­cję (nazwa pole­ce­nia), meto­dy to algo­ryt­mu, moż­na je opi­sać słow­nie, tabli­ca decy­zyj­ną, pseu­do­ko­dem, ale meto­dy to fak­tycz­nie technikalia…

  2. Pawel Zubkiewicz 20 lutego 2013 at 09:22

    Witam,

    Przeczytałem arty­kuł i szcze­rze mówiąc dużo bicia pia­ny o seman­ty­kę i nie wiem czy komuś coś roz­ja­śni­łeś w gło­wie Jarku. Proponuję następ­nym razem zamo­de­lo­wać kil­ka dia­gra­mów zamiast two­rzyć laborarty.

    Cytowana przez Ciebie oso­ba pisze Model dzie­dzi­ny jest ele­men­tem ana­li­zy sys­te­mo­wej, uka­zu­ją­cym biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi.” Kluczem do zro­zu­mie­nia jest «biz­ne­so­wa struk­tu­ra danych» – oso­bi­ście nie widzę nic rażą­ce­go w tym sformułowaniu. 

    Pracuje w orga­ni­za­cji gdzie ist­nie­je model obiek­tów biz­ne­so­wych zamo­de­lo­wa­ny na róż­nych pozio­mach aba­strak­cji m.in. też kon­cep­tu­al­nym. Są to mode­le wspol­ne dla cale­go biz­ne­su, do któ­rych IT ma dążyć. Przykładowo na pozio­mie kon­cep­tu­al­nym mamy zde­fio­ni­wa­ne rela­cje mie­dy obiek­ta­mi Umowa – Klient – Produkty. Kazdy niż­szy poziom abs­trak­cji uszcze­gó­ła­wia te rela­cje i dokła­da nowe obiek­ty biz­ne­so­we. W mode­lu nie ma atry­bu­tów czy metod. Czyli for­mu­ła biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi” jest dla mnie jak naj­bar­dziej prawdziwa.

    Oczywiście Context is the King i moż­li­we, że ów autor poda­wał sprzecz­ne przy­kła­dy do przy­to­czo­nej defi­ni­cji a ja się na siłe doszu­ku­ję prawdy.

    aha, kolej­na spra­wa jest tez taka, że model dome­ny to nie to samo co logicz­ny model danych (repre­zen­to­wa­ny cze­sto przez dia­gram klas) i fizycz­ny model danych (np. model tabe­li na bazie) aplikacji.

    • Jarek Żeliński 20 lutego 2013 at 10:07

      odpo­wia­dam:

      Cytowana przez Ciebie oso­ba pisze ?Model dzie­dzi­ny jest ele­men­tem ana­li­zy sys­te­mo­wej, uka­zu­ją­cym biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi.? Kluczem do zro­zu­mie­nia jest ?biz­ne­so­wa struk­tu­ra danych? ? oso­bi­ście nie widzę nic rażą­ce­go w tym sformułowaniu.

      A ja widzę i to bar­dzo, gdyż model dzie­dzi­ny w uję­ciu obiek­to­wym, a o takim pisze autor ucząc” ludzi UML’a, nie ma nic wspól­ne­go z mode­lem danych. Gdyby to było szko­le­nie z ana­li­zy struk­tu­ral­nej, mowa była by nie o UML/diagram klas a o dia­gra­mie ERD i tekst brzmiał by Model poję­cio­wy jest ele­men­tem ana­li­zy struk­tu­ral­nej, uka­zu­ją­cym biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi.” i zilu­stro­wa­ny był­by dia­gra­mem ERD, sło­wa bym nie powie­dział. Tego typu tek­sty pięt­nu­ję”, bo to pseu­do­wie­dza ludzi, któ­rzy mając być może duże doświad­cze­nie w ana­li­zie struk­tu­ral­nej (mode­le ERD i DFD), ubie­ra­ją to w zorien­to­wa­ną obiek­to­wo nota­cje UML nie zmie­nia­jąc podej­ścia struk­tu­ral­ne­go, w efek­cie stu­dent cytu­je mi taki tekst i pyta mnie czym się róż­ni dia­gram klas od ERD.

      Wszystko to co napi­sa­łeś dalej jest opi­sem rela­cyj­ne­go mode­lu danych i z obiek­to­wym nie­ste­ty nie ma nic wspól­ne­go. Absolutnie nie oce­niam orga­ni­za­cji w któ­rej pra­cu­jesz (prak­ty­ka budo­wa­nia rela­cyj­ne­go mode­lu dla fir­my jest dobra, rzecz w tym, że model rela­cyj­ny jest strat­ny stąd moda na obiek­to­wość”, któ­ra nie ma tej wady), ale w para­dyg­ma­cie obiek­to­wym nie ma poję­cia rela­cja, to cecha mode­lu rela­cyj­ne­go danych. Model obiek­to­wy i UML ope­ru­je poję­ciem zwią­zek” (aso­cja­cja) a to zupeł­nie co inne­go. jest jed­nak istot­na róż­ni­ca pomię­dzy «rela­cja” a aso­cja­cja” i tu bicie pia­ny o seman­ty­kę ma głę­bo­ki sens). Zdanie ?biz­ne­so­we struk­tu­ry danych i zależ­no­ści pomię­dzy nimi? o niczym jesz­cze nie mówi, ale umiesz­cze­nie go w tre­ści opi­su nota­cji UML o obiek­to­wej ana­li­zie czy­ni je z grun­tu fał­szy­wym, gdyż w para­dyg­ma­cie obiek­to­wym nie ist­nie­je poję­cie biz­ne­so­we struk­tu­ry danych”. To poję­cie rodem z ana­li­zy struk­tu­ral­nej i rela­cyj­ne­go mode­lu danych. W meto­dach obiek­to­wych nie ma mowy o danych (fizycz­na baza danych, jaka­kol­wiek, to imple­men­ta­cja utrwa­la­nia), a atry­bu­ty to ostat­ni etap ana­li­zy o pro­jek­to­wa­nia obiektowego. 

      Problem widzę w tym, że bar­dzo wie­lu ana­li­ty­ków i pro­gra­mi­stów pro­jek­tu­je i pisze opro­gra­mo­wa­nie meto­da­mi struk­tu­ral­ny­mi, czy­li ana­li­zu­je dane, mode­lu­je je, nor­ma­li­zu­je, i na koniec pisze funk­cje ope­ru­ją­ce na tych danych. To, że się ktoś np. prze­sta­wia z Pascala czy pro­ce­dur wbu­do­wa­nych bazy Oracle, na javę czy .Net, a dia­gra­my ERD zamie­nia na źle two­rzo­ne dia­gra­my UML (np. widu­je klu­cze obce na dia­gra­mach klas, poraż­ka!) nie czy­ni z tego pro­gra­mi­sty obiek­tow­ca”… Projekty w rodza­ju ana­li­za i model danych, funk­cje napi­sa­ne w javie, kod pogru­po­wa­ny na jakieś tam pod­pro­gra­my-kla­sy i mon­stru­al­ne mapo­wa­nie ORM (cza­sa­mi jak widzę u klien­tów pli­ki kon­fi­gu­ra­cyj­ne dla Hibernate to mi ręce opa­da­ją) to poraż­ka obiektowa…

      A ostat­nie Twoje zda­nie to teza, czy też się z tym nie zga­dzasz? Bo ogól­nie to jest tak: w meto­dach obiek­to­wych model dzie­dzi­ny to kolek­cja współ­pra­cu­ją­cych obiek­tów (a nie powią­za­nych rela­cyj­ne danych). Skoro obiek­ty współ­pra­cu­ją, to na wstęp­nym eta­pie ana­li­zy i pro­jek­to­wa­nia mają ope­ra­cje i nie mają atry­bu­tów. To wła­śnie odróż­nia meto­dy struk­tu­ral­ne od obiektowych.

      Zapewniam Cie, że kar­ty CRC w ogó­le nie maja na sobie” żad­nych atry­bu­tów, a są powszech­nie sto­so­wa­ne jako meto­da nauki myśle­nia obiek­to­we­go i ana­li­zy obiek­to­wej – to nie jest przy­pa­dek… Zacytuje jed­ną, z ksią­żek chy­ba nawet Jourdona: jeże­li ktoś nie potra­fi zapro­jek­to­wać sys­te­mu tyl­ko jako zesta­wu komu­ni­ku­ją­cych się obiek­tów bez zaj­mo­wa­nia się zbęd­ny­mi na rym eta­pie ich atry­bu­ta­mi, ten nigdy nie bez­ie obiek­to­wym pro­gra­mi­stą. Cóż, samo zasto­so­wa­nie obiek­to­wych narzę­dzi nie uczy­ni ani pro­jek­tu ani pro­gra­mu obiek­to­wym”.

  3. Pawel Zubkiewicz 20 lutego 2013 at 12:11

    Wszystko to co napi­sa­łeś dalej jest opi­sem rela­cyj­ne­go mode­lu danych i z obiek­to­wym nie­ste­ty nie ma nic wspólnego.”

    Zapewniam Cie, ze nikt nie pro­bo­wal stwo­rzyc rela­cyj­ne­go mode­lu danych dla kil­ku tysie­cy apli­ka­cji (sys­te­mow). Przynajmniej nie w tej orga­ni­za­cji. Model dome­ny jest abs­trak­cją biz­ne­so­wą – apli­ka­cja pra­cu­je w tej dome­nie i ma swo­je mode­le logicz­ny i fizycz­ny. Celem jest aby bylo tra­ce­abi­li­ty mie­dzy tymi mode­la­mi. Czyli sko­ro juz o seman­ty­ce dys­ku­tu­je­my, sta­wiam teze, że mówie­nie model dome­ny apli­ka­cji xy” jest logicz­nie nie­po­praw­ny, ponie­waż to nie apli­ka­cja ma model dzie­dzy a w nim TYLKO pracuje.

    Widze, że masz spo­ry pro­blem ze sło­wem «dane», jesli rozu­miesz je jako cia­gi danych z bazy to zaczy­nam rozu­mieć skąd nie­po­ro­zu­mie­nie. Zauwazyłem już w jed­nym z Twoim poprzed­nich wpi­sów na temat Architektury Korporacyjnej i TOGAFa, że strasz­nie Ci nie leży kon­cept danych – piję tutaj to Data archi­tec­tu­re” z ADM. Nie chcia­łem tego juz tam komen­to­wać, dal­te­go tutaj o tym wspo­mnę. Jak ktoś pisze data” to nie zawsze mysli data­ba­se”.

    Proponuje prze­czy­tać książ­ke Architektura Korporacyjna jako stra­te­gia (daje kon­tekst), a potem manu­ala do TOGAF 9 (daje wie­dze) – wie­le to roz­ja­snia w kwe­stii pro­jek­to­wa­nia apli­ka­cji w zło­żo­nych struk­tu­rach biznesu.

    • Jarek Żeliński 20 lutego 2013 at 15:25

      Odniosłem się tyl­ko do tego co napi­sa­łeś, nie cho­dzi o licz­bę apli­ka­cji a o to, że rela­cje” to nie ana­li­za obiek­to­wa”. Specyfikacja obiek­tów biz­ne­so­wych” rozu­mia­nych jako obiek­ty UML to kolek­cja, mogą być co naj­wy­żej poka­za­ne związ­ki uży­cia lub logicz­ne aso­cja­cje poka­zu­ją­ce np. to, że umo­wa i klient mogą zostać powią­za­ne na bazie PESEL klien­ta. Jednak mię­dzy obiek­ta­mi nie ma rela­cji (zakła­da­jąc, że sło­wo rela­cja ma swo­je znacz­nie na dia­gra­mie ERD). Być może nad­mier­ny skrót myślo­wy jaki zasto­so­wa­łeś dopro­wa­dził do nieporozumienia. 

      Pojęcie mode­lu dome­ny opi­sa­łem, w meto­dach obiek­to­wych apli­ka­cja imple­men­tu­je cały model danej dome­ny lub jego część, kil­ka apli­ka­cji (kom­po­nen­tów) może imple­men­to­wać róż­ne obsza­ry (czę­ści mode­lu) dome­ny. Tak więc mamy obiek­to­wy model dziedziny/domeny a apli­ka­cja imple­men­tu­je całość lub wybra­ną część tego mode­lu. Nie potra­fię zin­ter­pre­to­wać poję­cia apli­ka­cja pra­cu­je w mode­lu dziedziny”. 

      Nie mam pro­ble­mu z poję­ciem dane, w tym kon­tek­ście uży­wam roz­łącz­nie sło­wa dane jako ele­men­ty mode­lu danych” rodem z ERD, i atry­bu­ty obiek­tów rodem z OOAD. To, że jakaś kon­kret­ne cyfer­ki tu to DANE a tam to ATRYBUTY nie upraw­nia do uogól­nia­nia poję­cia dane. Słowo dane (data) ma w j.poslkim wie­le zna­czeń zależ­nych od kon­tek­stu, dla­te­go war­to te zna­cze­nia roz­gra­ni­czać lub w takich tek­stach uży­wać tyl­ko w jed­nym zna­cze­niu by unik­nąć nie­po­ro­zu­mień. Oprogramowanie obiek­to­we nie prze­twa­rza danych a zarzą­dza współ­pra­cą obiek­tów. Owszem z per­spek­ty­wy użyt­kow­ni­ka dosta­je on jakieś dane ale to inna per­spek­ty­wa. Znam obie suge­ro­wa­ne książ­ki, i nie ja jeden uwa­żam, że TOGAF zawie­ra pew­ne nie­ści­sło­ści ter­mi­no­lo­gicz­ne. Dotyczy to zresz­tą całe­go podej­ścia The Open Group. Otarłem się o pro­jekt tłu­ma­cze­nia słow­ni­ka na język pol­ski pojęć TOGAF (ich glos­sa­riusz) i wiem od tych ludzi, że było z tym bar­dzo cięż­ko… pro­blem z tym jest tak­że w dość nie­spój­nej nota­cji ArchiMate bo wyko­rzy­stu­je ona poję­cia rodem z UML ale wła­śnie np. sym­bol data (obiekt danych) jest reali­za­cją obiek­tu biz­ne­so­we­go na pozio­mie pro­ce­sów … trosz­kę to do sie­bie nie gada tym bar­dziej, że auto­rzy sami piszą, że uszcze­gó­ło­wie­nie tej czę­ści nale­ży robić dia­gra­mem klas UML. 

      Początkowo entu­zja­stycz­nie pod­sze­dłem do TOGAF ale w mia­rę zagłę­bia­nia się nabie­ra­łem wra­że­nia, że kon­cep­cja jest moc­no nie­do­pra­co­wa­na. Osobiście uwa­żam, że Siatka Zachmanna jako struk­tu­ra opi­su orga­ni­za­cji w posta­ci kolek­cji mode­li spraw­dza się znacz­nie lepiej, jej rela­tyw­nie mała popu­lar­ność to chy­ba efekt dużych nakła­dów the Open Group na pro­mo­cje opa­ten­to­wa­ne­go TOGAF+ArchiMate (oba wyma­ga­ją opłat licen­cyj­nych)… poza tym Architektura Korporacyjna dosko­na­le sobie radzi na narzę­dziach OMG gdzie śla­do­wa­nie nie sta­no­wi żad­ne­go pro­ble­mu za to cały zestaw narzę­dzi i tech­nik OMG jest za dar­mo a pra­cu­ją nad nimi po poje­dyn­cze fir­my a całe ich rzesze.

  4. Jarek Żeliński 20 lutego 2013 at 15:32

    Uzupełniając: dale­ki jestem od ogól­nej oce­ny Architektury Korporacyjnej, mam jakieś swo­je prze­my­śle­nia i jak czy­tam róż­ne książ­ki nie ja jeden. Uważam, jed­nak mie­sza­nie lub nawet dopusz­cza­nie do nie­jed­no­znacz­no­ści pomię­dzy meto­da­mi struk­tu­ral­ny­mi a obiek­to­wy­mi jest bar­dzo szko­dli­we. Kolekcja obiek­tów” vs. dane upo­rząd­ko­wa­ne w mode­lu rela­cyj­nym prze­twa­rza­ne przez zestaw pro­ce­dur” to skraj­nie róż­ne sys­te­mu. Nie mają z sobą nic wspól­ne­go, więc współ­dzie­le­nie jakich­kol­wiek pojęć z tych dzie­dzin jest co naj­mniej ryzy­kow­ne. meto­dy obiek­to­we to imple­men­ta­cja mode­lu dome­ny a meto­dy struk­tu­ral­ne to prze­twa­rza­nie upo­rząd­ko­wa­nych danych opi­su­ją­cych daną dome­nę, a to nie jest to samo.

  5. Pawel Zubkiewicz 20 lutego 2013 at 16:53

    ?Odniosłem się tyl­ko do tego co napi­sa­łeś, nie cho­dzi o licz­bę apli­ka­cji a o to, że ?rela­cje? to nie ?ana­li­za obiek­to­wa?. Specyfikacja ?obiek­tów biz­ne­so­wych? rozu­mia­nych jako obiek­ty UML to kolek­cja, mogą być co naj­wy­żej poka­za­ne związ­ki uży­cia lub logicz­ne aso­cja­cje poka­zu­ją­ce np. to, że umo­wa i klient mogą zostać powią­za­ne na bazie PESEL klien­ta. Jednak mię­dzy obiek­ta­mi nie ma rela­cji (zakła­da­jąc, że sło­wo rela­cja ma swo­je znacz­nie na dia­gra­mie ERD). Być może nad­mier­ny skrót myślo­wy jaki zasto­so­wa­łeś dopro­wa­dził do nieporozumienia. ?

    Asocjacja z UML to tez jest rela­cja. Association is a rela­tion­ship betwe­en clas­si­fiers which is used to show that instan­ces of clas­si­fiers could be either lin­ked to each other or com­bi­ned logi­cal­ly or phy­si­cal­ly into some aggre­ga­tion. – http://​www​.uml​-dia​grams​.org/​a​s​s​o​c​i​a​t​i​o​n​.​h​tml Czyli fakt, że dwa obiek­ty pozo­sta­ja w rela­cji nie ozna­czy odra­zu, że nale­zy uży­ci dia­gra­mu ERD aby tą rela­cję przedstawić.

    ?Pojęcie mode­lu dome­ny opi­sa­łem, w meto­dach obiek­to­wych apli­ka­cja imple­men­tu­je cały model danej dome­ny lub jego część, kil­ka apli­ka­cji (kom­po­nen­tów) może imple­men­to­wać róż­ne obsza­ry (czę­ści mode­lu) dome­ny. Tak więc mamy obiek­to­wy model dziedziny/domeny a apli­ka­cja imple­men­tu­je całość lub wybra­ną część tego mode­lu. Nie potra­fię zin­ter­pre­to­wać poję­cia ?apli­ka­cja pra­cu­je w mode­lu dziedziny?. ?

    Tutaj sie aku­rat zga­dza­my, chcia­łem pod­kre­ślić fakt, że apli­ka­cja imple­men­tuj bądź reali­zu­ję część (lub całość) dziedziny/domeny. Czyli mamy np. Domenę Kredyty i w niej apli­ka­cje reali­zu­ją­cą kre­dy­ty samo­cho­do­we dla firm. Ta domena/dziedzina narzu­ca na apli­ka­cje pew­ne ogra­ni­cze­nia (nie chce tutaj użyć sło­wa wyma­ga­nia bo ono jest nace­cho­wa­ne inny­mi zna­cze­nia­mi). Chodzi o to że cykl życia dome­ny biz­ne­so­wej jest inny niż cykl życia apli­ka­cji. Np. Wchodzi w życie pew­na regu­la­cja ? czy­li to ?biznes/życie/rynek? zmie­nia dome­nę. Aplikacja musi zostać zmie­nio­na lub sta­ję się nie­spój­na z dome­ną i tra­ci war­tość biznesową.

    ?Nie mam pro­ble­mu z poję­ciem dane, w tym kon­tek­ście uży­wam roz­łącz­nie sło­wa dane jako ?ele­men­ty mode­lu danych? rodem z ERD, i atry­bu­ty obiek­tów rodem z OOAD. To, że jakaś kon­kret­ne cyfer­ki tu to DANE a tam to ATRYBUTY nie upraw­nia do uogól­nia­nia poję­cia dane. Słowo dane (data) ma w j.poslkim wie­le zna­czeń zależ­nych od kon­tek­stu, dla­te­go war­to te zna­cze­nia roz­gra­ni­czać lub w takich tek­stach uży­wać tyl­ko w jed­nym zna­cze­niu by unik­nąć nie­po­ro­zu­mień. Oprogramowanie obiek­to­we nie prze­twa­rza danych a zarzą­dza współ­pra­cą obiek­tów. Owszem z per­spek­ty­wy użyt­kow­ni­ka dosta­je on jakieś dane ale to inna perspektywa.?

    Będę nie­ugię­ty. Angielskie sło­wo data ma wie­le zna­czeń. Mamy na przy­kład Information Data Model i jego spe­ca­li­za­cję w posta­ci Canonical Data Model. Ani jed­no ani dru­gie nie musi być ERD.

    ?Znam obie suge­ro­wa­ne książ­ki, i nie ja jeden uwa­żam, że TOGAF zawie­ra pew­ne nie­ści­sło­ści ter­mi­no­lo­gicz­ne. Dotyczy to zresz­tą całe­go podej­ścia The Open Group. Otarłem się o pro­jekt tłu­ma­cze­nia słow­ni­ka na język pol­ski pojęć TOGAF (ich glos­sa­riusz) i wiem od tych ludzi, że było z tym bar­dzo cięż­ko? pro­blem z tym jest tak­że w dość nie­spój­nej nota­cji ArchiMate bo wyko­rzy­stu­je ona poję­cia rodem z UML ale wła­śnie np. sym­bol data (obiekt danych) jest reali­za­cją obiek­tu biz­ne­so­we­go na pozio­mie pro­ce­sów ? trosz­kę to do sie­bie nie gada tym bar­dziej, że auto­rzy sami piszą, że uszcze­gó­ło­wie­nie tej czę­ści nale­ży robić dia­gra­mem klas UML. ?

    Akurat byłem w gru­pie osób pra­cu­ją­cych nad tłu­ma­cze­niem tego glo­sa­riu­sza. Moim zda­niem więk­szość pro­ble­mów była natu­ry lek­sy­kal­nej (jak dobrze oddać sens angiel­skiej defi­ni­cji). Faktycznie dwie lub trzy ory­gi­nal­ne defi­ni­cje były nie naj­wyż­szej jako­ści, jed­nak na pew­no nie mogę się zgo­dzić, że tak­so­no­mia któ­rą ofe­ru­je TOGAF jest nie­spój­na. W ArchiMate się tak moc­no nie wgry­za­łem, więc się nie wypowiem.

    ?Początkowo entu­zja­stycz­nie pod­sze­dłem do TOGAF ale w mia­rę zagłę­bia­nia się nabie­ra­łem wra­że­nia, że kon­cep­cja jest moc­no nie­do­pra­co­wa­na. Osobiście uwa­żam, że Siatka Zachmanna jako struk­tu­ra opi­su orga­ni­za­cji w posta­ci kolek­cji mode­li spraw­dza się znacz­nie lepiej, jej rela­tyw­nie mała popu­lar­ność to chy­ba efekt dużych nakła­dów the Open Group na pro­mo­cje opa­ten­to­wa­ne­go TOGAF+ArchiMate (oba wyma­ga­ją opłat licen­cyj­nych)? poza tym Architektura Korporacyjna dosko­na­le sobie radzi na narzę­dziach OMG gdzie śla­do­wa­nie nie sta­no­wi żad­ne­go pro­ble­mu za to cały zestaw narzę­dzi i tech­nik OMG jest za dar­mo a pra­cu­ją nad nimi po poje­dyn­cze fir­my a całe ich rzesze.?

    Oczywiści, AK jest pew­ną kon­cep­cją i jako taka jest ona nie­za­leż­na od narze­dzi któ­ry­mi się posłu­zy­my (z jed­nej bądź dru­giej staj­ni). Osobiście uwa­żam ze TOGAF dostar­cza dużo wię­cej narzę­dzi i tak potrzeb­nej ? choć wnio­sku­jąc z tej dys­ku­ji ? tak­so­no­mii niż siat­ka Zachmanna.

    Swoją dro­gą OMG też per­fek­cjo­ni­stą nie jest. Specyfikacja choć­by BPMNa jest… hmmm bar­dzo ela­stycz­na, co pro­wa­dzi do tego, że pra­wie każ­dy dia­gram w tym języ­ku da się obro­nić jako popraw­ny. Z dru­giej stro­ny stan­dard BMM, o któ­rym sam pisa­łeś, został wyda­ny bez nota­cji, cze­go zupeł­nie nie jestem w sta­nie zro­zu­mić. Swoją dro­gą jeden i dru­gi znam, uży­wam i polecam 🙂

    Co do ostat­nie­go zda­nia do nie do koń­ca je rozu­miem, więc napi­sze dla potom­nych. TOG nie jest poje­dyn­cza fir­mą a kon­sor­cjum. Podobnie jak w przy­pad­ku OMG w roz­wi­ja­niu stan­dar­dów uczest­ni­czy wie­le firm. To że ich pro­duk­ty są płat­ne, mnie też wkurza.

    PS. Dzieki za dobra dys­ku­sje, podo­ba mi sie.

    • Jarek Żeliński 20 lutego 2013 at 19:29

      Association is a rela­tion­ship betwe­en clas­si­fiers which is used to show that instan­ces of clas­si­fiers could be either lin­ked to each other” pod warun­kiem, że one są lin­ked”, a obiek­tów się raczej nie tak wią­że. Owszem, nie ma zaka­zu trwa­łe­go łącze­nia obiek­tów bo pozwa­la na to chy­ba każ­dy obiek­to­wy język, takie połą­cze­nie jed­nak ozna­cza, że ID jed­ne­go obiek­tu jest war­to­ścią atry­bu­tu dru­gie­go, ale to wła­śnie trwa­łe rela­cyj­ne powią­za­nie”. Nie negu­je tego. Ja sta­ram się poka­zać, że obiek­to­wy para­dyg­mat to co inne­go niż moż­li­wo­ści (fak­tem jest, że duże) UML czy obiek­to­wych języ­ków pro­gra­mo­wa­nia (moż­na napi­sać duży pro­gram będą­cy jed­na wiel­ka kla­są). Można w javie napi­sać pro­gram nie mają­cy z meto­da­mi obiek­to­wy­mi nic wspól­ne­go mimo, że to jego UMLowa doku­men­ta­cja może być popraw­nym zesta­wem diagramów. 

      Angielskie sło­wo data ma wie­le zna­czeń. Mamy na przy­kład Information Data Model i jego spe­ca­li­za­cję w posta­ci Canonical Data Model.” Owszem ale jest róż­ni­ca pomię­dzy Canonical Data Model” a Object orien­ted doma­in model”. 

      Takie dys­ku­sje kształ­cą więc i mi nie pozo­sta­je mi nic inne­go jak tak­że podzię­ko­wać. Nigdy nie ukry­wa­łem, jest wręcz ele­men­tem mojej stra­te­gii 🙂 to, że jestem pury­stą for­mal­nym. Jednak nie dla­te­go, by pacy­fi­ko­wać pro­jek­ty orto­dok­sją. To efekt dwóch rze­czy: teo­ria pozna­nia jako restryk­cyj­ne pod­cho­dze­nie do seman­ty­ki, pozwa­la unik­nąć nie­jed­no­znacz­no­ści. Druga rzecz, to zde­fi­nio­wa­nie ide­ału pozwa­la oce­nić (zmie­rzyć) odstęp­stwo kon­kret­ne­go pro­jek­tu od nie­go. To pozwa­la oce­nić ryzy­ko takie­go pro­jek­tu. Fizyka ma np. nie­ist­nie­ją­ce w natu­rze cia­ło dosko­na­le czar­ne, po co? By móc oce­nić błąd rze­czy­wi­stych obli­czeń. Zdaję sobie spra­wę, że to filo­zo­fia, ale taki mam cel :), nie tyl­ko ana­li­zo­wać i mode­lo­wać ale w 100% rozumieć :). 

      A przy oka­zji, nie tyl­ko BPMN jest ela­stycz­ny, każ­da nota­cja taka jest, to dla­te­go, prak­tycz­nie każ­dy model, w BPMN tak­że, podob­nie jak w UML, dla swej jed­no­znacz­no­ści, wyma­ga okre­śle­nia (opi­sa­nia) pragmatyki.

  6. Jarek Żeliński 3 marca 2013 at 10:36

    Polecam pre­zen­ta­cję, jej pierw­sza część dobrze odda­ne sens wydzie­la­nia dzie­dzi­ny, zawie­ra bar­dzo rze­czo­wy opis DDD:
    http://​www​.sli​de​sha​re​.net/​K​o​n​r​a​d​R​u​s​s​a​/​d​d​d​p​r​e​z​e​n​t​a​cja

  7. Pytacz 30 października 2021 at 20:43

    Witam. Napisał Pan „… W wol­nym tłu­ma­cze­niu: obiek­to­wy para­dyg­mat pro­gra­mo­wa­nia to repre­zen­to­wa­nie pojęć w posta­ci ?obiek­tów?, mają­cych atry­bu­ty (dane opi­su­ją­ce obiekt) oraz powią­za­ne pro­ce­du­ry, nazy­wa­ne metodami”

    Troszkę się pogu­bi­łem już powiem szcze­rze. Wydawało mi się czy­ta­jąc inne Pana wpi­sy, że atrybuty/wartości atry­bu­tów to nie dane,a z tego zda­nia wyni­ka że jed­nak dane. Proszę o rozjaśnienie.

    • Jarosław Żeliński 30 października 2021 at 21:03

      Atrybut obiek­tu gene­ral­nie to jego cecha. Np. kolor karo­se­rii samo­cho­du jest (może być) jego atry­bu­tem, ale bagaż­nik i jego zawar­tość też jest atry­bu­tem samo­cho­du. Mamy «dane prze­cho­wy­wa­ne» i «dane opi­su­ją­ce obiekt» i to nie jest to samo. Załóżmy, że mam w kie­sze­ni para­gon z kawiar­ni, ale też jestem czło­wie­kiem mają­cym pew­ne cechy, np. datę uro­dze­nia. Data uro­dze­nia to atry­but opi­su­ją­cy mnie. Treść para­go­nu, to tak­że atry­but, jego war­tość to doku­ment zawie­ra­ją­cy dane o tym, że kupi­łem kawę, jaką i kiedy. 

      Ogromnym pro­ble­mem dla wie­lu ludzi jest odej­ście od postrze­ga­nia danych rozu­mia­nych jako tabe­le baz danych. Niestety nadal na wie­lu uczel­niach uczy się stu­den­tów, że dane prze­cho­wu­je się w bazie danych, naj­le­piej rela­cyj­nej, że obiekt to połą­czo­ne dane i funk­cje je prze­twa­rza­ją­ce”. Taki model to pre­hi­sto­ria. Mamy cza­sy BigData, repo­zy­to­ria w chmu­rze bez SQL, i wszech­obec­ne nie­struk­tu­ral­ne dane. 

      Obiekt ma atry­bu­ty, mają one róż­ne war­to­ści, ale to czym są war­to­ści tych atry­bu­tów zale­ży od roli obiek­tu. Jeżeli jest to obiekt repo­zy­to­rium, to jego atry­but (jeden!) będzie np. prze­cho­wy­wał skom­pli­ko­wa­ny zestaw danych w posta­ci cią­gu zna­ków XML. Jeżeli będzie to obiekt repre­zen­tu­ją­cy kal­ku­la­tor upu­stów, war­to­ści atry­bu­tów mogą prze­cho­wy­wać np. aktu­al­ny sta­tus (usłu­ga dostępna/niedostępna), ale też obiekt taki może nie mieć atry­bu­tów w ogó­le, tyl­ko operacje.

  8. Pytacz 31 października 2021 at 20:26

    … Mamy ?dane prze­cho­wy­wa­ne? i ?dane opi­su­ją­ce obiekt?” rozu­miem z tym, że cięż­ko mi sobie wyobra­zić w świe­cie wir­tu­al­nym daną opi­su­ją­cą obiekt, któ­ra nie jest prze­cho­wy­wa­na w bazie czy to rela­cyj­nej, doku­men­to­wej czy każ­dej innej. 

    Więc dla mnie to tak: atry­but obiek­tu to jego cecha (a żeby być ści­słym nazwa tej cechy). A war­tość tej cechy to dana/dane zapi­sa­ne w dowol­nej posta­ci np. Xml.

    • Jarosław Żeliński 31 października 2021 at 20:53

      Fizyczne prze­cho­wy­wa­nie (utrwa­la­nie) to tyl­ko imple­men­ta­cja zacho­wy­wa­nia tre­ści na sta­łe, łącze­nie tego w jed­no na mode­lu jest szko­dli­we. To jak fak­tu­ry: treść fak­tur prze­cho­wu­je­my, ale sal­da tak­że, niby dane o fak­tu­rach a jed­nak nie to samo … Np. atry­bu­tem fak­tu­ry jest war­tość brut­to, sta­tus fak­tu­ry (np. prze­ter­mi­no­wa­na) jed­nak nie jest jej atry­bu­tem, ale jest jej cechą… Tak więc treść fak­tu­ry to np. XML (np. w pli­ku JPK) ale to czy jest opła­co­na, już nie jest w tym XML.

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.