V jakém vztahu jsou prvky User Story z agilních technik a Use Case z UML?

V jedné internetové diskusi jsem narazil na otázku, v jakém vztahu jsou prvky User Story používané v agilních technikách a prvky Use Case zavedené jazykem UML.

Tyto dva prvky jsou velmi důležitými styčnými body velmi efektivního postupu, ve kterém lze nasadit jednak agilní techniky vývoje (např. SCRUM)  a současně tvořit dokumentaci vývoje pomocí modelování v UML a to bez vzájemného antagonismu těchto dvou technik.

Proto si v tomto článku vysvětlíme oba prvky a jejich vztah blíže.

Při snaze zavádět ve vývoji IS modelování pomocí UML a současně používat agilní techniky vývoje hrozí dvě nebezpečná úskalí: Na jedné straně můžeme spadnout do pasti tvorby SW chaotickým a projektově nezvládnutým způsobem (tzv. chaotický vývoj. metodika tunel) anebo můžeme na straně druhé spadnout do druhé také velmi problematické a nebezpečné pasti, kdy se vývoj SW provádí příliš pomalým a přehnaně formalizovaným až byrokratickým postupem (například metodou Vodopád).

Oběma těmto extrémům je třeba se vyhnout a právě správné použití prvků User Story a Use Case je jedním z klíčových postupů spolupráce obou technik, agilní techniky a modelování v UML.

Pojem User Story jako první zavedli autoři tzv. Extrémního programování ve snaze najít a popsat situace, jak a kdy uživatel použije systém s popisem dané funkcionality (viz například ve wikipedii). Další agilní techniky tento pojem User Story převzaly.

Jazyk UML oproti tomu zavádí pojem Use Case jako „případ jednoho užití systému“, což zní sice podobně jako User Story, ale není to totéž. Popišme si nejprve, jak je takový jeden případ užití definován.

Poznámka: Z hlediska vyhledávání a postupu prací existují případy užití prvního druhu (hledají se v prvním kroku) a druhého druhu (hledají se v druhém kroku). Zde v tomto článku popisujeme případy užití prvního druhu, které vznikají primárně. Případy užití druhého druhu se zavádějí později, kdy se vyhledávají interakce mezi případy užití (nejčastěji  «include») volají případy užití mezi sebou velmi podobně jako funkce. Tyto případy užití druhého druhu nesouvisejí přímo s pojmem User Story a nejsou předmětem tohoto článku.

Označme si okolí a systém podle následujícího obrázku:

obr1

Obrázek 1: Okolí a systém

Pro definici jednoho případu užití (prvního druhu) je velmi důležitá výchozí situace našeho děje a to je stav, kdy tak říkajíc „nikdo (tj. ani okolí a ani systém) nic nechce“ a „nikdo nic nepotřebuje“.  Obrazně řečeno „obsluha má nohy na stole“ a systém „taky nic nedělá“.

Tento výchozí stav nazvěme jako IDLE stav, viz obrázek:

obr2Obrázek 2: IDLE stav na začátku

Nechť po tomto klidovém stavu vznikne nějaká událost v okolí. Tato událost vyvolá děj mimo systém, tj. v okolí, který začne probíhat. S nadsázkou řečeno „obsluha sundá nohy ze stolu“ a začne něco dělat, podotkněme, že systém stále o ději venku nic netuší :

obr3Obrázek 3: Děj v okolí spuštěný na událost

V rámci tohoto děje najednou někdo, například naše zmíněná obsluha, nebo něco dostane neodolatelné nutkání použít systém. Z toho důvodu v daném bodě děje okolí vyvolá (tj. zavolá neboli  instanciuje) odpovídající Use Case, tj. případ užití systému. Spustí se odpovídající program, který je v případu užití zaveden pomocí Use Case Scenario (scénáře případu užití). Situace je zde velice podobná, jako když se zmáčkne tlačítko ve výtahu anebo na nějakém stroji: Název případu užití reprezentuje nápis na tlačítku, tj. užitek, který ten, kdo tlačítko stiskne, očekává, že dostane.

Program na analytické úrovni zavedený pomocí scénáře reprezentuje běh programu, který k tomuto užitku dospěje (samozřejmě pokud scénář proběhne jako tzv. Happy Scenario a nespadne do žádné z Exception Flow větví).

