UML - Diagram případů užití

První úkol, tj. vymezení hranic systému, je v UML podpořeno dynamickýmpohledem modelovaným prostřednictvím diagramů případů užití, který jeznám pod celou řadou dalších názvů jako například diagram typovýchčinností, jednání atp. Tento diagram, obecně model, zobrazuje základnívztah systému k jeho okolí, tzv. aktorům. Aktory jsou nejčastěji samotníuživatelé systému, nicméně mohou jimi býti obecně libovolní externíčinitelé stojící mimo modelovaný systém. Může se tedy jednat například odalší HW s SW prostředky, jiné IS, s kterými má nový IS spolupracovat,instituce, které se systémem komunikují atd. Každý případ užití pakpředstavuje jeden z možných způsobů použití systému, jednu z možnýchcest komunikace aktor - systém. Konkrétním případem užití může býtnapříklad použití systému za účelem zjištění aktuálního stavu skladovýchzásob, zpracování faktury atp. Jednoduše řečeno, případy užití simulujípoužití reálného systému externími aktory. V rámci tvorby těchtodiagramů modelujeme vztah systému a jeho okolí, nikoliv vzájemnouinterakci, tj. způsob, jakými jsou jednotlivé případy užití zajištěnyinterními funkcemi systému.

Největší úskalí při používání tohoto prostředku spočívá v odhadnutí"správné úrovni abstrakce". Občas se může stát, že jsou případy užitímoc obecné a nelze s nimi bez patřičného spodrobnění efektivně pracovat.Na druhou stranu je nutné vyvarovat se druhého extrému, kterým jezneužívání tohoto nástroje pro funkcionální rozklad, který nemá s "UseCase modelováním" nic společného! Historie praví, že systém postavený nafunkcích, jež má zajišťovat, spíše než na objektech, které jej tvoří, jemnohdy nestabilní z hlediska měnících se uživatelských požadavků.Ačkoliv toto riziko a problémy s ním spojené objektový přístupneeliminuje bezezbytku, je přeci jenom možné nežádoucí efektyvyplývající ze změny požadavků částečně potlačit. V ideálním případě sezměna promítne v místě, kterého se bezprostředně týká, v horším případěovlivní dílčí změna mnoho součástí systému. S rostoucím počtemnásledných úprav pak logicky roste i riziko z nejnepříjemnějších –nekonzistence modelů.

Praxe ukazuje, že z hlediska používání UML je zvládnutí tvorby těchtomodelů jedním z nejobtížnějších úkolů, který navíc díky své povazevýraznou měrou ovlivňuje podobu výsledného produktu. Přestože je pomocítohoto prostředku možné rozdělit systém na dílčí oblasti, není tentoprostředek určený na komplexní modelování architektury. Snad více nežkde jinde je v tomto typu modelu nutno zvolit správný konsensus meziúplností a přehledností. Nepříliš adekvátním použitím mohou diagramypřípadů užití velice rychle nabobtnat a stanou se z nich nezvladatelnámonstra, která již neslouží svému původnímu účelu, tj. pro vytvořeníprvních "nástřelů" a pro základní členění systému.

Ve spojení s dalšími prostředky pro dynamické modelování je tvorbadiagramů případů užití fundamentálním prostředkem pro nalezení objektůparticipujících v modelovaném systému. Rozdělení celého systému najednotlivé případy užití přináší kromě vymezení hranic systému i možnostzpracovávat jednotlivé případy užití odděleně a částečně tak realizovatiterativní přírůstkový životní cyklus. Skrze tvorbu případů užití jsousamozřejmě definovány i základní uživatelské požadavky.