Visual Paradigm 15.0 Released

Dzisiejszej nocy opu­bli­ko­wa­no wer­sję 15 pakie­tu CASE Visua-Paradigm. Producent tego opro­gra­mo­wa­nia kon­se­kwent­nie pnie się na szczyt roz­wią­zań CASE w swo­jej kla­sie, a jako obser­wa­tor i użyt­kow­nik powiem tak: stra­te­gia jest pro­sta czy­li apli­ka­cja dla ana­li­ty­ka, pro­jek­tan­ta i archi­tek­ta ma udo­stęp­niać naj­wyż­szej kla­sy narzę­dzia do pra­cy ze stan­dar­do­wy­mi nota­cja­mi i zgod­nie z ich spe­cy­fi­ka­cja­mi, wspie­rać poję­cio­we i logicz­ne śla­do­wa­nie pomię­dzy mode­la­mi, w niczym nie ogra­ni­czać ana­li­ty­ka (nie narzu­cać żad­nej meto­dy­ki postę­po­wa­nia), dać narzę­dzia do pra­cy na eta­pie nie­for­mal­nym, wspie­rać cały pro­ces MDA jaki zwin­ne meto­dy pra­cy, i co naj­waż­niej­sze: dać narzę­dzie do komu­ni­ka­cji pomię­dzy uczest­ni­ka­mi projektu.

I taki jest Visual od lat, kolej­ne 15. wcie­le­nie, to jesz­cze wię­cej inte­gra­cji i jesz­cze wię­cej komunikacji:

Feb 27, 2018 – Visual Paradigm International Limited anno­un­ced today the rele­ase of Visual Paradigm 15.0.

Visual Paradigm 15.0 intro­du­ces a num­ber of new featu­res, which includes:

  • Wireflow Diagram
  • Animating paths in Wireflow Diagram
  • STEPS – Efficient design and ana­ly­sis with pre­scri­bed wizards
  • Visual API desi­gner for Swagger-based RESTful API
  • Swagger-based RESTful API generation
  • Visual API desi­gner for API-Blueprint for­mat­ted RESTful API
  • API-Blueprint for­mat­ted RESTful API generation
  • [VP Online] New dia­gram: ER Diagram
  • [VP Online] New dia­gram: Organization Chart
  • [VP Online] New dia­gram: Mind Map
  • [VP Online] New dia­gram: DFD
  • [VP Online] New dia­gram: Venn Diagram
  • [VP Online] New dia­gram: Floor Plan
  • [VP Online] Google Drive integration
  • [VP Online] Real-time syn­chro­ni­za­tion of diagrams
  • [VP Online] Multilingual support
  • [VP Online] Visio dra­wing import
  • [VP Online] Multi-pages support

Enhancements to Visual Paradigm 15.0 includes:

  • Upgraded Hibernate ver­sion to 5.1
  • Improved sta­bi­li­ty in High DPI environments
  • Refined data for­war­ding mecha­nism for TOGAF ADM
  • Supported hiding inter­fa­ce cap­tion in ArchiMate diagram
  • Supported impor­ting sty­les for gene­ra­te deliverables
  • Supported apply­ing Shape Legend on connectors
  • Supported adding one sha­pe to mul­ti­ple layers
  • Supported sen­ding sha­pes from Business Concept Diagram to backlog
  • Supported display­ing para­me­ter of entry/exit/do acti­vi­ty on State Machine Diagram
  • Supported ente­ring seve­ral deli­ve­ra­ble pro­per­ties as variables
  • Introduced new user per­mis­sion option to con­trol who can uplo­ad Just-in-Time Work Items to repository
  • Improved Traditional Chinese support

Source: Visual Paradigm 15.0 Released – ChangeLog – Discuss the Visual Paradigm

Biznesowy model danych – nie chcemy

Nadal obser­wu­ję to, że model rela­cyj­ny i two­rze­nie mode­li danych na eta­pie ana­li­zy wyma­gań” trzy­ma­ją się twar­do mimo tego, że nie wie­le wno­szą do pro­jek­tu a narzu­ca­ją (suge­ru­ją) kiep­ską archi­tek­tu­rę apli­ka­cji z jed­ną rela­cyj­na bazą danych. Co cie­ka­we zaczy­na­nie od bazy danych jest wręcz zaprze­cze­niem zwin­no­ści (koniecz­ność ukoń­cze­nia pro­jek­tu doce­lo­wej bazy danych przed roz­po­czę­ciem kodo­wa­nia czy­li kla­sy­ka water­fall, w efek­cie beto­no­wa­nie sta­nu z dnia roz­po­czę­cia) mimo, że autor­ki arty­ku­łu piszą o sobie że są agile…

Popatrzmy na to co pro­po­nu­ją w tym 2017 roku.:

If the­re are spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships, the­se can be inc­lu­ded in the bounds for con­text. For exam­ple, the PO for SeiSounds might want to spe­ci­fy that each acco­unt can only be asso­cia­ted with a maxi­mum of five users or liste­ners to avo­id friends buy­ing one paid sub­scrip­tion and sha­ring with eve­ry­one else. See the exam­ple below:

[…] CONCLUSION Business Data Diagrams are one of tho­se MUST HAVE models for any pro­duct that is dealing with data. The exer­ci­se of cre­ating the model itself cre­ates a power­ful, sha­red under­stan­ding of the under­ly­ing data con­structs as users under­stand it. Instrumental in hel­ping to iden­ti­fy addi­tio­nal, more deta­iled models that might be needed, the BDD can also help you get to a com­ple­te set of user sto­ries aro­und users inte­rac­ting with the data fol­lo­wing the cre­ate, use, edit, dele­te, move and copy actions. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram

Powyższy model:

  1. dekla­ru­je kon­kret­ną zna­ną na teraz”, war­tość limi­tu licz­by użyt­kow­ni­ków Konta,
  2. pomię­dzy auto­rem, utwo­rem i sta­cją jest nic nie­mó­wią­ca (każ­de z każ­dym bez żad­nych ogra­ni­czeń) zależność,
  3. pozo­sta­łe ele­men­ty nie wno­szą war­to­ści doda­nej (utwór jest cechą arty­sty czy może arty­sta jest cechą utworu…).

Zaryzykuję tezę, że powyż­sze w zasa­dzie nie poma­ga deve­lo­pe­ro­wi w niczym. Czy wno­si coś do pro­jek­tu? W moich oczach sta­no­wi pro­ste zapi­sa­nie” tego co zezna­li inda­go­wa­ni zama­wia­ją­cy (arty­kuł zawie­ra opis histo­ry­jek użyt­kow­ni­ka i ich koja­rze­nia z tym mode­lem danych). Stwierdzenie zaś, że …spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships…, (np. mak­si­mum pię­cio­ro użyt­kow­ni­ków może jed­no­cze­śnie słu­chać), to nie regu­ła biz­ne­so­wa a kry­te­rium decy­zyj­ne (wię­cej o regu­łach biz­ne­so­wych w lite­ra­tu­rze). 

