Architektura

Projekty infor­ma­tycz­ne się roz­ra­sta­ją, cała bran­ża ewo­lu­uje. Ostatnie 20 lat doświad­czeń poka­za­ło, że owszem sztu­ką jest stwo­rzyć i wdro­żyć opro­gra­mo­wa­nie, ale jesz­cze więk­szą sztu­ką jest je kon­ser­wo­wać, zmie­niać i roz­wi­jać. Wiele firm bory­ka się z powta­rza­ny­mi dłu­go­trwa­ły­mi i kosz­tow­ny­mi ​„ana­li­za­mi przed­wdro­że­nio­wy­mi” poprze­dza­ją­cy­mi każ­dy kolej­ny pro­jekt wdra­ża­nia zmian. To sku­tek bra­ku aktu­al­nej doku­men­ta­cji posia­da­ne­go sys­te­mu. To jak pla­no­wa­nie nowej budo­wy w mie­ście nie mając aktu­al­nych pla­nów urba­ni­stycz­nych tego mia­sta: każ­dy nowy pro­jekt to ponow­ne doku­men­to­wa­nie sta­nu obec­ne­go, tyl­ko dla­te­go, że ktoś nie udo­ku­men­to­wał zmian wpro­wa­dzo­nych ostat­nim razem (być może poprzed­nio udo­ku­men­to­wał jakiś stan zasta­ny, jed­nak nie aktu­ali­zo­wał tej doku­men­ta­cji). Podobno deve­lo­per pamię­ta co mają jego klien­ci, jed­nak zmia­na deve­lo­pe­ra sta­je się wte­dy trud­na, a nie raz nie­moż­li­wa z powo­du złej umo­wy (pra­wo autor­skie) i bra­ku doku­men­ta­cji (wie­dza w gło­wach pro­gra­mi­stów, wdro­że­niow­ców, bywa, że nigdzie), to efekt zna­ny jako ven­dor lock-in.

Rozwiązaniem jest doku­men­ta­cja sys­te­mu. Co jest głów­nym wyzwa­niem w two­rze­niu doku­men­ta­cji sys­te­mu? Ustalenie kom­pro­mi­su mię­dzy szcze­gó­ło­wo­ścią doku­men­ta­cji a cza­sem i kosz­tem jej opra­co­wa­nia a potem aktu­ali­za­cji. Tym kom­pro­mi­sem jest archi­tek­tu­ra: struk­tu­ra opi­su­ją­ca co i do cze­go słu­ży: ele­men­ty sys­te­mu i ich wza­jem­ne powią­za­nia, ale bez anga­żo­wa­nia się w doku­men­to­wa­nie deta­li tych ele­men­tów (her­me­ty­za­cja). To dla­te­go bar­dzo przy­dat­ne jest kom­po­nen­to­we podej­ście do pro­jek­to­wa­nia i obiek­to­wy para­dyg­mat two­rze­nia opro­gra­mo­wa­nia.

Dzisiaj kil­ka słów o trzech książ­kach, każ­da z nich była na tym blo­gu krót­ko recen­zo­wa­na, razem sta­no­wią moim zda­niem pod­sta­wo­wy zestaw pro­jek­tan­ta. Pod poję­ciem pro­jek­to­wa­nia rozu­mie­my two­rze­nie pro­jek­tu sys­te­mu czy­li doku­men­to­wa­nie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książ­ka to rodzaj pod­su­mo­wa­nia. We wstę­pie czytamy:

„Architektura opro­gra­mo­wa­nia – kon­cep­cyj­ny klej, któ­ry spa­ja każ­dą fazę pro­jek­tu, dla jego wie­lu inte­re­sa­riu­szy – jest powszech­nie uzna­wa­na za kry­tycz­ny ele­ment współ­cze­sne­go roz­wo­ju opro­gra­mo­wa­nia. Praktycy coraz czę­ściej prze­ko­nu­ją się, że poświę­ca­nie szcze­gól­nej uwa­gi archi­tek­tu­rze sys­te­mu opro­gra­mo­wa­nia przy­no­si wymier­ne korzy­ści. Bez archi­tek­tu­ry, któ­ra jest odpo­wied­nia dla roz­wią­zy­wa­ne­go pro­ble­mu, pro­jekt będzie się poty­kał, a naj­praw­do­po­dob­niej zakoń­czy się nie­po­wo­dze­niem. Ale nawet przy dosko­na­łej archi­tek­tu­rze, jeśli nie jest ona dobrze rozu­mia­na i prze­ka­zy­wa­na, pro­jekt ma małe szan­se powodzenia. 

