Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od dłuż­sze­go cza­su (patrz: pro­jek­to­wa­nie zorien­to­wa­ne na inter­fej­sy). Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. Jest to tak­że opis sty­lu pro­jek­to­wa­nia archi­tek­tu­ry sys­te­mu zorien­to­wa­ne­go na inter­fej­sy (archi­tek­tu­ra zorien­to­wa­na na interfejsy).

Pakiet w UML

W nota­cji UML pakie­ty są ele­men­tem gru­pu­ją­cym, zapew­nia­ją moż­li­wość struk­tu­ry­za­cji i orga­ni­za­cji ele­men­tów mode­li UML. Specjalnym typem pakie­tu jest wła­śnie model :

Pakiet, jako ele­ment gru­pu­ją­cy ele­men­ty, może więc nie tyl­ko repre­zen­to­wać (ozna­czać) abs­trak­cję kom­po­nen­tu, ale tak­że gru­po­wać jego ele­men­ty w repo­zy­to­rium pro­jek­tu UML i opi­sy­wać ich struk­tu­rę: wraz zawar­to­ścią może sta­no­wić model. 

Pakiet jako podsystem

Skorzystała z tego Rebeka Wirfs-Brock, pro­po­nu­jąc bar­dzo uży­tecz­ną konstrukcję:

Skoro więc pakiet może gru­po­wać ​„cokol­wiek”, może więc w szcze­gól­no­ści gru­po­wać ele­men­ty mode­lu­ją­ce np. usłu­gę apli­ka­cji na pozio­mie spe­cy­fi­ka­cji i realizacji. 

Standardowo w UML moż­na, dla usys­te­ma­ty­zo­wa­nia mode­lu i struk­tu­ry repo­zy­to­rium, two­rzyć kon­struk­cje jak poniżej:

Tu war­to zwró­cić uwa­gę na to, że zgod­nie ze sty­lem pro­jek­to­wa­nia zorien­to­wa­ne­go na inter­fej­sy, kla­sy na powyż­szym mode­lu tak­że repre­zen­tu­ją inter­fej­sy, reali­za­cje ich ope­ra­cji to mogą być meto­dy tych klas, albo wywo­ła­nia inter­fej­sów zło­żo­nych komponentów. 

Wirfs-Brock pro­po­nu­je umiesz­cze­nie abs­trak­cyj­ne­go inter­fej­su wewnątrz pakie­tu, któ­ry gra­ficz­nie jest dedy­ko­wa­nym sym­bo­lem dla ste­reo­ty­pu «sub­sys­tem», ta abs­trak­cją może być tak­że ww. przy­pa­dek użycia: 

Standardowy kształt repre­zen­tu­ją­cy pakiet na dia­gra­mach, został podzie­lo­ny na obsza­ry: ope­ra­cje (abs­trak­cyj­ny inter­fejs), spe­cy­fi­ka­cja, reali­za­cja. Główną zale­tą tej kon­struk­cji, w porów­na­niu z ​„tra­dy­cyj­ną”, jest moż­li­wość upo­rząd­ko­wa­nia tre­ści dia­gra­mu i struk­tu­ry repo­zy­to­rium, poprzez umiesz­cze­nie abs­trak­cji spe­cy­fi­ka­cji usłu­gi wewnątrz pakie­tu, któ­ry repre­zen­tu­je tak­że jej reali­za­cję (archi­tek­tu­rę).

W przy­pad­ku gdy uży­je­my tej kon­struk­cji do orga­ni­zo­wa­nia mode­li usług apli­ka­cji (przy­pad­ków uży­cia), wyglą­da to jak na dia­gra­mie powy­żej. Konstrukcji tej moż­na użyć z powo­dze­niem do innych wewnętrz­nych kom­po­nen­tów, dla­te­go mamy do dys­po­zy­cji dodat­ko­wą prze­strzeń na poka­za­nie nazw ope­ra­cji kom­po­nen­tu (pakiet, zgod­nie z MOF, to tak­że klasyfikator). 

W pro­jek­tach reali­zo­wa­nych od ogó­łu do szcze­gó­łu, korzy­sta­nie z tej kon­struk­cji jest to bar­dzo przy­dat­ną meto­dą, bo pozwa­la zade­kla­ro­wać ele­ment mode­lu­ją­cy kom­po­nent, a póź­niej wypeł­nić go tre­ścią, zacho­wu­jąc od począt­ku spój­ną, hie­rar­chicz­ną struk­tu­rę pro­jek­tu i repozytorium. 

Przykład

