K tomuto článku mne inspiroval jeden komentář k předešlému článku, evidentně od programátora.
K článku se ale nemusíte nyní vracet, protože jsem pro vás připravil následující výukové video na dané téma, prosím shlédněte jej a poté pokračujte ve čtení.
(BTW: Jednalo se o článek Proč je v analýze tak důležitý stav nečinnosti u informačního systému)
Pokud máte shlédnuto, posuďte nyní následující komentář k danému tématu:
Miloš:
Na druhou stranu, pokud systém zobrazí dialog pro výběr něčeho a já budu koukat z okna nebo telefonovat, půjdu na oběd, systém čeká a nic nedělá. A čeká se zobrazeným seznamem, dokud něco nevyberu nebo dialog nezavřu.
Rozdělit ale UC Vyber barvu na Zobraz barvy a Vyber barvu (to mohu přidat vložit nebo předřadit UC zadej kritéria vyhledání).
Myslím, že tento příspěvek psal „rodilý programátor“.
Problém této úvahy je totiž v tom, že vše vypadá na první pohled vcelku logicky, vždyť přece i uprostřed programu „se čeká v IDLE stavu“. Jenže zde je právě jedno opominutí, které programátor vnořený svého programu nevidí (tj. pro stromy nevidí les).
Kde je háček?
Když totiž běží program, tak implementace případu užití prvního druhu (scénář) je již spuštěna, tj. tento případ užití byl již vybrán a použit z IDLE stavu – nirvány, kdy nikdo nic nepotřebuje. Přitom platí jednoduché pravidlo , že každý užitek má svůj zrcadlový protějšek a tím je požadavek (Request). Je vcelku zřejmé, že to, co není požadováno (tj. není potřebné), tak to nemá užitek. A každý takový užitek má svůj počátek právě v požadavku, v našem případě požadavku na systém, který vede k použití případu užití prvního druhu a spuštění jeho implementace.
Pokud tedy systém zobrazí seznam a čeká na událost výběru, tak v té chvíli jsme již daleko za prvním Requestem, který vznikl ve stavu nirvány (IDLE stav), kdy nikdo nic nepotřeboval. Nyní již ale něco potřebujeme, například „zaevidovat novou došlou fakturu“, tj. Request už tam je a jeho plnění již běží k užitku
(BTW: Asi tušíme, o čem jsou případy užití druhého druhu, které vznikají až po nalezení případů užití prvního druhu. Jsou vnitřní a primárním úkolem případů užití druhého druhu je obsloužit opětovnou použitelnost, například opakující se výběr ze seznamu osob apod..)
Představme si situaci, kdy obsluha má za úkol evidovat došlé faktury. Nemá v té chvíli žádnou fakturu k zaevidování a tak kouká z okna, nebo popíjí kafe, nebo jde na oběd.
V té chvíli přijde šéf a zeptá se: „Jak to, že nic neděláte?“.
A zazní odpověď: „Momentálně není co evidovat.“
Jenže pokud přijde došlá faktura a je třeba ji zaevidovat (tj. vznikl Request a zrcadlově je použit případ užití), tak je tato situace úplně odlišná – Request už vznikl a užití běží. Šéf má opravdu právo se zlobit, že obsluha odešla na oběd od rozdělané práce.
Proto jsou důležité ty stavy nirvány, kdy nikdo nic nepotřebuje (čistý stůl), protože přesně definují první Request a následně jeho splnění, tím se dá velmi dobře. přehledně a efektivně rozdělit posloupnosti kroků zpracování.
A jedna finta nakonec:
Programátorům tuto situaci vysvětluji jako analogii s vnořenými transakcemi. Jestliže systém čeká na výběr ze seznamu, tak ta hlavní (tj. první) transakce už je spuštěna a toto je pouze jakási (víceméně „podružná“) vnitřní vnořená transakce.
Napsat komentář