Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC

http://www.objects.cz Dobrá rada pro tvorbu USE CASE MODELU, © Kraval Ilja

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC Úvod Před nedávnem jsem obdržel trochu delší mail tohoto znění: Dobrý den pane Kravale, před časem jsem absolvoval vaše školení zaměřené na UML a jeho použití v analýze. V rámci každodenních analytických prací existuje několik obecných problémů, které se vyskytují prakticky na každém projektu a pro které prozatím nemám jednoznačné řešení. Mám sice nějaké návrhy, ale nejsem si jimi jistý. Chtěl jsem vás proto požádat o konzultaci těchto problémů, které nejsou nijak projektově nebo doménově specifické ale naráží na ně každá firma prakticky ve všech projektech. 1. Prvním problémem je, jak předávat designerům a zákazníkovi informaci o tom, že v konkrétním kroku scénáře UseCase je zpracovávána určitá sada atributů. (Například že v kroku 1.Klient vyplní hodnoty pro atribut X, Y, Z) Podle mého názoru existují dva základní způsoby řešení. - První a nejjednodušší je samozřejmě vypsání kompletního seznamu atributů, které jsou v daném kroku UseCase zpracovávány, přímo do textu příslušného kroku scénáře. Tedy například "Uživatel vyplní pole Jméno, Příjmení a Kód zboží." nedostatek takového řešení je v tom že výčet atributů může tvořit poměrně obsáhlý seznam a jeho kompletní vepsání, značně znepřehlední čtení daného Usecase. Navíc při změně seznamu je třeba nezapomenout provádět úpravu hned na několika místech v modelu a to jak v boundary Class reprezentující daný formulář, tak v UseCase. - Z uvedených důvodů se mi jako lepší jeví druhá varianta kdy do příslušného kroku UseCase neuvedu kompletní výčet

Strana 1


zpracovávaných atributů ale pouze nějakou formu odkazu na název třídy která dané atributy obsahuje. Při změně potom stačí provést úpravu obsahu této třídy ale na UseCase se nemusí sahat. Otázkou ovšem je na co se z UseCase odkazovat. Je správné odkazovat se na Analytické třídy typu entity, nebo spíše na analytické třídy typu boundary? Moje představa je taková že budu mít boundary třídy strukturované do tří úrovňové hierarchie kde na nejvyšší úrovni je obrazovka. K obrazovce je pomocí kompozice připojena sada boundary tříd se stereotypem blok a ke každému bloku je kompozicí připojena sada tříd se stereotypem segment. Například obrazovka Žádost se skládá z bloků Osobní údaje, Popis zboží a Informace o ceně a třeba sekce Osobní údaje se skládá ze sekcí Personální údaje a Adresa. V kroku UseCase Založení žádosti by pak nebylo napsáno "Uživatel vyplní ulici, číslo domu, město, PSČ", ale bylo by tam napsáno "Uživatel vyplní sekci Adresa." Druhé možné pojetí je založeno na tom, že se budu v příslušném kroku UseCase odkazovat nikoli na boundary třídy, ale přímo na entity. Důvodem je především to, že v době vytváření scénářů Usecase nejsou velmi často boundary třídy ještě vůbec známy. problém ale vidím v tom že entity narozdíl od boundary tříd velmi často obsahují atributy používané na několika různých boundary třídách a proto akce popisovaná v příslušném kroku useCase nemusí vždy pracovat se všemi atributy příslušné entity. Například nemohu napsat že "Uživatel vyplní atributy entity Adresa". Když tato třída Adresa obsahuje narozdíl od boundary třídy Adresa klienta i atribut Platnost, se kterým se v daném kroku nepracuje. Máte prosím nějaký názor na tuto problematiku mapování atributů analytických tříd ať už entit nebo boundary, na Usecase? 2. Další často probíranou záležitostí je, jak pojmout situaci, kdy po ukončení nějaké funkcionality, popisované jedním Usecase, je bezprostředně spuštěna (buďto automaticky nebo manuálním zásahem uživatele) funkcionalita popisovaná jiným UseCase. Například ihned po ukončení UseCase Založit žádost následuje vždy UseCase Vytisknout žádost, jehož obsah ale nemůže být součástí UseCase Založit žádost, protože tisk žádosti se provádí nejen po jejím založení ale i v jiných dalších případech a tak je existence samostatného UseCase pro popis tisku žádosti zcela oprávněná. Jakým způsobem tedy předat designerovi informaci, že vždy po provedení Usecase Založit žádost je nutné provést UseCase Vytisknout žádost? Dokážu si představit tři různá řešení, z nichž první dvě mi přijdou jako špatná.

Strana 2


