Praxe AAF 5: AI a Use Case Scenario

This entry is část 5 z 5 in the series Praktické kapitoly Agilní analýzy s AI

Minule jsme ze schváleného Zlatého chodu procesu vytáhli prvky Use Case 1. druhu — body, kde se systém skutečně použije. Tím jsme se dostali na hranici mezi HLA a LLA.

Use Case 1. druhu funguje jako interface v OOP: zvenku nabízí možnost použití, uvnitř je jeho implementace ve formě scénáře. Tenhle díl je právě o tom vnitřku — o scénáři Use Case. A hlavně o tom, proč jeho psaní není sloh, ale řemeslo s pevnými pravidly, díky kterým je výstup konzistentní a srozumitelný i pro AI.

Co je scénář Use Case

Vnitřní scénář Use Case 1. druhu je implementace — popis algoritmu, který pracuje s pojmy a vztahy z Class Modelu (CLM).

Není to vyprávění. Není to obrazovkový popis typu „obsluha klikne, otevře se obrazovka“.
Je to čistý algoritmus programu — nic víc, nic míň. Logika.

Základem je tzv. Scénářový vzor (Scenario Pattern) jako kanonická formulace, kterou se v textu scénáře vyjadřuje práce s konkrétním vztahem z CLM. Pro tentýž vztah se v každém Use Case použije stejná věta. Liší se jen podle toho, kdo akci provádí — obsluha nebo systém.
Pojmy ve formulacích jsou povinně z CLM. To je základní kámen celé metody.

Příklad vzoru „Odkaz do seznamu“

Pro prvek Obsluha:
„Obsluze se zobrazí seznam <destination>. Obsluha vybere <destination> a <source> se prováže na daný prvek .“

Pro Systém:
„Přijme se kód <destination> . Podle tohoto kódu se v seznamu <destination> najde <destination> . Pokud nenalezen, ERR__NENALEZEN.

<source> se prováže na nalezený prvek <destination>.“

Vzory jako pilíře konstrukce

Tady je jádro celého dílu.
Scénář není volný text. Pracuje nad centrálním slovníkem — CLM, jediným zdrojem pravdy o tom, jaké pojmy existují a jaké jsou mezi nimi vztahy (ty jsou také striktně dány kanonickými vzory).
Platí zásadní META pravidlo:

Tentýž vztah z Class Modelu se musí ve všech scénářích promítnout stejným scénářovým vzorem.

Nemůže se stát, že v jednom Use Case se vztah popíše jako Odkaz do seznamu a v jiném jako Kompozice. To by znamenalo rozpad centrálního slovníku.

Protože daný vztah je v modelu jeden, jsou pravidla psaní scénářů napříč všemi prvky Use Case stejná.
Není to estetika. Je to nutný důsledek sdíleného slovníku a pravidel jeho použití.

A právě tahle předurčenost dělá scénář kontrolovatelný a reprodukovatelný: dva analytici (včetně AI) musí pro tentýž vztah napsat tutéž větu. A tam, kde není volnost, není prostor pro hádání — ideální půda pro AI.

Jak si s tím poradí AI: MTP

Aby to nezůstalo u teorie, vzali jsme syrový scénář Use Case z původní dokumentace MTP (ještě pre‑AAF, styl SCRUM/UML) a nechali AI Analytika provést jeho dotažení do AAF/LLA podoby.
Syrový nástřel, tak jak přišel z původní dokumentace (pre‑AAF, SCRUM/UML):

UC Vygenerování čekající platby (vstup Identifikace kina, částka) (výstup kód rezervace) { provede se UC Verifikace kina {Identifikace kina} vrací se nalezené verifikované Kino (není řešeno v tomto kroku iterace) Vytvoří se nový prvek Platba a naváže se na nalezené Kino. Vytvoří se nový kód rezervace a vloží se spolu s prvkem přijatá částka do nového prvku Platba. Vytvoří se nový prvek Stav platby a přidá se do seznamu stavů platby daného prvku Platba, vloží se do něj aktuální timestamp a prováže se na prvek číselníku Stav pro platby {kod = 1, čekající}. Vrací se kód rezervace resp. chybový stav. }

AI prošla scénář větu po větě a u každé práce s daty rozpoznala vztah z CLM a dosadila odpovídající vzor. Konkrétně:

rozpoznala složený vzor „Vlak má svoje vagóny“ (Kompozice ku N + Odkaz do seznamu) tam, kde se zapisoval stav platby;
odhalila pojem, který v CLM vůbec není — fiktivní „kód = 1“; označila ho za porušení slovníku a podala návrh;
převedla volání jiného Use Case do rezervovaného tvaru „použije se UC X“ a „vrácená hodnota se dosadí do Y“;
doplnila chybějící Exception Flow (ERR_…), sjednotila psaní pojmů velkým písmenem, opravila předávání parametrů přes primitivní identifikátor.

