Z pohledu UML je případ užití a aktor natolik primitivní záležitostí, že ji ovládá téměř každý po pětiminutovém vysvětlení. Ovšem zápas začíná ve chvíli, kdy se začnou používat. Jednou takovou dílčí bitvou je nalezení odpovědi na otázku: ke kterým všem případům užití má vést asociace od aktora?

Ukažme si to na příkladu. Předem však musím upozornit, že níže popisovaná technika NENÍ dána standardem UML, ale popisuje jeden ze způsobů, jak pracovat s případy užití.

Mějme jednoduchý e-shop, který bude nabízet knihy. Zákazník přijde, prohlíží si nabídku, a pokud se rozhodne něco koupit, vloží zboží do košíku, zadá doručovací adresu, způsob platby a nakonec potvrdí celou objednávku.

Primárním případem užití zde budeme myslet takový případ užití, který slouží k základnímu cíli uživatele (aktora) našeho systému. V našem příkladu je takovým cílem zakoupit si knihu. Diagram pak může vypadat takto:

Dosud je vše v pořádku. Postupnou analýzou problematiky však určíme, že je potřeba zavést další případy užití: Zobraz knihu, Vyhledej knihu, Zpracuj košík apod. Jde o sekundární (či pomocné) případy užití, které sice nejsou důvodem, proč uživatel náš systém používá, ale primární případy užití se bez nich neobejdou. Náš primární případ užití je pak bude využívat pro svou potřebu. To zobrazíme pomocí vztahu include:

Opět, dosud tu nebude nic, co bychom mohli nějak rozporovat.

Ke kterým případům užití však udělat asociace od Zákazníka? Tady nám už UML nepomůže, neboť to říká, že asociaci lze od aktora vést k libovolnému případu užití. Jenže pokud to uděláte, diagram bude nečitelná změť čar. Již asi tušíte, že vhodná odpověď je asociace pouze s primárními případy užití. Výsledek tedy bude vypadat takto:

Toto pravidlo se docela osvědčuje, ale někdy může vést ke zmatení. Do našeho modelu totiž přidáme nového aktora a to Prodavače. Nyní si představte situaci, kdy naši eShopovou aplikaci používá i tento prodavač. Ten stojí např. mezi regály, když v tom jej osloví zákazník a zeptá se: Máte knihu XY? Pokud prodavač neví, přistoupí k počítači a knihu vyhledá. Pokud se povede, zákazník má radost, pokud ne, děje se něco jiného. Náš diagram bychom tedy mohli upravit takto:

Je to však v pořádku? Vždyť máme asociaci k sekundárnímu případu užití a my jsme si řekli, že to dělat nebudeme! Ovšem v pořádku to je. Případ užití je totiž sekundárním pro Zákazníka, ale primárním pro Prodavače. A proto je naše asociace dle našeho pravidla.

A to je vlastně vše, co jsem k tomu chtěl povědět. Zapamatujte si prosím jedno zásadní pravidlo modelování: vždy mějte na paměti, z jakého pohledu se na vaše prvky díváte. Každý pohled totiž může být jiný. A doporučení, které jsem zde záměrně porušil: Každý digram by měl být pouze a jen z jednoho úhlu pohledu. Porušení tohoto pravidla vede k nepochopením a nedorozuměním.

Pozn.: V uvedeném příkladu se samozřejmě můžete šťourat a hledat pro i proti. Já osobně se používání aktorů bráním. Je to zbytečný prvek, který se hodí maximálně pro diagram na prezentaci pro zadavatele. Raději používám popis nějakého procesu, přičemž případ užití realizuje některý krok takového procesu. Ale o tom třeba někdy příště.