3. díl - UML - Use Case Specifikace

Návrhové vzory UML UML - Use Case Specifikace

V minulém dílu UML tutoriálů jsme si představili Use Case diagram. Vytvořili jsem si jednoduchý Use Case diagram redakčního systému podobnému devbooku. Nyní 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 popisoval 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 hlavní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 4mi náhodnými, orotovanými písmeny.
  2. Uživatel vyplní text zprávy, své 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 (catptcha).

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

 

  Aktivity (1)

Článek pro vás napsal David Čápka
Avatar
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (12 hlasů) :
4.583334.583334.583334.583334.58333


 


Miniatura
Předchozí článek
UML - Use Case Diagram
Miniatura
Všechny články v sekci
UML
Miniatura
Následující článek
UML - Doménový model

 

 

Komentáře

Avatar
Jakub Vaněk (Bubavanek):

Mam jen takovou otazku. Nemel by ve scenari iniciovat typovou ulohu akter a system na nej reagovat?

 
Odpovědět 9.2.2014 20:08
Avatar
Roman
Člen
Avatar
Roman:

Skvelý článok dosť mi pomáha sa zorientovať v učive pri návrhu UML na VŠ ďakujem :)

 
Odpovědět 20. března 9:39
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 2 zpráv z 2.