Při tvorbě informačních systémů (IS) hraje nezastupitelnou roli USE CASE MODEL (model případů užití). Díky tvorbě tohoto modelu se nejen výrazně ztransparentní vývoj IS, ale díky tomuto modelu (pokud je tvořen správně, rychle a podle šablon) je možné efektivně tvořit další důležité dokumenty projektu, které by jinak vznikaly „z čisté vody“, tedy opakovaně. Tvorba USE CASE MODELU, která se jeví na první pohled jako „práce navíc“ takto paradoxně šetří práci. Další dokumenty nutné pro projekt, jako jsou např.:

seznam funkcionalit pro vedoucího projektu (seznam nutný pro řízení projektu)
uživatelská příručka,
funkční specifikace produktu tj. dodatek obchodní smlouvy,
dokumenty pro obchodní nabídku,
plány testů
apod.

vznikají z tohoto dokumentu jednoduchými úpravami. Pro získání těchto dokumentů stačí export z CASE nástroje a následná úprava dokumentu v RTF nebo HTML formátu. Vedoucí projektu má takto k dispozici nejenom dokument, který mu slouží k přehledu nad projektem, ale slouží také jako zdroj pro vznik dalších dokumentů nezbytných pro projekt. (blíže viz například produkt EFEM UC MODELING na tomto serveru)

Při tvorbě USE CASE MODELU vzniká vcelku logická otázka, jak nalézt všechny prvky USE CASE a na žádný přitom nezapomenout. Pokud je systém jenom trochu složitější, nelze nalézt všechny případy užití výčtem. Vyvstává tedy otázka systematického postupu vyhledávání všech případů užití (všech funkcionalit systému).

V metodikách, které se zabývají postupy tvorby informačních systémů, lze u tvorby modelů typu USE CASE (modely případů užití) vypozorovat dva základní přístupy pro vyhledávání případů užití.

Přístup přes prvky ACTOR

V prvním z těchto přístupů, označme jej jako „přístup přes prvky typu ACTOR (aktér)“ hraje důležitou roli právě prvek okolí, tj. prvek ACTOR. V tomto postupu se vyhledávají prvky okolí (prvky ACTOR) a na základě těchto prvků se poté určuje funkcionalita systému. Úvaha zní vcelku logicky: Kdo nebo co všechno musí komunikovat se systémem a proč? Následuje výčet funkcionalit, které tento prvek potřebuje od systému. V tomto případě je význam prvků ACTOR velmi důležitý. Chybné určení prvků ACTOR nebo dokonce jejich vynechání vede k chybám v modelu případů užití.

Přístup přes BPM

Druhý možný postup se obrací na modelování procesů podniku (tzv. BUSINESS PROCESS MODELING neboli BPM). Při tomto přístupu se jako první nevyhledávají prvky okolí (prvky ACTOR), ale procesy podniku, které budou podporovány systémem. Přístup je od předešlého velmi odlišný: Ve chvíli tvorby modelu procesů podniku není až tak zajímavé „kdo“ je onen objekt z okolí, který komunikuje se systémem, ale „co se děje v okolí“, že je třeba systém třeba použít. Tímto způsobem lze získat (pomocí rozkladu procesů apod.) systematický výčet všech procesů podniku a následně také případy užití systému. Tento postup převzala a využívá také technologie EFEM UC MODELING (viz nabídka tohoto serveru). Prvek ACTOR vstupuje do hry až po tomto vyhledání procesů a případů užití a slouží ke třem účelům:

Slouží k verifikaci (inventarizaci), že máme všechny procesy a všechny případy užití v pořádku. Kladou se kontrolní dotazy, například takto: A co taková uklízečka? Nebude ona potřebovat IS?

Slouží k identifikaci interfaců systému (každá spojnice mezi prvkem ACTOR a prvkem případu užití implikuje nějaký interface systému, důležité hlavně u prvků ACTOR typu externí systém)

Slouží jako pěkný okrasný prvek diagramů

Porovnání obou přístupů

Zkušenost ukazuje, že druhý způsob, tj. postup vyhledání prvků USE CASE přes BPM, je mnohem schůdnější, efektivnější a méně chybový.

Hlavní důvody jsou tyto:

Znázornění prvků ACTOR narušuje základní princip anonymity klienta systému. Pokud navrhujeme systém, nevíme, kdo „je na druhé straně“, tj. mimo systém. Snaha o specifikaci prvků ACTOR vede k neplodným diskusím, kdo je vlastně za klávesnicí. (jak pro programátora nezajímavé, kdo program vlastně používá!). Pokud si klient zakládá účet na pobočce banky, a nalezne se prvek USE CASE s názvem „Založení běžného účtu klientovi na přepážce banky“, tak kdo je vlastně prvkem ACTOR? Klient nebo Obsluha? Jinak řečeno, který z těchto dvou obrázků

a následující

je vlastně správně?

Zažil jsem podobnou situaci: Tým se v diskusi rozdělil na dva nesmiřitelné tábory. Jedni argumentují: Přece nebudete tvrdit, že klient přeskočí přepážku, odstrčí obsluhu a naťuká si to sám? Druzí naopak tvrdí: Prvkem ACTOR je Klient a ta vaše odstrčená Obsluha je jenom prostředník! Ta přece nic do systému nepřináší, ona pouze zprostředkuje. To už tam můžete dát taky klávesnici a monitor, protože ona ta Obsluha jinou funkci nemá! A navíc, přece nebudete tvrdit, že tento případ užití je tu pro Obsluhu! Případ užití je pro Klienta, jak je již patrné v názvu případu užití. Jemu přináší užitek, Obsluha by se na to nejraději vykašlala, kdyby mohla… A kdo má pravdu? Diskuse tohoto typu jsou neplodné a zbytečné, protože z hlediska návrhu samotného případu užití a jeho scénáře jsou tyto věci nezajímavé.