obr4

Obrázek 4: Děj venku a děj uvnitř, spuštění případu užití

Abychom pochopili do důsledku, jak Use Case funguje, je třeba uvést poslední důležitou okolnost celého děje a totiž finální stav, do kterého okolí i systém nakonec dospěje, až program reprezentovaný scénářem užití doběhne do konce a okolí získá užitek. V té chvíli na konci celého scénáře, kdy došlo k uspokojení okolí, opět nastává IDLE stav, který je v podstatě stejný, jako jsme jej definovali na začátku, kdy „nikdo nic nechce“, tj. „obsluha si dá opět nohy na stůl“, viz obrázek:

obr5

Obrázek 5: Konečný IDLE stav, opět rovnováha

Uveďme si jako příklad takovýto děj u evidenčního systému obchodu ve skladové části:

Ke skladu obchodu přijíždí kamion se zbožím. Skladník bere do ruky přístroj PDA se čtečkou čárového kódu, zboží se postupně vykládá na rampu a skladník toto vyložení zboží z kamionu na rampu skladu zaeviduje.

Zde celý děj končí okamžikem, kdy se všechno zboží (tj. krabice) vyloží a zaeviduje se tak celá vykládka kamionu na rampu (pokud děj neskončí někde v error větvi)

Jedním z úkolů analytika je nalézt všechna tato volání kontextu okolí versus užitek systému.

Nyní se dostáváme ke styčnému bodu mezi pojmem User Story a Use Case. Vyhledávání případů užití se děje právě sofistikovaným způsobem pomocí nalezení všech takovýchto dvojic, kdy děj okolí spouští případ užití. Znamená to, že v prvním kroku se ve spolupráci s konzultantem resp. spolupracovníkem v roli Product Owner nalezne jednoduchý textový tvar děje od jednoho IDLE stavu do následujícího IDLE stavu. Tento textový popis se jako první nástřel odsouhlasí a víc se v této první fázi nežádá. Vznikne tak „jeden příběh použití sytému“, což je vlastně jedno User Story.

Efektivní techniky nalézání případů užití pomocí UML však pokračují dále dalším postupem, protože práce analytika nyní ještě neskončila: Nyní se musí v odsouhlaseném textu User Story najít ten bod děje, kde se volá případ užití (viz červený bod na obrázku). Tímto se děj rozdělí na dva scénáře: jednak „děj v okolí“ před zavoláním a „děj v systému“ volaný z okolí a současně se identifikuje užitek, proč se systém v tomto bodě volá (tj. nalezne se správný název tlačítka v červeném bodě). Takto z textového User Story vzniknou dva nové prvky provázané voláním: Na jedné straně vznikne Business Proces (děj venku)  a z něj volaný případ užití – Use Case (děj uvnitř systému). Analytik tuto situaci znázorní pomocí vztahu Dependency Business Proces versus nalezený Use Case.

Jaké jsou výhody dalšího zpracování User Story dělením na Business Proces a Use Case?

1. Vyhledání rozhraní systému

Rozdělení scénáře a určení bodu volání případu užití z okolí identifikuje bod rozhraní, tj. co je naším řešením a co už ne. V mnoha případech nastává chyba právě v určení tohoto bodu.

Příklad: Vraťme se k User Story popisujícímu vyskladnění zboží na rampu, okamžitě vyvstane otázka, kde začíná náš systém? Je ono PDA také součástí našeho řešení a budeme ho programovat? Dovedeme si představit, jak nepříjemná situace by nastala, kdyby se v projektu opomnělo toto zařízení naprogramovat a tato skutečnost by se zjistila až ke konci projektu…

2. Dekompozice procesů, procesní mapa a inventarizace případů užití

Pro modelování všech těchto situací volání z okolí se s výhodou použije škola procesního modelování nejlépe v syntaxi BPMN 2.0, kde uvedené děje okolí reprezentují okolní procesy (tj. aktivity okolí), které spouštějí případy užití. Tyto procesy lze uspořádat díky možnosti skládání procesů do vyšších procesů a to hierarchicky do stromu a vzniklá tak tzv. procesní mapa. Tímto jednoduchým postupem lze získat velmi dobrý přehled o všech oblastech řešení, provádět inventarizaci případů užití, kontrolovat jejich úplnost apod.

