Když se analytik poprvé seznámí s teorií týkající se návrhu analytického modelu případů užití (tzv. USE CASE MODELING), ocení její přínos pro návrh systému. Díky této teorii se mu dostává do rukou silná zbraň pro zpracování nepřeberné haldy funkcionálních požadavků a to navíc přehledným srozumitelným a systematickým způsobem.

Celá teorie návrhu USE CASE MODELU na něj nejprve zapůsobí dojmem, že je to „brnkačka“. Všechno je na první dojem jasné a „no problem“. Pokud totiž vidíme případy užití již správně a korektně navržené a tedy bez chyb, je na první pohled vše jednoduché a srozumitelné. Problém spočívá v tom, že v praxi musíme nejprve správné případy užití navrhnout a tedy v této fázi je ještě nevidíme. Najednou se vynořuje řada otázek a naráží se na možné chyby a nejistoty, jestli je to správně. Už to není „no problém“, ale spíše velký problém.

Při školeních a konzultacích se často setkávám s jednou z nejčastějších chyb a tou je „přílišné kouskování případů užití“. Nejprve jsem na tuto chybu narazil při konzultaci v jedné firmě, která vyvíjí informační systémy pro velké obchodní řetězce, kde mi byl předložen USE CASE MODEL se spoustou „malých případů užití“, které však všechny neměly nárok na život. Shodou okolností jsem se se stejnou chybou setkal minulý týden u účastníků Kurzu profesního růstu analytika AM PROFESSIONAL (distanční e-kurz), kteří měli za úkol podle metodických pokynů kurzu a zadání (zadání aplikace viz zde) odhalit chod jednoho složitějšího podnikového procesu malé dílny a odevzdat nalezené případy užití informačního systému. Účastníkům kurzu jsem tuto chybu podrobně popsal a přímo v praxi vysvětlil. A do třetice: Tento týden jsem při konzultaci v jedné bance řešil úplně stejný problém.

Je vidět, chyba je to poměrně dost častá a musím podotknout, že je také dost záludná, protože k jejímu odhalení musí mít analytik nejen dobré znalosti, ale také větší praktické zkušenosti.

Podstata chyby

Vše začíná vcelku rozumně a správně: Nejprve se analytikovi podaří posbírat funkční požadavky a vznikne tak jakýsi nepřehledný výčet toho, „co to má umět“. Pak je třeba se vypořádat s touto nepřehlednou haldou všech možných funkčních kroků ve smyslu „je třeba „zaevidovat toto takto“ a také „je třeba evidovat toto“ a taky nezapomeňte na „toto“.

Například ve zmíněné aplikaci Kurzu profesního růstu analytika AM PROFESSIONAL (viz již uvedené zadání) je třeba v informačním systému dílny na základě objednávky založit výrobní zakázku, je třeba určit, co se vyrobí a co se vyskladní, je třeba přiřadit pracovníky do výroby, je třeba zahájit výrobu výrobku, nahlásit ukončení výroby výrobku, vyskladnit materiál a je třeba naprogramovat spoustu jiných dalších kroků evidence podporujících chod dílny.

Podobně v oné bance je třeba klientovi poskytnout bankovní produkt tak, že se při založení produktu identifikuje klient, produkt se namodeluje, vyberou se nejlepší možnosti produktu, připraví se podklady, produkt se odsouhlasí, atd.

Podstata zmíněné chyby kouskování případů užití spočívá v tom, že tyto jednotlivé kroky zpracování nemusí být a většinou ani nejsou přímo hledané případy užití, které se spouštějí z podnikových procesů jako případy užití reagující na událost potřebnosti zvně. Jsou to ve většině pouze jejich části, tedy jsou to jen kroky (ještě výstižněji pouze „krůčky“), které tyto hledané případy užití obsahují.

