3. diel - UML - Use Case Špecifikácie

V minulej lekcii, UML - Use Case Diagram , sme si predstavili Use Case diagram. Vytvorili som si jednoduchý Use Case diagram redakčného systému podobnému ITnetwork. Teraz v UML tutoriálu nadviažeme na tento model a doplníme k nemu tzv. Use Case špecifikáciu.

Use Case Špecifikácie

Samotný UC diagram nám ukazuje, aké funkcionality systém obsahuje a ako (kým) sú spúšťané. Okrem názvov jednotlivých prípadov použitia o nich však nevieme vôbec nič.

Tento problém rieši Use Case Špecifikácie. Jedná sa o doplňujúce dokument, ktorý je k Use Case diagramu priložený. Nemá žiadnu pevne definovanú podobu, môže byť vo forme tabuľky alebo obyčajného textu.

Špecifikácia obsahuje jednotlivé prípady použitia, ku každému z nich definuje niekoľko bodov. Najprv si ich popíšeme, potom si skúsime časť špecifikácie k nášmu modelu vytvoriť. Vymenujme si teda jednotlivé časti špecifikácie pre jeden prípad použitia:

1. Krátky popis (Brief Description)

V prvej časti krátko popíšeme prípad použitia, stačí 1 až 2 vety. Mal by vysvetľovať, akú má funkčnosť pre užívateľov pridanú hodnotu, prečo ju používateľ spúšťa. Vieme, že Use Case diagram opisuje funkčnosť práve z pohľadu užívateľa. Toto pravidlo zachováme aj v UC špecifikácii. Príkladom by mohol byť popis: "Use Case umožňuje vytlačiť vybraný dokument".

2. Aktéri (Actors)

Ďalšia časť menuje aktérmi, ktorí sa prípadu použitia zúčastňuje. Príkladom môžu byť Systém a Užívateľ.

3. Podmienky pre spustenie

Každý prípad použitia môže mať definované určité podmienky, ktoré musia byť pre jeho spustenie splnené. Tie môžeme uviesť v tejto časti jeho špecifikácie. Tieto podmienky môžeme tiež vynechať. Príkladom podmienok pre spustenie môže byť nainštalovaná tlačiareň alebo internetové pripojenie. Bez týchto náležitostí nemá UC zmysel a nebude ani spustený.

4. Základný tok

Konečne sa dostávame k základnému toku. V jeho bodoch je popísaná interakcia medzi aktérmi a jednotlivými prípady použitia. Body zapisujeme ako scenár, v ktorom sa striedajú vždy aktér a systém. Opäť máme na pamäti, že popisujeme z pohľadu užívateľa a toho, aký pre neho má prípad použitia význam. Častou chybou je popisovať čo systém zobrazí, čo používateľ zapíše do formulára a podobne. Popis by mal však byť úplne odtienený od toho, ako systém vyzerá, mal by sa zamerať na to, ako funguje. Základný tok nerieši možné chyby a predpokladá bezproblémový priebeh, kde v poslednom kroku dôjde k splneniu cieľa prípadu použitia. Príklad si ukážeme ďalej.

5. Alternatívne toky

Špecifikácia môže obsahovať niekoľko alternatívnych tokov (scenárov), ktoré umožňujú reagovať na odchýlky od scenára základného. Ide o poruchy alebo chyby, či už zo strany užívateľa (zle zadal heslo) alebo systému (nepodarilo sa vytlačiť dokument). Alternatívne tok sa vždy vzťahuje k určitému bodu hlavného toku a rieši jeho neštandardné verzii. Väčšinou je na konci odkázaný opäť na nejaký bod hlavného toku, kde zas hlavný tok pokračuje ďalej.

6. Podmienky pre dokončenie

Podobne, ako môže mať prípad použitia podmienky cez spustením, môže mať aj podmienky pre dokončenie. Podmienkami môže byť napr. Že všetko prebehlo v poriadku, alebo že chyby boli zaznamenané do chybového logu.

Zamerajme sa teraz na náš prvý Use Case, ktorým je napísať komentár. Napíšeme pre neho špecifikáciu:

UC1 - Napísať komentár

Teraz už máme konkrétnu predstavu o tom, ako UC špecifikácie vyzerá. Môžete si ju doplniť pre ďalší UC z nášho Use Case diagramu.

Ukážka zložitejšieho UC diagramu

Ešte máme sľúbenú ukážku zložitejšieho UC diagramu, nižšie sa môžete pozrieť, ako by vyzeral reálny diagram reklamačného systému:

Vzťah požiadaviek a Use Case diagramu

Od zákazníka, zadávateľa softvéru, samozrejme nedostaneme rovno Use Case diagram, ale zoznam požiadaviek. Potom, čo ho roztriedime pomocou metódy FURPS a získame požiadavky funkčné, z nich vytvoríme Use Case diagram. Aby sme sa uistili, že každý požiadavka je realizovaný nejakým UC a že sme na žiadny nezabudli, používa sa často k mapovanie požiadaviek na prípady použitia tabuľka. Tá môže vyzerať napr. Nasledovne:

	prípady použitia
požiadavky	UC1	UC2	UC3	UC4
F1	+	+	+
F2				+
F3

V tabuľke máme vodorovne stĺpčeky pre všetky prípady použitia (tu v príklade len 4). Zvisle máme v riadkoch jednotlivé funkčné požiadavky od zákazníka (tu 3). Vidíme, že funkčné požiadavka F1 realizuje hneď niekoľko UC. Toto by sa mohlo stať v prípade, keď zákazník odovzdá napr. Požiadavka typu "Administrovať články" a vy ho rozpíšete na UC publikovanie článku, UC vyhľadanie článku, UC zamietnutie článku. Naopak požiadavka F2 je už realizovaný len jedným UC. U požiadavke F3 vidíme, že ho nerealizuje žiaden UC, čo je chyba. Práve k odhaleniu takých chýb pri väčšom počte UC vytvárame tabuľku uľahčujúce mapovanie. Môžeme si tak byť istí, že systém bude obsahovať všetko podľa jeho zadania.

V budúcej lekcii, UML - Doménový model , si nakreslíme doménový model.