Ten straszny diagram klas

(aktu­ali­zo­wa­ny 2020) Gdybym miał oce­nić sta­ty­stycz­nie dia­gram klas opi­sy­wa­ny w książ­kach o UML , pro­jek­tach jakie widu­ję nie tyl­ko w pra­cach stu­den­tów, to powie­dział bym, że jest jakiś pro­blem z nimi. Dlaczego? Pokaże to, co moim zda­niem jest chy­ba nie tak. Szczególnie jak ktoś uwa­ża, że dia­gram klas do model danych co wprost pro­wa­dzi do antyw­zor­ca obiek­to­we­go o nazwie ane­micz­ny model dzie­dzi­ny ?*?Ten arty­kuł to kon­ty­nu­acja poprzed­nie­go arty­ku­łu o mode­lach dzie­dzi­ny sys­te­mu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszyst­kim ana­li­za to nie pro­jekt, powin­na poka­zać obiek­tyw­ny stan fak­tycz­ny. Druga rzecz, o tym już nie­któ­rzy zapo­mi­na­ją: wyni­kiem ana­li­zy jest doku­men­ta­cja zro­zu­mie­nia, tak więc model ana­li­tycz­ny nie może być mode­lem poka­zu­ją­cym stan po uprosz­cze­niach. To powi­nien być model rze­czy­wi­sto­ści z nanie­sio­ny­mi, zasto­so­wa­ny­mi lokal­nie, ogra­ni­cze­nia­mi i uprosz­cze­nia­mi. Innymi sło­wy: dla fabry­ki spodni budu­je­my kom­plet­ny model czło­wie­ka (mane­kin) z komen­ta­rzem, że tu w uży­ciu jest część od pasa w dół a nie wma­wia­my niko­mu, że w tej fabry­ce czło­wiek skła­da sie wyłącz­nie z bio­der i nóg. W prze­ciw­nym wypad­ku, przy­szła roz­bu­do­wa sys­te­mu będzie co naj­mniej problematyczna.

Produkt ana­li­zy prze­ka­zu­je infor­ma­cję o tym co zasta­no, opi­su­je poję­cia i regu­ły jakie nimi rzą­dzą. Tak na praw­dę, opi­sać fir­mę (orga­ni­za­cję) to zna­czy stwo­rzyć listę pojęć jaki­mi się w niej ope­ru­je (jaki­mi moż­na ją opi­sać) i regu­ły jakie ogra­ni­cza­ją swo­bo­dę uży­cia (funk­cjo­no­wa­nia) tych pojęć. Model poję­cio­wy (ich spe­cy­fi­ka­cja) to seman­ty­ka sys­te­mu, ogra­ni­cze­nia swo­bo­dy ich wza­jem­ne­go koja­rze­nia to syn­tak­ty­ka, i na koniec dzie­dzi­no­we ogra­ni­cze­nie swo­bo­dy ich uży­cia to prag­ma­ty­ka. Wkrada się tu tak­że przy­dat­ne poję­cie jakim jest entro­pia czy­li mia­ra nie­upo­rząd­ko­wa­nia. Tak więc mamy sys­tem pojęć, jego entro­pia (sto­pień nie­upo­rząd­ko­wa­nia) jest ogra­ni­czo­na syn­tak­ty­ką i prag­ma­ty­ką spe­cy­ficz­ną dla dzie­dzi­ny i miej­sca (orga­ni­za­cji). Co to ozna­cza dla ana­li­zy przedwdrożniowej?

Jednym z celów tej ana­li­zy jest odkry­cie i zapi­sa­nie wie­dzy o pod­mio­cie infor­ma­ty­zo­wa­nym”. Jak ją zapi­sać? Ano wła­śnie tak: zbu­do­wać listę pojęć i wska­zać opi­sa­ne ogra­ni­cze­nia. Doskonałym narzę­dziem do tego jest dia­gram klas (odra­dzam dia­gram ERD, moż­na go póź­niej zbu­do­wać w opar­ciu o model poję­cio­wy, jeże­li zaj­dzie taka potrze­ba, ale nie nale­ży tych dwóch mode­li sto­so­wać zamien­nie). Diagram klas opi­su­ją­cy taki sys­tem poję­cio­wy to tak zwa­na prze­strzeń poję­cio­wa (name­spa­ce) . Jak to wygląda:

Diagram klas, taksonomia

Od razu uwa­ga: powyż­szy dia­gram jest nad­mia­ro­wy, w real­nym pro­jek­cie bym tego tak nie nary­so­wał, ale po kolei.???