- První možnost je že informaci o tom že na sebe oba UseCase navazují, nijak v modelu nezaznamenám a tím pádem jí ani nepředám. - Druhá možnost je propojit oba Usecase tak, že UseCase Založit žádost by jako poslední bod svého hlavního scénáře obsahoval include Usecase Vytisknout žádost. Ovšem takto pojaté UseCase diagramy by pak byly naprosto nepřehledné a plné změti vazebních čar. - Třetí a mnou preferovaná možnost, je zaznamenat úspěšné ukončení UseCase Založit žádost jako jeden z několika možných Starting events UseCasu Vytisknout žádost. A jako jednoho z primárních Actorů UseCase Vytisknout žádost zařadit i System, nebo System event (protože o Actora Time respektive Time event se v tomto případě nejedná). Jaký je váš názor na mnou navrhované řešení? 3. S předchozím problémem souvisí i další často zvažovaný problém, který spojený s existencí menu a faktem, že funkcionalita je většinou aktivována výběrem z nějakého menu a že po ukončení používání této funkcionality se uživatel opět k tomuto menu vrací a aktivuje z něj funkcionalitu jinou. I zde jsem se setkal s prvními dvěma variantami řešení, tak jak jsem je popsal v předchozím bodě. Tedy buďto, že usecase pro menu vůbec neexistuje, nebo že každý UseCase pro takovou funkcionalitu začíná krokem "systém zobrazí menu a uživatel z něj vybere ...". Případně že to bylo řešeno tak, že vznikl samostatný UseCase pro zobrazení menu a ten byl includovan jako první krok příslušného scénáře UseCasu, který popisoval konkrétní funkcionalitu. Například tedy UseCase Založit žádost nejprve includoval UseCase Zobrazit menu a teprve jako druhý byl první krok funkcionality založení žádosti. I v případě této problematiky je ale podle mě správným řešením, udělat pro zobrazení menu samostatný UseCase, který ovšem není do ostatních UseCase includován. Výběr v menu je pak uveden jako jeden z možných Starting eventů v příslušných UseCase popisujících vlastní funkcionalitu. jaký je váš názor na tuto problematiku? 4. Posledním problémem, na který bych se vás rád zeptal, je dotaz na to, jakým způsobem v modelu zachytit neočekávané ukončení libovolného UseCase. typicky se jedná o situaci, kdy uživatel Strana 3


používá nějakou funkcionalitu, která je popisována určitým UseCase a při tom existuje možnost, že ve kterém kolik kroku daného UseCase uživatel přeruší tento UseCase například tak, že klikne někde v menu a tím aktivuje zcela jinou funkčnost, nebo že dojde k neočekávanému pádu systému. Máte vyřešený nějaký způsob, jak tuto informaci o neočekávaném ukončení UseCase v modelu zachytit? Nechce se mi věřit, že by neexistovala nějaká lepší a jednodušší varianta řešení než ta, než každý UseCase bude obsahovat specielní výjimkovým scénář, který bude ve všech UseCase stejný a bude říkat, že UseCase může být z těch a těch důvodů v kterémkoli svém kroku přerušen. Omlouvám se za tak rozsáhlý email s velkým množstvím dotazů. Přesto věřím, že nastíněné otázky jsou tak obecné a zvažují je mnozí analytici na mnoha projektech, že jsou i pro vás a studenty vašich kurzů zajímavé. Předem děkuji za vaši případnou pomoc s těmito problémy a přeji vám hezký den, P. R. Analytik Vzhledem k rozsahu dotazů budu odpovídat postupně seriálem článků.

Doporučení pro práci s pojmy ve scénářích UC

Rád bych neprve upozornil na jednu důležitou okolnost: Právě připravuji metodické dokumenty z řady technologie zvané OCM (Object Consulting Methodology). Tyto dokumenty velmi podrobně popisují doporučené postupy při návrhu softwaru včetně praktických kroků učiněných v nástroji EA a v nástroji EA Object Editor. Tento článek je výňatek z této dokumentace OCM upravený do podoby článku.

Nyní se pustíme do prvního bodu, tj. jak pracovat s texty scénářů případů užití obsahujících pojmy jako rodné číslo, jméno, příjmení atd. První základní část otázky z bodu 1 lze stručně shrnout do následující formulace: „Jak a na co provázat opakující se pojmy z textů scénářů?“ Odpověď má dvě roviny: teoretickou a technickou. První rovina vysvětluje „o co jde“, druhá rovina popisuje „konkrétní postup“, jak ho dosáhnout konkrétně v EA.

Strana 4


