Pouze tento týden sleva až 80 % na e-learning týkající se C# .NET. Zároveň využij akce až 50 % zdarma při nákupu e-learningu. Více informací:
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

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ář

Krátký popis

Use case umožňuje okomentovat článek v redakčním systému.

Aktéři

  • Uživatel
  • Systém

Podmínky pro spuštění

Uživatel se musí nacházet na příslušném článku.

Základní tok

  1. Systém vygeneruje formulář a obrázek se 4 náhodnými, deformovanými písmeny (CAPTCHA).
  2. Uživatel vyplní text zprávy, své celé jméno a email. Dále opíše text z obrázku do připraveného pole a formulář odešle.
  3. Systém zvaliduje data od uživatele.
  4. Systém uloží zprávu.

Alternativní tok 1

2.1 - Pokud je uživatel registrovaný, neprochází kontrolou pomocí opsání kontrolního obrázku.

Alternativní tok 2

3.1 - Pokud uživatel zadal neplatný vstup nebo vstupy, systém na skutečnost uživatele upozorní a nedovolí zprávu odeslat.
3.2 - Uživatel opraví neplatný vstup/vstupy a tok pokračuje na 2. bodu základního toku.

Podmínky pro dokončení

Nový komentář bude korektně uložen v databázi.

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:

Use Case diagram případů užití firmy AM Electro

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:

  Případy užití
Požadavky UC1 UC2 UC3 UC4
F1 + + +  
F2       +
F3        

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í.


 

Předchozí článek
Řešené úlohy k 1.-2. lekci UML
Všechny články v sekci
UML
Přeskočit článek
(nedoporučujeme)
Řešené úlohy k 3. lekci UML
Článek pro vás napsal David Čápka
Avatar
Uživatelské hodnocení:
174 hlasů
David je zakladatelem ITnetwork a programování se profesionálně věnuje 13 let. Má rád Nirvanu, nemovitosti a svobodu podnikání.
Unicorn university David se informační technologie naučil na Unicorn University - prestižní soukromé vysoké škole IT a ekonomie.
Aktivity