Co je UML?

UML je vizuální jazyk pro popis softwarových systémů. Dává vám pevnou sadu tvarů, čar a pravidel, aby diagram, který nakreslíte, znamenal totéž i pro někoho, kdo neseděl v místnosti, kde vznikal.

To je celá nabízená hodnota a vyplatí se to říct přímo. Rámeček s názvem není UML. Rámeček se třemi přihrádkami, prázdný trojúhelník mířící na jiný rámeček a 1..* na jednom konci čáry je UML a říká něco přesného: tento typ dědí od tamtoho a jedna instance prvního je spojena aspoň s jednou instancí druhého. Kdokoli, kdo zná notaci, to přečte stejně. To je to, co si kupujete.

Jazyk udržuje Object Management Group. Aktuální vydání je UML 2.5.1, zveřejněné v roce 2017. Pochází z práce, kterou Grady Booch, James Rumbaugh a Ivar Jacobson sloučili v Rationalu v polovině devadesátých let, kdy měl obor zhruba padesát konkurenčních notací a žádný způsob, jak přečíst cizí návrh. OMG přijala UML 1.1 v roce 1997. Verze 2.5 byla především úklidem: specifikace se rozpadla na svazky „infrastructure“ a „superstructure“, ve kterých se vyznalo málo lidí, a 2.5 je složila zpět do jednoho dokumentu.

Každý diagram UML odpovídá na jednu ze dvou otázek. Diagramy struktury odpovídají na „z čeho se tento systém skládá?“ - části, typy, stroje a to, jak jsou uspořádány. Popisují věci, které platí bez ohledu na čas.

Diagramy chováníodpovídají na „co tento systém dělá?“ - toky, zprávy, stavy a pořadí, v jakém se věci dějí. Popisují věci, které platí jen v určitém okamžiku.

Diagram tříd vám řekne, že Payment má částku a stav. Stavový diagram vám řekne, že platba přejde z Authorized do Captured, ale nikdy naopak. Ani jeden nedokáže vyjádřit to druhé a většina skutečných otázek potřebuje od každého jeden. Pokud zjistíte, že se snažíte ukázat pořadí na diagramu tříd, je to signál nakreslit druhý diagram, a ne přetěžovat první.

Chování má o jednu úroveň vnoření navíc. Čtyři ze sedmi diagramů chování - sekvenční, komunikační, časový a přehledu interakcí - jsou všechno diagramy interakce, čtyři různá vykreslení téže základní myšlenky: účastníci si vyměňují zprávy. V principu jsou zaměnitelné. V praxi převažují sekvenční diagramy, protože svislá časová osa je to nejsnáze čitelné na světě.

Tady je celý jazyk na úrovni „potřebuju to dnes?“. Když je odpověď ano, klikněte na odkaz.

V praxi je zdravá většina skutečného UML tvořena čtyřmi z nich: diagramem tříd, sekvenčním, případů užití a aktivit. Zbylých deset existuje proto, že je někdo potřeboval, a tři nebo čtyři z nich jsou opravdu výborné, když si to situace žádá - stavový diagram pro životní cyklus, diagram nasazení pro revizi infrastruktury. Zbytek si vystačíte přečíst, až na něj narazíte, a nikdy ho nekreslit.

Vycházejte z otázky, ne z diagramu. Chybou je vybrat si nejdřív typ diagramu a teprve pak rozhodovat, co na něj dát - tak vznikne diagram tříd o dvou stech rámečcích, který nikdo nikdy nepřečetl.

• „Kdo to používá a k čemu?“ - diagram případů užití. Rozsah a aktéři, ještě než existuje jakýkoli návrh.
• „Jaké jsou pojmy a jak spolu souvisejí?“ - diagram tříd. Výchozí strukturní pohled.
• „Co se stane, když někdo klikne na zaplatit?“ - sekvenční diagram. Pořadí zpráv mezi účastníky.
• „Jaký je proces, včetně větvení?“ - diagram aktivit. Tok s rozhodnutími a souběžností.
• „V jakých stavech tahle věc může být?“ - stavový diagram. Životní cyklus a povolené přechody.
• „Co kde běží?“ - diagram nasazení. Uzly, artefakty, prostředí.
• „Jaké jsou služby a jejich kontrakty?“ - diagram komponent. Poskytovaná a vyžadovaná rozhraní.
• „Jak je kód uspořádaný?“ - diagram balíčků. Seskupení a povolené závislosti.

Není to proces. UML neříká nic o tom, kdy modelovat, kolik modelovat nebo kdo to schvaluje. Je to notace. Metodiky jako RUP kolem něj byly postaveny a často se s ním pletou; UML můžete použít v jakémkoli procesu, včetně žádného.

Není to programovací jazyk. Modely UML mohou být dost podrobné na to, aby se z nich generoval kód, a některé nástroje to přesně dělají. Většina týmů to nedělá a dělat by neměla. Úplné obousměrné generování kódu je nejčastější jediný důvod, proč se snahy o UML zhroutí: z modelu se stane druhá, horší kopie zdroje, kterou nikdo neaktualizuje.

Není to všechno nebo nic. Neexistuje požadavek použít všech čtrnáct diagramů nebo modelovat každou třídu. Nakreslit jeden sekvenční diagram, aby se urovnal spor o to, kdo koho volá, je naprosto legitimní použití UML a pravděpodobně to nejcennější.

Není to totéž co ArchiMate. Oba jsou modelovací jazyky a překrývají se dost na to, aby to mátlo. UML modeluje software - třídy, komponenty, zprávy. ArchiMate modeluje podnik kolem něj - byznys procesy, schopnosti, aplikační a technologickou vrstvu. Velká organizace obvykle potřebuje oba, v různých výškách.

Poctivá odpověď zní: mnohem méně, než k čemu vybízejí nástroje. Model si své místo zaslouží tehdy, když se čte častěji, než se edituje. Tři věci to spolehlivě zajistí.

Modelujte části, které se těžko drží v hlavě. Stavový automat plateb s devíti stavy a dvěma nepovolenými přechody stojí za diagram. Třípoložkové DTO ne.

Modelujte na jednom diagramu v jedné výšce. Nejčastějším selháním skutečného diagramu tříd je míchání doménových pojmů s instalatérstvím frameworku na jednom plátně. Dva diagramy, každý vnitřně soudržný, porazí jeden technicky úplný.

Modelujte to, co si necháte. Diagram v prezentaci je kresba s trvanlivostí jedné schůzky, a to je v pořádku, dokud víte, že to tak je. Diagram v repozitáři, vedle kódu, který popisuje, je model - a potřebuje vlastníka.

Pokud jste v notaci noví, přečtěte si nejdřív článek o diagramu tříd. Nese největší podíl slovníku UML - generalizaci, asociaci, násobnost, kompozici - a každý další diagram struktury tyto značky přebírá. Pak si přečtěte článek o sekvenčním diagramu, který dělá totéž pro chování.

Ty dva pokryjí většinu toho, co kdy budete mít přečíst. Všechno ostatní v této sérii je napsané tak, aby se dalo vzít do ruky v den, kdy to potřebujete, v libovolném pořadí, a každý článek předpokládá jen ty dva.