Čo je UML?

UML je vizuálny jazyk na popis softvérových systémov. Dáva vám pevnú sadu tvarov, čiar a pravidiel, aby diagram, ktorý nakreslíte, znamenal to isté aj pre niekoho, kto nesedel v miestnosti, kde vznikal.

To je celá ponúkaná hodnota a oplatí sa povedať to priamo. Rámček s názvom nie je UML. Rámček s tromi priehradkami, prázdny trojuholník mieriaci na iný rámček a 1..* na jednom konci čiary je UML a hovorí niečo presné: tento typ dedí od tamtoho a jedna inštancia prvého je spojená aspoň s jednou inštanciou druhého. Ktokoľvek, kto pozná notáciu, to prečíta rovnako. To je to, čo si kupujete.

Jazyk udržiava Object Management Group. Aktuálne vydanie je UML 2.5.1, zverejnené v roku 2017. Pochádza z práce, ktorú Grady Booch, James Rumbaugh a Ivar Jacobson zlúčili v Rationale v polovici deväťdesiatych rokov, keď mal odbor zhruba päťdesiat konkurenčných notácií a nijaký spôsob, ako prečítať cudzí návrh. OMG prijala UML 1.1 v roku 1997. Verzia 2.5 bola najmä upratovaním: špecifikácia sa rozpadla na zväzky „infrastructure“ a „superstructure“, v ktorých sa vyznal málokto, a 2.5 ich zložila späť do jedného dokumentu.

Každý diagram UML odpovedá na jednu z dvoch otázok. Diagramy štruktúry odpovedajú na „z čoho sa tento systém skladá?“ - časti, typy, stroje a to, ako sú usporiadané. Popisujú veci, ktoré platia bez ohľadu na čas.

Diagramy správaniaodpovedajú na „čo tento systém robí?“ - toky, správy, stavy a poradie, v akom sa veci dejú. Popisujú veci, ktoré platia len v určitom okamihu.

Diagram tried vám povie, že Platba má sumu a stav. Stavový automat vám povie, že platba prejde z Autorizovaná do Zachytená, ale nikdy naopak. Ani jeden nedokáže vyjadriť to druhé a väčšina skutočných otázok potrebuje po jednom z každého. Ak zistíte, že sa snažíte ukázať poradie na diagrame tried, je to signál nakresliť druhý diagram, nie preťažiť prvý.

Správanie má o jednu úroveň vnorenia viac. Štyri zo siedmich diagramov správania - sekvenčný, komunikačný, časový a prehľadu interakcií - sú všetko diagramy interakcie, štyri rôzne vykreslenia tej istej myšlienky: účastníci si vymieňajú správy. V princípe sú zameniteľné. V praxi prevládajú sekvenčné diagramy, pretože zvislá časová os je to najľahšie na čítanie na svete.

Tu je celý jazyk na úrovni „potrebujem to dnes?“. Keď je odpoveď áno, nasledujte odkaz.

V praxi je zdravá väčšina skutočného UML štyrmi z nich: diagram tried, sekvenčný, prípadov použitia a aktivít. Ostatných desať existuje, pretože ich niekto potreboval, a tri či štyri z nich sú naozaj vynikajúce, keď si to situácia žiada - stavový automat na životný cyklus, diagram nasadenia na revíziu infraštruktúry. Zvyšok si viete prečítať, keď na ne narazíte, a nikdy ich nemusíte kresliť.

Vychádzajte z otázky, nie z diagramu. Chybou je vybrať si najprv typ diagramu a až potom rozhodovať, čo naň dať - takto skončíte s diagramom tried o dvesto rámčekoch, ktorý nikto nikdy neprečítal.

• „Kto to používa a na čo?“ - diagram prípadov použitia. Rozsah a aktéri, skôr než existuje akýkoľvek návrh.
• „Aké sú pojmy a ako spolu súvisia?“ - diagram tried. Predvolený pohľad na štruktúru.
• „Čo sa stane, keď niekto klikne na zaplatiť?“ - sekvenčný diagram. Poradie správ medzi účastníkmi.
• „Aký je proces, aj s vetvami?“ - diagram aktivít. Tok s rozhodnutiami a súbežnosťou.
• „V akých stavoch môže táto vec byť?“ - stavový diagram. Životný cyklus a povolené prechody.
• „Čo kde beží?“ - diagram nasadenia. Uzly, artefakty, prostredia.
• „Aké sú služby a ich zmluvy?“ - diagram komponentov. Poskytované a vyžadované rozhrania.
• „Ako je kódová základňa usporiadaná?“ - diagram balíkov. Zoskupenie a povolené závislosti.

Nie je to proces. UML nehovorí nič o tom, kedy modelovať, koľko modelovať ani kto to schvaľuje. Je to notácia. Metodiky ako RUP boli okolo neho postavené a často sa s ním zamieňajú; UML sa dá použiť pri akomkoľvek procese, aj pri žiadnom.

Nie je to programovací jazyk. Modely v UML môžu byť dosť podrobné na generovanie kódu a niektoré nástroje presne to robia. Väčšina tímov to nerobí a ani by nemala. Úplné obojsmerné generovanie kódu je najčastejším jediným dôvodom, prečo sa snahy o UML zrútia: z modelu sa stane druhá, horšia kópia zdrojáku, ktorú nikto neaktualizuje.

Nie je to všetko alebo nič. Nič nevyžaduje použiť všetkých štrnásť diagramov ani modelovať každú triedu. Nakresliť jeden sekvenčný diagram na urovnanie sporu o tom, kto koho volá, je úplne legitímne použitie UML a pravdepodobne to najhodnotnejšie.

Nie je to to isté ako ArchiMate. Oboje sú modelovacie jazyky a prekrývajú sa dosť na to, aby to mýlilo. UML modeluje softvér - triedy, komponenty, správy. ArchiMate modeluje podnik okolo neho - podnikové procesy, spôsobilosti, aplikačnú a technologickú vrstvu. Veľká organizácia typicky potrebuje oboje, v rôznych výškach.

Úprimná odpoveď znie: oveľa menej, než k čomu nabáda nástroj. Model si zaslúži svoje miesto vtedy, keď sa číta častejšie, než sa upravuje. Spoľahlivo k tomu vedú tri veci.

Modelujte tie časti, ktoré sa ťažko držia v hlave. Stavový automat platby s deviatimi stavmi a dvoma zakázanými prechodmi si diagram zaslúži. DTO s tromi poľami nie.

Modelujte na jednom diagrame v jednej výške. Najčastejším zlyhaním skutočného diagramu tried je miešanie doménových pojmov s inštalatérstvom frameworku na jednom plátne. Dva diagramy, každý vnútorne konzistentný, sú lepšie než jeden, ktorý je technicky úplný.

Modelujte to, čo si necháte. Diagram v prezentácii je kresba s trvanlivosťou jednej porady, a to je v poriadku, pokiaľ viete, že to tak je. Diagram v repozitári, vedľa kódu, ktorý popisuje, je model - a potrebuje vlastníka.

Ak ste v notácii noví, prečítajte si najprv článok o diagrame tried. Nesie najväčší podiel slovníka UML - generalizáciu, asociáciu, násobnosť, kompozíciu - a každý ďalší diagram štruktúry tieto značky preberá. Potom si prečítajte článok o sekvenčnom diagrame, ktorý robí to isté pre správanie.

Tie dva pokrývajú väčšinu toho, čo od vás kedy budú chcieť prečítať. Všetko ostatné v tejto sérii je napísané tak, aby sa dalo vziať do ruky v deň, keď to potrebujete, v ľubovoľnom poradí, a každý článok predpokladá len tie dva.