Trzeba sobie tu jasno powie­dzieć, że induk­cyj­ne podej­ście do ana­li­zy (zbie­ra­nie i zapi­sy­wa­nie obser­wa­cji w celu iden­ty­fi­ka­cji tren­du lub powtó­rzeń) przy­po­mi­na pró­by zro­zu­mie­nia gry w sza­chy meto­dą wie­lo­krot­nej obser­wa­cji roz­gry­wek. Im wier­niej­szy opis gry ma powstać, tym wię­cej obser­wa­cji nale­ży udo­ku­men­to­wać, co nie zmie­nia fak­tu, że taki doku­ment nie mówi abso­lut­nie nic o przy­szłych roz­gryw­kach. Alternatywą jest deduk­cyj­ne podej­ście, pole­ga­ją­ce na zro­zu­mie­niu i opra­co­wa­niu, moż­li­wie naj­mniej­szym nakła­dem pra­cy, reguł gry w sza­chy, cze­go udo­ku­men­to­wa­nie wyma­ga naj­wy­żej dwóch stron papie­ru A4, taki doku­ment opi­su­je tak­że w 100% wszyst­kie przy­szłe roz­gryw­ki… 

Jak inaczej podejść do tego? 

Na począ­tek nale­ży zro­zu­mieć dzie­dzi­nę pro­ble­mu i opi­sać ją słownikiem:

Powyższy model poję­cio­wy (dia­gram nota­cji SBVR, dia­gram klas nota­cji UML) to słow­nik pojęć a nie model danych. To dia­gram obra­zu­ją­cy poję­cia i kon­tek­sto­we związ­ki mię­dzy nimi (tym kon­tek­stem są fak­ty z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu). Nie są to ani dane ani regu­ły biz­ne­so­we. Są to nazwy, a nie byty sys­te­mo­we”. Poza takim dia­gra­mem, nale­ży tak­że stwo­rzyć słow­nik pojęć biz­ne­so­wych w posta­ci tabe­li zawie­ra­ją­cej pre­cy­zyj­ne, dzie­dzi­no­we defi­ni­cje tych pojęć. Dla wygo­dy i pre­zen­ta­cji ich tre­ści nanio­słem dwie regu­ły na dia­gram, są sko­ja­rzo­ne z Kontem gdyż jego doty­czą. Co do zasa­dy regu­ły biz­ne­so­we są koja­rzo­ne z ele­men­ta­mi na innych dia­gra­mach poprzez sło­wa zdefiniowane.

Cała ana­li­za powin­na się zaczy­nać od udo­ku­men­to­wa­nia mode­li pro­ce­sów. Tu pomi­ną­łem te mode­le bo ich opi­sów jest na moim blo­gu wie­le, a chcę się sku­pić na dzie­dzi­nie dla jakiej powsta­je apli­ka­cja. Analiza i zro­zu­mie­nie pro­ble­mu pro­wa­dzi do stwo­rze­nia mode­lu dzie­dzi­ny apli­ka­cji. Taki model powsta­je na pod­sta­wie tre­ści doku­men­tów wewnętrz­nych i zewnętrz­nych (tu np. Ustawa o pra­wach autor­skich), poma­ga­ją co naj­wy­żej bie­żą­ce wyja­śnie­nia. Do jego powsta­nia nie są potrzeb­ne żad­ne warsz­ta­ty ani cało­dzien­ne spotkania.

Celem mode­lo­wa­nia dzie­dzi­ny sys­te­mu (tu apli­ka­cji) jest udo­ku­men­to­wa­nie wewnętrz­nej logi­ki apli­ka­cji, czy­li mecha­ni­zmu jej dzia­ła­nia. Absolutnie nie jest to model danych. Powyższy model nie jest mode­lem ukoń­czo­nym”, wyma­ga na pew­no dopra­co­wa­nia, jed­nak moim celem jest jedy­nie poka­za­nie idei jego two­rze­nia. Nazwy klas, atry­bu­tów, ope­ra­cji zawie­ra­ją poję­cia zawar­te w słow­ni­ku pojęć. Zapewnia to jed­no­znacz­ność i zro­zu­mie­nie. Dodam, że dopie­ro ten model poka­zu­je bar­dzo waż­ną rzecz, to że autor jest cechą utwo­ru a nie odwrotnie. 

Tak więc:

  1. uru­cho­mie­nie i korzy­sta­nie z emi­sji kon­tro­lo­wa­ne jest przez Zarządzanie emi­sją, tu spraw­dza­ne są i egze­kwo­wa­ne, regu­ły biznesowe, 
  2. kom­po­nent Zarządzanie emi­sją korzy­sta tak­że z infor­ma­cji zawar­tych w Koncie użyt­kow­ni­ka i Playlisty, deta­le utwo­rów pobie­ra z Repozytorium utworów. 

Tu waż­ne jest pod­kre­śle­nie, że regu­ła doty­czą­ca ogra­ni­cze­nia licz­by jed­no­cze­śnie słu­cha­ją­cych, jest oddzie­lo­na od Kont użyt­kow­ni­ków i (nie poka­za­nych tu) Subskrypcji. Dzięki temu para­metr ten jest łatwo mody­fi­ko­wal­ny z pozio­mu apli­ka­cji (para­me­try­zo­wa­ne kry­te­rium decy­zyj­ne) bez potrze­by jakich­kol­wiek inge­ren­cji w model danych”. Umieszczanie jakich­kol­wiek reguł w bazie danych (czy­li na pozio­mie imple­men­ta­cji utrwa­la­nia) jest nie­ste­ty ich beto­no­wa­niem”.

Zmienność, nie tyl­ko ryn­ku ale i samych reguł w orga­ni­za­cjach, to sta­ły ele­ment śro­do­wi­ska apli­ka­cji. Dlatego dobrą prak­ty­ką jest, by utrwa­la­nie danych (wszel­kie bazy danych, pli­ki itp..) nie słu­ży­ło do nicze­go poza utrwa­la­niem. Logika biz­ne­so­wa powin­na być w w 100% w apli­ka­cji a nie podzie­lo­na pomię­dzy apli­ka­cję i dane (żad­na baza danych nie jest w sta­nie prze­cho­wy­wać innych reguł biz­ne­so­wych niż bez­po­śred­nie związ­ki ilo­ścio­we). Na eta­pie imple­men­ta­cji, sto­su­je­my zasa­dę her­me­ty­za­cji, czy­li nie współ­dzie­li­my, na żad­nym pozio­mie, danych pomię­dzy repo­zy­to­ria­mi i nie usu­wa­my redun­dan­cji. Dzięki temu nie odci­na­my sobie dro­gi do zmian sys­te­mu takich jak np. zastą­pie­nie kla­sy Dane oso­bo­we inter­fej­sem do zewnętrz­ne­go sys­te­mu, dys­po­nu­ją­ce­go taki­mi infor­ma­cja­mi (kla­sa ta zosta­nie zmie­nio­na, sta­nie się wte­dy mostem do API zewnętrz­ne­go sys­te­mu co nie pocią­gnie za sobą jakich­kol­wiek zmian, bo inter­fejs tej kla­sy i jej nazwa pozo­sta­ną nie­zmie­nio­ne, patrz zasa­da open-clo­se prin­ci­pia oraz polimorfizm).

Poniżej klu­czo­we związ­ki w UML i ilu­stra­cja związ­ku pomię­dzy mode­lem poję­cio­wym a mode­lem struk­tu­ry (archi­tek­tu­ry, to model dziedziny):

