Niedawno cyto­wa­łem tu pew­ne­go profesora:

Drodzy Młodzi Przyjaciele. Czuję się w obo­wiąz­ku zwie­rzyć się Wam z bar­dzo przy­krej tajem­ni­cy. Nie jeste­ście ? więk­szość z Was ? dobrze wykształ­ce­ni, a jedy­nie tak Wam się wyda­je. Zostaliście oszu­ka­ni naj­pierw przez nauczy­cie­li, a potem przez wykła­dow­ców ? wyzna­je Jan Stanek, pro­fe­sor fizy­ki z Uniwersytetu Jagiellońskiego. (za Wiedza po stu­diach? ).

i cóż, nie­ste­ty chy­ba ma rację. Ten arty­kuł jest moim subiek­tyw­nym odczu­ciem, jed­nak sta­ra­łem się wska­zać na źró­dła moje­go ​„sprze­ci­wu”.

Regularnie jestem pro­szo­ny przez stu­den­tów o kore­pe­ty­cje z zakre­su ana­li­zy i mode­lo­wa­nia obiek­to­we­go, cza­sem tak­że mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Wspólną ich cechą jest to, że ana­li­za obiek­to­wa i UML to ​„ostat­nie kil­ka ich zajęć na szyb­ko”, a mowa o kie­run­kach infor­ma­ty­ka, ana­li­za i pro­jek­to­wa­nie itp. Ktoś taki na ryn­ku pra­cy w dużych i trud­nych pro­jek­tach jest ​„szkod­ni­kiem”, bo jak zauwa­żył wyżej cyto­wa­ny pro­fe­sor, czło­wiek taki z peł­nym prze­ko­na­niem, że coś dobrze robi, po pro­tu szkodzi.

Do napi­sa­nia tego arty­ku­łu ​„zmu­si­ła” mnie kolej­na przy­go­da z kore­pe­ty­cja­mi, w któ­rej tym razem dosta­łem od stu­den­ta peł­ną treść zada­nia wraz ze wska­zów­ka­mi. Nie będę pisał o jaką uczel­nię cho­dzi i kim jest ten­że wykła­dow­ca bo nie jest moim celem kry­ty­ka oso­by czy uczel­ni. To co pisze, wyda­je mi się, jest zja­wi­skiem powszech­nym (w mia­rę cza­su jakim dys­po­nu­je, udzie­lam czę­sto kore­pe­ty­cji stu­den­tom róż­nych uczelni).

Zadanie i zalecenia

(kur­sy­wą wska­zów­ki, wyma­ga­nia wykładowcy)

Należy utwo­rzyć model infor­ma­cyj­ny sys­te­mu – dia­gram klas. Problem w tym, że w ana­li­zie obiek­to­wej nie uży­wa się poję­cia ​„model infor­ma­cyj­ny”. Jest to poję­cie z obsza­ru rela­cyj­ne­go mode­lo­wa­nia danych i ana­li­zy sys­te­mo­wej. Diagram klas to albo model poję­cio­wy (słow­ni­ko­wy) albo model struk­tu­ry kodu opro­gra­mo­wa­nia: byty mają­ce atry­bu­ty i ope­ra­cje (umie­jęt­no­ści).

Każdy z atry­bu­tów musi mieć usta­lo­ny typ danych. To jest zada­nie na eta­pie imple­men­ta­cji a nie ana­li­zy obiek­to­wej i pro­jek­to­wa­nia logi­ki sys­te­mu. typy danych to pra­ca dla pro­gra­mi­sty. Typy danych to poję­cia z obsza­ru pro­gra­mo­wa­nia, są (nie­co) róż­ne w róż­nych języ­kach pro­gra­mo­wa­nia. Przymus ich dekla­ro­wa­nia już na eta­pie ana­li­zy i pro­jek­to­wa­nia, czy­li przed wybo­rem tech­no­lo­gii, jest dla mnie kurio­zal­ny. Jeżeli ​„wykła­dow­ca” ma taki styl pra­cy jako ​„ana­li­tyk” to jest źle, że prze­no­si to na zaję­cia ze stu­den­ta­mi, bo stu­den­tów nale­ży uczy kla­sy­ki i stan­dar­dów a nie pry­wat­nej meto­dy pra­cy. Owszem, nale­ży powie­dzieć, że np. nazwi­sko może skła­dać się wyłącz­nie z liter, gdzie pierw­sza jest duża a resz­ta małe ale to infor­ma­cja dla pro­gra­mi­sty a nie ​„typ danych”. Poza tym takie regu­ły zapi­su nazwisk moż­na imple­men­to­wać na wię­cej niż jeden sposób.

