Proč je v analýze tak důležitý stav nečinnosti u informačního systému, 2.část

V předešlém článku bylo vysvětleno, jak se mají správně chápat případy užití prvního druhu. V definici těchto případů užití sehrává svou velmi důležitou roli stav nečinnosti, který jsme nazvali jako IDLE stav. V této části si vysvětlíme, k jakým základním až fatálním chybám dochází, pokud se tento stav opomíjí a když se hledání případů užití neprovádí korektním způsobem (i s příkladem).

Pohled na systém shora a pohled na systém zespodu

Je sice pravda, že celý informační systém lze chápat tak, že je složen ze spousty malých programů (částí kódu) a že na této skladbě kódu odspodu nahoru je postaven princip programování. Kousky kódu mají svou viditelnou hierarchii budování a skládání programu zespodu nahoru, což je implementační pohled programátora, který program tvoří a skládá.

Ale pro počáteční analýzu je o mnoho důležitější pohled na systém shora, nikoliv zespodu.

Existuje několik možných názvů tohoto počátečního pohledu na systém shora, mně osobně se nejvíc líbí název „High Level Analysis View“. V rámci tohoto pohledu vznikají dokumenty z fáze počátečního vývoje, což má na starosti analytik informačního systému. Tato fáze bývá mnohdy podceňována z toho důvodu, že systém tvoří tým „velmi silných a kvalitních programátorů“, kteří dobře vidí systém zespodu a tento pohled shora prostě buď nevidí anebo mnohdy o něm ani neví.

Když si vysvětlíme základní myšlenku High level Analysis View, zřetelně uvidíme návaznost na předešlé úvahy týkající se případů užití a stavů nečinnosti zvaných jako IDLE stavy.

Základní myšlenkou High Level Analysis View je představa, že když se používá informační systém, tak toto používání probíhá v jednotlivých krocích. Použití systému tedy není absolutně kontinuálním dějem, který běží bez přerušení. Podobně jako v kuchařce i zde platí: nejprve se dělá toto, potom toto a poté toto atd. (Tak trochu s nadsázkou bych jako bývalý fyzik tuto situaci přirovnal ke „kvantování času“)

Když se zeptáme, co tyto kroky od sebe odděluje, tedy co je mezi nimi, tak se vracíme k tématu předešlého článku: Posloupnost kroků jdoucích po sobě vypadá tak, že tyto kroky jsou od sebe zřetelně odděleny stavy nečinnosti, tedy našimi IDLE stavy, ve kterých se čeká na další událost spouštějící další krok. Celá logika děje při používání systému tedy vypadá podle této šablony:

IDLE stav -> událost -> krok -> IDLE stav -> událost -> krok atd.

Pokud tyto kroky nazveme procesy anebo aktivitami okolí, můžeme je začít modelovat pomocí syntaxe BPMN 2.0. Uvedená šablona se tak ztransformuje na následující schéma:

IDLE stav -> událost -> proces -> IDLE stav -> událost -> proces -> atd.

Procesní modelování tedy není nic jiného než velmi názorné a srozumitelné vyjádření kroků posloupnosti používání systému v krocích od jednoho IDLE stavu do dalšího IDLE stavu atd. V další úvaze se dostáváme ke spuštění případu užití v rámci daného kroku a ocitáme se přesně v již zmíněné definici případu užití prvního druhu z předešlé kapitoly. Šablona se ještě jednou transformuje a to již do této podoby:

IDLE stav -> událost -> proces spouštějící UC prvního druhu -> IDLE stav -> událost -> proces spouštějící UC prvního druhu -> atd.

Jako příklad si ukážeme model chodu procesu s případy užití u jednoduchého evidenčního systému, kde autor knih rozesílá svoje knihy jako výtisky na dobírku svým klientům (mimochodem tento diagram používám ve školení Analytické modelování v praxi – např. viz Pobytový kurz Analytické modelování pro jednotlivce ve Špindlerově Mlýně v Krkonoších – pro vysvětlení syntaxe a použití prvku„Parallel Gateway“ v BPMN 2.0):

Popis:
Zákazník pošle objednávku mailem, faxem apod. (v této verzi nikoliv přes webový formulář), obsluha ji zaeviduje (rezervace knih na skladě pro objednávku).
Účetní vystavuje fakturu a vytiskne ji a současně se na skladě vyskladní rezervované výtisky
Knihy i fatura se sejdou na jednom stole pro kompletaci do jednoho balíku.
Balík se odešle

Stále se opakující chyba degradace High Level Analysis View

Mnoho vývojářů by se nyní mohlo ozvat:

„Ale my používáme BPMN a přitom máme stále problémy s analytickým uchopením systému jako celku…“

V těchto případech jsem při analýze problémů v těchto firmách a to přímo nad jejich modely narážel na stále opakující se chybu, která je ve své podstatě snadno pochopitelná, ale opakuje se stále znovu a dokola:

Schéma posloupnosti kroků v těchto firmách vůbec neodpovídalo již zmíněné šabloně „IDLE stav -> událost -> proces spouštějící UC prvního druhu -> IDLE stav -> událost -> proces spouštějící UC prvního druhu -> atd.“.

Jako příklad v návaznosti na diagram s chodem posílání knih na dobírku bych jako „zmršený“ model uvedl tento diagram:

Je zřejmé, že výše uvedený diagram neodpovídá šabloně posloupností kroků oddělených IDLE stavy. Přece neplatí, že obsluha poté, co si vybere klienta, dá nohy na stůl a popíjí kafe s očekáváním další události…

Tvůrce tohoto diagramu se evidentně nechal vlákat do pasti popisu detailu vnitřku případu užití, který byl v prvním diagramu nazván jako „Založení objednávky“ (mimochodem který v tomto chybném diagramu vůbec není uveden, což je fatální chyba!).

Námitka ve smyslu: „Ale přece vyhledání klienta tam přece bude!“ neobstojí, protože scénář vyhledání klienta tam sice nakonec opravdu bude, ale nikoliv na úrovni High Level Analysis View, ale později a mnohem níže, a to až na úrovni Use Case Implementation Level View při popisu vnitřku případů užití jako zadání do programování.

Poznámka nakonec: Při pohledu na podobné diagramy se zeptám: „Ten diagram tvořil zkušený programátor, že ano?“ …a většinou dostanu kladnou odpověď :) .