Use Case 1. druhu

Úvod

Tato kapitola zavádí pojem Use Case 1. druhu jako elementární jednotku použití systému zvenčí, při které systém vykoná určitou službu a vrátí okolí výsledek, pro který byl použit.

V UML je Use Case definován obecně jako pojem spojený s užitkem prvku daného typu. AAF tento obecný pojem zpřesňuje a zavádí dva druhy. Use Case 1. druhu je primární a odpovídá užitku celého systému vůči jeho okolí. Use Case 2. druhu je sekundární, vzniká refaktorizací uvnitř systému přes interakci include a je definován v samostatné kapitole.

Use Case 1. druhu

Use Case 1. druhu je definován prostřednictvím šablony děje Okolí–Systém. Děj postupuje v sedmi krocích od stavu rovnováhy zpět do stavu rovnováhy.

Na začátku se Okolí i Systém nacházejí ve stavu nečinnosti, kdy nikdo nic nepotřebuje a nic se neděje. AAF tento stav označuje jako stav rovnováhy.

V Okolí dojde k události, která tento stav naruší. Děj v Okolí se začne vykonávat. Systém o této události zatím nic neví.

Děj v Okolí dospěje do bodu, kdy je třeba použít Systém. Tento bod nazýváme bod potřebnosti použití systému, alias cinknutí systému (jako ve výtahu).

V tomto bodě děje Okolí použije, alias vyvolá daný Use Case 1. druhu.

Use Case má ve své vnitřní implementaci scénář, který reprezentuje program. Tento scénář se začne vykonávat. Děj nyní pokračuje uvnitř Systému.

Scénář doběhne do svého konce. Pokud skončí jako Happy Scenario, Use Case předává děj zpět do Okolí a vrací mu užitek, pro který byl použit.

Děj v Okolí dokončí svůj zbytek. Okolí i Systém se vrátí do stavu rovnováhy a čeká na další událost, která rovnováhu naruší.

Pokud struktura Use Case této šabloně neodpovídá, není to Use Case 1. druhu.

Poznámka: Spouštěčem prvku Use Case může být i časová událost.

Důsledek pro kroky procesu. Šablona děje od rovnováhy k rovnováze není pouze popisem životního cyklu Use Case 1. druhu. Je zároveň generátorem korektně vymezených kroků procesu v Okolí. Tím, že každý Use Case 1. druhu začíná a končí ve stavu rovnováhy, vzniká přirozené dělení procesu Okolí na kroky, kde každý krok odpovídá právě jednomu úseku mezi dvěma rovnováhami. Striktní dodržování pravidla rovnováha–rovnováha tak zaručuje, že kroky procesu jsou definovány korektně a nejsou ani drobeny do střípků, ani slepovány do nepřehledných celků. Tato vlastnost je důsledkem definice a využívá se při hledání UC z procesu i naopak při kontrole správnosti procesní mapy.

Rozlišující znaky

Use Case 1. druhu je správně identifikovaný, pokud splňuje následující znaky.

Začíná a končí ve stavu rovnováhy. Pokud nelze identifikovat výchozí ani cílový stav rovnováhy, Use Case je špatně vymezený.

Jeho název vyjadřuje užitek pro Okolí, ne technickou operaci. Název typu „Zaevidování došlé faktury" je správný, název typu „Vložení záznamu do databáze" je špatný.

Je vyvolán z konkrétního bodu v procesu okolí. Bez tohoto bodu Use Case nemá zdroj použití a nelze ověřit, zda je v systému potřeba.

Jeho scénář popisuje pouze vnitřní implementaci, tedy LLA. Nemíchá se s popisem děje okolí, který patří do HLA.

Pokud končí Happy Scenario, vrací Okolí užitek odpovídající jeho názvu nebo kontextem blízký k jeho názvu.

Příklady

Do firmy přijde faktura k proplacení. Obsluha ji chce zaevidovat. Tento příběh tvoří jeden Use Case 1. druhu.

Výchozí stav rovnováhy je nečinnost, kdy obsluha sedí u stolu a systém nic nedělá. Událost spouštějící děj v Okolí je příchod faktury. Děj v Okolí pokračuje tím, že obsluha vezme fakturu a rozhodne se ji zaevidovat. Bod potřebnosti použít systém nastane v okamžiku, kdy obsluha přistoupí k systému s úmyslem fakturu zaevidovat. Vyvolá se Use Case Zaevidování došlé faktury. Scénář Use Case proběhne, faktura je zaevidována. Use Case vrátí užitek, tedy potvrzení, že faktura je v systému. Obsluha pokračuje v Okolí dalšími kroky a nakonec se vrací do stavu rovnováhy.

Nejčastější chyby

Nejčastější chybou je střípkování, kdy se Use Case definuje jako jeden krok scénáře místo celého děje od rovnováhy k rovnováze. Vznikají tak Use Case typu „Zadej heslo", „Klikni na tlačítko", což jsou kroky scénáře, ne samostatné Use Case 1. druhu.

Druhou typickou chybou je míchání HLA a LLA. Scénář Use Case popisuje vnitřní implementaci a nesmí obsahovat popis toho, co se děje v okolí systému před voláním Use Case nebo po jeho dokončení.

Třetí chybou je předčasné vynoření, kdy se Use Case předčasně ukončí scénář bez dosažení užitku, pro který existuje.

Čtvrtou chybou je pojmenování Use Case přes technickou operaci místo přes užitek. Název má vyjadřovat to, co Okolí získává, ne to, jak a co Systém dělá technicky.

Vazby

Rozpracováno.

Verze a změny

• 2.0 — refaktor na v9 šablonu Definice. Odstranění číslovaných nadpisů, sloučení obsahu pod jeden pojem H2 Use Case 1. druhu. Sekce Indikátory kvality přesunuta do ### Rozlišující znaky pod pojmem. Sekce Vstupy, Výstupy, Jak to používá AI odstraněny (nepatří do typu Definice). Sekce Mini-příklad přejmenována na Příklady. Sekce Vazby na ostatní kapitoly přejmenována na Vazby a označena placeholderem Rozpracováno. Odstraněny pracovní HTML komentáře. H1 přejmenován z Definice Use Case 1. druhu na Use Case 1. druhu (sjednocení s name).
• 1.0 — první verze kapitoly.