Przykładowa struk­tu­ra dla dwóch przy­pad­ków uży­cia wyglą­da jak poniżej:

Powyższy sche­mat obra­zu­je struk­tu­rę diagramów:

• dia­gram przy­pad­ków uży­cia to naj­wyż­szy poziom abs­trak­cji: spe­cy­fi­ku­je umo­wą jako listę wyma­ga­nych usług systemu,
• kolej­ny u góry po pra­wej jeden dia­gram, to model archi­tek­tu­ry wyso­kie­go pozio­mu (HLD) tego sys­te­mu, gdzie każ­dy przy­pa­dek uży­cia to osob­ny kom­po­nent (np. mikro­ser­wis) mają­cy swo­ją imple­men­ta­cję, taki model poka­zu­je tak­że wewnętrz­ną inte­gra­cję tych kom­po­nen­tów oraz ewen­tu­al­ną inte­gra­cję z oto­cze­niem (inne systemy),
• każ­dy kom­po­nent, reali­zu­ją­cy okre­ślo­ny przy­pa­dek uży­cia, ma swo­ją odręb­ną wewnętrz­ną archi­tek­tu­rę (LLD).

Powyższe sta­no­wi pro­stą i sku­tecz­ną meto­dę porząd­ko­wa­nia ele­men­tów mode­li, zgod­ną z UML więc nie powin­no być pro­ble­mu z wyko­na­niem takie­go dia­gra­mu, a jak widać nie­któ­re narzę­dzia (tu Visual Paradigm) są do tego przy­go­to­wa­ne. Jeżeli Wasze narzę­dzie nie ofe­ru­je dedy­ko­wa­ne­go pakie­tu w wer­sji pro­po­no­wa­nej przez Wirfs-Brock, porząd­ko­wa­nie archi­tek­tu­ry z pomo­cą pakie­tów uła­twia mode­lo­wa­nie oraz zro­zu­mia­łość mode­li i struk­tu­rę repo­zy­to­rium projektu.

Podsumowanie

Czy ma sens takie mode­lo­wa­nie? Dlaczego nie zacząć od razu kodo­wać? W małym pro­jek­cie zapew­ne było­by to prze­ro­stem for­my nad tre­ścią (ale nie zawsze!). Jednak więk­sze pro­jek­ty reali­zo­wa­ne ​„od razu w kodzie”, mają ogrom­ne pro­ble­my ze spój­no­ścią, sepa­ra­cją domen (dzie­dzi­na sys­te­mu i model poję­cio­wy ) oraz z podej­mo­wa­niem decy­zji w jakiej kolej­no­ści i co ma powsta­wać, bo z zasa­dy nie powsta­nie od razu cały sys­tem (patrz tak­że recen­zja książ­ki: Marsz ku klę­sce).

Do tego nale­ży dodać typo­we obec­nie wyma­ga­nie biz­ne­so­we: nie chce­my i nie może­my cze­kać na ukoń­cze­nie i odda­nie całe­go sys­te­mu, chce­my mieć moż­li­wość jak naj­szyb­sze­go uspraw­nie­nia pra­cy i roz­po­czę­cia korzy­sta­nia z wybra­nych usług sys­te­mu. Pozostałe mogą być wdra­ża­ne w umó­wio­nej kolej­no­ści, wraz z upły­wem cza­su. Więc na pew­no nie może to być monolit.

Jest to moż­li­we pod jed­nym warun­kiem: całość musi zostać podzie­lo­na na odręb­ne i samo­dziel­ne kom­po­nen­ty ​„pierw­sze­go dnia pro­jek­tu”. Innymi sło­wy: pro­jekt zaczy­na­my zawsze od opra­co­wa­nia archi­tek­tu­ry cało­ści sys­te­mu (HLD), a potem kolej­no (ite­ra­cyj­nie) dopra­co­wu­je­my deta­le każ­de­go kom­po­nen­tu (LLD) i dostar­cza­my je klientowi.

Kolejny powód do mode­lo­wa­nia, szcze­gól­nie HLD, to inte­gra­cja. Otóż, jeże­li uznać, że żad­na apli­ka­cja biz­ne­so­wa nie dzia­ła samo­dziel­nie, a zawsze jako ele­ment więk­szej cało­ści, to zna­czy, że: żaden sys­tem ​„nie jest mały”, że jest zawsze czę­ścią nad­rzęd­ne­go sys­te­mu, sys­te­mu wspie­ra­ją­ce­go całą orga­ni­za­cję, jej dostaw­ców i odbior­ców, to zna­czy, że

