Scénáře případů užití (Use Case Scenario) vyjadřují posloupnost kroků programu, ať už budoucího zatím pouze navrženého, anebo již implementovaného a nasazeného u zákazníka. Mohlo by se proto na první pohled zdát, že u popisu algoritmu nemá smysl hovořit o nějakých stavech a tedy s tím souvisejícím nastavením hodnot u scénáře případů užití (podobně jako je tomu u objektů).
Avšak také případy užití spadají do velké rodiny „instanciovatelných prvků“ a lze proto u nich dynamicky nastavit nějaké hodnoty a na ně se poté obracet v běhu programu.
Této vlastnosti může analytik prakticky a efektivně využít pro vylepšení opětovné použitelnosti v Use Case Modelu a tedy pro zefektivnění psaní scénářů. Dokonce, pokud napíše takovýto scénář s využitím stavů případů užití korektně, bude i program tyo stavy používat a to přesně v té logice, jak ji napíše analytik.
Uveďme si jako první způsob využití „stavovosti“ u případů užití v možnosti nastavení přístupnosti polí u inkludovaného případu užití ještě před jeho zavoláním.
Vysvětleme si tuto možnost pomocí následujícího příkladu:
Při založení nějakého nového prvku v systému (například založení nové faktury, založení nové objednávky apod.) se z okolí (tj. z podniku) vyvolá případ užití „Založení nového prvku X“. Následně se provede scénář zadání hodnot u daného prvku a nový prvek se uloží.
Nechť uvedený prvek lze vybrat a následně opětovně editovat, což vede k dalšímu případu užití. Na první pohled je zřejmé, že celé části scénářů u editace vybraného prvku a u editace nového prvku jsou stejné. Žádá se tedy využít opětovnou použitelnost, tj. zavést společný jeden scénář pro editaci aktuálně vybraného prvku v obou případech.
Avšak musíme být opatrní, nějaké rozdíly mezi oběma scénáři tu přece jen jsou: Některá z polí, která bylo množné editovat při založení, nebude již možné při následné editaci (po výběru ze seznamu) změnit, tj. tato pole nebudou přístupná (nemáme zde na mysli pouze editaci pole, ale například i výběr prvku ze seznamu, který již nelze měnit).
A jedné straně se tedy žádá opětovně použít daný scénář, což evidentně vidíme „až k představě obrazovky“, na straně druhé se tyto scénáře liší v možnostech povolení nebo zákazu editace některých polí.
Zde se právě uplatní možnost nastavit u daného případu užití „parametry“, v tomto případě „editovatelnost“ určitých polí. Znamená to, že těsně před zavoláním tohoto inkludovaného případu užití se napíše ve scénáři, která pole se zpřístupní resp. která nikoliv, například takto:
UC Editace prvku X
Obsluze se zobrazí seznam prvků X (co se zobrazí), obsluha vybere prvek X.
Nastaví se a1, a2, … na „disabled“ a zavolá se UC Editace aktuálního X
…
V samotném scénáři případu užití Editace aktuálního X bude u polí a1, a2, atd. uvedeno, že je lze zpřístupnit resp. znepřístupnit (například pomocí slovního spojení enabled / disabled apod.) , například takto:
Obsluha zadá a1 (a1 potentionally enabled/disabled)…
Navíc bych doporučoval někde buď ve scénáři na začátku anebo na jiném vhodném místě případu užití (například do podmínky PRECONDITION) vypsat všechny možnosti nastavení, například takto.
Před zavoláním tohoto UC lze nastavit:
a1 enabled/disabled,
a2 enabled/disabled … atd.
Je možné také toto nastavení hodnot (vlastností) před daným konkrétním voláním znázornit i v diagramu pomocí textu, například takto:
Obrázek 1 : Možnost znázornění nastavení hodnot před voláním případu užití v UC diagramu
Určitě si umíme představit, že toto nasazení opětovné použitelnosti bude fungovat až do úrovně kódu, kdy programátor skutečně nejprve nastaví nějaké vlastnosti prvků formuláře (resp. jeho části) a poté jej zobrazí uživateli.
Je samozřejmě na dohodách a na metodikách ve firmě, co vše bude v textu zapsáno a co vše bude znázorněno v diagramu. V každém případě se vyžaduje transparentnost a srozumitelnost zápisu tak, aby technolog resp. programátor dobře pochopil, co se po něm žádá, ať už v rámci zadání nového programu anebo při změnovém řízení.
Konec článku
Napsat komentář