Přidej si svou IT školu do profilu a najdi spolužáky zde na síti :)

3. díl - UML - Use Case Specifikace

Návrh UML UML - Use Case Specifikace

Unicorn College ONEbit hosting Tento obsah je dostupný zdarma v rámci projektu IT lidem. Vydávání, hosting a aktualizace umožňují jeho sponzoři.

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

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 "Administrace článků" a vy jej v UC rozepíšete na publikování článku, vyhledání článku, 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í.


 

 

Článek pro vás napsal David Čápka
Avatar
Jak se ti líbí článek?
16 hlasů
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.
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
Aktivity (3)

 

 

Komentáře

Avatar
Jakub Vaněk (Bubavanek):9.2.2014 20:08

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:20.3.2016 9:39

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

 
Odpovědět 20.3.2016 9:39
Avatar
Simona Dostálová:27. září 13:45

Moc se mi tato výuka líbí, je to srozumitelně vysvětleno. Díky

 
Odpovědět 27. září 13:45
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 3 zpráv z 3.