Książka Documenting Software Architectures, dostar­cza naj­bar­dziej kom­plet­nych i aktu­al­nych wska­zó­wek, nie­za­leż­nie od języ­ka czy nota­cji, jak ująć archi­tek­tu­rę w powszech­nie zro­zu­mia­łej for­mie. Bazując na swo­im boga­tym doświad­cze­niu, auto­rzy naj­pierw poma­ga­ją zde­cy­do­wać, jakie infor­ma­cje nale­ży udo­ku­men­to­wać, a następ­nie, za pomo­cą wska­zó­wek i przy­kła­dów (w róż­nych nota­cjach, w tym UML), poka­zu­ją, jak wyra­zić archi­tek­tu­rę, aby inni mogli na jej pod­sta­wie z powo­dze­niem budo­wać, uży­wać i utrzy­my­wać sys­tem. Książka zawie­ra zasa­dy two­rze­nia solid­nej doku­men­ta­cji, cele i stra­te­gie doku­men­ta­cji, wido­ki i sty­le archi­tek­to­nicz­ne, doku­men­ta­cję inter­fej­sów opro­gra­mo­wa­nia i zacho­wa­nia opro­gra­mo­wa­nia oraz sza­blo­ny do zbie­ra­nia i orga­ni­zo­wa­nia infor­ma­cji w celu stwo­rze­nia spój­ne­go pakietu. 

Zdaniem auto­rów klu­czem są poję­cia: ele­ment sys­te­mu, jego cechy i związ­ki mię­dzy tymi ele­men­ta­mi. Zwracają uwa­gę na to, że zwią­zek mię­dzy ele­men­ta­mi to ich wza­jem­ne wywo­ły­wa­nie się (współ­pra­ca to nie rela­cje a uży­cie). Mając model poja­wia się dru­ga waż­na rzecz: adre­sa­ci infor­ma­cji czy­li per­spek­ty­wy opi­su sys­te­mu. Dlatego kolej­na istot­na rzecz to treść i for­ma pre­zen­to­wa­nia kontekstu. 

Kolejna książ­ka to Architektura Oprogramowania w Praktyce . Ze wstęu: ​„Wielokrotnie nagra­dza­na i cie­szą­ca się dużym zain­te­re­so­wa­niem Architektura opro­gra­mo­wa­nia w prak­ty­ce, wyda­nie trze­cie, zosta­ła zna­czą­co zmie­nio­ne, aby odzwier­cie­dlić naj­now­sze osią­gnię­cia w tej dzie­dzi­nie. W książ­ce po raz kolej­ny przed­sta­wio­no kon­cep­cje i naj­lep­sze prak­ty­ki archi­tek­tu­ry opro­gra­mo­wa­nia – struk­tu­rę sys­te­mu opro­gra­mo­wa­nia oraz spo­sób, w jaki jego ele­men­ty mają ze sobą współdziałać. 

W tym wyda­niu auto­rzy sku­pi­li się na kon­cep­cji roz­wo­ju archi­tek­tu­ry. Każdy cykl roz­wo­ju poka­zu­je, w jaki spo­sób archi­tek­tu­ra wpły­wa na okre­ślo­ny kon­tekst, w któ­rym odgry­wa klu­czo­wą rolę, oraz jak jest kształ­to­wa­na przez ten kon­tekst. Konteksty te obej­mu­ją śro­do­wi­sko tech­nicz­ne, cykl życia pro­jek­tu, pro­fil biz­ne­so­wy orga­ni­za­cji oraz prak­ty­ki zawo­do­we archi­tek­ta. Autorzy znacz­nie roz­sze­rzy­li tak­że omó­wie­nie atry­bu­tów jako­ści, któ­re pozo­sta­ją cen­tral­nym ele­men­tem ich filo­zo­fii archi­tek­tu­ry – każ­de­mu z atry­bu­tów poświę­ci­li cały roz­dział – oraz roz­sze­rzy­li omó­wie­nie wzor­ców architektonicznych.” 

Autorzy cie­ka­wie pre­zen­tu­ją to jak i po co powsta­je doku­men­ta­cja: pro­ce­so­wo. Streszczają (pre­zen­tu­ją) treść książ­ki w posta­ci kil­ku pro­stych mode­li procesów:

Ta for­ma bar­dzo mi się spodo­ba­ła: poka­zu­je bodź­ce, model (arti­fact) logi­ki i efekt uzy­ska­ny. Generalnie auto­rzy w swo­jej książ­ce pre­zen­tu­ją prak­tycz­ne aspek­ty doku­men­to­wa­nia opro­gra­mo­wa­nia i sto­so­wa­nia tej doku­men­ta­cji. Pamiętajmy tak­że, że doku­men­ta­cja opro­gra­mo­wa­nia to przede wszyst­kim jego modele. 

Na koniec zosta­wi­łem książ­kę naj­star­szą: Large-Scale Software Architecture .