Podstawowe poję­cia (seman­ty­ka) ana­li­zo­wa­ne­go sys­te­mu to kla­sy ozna­czo­ne nie­bie­skim kolo­rem. Bardzo czę­sto zda­rza się, że pew­ne poję­cia moż­na lub nale­ży pokla­sy­fi­ko­wać, by prze­ka­zać infor­ma­cję o ist­nie­niu tej kla­sy­fi­ka­cji. Diagram ten moż­na wiec uzu­peł­nić na dwa spo­so­by: sto­su­jąc tak zwa­ne super­kla­sy (uogól­nie­nie, zebra­nie kil­ku wspól­nych cech) oraz tak zwa­ne ste­reo­ty­py, czy­li zna­cząc dodat­ko­wo kla­sy. Klasa uogól­nia­na nazy­wa­na jest spe­cja­li­za­cją. Na powyż­szym dia­gra­mie Zamówienie (spe­cja­li­za­cja) jest spe­cy­ficz­nym rodza­jem Dokumentu (uogól­nie­nie) a każ­dy doku­ment to coś będą­ce­go jakąś tre­ścią np. na papie­rze. Zamówienie jed­nak jest tak­że «obiek­tem biz­ne­so­wym», utrwa­lo­nym i zro­zu­mia­łym poję­ciem (bytem) w fir­mie, do cze­goś kon­kret­ne­go służy.

Jest pew­na seman­tycz­na róż­ni­ca pomię­dzy super-kla­są a ste­reo­ty­pem, gdyż uwa­żam, że tych pojęć nie moż­na sto­so­wać zamien­nie. Super-kla­sa poka­zu­je, że pew­ne byty są uogól­nia­ne (mają one jakieś wspól­ne cechy zebra­ne w tym uogól­nie­niu) i uogól­nie­nie to – jako poję­cie – jest sto­so­wa­ne w roz­mo­wie”. Stereotyp wska­zu­je na pew­ne ist­nie­ją­ce i istot­ne (chce­my to zako­mu­ni­ko­wać w doku­men­ta­cji) roz­róż­nie­nie pomię­dzy poję­cia­mi jed­nak nie jest ono sto­so­wa­ne w roz­mo­wie”. Można więc uznać, że poję­cie Dokument funk­cjo­nu­je w roz­mo­wie” na rów­ni z poję­ciem Zamówienie choć jest to poję­cie (Dokument) abs­trak­cyj­ne. Nie ist­nie­je coś takie­go jak ogól­ny doku­ment” ale poję­cie to jest powszech­nie sto­so­wa­ne w fir­mach, abs­trak­cje takie ozna­cza­my pisząc nazwę takiej kla­sy kur­sy­wą. Można tak­że powie­dzieć, że Zamówienie jest «obiek­tem biz­ne­so­wym» (coś istot­ne­go, uży­wa­ne­go) jed­nak raczej nikt nie uży­wa tego poję­cia na co dzień. Ten ste­reo­typ infor­mu­je czy­tel­ni­ka ana­li­zy, że to coś istot­ne­go (jakimś kontekście).

Wpłata jest zda­rze­niem, jed­nak zda­rze­nie to coś, co na co dzień nie jest trak­to­wa­ne jako rów­no­praw­ne sło­wo” w biz­ne­sie. Dlatego w tym przy­pad­ku w mode­lu użył­bym tyl­ko ste­reo­ty­pu «zda­rze­nie», by wska­zać, że jest to coś inne­go niż «obiekt biz­ne­so­wy» ale już nie użył bym, abs­trak­cyj­nej super­kla­sy Zdarzenie. Jeżeli jed­nak w toku pro­jek­to­wa­nia (etap po ana­li­zie) uzna­my, że chce­my prze­twa­rzać dane o tych zda­rze­niach zapro­jek­tu­je­my dla sys­te­mu kla­sę Zdarzenie.

Obiektem biz­ne­so­wym jest jed­nak Dowód Wpłaty (tak na praw­dę repre­zen­tu­je on to zda­rze­nie ale nie jest to toż­sa­me poję­cie: stwier­dze­nie wpła­ty nie jest dowo­dem wpła­ty). Te niu­an­se są bar­dziej oczy­wi­ste (mam nadzie­ję :)) na przy­kła­dzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu tak­że ewi­dent­nie, że Klient jest wyłącz­nie Osobą.

