Proč?
- zpřesnění zadání, podklady pro dokumentaci
- podklady pro akceptační testy
- vyjasnění si požadavků se zákazníkem
- zadání pro programátory
- Případy užití už mohou být formou zadání pro programátory (už vidím aktéry, jaké přesně dělají činnosti apod.)
- Tvoří základ pro tvorbu uživatelské příručky a také slouží jako podklad k tvorbě akceptačních testů
Skládá se z:
- Seznam účastníků/aktérů
- Diagram případů užití
- Seznam případů užití (popis a slovní rozšíření diagramu případů užití)
- zde lze nadefinovat hlavní a alternativní scénáře + různé výjimky
- také musím specifikovat podmínky provedení
flowchart BT Knihovník --> Čtenář
- generalizace/dědičnost mezi účastníky (účastník může v systému spouštět i všechny případy svého rodiče)
- čas je také jeden z aktérů - v aplikaci mohu mít automaticky spouštěné úlohy na základně nějaké časové události
<<include>>
- když mám nějakou část použitou v několika případech užití, tak ji mohu vyjmout, udělat z ní samostatný případ užití a pak ji “naincludovat” do původních případů užití (využití DRY principu)
- povinné zahrnutí případu užití
Zobrazit seznam knih
Scénář ukazuje postup při zobrazení seznamu knih:
- Systém zobrazí seznam knih
- Uživatel jednu knihu vybere
- Systém …
- Uživatel …
Případ užití “Zobrazit seznam knih” je zahrnut (include) jak z případu “Upravit údaje o knize”, tak z případu “Odstranit knihu”. Aktérem je Knihovník.
flowchart LR actor([Knihovník]) upravit(Upravit údaje o knize) odstranit(Odstranit knihu) zobrazit(Zobrazit seznam knih) actor --> upravit actor --> odstranit upravit -->|«include»| zobrazit odstranit -->|«include»| zobrazit
<<extends>>
- používá se, pokud je vyčleněná část scénáře nepovinná
flowchart TD actor([Knihovník]) UC1([Upravit údaje o knize]) UC2([Vyhledat knihu]) UC3([Odstranit knihu]) actor --> UC1 actor --> UC3 UC1 -->|«include»| UC2 UC3 -->|«extend» zobrazení seznamu| UC2
Scénář - Odstranit knihu
- UC začíná, když …
- Volitelný krok: zobrazení seznamu knih (toto je rozšiřující část, proto «extend»)
- Systém odstraní zvolenou knihu
Krok zobrazení seznamu je nepovinný - proto je modelován pomocí «extend», nikoli «include».
Doporučení při tvorbě
-
popisuj, co má systém dělat, ne JAK to má dělat
-
nerozepisuj se u “nezajímavých” UC
-
diagram je pouze doplňující, hlavní úsilí jde do popisu a do scénářů
-
jako doplnění scénáře užití může sloužit také návrh grafiky (wireframes, Figma, náčrty, nákresy…)
-
v popisu scénáře se popisuje hlavně interakce uživatele se systémem (tedy jeden bod je akce uživatele a druhý bod je reakce systému atd.)
-
Systém a Čas jsou aktéři pouze v případě pokud vykonávají něco nezávisle na uživatelské akci
- kdybych tam zaznačoval jenom reakce systému, tak budu mít aktéra Systém, který bude ukazovat na všechny Use Cases, což nemá moc smysl, ani vypovídající hodnotu
-
pokud je analytický tým oddělený od vývojového, tak je nutné minimalizovat nutnou komunikaci (právě fakt dobrým a podrobným diagramem užití)
-
pokud je výsledkem projektu nějaký framework či knihovna, tak je třeba zvážit, jestli je potřeba takový diagram vůbec vytvářet
Chyby v modelu
Diagram případů užití nezobrazuje tok událostí. K tomuto účelu slouží jiné nástroje:
- textové scénáře
- diagram aktivit
- stavový diagram
Diagram případů užití také nezobrazuje datová úložiště ani paměti systému.
Plus každý případ užití musí mít svého aktéra