Při in-house školení ve firmách anebo v rámci veřejných školení velmi často řešíme příklady přinesené přímo účastníky školení jako součást konzultace. Několikrát se mi stalo, že jsem přitom identifikoval stále tutéž opakující se chybu a proto bych se tady o ní rád tak trochu rozepsal. Dopředu musím podotknout, že se jedná o chybu velice častou a záludnou, protože souvisí s častou záměnou názvu případu užití s aktivitou v daném případu užití.
Nejprve se zmíním o definici případů užití spouštěných z procesů podniků (tj. z okolí), které se někdy pracovně nazývají případy užití „prvého druhu“ resp. jako „případy užití v první linii“.
Poznámka: Kromě toho existují případy užití „druhého druhu“ resp. „v druhé linii“, které vznikají díky interakcím mezi případy užití a nasazením opětovné použitelnosti, což vede k refaktoringu scénářů
Případ užití „prvního druhu“ spouštěný z procesu podniku má tuto povahu posloupnosti děje: Výchozí je stav „nečinnosti“, kdy okolí i systém jsou ve stavu „idle“, tj. nikdo nic nechce, nikdo nic nepotřebuje, ani okolí, a ani systém, všichni spí (a obsluha má nohy na stole). Následuje událost v okolí (anebo časová událost v systému). Díky této události se začíná odehrávat děj v okolí systému, tj. obsluha sundává nohy ze stolu a musí něco začít dělat. Začne se odehrávat aktivita okolí systému, systém o této aktivitě okolí ještě nic neví. V rámci této aktivity se najednou potřebuje použít systém. V té chvíli se spustí (tj. instanciuje) jeden z případů užití, což reprezentuje budoucí program. Takto spouštěné případy užití budeme nadále nazývat případy užití prvého druhu resp. připady užití v první linii.
Příklad: Výchozí stav „nikdo nic nepotřebuje“, následuje událost „do podniku přichází faktura k proplacení“, kterou je třeba zaevidovat. Použije se USE CASE „Založení nové faktury k proplacení“.
Platí jedno důležité pravidlo: Název případu užití vystihuje ten užitek, pro který se případ užití instanciuje, pro který se použije, a vše ostatní je pro jeho název podružné! Je to de facto plnění nějakého požadavku z okolí.
Díky tomuto pojetí nalézání případů užití lze najít dobře všechny „vstupní body“ do systému a provést tak vcelku dobrou inventarizaci rozsahu systému.
Dále uvedené častá chyba však vede k situaci, kdy odhadnout rozsah systému je díky ní velmi obtížné. Chyba spočívá v tom, že dochází k záměně pojmu případ užití a aktivity. Souvisí úzce s představou, jak to v systému proběhne, když se USE CASE spustí. Touto záměnou aktivity a případu užití dojde k chybnému určení názvů případů užití a jejich identifikaci.
Vysvětleme si tuto chybu na klasickém příkladu evidence osob.
V rámci práce s evidencí osob nechť analytik správně nalezl (mimo jiné) tyto případy užití systému:
- Založení nové osoby
- Editace osoby
- Smazání osoby
Odpovídající správný model pak vypadá takto:
Správný model případů užití
Následně analytik zjistí, že scénář případu užití Editace osoby probíhá tak, že nejprve se obsluze zobrazí seznam osob, obsluha z něj vybere osobu a potom se provede editace aktuálně vybrané osoby. Poté analytik objeví, že podobně se ve scénáři UC Smazání osoby zobrazí seznam osob, obsluha vybere osobu a ta se poté (po odsouhlasení) smaže.
Analytik tedy správně určil, že jedna část scénáře se opakuje v obou případech užití, proto tuto část opakujícího se scénáře správně „vytkne“ tak, že zavede nový případ užití (druhého druhu) a pomocí interakce include jej zavolá, čímž vznikne následující model:
Správné nasazení vztahu include
Všimněme si, že, i když počet případů užití se zvedl o jedna, z hlediska rozsahu užitkovosti systému se systém nijak nerozšířil, pouze část scénáře v obou případech užití (viz UC Výběr osoby) se „vytkla“ do společného scénáře. Takto vzniklé případy užití budeme nadále nazývat případy užití druhého druhu resp. případy užití v druhé linii.
Uvedli jsme si správný model a nyní se věnujme často se opakující se chybě záměny případu užití a aktivity.
Analytik se příliš soustředí na posloupnost aktivit, jak jdou za sebou, a chybně určí případy užití s include tak, že „nejprve“ se zavolá případ užití Výběr osoby a v rámci něj se přes include spustí UC Editace osoby resp. UC Smazání osoby. Vidí to, jakoby případy užití šly takto za sebou. Vznikne tak následující (pozor – to je chybný !) model:
Chybný model se záměnou případů užití
Název UC se zaměnil za první aktivitu a dále se „větví“ na případy užití, které po něm „následují“.
Zkusme si přečíst tento chybný model vlastními slovy přesně tak, jak chybně namalován: „Obsluha systému přistupuje k systému proto, aby vybrala osobu. Tečka.“ … a to je samozřejmě nesmysl.
Když jsem toto vysvětloval v jedné firmě analytikovi, který zavedl podobnou chybu, odpověděl mi: „Ano, ale tam není tečka. To pokračuje dál, obsluha se pak rozhoduje, zda chce Editovat osobu anebo Smazat osobu.“
V této mylné úvaze je schována chyba porušení objektového paradigmatu (viz zmíněná kniha resp. školení), který platí i pro případy užití, a současně tím vzniká i chyba záměny příčiny a následku. Z hlediska objektového paradigmatu je totiž celý případ užití viděný zvenku obsluhou (tj. je viděn jako tlačítko na systému) a současně název tohoto tlačítka dává také správný název celému danému případu užití. Podívejme se tedy na daný případ užití pohledem obsluhy (tj. z pohledu panáčka na diagramu). Tlačítko na systému se nyní nazývá „Výběr osoby“ a nikoliv tak, jak obsluha skutečně potřebuje a očekává.
Na toto zdůvodnění mi analytik odpověděl, že obsluha nemusí mít v okamžiku výběru osoby jasno, zda bude mazat anebo editovat. Tato úvaha je již hodně mimo, protože případy užití jsou definovány jako celek ve smyslu „nabízené užitky“ a ty se mají „pro něco používat“. Když bych tuto myšlenku „nerozhodnuté obsluhy“ přirovnal k situaci v běžném životě, bylo by to stejné, jako následující situace: Původní správná věta „V rámci celého svatebního obřadu bude zahrán Svatební pochod“ se chybnou úvahou změní na: „Nejprve se rozhodneme zahrát si (bůhví proč) Svatební pochod a potom teprve budeme uvažovat o svatebním obřadu.“ Zřetelně vidíme záměnu logiky, tedy „kdo vznikl a proč“ (tj. záměna příčiny a následku).
Je zřejmé, že tato chyba má své velmi nepříjemné důsledky: Při inventarizaci případů užití, což je pro vedoucího projektu resp. ScrumMastera velmi důležité pro zjištění rozsahu prací na projektu (na což existuj specifické postupy, například viz naše veřejná školení resp. školení in-house), se případy užití z první linie najednou schovají do druhé linie (tj. do druhé řady mezi „inkludované“), čímž se totálně ztrácí transparence pohledu na systém z hlediska jeho rozsahu.
Jak se této chybě vyvarovat? Na to je jednoduchý postup: Vžijme se do role Obsluhy („panáčka“), jak vidí užitek získaný z případu užití. Většinou se jedná o konečný výsledný stav, až UC doběhne. Tak je třeba případ užití nazvat a teprve poté hledat „inkludované“ případy užití, které vznikají díky opětovné použitelnosti.
Pro další vysvětlení může být nápomocna podobná situace v programování, kdy programátor chybně nazve funkci resp. metodu objektu tak, že tento název nevystihuje přesně, co se od této funkce resp. metody očekává, ale nazve ji například jejím prvním krokem.
Konec článku
Napsat komentář