Klasy na tym eta­pie nie mają zde­fi­nio­wa­nych ope­ra­cji. Klasa w UML to: nazwa, atry­bu­ty i ope­ra­cje(!). W lite­ra­tu­rze przed­mio­tu wręcz twier­dzi się, że na wstęp­nym eta­pie ana­li­zy i pro­jek­to­wa­nia obiek­to­we­go ope­ru­je się inter­fej­sa­mi czy­li wła­śnie ​„tyl­ko” nazwą i listą ope­ra­cji kla­sy. Operacja to bar­dzo waż­ny ele­ment mode­lu bo zawie­ra reali­zo­wa­ną w niej logi­kę (np. biz­ne­so­wą). Poziom abs­trak­cji mode­lu nie ma tu żad­ne­go zna­cze­nia, bo jeże­li obiekt fak­tu­ra ​„liczy VAT” to gdzieś to, jak nale­ży ten VAT wyli­czać, nale­ży w pro­jek­cie ​„umie­ścić”, np. w ope­ra­cji ​„wyliczVAT”. Tak więc ​„dia­gram klas bez ope­ra­cji” to kla­sycz­ny antyw­zo­rzec obiek­to­wy o wdzięcz­nej nazwie ​„ane­micz­ny model dzie­dzi­ny”, powo­dy są pro­ste (wytłusz­cze­nie):

Anemiczny model dzie­dzi­ny (ang. Anemic Domain Model): Antywzorzec opi­sa­ny przez Martina Fowlera. W tym przy­pad­ku model dzie­dzi­ny skła­da się z klas z atry­bu­ta­mi bez metod, nie jest więc obiek­to­wy. Logika biz­ne­so­wa prze­nie­sio­na jest do innych klas, któ­re trans­for­mu­ją kla­sy dzie­dzi­ny zmie­nia­jąc ich stan (stąd nazwa Fowlera: skryp­ty trans­ak­cyj­ne). Antywzorzec ten przed­mio­tem wie­lu dys­ku­sji – znacz­na część meto­dyk two­rze­nia opro­gra­mo­wa­nia w Javie (w tym EJB) ope­ru­je na takim mode­lu. Duża część pro­jek­tan­tów prze­no­si też swo­je przy­zwy­cza­je­nia z mode­lo­wa­nia baz danych mode­lu­jąc sys­tem w ten spo­sób. (za Antywzorzec pro­jek­to­wy ? Wikipedia, wol­na ency­klo­pe­dia).

Dodam też, że EJB to tech­no­lo­gia z lat 90-tych (od któ­rej się już odcho­dzi, jako śro­do­wi­sko zosta­ła już tyl­ko JEE z zacho­wa­niem kom­pa­ty­bil­no­ści wstecz, więc ist­nie­nie JavaBeans’ów nie zna­czy, że nadal są sexi)…

Wszystkie aso­cja­cje muszą mieć licz­no­ści i nazwy ról. Po pierw­sze związ­ki logicz­ne to nie tyl­ko aso­cja­cje, bo mogą być tak­że związ­ki ​„uży­cia”. Nazwy ról to ana­chro­nizm rodem z mode­li ERD (mode­le danych rela­cyj­ne), poma­ga cza­sem na dia­gra­mach ale raczej wte­dy gdy obiek­ty, ich nazwy oraz ope­ra­cje ​„są nie­ja­sne”, ale to raczej mówi o tym, że model jest kiep­ski. To, że nota­cja UML ma dzie­siąt­ki ​„faj­nych rze­czy” nie zna­czy, że nale­ży użyć wszyst­kich, umiesz­cza­my na mode­lach ​„to o czym wie­my i chce­my powie­dzieć” a nie ​„wszyst­ko”.