Nejlépe si tento rozdíl uvědomíme na triviálním příkladu: V systému se evidují osoby. U dané osoby lze změnit její příjmení (ať už s historií nebo ne). Pokud bychom přijali tezi, že díky změně příjmení se spustí případ užití z procesu (tj. jedná se o případ užití „prvního druhu“), potom bychom pro každou možnou další změnu i u jiných atributů zaváděli další a další případy užití. Vzato ad absurdum, pokud bychom měli entitu o dvaceti atributech, zavedli bychom podle tohoto principu dvacet malých případů užití, což je samozřejmě nesmysl.

Otázkou tedy je, jak tuto situaci řešit a jak správně postupovat?

Rady k řešení

Přestože se jednotlivá řešení procesních modelů podniku a následně modelu případů užití liší případ od případu, lze alespoň orientačně vyjmenovat obecně platná pravidla správných postupů:

1. Případů užití bývá obvykle mnohem méně, než je kroků zpracování. Model chodu procesu bývá jednoduchý a srozumitelný. Správný model případů užití je velmi transparentní. Pokud tomu tak není a diagramy případů užití vypadají jako změť příliš mnoha nepřehledných kousků funkcionalit, potom je USE CASE MODEL určitě špatně!

2. Dobré scénáře případů užití bývají spíše delší než kratší (s výjimkou několika málo výjimečných případů užití typu storno, zastavení produktu apod.), tj. krátký scénář je pro analytika signálem pro zahájení kontroly, zda náhodou není scénář případu užití neúplný. Není totiž správné vynořit se ze scénáře případu užití dříve, než je třeba. Jinými slovy: Chybou je, když scénář skončí dříve, než měl, neboť de facto popisuje nedokončený případ užití. Například proč nedovolit obsluze, aby při založení bankovního produktu mohla zmíněný produkt také hned namodelovat jako další krok zpracování uvnitř tohoto scénáře? Scénář případu užití by měl končit až tam, kde již nelze logicky vzato dále ve scénáři pokračovat, kdy například další zpracování kroků probíhá „odjinud“ anebo „jinou odpovědnou osobou“ apod.

3. Je třeba vždy zvážit možnost návratu obsluhy k rozdělané práci a kdy už to nelze. V uvedeném příklad z banky to znamená možnost návratu ke krokům nastavení bankovního produktu a co se stane po odsouhlasení.

4. Věnujte pozornost „stavovosti evidovaných entit“, tj. jak se mění stavy evidovaných entit, to vám také hodně napoví.

5. Velmi matoucí je také to, že jedna navržená obrazovka v designu může obsahovat vícero případů užití. Neplatí totiž rovnice „1 obrazovka = jeden případ užití“, jak se může mnohdy mylně analytik domnívat. Uvedu klasický příklad: U jednoho systému, který jsme řešili na konzultačním školení, jedna navržená obrazovka v designu zobrazila seznam zpráv v různých stavech a při výběru zprávy se podle jejího stavu „vyšedila“ nebo „aktivovala“ tlačítka jako: „Odeslat“, „Podepsat“, „Odsouhlasit“ apod. Takováto obrazovka obsahuje hned několik případů užití, i když vše vidíme „najednou na jedné kopě“!

Je třeba zdůraznit, že zvládnutí často se vyskytujícího problému správné identifikace procesů podniku, následně případů užití prvního druhu a případně jejich chybné kouskování, vyžaduje určitou praxi, ale musím hned dodat, že praxi se „správnými řešeními“. Pokud totiž pracovník dlouhodobě vyrábí své modely stále chybně, je mu taková praxe vlastně na nic. Je tedy prospěšné, pokud má vývojář možnost seznámit se správnými řešeními a na nich získávat nezbytné zkušenosti, a to buď přímo na svém systému (například viz možnost výhodných a kvalitních balíčků konzultací) anebo pomocí našich školení (viz Pobytová, Internetová a In-house školení).

Autor spravuje web věnující se OOP a UML.

Přidat komentář

Jméno (povinné)

E-mail, nebude zveřejněn (povinné)

Web

Ochrana proti spamu: (povinné)*
Opište prosím text z obrázku.