3. Chod procesu, posloupnost děje, epic

Dalším důležitým krokem je nalézání tzv. epiců, což je posloupnost několika User Story za sebou včetně větvení, čemuž v BPMN odpovídá chod procesů včetně využití velmi přesné syntaxe BPMN (využití prvků Sequence Flow, Events, Gateways etc.). Tuto posloupnost dějů Product Owner rád vidí i v BPMN modelu, protože se mu přesně znázorní, „takto se budete chovat a přitom takto používat systém“.

Jako příklad posloupnosti kroků uveďme chod zboží v našem příkladu. Je zřejmé, že krabice se zbožím nezůstanou na rampě a budou poté (na další událost) přesunuty do skladu a to se zaeviduje. Následuje tedy proces Přesun zboží z rampy na sklad, který bude volat Use Case Zaevidování přesunu zboží z rampy na sklad atd. Stejně tak zboží by nemělo skončit na skladě, dojde k přesunu na prodejnu atd.

Závěr

Prvky User Story a Use Case jsou v přímém vztahu v tom smyslu, že při vyhledávání případu užití se začíná nejprve prvkem User Story, což reprezentuje jeden jednoduchý textový popis děje od jednoho rovnovážného IDLE stavu, kdy nikdo nic nechce, přes událost a celkový děj venku a uvnitř až po druhý rovnovážný IDLE stav, kdy je splněn užitek a opět nikdo nic nechce.

Efektivní Use Case Techniky a procesní modelování pomocí syntaxe BPMN však jdou dále: V nalezeném textu User Story se poté identifikují body volání prvků Use Case, čímž vzniknou rozdělením User Story dva nové prvky: Business Process a Use Case. Následně se pro modelování procesů efektivně nasadí syntaxe BPMN, pro modelování případů užití syntaxe Use Case Modelu .

Poznámka: Postupům efektivních Use Case technik spolu s procesním modelováním je na našich školeních pro jednotlivce věnována velká pozornost, viz např.  zde

Tento další postup zpracování procesů a případů užití je pro vedoucího analytika a pro šéfa (Scrum Mastera) nezbytný: Pokud se neprovede, nemůžeme mít nikdy jistotu, že rozhraní systému jsou určena správně, že případy užití jsou opravdu všechny a že chod procesů podniku odpovídá požadovanému chodu s užitím systému požadovaném Product Ownerem.

Categories

About the Author:

správce a majitel Serveru objektových technologíí http://www.objects.cz

One Comment
  1. Milan Číha

    Pěkný den, pane Kravale.

    K tématu vyhledávání případů užití bych rád poznamenal, že další užitečnou technikou pro vyhledávání případů užití jsou stavové diagramy.

    Hledal jsem na serveru objects.cz související články (nechtěl jsem nosit vodu do řeky 🙂 a našel jsem dva díly “O významu procesního modelování …”, ve kterých zmiňujete techniku “Project Scope Widening”. Následující text by možná mohl přispět k volnému pokračování (navazuje spíše na “Project Scope Widening” než na procesní modelování).

    Stavový diagram sice nemusí popisovat celý životní cyklus objektu, ale pro vyhledávání případů užití je to užitečné. Zkusme si tedy pro každou nalezenou primární (tedy důležitou a nezávislou) třídu nakreslit stavový diagram od vzniku objektu až po jeho zánik. Uznávám, že vznik i zánik nemusí “patřit” do popisovaného systému. I takové zjištění je však výhra – můžeme si zkontrolovat popis okolí systému.

    Z hlediska formálního obsahuje stavový diagram nejen názvy stavů, ale také názvy přechodů. Jako názvy přechodů by měly být použity identifikátory a názvy případů užití. Takže si zkontrolujme, zda jsme toho schopni opravdu u každého přechodu, který souvisí s popisovaným systémem. Možná, že nalezneme další případ užití (a stav a přechod … :-).

    Děkuji Vám za Vaši práci.

    Milan Číha

0 Pings & Trackbacks

Leave a Reply