UML – jazyk návrhu objektových aplikací

Jazyk UML je pravděpodobně nejznámějším modelovacím jazykem současné generace analytiků a desinerů. Od svého vzniku v r. 1994 prošel mnoha revizemi, ale základní charakteristiky si stále uchoval:

  • Je optimalizován pro návrh objektově orientovaných softwarových řešení
  • Hlavní určení je pro oblast designu modulárně a objektově strukturovaných aplikací

UML se byl v minulých letech takřka jediným modelovacím jazykem a používal se na všechno od procesního modelování po popis infrastruktury, ačkoli na to nikdy nebyl určen a není na to vhodný.

UML pro design

Vstupem pro design jsou funkční požadavky, v UML popsány use-case elementy.

Designer navrhuje funkčnost systému formou metod tříd, ke kterým se požadovaná funkčnost vztahuje. Samotné objekty primárně reprezentují business entity. Pro ty UML nemá odpovídající element, takže při jejich modelování designer vychází opět z use-case nebo byly od počátku modelovány jinak, např. pomocí tříd.

Při návrhu implementace jsou navrženy diagramy aktivit, stav­ové a komunikační diagramy. Pokud realizace vyžaduje provázání více modulů, poslouží diagram komponent. Podrobný popis komunikace systémů popíše sekvenční diagram.


UML pro business analýzu

Zatímco pro design aplikace je v jazyce UML podpořen velmi dobře, na business analýzu připraven není.

Základem business analýzy je popis organizace, činností, procesů a interních vazeb. Nezbytnou součástí je také popis business entit. Pro popis organizace samotné je možné použít rolí a jejich hierarchie. Lepším jazykem pro modelování je ale pro všechny elementy ArchiMate.

Procesy je možné modelovat pomocí diagramů aktivit, ale pokud je možné využít jazyka BPMN, je to rozhodně lepší volba.  

Pro modelování funkčních požadavků slouží use-case, UML dobře rozlišuje mezi business use-case a funkčními use-case. (Je vhodné nezaměňovat use-case modely s procesními modely: Pokud se v use-case modelech modeluje i pořadí jednotlivých use-case , stává se model nepřehledným.)

Pro modelování business je v UML nejlepší strukturou třída. Její vnitřní logická struktura (atributy, funkce) umožňuje dobře mode­lovat i vlast­nosti a hodnoty business entity, na druhou stranu řada vazeb, které jsou modelování tříd vlastní, do business analýzy ne­patří. Především hie­rarchie, dě­dič­nost a vlastnos­ti poly­morfiz­mu nebo za­pouzdře­ní. Jakkoli se mohou tyto mo­delo­vací postupy zdát ana­lyti­kům užitečné, nesmí zapo­menout, že bu­dou-li je použí­vat, určitě analýze nebu­dou lidé z businessu rozumět.

Řadu elementů analýzy, jako business omezení, pravidla apod. lze využívat use-case elementů upřesněných stereotypem.

Pokud se pro modelování business analýzy využije diagramů aktivit, je třeba, aby se modely analýzy nemíchaly s modely designu. K tomu pomůže rozdělení do samostatných celků (např. package) a pokud možno i využívání jiných stereotypů, které jednoznačně odliší aktivity businessu a systémů.


Silné a slabé stránky UML

V čem je UML dobré

UML jazyk díky své promyšlenosti a dlouhodobému používání má řadu nesporných výhod:

  • Je Velmi rozšířený, takže ve vývojových týmech dobře známý, pro komunikaci je díky tomu vhodný
  • Pokud vyvíjíte objektová řešení, jazyk poskytuje vše, co je pro modelování potřebné
  • Je podporován mnoha nástroji, takže investice do technologií nejsou velké
  • Existuje podpora pro automatické generování kódu

Na co drobé není

Nevýhody UML nejsou ani tak způsobeny jazykem samotným jako tím, jak je používán. Do jisté míry se ale projevuje i jeho stáří, protože od dob jeho vzniku se způsob programování velmi změnil.

  • Současné programování je většinou více kompo­nento­vé než objekto­vé. Objekto­vé prin­ci­py nejsou mnohým dosta­tečně zřejmé.
  • Všechny současné aplikace jsou postavené na knihov­nách. Pro ty většinou neexistují dostupné odpovídající modely do UML nástrojů, takže model postrádá základní třídy pro vy­ví­jené objekty. Ty samozřejmě může tým doplnit, ale to je velmi zdlouhavé. Samozřejmě to také brání generování kódu.
  • Detailní návrh a design řešení v podstatě popírají agilní me­todi­ky vývoje, takže pro mnohé současné týmy jsou pro­myšle­né modely řešení de facto tabu.
  • O modelování se nejčastěji snaží analytici, kteří mají na sta­rost i business analýzu, pro kterou UML není vhodný.

Služby k UML