Unified Modeling Language je v programátorskom svete vnímaný rôzne. Jedna skupina programátorov využíva UML ako vhodný nástroj na vizualizáciu softvéru, druhá skupina programátorov ho zaznáva ako zbytočný formalizmus.
A obe skupiny majú pravdu: UML je dobrý sluha, ale zlý pán.
Vizualizácia zložitého systému
Vo všetkých komplexných oblastiach sa snažia ľudia nájsť vhodnú vizualizáciu. Grafický diagram dokáže skryť detaily a názorným spôsobom demonštrovať kľúčové vlastnosti systému. Lekári kreslia obehovú sústavu, kostru človeka, dýchaciu sústavu. Stavební architekti kreslia domy ako sústavu viacerých výkresov. Zapojenie elektronických súčiastok na plošnom spoji sa kreslí vo forme zjednodušenej schémy. Dobrá vizualizácia dokáže pri komplexných systémoch poskytnúť viac informácií ako textový popis.
A to je aj vzťah medzi UML diagramom a zdrojovým kódom.
UML je dobrý sluha
Pre veľký softvér je extrémne ťažké udržať nadhľad nad celým kódom – a to najmä v momente, keď zdrojový kód ešte ani neexistuje. Síce nemá význam robiť vizualizáciu zoznamu požiadaviek alebo zoznamu prípadov použitia (use-cases alebo user-stories). Avšak pri objektovo-orientovanom programovaní je diagram tried (class diagram) silnou pomôckou. Vizualizácia má totiž pár podstatných výhod oproti priamemu kódovaniu:
- dá sa rýchlo nakresliť
- dokáže byť zameraná len na to podstatné
- je oveľa lepšie čitateľná
- Bubbles and arrows don’t crash (Bertrand Meyer)
- v kóde nenájdeme architektúru a ani doménu
Dá sa ľahko nakresliť
S vizualizáciou sa dá experimentovať. Diagram tried sa dá rýchlo nakresliť v prvej, druhej, tretej … verzii. Schopnosť dizajnéra rýchlo a bezbolestne zahodiť jeho vlastný návrh je na začiatku vývoja kľúčová. Málokedy dokáže dizajnér na prvý pokus navrhnúť správny dizajn aplikácie. Oveľa lepšie je zahadzovať návrhy na začiatku projektu, než na konci. Na konci vývoja sú náklady na refactoring dizajnu tak obrovské, že sa radšej nerobí. Zdrojový kód tak trpí množstvom barličiek a workaroundov, ktoré si nikto netrúfne zmeniť.
Ak sa vizualizácia vypúšťa a namiesto nej sú vytvárané triedy už vo forme reálneho zdrojového kódu, znižuje to chuť programátora či dizajnéra vykonávať do nich zásadné zásahy.
Dokáže byť zameraná len na to podstatné
Na začiatku návrhu je celkom bežné, že triedy majú iba názvy a definície zodpovedností. Chýbajú im atribúty, respektíve k atribútom chýbajú typy. Dizajnér sa na začiatku návrhu obvykle zameriava na popis triedy v štýle odporúčaní CRC – čiže „Class, Responsibility, Collaboration“.
Implementácia uvedených tried v jazyku Java bude obsahovať veľa „šumu“. Nezaobíde sa bez povinných kľúčových slov ako „import“, „package“, „public“, „class“, nehovoriac o konštruktoroch a prípadných get-metódach, či dokonca implementácii metód „equals“ a „hashcode“. Implementácia rovnakých tried v jazyku UML je zameraná iba na kľúčové vlastnosti tried.
Je oveľa lepšie čitateľná
Z jedného pohľadu na predošlý diagram je možné zistiť, že dizajnér navrhol tri triedy, ktoré sú vzájomne prepojené asociáciami s definovanými kardinalitami. Zápis rovnakých tried v jazyku Java predstavuje tri samostatné súbory. Navyše z pohľadu na súbor „FyzickaOsoba.java“ nebude jasný vzťah tejto triedy k „FakturacnaZlozka“ a už vôbec nie súvislosť s objektom Faktura. Pri rozsiahlejšom systéme už človek nedokáže udržať celý dizajn naraz v hlave.
Bubbles and arrows don’t crash
Vizualizácia nepadá a nehlási kompilačné chyby. Keď sa dizajnér zameriava na zachytenie domény, nemal by riešiť technické detaily svojho návrhu. Hlavne kvôli tomu, že svoj návrh možno napokon zahodí, takže nemá zmysel investovať čas do detailov. Navyše implementačné detaily zneprehľadňujú návrh. Dizajn systému kreslený na začiatku v UML môže byť pripravený efektívnejšie, než keď je dizajn priamo písaný ako zdrojový kód. Ponorenie do zdrojového kódu donúti dizajnéra opustiť široký nadhľad nad systémom a začať riešiť technické problémy.
V kóde nenájdeme architektúru a ani doménu
Architektúra softvéru sa dá iba nakresliť a popísať textom, ale nedá sa zachytiť v žiadnom programovacom jazyku. Zdrojový kód už obsahuje iba dôsledky rozhodnutia softvérového architekta, ale nie architektúru samotnú. V zdrojovom kóde je možné nájsť napríklad volanie REST-ových služieb, z čoho vyplýva, že súčasťou architektúry sú aj REST-ové služby. Ale napríklad odpovede na otázky, ktoré časti aplikácie môžu a ktoré nesmú pristupovať do databázy, v zdrojovom kóde nie sú.
Pri architektúre je vizualizácia nevyhnutný nástroj. Architekt si síce môže vymyslieť svoj vlastný spôsob kreslenia architektúry, ale to už nedáva veľmi zmysel. Preto treba použiť UML – štandardizovaný vizualizačný jazyk.
UML je zlý pán
Problémy s využívaním UML sú nasledovné:
- samotné UML ako jazyk je obrovský
- duplicitná údržba dizajnu v UML a v zdrojovom kóde
- implementačné detaily môžu byť z pohľadu dizajnu rozhodujúce
Samotné UML ako jazyk je obrovský
Naučiť sa celé UML je drina a nedáva to veľmi význam. Treba si z UML vybrať to, čo dizajnér potrebuje. Obvykle sú pre architektúru potrebné komponentové diagramy a deployment diagramy. Pre samotný dizajn treba diagram tried, diagram package-ov a sekvenčný diagram. V istých situáciách je vhodné pomôcť si stavovým diagramom a objektovým diagramom. Vo väčšine prípadov si dizajnér vystačí so základnou znalosťou, pretože ponoriť sa hlbšie do detailov znamená ponoriť sa hlbšie do implementácie.
UML certifikácia trochu vytvára ilúziu o tom, že držiteľ certifikácie je dobrý dizajnér alebo architekt. Asi tak, ako znalosť slovenčiny automaticky implikuje dobrého spisovateľa. UML je iba jazyk.
Duplicitná údržba dizajnu v UML a v zdrojovom kóde
Udržiavať dizajn v UML počas vývoja je skutočne problém. Buď na to dizajnér rezignuje a dizajn ostane len v zdrojovom kóde so všetkými spomínanými negatívami. Alebo akúkoľvek zmenu v triede prácne zanesie aj do UML diagramu. Najefektívnejšia je stredná cesta: z času na čas urobiť review diagramov a upraviť ich v súlade so zdrojovým kódom. Napríklad na konci iterácie, minimálne na konci projektu. Objektové nástroje obvykle ponúkajú aj možnosť spätne načítať zmeny v triede do UML modelu. Túto funkčnosť je vhodné využiť, ak bola do zdrojového kódu pridaná nová trieda, či dokonca celý package.
Implementačné detaily môžu byť z pohľadu dizajnu rozhodujúce
Dizajnér častokrát nedokáže dotiahnuť svoj model v UML do konca. Niektoré rozhodnutia si musí overiť priamo v implementácii, čiže v zdrojovom kóde. Dizajnér teda nesmie byť uzavretý vo svojej UML-bubline bez kontaktu so zdrojovým kódom, ale musí byť takzvaný „hands-on“ – t.j. schopný naprogramovať vlastný návrh. Inak sa z UML stane veľmi zlý pán.
Zhrnutie
UML je vizuálny jazyk určený na zachytenie rôznych pohľadov na softvér. Určite sa veľmi oplatí použiť UML na začiatku vývoja a zakresliť v ňom architektúru a dizajn, ako aj počas vývoja dizajn primeraným spôsobom dopĺňať a meniť. Čím je projekt rozsiahlejší a čím je doména komplikovanejšia, tým viac sa oplatí investovať čas do údržby modelu v UML. Treba si však dať veľký pozor na mieru detailu. Niektoré rozhodujúce nuansy môžu dizajnérovi uniknúť. Ani nie tak kvôli nedostatkom jazyka UML, ale kvôli zložitosti samotného problému.