projekt knihovna -požadavky x Use Case x Use Case diagram

August 3, 2009 by · Leave a Comment
Filed under: Práce, programování 

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.

Share

Projekt knihovna – Use Case

August 3, 2009 by · Leave a Comment
Filed under: Práce, programování 

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ě:

Use CaseJestli 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.

Share

TOPlist