Práce s prvky ACTOR vede k častým chybám také při určení, kdo všechno vlastně komunikuje s prvkem případu užití s následnou záměnou pojmu Role z přístupových práv. Vezměme takovýto příklad: V knihovně existuje evidenční systém, který umožňuje, aby se čtenář přes intranet dozvěděl, zda je hledaná kniha k dispozici a kde se nachází. Nalezneme tyto prvky okolí: Knihovník, Administrátor a Čtenář. Mějme případ užití Prohlížení titulů knihovny. Kdo všechno je prvkem okolí? Následující úvaha je chybná: Všichni tři mohou prohlížet tituly, takže se chybně namaluje následující obrázek:

Pokud autor namaluje předešlý obrázek, vyjádřil tím úplně jinou skutečnost, než jakou původně zamýšlel: V probíhajícím scénáři případu užití „Prohlížení titulů knihovny“ existují tři použité kanály (interfacy), jeden v kontextu Knihovníka, druhý v kontextu Čtenáře, třetí v kontextu Administrátora. V daném scénáři „Prohlížení“ by každý z nich musel do scénáře něčím přispět, což není pravda. Designér při pohledu na tento obrázek usuzuje, že v daném scénáři budou existovat tři komunikace (kontexty přístupu k systému). V tomto případě pro tento případ užití by bylo vhodné zvolit buď „neutrální“ název Obsluha anebo zvolit pouze prvek Čtenář. V druhém případě nastává drobný problém: Neznalým problematiky je třeba vysvětlit, že ten, kdo si prohlíží tituly, není ani Administrátor, ani Knihovník, ale je to ten, kdo vstupuje do prvku ACTOR Čtenář. Název Obsluha je v tomto případě méně kolizní a proto lepší.

Na druhou stranu se může stát, že daný prvek USE CASE vskutku interaguje hned s několika prvky ACTOR a nejedná se o chybu. Například v procesu podniku bankovní služby typu GSM nalezneme následující popisu : „Klient GSM pošle zprávu do banky, ta se vyhodnotí v bankovním informačním systému a odpověd se pošle buď zpátky klientovi anebo na fax nebo e-mail“. Odpovídající část modelu pro případ užití zpracování služby pak vypadat takto:

obrázek 1 Prvky ACTOR správně identifikují interfacy

Na předešlém obrázku je zřetelně vidět, jaké vstupy a výstupy se budou řešit, jsou to průsečíky interakcí v bodech BOUNDARY s interakcí USE. Nalezly se tři problémy interfaců k řešení, které se skutečně musely řešit až do kódu (práce s modemem GSM, vstupní kanál banky, emailový a faxový klient)

Nejpádnější důvod pro to, aby se pro počáteční vyhledání případů užití používaly zásadně procesy podniku, je následující: Pokud nalezneme prvek ACTOR jako prvek okolí, stejně je tento prvek pro nás synonymem činností, tj. procesů v okolí. Vysvětleme si to na předešlém příkladu, kde byl nalezen prvek ACTOR Knihovník. Ale stačí nám to, že jsme nalezli prvek Knihovník? Stejně se nakonec ptáme, a co to vlastně znamená, že jsme nalezli Knihovníka, tedy ptáme se, co vlastně knihovník dělá? Je to ten, kdo zavádí nové knihy, eviduje čtenáře, rozesílá upomínky atd. Tedy lze říci, že prvek ACTOR je objekt z okolí systému, který je účasten v procesu podniku, „personifikuje“ jej, je jeho nositelem a proto nalezení procesu (zatím bez prvku ACTOR) je mnohem důležitější, protože tento proces podniku určuje kontext užití systému přesně a bez diskusí ohledně názvu a významu prvku ACTOR (tj. odpadá otázka „kdo to vlastně je ten na druhé straně mimo systém“).

Samozřejmě to neznamená, že se vyhledávání prvků ACTOR vyhneme. Pouze je jim dána jiná pozice v tvorbě USE CASE MODELU než u prvního přístupu.

Závěrem lze konstatovat, že postup vyhledání prvků USE CASE přes prvky ACTOR je pracnější, více chybové a méně efektivní s mnoha neplodnými diskusemi. Mnohem snazší je vyhledávát případy užití přes procesy podniku.

Doporučený postup práce s prvky ACTOR je na základě praxe následující:

Vyhledejte procesy podniku a na základě nich případy užití. Pokud v této chvíli „narazíte“ na prvek ACTOR, tak jeho význam je pouze podpora tohoto cíle „vyhledání procesů podniku a poté prvků užití“. Například výčet všech externích systémů lépe umožní nalézt všechny procesy, které vedou ke komunikaci s těmito systémy. Cílem tohoto kroku není nalézt prvky ACTOR, ale procesy podniku.

Prvky ACTOR se poté znázorňují v diagramech jako objekty účastnící se procesů podniku a interagující s prvky USE CASE. Díky tomu se jednak verifikuje, že máme všechny procesy a všechny případy užití, ale také se identifikují všechny interfacy systému. Nezapomeňme, že diagramy se díky prvkům typu ACTOR také zkrášlí, což je významná část dokumentace pro odběratele, který prvky typu ACTOR v diagramech rád vidí.

Všechny odpovídající postupy tvorby USE CASE MODELU jsou podrobně rozepsány v postupkách EFEM UC MODELING až do návodů k "poslednímu" kliknutí v nástroji EA. Ve firmě tak lze jednoduše zavést odpovídající postupy velmi jednoduchou formou. Blíže viz nabídka našeho serveru.