Diagram ten zawie­ra tak­że pew­ne regu­ły biz­ne­so­we (ogra­ni­cze­nia entro­pii, czy­li swo­bo­dy). Są to liczeb­no­ści nanie­sio­ne na sko­ja­rze­nia (aso­cja­cje), linie łączą­ce kla­sy. Zaznaczono np. że Sprzedawca może mieć pod opie­ką klien­tów, tak­że żad­ne­go, jed­nak klient musi mieć i tyl­ko jed­ne­go opie­ku­na. Brak linii łączą­cej dwie kla­sy świad­czy zaś o tym, że nie ogra­ni­cza­ją się one nawza­jem w żaden spo­sób np. Wpłaty w żaden spo­sób nie wpły­wa­ją na Sprzedawcę i odwrot­nie. Istnieje jedy­nie pośred­ni zwią­zek mówią­cy, że moż­na sko­ja­rzyć Wpłatę ze Sprzedawcą, ele­men­tem koja­rzą­cym jest Faktura i jest ona tak­że kon­tek­stem tego sko­ja­rze­nia: Faktura jest pro­duk­tem pro­ce­su Sprzedaży, za któ­ry odpo­wia­da Sprzedawca. To jest powód, dla któ­re­go model pro­ce­sów powi­nien tak­że powstać jako jeden z pro­duk­tów takiej ana­li­zy bo to on zawie­ra tę wła­śnie informację.

Model dziedziny to projekt

A teraz model dzie­dzi­ny, przy­to­czę dia­gram uży­ty w poprzed­nim artykule:

Diagram klas, model dziedziny systemu

Jak widać jest pomię­dzy nimi istot­na róż­ni­ca. Jej źró­dłem jest to, że tak­so­no­mia to model poję­cio­wy zaś model dzie­dzi­ny (w rozu­mie­niu Model z wzor­ca MVC) to opis prze­twa­rza­nia. Przede wszyst­kim model dzie­dzi­ny nie zawie­ra pojęć abs­trak­cyj­nych. Dlaczego? No bo ich nie zapi­su­je­my i nie prze­twa­rza­my :)! Po dru­gie pew­ne poję­cia znik­nę­ły z mode­lu (Klient, jest akto­rem) bo Klient nie jest prze­twa­rza­ny, ale dane klien­ta będą atry­bu­ta­mi (nie zazna­czo­no) Zamówienia: jest on tu, Klient, zama­wia­ją­cym. Czytaj wię­cej o two­rze­niu i testo­wa­niu mode­lu dzie­dzi­ny.

Tak więc war­to zwró­cić uwa­gę na to, że dia­gram klas dia­gra­mo­wi nie rów­ny, to samo narzę­dzie może posłu­żyć do dwóch róż­nych celów w tej samej doku­men­ta­cji. Widać tak­że (mam nadzie­ję), że pró­ba poka­za­nia na jed­nym dia­gra­mie zarów­no sys­te­mu pojęć jak i spo­so­bu ich prze­twa­rza­nia, jako infor­ma­cji w sys­te­mach infor­ma­tycz­nych, jest raczej błęd­nym podej­ściem. Wydaje mi się, że podej­mo­wa­nie takich prób świad­czy o nie­zro­zu­mie­niu róż­ni­cy pomię­dzy sys­te­mem poję­cio­wym a mode­lem prze­twa­rza­nia infor­ma­cji. W szcze­gól­no­ści gdy doty­czy to sys­te­mów obiektowych.

Programistom pole­cam tak­że te stro­ny.


  1. ?*?
    https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​A​n​e​m​i​c​D​o​m​a​i​n​M​o​d​e​l​.​h​tml
  2. ???
    w 2015 roku zmie­ni­ła się spe­cy­fi­ka­cja UML, usu­nię­to poję­cie dzie­dzi­cze­nia i agre­ga­cji, suge­ru­ję uzu­peł­nić wie­dzę wpi­sa­mi, któ­re powsta­ły po 2015 roku. 

Źródła

Zelinski, J. (2020) Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).
Fowler, M. (1997) Analysis pat­terns: reu­sa­ble object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-orien­ted softwa­re engineering).
Usman, M. et al. (2017) Taxonomies in softwa­re engi­ne­ering: A Systematic map­ping stu­dy and a revi­sed taxo­no­my deve­lop­ment method’, Information and Software Technology, 85, pp. 43 – 59. Available at: https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​1​7​.​0​1​.​006.
Stevens, P. (2007) UML Inżynieria opro­gra­mo­wa­nia. Translated by I. Jakóbik. Gliwice: Helion.
Booch, G., Rumbaugh, J. and Jacobson, I. (2002) UML prze­wod­nik użyt­kow­ni­ka. dru­gie wyda­nie. Warszawa: WNT (inży­nie­ria oprogramowania).

Inne artykuły na podobny temat

