(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:

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:

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.

Źródła