Przypadki uży­cia: dla każ­de­go z akto­rów musi być odręb­ny dia­gram przy­pad­ków uży­cia. Nie mam poję­cia co jest powo­dem takiej nad­mia­ro­wo­ści doku­men­tu. ponad to, takie podej­ście ​„ukry­wa” fakt, że wie­le przy­pad­ków uży­cia może być sko­ja­rzo­nych z tym samym aktorem.

Przypadki uży­cia: nale­ży stwo­rzyć osob­ny dia­gram poka­zu­ją­cy hie­rar­chię dzie­dzi­cze­nia akto­rów. Plączą się ​„porad­ni­ki” opi­su­ją­ce sto­so­wa­nie dzie­dzi­cze­nie pomię­dzy akto­ra­mi, jed­nak to kurio­zum raczej nie da się obro­nić. Aktorzy to byty rze­czy­wi­ste (kon­kret­ne role czy oso­by lub zewnętrz­ne sys­te­my). Budowanie abs­trak­cji czy­li super akto­ra, po któ­rym inny dzie­dzi­czy jest nie­uza­sad­nio­ne, opi­sy­wa­nie tą meto­dą ​„dzie­dzi­cze­nia upraw­nień” jest dla mnie, i nie tyl­ko kolej­nym kurio­zum, bo nie­ste­ty pra­wa dostę­pu nie są dzie­dzi­czo­ne (nie licząc może sza­blo­nów i grup, ale sza­blon to nie aktor) a są nada­wa­ne indy­wi­du­al­nie. Kiepskim pomy­słem jest układ, któ­ry spo­tka­łem na dia­gra­mie ​„pra­cy któ­ra zali­czy­ła”: Administrator dzie­dzi­czy po Użytkowniku. W bez­piecz­nym sys­te­mie Administrator nie powi­nien być ​„bogiem” tyl­ko Administratorem, więc nie może mieć praw do wszyst­kich danych i ope­ra­cji, do któ­rych ma dostęp Użytkownik Systemu, któ­rym ten Administrator admi­ni­stru­je. No i po co osob­ny diagram?

Przypadki uży­cia: dla każ­de­go dia­gram aktyw­no­ści z trze­ma par­ty­cja­mi: Aktor, war­stwa pre­zen­ta­cji, war­stwa logi­ki. Takie kurio­zum plą­cze się w kil­ku porad­ni­kach ale po pierw­sze ​„war­stwa logi­ki” i tak nie zastą­pi nam tu dia­gra­mu sekwen­cji i mode­lu dzie­dzi­ny (te dia­gra­my raczej i tak muszą powstać), a jego war­tość doda­na jest moim zda­niem zero­wa bo nie dość, że jest to nad­mia­ro­wy doku­ment (pamię­ta­my, że dia­gram sekwen­cji i tak powsta­nie) to nie da się na dia­gra­mie aktyw­no­ści poka­zać wewnętrz­nej logi­ki sys­te­mu ina­czej niż abs­trak­cji pod tytu­łem ​„System” czy­li tego co i tak jest na dia­gra­mie przy­pad­ków użycia.

Na zakończenie

Powyższe to tyl­ko przy­kład ​„zada­nia dla stu­den­ta”, takich ​„zadań” i ich zali­czeń znam mul­tum. Ktoś tak ​„wykształ­co­ny” poja­wia się na ryn­ku pra­cy i ma pre­ten­sje, że ma kło­po­ty ze zna­le­zie­niem pra­cy albo na pod­sta­wie dyplo­mu pre­sti­żo­wej uczel­ni zosta­je zatrud­nio­ny, i sie­je spu­sto­sze­nie w pro­jek­tach nie raz ogrom­nej war­to­ści. Jest nie raz gorzej, bo budu­je ste­reo­typ ​„nie­przy­dat­nej i kosz­tow­nej pra­cy ana­li­ty­ka”. Powyższy przy­kład to pra­ca wykła­dow­cy na pre­sti­żo­wej w naszym kra­ju uczel­ni na kie­run­ku Analiza Biznesowa.