|
Rozbor nejčastější chyby při vyhledávání případů užití
autor: RNDr. Ilja Kraval, červen 2011
Object Consulting s.r.o.
Server objektových technologií
Úvod
V některých předešlých článcích (viz například O jedné záludnosti interakce include v modelu případů užití anebo Chyba kouskování případů užití a předčasné ukončení scénářů) bylo pojednáno o jedné z nejčastějších chyb při vyhledávání případů užití, která by se dala nazvat „kouskování případů užití“. Jedná se o chybu, která se vyskytuje velmi často, dokonce by se dalo říci, že statisticky vzato v každém projektu návrhu IS se vždy minimálně alespoň jednou vyskytne.
Někdy je dobré pochopit, jak uvažuje ten, kdo dělá chybu. Tento článek vysvětluje právě onu chybnou úvahu, které byste se měli vyvarovat.
Primární a sekundární případy užití
Základní myšlenka postupu vyhledávání případů užití není až tak složitá:
Najděte procesy podniku (chování okolí), které vedou ke spuštění případů užití vašeho systému. Tím jste našli jak případy užití, tak kontext jejich spuštění.
Tyto případy užití, které jsou spouštěné z procesů, budeme nazývat jako primární, protože jsou to ony, kterými systém přináší primární užitky. Kromě nich totiž existují i další případy užití, které vznikají sekundárně pomocí interakcí mezi případy užití («include»), budeme je nazývat sekundární případy užití.
Sekundární případy užití vznikají v druhém kroku vytknutím případů užití a přeskupením, tj. „refactoringem“ scénářů pomocí interakce «include».
Právě opominutí rozdílu mezi primárními a sekundárními případy užití vede ke zmíněné chybě.
Záměna názvů případů užití za první aktivity
Pro demonstraci a vysvětlení uvedené chyby zvolme následující příklad:
Máme za úkol najít případy užití informačního systému malé městské knihovny. Podle doporučených postupů ze školení nejprve hledáme tzv. „zlaté procesy“ knihovny. Našli jsme díky tomuto postupu složený proces Průběh zápůjčky. Díky vyhledávání zlatých procesů začneme zpracovávat jako jeden z prvních proces nazvaný Zapůjčení knih čtenářem. Nejprve nahrubo nastíníme, o co v tomto ději jde:
Proces Zapůjčení knih čtenářem Stručné story: {Čtenář si vybere knihy z polic v knihovně, přijde ke knihovníkovi a ten přes čtečku čárového kódu zaznamená celou zápůjčku čtenáře}
Nyní popíšeme celý děj podrobně s důrazem na volání případu užití, který nalezneme jako použití systému, tedy nalezneme případ užití volaný z tohoto procesu. Určitý děj se děje venku (ten neprogramujeme), jiný děj se děje uvnitř našeho systému (ten programujeme). Uveďme si zde obě varianty řešení, jak chybnou, tak i správnou.
Chybné řešení s kouskováním případů užití bude vypadat například takto:
Analytik si v duchu představí, jaká je vlastně posloupnost kroků, které je třeba vykonat, aby se celý děj uvedený ve zkratce zrealizoval. Například navrhne toto (připomeňme, že chybné) řešení popisu scénáře procesu:
Proces Zapůjčení knih čtenářem
Scénář { Čtenář přichází s knihami k pultu, spustí se UC Načtení čárového kódu čtenářského průkazu (s možností kód zadat ručně, najde se čtenářský průkaz v systému), potom se spustí cyklem UC Načtení čárového kódu knihy, najde se kniha s tímto kódem v systému, přiřadí se datum… atd. }
V tomto textu děje procesu se vyskytuje klasická chyba „kouskování“ případů užití na menší případy užití. Správné řešení je totiž z pohledu spouštěných případů užití mnohem jednodušší:
Proces Zapůjčení knih čtenářem
Scénář { Čtenář přichází s knihami k pultu, volá se UC Zaevidování zápůjčky čtenáře. }
Možná nás v prvé chvíli překvapí triviálnost tohoto řešení. A kde je načtení čárového kódu průkazu? A kde naleznu načtení čárového kódu knih? Tyto sekvence děje se v žádném případě neztratily, ty tam jsou, ale až za hranicí případu užití! Uvedený „správný“ scénář se následně znázorní těmito diagramy:
V diagramu podpory:
Obrázek 1 Chod procesu i s UC
Do předešlého diagramu chodu procesu a spouštění případů užití bychom měli umisťovat pouze primární případy užití a nikoliv vytknuté sekundární tj. „inkludované“ případy užití.
V jiném prvku Package (například UCM) se objeví následující diagram, kde již nalezneme hledané sekvence načtení čárového kódu například takto:
Obrázek 2 Use Case Diagram s interakcemi v diagramu Use Case Modelu (nikoliv BPMN)
Tento obrázek zřetelně ukazuje, kde se stala chyba: Když se totiž podíváte zvně na primární případ užití (zde z pohledu knihovníka), potom tento název Zaevidování zápůjčky čtenáře přesně určuje „cíl, užitek“ případu užití a tak má být tento případ užití nazván (a tak se hledá). Předešlý obrázek říká následující: Knihovník spustil systém s cílem zaevidovat zápůjčku (a ne načíst kód).
Pokud se podíváme na chybné řešení, je zřejmé, kde se stal omyl a jak vznikl: Každý případ užití začíná nějakou „první aktivitou“ a očima programátora se spustí tato aktivita jako první, tedy programátor to vidí chybně „jako první spuštěný případ užití“. Proto takto nesprávně nazve případ užití. To je však chybný pohled, protože porušuje objektové paradigma, obracíme se totiž chybně dovnitř případu užití a nevidíme jej jako celek.
Zásada zní jednoduše: Případ užití se nejmenuje podle aktivity, která se v něm spustí jako první, ale nazve se podle účelu, proč byl spuštěn a proč k němu bylo přistoupeno. Nastává paradoxní situace: Účel bývá získáván až na konci scénáře případu užití (a ne na začátku), kdy celý „happy scenario“ případu užití projde bez chyb a výjimek až do zdárného konce případu užití. V našem příkladu je na konci získán „happy stav“ = „je zaevidována zápůjčka knih“ (dá se vyjádřit jako postcondition případu užití).
Rada: Znamená to, že se spíše díváme na konec scénáře případu užití, když volíme jeho název, než na jeho začátek.
Závěr
Primární případ užití má mít svůj název odvozen od výsledku (užitku), který je dán „návratem užitku“ na konci „happy scenario“ případu užití a vyjadřuje účel, smysl, užitek, proč někdo z okolí přistoupil k systému a co vlastně žádá.
Často se vyskytující chyba kouskování primárních případů užití má mnohdy svou podstatu v záměně názvu případu užití za první aktivitu, která se v něm spouští, a této chyby je třeba se vyvarovat...
Konec článku
|
