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

V predchádzajúcom cvičení, Riešené úlohy k 1.-2. lekciu UML, sme si precvičili získané skúsenosti z predchádzajúcich lekcií.

Teraz v UML tutoriále nadviažeme na tento model a doplníme k nemu tzv. Use Case špecifikáciu.

Use Case Špecifikácia

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. Ide o doplňujúci 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 užitia, stačí 1 až 2 vety. Mal by vysvetľovať, akú má funkčnosť pre používateľa pridanú hodnotu, prečo ju používateľ spúšťa. Vieme, že Use Case diagram popisuje 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ť vymenuje aktérov, ktorí sa prípadu použitia zúčastňujú. 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

Napokon sa dostávame k základnému toku. V jeho bodoch je popísaná interakcia medzi aktérmi a jednotlivými prípadmi 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ívny tok sa vždy vzťahuje k určitému bodu hlavného toku a rieši jeho neštandardnú verziu. 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 na 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ácia vyzerá. Môžete si ju doplniť pre ďalšie 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 žiadnu nezabudli, používa sa často na mapovanie požiadaviek na prípady použitia tabuľka. Tá môže vyzerať napr. takto:

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žiadavku 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. Pri požiadavke F3 vidíme, že ho nerealizuje žiadny UC, čo je chyba. Práve na odhalenie takýchto chýb pri väčšom počte UC vytvárame tabuľku uľahčujúcu mapovanie. Môžeme si tak byť istí, že systém bude obsahovať všetko podľa jeho zadania.

V nasledujúcom cvičení, Riešené úlohy k 3. lekcii UML, si precvičíme nadobudnuté skúsenosti z predchádzajúcich lekcií.