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

Je vcelku zřejmé, že pokud mají vývojáři odevzdat dobrý a pokud možno bezchybně fungující informační systém, tak se soustředí v prvé řadě na to, co má tento systém dělat.  Věnují se tomu, jak mají vypadat algoritmy programu, jak se má program chovat, co má dělat – a to na začátku na logické a analytické úrovni a poté až po návrh výsledného kódu. Vývojáři jsou tedy vcelku pochopitelně zaměřeni na systém v jeho činnosti, tedy na to, co se děje, když program běží

„Programátoři programují systém a uživatel jej pak použije…“ To se může jevit jako úplná samozřejmost (od toho přece programátoři v týmu jsou), takže otázka zní: Proč se tím vlastně zabýváme?

IDLE stav systému a okolí

Oproti tomuto programátorskému pohledu na již běžící systém existuje jedna fáze vývoje (a je to hned ta první označována někdy jako „high level analysis“), kde je opravdu velmi důležité se plně soustředit naopak na situace, kdy systém ani obsluha vůbec nic nedělají a jsou v klidu.  Jedná se o stav, kdy ani obsluha a ani systém nic nepotřebují, tedy ani nic nechtějí, tj. jedná se o stav oboustranné nečinnosti. Také budeme říkat, že systém i okolí jsou v tzv. IDLE stavu.

Tento stav samozřejmě neprogramujeme, takže proč se o něj zajímat?

Poznámka: S trochou nadsázky o tomto IDLE stavu hovořím jako o situaci, kdy obsluha má nohy na stole a popíjí kafe a na straně druhé systém se taky „fláká“ a vůbec nic nedělá.

Paradoxně tento stav je z hlediska analýzy velmi důležitý (ale také velmi opomíjený).  Mnohdy totiž nastává problém v tom, že tento stav se vůbec neuvažuje a díky tomu se Use Case Model navrhne s fatálními chybami.

Mimochodem tato situace IDLE stavu je velice výhodná u zaplacených licencovaných systémů, protože uživatel sice za systém platí, ale protože kdo nic nedělá, nic se nepokazí  :).

Proč je ale tento IDLE stav tak důležitý? Vyplývá to ze samé povahy případu užití a chování okolí, tedy modelování business procesů jako kontextového modelu použití systému.

Definice případu užití prvního druhu

Jazyk UML sice nerozlišuje přímo ve své syntaxi případy užití prvního a druhého druhu, ale při jejich vyhledávání musíme respektovat toto rozlišení, které je dáno povahou užití systému okolím.

Use Case prvního druhu, který se hledá jako první, odpovídá určité šabloně  děje (a nijak jinak). Pokud této šabloně případ užití neodpovídá, tak se jedná případ užití druhého druhu (ten se hledá v jiné fázi analytického modelování, nikoliv v „high level analysis“).

Šablona definice případu užití prvního druhu je znázorněna dějem na následujícím obrázku, je třeba jej číst shora dolů, což nyní učiníme i s komentářem:

1. IDLE stav

Čteno na předešlém obrázku shora, děj začíná již vzpomínaným IDLE stavem jak u systému, tak u okolí. V tomto bodě děje si představme, že obsluha má nohy na stole, popíjí kafe a systém také nemusí nic dělat. Velmi důležité na tomto stavu je to, že je to stabilní stav v tom smyslu, že pokud by nepřišla žádná událost, tak by tento stav nicnedělání stále trval snad donekonečna, protože nikdo nic nepotřebuje a nikdo nic nechce (dokonalá nirvána). Také je to stav rovnováhy, protože vše je v klidu a vše spí.

2. Událost narušující rovnováhu

V určitém okamžiku nastane událost, buď venku v okolí anebo časová událost v systému (scheduler, služba apod.). Tato situace naruší rovnováhu nirvány a pokud je to událost venku, donutí obsluhu k nějaké činnosti (protože to má v popisu práce) anebo časová událost spustí nějakou činnost systému. Zvažme příklady vnější události: Například na stole se objeví faktura k proplacení, anebo ke skladu přijede kamion se zbožím anebo v technologickém systému se na sběrnici objeví nová zpráva apod. Na základě této události se spustí děj venku, systém stále spí.

3. Potřebnost použití systému

V rámci děje venku v určitém okamžiku nastane potřebnost použít systém. Tady identifikujeme jedno použití systému tedy případ užití („případ užití“ jako prvek v UML), který se použije. Spustí se program, který realizuje daný případ užití a který (jak doporučuji) bývá popsán například scénářem případu užití. Pokud scénář skončí jako úspěšný (Happy Scenario), pak případ užití přinese svůj užitek. A co je důležité, na konci se díky němu vyrovná dočasná nerovnováha, tj. opět následuje kýžený poslední bod této šablony, nirvána klidu, viz další bod děje…

4. IDLE stav

Obsluha i systém spokojeně ukončili práci, nerovnováha je vyrovnána a oba spokojeni se oddávají opět sladkému nicnedělání. Čeká se na další událost, která povede k dalšímu narušení rovnováhy.

Paradoxně na celé situaci při vyhledávání případů užití nejdůležitější právě zmíněné dva stavy na začátku a na konci, tedy stavy nečinnosti. Nejlépe si to ukážeme na příkladech, kde se analytik dopustil chyby díky tomu, že tyto stavy neuvažoval.  Uvidíme tak přesně, kde a jaký nastane problém.

Klasický příklad

Uveďme si klasický příklad chybného postupu při vyhledávání případů užití.

Představme si, že mám vytvořit systém evidující zakázky ve firmě a žádá se v určitém okamžiku přiřadit zaměstnance řešící tuto zakázku. Při vyhledávání případů užití pomocí procesů (BPM) analytik popsal určitou část děje (USE CASE Epic) takto:

V čem je zde chyba, když to vše z hlediska kroků děje vypadá jako v pořádku? Vždyť opravdu dojde nejprve k vybrání zaměstnance a poté jeho přiřazení k zakázce…

Jenže pokud by se systém i s jeho případy užití choval opravdu takto, jak to popsal analytik, tak dojdeme až k takřka komické a absurdní situaci, stačí si doplnit nutné IDLE stavy mezi případy užití naší již zmíněnou nadsázkou s obsluhou popíjející kafe s nohami na stole:

Jak je vidět, tak daný scénář samozřejmě neodpovídá základní šabloně pro případ užití prvního druhu. Nyní je už zřejmé, proč jsou tak důležité stavy nečinnosti systému, které si analytik při psaní tohoto scénáře neuvědomil. Rozdělení děje na jednotlivé části přes IDLE stavy vede ke správnému pochopení a podchycení chování informačního systému v krocích tak, jak jdou po sobě. Nejprve se provede krok A, potom krok B, pokud je ale splněna ta a ta podmínka, tak namísto B nastane C atd. Důležité na tom vše je to, že mezi těmito kroky jsou zmíněné IDLE stavy, protože v daném kroku při použití systému dosáhne okolí užitku a je tedy „spokojeno“ a nemusí nic dělat. Dostáváme tak pohled na systém pomocí High Level Analysis, následně pomocí modelování v syntaxi BPMN. Touto analýzou se získá možnost velmi dobré dohody s budoucím uživatelem ve smyslu „takto se budete chovat a přitom budete takto používat systém“. Pokud však navrhneme tyto kroky chybně jako v předešlém příkladu, pohled systém ztráci svou logiku a získáme tak akorát pohled na chování systému a okolí jako na obrovskou nepřehlednou hromadu střípků malých scénářů…