Lekce 3 - UML - Use Case Specifikace

V předešlém cvičení, Řešené úlohy k 1.-2. lekci UML, jsme si procvičili nabyté zkušenosti z předchozích lekcí.

Nyní v UML tutoriálu navážeme na tento model a doplníme k němu tzv. Use Case specifikaci.

Use Case Specifikace

Samotný UC diagram nám ukazuje, jaké funkcionality systém obsahuje a jak (kým) jsou spouštěny. Kromě názvů jednotlivých případů užití o nich však nevíme vůbec nic.

Tento problém řeší Use Case Specifikace. Jedná se o doplňující dokument, který je k Use Case diagramu přiložen. Nemá žádnou pevně definovanou podobu, může být ve formě tabulky nebo prostého textu.

Specifikace obsahuje jednotlivé případy užití, ke každému z nich definuje několik bodů. Nejprve si je popíšeme, potom si zkusíme část specifikace k našemu modelu vytvořit. Vyjmenujme si tedy jednotlivé části specifikace pro jeden případ užití:

1. Krátký popis (Brief Description)

V první části krátce popíšeme případ užití, stačí 1 až 2 věty. Měl by vysvětlovat, jakou má funkčnost pro uživatele přidanou hodnotu, proč ji uživatel spouští. Víme, že Use Case diagram popisuje funkčnost právě z pohledu uživatele. Toto pravidlo zachováme i v UC specifikaci. Příkladem by mohl být popis: "Use Case umožňuje vytisknout vybraný dokument".

2. Aktéři (Actors)

Další část jmenuje aktéry, kteří se případu užití účastní. Příkladem mohou být Systém a Uživatel.

3. Podmínky pro spuštění

Každý případ užití může mít definované určité podmínky, které musí být pro jeho spuštění splněny. Ty můžeme uvést v této části jeho specifikace. Tyto podmínky můžeme také vynechat. Příkladem podmínek pro spuštění může být nainstalovaná tiskárna nebo internetové připojení. Bez těchto náležitostí nemá UC smysl a nebude ani spuštěn.

4. Základní tok

Konečně se dostáváme k základnímu toku. V jeho bodech je popsána interakce mezi aktéry a jednotlivými případy užití. Body zapisujeme jako scénář, ve kterém se střídají vždy aktér a systém. Opět máme na paměti, že popisujeme z pohledu uživatele a toho, jaký pro něj má případ užití význam. Častou chybou je popisovat co systém zobrazí, co uživatel zapíše do formuláře a podobně. Popis by měl však být úplně odstíněn od toho, jak systém vypadá, měl by se zaměřit na to, jak funguje. Základní tok neřeší možné chyby a předpokládá bezproblémový průběh, kde v posledním kroku dojde ke splnění cíle případu užití. Příklad si ukážeme dále.

5. Alternativní toky

Specifikace může obsahovat několik alternativních toků (scénářů), které umožňují reagovat na odchylky od scénáře základního. Jedná se o poruchy nebo chyby, ať již ze strany uživatele (špatně zadal heslo) nebo systému (nepodařilo se vytisknout dokument). Alternativní tok se vždy vztahuje k určitému bodu hlavního toku a řeší jeho nestandardní verzi. Většinou je na konci odkázán opět na nějaký bod hlavního toku, kde zas hlavní tok pokračuje dále.

6. Podmínky pro dokončení

Podobně, jako může mít případ užití podmínky přes spuštěním, může mít i podmínky pro dokončení. Podmínkami může být např. že vše proběhlo v pořádku nebo že chyby byly zaznamenány do chybového logu.

Zaměřme se nyní na náš první Use Case, kterým je napsat komentář. Napíšeme pro něj specifikaci:

UC1 - Napsat komentář

Nyní již máme konkrétní představu o tom, jak UC specifikace vypadá. Můžete si ji doplnit pro další UC z našeho Use Case diagramu.

Ukázka složitějšího UC diagramu

Ještě máme slíbenou ukázku složitějšího UC diagramu, níže se můžete podívat, jak by vypadal reálný diagram reklamačního systému:

Vztah požadavků a Use Case diagramu

Od zákazníka, zadavatele softwaru, samozřejmě nedostaneme rovnou Use Case diagram, ale seznam požadavků. Poté, co jej roztřídíme pomocí metody FURPS a získáme požadavky funkční, z nich vytvoříme Use Case diagram. Abychom se ujistili, že každý požadavek je realizován nějakým UC a že jsme na žádný nezapomněli, používá se často k mapování požadavků na případy užití tabulka. Ta může vypadat např. takto:

V tabulce máme vodorovně sloupečky pro všechny případy užití (zde v příkladu jen 4). Svisle máme v řádcích jednotlivé funkční požadavky od zákazníka (zde 3). Vidíme, že funkční požadavek F1 realizuje hned několik UC. Toto by se mohlo stát v případě, když zákazník předá např. požadavek typu "Administrovat články" a vy jej rozepíšete na UC publikování článku, UC vyhledání článku, UC zamítnutí článku. Naopak požadavek F2 je již realizován jen jedním UC. U požadavku F3 vidíme, že jej nerealizuje žádný UC, což je chyba. Právě k odhalení takových chyb při větším počtu UC vytváříme tabulku usnadňující mapování. Můžeme si tak být jistí, že systém bude obsahovat vše dle jeho zadání.

V následujícím cvičení, Řešené úlohy k 3. lekci UML, si procvičíme nabyté zkušenosti z předchozích lekcí.