Często spo­ty­kam się z czymś takim jak ​„Diagramy klas (UML) to mode­lo­wa­nie wyma­gań z per­spek­ty­wy danych (model danych)”. Jest to nie­ste­ty dość czę­sto spo­ty­ka­na ​„here­zja”, tak­że w zale­ca­nej przez wie­lu lite­ra­tu­rze, o czym swe­go cza­su wspominałem:

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 w nota­cji UML. Do mode­lo­wa­nia danych uży­wa­my nota­cji ERD (ang. Entity Relationship, 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 UML w mode­lo­wa­niu danych). Źródło: Business Analysis ? dia­gram klas UML i bazy danych | Jarosław Żeliński IT-Consulting

Przypomnę po raz kolej­ny czym jest obiek­to­wy para­dyg­mat ana­li­zy i projektowania:

Paradygmat obiek­to­wy ana­li­zy i pro­jek­to­wa­nia to uzna­nie, że ana­li­zo­wa­ny lub pro­jek­to­wa­ny sys­tem to współ­pra­cu­ją­ce w okre­ślo­nym celu obiekty. 

Definicja ta jest zbież­na z defi­ni­cją poję­cia sys­tem: zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków i rela­cji) mię­dzy nimi (Sienkiewicz, 1994).

Innymi sło­wy sys­tem, w rozu­mie­niu ogól­nej teo­rii sys­te­mów (UML i meto­dy obiek­to­we wspie­ra­ją wła­śnie tę teo­rię), sys­tem to zbiór współ­pra­cu­ją­cych obiek­tów. Nie ma tu żad­nej mowy o danych. Dlaczego? Bo współ­pra­cu­ją ze sobą obiek­ty a nie dane. Owszem, dys­po­nu­je­my nimi, ale … Każdy zespół współ­pra­cu­ją­cych ludzi nie­wąt­pli­wie wyko­rzy­stu­je, a nie raz prze­twa­rza, okre­ślo­ne infor­ma­cje. Jednak ta współ­pra­ca pole­ga na współ­pra­cy, infor­ma­cje są wymie­nia­ne na okre­ślo­nych nośni­kach, to obiek­ty biz­ne­so­we. Np. celem nego­cja­cji jest współ­pra­ca nego­cja­to­rów i pod­pi­sa­na umo­wa (jej treść to szcze­gó­ły przy­da­ne w spo­rze oraz cel zawar­cia umo­wy), celem sprze­da­ży jest przy­chód (a nie fak­tu­ra), celem dosta­wy jest towar w okre­śla­nym miej­scu i cza­sie (list prze­wo­zo­wy wska­zu­je miej­sce i czas, doku­ment WZ to tyl­ko spe­cy­fi­ka­cja kon­kret­ne­go przed­mio­tu tej dosta­wy) itd.

Popatrzmy na jeden z wie­lu szkie­le­tów tak zwa­nej archi­tek­tu­ry biz­ne­so­wej (archi­tek­tu­ra biz­ne­so­wa, archi­tek­tu­ra korporacyjna):

