projekt knihovna -požadavky x Use Case x Use Case diagram
Když už jsme si připravili Use Case diagram (a není ještě úplný), měly bychom si říci, jaký je vlastně rozdíl resp. vztah mezi požadavky, Use Case a Use Case diagramem. Čtenáře poprosím o schovívavost, ale budu používat anglický termín Use Case namísto českého Případy Užití, který je i u nás obecně používaný a nechci být jazykový puritán.
Takže shrňme si to:
Požadavky
Jsou seznam operací, které bude systém provádět, respektive, které budou jednotliví uživatele používat, většinou by mělo být alespoň trochu popsáno o co jde (často jen slovně) a kdo činnost provádí/má k ní oprávnění.
Diagram Use Case
Obsahuje jednotlivé uživatele/role (Actors) a procesy (Use Cases) s naznačením, co kdo má oprávnění provádět. Zde již je vidět jistý náznak objektové hierarchie – mezi uživateli se často používá vztahu generalizace. Což je vlastně zobecnění, tedy “nadtřída” a naopak vztah specializace, což je potomek, tedy podtřída. Mezi procesy pak existují vztahy <<include>> a <<extends>> – píše se na šipku spojující procesy (Use Case-y, jestli to tak mohu skloňovat) a vede směrem k případu, který se v tom prvním používá – tedy například šipka s include vede od rezervovat knihu k procesu najít knihu … když chceme knihu zarezervovat, musíme jí předtím najít – velmi často je proces ke kterému vede vztah <<include>> sám o sobě nepoužitelný. Spojení extends je méně časté a ukazuje rozšíření dané funkce, případu, které nemusí vždy nastat – při přidávání knihy bychom mohli zakládat kategorii (žánr), ale to jenom tehdy, pokud by již daný žánr neexistoval … Určitě sek tomu při zpřeňování ještě dostaneme.
Use Case – Případy užití
A konečně poslední varianta – není to graf, ale seznam jednotlivých Use Case, spolu s popisem jednotlivých kroků a jejich odpovědností – vhodné je pro popis používat jistý pseudokód – ať už anglický, nebo čestký, tedy “když/if, jinak/else, dokud/while …” nejdůležitější je abychom myi zákazník popisu rozumněli.
Nejjednodušší je asi zápis do tabulky
Rezervování knihy | ||
---|---|---|
krok | role | popis |
1 | uživatel | vyhledání knihy |
3 | uživatel/knihovník | IF knihovník |
2.1 | knihovník | – vyhledat uživatele |
2.2 | knihovník | END |
3 | system | ověřit stav uživatele |
4 | system | IF uživatel není zablokován |
4.1 | system | – založit rezervaci knihy |
4.2 | system | END |
Všimněme si jedné drobnosti – v tuhle fázi často ignorujeme stavy kniha nenalezena, uživatel nenalezen – většinou procházíme typické scénáře. Na výjimky/speciální případy bude snad čas později. Jde spíše o to si popsat s uživatelem standardní běh systému.
Projekt knihovna – Use Case
Protože jsme si posledně definovali požadavky a kreslili si je do grafu podobně jako Use Case, jediné co nyní potřebujeme je uvědomut si – spolu s uživatelem, kdo jaké dělá/používá. Identifikovali jsme čtyři možné role – host, uživatel, knihovník a administrátor. Tak jim tedy přiřaďmě jednotlivé akce – zde je určitě prostor pro diskuzi se zákazníkem, protože na něm je určit, jestli host smí prohlížet seznam knih, uživatel si sám půjčit knihu, …
Výsledný UML diagram vypadá následovně:
Jestli se ptáte, v čem je diagram vytvořen, je to IDE NetBeans, aktuálně v 6.7. Volba prostředí již asi i přeurčuje, kam budu dále směřovat a jaké možnosti budeme mít.