Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

Model poję­cio­wy (dia­gram fak­tów SBVR lub model poję­cio­wy, dia­gram klas UML)

(UWAGA! Powyższy model nie jest żad­nym mode­lem dzie­dzi­ny” ani mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

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 :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Czytaj dalej… Model dzie­dzi­ny jako mecha­nizm”

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?

Diagram obiektów czyli bottom-up

W toku nie­jed­nej ana­li­zy moż­na spo­tkać się z sytu­acją gdy stan­dar­do­we podej­ście pole­ga­ją­ce na bada­niu doku­men­tów i ana­li­zie zstę­pu­ją­cej (od ogó­łu do szcze­gó­łu, ang. top-down) może być trud­ne lub wręcz nie moż­li­we. Dotyczy to ana­li­zy sys­te­mów sła­bo udo­ku­men­to­wa­nych lub wręcz nie­udo­ku­men­to­wa­nych, gdzie jedy­ne dostęp­ne dane to obser­wa­cja lub rela­cja obser­wa­to­ra (uczest­ni­ka, itp. czy­li rela­cja z dru­giej ręki). Jest to sytu­acja podob­na to serii (pakie­tu) zebra­nych user sto­ry” (w nomen­kla­tu­rze meto­dyk zwin­nych histo­ryj­ki użyt­kow­ni­ka), nie­for­mal­nych rela­cji. Jak ugryźć taką sytuację?

Z pomo­cą przy­cho­dzi poję­cie spe­cy­fi­ka­cji instan­cji w UML, zapew­ne brzmi to strasz­nie ale nie jest tak źle. Cóż to jest ta spe­cy­fi­ka­cja instan­cji? Co mówi spe­cy­fi­ka­cja (UML v.2.5):

9.8 Instances
9.8.1 Summary
InstanceSpecifications repre­sent instan­ces of Classifiers in a mode­led sys­tem. They are often used to model exam­ple con­fi­gu­ra­tions of instan­ces. They may be par­tial or com­ple­te repre­sen­ta­tions of the instan­ces that they cor­re­spond to.

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze tych rze­czy” o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi słowy

dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rzeczy

Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić od dołu” czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez klien­ta”. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le kon­kret­nych sytu­acji” z życia.

Tak więc napi­szę tu kil­ka słów o bar­dzo mało popu­lar­nym dia­gra­mie UML: dia­gra­mie obiek­tów (spe­cy­fi­ka­cje instancji).

InstanceSpecUML25Notation
(źr. UML v.2.5, for­mal 15 – 03-01)

Powyższe przy­kła­dy to mode­le kon­kret­nych sytu­acji: mamy tu (od góry) kon­kret­ną uli­cę, kon­kret­ny adres, dwie oso­by i zwią­zek mię­dzy nimi (ojciec-syn) oraz tak zwa­ną war­tość (nazwa­ne kon­kret­ne war­to­ści to tak­że obiek­ty). Diagram obiek­tów zawie­ra więc prak­tycz­nie wyłącz­nie kon­kret­ne, nazwa­ne byty w opi­sy­wa­nej rze­czy­wi­sto­ści. Prawdę mówiąc bar­dzo wie­le, o ile nie więk­szość, sche­ma­tów blo­ko­wych wyko­ny­wa­nych w tak zwa­nych doku­men­tach biz­ne­so­wych i pre­zen­ta­cjach, to pew­ne nie­for­mal­ne dia­gra­my obiek­tów. Wszędzie tam gdzie na sche­ma­cie blo­ko­wym są kon­kret­nie nazwa­ne uni­kal­ne ele­men­ty łączo­ne róż­ny­mi for­ma­mi linii i strza­łek, moż­na mówić o przed­sta­wie­niu kon­kret­nej zma­te­ria­li­zo­wa­nej” sytuacji.

Typowym przy­kła­dem są sche­ma­ty orga­ni­za­cyj­ne. Poniżej jed­na z wie­lu dostęp­nych w sie­ci Internet struk­tur orga­ni­za­cyj­nych: są to kon­kret­ne nazwy orga­nów (np. Rada Nadzorcza), komó­rek orga­ni­za­cyj­nych i sta­no­wisk, np. jak na poniż­szym diagramie.

źr. http://www.darrwww.hb.pl/pl/1042/Kadra_i_struktura_organizacyjna/
źr. http://​www​.dar​rwww​.hb​.pl/​p​l​/​1​0​4​2​/​K​a​d​r​a​_​i​_​s​t​r​u​k​t​u​r​a​_​o​r​g​a​n​i​z​a​c​y​j​na/

Powyższy dia­gram do dość powszech­na for­ma doku­men­to­wa­nia struk­tu­ry orga­ni­za­cyj­nej. Poniżej wer­sja tej struk­tu­ry (okro­jo­na) w posta­ci dia­gra­mu obiektów:

Analiza stanu faktycznego_1

Są to dokład­nie te same blocz­ki”, na dia­gra­mie tym (UML, dia­gram obiek­tów) każ­dy ele­ment to instan­cja (kla­sy)”. Na tym eta­pie odwzo­ro­wu­je­my jedy­nie to co wie­my w for­mie jaką zna­my. Kolejny etap to szu­ka­nie zasad i klu­czo­wych dla nich pojęć, skla­sy­fi­ko­wa­nie obiek­tów odwzo­ro­wa­nych na diagramie:

Struktura organizacyjna - model pojeciowy

Powyższy dia­gram to dia­gram fak­tów (spe­cy­fi­ka­cja SBVR/OMG). Jest to model poję­cio­wy, skła­da się z pojęć słow­ni­ka (pojęć biz­ne­so­wych) i fak­tów łączą­cych te poję­cia, na ich pod­sta­wie two­rzo­ne są kla­sy i atry­bu­ty, do któ­rych przy­po­rząd­ko­wy­wa­ne są poszcze­gól­ne obiek­ty mode­lu ana­li­zo­wa­ne­go (dia­gra­mu obiektów):

Struktura organizacyjna - klasyfikacja obiektów

Powyżej obiek­to­wy model Struktury orga­ni­za­cyj­nej po uzu­peł­nie­niu o kla­sy­fi­ka­to­ry (każ­dy obiekt na dia­gra­mie został przy­po­rząd­ko­wa­ny do okre­ślo­nej kla­sy). Teraz moż­na opra­co­wać struk­tu­rę metamodelu:

Struktura organizacyjna - model dziedziny

Powyższy dia­gram to meta­mo­del tego co przed­sta­wia dia­gram obiek­tów (pier­wot­nie poka­za­na struk­tu­ra orga­ni­za­cyj­na). Teraz poja­wia się pyta­nie: co ma wyko­nać pro­gra­mi­sta (o ile takie jest zada­nie). Na tym eta­pie zro­zu­mie­li­śmy czym jest struk­tu­ra orga­ni­za­cyj­na i udo­ku­men­to­wa­li­śmy to, ale nadal nie roz­wią­za­li­śmy pro­ble­mu: jak to zaim­ple­men­to­wać (powyż­sze nie jest żad­nym wyma­ga­niem imple­men­ta­cji dla programisty).

Teraz mamy dwa wyj­ścia (pew­nie są też inne): potrak­to­wać powyż­sze jako meta­mo­del struk­tu­ry orga­ni­za­cyj­nej, użyć go, po uzu­peł­nie­niu o ogra­ni­cze­nia, jako recep­ty” dla fabry­ki struk­tu­ry orga­ni­za­cyj­nej”, uzu­peł­nić o kla­sy two­rzą­ce tę struk­tu­rę (wspo­mnia­ną fabry­kę) i dokoń­czyć model dzie­dzi­ny sys­te­mu”, albo poprze­stać na tym eta­pie, spi­sać regu­ły biz­ne­so­we” i w tej for­mie prze­ka­zać deve­lo­pe­ro­wi (wte­dy on sam musi roz­wią­zać pro­blem meto­dy imple­men­ta­cji). Jedno jest pew­ne: nie jest to abso­lut­nie żaden model danych.

Tak więc ana­li­za od szcze­gó­łu do ogó­łu” cza­sa­mi bywa bar­dzo pomoc­na. Pozwala wyjść od kon­kret­ne­go rze­czy­wi­ste­go sta­nu świa­ta” i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest mode­lem dzie­dzi­ny” jed­nak nim nie jest.

UML version 2.5

Co praw­da for­mal­na publi­ka­cja wer­sji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie uto­nie (spo­koj­ne prze­brnię­cie tych 794 stron wyma­ga cza­su i cier­pli­wo­ści), czy­li wzmian­ka i kil­ka słów z pierw­szych wra­żeń. Specyfikacja do pobra­nia tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5

Zdaję sobie spra­wę z tego, że poniż­sze nie wszyst­kim z Was wszyst­ko wyja­śni ale ten aku­rat wpis adre­su­ję dla tych z Was, któ­rzy korzy­sta­ją już z UML, nawet w bar­dzo pro­sty sposób.

Wersja 2.5 UML to wer­sja chy­ba prze­ło­mo­wa, bo:

  • zre­zy­gno­wa­no w koń­cu z podzia­łu na dwie czę­ści Infrastructure i Superstructure,
  • upo­rząd­ko­wa­no cały sys­tem poję­cio­wy nota­cji: jest to w koń­cu jed­na w peł­ni spój­na nota­cja (sys­tem kla­sy­fi­ka­to­rów, kie­dyś Infrastructure) oraz zestaw pre­de­fi­nio­wa­nych grup ste­reo­ty­pów z ich dedy­ko­wa­ną seman­ty­ką i syn­tak­ty­ką (kie­dyś Superstructure).
  • dia­gram jako poję­cie, obec­nie sta­no­wi jedy­nie kon­tekst a nie, jak kie­dyś zamknię­tą sub­no­ta­cję” (UML zaczy­nał w latach 90-tych jako zle­pek kil­ku nota­cji trzech autorów).

Obecnie mamy osiem typów dia­gra­mów (kopia z oryginału):

UML dia­grams may have the fol­lo­wing kinds of fra­me names as part of the heading:
? acti­vi­ty
? class
? com­po­nent
? deploy­ment
? inte­rac­tion
? pac­ka­ge
? sta­te machi­ne
? use case
In addi­tion to the long form names for dia­gram heading types, the fol­lo­wing abbre­via­ted forms can also be used:
? act (for acti­vi­ty fra­mes)
? cmp (for com­po­nent fra­mes)
? dep (for deploy­ment fra­mes)
? sd (for inte­rac­tion fra­mes)
? pkg (for pac­ka­ge fra­mes)
? stm (for sta­te machi­ne fra­mes)
? uc (for use case frames)

Jak widać, trzy­li­tro­wych skró­tów ozna­cza­ją­cych dia­gra­my jest o jeden mniej (sie­dem). To wyni­ka z tego, że wszyst­kie dia­gra­my w UML to tak na praw­dę dia­gra­my klas (ten typ dia­gra­mu nie ma swo­je­go dedy­ko­wa­ne­go skró­tu), z tym że sta­no­wią one kon­tek­sto­we pro­fi­le. Struktura poję­cio­wa tych dia­gra­mów (ich [[tak­so­no­mia]]):

UML The taxonomy of structure and behavior diagrams

W sto­sun­ku do UML 2.4 dia­gram pro­fi­lu jest teraz rów­no­praw­nym typem dia­gra­mu (czter­na­sty). Wszystkie poję­cia UML (con­structs) zosta­ły przy­dzie­lo­ne kon­tek­sto­wo to typów diagramów:

The con­structs con­ta­ined in each of the UML dia­grams are descri­bed in the clau­ses indi­ca­ted below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment dia­gram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozu­mieć w ten spo­sób: dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py acti­vi­ties” (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla kla­sy­fi­ka­to­rów struk­tu­ral­nych”, itd.

Warto przy­pa­trzeć się swo­im narzę­dziom CASE, gdyż nie­ste­ty nie wszyst­kie mają wbu­do­wa­ny powyż­szy kla­so­wy” para­dyg­mat (w UML wszyst­ko jest kla­są). Wiele z nich nadal hoł­du­je zasa­dzie dia­gra­my jako odręb­ne nota­cje, obec­nie w UML w każ­dym typie dia­gra­mu moż­na użyć każ­de­go ele­men­tu nota­cji, dia­gram jako poję­cie to wyłącz­nie kon­te­ner nio­są­cy głów­ny kon­tekst dane­go mode­lu, bo przy­po­mi­nam, że dia­gram w UML to wyłącz­nie widok cało­ści lub czę­ści mode­lu z okre­ślo­nej per­spek­ty­wy i na okre­ślo­nym pozio­mie abstrakcji.

[uzu­peł­nie­nie 2015-11-21] Z pew­ną satys­fak­cją odkry­łem” (pier­wot­nie, pisząc ten arty­kuł mie­siąc temu, nie zwró­ci­łem na to uwa­gi), że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji, zwa­nej w czę­ści lite­ra­tu­ry sła­bą kom­po­zy­cją”. Ta kurio­zal­na kon­struk­cja poję­cio­wa kłó­ci­ła się z poję­ciem i aso­cja­cji jako takiej i kom­po­zy­cji jako związ­ku całość część”. Nie ja jeden, jak śle­dzę dys­ku­sje człon­ków OMG na listach LinkedIn, dekla­ro­wa­łem, że nie rozu­miem” czym jest agre­ga­cja (chy­ba pierw­szym, któ­ry to gło­śno mówił był Martin Fowler). Na szczę­ście widać, że defi­ni­cja tego poję­cia nie wytrzy­ma­ła boju z logi­ką. Co praw­da sym­bol aso­cja­cji z pustym rom­bem” jest (tyl­ko) na liście sym­bo­li w dodat­ku B.6 (str. 718) jed­nak widać, że to relikt kom­pa­ty­bil­no­ści wstecz, w tre­ści całej spe­cy­fi­ka­cji to poję­cie nie jest w ogó­le uży­wa­ne. Generalnie mamy zwią­zek kom­po­zy­cji (peł­ny romb), a ele­ment skom­po­no­wa­ny może być rze­czy­wi­sty (part) lub abs­trak­cyj­ny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dzie­dzi­cze­niem: nie ma dzie­dzi­cze­nia (korek­ta gru­dzień 2017, UML 2.5.1.).

Polecam całą spe­cy­fi­ka­cję, znacz­nie krót­sza od poprzedniej :).