A hlavně — nehádala.
Co scénář jednoznačně neurčoval, AI nevyplnila potichu. Vrátila to jako strukturované dotazy s doporučením.

Svůj konečný návrh scénáře postavila na doporučených variantách s výhradou „čeká na potvrzení“:

UC Vygenerování čekající platby (vstup Identifikace kina : řetězec, Částka : peněžní částka) (výstup Kód rezervace : řetězec) { // verifikace kina použije se UC Verifikace kina (Identifikace kina); vrácená hodnota se dosadí do Kino. pokud se Kino nevrátí (neverifikováno), ERR_KINO_NEVERIFIKOVANO. // založení Platby vytvoří se nová Platba a prováže se na nalezené Kino. vygeneruje se nový Kód rezervace a dosadí se do Platby; do Platby se dosadí přijatá Částka. // založení čekajícího stavu (Vlak má svoje vagóny: Stav platby je vagón, Stav pro platby je sdílená položka) vytvoří se nový Stav platby a vloží se do seznamu stavů dané Platby. do Stav platby se dosadí aktuální datum a čas (Pozn. AM→Design: mechanismus získání času = Design). v seznamu Stav pro platby se najde Stav pro platby s hodnotou čekající; Stav platby se prováže na nalezený prvek. // návrat vrátí se Kód rezervace dané Platby. } ERR_KINO_NEVERIFIKOVANO (červený, stop): Kino se podle Identifikace kina neverifikovalo; Platba nevznikne, UC končí chybou.

Jediná připomínka k návrhu AI: Číselník Stav je pevný; čekající je konstantní položka, takže se nehledá, ale dosadí se konstantní odkaz.

Pokud si chcete prohlédnout celý test, viz protokol testu (= vstup + odpověď).

Ověření na jiné doméně: skladová rezervace

Aby bylo jasné, že to není naučené zrovna na MTP, pustili jsme stejný postup na úplně jinou doménu — skladovou rezervaci.

Tady jsou vstupní syrové scénáře UC pro zpracování v testu:

UC Rezervace zboží (vstup kód zboží, objednané množství, odběratel) { najde se skladová položka podle kódu zboží spočítá se dostupnost: dostupné množství = množství na skladě + suma množství aktivních rezervací ověří se dostupnost pokud dostupné množství > objednané množství vytvoří se nová rezervace, vygeneruje se kód rezervace, uloží se množství a časová značka rezervace se přidá k položce použije se UC Potvrzení objednávky (Objednávka) jinak nic } UC Dostupné množství (skladová položka) { vrátí se množství na skladě minus rezervace } UC Zrušení rezervace (kód rezervace) { najde se rezervace s tímto kódem najde se šarže s tímto kódem rezervace se zruší (stav zrušená), zákazník se informuje }

AI stejně jako u MTP:

rozpoznala vzory podle vztahů z CLM,
držela slovník (chytila pojem „Šarže“, který v CLM není, i synonymum „odběratel“ vs. „Zákazník“),
doplnila ERR_NEDOSTATEK,
trvala na primitivním identifikátoru na hranici Use Case,
upozornila na místo, kde hrozí souběh alias kolize paralelních běhů — přechod z analytické úrovně do Designu (nedělitelnost operace, konzistence čtení).

Pokud máte zájem nahlédnout do detailů testu, viz zde.

Navrhovaný scénář od AI (uvnitř jsou odkazy na nálezy, které by bylo vhodné opravit nebo upřesnit)

UC Rezervace zboží (Kód zboží, Číslo objednávky, Kód zákazníka) // hranice = primitivní id [A, B, F] { // najdi skladovou položku V seznamu Skladových položek se najde Skladová položka s tímto Kódem zboží. Pokud nenalezena, ERR_SKLADOVA_POLOZKA_NENALEZENA. // najdi objednávku — zdroj Objednaného množství (ZZI) [F] V seznamu Objednávek se najde Objednávka s tímto Číslem objednávky. Pokud nenalezena, ERR_OBJEDNAVKA_NENALEZENA. // najdi zákazníka [A, B, G] V seznamu Zákazníků se najde Zákazník s tímto Kódem zákazníka. Pokud nenalezen, ERR_ZAKAZNIK_NENALEZEN. // zjisti dostupnost (bez duplikace výpočtu — include) Použije se UC Dej dostupné množství (Kód zboží). Vrácená hodnota se dosadí do Dostupného množství. // rozhodnutí o rezervaci Pokud Dostupné množství >= Objednané množství Objednávky: // [dotaz D] Vytvoří se nová Rezervace a vloží se do seznamu Rezervací dané Skladové položky. // Kompozice ku N Vygeneruje se Kód rezervace. Množství Rezervace = Objednané množství Objednávky. Časová značka Rezervace = aktuální okamžik. Stav Rezervace = aktivní. // [dotaz H] Rezervace se prováže na nalezeného Zákazníka. // [dotaz G] Použije se UC Potvrzení objednávky (Číslo objednávky). // primitivní id, ne celá Class Pokud Dostupné množství < Objednané množství Objednávky: ERR_NEDOSTATEK_ZASOB. // Pozn. AM→Design: čtení dostupnosti + vznik Rezervace nad touž Skladovou položkou je // check-then-act → požadavek KONZISTENCE ČTENÍ a NEDĚLITELNOST vůči souběžným // rezervacím téže Skladové položky. Mechanismus (zámek/transakce/preempce) = Design. } ERR_SKLADOVA_POLOZKA_NENALEZENA: červený (stop). ERR_OBJEDNAVKA_NENALEZENA: červený (stop). ERR_ZAKAZNIK_NENALEZEN: červený (stop). ERR_NEDOSTATEK_ZASOB: warning/stop — povaha k rozhodnutí PO [dotaz: žlutý × červený]. UC Dej dostupné množství (Kód zboží) // činnostní název [13]; hranice = primitivní id [14] { V seznamu Skladových položek se najde Skladová položka s tímto Kódem zboží. Pokud nenalezena, ERR_SKLADOVA_POLOZKA_NENALEZENA. Najdou se všechny Rezervace dané Skladové položky ve Stavu aktivní. Dostupné množství = Množství na skladě − suma Množství těchto Rezervací. // [dotaz C] Vrátí se Dostupné množství. // Pozn. AM→Design: čtená Skladová položka a její Rezervace se během výpočtu nesmí změnit // (KONZISTENCE ČTENÍ). Služba neslibuje trvanlivost hodnoty po návratu. Mechanismus = Design. } ERR_SKLADOVA_POLOZKA_NENALEZENA: červený (stop). UC Zrušení rezervace (Kód rezervace) { V seznamu Rezervací se najde Rezervace s tímto Kódem rezervace. Pokud nenalezena, ERR_REZERVACE_NENALEZENA. Pokud Stav Rezervace není aktivní, ERR_REZERVACE_NELZE_ZRUSIT. // [dotaz H] Stav Rezervace = zrušená. // krok „najde se šarže“ odstraněn — pojem mimo CLM [dotaz E] // informování zákazníka [dotaz G] Z Rezervace se naviguje na jejího Zákazníka. // Pozn. AM→Design: Zákazníkovi se odešle informace o zrušení Rezervace // (logický požadavek; kanál/forma = Design). } ERR_REZERVACE_NENALEZENA: červený (stop). ERR_REZERVACE_NELZE_ZRUSIT: červený (stop).

Poznámka: Tady by se hodilo u Zrušení rezervace ošetřit podmínky, které by se měly zkontrolovat, než se rezervace zruší. Nejlépe pomocí vzoru Reakce tj. princip Open / Closed – analogie GOF vzoru Observer resp. JAVA Listener

Test potvrdil: Jiná doména, tytéž vzory, stejný mechanismus, stejný výsledek. Protože vzor neurčuje doména, ale vztah v Class Modelu.

Pointa

Všimněte si, k čemu došlo:

Nestavělo se od nuly — vyšlo se ze scénáře, který už existoval, a jen se dotáhl podle pravidel.

Scénář se nepsal „od oka“, ale podle vzorů předurčených Class Modelem. Tentýž vztah → tatáž věta.

Reprodukovatelnost a kontrolovatelnost jako druhý pár očí.

Scénář a pojmy CLM se budují ruka v ruce — změna slovníku znamená změnu scénáře. A oběma oblastem AI dobře rozumí a kontroluje konzistenci mezi nimi. To je základ zachování hodnoty pro zákazníka: toto se eviduje (CLM), takto se s tím tady pracuje (UC Scenario) a je to umístěno tady v celkovém kontextu používání systému (HLA s tokem děje a UC 1. druhu).

Předurčenost pomocí vzorů dělá metodu uchopitelnou pro AI — ta nemusí vymýšlet formulace, jen aplikuje vzor.

Navíc metodika určuje, co je třeba kdy udělat. Žádný „Claptrap Driven Project“.
Postup vyžaduje:

musí se odevzdat UC scénář povinně s protokolem AI,
ergo musí se před tím najít Use Case cinknutím (AI protokol),
ergo před tím musí existovat Use Case Epic.

Je to pořád stejná myšlenka přístupu „Document Driven Project“, jen zase o kus dál.

Zavádění metodiky se opět realizuje samotnou praxí: AI současně zastává roli AI Mentora. Analytici se učí vzory scénářů tak, že je tvoří: pokud se „netrefí“ formulací, AI oponuje a doporučí změny.

Co bude dál

V článku se několikrát zdůraznilo, že napsat scénář bez pojmů ze slovníku nelze (platí nejenom pro UC scénáře).

Takže příště si ukážeme, jak jsou zavedeny vzory v Class Modelu a jak s nimi pracuje AI.

Chcete to u vás?

Zaujaly vás tyhle postupy a rádi byste je používali i u vás? Napište mi na objects@objects.cz anebo pošlete zprávu na LinkedIn, nezávazně probereme možnosti.