V minulém díle tohoto malého seriálu jsme se seznámily s UML jako takovým a především s diagramem případů užití (use case). Dnes je na řadě další neocenitelný pomocník analytika - scénář.
Moto: Nejhorší je, když software dělá úplně všechno, kromě toho, co dělat měl.
Scénář (scenario)
Scénář je do značné míry neoddělitelnou součástí USE-CASE diagramu. Scénář je v podstatě silně strukturovaný text, který popisuje činnost uživatele při práci se systémem a činnost systému. Jednotlivé odstavce pak odpovídají jednotlivým use case („případ užití“). Aby bylo dosaženo co největší přehlednosti a jednoduchosti, používají se k tvorbě scénářů editory, které umožňují vytvářet interaktivní text. Obvykle bývá takové prostředí přímo součástí nástrojů pro tvorbu UML diagramů (case nástroje). Pokud ne, pak nám postačí obyčejný textový editor (OpenOffice Write, MS Word, apod.)
Celý scénář je velmi podobný nápovědě, ale je vytvářen v okamžiku, kdy ještě žádná aplikace neexistuje. Věty v něm mají velmi unifikovanou strukturu a po slohové stránce je tedy velmi nudný. Krátký výňatek ze scénáře by mohl vypadat například takto:
Procházení seznamem žáků
Objeví se nová obrazovka (Scr. Procházení žáky). Obrazovka obsahuje seznam žáků (údaje: jméno, příjmení, rok nástupu, počet úspěchů). V seznamu je možno označit jednoho nebo více žáků.
Přidání žáka
Objeví se nová obrazovka (Scr. Přidání žáka). Obsluha vyplní údaje: jméno, příjmení, rodné číslo, rok nástupu do školy. Obsluha potvrdí zadaná data volbou „Ok“ jinak zvolí „Storno“.
Pokud je volba „Ok“ jsou zkontrolována zadaná data:
- Jméno: délka maximálně 20 znaků
- Příjemní: délka maximálně 30 znaků
- Rodné číslo: dělitelné 11
- Rok nástupu do školy: nižší nebo roven aktuálnímu roku
Pokud jsou data v pořádku, obsluze se zobrazí informace o úspěšném vložení žáka, jinak se zobrazí (Scr. Přidání žáka). Chybně vyplněná pole jsou označena. Obsluha opraví údaje. Obsluha zvolí „Ok“ nebo „Storno“ (dále viz výše).
Již teď je jasné, jaké informace se ve scénáři nacházejí. Především zde nalezneme základní prvky, které bude uživatel používat pro práci se systémem (Obrazovky, Screens, Scr.) Dále je ve scénáři přesně popsáno, co bude provádět uživatel (obsluha) systému a co bude provádět systém sám.
Scénář není přesným popisem, jak dané úkoly řešit. Obsahuje pouze informace zásadního významu jako jsou dohodnutá pravidla pro zadávaná data, způsoby šifrování, základní prvky komunikace s uživatelem apod. V žádném případě by scénář neměl obsahovat fráze a názvy, které jsou specifické pro konkrétní programovací jazyk nebo vývojovou platformu. Proto se také ve scénáři objevuje pouze označení „seznam“ a ne např. listbox, rozbalovací seznam a podobně.
Každý ustálený vývojový tým si po čase zvykne na určitou formu a rozsah scénářů. Scénář se pak stává základním dokumentem, který spolu s USE-CASE modelem tvoří základ budoucího systému. Protože se ve scénáři neobjevují pojmy, které jsou specifické pro konkrétní programovací jazyk, je scénář čitelný i pro zákazníka. Zákazník tedy již na začátku vývoje ví, co a jak bude nový systém umět a může dohodnuté funkčnosti vyžadovat na dodavateli.