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
Krátky popis
Use case umožňuje okomentovať článok v redakčnom systéme.
Aktéri
- Užívateľ
- systém
Podmienky pre spustenie
Užívateľ sa musí nachádzať na príslušnom článku.
Základný tok
- Systém vygeneruje formulár a obrázok sa 4mi náhodnými, orotovanými písmenami.
- Užívateľ vyplní text správy, svoje celé meno a email. Ďalej opíše text z obrázku do pripraveného poľa a formulár odošle.
- Systém zvaliduje dáta od užívateľa.
- Systém uloží správu.
Alternatívne tok 1
2.1 - Pokiaľ je užívateľ registrovaný, neprechádza kontrolou pomocou opísaní kontrolného obrázku (catptcha).
Alternatívne tok 2
3.1 - Ak používateľ zadal neplatný vstup alebo vstupy, systém na
skutočnosť používateľa upozorní a nedovolí správu odoslať.
3.2 - Užívateľ opraví neplatný vstup / vstupy a tok pokračuje na 2. bodu
základného toku.
Podmienky pre dokončenie
Nový komentár bude korektne uložený v databáze.
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 budúcej lekcii, UML - Doménový model , si nakreslíme doménový model.