Teorie - logika posloupnosti prací na analytickém modelu Platí jedna důležitá a logicky jasná skutečnost: Pojmy, které se vyskytují ve scénářích UC, nelze ve chvíli psaní scénářů provázat ani na analytické třídy a ani na formuláře. V této chvíli totiž nejsou tyto prvky modelu nalezeny (ani analytické třídy a ani formuláře) a teprve se budou „vymýšlet“ z těchto pojmů. Pokud si důkladně přečteme poslední souvětí, a zejména poslední větu z posledního souvětí, tak je zřejmé, že evidentně existuje kromě analytických tříd ještě další prvek analytického modelování předcházející třídy, nazvěme jej „uživatelský pojem“ neboli „user concept“. Naše prvky s názvem rodné číslo, příjmení atd. reprezentují právě tyto prvky typu „user concept“. Jinak řečeno, znamená to, že evidentně existuje prvek v analytickém modelování reprezentující úplně první analytickou úroveň. Těmito prvky jsou „uživatelské pojmy“ nebo jen „pojmy“ resp. „user concepts“. Z nich teprve vznikají analytické třídy. Vyplývá z toho, že existuje ještě mapování „z uživatelských pojmů do analytických tříd“. Teprve až analytické třídy (vzniklé z pojmů) jsou již abstraktním vyjádřením tříd v designu (například abstraktním vyjádřením tabulek apod.).

První závěr: Je vhodné zavést pojmy, se kterými pracuje scénář. Tyto pojmy by měly být používány jednotně ve všech scénářích, tj. nesmí se používat synonyma. Z těchto pojmů se pak buduje analytický model tříd a následně modely designu.

Praxe - Konkrétní postup Nyní se dostáváme ke konkrétnímu postupu, jak pracovat s pojmy ve scénářích. Cituji nejprve jednu část otázky z mailu: „...Navíc při změně seznamu je třeba nezapomenout provádět úpravu hned na několika místech v modelu...“ Tato věta ukazuje na určitý nedostatek, který mají CASE nástroje, a tento nedostatek má obecnější podobu, tj. nevyskytuje se jen a pouze při psaní scénářů, ale prolíná se všemi pracemi s CASE nástroji. Obecně CASE nástroj (zde EA) nepodporuje „živé odkazy“ z textu na jiné prvky v modelu. Malá vysvětlující odbočka předešlé věty: Před dalším čtením článku si prosím přečtěte odstavec s názvem „Výhoda stále aktuálních odkazů v textu“ na stránce: http://www.objects.cz/eaoe/eaoe.html. Pokud použijeme na stránce zmíněný produkt EAOE, potom existuje jednoduchá odpověď na původně složitou otázku:

Strana 5


Otázka: „Na co a jak provázat pojmy ze scénářů UC?“ Odpověď: „Na pojmy“. ☺ Postup je velmi jednoduchý: •

Založte vedle prvku Package s případy užití druhý Package, dejte mu název User concepts of (nebo česky Uživatelské pojmy <čeho>)

•

Jakmile se při psaní scénářů narazí na opakující se (zajímavé) podstatné jméno (rodné číslo, faktura, seznam faktur, fyzická osoba, seznam fyzických osob atd.) reprezentující pojem, se kterým se pracuje v systému, nepište ho do scénáře! Založte prvek typu Object do Package obsahující pojmy, dejte tomuto prvku typu Object stereotyp <<user concept>> a dejte mu název tohoto pojmu. Pokud chcete, můžete dát do Notes i vysvětlení „o co v pojmu jde“. V textu scénáře založte odkaz na tento prvek pomocí EAOE nástroje. V package „vedle“ vzniká seznam pojmů jako prvky typu Object se stereotypem <<user concept>>

•

Jakmile znovu narazíte na opakující se pojem při psaní scénáře, pak na dané místo založte odkaz na tento prvek pomocí EAOE nástroje. Použití odkazů na pojmy má za následek tyto skutečnosti: o Tvorba synonym je výrazně omezena. Pojmy se totiž vybírají ze seznamu a nezakládají se znovu v textech. o Práce se výrazně urychlí, celé názvy se přenášejí pouze kliknutím a nepřemýšlí se, jak pojem vlastně zněl, protože se nabízí v seznamu o Při změně názvu pojmu se změna projeví ve všech textech o Seznam pojmů je výchozí seznam pro zpracování modelu tříd o Při evidenci vztahu „Pojem - Analytická třída – Design třída“ dostáváme kýženou oboustrannou evidenci od pojmů k designu do kódu a zpět (realizace pojmu v designu a vysvětlení designu pomocí pojmů zpětně)

Praktický postup je, jak vidět, velmi jednoduchý a praktický. Všimněte si jedné důležité okolnosti: Package s pojmy reprezentuje něco jako slovník pojmů systému a na něj budeme mapovat analytické třídy. Navíc, tento slovník je „dostatečně chytrý“: Pokud změníte název pojmu v tomto slovníku, tak tato změna se automaticky díky nástroji EAOE promítne do všech textů všech scénářů ☺. V dalším článku se budeme věnovat další otázce z mailu. KONEC ČLÁNKU

Strana 6

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC

Recommend Documents