Komentarze

  1. Hania Wesołowska 13 lipca 2012 at 13:46

    Czyli tak­so­no­mię (nie­bie­skie) przy­go­to­wu­je­my na wcze­snym eta­pie i zatwier­dza­my z zama­wia­ją­cym, a model dzie­dzi­ny (żół­te) przy­go­to­wu­je­my dla sie­bie (nie poka­zu­je­my klien­to­wi, ale prze­ka­zu­je­my zespo­ło­wi wykonawców)?

  2. Piotrek 8 sierpnia 2012 at 12:10

    Z jakich rela­cji nale­ży korzy­stać przy budo­wa­niu mode­lu poję­cio­wym (tak­so­no­mii)? Na przed­sta­wio­nym sche­ma­cie są tyl­ko aso­cja­cje i uogól­nie­nia. Czy zazna­cza­nie na tym eta­pie kom­po­zy­cji czy agre­ga­cji jest zasadne?
    I dru­ga spra­wa – na ile głę­bo­ko scho­dzić na eta­pie mode­lu poję­cio­we­go. Przykład: zarów­no Zamówienie jak i Faktura skła­da się z pozy­cji. Na poda­nym przy­kła­dzie zosta­ło to pomi­nię­te. Pytanie czy celo­wo czy dla uproszczenia?

    • Jarek Żeliński 8 sierpnia 2012 at 12:22

      Model poję­cio­wy to nic inne­go jak słow­ni­ko­we podej­ście do tema­tu” podob­ne do pod­ręcz­ni­ko­wej kla­sy­fi­ka­cji roślin czy psów. Stosując dia­gram klas do tego, nale­ży się wystrze­gać cho­ro­by rela­cyj­nej” czy­li trak­to­wa­nia pojęć (klas) jak encji (tabel) na dia­gra­mach baz danych (ERD) bo mają tu one zupeł­nie inny sens. Przedstawiony przy­kład poka­zu­je wyłącz­nie logi­kę poję­cio­wą więc Faktura jest jakoś” powią­za­na logicz­nie z Zamówieniem. Ale! Tu (model poję­cio­wy) Faktura i Zamówienie to nie doku­men­ty” z ich tre­ścią, a poję­cia np. Faktura do doku­ment, który…”.

      Głębokość uszcze­gó­ło­wie­nia. Więc wyja­śni­ło się jed­no: na mode­lu poję­cio­wym Faktura to zde­fi­nio­wa­ne poję­cie – ter­min, więc nie ma żad­nych pozy­cji fak­tu­ry itp. Można zde­fi­nio­wać poję­cie pro­dukt” itp. ale wte­dy dia­gram klas jako model poję­cio­wy (chcąc poka­zać każ­dy zwią­zek logicz­ny) sta­nie się nie­czy­tel­nym tale­rzem spa­get­ti” albo będzie nie­kom­plet­ny (w zasa­dzie w biz­ne­sie wszyst­kie poję­cia jakoś się ze sobą wią­żą). Dlatego od jakie­goś cza­su dia­gra­mu klas nie uży­wam do mode­lo­wa­nia sys­te­mu pojęć, poprze­sta­jąc na słow­ni­ku pojęć i spe­cy­fi­ka­cji doku­men­tów (obiek­tów biz­ne­so­wych). Diagramów klas uży­wam wyłącz­nie do mode­lo­wa­nia dzie­dzi­ny sty­lem opi­sa­nym jako DDD, cza­sa­mi do zobra­zo­wa­nia metamodeli.

  3. MikeR 7 lutego 2017 at 15:29

    Mam pyta­nie ponie­waż w książ­ce B. Bruegge i A.H. Duttoit Inżynieria opro­gra­mo­wa­nia w uję­ciu obiek­to­wym” auto­rzy wspo­mi­na­ją o mode­lach dzie­dzi­ny apli­ka­cyj­nej i reali­za­cyj­nej. Na stro­nie 40 piszą, że: Istotą podej­ścia zorien­to­wa­ne­go obiek­to­wo jest połą­cze­nie mode­li obu dzie­dzin(…)”. Czy zatem wspo­mnia­ny w tym arty­ku­le (i innych arty­ku­łach na tym blo­gu) model dzie­dzi­ny mamy utoż­sa­miać z oby­dwo­ma mode­la­mi ze wspo­mnia­ne­go opracowania?

    • Jaroslaw Zelinski 7 lutego 2017 at 18:05

      Hm… dobre pyta­nie… Generalnie mamy model logi­ki sys­te­mu” czy­li jego mecha­nizm dzia­ła­nia”. Myślę, że inten­cją auto­ra było oddziel­nie logi­ki sys­te­mu” od logi­ki inte­rak­cji z nim”. Jeżeli tak, to odpo­wia­da temu wzo­rzec MVC-MV-VM. Model dzie­dzi­ny to taki e„prawa fizy­ki w tym sys­te­mie”. To pod­sta­wa jego dzia­ła­nia. Ale już model” inte­rak­cji z apli­ka­cją na kom­pu­te­rze a model inte­rak­cji na smart­fo­nie mają swo­ją specyfikę.

    • MikeR 7 lutego 2017 at 21:31

      Dzięki za info. Teraz jest to dla mnie bar­dziej jasne.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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