(źr. https://it-consulting.pl//2014/10/07/wstep-do-architektury-biznesowej/)

Ma ona, każ­da orga­ni­za­cja, przede wszyst­kim cele. By mogła je reali­zo­wać ma: fasa­dę (tak się obja­wia na zewnątrz), wewnętrz­ne pro­ce­sy biz­ne­so­we, meto­dy komu­ni­ka­cja (z oto­cze­niem), oraz ​„enti­ties” (nie mylić z mode­lem rela­cyj­nym danych) czy­li obiek­ty biz­ne­so­we, to co jest ​„mię­sem” cało­ści, bo to one ze przed­mio­tem współ­pra­cy i nio­są infor­ma­cje. Każda orga­ni­za­cja to sys­tem zło­żo­ny ze współ­pra­cu­ją­cych ele­men­tów: tych nio­są­cych infor­ma­cje i tych mają­cych wie­dzę o mecha­ni­zmach (logi­ce) tej współpracy.

Kolejna waż­na rzecz to zauwa­że­nie, że opro­gra­mo­wa­nie to narzę­dzie pra­cy. Część (rzad­ko kie­dy wszyst­kie) obiek­tów biz­ne­so­wych (są nimi doku­men­ty i ich treść) będzie mia­ła swo­je wer­sję elek­tro­nicz­ną, co jed­nak nie zmie­nia fak­tu, że to jedy­na zmiana!

Tak więc kil­ka słów o wyma­ga­niach na narzę­dzie pra­cy. Oprogramowanie to narzę­dzie pra­cy, wyra­fi­no­wa­ne ale jed­nak tyl­ko narzę­dzie, któ­re jest deter­mi­ni­stycz­ne, czy­li 100% zacho­wań tego opro­gra­mo­wa­nia jest prze­wi­dy­wal­na i zosta­ła z góry okre­ślo­na. Te zacho­wa­nia to nic inne­go jak nasze wyma­ga­nia wobec tego narzę­dzia pra­cy. Skoro jest to narzę­dzie, to wyma­ga­nia są opi­sem tego narzę­dzia. I tu zaczy­na się ​„zaba­wa”, bo jed­nak nie dzia­ła ​„kla­sycz­ne” i ana­chro­nicz­ne już moim zda­niem, zesta­wie­nie wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne (to podział z lat 80-tych). Tu przy­po­mnę, że mło­tek może mieć kil­ka­na­ście cech, któ­re moż­na nazwać funk­cjo­nal­ny­mi i poza-funk­cjo­nal­ny­mi, co nie zmie­nia fak­tu, że gene­ral­nie słu­ży wyłącz­nie do ude­rza­nia w coś (świad­czy jed­ną usłu­gę), jest to przy­pa­dek uży­cia: ude­rzyć w coś. Stan począt­ko­wy: wie­my w co ude­rzyć i po co (z jaką siłą), stan koń­co­wy to efekt pożą­da­ny (np. wbi­ty gwóźdź). Panuje moda na nazy­wa­nie przy­pad­ka­mi uży­cia kon­tek­stu z per­spek­ty­wy akto­ra, było by więc: uderz w gwoźdź, uderz w ścia­nę, uderz w oso­bę, uderz w szy­bę, uderz w stół sła­bo, uderz w pły­tę chod­ni­ko­wą moc­no, i tak mozna w nie­skoń­czo­ność jak tyl­ko np. nie prze­rwie­my tak zwa­nych ​„warsz­ta­tów zbie­ra­nia wyma­gań”. To, takie podej­ście, nie ma więk­sze­go sen­su, bo zamu­la deve­lo­pe­ra nad­mia­rem infor­ma­cji i nic nie mówi o kon­struk­cji młotka.

Bardziej wyra­fi­no­wa­na usłu­gą będzie zarzą­dza­nie dany­mi kon­tak­to­wy­mi. Mamy więc szaf­kę, szu­fla­dy, a w nich kar­to­te­ki z dany­mi kon­tak­to­wy­mi. Jest to narzę­dzie pra­cy, całość – szaf­ka i jej zawar­tość – to ​„mar­twa natu­ra”, któ­rej użyt­kow­nik (aktor) uży­wa w sobie tyl­ko zna­nym kon­tek­ście. Może nim być zapa­mię­ty­wa­nie adre­sów dostaw­ców, odbior­ców, poten­cjal­nych klien­tów, itp. Z uwa­gi na to, że ma być postęp, opi­su­je­my tę szaf­kę razem z archi­wi­stą (opro­gra­mo­wa­nie zastą­pi część jego pra­cy), któ­ry zarzą­dza dostę­pem do niej. Czy kar­ta kata­lo­go­wa wie do cze­go jest uży­wa­na? Nie. Czy cel uży­cia cokol­wiek zmie­nia w kon­struk­cji tego mebla i jego zawar­to­ści? Nie. Więc co? Tu obiek­tem biz­ne­so­wym będzie nośnik danych kon­tak­to­wych, jed­nak to my decy­du­je­my co i po co zapi­su­je­my a nie szaf­ka, archi­wi­sta też nie wni­ka w treść. Owszem, wygod­nie będzie opra­co­wać jed­na­ko­wy sza­blon na te dane, nadal nie zmie­nia to fak­tu, że będzie­my zazna­cza­li np. w polu ​„typ adre­su” jakimś sło­wem czy dany adres to dostaw­ca, odbior­ca, czy może zain­te­re­so­wa­ny poten­cjal­ny klient.

Co tu jest wyma­ga­niem? Zamawiając elek­tro­nicz­ną wer­sje kar­to­tek, powie­my co nie­co o łatwo­ści dostę­pu, o wyszu­ki­wa­niu, o kon­tro­li dostę­pu, i gdzieś na koń­cu przy­to­czy­my wzór kar­ty kata­lo­go­wej. Dodamy regu­ły biz­ne­so­we (zastą­pi­my archi­wi­stę), np. dane jed­nej oso­by powin­ny być tyl­ko na jed­nej kar­cie (brak duble­tów) a świa­dec­twem uni­kal­no­ści będzie zgod­ność imie­nia, nazwi­ska i kodu pocz­to­we­go (są też inne pomy­sły). Inną regu­łą może być zakaz nisz­cze­nia kart, żąda­nie nie­kon­tak­to­wa­nia się może być reali­zo­wa­ne dodat­ko­wym zapi­sem ​„nie dzwo­nić”, nasze opro­gra­mo­wa­nie przej­mie na sie­bie pro­ce­du­ry reali­zo­wa­ne przez archiwistę.

Czy mamy tu jakąś ​„per­spek­ty­wę danych sys­te­mu”? Gdybyś my mie­li doce­lo­wo stwo­rzyć opro­gra­mo­wa­nie w mode­lu ​„dane + funk­cje = pro­gram” to tak, ale my mówi­my o obiek­to­wych meto­dach ana­li­zy i pro­jek­to­wa­nia, mówi­my o tym dekla­ru­jąc uży­cia nota­cji UML (jest obiek­to­wa). Każda więk­sza apli­ka­cja to wie­le takich osob­nych sza­fek na doku­men­ty, wie­le reguł biz­ne­so­wych powią­za­nych z doku­men­ta­mi, cały­mi szaf­ka­mi, oraz mecha­ni­zmy ope­ro­wa­nia tymi doku­men­ta­mi w kon­kret­nych celach. Czy ma tu jaki­kol­wiek sens ​„wycią­ga­nie” tego, że adres kore­spon­den­cyj­ny pod­mio­tu powta­rza się w róż­nych kon­tek­stach na więk­szo­ści tych doku­men­tach? Czy ma sens wycią­ga­nie ​„na wierzch” tego, że poło­wa doku­men­tów zawie­ra coś takie­go jak ​„pro­dukt”. Nie ma to żad­ne­go sen­su, bo po pierw­sze te szaf­ki i kar­to­te­ki, każ­da żyje wła­snym życiem i nie zmie­ni­my tego, w każ­dej chwi­li może nam dojść nowa szaf­ka z nowy­mi papie­ra­mi, a sta­ra znik­nąć gdy sta­nie się nie­po­trzeb­na. Może nam się przy­tra­fić rezy­gna­cja z szaf­ki na rzecz korzy­sta­nia z usłu­gi biu­ra nume­rów na tele­fon. Takich sytu­acji nie tyl­ko nie jeste­śmy w sta­nie prze­wi­dzieć, może­my nie mieć moż­li­wo­ści prze­ciw­dzia­ła­nia temu (np. zmia­ny w prawie).

Obiektowe podej­ście uwa­la­nia nas od zaj­mo­wa­nia się osob­no ​„wspól­ny­mi dany­mi”, powiem wręcz, podej­ście takie – usu­wa­nie redun­dan­cji i współ­dzie­le­nie – jest wręcz szko­dli­we, ​„Perspektywa danych” to struk­tu­ral­ne a nie obiek­to­we podej­ście, nie ma w nim nic złe­go ale nie mie­szaj­my tego. Pisałem o tym:

Metody struk­tu­ral­ne to roz­kła­da­nie pro­ble­mu biz­ne­so­we­go na oddzie­lo­ne od sie­bie dane i pro­ce­du­ry ich prze­twa­rza­nia. Informacje o obiek­tach rze­czy­wi­stych są tra­co­ne w tych meto­dach. Model rela­cyj­ny danych to model, w któ­rym utra­co­no wie­le infor­ma­cji, np. nie da się z mode­lu rela­cyj­ne­go odtwo­rzyć np. fak­tu­ry nie wie­dząc jak ona wyglą­da. Do wydru­ku fak­tu­ry potrzeb­ne jest zapy­ta­nie, któ­re wycią­gnie z bazy danych wła­ści­we dane i pro­ce­du­ra któ­ra wła­ści­wie je sfor­ma­tu­je. Metody obiek­to­we pole­ga­ją na wier­nym mode­lo­wa­niu (odwzo­ro­wa­niu) ś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. Ź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

Czy mamy więc jakieś per­spek­ty­wy w mode­lach obiek­to­wych? W zasa­dzie tyl­ko dwie:

- przy­pad­ki uży­cia (dia­gram przy­pad­ków uży­cia) i sko­ja­rzo­ne z każ­dym z nich sce­na­riu­sze, jako opi­sy tego jak sys­tem ma się zacho­wać w odpo­wie­dzi na pró­bę jego użycia,

- struk­tu­ra wewnętrz­na tego sys­te­mu (model dzie­dzi­ny sys­te­mu – dia­gram klas) , odwzo­ro­wu­ją­ca ​„współ­pra­cu­ją­ce obiek­ty”, jest to opis mecha­ni­zmu dzia­ła­nia tego sys­te­mu (blo­ki funk­cjo­nal­ne, obiek­ty i komponenty).

Czy ma sens two­rze­nie zamó­wie­nia na szaf­ki do kar­to­tek wysy­ła­jąc tyl­ko zdję­cie stro­ny czo­ło­wej wraz z dzie­siąt­ka­mi stron opo­wie­ści o tym jak do tej pory ich uży­wa­no? Jest to bar­dzo ryzy­kow­ne podej­ście. Duże bez­piecz­niej jest zapro­jek­to­wać kon­struk­cję takiej szaf­ki, wska­zu­jąc gdzie jakie zam­ki i blo­ka­dy chce­my mieć i dać taki pro­jekt do wyko­na­nia. Owszem nie ma sen­su odbie­ra­nie chle­ba inży­nie­rom, pisa­nie z jakich mate­ria­łów to ma być zro­bio­ne i jaki­mi tech­ni­ka­mi wyko­na­ne i zabez­pie­czo­ne. Ale wewnętrz­ne, ​„czy­sto biz­ne­so­we” szcze­gó­ły takie jak podział na szu­fla­dy, wzo­ry kar­to­tek, wymóg moż­li­wo­ści ich mody­fi­ka­cji, kon­tro­la dostęp do szu­flad, owszem: to war­to opi­sać same­mu (lub zatrud­nić projektanta).

Wiele ksią­żek zawie­ra opis tak zwa­ne­go wido­ku 4+1 Kruchtena. Co tam mamy? To jeden z wie­lu dostęp­nych w sie­ci opisów:

• per­spek­ty­wa logi­ki biz­ne­su ? ist­nie­je w każ­dym sys­te­mie infor­ma­tycz­nym i uka­zu­je róż­ne ele­men­ty sys­te­mu infor­ma­tycz­ne­go w kon­tek­ście logi­ki biz­ne­su, takie jak kla­sy, pakie­ty itp.;

• per­spek­ty­wa pro­ce­sów ? opi­su­je wszyst­ko co jest zwią­za­ne z współ­bież­no­ścią pra­cy SI, naj­czę­ściej opi­su­je komu­ni­ka­cję i syn­chro­ni­za­cję róż­nych kom­po­nen­tów sys­te­mu i z regu­ły doty­czy sys­te­mów roz­pro­szo­nych i/lub współbieżnych;

• per­spek­ty­wa imple­men­ta­cji ? opi­su­je spo­sób imple­men­ta­cji ele­men­tów skła­do­wych sys­te­mu, z regu­ły jest to sta­tycz­ny opis skła­do­wych ele­men­tów sys­te­mu w jego fizycz­nym śro­do­wi­sku (dewe­lo­per­skim, a doce­lo­wo produkcyjnym);

• per­spek­ty­wa wdro­że­nia ? opi­su­je spo­sób fizycz­ne­go kopio­wa­nia i wdra­ża­nia róż­nych ele­men­tów SI, spo­sób ich komu­ni­ko­wa­nia się w kon­tek­ście ich fizycz­ne­go roz­lo­ko­wa­nia na doce­lo­wej plat­for­mie informatycznej;

• per­spek­ty­wa przy­pad­ków uży­cia ? opi­su­je naj­bar­dziej zna­czą­ce wyma­ga­nia SI dla użyt­kow­ni­ków koń­co­wych, czy­li te przy­pad­ki uży­cia lub ich czę­ści, któ­re wywie­ra­ją naj­więk­szy wpływ na archi­tek­tu­rę i są naj­bar­dziej kry­tycz­ne do zobra­zo­wa­nia mecha­ni­zmów dzia­ła­nia systemu.

Wystarczy porów­nać to z moim opi­sem powy­żej, by zauwa­żyć, że powyż­sze to zbęd­ne kom­pli­ko­wa­nie cało­ści i nie­po­trzeb­ne wpla­ta­nie kon­tek­stu biz­ne­so­we­go (mło­tek nie wie w jakim celu jest używany).

Implementacja to pra­ca dla deve­lo­pe­ra a mie­sza­nie w to póź­niej­sze­go wdro­że­nia już zupeł­nie pomie­sza­nie celów spe­cy­fi­ko­wa­nia wymagań.

Przypadki uży­cia to zewnętrz­ne (widzia­ne przez jego użyt­kow­ni­ka) cechy sys­te­mu. Używanie sło­wa ​„pro­ces” do tego co w UML nazy­wa się ​„sekwen­cja” powo­du­je tyl­ko nie­po­ro­zu­mie­nia, tu każ­dy przy­pa­dek uży­cia jest reali­zo­wa­ny z uży­ciem wewnętrz­nych kom­po­nen­tów, jest to logi­ka biz­ne­so­wa (mecha­nizm dzia­ła­nia) czy­li i model dzie­dzi­ny. Nie przy­pad­kiem klu­czo­wą cecha obiek­to­we­go podej­ścia jest her­me­ty­za­cja czy­li ukry­wa­nie wnę­trza kom­po­nen­tów (do same­go koń­ca). Najpierw ana­li­zu­je­my i doku­men­tu­je­my do cze­go słu­ży fak­tu­ra, a na koń­cu (mają kom­plet­ny pro­jekt) upew­nia­my się (testu­je­my), że każ­dy kom­po­nent dys­po­nu­je wie­dzą potrzeb­ną mu do reali­za­cji przy­pad­ku uży­cia. Na samym koń­cu jest mowa o danych, i nie jako odręb­nej per­spek­ty­wie, a jako wewnętrz­nych cechach (atry­bu­tach) kom­po­nen­tów. Tu dopie­ro defi­niu­je­my ewen­tu­al­ne zawar­to­ści doku­men­tów repre­zen­to­wa­nych w mode­lu dzie­dzi­ny przez odręb­ne kom­po­nen­ty. I abso­lut­nie nie uwspól­nia­my (nie nor­ma­li­zu­je­my, nie pozby­wa­my się redun­dan­cji) na co zwró­ci­łem uwa­gę na początku.

Nie powin­ni­śmy zapo­mi­nać, że model Kruchtena to poło­wa lat 90-tych, szczyt roz­kwi­tu metod struk­tu­ral­nych i racz­ku­ją­ce meto­dy i narzę­dzia obiek­to­we. To sta­re sys­te­my i ich rela­cyj­ne bazy danych wymu­si­ły sto­so­wa­nie [[mapo­wa­nia ORM]] i takich narzę­dzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tam­tej pory minę­ło 20 lat. Nie musi­my się cofać do począt­ków inży­nie­rii opro­gra­mo­wa­nia w wer­sji obiek­to­wej. Coś takie­go jak per­spek­ty­wa danych to ana­chro­nizm. Podejście to w 100% zosta­ły już daw­no zastą­pio­ne przez MDA. Ale o tym już tu pisałem 😉