Na zakoń­cze­nie war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest mode­lem danych” (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma dzi­siaj racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie aplikacji.

Warto tak­że mieć na uwa­dze to, że opro­gra­mo­wa­nie może być two­rzo­ne z uży­ciem zewnętrz­nych kom­po­nen­tów dostęp­nych na ryn­ku. Założenie więc na samym począt­ku pro­jek­tu, że dane są w jed­no­li­ty spo­sób prze­cho­wy­wa­ne i współ­dzie­lo­ne w jed­nej cen­tral­nej i współ­dzie­lo­nej bazie danych, wraz z logi­ką ich uży­cia, jest tu nie tyl­ko nie­uza­sad­nio­ne ale wręcz szkodliwe. 

I na koniec grat­ka: dokład­nie ta powsta­ła, i nadal tak wyglą­da, znacz­na więk­szość obec­nych na ryn­ku sys­te­mów ERP, CRM itp.… 

oraz cytat z literatury

z 1994 roku:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

Związki w UML czyli abstrakcja vs rzeczywistość

Wstęp

Tym razem o kil­ku powszech­nie popeł­nia­nych błę­dach w korzy­sta­niu z UML. Chodzi o poję­cia abs­trak­cji, meta­mo­de­li i zależ­no­ści oraz o związ­ki mię­dzy ele­men­ta­mi na dia­gra­mach. Kluczową, moim zda­niem, przy­czy­ną two­rze­nia złych” mode­li obiek­to­wych jest uży­wa­nie nota­cji UML do two­rze­nia mode­li struk­tu­ral­nych, nie mają­cych z obiek­to­wym para­dyg­ma­tem nic wspól­ne­go. Druga to nie­zro­zu­mie­nie poję­cia para­dyg­ma­tu obiek­to­we­go. Ogromna ilość dia­gra­mów wyko­na­nych z uży­ciem sym­bo­li nota­cji UML, z UML i para­dyg­ma­tem obiek­to­wym ma nie­wie­le wspólnego.

Najpierw kil­ka defi­ni­cji i pojęć.

Paradygmat pro­gra­mo­wa­nia (ang. pro­gram­ming para­digm) ? wzo­rzec pro­gra­mo­wa­nia kom­pu­te­rów przed­kła­da­ny w danym okre­sie roz­wo­ju infor­ma­ty­ki ponad inne lub cenio­ny w pew­nych oko­licz­no­ściach lub zasto­so­wa­niach. (Źródło: Paradygmat pro­gra­mo­wa­nia ? Wikipedia, wol­na ency­klo­pe­dia)

No to teraz obiek­to­wy paradygmat:

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. (Źródło: Programowanie obiek­to­we ? Wikipedia, wol­na ency­klo­pe­dia)

albo:

Programowanie obiek­to­we lub ina­czej pro­gra­mo­wa­nie zorien­to­wa­ne obiek­to­wo (ang. object-orien­ted pro­gra­ming, OOP) to para­dyg­mat pro­gra­mo­wa­nia przy pomo­cy obiek­tów posia­da­ją­cych swo­je wła­ści­wo­ści jak pola (dane, infor­ma­cje o obiek­cie) oraz meto­dy (zacho­wa­nie, dzia­ła­nia jakie wyko­nu­je obiekt). Programowanie obiek­to­we pole­ga na defi­nio­wa­niu obiek­tów oraz wywo­ły­wa­niu ich metod, tak aby współ­dzia­ła­ły wza­jem­nie ze sobą. (Źródło: Programowanie obiek­to­we ? Encyklopedia Zarządzania

Słownik języ­ka pol­skie­go mówi:

współ­dzia­łać
1. ?dzia­łać wspól­nie z kimś?
2. ?przy­czy­niać się do cze­goś razem z inny­mi czyn­ni­ka­mi?
3. ?o mecha­ni­zmach, narzą­dach itp.: funk­cjo­no­wać w powią­za­niu z innymi?

wywo­łać ? wywo­ły­wać
1. ?woła­niem skło­nić kogoś do wyj­ścia skądś?
2. ?przy­po­mnieć sobie lub innym coś?
3. ?spo­wo­do­wać coś lub stać się przy­czy­ną cze­goś?
4. ?oznaj­mić coś publicz­nie?
5. ?oddzia­łać na kli­szę, bło­nę lub papier foto­gra­ficz­ny środ­ka­mi che­micz­ny­mi w celu uwi­docz­nie­nia obra­zu uta­jo­ne­go na mate­ria­le światłoczułym?

Tak więc stwier­dze­nie, że obiek­ty z sobą współ­dzia­ła­ją” ozna­cza, że wywo­łu­ją się” wza­jem­nie w celu spo­wo­do­wa­nia cze­goś kon­kret­ne­go. Innymi sło­wy obiek­ty two­rzą­ce pro­gram (sys­tem) są od sie­bie wza­jem­nie uza­leż­nio­ne. Dlatego pod­sta­wo­wym związ­kiem w pro­ce­sie ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo jest wza­jem­na zależ­ność”, nazy­wa­na w ory­gi­nal­nej spe­cy­fi­ka­cji UML związ­kiem usłu­go­daw­ca-usłu­go­bior­ca”.

Zależności

Związek ten nale­ży utoż­sa­miać z każ­dą wza­jem­ną zależ­no­ścią. Z uwa­gi na to, że mamy wie­le typów zależ­no­ści, wska­zu­je­my kon­kret­ny typ z pomo­cą ste­reo­ty­pu («[nazwa_typu]»).

Najczęściej wystę­pu­ją­cy typ zależ­no­ści to zwią­zek uży­cia. Oznacza on, że jeden obiekt wywo­łu­je umie­jęt­no­ści (ope­ra­cje) inne­go czy­li uży­wa go” do reali­za­cja swo­je­go zada­nia. Związek taki ozna­cza­ny ste­reo­ty­pem «use»:

uml-diagram-klas-zwiazek-uzycia

F uży­wa (jest zależ­ny od) E (co do zasa­dy tu F nie jest samo­dziel­ny w tym co robi”).

Formą zależ­no­ści jest tak­że dość rzad­ko wyko­rzy­sty­wa­na abs­trak­cja («Abstraction»). Związek ten jest wyko­rzy­sty­wa­ny do łącze­nia dwóch pojęć, z któ­rych jed­no jest abs­trak­cją dru­gie­go. Inna czę­sto wyko­rzy­sty­wa­na zależ­ność to «instanceOf» ozna­cza zależ­ność mode­lu (obiek­tu) od jego meta­mo­de­lu (kla­sy­fi­ka­to­ra) a tak­że od meta­me­ta­mo­de­lu.

Tak więc model opro­gra­mo­wa­nia w nota­cji UML z uży­ciem obiek­to­we­go para­dyg­ma­tu powi­nien wyglą­dać mniej wię­cej tak:

Wzorzec BCE

Na dia­gra­mie uży­to sym­bo­li klas (gra­ficz­na repre­zen­ta­cja ste­reo­ty­pów) zaczerp­nię­tych wzor­ca archi­tek­to­nicz­ne­go BCE.

Realizacja i kompozycja

Dokumentowanie deta­li struk­tu­ry ele­men­tów np. repo­zy­to­rium, wyma­ga stwo­rze­nia kolej­ne­go dia­gra­mu: mode­lu struk­tu­ry obiek­tów repre­zen­tu­ją­cych np. zło­żo­ną struk­tu­rę obiek­tu nio­są­ce­go infor­ma­cje (np. z formularza).

uml-diagram-klas-zwiazki-realizacja

Korzystamy tu ze związ­ku reali­za­cja i związ­ku kom­po­zy­cja. Realizacja to zwią­zek pomię­dzy spe­cy­fi­ka­cją a jej reali­za­cją (pro­jek­tem, imple­men­ta­cją, itp.), wska­zu­je zależ­ność imple­men­ta­cji od jej mode­lu. C2 jest spe­cy­fi­ka­cją (opi­sem, doku­men­ta­cją) reali­za­cji D2. Najczęściej zwią­zek ten jest sto­so­wa­ny pomię­dzy spe­cy­fi­ka­cją inter­fej­su a jego imple­men­ta­cją a tak­że gene­ral­nie pomię­dzy abs­trak­cją a jej reali­za­cją. Typowym przy­kła­dem uży­cia tego związ­ku jest np. poka­za­nie na jed­nym dia­gra­mie abs­trak­cji bytu w repo­zy­to­rium i reali­za­cji jej struktury:

model-dziedziny-realizacja-repozytorium

Na dia­gra­mie uży­to tak­że związ­ku całość-część”: linia zakoń­czo­na wypeł­nio­nym rom­bem na jed­nym koń­cu. Romb wska­zu­je na całość”: ele­ment nad­rzęd­ny drze­wia­stej struk­tu­ry kon­struk­cji. Jest to spe­cjal­ny zwią­zek ozna­cza­ją­cy trwa­łe (kon­struk­cyj­ne) powią­za­nie pomię­dzy deta­la­mi skła­da­ją­cy­mi się na okre­ślo­ną całość. UWAGA! Nie ma on nic wspól­ne­go z poję­ciem rela­cji” zna­nym z teo­rii rela­cyj­nych baz danych!

Biorąc pod uwa­gę fakt, jakim jest her­me­ty­za­cja jako cecha obiek­to­wych kon­struk­cji, takie enti­ties” nie współ­dzie­lą mie­dzy sobą ŻADNYCH ele­men­tów (danych). Użycie na dnie” bazy danych, wspól­nej dla całej apli­ka­cji, bazy dopro­wa­dzo­nej do tak zwa­nej znor­ma­li­zo­wa­nej posta­ci, łamie wszel­kie zasa­dy obiek­to­wych kon­struk­cji: łamie pod­sta­wo­wą zasa­dę jaką jest her­me­ty­za­cja imple­men­ta­cji obiek­tów (zakaz jakie­go­kol­wiek współ­dzie­le­nia cze­go­kol­wiek, nie nale­ży mylić współ­dzie­le­nia z re-użyciem).

Generalizacja i asocjacja

Oprócz mode­li struk­tur, powsta­ją czę­sto mode­le poję­cio­we. Są to odręb­ne dia­gra­my. Ich celem jest doku­men­to­wa­nie związ­ków seman­tycz­nych i syn­tak­tycz­nych pomię­dzy klu­czo­wy­mi poję­cia­mi wyko­rzy­sty­wa­ny­mi w pro­jek­cie. Stanowią one nazwy obiek­tów i ich typy (atry­bu­ty klas to tak­że obiek­ty). Wykorzystywane są tu dwa rodza­je związ­ków: gene­ra­li­za­cja i aso­cja­cja. Są to związ­ki repre­zen­tu­ją­ce WYŁĄCZNIE logicz­ne powią­za­nia pomię­dzy poję­cia­mi, nie mode­lu­ją one struk­tur a ni implementacji!

Jeżeli jakieś poję­cie ma swo­je spe­cja­li­zo­wa­ne typy, lub z dru­giej stro­ny, gru­pa pojęć daje się uogól­nić innym nad­rzęd­nym poję­ciem (gene­ra­li­zo­wa­nie), sto­su­je­my zwią­zek gene­ra­li­za­cji. Związek ten (korzy­sta­nie z nie­go) ma sens tyl­ko gdy licz­ba typów to co naj­mniej dwa, co do zasa­dy zwią­zek gene­ra­li­za­cji słu­ży do gru­po­wa­nia. Jeżeli pomię­dzy poję­cia­mi ist­nie­je zwią­zek wyni­ka­ją­cy z dzie­dzi­ny pro­ble­mu (np. zwią­zek pomię­dzy zwie­rzę­ciem a kar­mą dla nie­go) mode­lu­je­my go linią cią­głą łączą­cą powią­za­ne tak poję­cia. Poniżej gra­ficz­ny przy­kład uży­cia tych związków:

zwiazki-generalizacji-i-asocjacje-w-modelu-pojeciowym

B1 i B2 to kon­kret­ne typy poję­cia A (typem jest tak­że poję­cie). Analogicznie B12 i B22 to typy poję­cia A3. Pomiędzy poję­cia­mi A i A3 ist­nie­je zwią­zek logicz­ny (moż­na go nazwać, wpi­su­jąc te nazwę na linii). Typy mogą mieć wię­cej niż jeden kon­tekst dla­te­go mogą zostać pogru­po­wa­ne a każ­da gru­pa otrzy­mu­je nazwę nazwa gru­py” (oryg. Generalization Sets). Nie ma sen­su zwią­zek gene­ra­li­za­cji pomię­dzy tyl­ko jed­ną parą pojęć, bo ozna­cza wte­dy po pro­stu toż­sa­mość. Np. poję­cie woje­wódz­two” w Polsce ma obec­nie szes­na­ście spe­cja­li­za­cji, mają one swo­je nazwy, i to jest jed­na gru­pa typów. Jednak woje­wódz­twa moż­na podzie­lić tak­że np. ze wzglę­du na wiel­kość na np. trzy gru­py: małe woje­wódz­two, śred­nie woje­wódz­two i duże woje­wódz­two, i to będzie dru­ga i nie­za­leż­na gru­pa typów.

Modele…

Wszystkie powyż­sze przy­kła­dy to dia­gra­my klas nota­cji UML, jed­nak jak widać każ­dy ma zupeł­nie inne prze­zna­cze­nie (jest mode­lem cze­go inne­go). Nie oma­wia­łem tu zupeł­nie dia­gra­mów klas mode­lu­ją­cych kod pro­gra­mów. Zaznaczę jedy­nie, że są to kolej­ne mode­le doku­men­to­wa­ne z uży­ciem dia­gra­mów klas nota­cji UML, i omó­wio­ne powy­żej związ­ki dzie­dzi­cze­nia i aso­cja­cje na mode­lach poję­cio­wych mają tam zupeł­nie inne znaczenie.

Modele mogą być róż­ne i doty­czyć róż­nych rze­czy (patrz Modele.…). Tu chcę zwró­cić uwa­gę na bar­dzo waż­ny aspekt: abs­trak­cyj­ne i rze­czy­wi­ste poję­cia w mode­lach (na dia­gra­mach). Dostrzegam ogrom­ny bała­gan nie tyl­ko w doku­men­tach pro­jek­to­wych ale tak­że i w lite­ra­tu­rze, gdzie auto­rzy poka­zu­ją wie­le róż­nych przy­kła­dów, któ­re nie­ste­ty są złe i pozba­wio­ne uzasadnienia.

Przede wszyst­kim mode­le dzie­li­my, jak już wspo­mnia­łem, na poję­cio­we i te mode­lu­ją­ce jakąś okre­ślo­ną rze­czy­wi­stość. Modele poję­cio­we to mode­le poka­zu­ją­ce poję­cia oraz seman­tycz­ne i syn­tak­tycz­ne związ­ki mie­dzy nimi. Modele poję­cio­we słu­żą do udo­ku­men­to­wa­nia dzie­dzi­no­wej tak­so­no­mii co z jed­nej stro­ny pozwa­la utrzy­mać peł­ną jed­no­znacz­ność doku­men­ta­cji a z dru­giej, na eta­pie imple­men­ta­cji, pozwa­la podej­mo­wać decy­zje o typach danych. Służą one np. do budo­wa­nia słow­ni­ków i ety­kie­to­wa­nia np. pól for­mu­la­rzy (pole Nazwa woje­wódz­twa, któ­re­go zawar­tość będzie wybie­ra­na ze słow­ni­ka zawie­ra­ją­ce­go szes­na­ście nazw). Na tych mode­lach poja­wia­ją się w zasa­dzie wyłącz­nie poję­cia sta­no­wią­ce abs­trak­cje i typy, nie są to mode­le żad­ne­go kodu, dzie­dzi­ny itp. Tu przy­po­mnę, że model dzie­dzi­ny sys­te­mu to model opi­su­ją­cy mecha­nizm jego (sys­te­mu, apli­ka­cji) dzia­ła­nia, repre­zen­to­wa­ny jest przez liter­kę M we wzor­cu MVC, poważ­nym błę­dem jest uzna­wa­nie tych mode­li za mode­le danych.

Modele struk­tu­ry to mode­le opi­su­ją­ce okre­ślo­ne kon­struk­cje”, głów­nie na dwóch pozio­mach abs­trak­cji: jako model i jako meta­mo­del. Z regu­ły, w pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, ta kon­struk­cja to wła­śnie Model Dziedziny czy­li mecha­nizm dzia­ła­nia, tak zwa­na logi­ka biznesowa/dziedzinowa aplikacji.

Podsumowanie

Tak więc nie ma cze­goś takie­go jak dia­gram klas dla pro­jek­tu”. Mamy dla dane­go pro­jek­tu: model poję­cio­wy, mode­le logi­ki sys­te­mu, mode­le struk­tu­ry obiek­tów, mode­le imple­men­ta­cji. To wszyst­ko są dia­gra­my klas ale każ­dy z nich do model cze­goś inne­go”. Paradygmat obiek­to­wy jasno mówi: obiek­ty współ­pra­cu­ją, więc stan­dar­do­wym związ­kiem w mode­lach logi­ki dzia­ła­nia są związ­ki uży­cia a nie aso­cja­cje ani związ­ki dzie­dzi­cze­nia czy kom­po­zy­cji. Diagramy te nie są żad­ny­mi mode­la­mi danych mię­dzy inny­mi dla­te­go, że z zasa­dy para­dyg­mat obiek­to­wy ukry­wa je (her­me­ty­za­cja), na zewnątrz” dostęp­ne są wyłącz­nie publicz­ne ope­ra­cje obiek­tów. Utrwalanie obiek­tów (zapis war­to­ści atry­bu­tów np. w bazie danych) to zada­nie do roz­wią­za­nia dopie­ro na eta­pie imple­men­ta­cji, pole­ga­ją­ce na zagwa­ran­to­wa­niu zacho­wa­nia” sta­nów obiek­tów na czas wyłą­cze­nia zasi­la­nia, by nie ule­cia­ły” z pamię­ci kom­pu­te­ra, któ­ry jest śro­do­wi­skiem wyko­na­nia pro­gra­mu. Na eta­pie ana­li­zy obiek­to­wej i mode­lo­wa­nia logi­ki sys­te­mu nie mode­lu­je­my żad­nych danych.

Poniższy przy­kład, jakich wie­le w sie­ci, jest wzor­co­wym antyprzykładem.

(https://​www​.wie​dza​na​plus​.pl/​p​r​o​g​r​a​m​o​w​a​n​i​e​/​3​3​-​u​m​l​/​6​8​-​j​e​z​y​k​-​u​m​l​-​p​r​o​j​e​k​t​-​s​k​l​e​p​u​-​k​o​m​p​u​t​e​r​o​w​e​g​o​.​h​tml)

Pierwsza zła cecha tego dia­gra­mu to czę­sty błąd nazy­wa­ny popu­lar­nie prze­cią­ża­niem obiek­tów”: tu obiekt Faktura ma ope­ra­cje spo­rządź”. Klasyczny błąd archi­tek­to­nicz­ny pole­ga­ją­cy na obcią­ża­niu obiek­tu cudzą odpo­wie­dzial­no­ścią. Jeżeli kla­sa Faktura repre­zen­tu­je np. fak­tu­ry sprze­da­ży, to sys­tem mają­cy w pamię­ci kolek­cję setek fak­tur i każ­da z kodem (ma te ope­ra­cję) słu­żą­cym do jej spo­rzą­dze­nia był­by masa­krą zaję­to­ści pamię­ci. Dodam, że model taki nie ma nic wspól­ne­go z rze­czy­wi­sto­ścią, bo fak­tu­ry wysta­wia ktoś” a nie fak­tu­ra”. Trzecia rzecz: fak­tu­ra zaku­pu i fak­tu­ra sprze­da­ży to niczym nie róż­nią­ce się struk­tu­ry, więc two­rze­nie takie­go roz­róż­nie­nia jest pozba­wio­ne sen­su. To błę­dy poję­cio­we i ten dia­gram ma masę takich błę­dów. Druga wada: błęd­ne uży­cie związ­ku kom­po­zy­cji: powyż­szy dia­gram nale­ża­ło­by inter­pre­to­wać jako struk­tu­rę o jed­nej zwar­tej kon­struk­cji, np. takiej jak samo­chód skła­da­ją­cy się z setek pod­ze­spo­łów ale sta­no­wią­cy jed­nak jed­ną całość. Brak mode­lu poję­cio­we­go i słow­ni­ka powo­du­je wie­le nie­jed­no­znacz­no­ści. Np. zwią­zek pomię­dzy Klientem a rekla­ma­cją wska­zu­je, że Reklamacje są inte­gral­ną czę­ścią Klienta (tak jak koła i sil­nik są inte­gral­ną czę­ścią samo­cho­du) co nawet w świe­tle potocz­ne­go rozu­mie­nia tych słów kłó­ci się ze zdro­wym rozsądkiem.

Użycie związ­ków poję­cio­wych (aso­cja­cja) jest zupeł­nie nie­zro­zu­mia­łe w tym przy­pad­ku. Nazwa aso­cja­cji zawie­ra” nie ma kie­run­ku a więc nie wia­do­mo co jest zawar­te w czym. Związki zależ­no­ści tak­że są nie­ja­sne: jak inter­pre­to­wać np. zapis mówią­cy, ze obiek­ty kla­sy użyt­kow­ni­cy zale­żą od obiek­tów kla­sy Raporty? Jeżeli autor miał na myśli użyt­kow­nik uży­wa rapor­tów” to popły­nął w sfe­rę mowy potocz­nej”, to chy­ba naj­czę­ściej spo­ty­ka­ny błąd pole­ga­ją­cy na tym, że autor dia­gra­mu nadal pisze spe­cy­fi­ka­cję pro­zą, ale z uży­ciem sym­bo­li (tu UML) zamiast słów.

Mogę się jedy­nie domy­ślać, że autor dia­gra­mu miał w gło­wie” model rela­cyj­ny związ­ków encji i użył ikon z nota­cji UML w cał­ko­wi­cie innych zna­cze­niach niż ta nota­cja defi­niu­je. Takie dia­gra­my nie powin­ny powsta­wać, są one nie­ste­ty dowo­dem na to, że pro­gra­mi­ści mówią­cy te doku­men­ty z UML nic nie wyja­śnia­ją i są nie­pre­cy­zyj­ne, i tak musi­my sami powtó­rzyć te ana­li­zę” mają rację. Są tak­że dowo­dem, że są to jed­nak pro­jek­ty struk­tu­ral­ne a nie obiek­to­we, a uży­cie nota­cji UML pole­ga­ło na sko­rzy­sta­niu z zesta­wu ikon tak się to robi two­rząc nie­sfor­ma­li­zo­wa­ne sche­ma­ty blo­ko­we z uży­ciem np. pro­gra­mów do two­rze­nia pre­zen­ta­cji takich jak PowerPoint. Zapewne poza auto­rem tego dia­gram, nikt nie ma poję­cia o co w nim cho­dzi.… Jeżeli autor miał na celu udo­ku­men­to­wa­nie mode­lu danych” to powi­nien użyć nota­cji ERD. A tak to mamy sche­mat blo­ko­wy, w któ­rym ktoś użył UML jako biblio­te­ki sym­bo­li wpro­wa­dza­jąc czy­tel­ni­ka w błąd.

Z przy­kro­ścią muszę przy­znać, że od takich błę­dów nie są wol­ne tak­że nie­któ­re pod­ręcz­ni­ki i mate­ria­ły szko­le­nio­we… a tak­że doku­men­ty two­rzo­ne przez pra­cow­ni­ków wie­lu firm na ryn­ku IT.

P.S.

Na przy­kła­dy popraw­nych dia­gra­mów z uza­sad­nie­niem zapra­szam do mojej książ­ki i na moje szko­le­nia i warsz­ta­ty.

Specyfikacja UML v.2.5

Niestety spraw­ne” korzy­sta­nie z takich spe­cy­fi­ka­cji wyma­ga umie­jęt­no­ści czy­ta­nia mode­li poję­cio­wych (dia­gra­mów klas UML) opi­su­ja­cych syn­tak­ty­kę (syn­tax) jak wyżej (ich two­rze­nie też do łatwych nie nale­ży…). Przytaczam to jako źró­dło tego o czym tu pisałem.

W UML wszyst­ko jest kla­są”, związ­ki mię­dzy ele­men­ta­mi dia­gra­mów tak­że. Zostało to poka­za­ne w spe­cy­fi­ka­cji UML v.2.5.:

uml-zaleznosci
uml-klacyfikator
uml-zwiazki

W UML 2.5 prak­tycz­nie zni­ka w koń­cu dzie­dzi­cze­nie i agre­ga­cja. Uff… poni­żej pod­su­mo­wa­nie na jed­nym diagramie.

Dodatek [2022 – 07-22]

…chciał­bym zapy­tać o dzie­dzi­cze­nie w UML. Brałem ostat­nio udział w kil­ku roz­mo­wach o pra­cę. Moi roz­mów­cy czę­sto utrzy­mu­ją, że w UML jest to dzie­dzi­cze­nie. Mało tego, wyko­rzy­stu­ją to dzie­dzi­cze­nie na dia­gra­mach klas, w czymś co nazy­wa­ją mode­lem dzie­dzi­ny (oczy­wi­ście bez ope­ra­cji klas). Zajrzałem do spe­cy­fi­ka­cji UML i jestem tro­chę zdez­o­rien­to­wa­ny, ponie­waż poję­cie dzie­dzi­cze­nie dość czę­sto wystę­pu­je w tej doku­men­ta­cji, choć­by w tym fragmencie. 

W jakim zna­cze­niu jest tu uży­te poję­cie dzie­dzi­cze­nia? Czy jest gdzieś w spe­cy­fi­ka­cji wprost infor­ma­cja o usu­nię­ciu dzie­dzi­cze­nia z UMLa?

Porównując ze spe­cy­fi­ka­cją 2.4. nie ma, poję­cie dzie­dzi­cze­nia nadal jest obec­ne w języ­kach pro­gra­mo­wa­nia, a w spe­cy­fi­ka­cji 2.5.xx sło­wo inhe­ri­tan­ce” poja­wia sie tyl­ko 4 razy, i doty­czy wyłącz­nie komen­ta­rzy zwią­za­nych z uogólnieniami. 

Cytowany zwią­zek Generalizacji jest związ­kiem poję­cio­wym a nie struk­tu­ral­nym cze­goś ist­nie­ją­ce­go (struk­tu­ra mode­lo­wa­ne­go sys­te­mu). Formalnie w UML mamy zwią­zek Generalizacji, i jest to zwią­zek poję­cio­wy, ale nie ma w UML roz­dzia­łu Dziedziczenie”. Inherit w j. angiel­skim to tak­że prze­ję­cie cech po czymś” czy­li zwią­zek gene­ra­li­zo­wa­nia i spe­cja­li­zo­wa­nia. Generalziacja, jako zwią­zek ogól­ny-szcze­gól­ny, poka­zu­je że szcze­gól­ny przy­pa­dek, poję­cie i jego defi­ni­cja, ma wszyst­kie cechy przy­pad­ku ogól­niej­sze­go, więc pies jako szcze­gól­ny typ ssa­ka ma wszyst­kie cechy ssa­ka (cho­dzi o defi­ni­cje tego czym jest ssak). Czyli:
1. ssak: krę­go­wiec, któ­re­go mło­de kar­mią się mle­kiem mat­ki,
2. pies: <ssak> któ­ry szcze­ka,
więc:

pies: <krę­go­wiec, któ­re­go mło­de kar­mią się mle­kiem mat­ki>, któ­ry szczeka, 

czy­li pies (a kon­kret­nie defi­ni­cja psa) dzie­dzi­czy” po ssa­ku (defi­ni­cji ssa­ka) jego okre­ślo­ne cechy, czy­li ozna­cza to, że są one (cechy ssa­ka) np. dla psa i kota wspól­ne, a nie że, kot czy pies coś dzie­dzi­czy” po ssaku :). 

Dlatego w UML teraz jest napi­sa­ne, że mamy gene­ra­li­za­cję jako zwią­zek mię­dzy kla­sa­mi, ale nigdzie nie ma związ­ku dzie­dzi­cze­nia” mię­dzy klasami.

Tekst rozdz. 9.2.3.2. tłu­ma­czy­my tak, ze gene­ra­li­za­cja ozna­cza, że gene­ra­li­zo­wa­na defi­ni­cja (cechy czy­li atry­bu­ty i zacho­wa­nia) są wspól­ne (dzie­dzi­czą) dla spe­cja­li­zo­wa­nych ele­men­tów. W mode­lu poję­cio­wym (name­spa­ce) tak to dzia­ła. I teraz: model struk­tu­ry cze­go­kol­wiek ist­nie­ją­ce­go nie ma abs­trak­cji (a gene­ra­li­zo­wa­ne poję­cia to abs­trak­cje, poję­cie ssak to poję­cie abs­trak­cyj­ne). Opisując więc trak­tor jako pojazd czy doku­men­ty w księ­go­wo­ści jako doku­en­ty, nie ma nad nimi uogól­nień”, po któ­rych dzie­dzi­czą (sa to jed­nak poję­cia słow­ni­ko­we). Po tra­wie nie bie­ga­ją ssa­ki” tyl­ko psy, koty, lwy… 

Znakomita więk­szość zna­nych mi ludzi w IT nie odróż­nia mode­lu poję­cio­we­go od mode­lu struk­tu­ry sys­te­mu, któ­ry zbu­do­wa­ny jest (każ­dy) z real­nych ele­men­tów. W miej­sce sta­re­go” dzie­dzi­cze­nia w UML wpro­wa­dzo­no poję­cia: sza­blon (tem­pla­te) oraz rola (real­nym czymś w samo­cho­dzie jest sil­nik”, poję­cie napęd” to nazwa funkcji/roli okre­ślo­ne­go kom­po­nen­tu, ale nie pisze­my: „<sil­nik> dzie­dzi­czy po <napę­dzie>” tyl­ko „<sil­nik> peł­ni rolę <napę­du>” tak samo jak nie powie­my „<pies> dzie­dzi­czy po <zwie­rzę domo­we>” tyl­ko „<pies> peł­ni rolę <zwie­rzę­cia domowego>”. 

Języki pro­gra­mo­wa­nia pozwa­la­ją na tak zwa­ne re-uży­cie kodu, czy­li wycią­ga­nie pew­nych wspól­nych cech ponad kon­kret­ne komponenty/klasy (abs­trak­cja) po to by tyl­ko raz pisać kod kom­po­nen­tów mają­cych wspól­ne cechy. Jednak pro­jek­tu­jąc model dzie­dzi­ny” nie ma w niej abs­trak­cji, mając model dzie­dzi­ny (mecha­nizm dzia­ła­nia apli­ka­cji) zamie­nia­my gene­ra­li­za­cje i dzie­dzi­cze­nia” poję­cio­we na atry­bu­ty i typy real­nych rze­czy, tak to opi­sa­no książ­ce o mode­lo­wa­niu sys­te­mów już w 2007 roku: 

Oczywiście pro­gra­mi­sta może uży­wać gdzie chce dzie­dzi­cze­nia (ma taką moż­li­wość w każ­dym obiek­to­wym języ­ku pro­gra­mo­wa­nia) ale to jed­na z naj­gor­szych prak­tyk, bo łamią­cych klu­czo­wą zasa­dę jaką jest her­me­ty­za­cja kom­po­nen­tów („zakaz” współ­dzie­le­nia cze­go­kol­wiek). To dla­te­go od wie­lu lat OOP (Object-orien­ted Programming, języ­ki i pro­gra­mo­wa­nie obiek­to­we) i OOAD (Object-orien­ted Analysis and Design) to odręb­ne dzie­dzi­ny”.

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?

Business Analysis – diagram klas UML i bazy danych

Regularnie widu­je pyta­nia takie jak to:

I have an assi­gn­ment for deve­lo­ping a hotel rese­rva­tion sys­tem! One of tasks is to deve­lop UML class dia­gram! However, in the task descrip­tion it is writ­ten Class dia­gram sho­uld repre­sent your data­ba­se”. I am a bit con­fu­sed abo­ut the rules, nota­tions and etc… becau­se I can’t find any offi­cial UML class dia­grams spe­ci­fi­cal­ly for data­ba­ses! Could you help me ple­ase? (UML class dia­gram for data­ba­se).

i regu­lar­nie piszę: uży­wa­nie dia­gra­mu klas jako repre­zen­ta­cji [rela­cyj­nej] bazy danych to świa­dec­two kom­plet­ne­go nie­zro­zu­mie­nia ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo (żeby nie powie­dzieć igno­ran­cji). Jest to tak­że świa­dec­two bra­ku zna­jo­mo­ści lite­ra­tu­ry, bo fak­tycz­nie, jak zauwa­ża autor powyż­szych słów, nie ma ofi­cjal­nych mate­ria­łów (orga­ni­za­cja stan­da­ry­zu­ją­ca) mówią­cych o mode­lo­wa­niu danych dia­gra­ma­mi klas nota­cji UML. Do mode­lo­wa­nia danych uży­wa­my nota­cji ERD (ang. [[Entity Relationship Diagram]], dia­gram związ­ków encji). Niestety takie wzmian­ki – jak sto­so­wać dia­gram klas UML do mode­lo­wa­nia danych – moż­na zna­leźć w książ­kach uzna­wa­nych za war­to­ścio­we (okład­ka jed­nej z nich po pra­wej), moż­na usły­szeć na wie­lu szko­le­niach doty­czą­cych nota­cji UML, a nawet usły­szeć o tym moż­na – mode­lo­wa­nie danych w UML – z ust nie­jed­ne­go wykła­dow­cy na uczel­niach wyż­szych tech­nicz­nych (co jest smut­ne, mam na pół­ce pod­ręcz­nik aka­de­mic­ki z opi­sem sto­so­wa­nia klu­czy głów­nych i obcych na dia­gra­mach klas w mode­lo­wa­niu danych).

Przy oka­zji. Książkę tę (okład­ka obok: Business Analysis, Malcolm Eva (Author), Keith Hindle (Author), Craig Rollaston (Author)), mam na pół­ce, prze­czy­ta­łem, i mam oba­wy przez jej pole­ca­niem, mimo, że przez wie­lu jest uwa­ża­na nie­mal­że za biblię ana­li­ty­ka biz­ne­so­we­go (ale jako ogól­ny opis mode­lu kom­pe­ten­cyj­ne­go ana­li­ty­ka moż­na ją uznać).

Krótkie przy­po­mnie­nie pojęć (sł. j. polskiego):

dane
1. ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywodach?
2. ?infor­ma­cje prze­twa­rza­ne przez komputer?

obiekt
1. ?przed­miot, któ­ry moż­na zoba­czyć lub dotknąć?
2. ?rzecz abs­trak­cyj­na, np. cecha lub pojęcie?
3. ?coś, cze­go doty­czą czy­jeś dzia­ła­nia, zain­te­re­so­wa­nia lub uczucia?
4. ?budy­nek lub zespół budyn­ków; też: urzą­dze­nia terenowe?

Generalnie dane to zapis fak­tów (infor­ma­cje, wie­dza), obiekt to abs­trak­cyj­ny bądź rze­czy­wi­sty byt, mają­cy okre­ślo­ne cechy i reagu­ją­cy na bodź­ce. To dwa róż­ne świa­ty. Tak zwa­ny [[para­dyg­mat obiek­to­wy]] to mode­lo­wa­nie (trak­to­wa­nie) sys­te­mu jako zbio­ru współ­pra­cu­ją­cych w okre­ślo­nym celu obiek­tów. Model danych zaś, to opis orga­ni­za­cji infor­ma­cji. Model obiek­to­wy to struk­tu­ra współ­pra­cu­ją­cych obiek­tów mają­cych okre­ślo­ne zacho­wa­nia. Nie tyl­ko na uczel­niach nadal poku­tu­je sta­re”: Algorytmy plus struk­tu­ry danych rów­na się pro­gra­my, ale to defi­ni­cja jesz­cze z cza­sów prze­twa­rza­nia wsa­do­we­go. Dzisiaj mamy wokół sie­bie współ­dzia­ła­ją­ce kom­pu­te­ry, smart­fo­ny, linie pro­duk­cyj­ne, a nawet sprzęt AGD, gdzie tu są te oddziel­ne struk­tu­ry danych i algo­ryt­my”? Nie ma, są współ­dzia­ła­ją­ce obiek­ty. Owszem, każ­dy obiekt ope­ru­je okre­ślo­ny­mi dany­mi, ale są one w środ­ku” i nie są jed­ną wiel­ką bazą danych”.

Notacja UML bazu­je na obiek­to­wym para­dyg­ma­cie, dia­gram klas tej nota­cji słu­ży do mode­lo­wa­nia obiek­to­wej struk­tu­ry dowol­ne­go sys­te­mu (obiekt to nazwa, atry­bu­ty i ope­ra­cje jakie wyko­nu­je na żąda­nie). Nie ma tu mowy o żad­nych danych, co naj­wy­żej obiek­ty cechu­ją się okre­ślo­ny­mi atry­bu­ta­mi, te jed­nak nie są współ­dzie­lo­ne a zamknię­te w tych obiek­tach, bo to ich pry­wat­ne” cechy. Gdyby te atry­bu­ty były współ­dzie­lo­ne, sys­tem taki był­by nie­mo­dy­fi­ko­wal­ny, nie­po­dziel­ny i nie­podat­ny na zmia­ny, na wymia­nę w nim jed­ne­go obiek­tu na inny (co obser­wu­je­my nadal w sys­te­mach zin­te­gro­wa­nych meto­dą współ­dzie­le­nia danych, tak jest skon­stru­owa­ne wie­le sys­te­mów ERP!).

Owszem, na pozio­mie tech­no­lo­gicz­nym nadal korzy­sta­my z pli­ków na dys­kach i baz danych (nie zawsze rela­cyj­nych) ale to co inne­go, korzy­sta­my z nich do zapi­su (utrwa­la­nia) sta­nu sys­te­mu, utrwa­la­nia infor­ma­cji (danych). Na sty­ku tych dwóch świa­tów korzy­sta­my (jeże­li jest taka koniecz­ność) z mapo­wa­nia mode­lu obiek­to­we­go na utrwa­la­ne dane i wte­dy korzy­sta­my z nota­cji UML do mode­lo­wa­nia obiek­to­wej stryk­tu­ry apli­ka­cji i np. z nota­cji ERD do mode­lo­wa­nia np. rela­cyj­nej struk­tu­ry danych, łącz­nie nazy­wa się [[mapo­wa­nie obiek­to­wo-rela­cyj­ne (ORM)]]. Tak więc mode­lo­wa­nie danych nota­cją UML to pogwał­ce­nie zasad sto­so­wa­nia tej nota­cji i nie­zro­zu­mie­nie samej nota­cji, poję­cia obiekt i kla­sa. Skąd się bio­rą takie pomy­sły? Bardzo wie­lu ludzi uży­wa nota­cji tyl­ko w cha­rak­te­rze biblio­tek sym­bo­li, zaś nota­cja to sys­tem poję­cio­wy, a to nie jest to samo. A przy oka­zji: two­rze­nie takich mode­li w nota­cji UML, jako pro­jek­ty mode­lu dzie­dzi­ny sys­te­mu (obiek­to­we­go), to kla­sycz­ny antyw­zo­rzec pro­jek­to­wy o nazwie [[ane­micz­ny model dziedziny]].

System Analysis And Design with UML 2.0

Tym razem książ­ka napi­sa­na jak pod­ręcz­nik. Co praw­da napi­sa­na w 2005 roku, ale opar­ta jest na UML w wer­sji 2.0 więc nie psu­je” czy­tel­ni­ka ;). Książka zawie­ra w posta­ci bar­dzo dobrze upo­rząd­ko­wa­nej, opis całe­go pro­ce­su two­rze­nia opro­gra­mo­wa­nia meto­da­mi obiek­to­wy­mi: od pla­no­wa­nia do implementacji.

Wstęp zawie­ra bar­dzo poucza­ją­ce porów­na­nie i pod­su­mo­wa­nie pro­ce­sów wytwór­czych: od kla­sycz­ne­go wodo­spa­du do pro­gra­mo­wa­nia eks­tre­mal­ne­go. Znajdziecie tak­że uwa­gi na temat metod będą­cych ich kom­bi­na­cja­mi i, w róż­nych warian­tach, chy­ba naj­czę­ściej stosowanych.

Omówiono: fazę ini­cja­cji w tym pla­no­wa­nie i zarzą­dza­nie pro­jek­tem deve­lo­per­skim. Fazę ana­li­zy w tym ana­li­zę wyma­gań, mode­lo­wa­nie funk­cjo­nal­no­ści, struk­tu­ry i zacho­wa­nia. Fazę pro­jek­to­wa­nia w tym przej­ście z ana­li­zy na pro­jek­to­wa­nie, pro­jek­to­wa­nie klas i ich metod, pro­jek­to­wa­nie war­stwy danych, pro­jek­to­wa­nie komu­ni­ka­cji użyt­kow­ni­ka z sys­te­mem (GUI), pro­jek­to­wa­nie archi­tek­tu­ry (szcze­gól­nie ma to zna­cze­nia dla dużych sys­te­mów). Na koń­cu faza imple­men­ta­cji i wdrożenia.

Książka zawie­ra wie­le boga­to ilu­stro­wa­nych przy­kła­dów. Co praw­da auto­rzy powie­la­ją jesz­cze coś, co w moim mnie­ma­niu jest błę­dem, a mia­no­wi­cie nie oddzie­la­ją (albo łączą) ana­li­zy poję­cio­wej od obiek­to­wej na eta­pie ana­li­zy i pro­jek­to­wa­nia struk­tu­ry. Niestety model dzie­dzi­ny sys­te­mu to nie model poję­cio­wy, łącze­nie ich w jeden to echa kla­sycz­nej ana­li­zy struk­tu­ral­nej (dia­gra­my ERD i mode­le relacyjnej).

System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden
System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

Generalnie książ­kę pole­cam, mało jest tak dobrze napi­sa­nych kom­pen­diów na ten temat. Co do róż­ni­cy pomię­dzy ana­li­zą poję­cio­wą i pro­jek­to­wa­niem mode­lu dzie­dzi­ny sys­te­mu, nie raz pisa­łem (patrz art. Cholerny dia­gram klas) ale leży już w kolej­ce do prze­czy­ta­nia Business Rules Concepts Ronalda Ross’a. To czwar­ta edy­cja tej pozy­cji (mam wszyst­kie ;)) i już po pobież­nym przej­rze­niu widać ewo­lu­cje i stop­nio­we dora­sta­nie dziec­ka Ronalda Ross’a jakim jest kon­cep­cja reguł biz­ne­so­wych i mode­li poję­cio­wych jako narzę­dzia ana­li­zy i mode­lo­wa­nia. Koncepcja dosko­na­le pasu­je do metod obiek­to­wych ana­li­zy i pro­jek­to­wa­nia, ale o tym innym razem.

Książkę pole­cam przede wszyst­kim ana­li­ty­kom do nauki ale tak­że wyżar­tym” pro­gra­mi­stom, by sobie upo­rząd­ko­wa­li zdo­by­te doświad­cze­nie i moż­li­wie łagod­nie prze­cho­dzi­li od metod struk­tu­ral­nych do obiek­to­wych. Tu pew­nie nowin­ka dla nich: bazy danych pro­jek­tu­je­my na samym koń­cu, na eta­pie imple­men­ta­cji opra­co­wa­ne­go kom­plet­ne­go pro­jek­tu obiektowego.