Jak piszą auto­rzy, celem pro­jek­to­wa­nia (doku­men­to­wa­nia) archi­tek­tu­ry dużych apli­ka­cji jest uchwy­ce­nie i opi­sa­nie prak­tycz­nych metod jego zobra­zo­wa­nia (udo­ku­men­to­wa­nia), mają­cych na celu zwięk­szyć efek­tyw­ność komu­ni­ka­cji zespo­łów pro­gra­mi­stów i ich zro­zu­mie­nia kon­tek­stu systemu.

W tej książ­ce auto­rzy poka­zu­ją, jak wyko­rzy­stać archi­tek­tu­rę opro­gra­mo­wa­nia już jako narzę­dzie na eta­pie zarzą­dza­nia roz­wo­jem apli­ka­cji, nie tyl­ko jako powy­ko­naw­czą doku­men­ta­cję po pod­ję­ciu wszyst­kich decy­zji pro­jek­to­wych. Prezentują w swo­jej książce:

• Zwięzły opis wyko­rzy­sta­nia języ­ka UML w archi­tek­tu­rze dużych aplikacji, 
• Architekturę opro­gra­mo­wa­nia i zasa­dy jej projektowania,
• Zwracają uwa­gę na jej nie­za­leż­ność od tech­no­lo­gii i dostawców.

Tę książ­kę moż­na pod­su­mo­wać tak: każ­da archi­tek­tu­rę nale­ży doku­men­to­wać od ogó­łu do szcze­gó­łu, każ­dy model powi­nien być pro­sty i zwię­zły ale mode­li tych może być wie­le, każ­dy sys­tem to jego klu­czo­wa rola, jego wewnętrz­na struk­tu­ra i zacho­wa­nia jego skła­do­wych ele­men­tów oraz jego poję­cio­wy dzie­dzi­no­wy ogól­ny opis. 

Podsumowanie

Powyższe opi­sy to klu­czo­we cechy każ­dej z tych trzech pozy­cji. Moją inten­cją było pole­ce­nie tych trzech pozy­cji jako zesta­wu pre­zen­tu­ją­ce­go dość kom­plet­ną wie­dzę na temat sta­nu wie­dzy na temat pro­jek­to­wa­nia opro­gra­mo­wa­nia sku­pia­ją­ce­go się na jego archi­tek­tu­rze. Jako efekt uzy­sku­je­my doku­men­ta­cję rela­tyw­nie szczu­płą obję­to­ścio­wo, więc będzie czy­ta­na. Stosowanie stan­dar­du nota­cyj­ne­go, jakim jest UML, uzy­sku­je­my sze­ro­ki zasięg odbior­ców i uni­wer­sal­ność. Zwracają na to uwa­gę auto­rzy wszyst­kich tych trzech pozycji. 

Ostatnia pozy­cja to kla­sy­ka kom­po­nen­to­we­go podej­ścia do pro­jek­to­wa­nia. Pierwsze dwie powsta­ły kil­ka lat po fascy­na­cji auto­rów zwin­nym podej­ściem (agi­le). Podobnie jak Scott Ambler , odkry­li że zbyt­nie przy­kła­da­nie wagi do ​„dzia­ła­ją­ce­go opro­gra­mo­wa­nia” na nie­ko­rzyść jego doku­men­ta­cji, powo­du­je szko­dy na kolej­nych eta­pach cyklu życia pro­duk­tu jakim jest aplikacja. 

Żadne opro­gra­mo­wa­nie nie powsta­je tyl­ko na jeden dzień, będzie komuś słu­ży­ło mie­sią­ca­mi, lata­mi, a świat nie stoi w miej­scu. sta­wia­nie tezy, że celem two­rze­nia opro­gra­mo­wa­nia jego powsta­nie jest szko­dli­we. Kluczem jest cykl życia opro­gra­mo­wa­nia, a jego doku­men­ta­cja to jedy­na for­ma komu­ni­ko­wa­nia się zmie­nia­ją­cych się osób, lata­mi zaan­ga­żo­wa­nych w utrzy­ma­nie i roz­wój aplikacji. 

Te trzy książ­ki to moim zda­niem mały zbiór rze­tel­nej wie­dzy, któ­ry powi­nien pomóc każ­de­mu począt­ku­ją­ce­mu i zagu­bio­ne­mu ​„junio­ro­wi ana­li­zy biz­ne­so­wej” w nauce two­rze­nia wyso­kiej jako­ści doku­men­ta­cji. To tak­że wie­dza przy­dat­na dla doświad­czo­nych ana­li­ty­ków i pro­jek­tan­tów: zawsze war­to wie­dzieć jak robią to inni, mają­cy ogrom­ny doro­bek. Dokumentacja sys­te­mu to jedy­ne trwa­łe źró­dło wie­dzy o nim, jed­nak zła i nie­ak­tu­al­na doku­men­ta­cja jest gor­sza od jej braku… 

Źródła