To zaś ozna­cza, że zawsze nale­ży wyko­nać (mieć) model HLD sys­te­mu całej orga­ni­za­cji. Bez tego nie jest moż­li­wa ana­li­za wpły­wu: na co w fir­mie ma wpływ ten ​„mały” sys­tem, któ­ry wła­śnie wdra­ża­my lub modyfikujemy.

Na koniec cie­ka­we zesta­wie­nie jak ewo­lu­owa­ło podej­ście do pro­jek­to­wa­nia w latach 1990 – 2005. Manifest Agile (Manifesto for Agile Software Development) opu­bli­ko­wa­no w 2001 roku. Po tym cza­sie sygna­ta­riu­sze mani­fe­stu, w swo­ich póź­niej­szych publi­ka­cjach, zaczę­li zwra­cać jed­nak uwa­gę na pro­jek­to­wa­nie archi­tek­tu­ry by uni­kać bała­ga­nu w więk­szych projektach.

Od 2005 roku te meto­dy są dosko­na­lo­ne. Pojawiły się mikro­ser­wi­sy, fala fascy­na­cji poka­za­ła, że nad­mier­ne roz­drab­nia­nie usług wpro­wa­dza cha­os, lekar­stwem mało być Use Case 2.0 . Pojawiają pró­by porząd­ko­wa­nia mikro­se­wi­sów . Jednak chy­ba naj­więk­szy wkład w meto­dy pro­jek­to­wa­nia opar­te na archi­tek­tu­rze ma wła­śnie idea pro­jek­to­wa­nia zorien­to­wa­ne­go na role i odpo­wie­dzial­ność klas .

Dodatek: koniec wodospadów

Nadal bar­dzo czę­sto wie­lu auto­rów przy­po­mi­na i kry­ty­ku­je ​„wodo­spa­do­we” (water­fall) meto­dy wytwa­rza­nia opro­gra­mo­wa­nia, słusz­nie wyty­ka­jąc im nie­efek­tyw­ność i nie­ade­kwat­ność do aktu­al­nej zmien­nej sytu­acji i potrzeb ryn­ku. Podstawą tej kry­ty­ki jest teza, że ana­li­za i pro­jek­to­wa­nie to żmud­ne, szcze­gó­ło­we i dłu­gie pro­jek­to­wa­nie całe­go sys­te­mu. Była by to praw­da, gdy­by ten sys­tem miał być mono­li­tem (zresz­tą decy­zja o pro­jek­to­wa­niu jed­nej rela­cyj­nej bazy SQL dla całej apli­ka­cji to wła­śnie decy­zja o budo­wie monolitu).

Ale ana­li­za i pro­jek­to­wa­nie to fak­tycz­nie nie musi być water­fall i mono­lit. Szybkie (moż­na nawet powie­dzieć, że zwin­ne) two­rze­nie opro­gra­mo­wa­nia, to ana­li­za war­stwy ope­ra­cyj­nej dzia­ła­nia fir­my i szyb­kie mode­lo­wa­nie kom­po­nen­to­wej archi­tek­tu­ry cało­ści apli­ka­cji na pozio­mie HLD. Następnie ite­ra­cyj­nie pro­jek­tu­je­my szcze­gó­ły czy­li archi­tek­tu­rę (wnę­trze) kolej­nych kom­po­nen­tów (LLD) i zle­ca­my ich imple­men­ta­cję. Całość jest prze­wi­dy­wal­na, bo ma mamy obraz cało­ści (HLD to tak­że inter­fej­sy mię­dzy kom­po­nen­ta­mi) i moż­li­wa jest wyce­na fixed-pri­ce, kolej­ne kro­ki to, w usta­lo­nej kolej­no­ści zależ­nej od potrzeb biz­ne­so­wych Zamawiającego, imple­men­ta­cja i odda­wa­nie do użyt­ku kolej­nych usłu­gi apli­ka­cji (kom­po­nen­tów):

Więc duży pro­jekt i pro­jek­to­wa­nie poprze­dza­ją­ce wdro­że­nie to nie jest żaden mono­lit. Nie ma tu pro­jek­tu żad­nej cen­tral­nej bazy danych, nie ma pro­jek­to­wa­nia deta­li cało­ści na samym począt­ku. Każdy kom­po­nent ​„żyje wła­snym życiem” czy­li mamy mikro­ser­wi­sy: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych.

Ostatniego dnia pro­jek­tu mamy dzia­ła­ją­cy sys­tem oraz jego peł­ną i aktu­al­ną dokumentację. 

Dodatek

Źródła