Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval © 2007 http://www.objects.cz

K napsání tohoto článku mne inspiroval tento mail:

Dobrý den pane Kravale, chci Vás poprosit o radu, která zní: Jak a kde v rámci Enterprise Architectu psát specifikaci pro práci programátora? V naší firmě jsem pověřen tvorbou analytické metodiky, čili snažíme se do vývoje vnést jakýsi řád. Bohužel, to zatím dopadá tak, že poté co analytici (bývalí programátoři) objevili kouzlo Use Case, začali do scénářů vypisovat přesné chování systému tak, aby zachytili interakci uživatele s už hotovým softwarem. Tento UC je pak plný programátorských pojmů a je napsán tak, že mu rozumí opravdu jen vývojář. Designové modely nedělají vůbec. Snažím se je přesvědčit, že je nutné vytvářet user inteface (třeba nakreslit tužkou) a k tomu implementační model, jejich otázka ale je, jak tam zachytí interakci s uživatelem a chování softwaru a jak zajistí, aby nemuseli výkonným programátorům neustále vysvětlovat jak to má fungovat. Pro příklad uvádím výtah z jednoho UC

Jak správně psát scénáře k případům užití? © Ilja Kraval, 2007, http://www.objects.cz

---6. Uživatel specifikuje referenci na klienta 6.1. Uživatel přesune cursor na pole rodné číslo klienta 6.2. Uživatel zadá kompletní rodné číslo a zajistí opuštění pole 6.2.1. Systém nalezna unikátního klienta 6.2.2. Systém zobrazí jméno a příjmení klienta v následujícím poli gridu 6.2.3. Systém uchová referenci na klienta 6.2.4. Systém posune cursor na položku obchodního zástupce ---Tímto zápisem,dle jejich názoru, odpadá složité vysvětlování programátorovi, jak se má systém chovat, ovšem pro uživatele je to "španělská vesnice". Komunikaci s uživatelem vedou na základě Business modelu, který ovšem taky není úplně optimálně napsán a do jisté míry supluje Use Case. Samozřejmě, že dalším vysvětlením jejich postupu je standardní konstatování, že na analýzu podle pravidel není čas.

Prosím Vás proto o Váš názor. Děkuji S pozdravem M.B.

Odpověď na tento mail jsem zformuloval takto:

Přeji pěkný den, děkuji za Váš mail s velmi výstižným popisem problému. To, co popisujete, je velmi častým a běžným jevem, ale co se týče jeho odstranění, tak musím konstatovat, že poradit přes mail

strana 2


není v tomto případě technicky možné, protože to, co nazýváte „radou“, je předmětem 5 denního školení návrhu IS a z toho důvodu obsahově nelze mailem tak širokou problematiku popsat. Mohu se však pokusit o celkové shrnutí chyb, na které byste se měli soustředit a řešit je. Školení OOP a UML v celém 5 denním obsahu mimo jiné vysvětluje jejich podstatu a vede nakonec k jejich odstranění. Tvorbě prvků typu USE CASE spolu s procesním modelováním BPM je ve školení věnován celý jeden den a to i s ukázkovými příklady. Předkládám tedy přehled chyb, které jsou z Vašeho mailu patrné, a to i s jejich charakteristikou a stručným popisem řešení. 1. Zohlednění úrovní abstrakce Ve scénářích není evidentně zohledněno, co je to fáze analytické modelování, fáze designu a kódování a jak se tvoří artefakty těchto úrovní, jaké jsou základní postupy tvorby, jaká je povinná sémantika a vyjadřování na těchto úrovních, jaký tvar a formu mají artefakty těchto úrovní. Došlo k „podstatnému smíchání pojmů z různých úrovní abstrakce“. Této problematice, jaké jsou zásady psaní analýzy, designu a kódu, je věnován celý jeden půlden školení OOP a UML i s příklady. 2. Chybně psané scénáře v prvcích typu USE CASE Psaní scénářů podléhá přísným pravidlům, která jsou evidentně ve vašem případě porušena. Jedná se zejména o porušení pravidla pojmosloví s dodržením úrovně abstrakce analytického modelování (viz předešlý odstavec - např. věta „Uživatel přesune cursor...“ je chybná resp. v další větě zmínka o gridu není v pořádku). Scénář má vystihovat logiku a nikoliv ovládání samotných design prvků. K vyjadřování ve scénářích slouží zavedené uživatelské koncepty, jako ve vašem případě klient, rodné číslo, seznam klientů atd. Kromě těchto pojmů by tvůrce scénáře neměl používat další pojmy „z jiného programátorského prostoru“ (např. cursor, grid atd.).

strana 3


3. Nejsou použity vzory scénářů Vzory jako opakující se řešení situací obecně velmi napomáhají sjednocení postupů. Existují také vzory scénářů případů užití jako opakujících se situací (výběr ze seznamu, editace polí atd.). Tyto vzory evidentně nejsou ve vašem případě použity. 4. Nejsou použita doporučení pro větnou skladbu scénářů Zkušenosti z firem při psaní scénářů mne vedla k určitým doporučením, která zde také nejsou respektována. Jedno z těchto doporučení je, aby se nepoužívalo větné spojení „Systém provede...“, například u vás „Systém nalezne unikátního klienta“, ale namísto toho se pro chování systému (nikoliv aktérů) používala zvratná slovesa. Ve vašem případě doporučuji slovní spojení „...nalezne se ...“ a nikoliv „Systém nalezne...“. Toto doporučení velmi úzce souvisí s objektovým přístupem analytika. Navíc v kombinaci se vzory a zásadami psaní scénářů případů užití by se věta měla doplnit o slovní spojení „nalezne se v seznamu klientů“, k tomu ještě ve větě chybí podle čeho se klient nachází, například „podle zadaného rodného čísla“. Správná věta by mohla znít například takto: „Podle zadaného rodného čísla se v seznamu klientů nalezne klient. Pokud není nenalezen tak <...>“... 5. Model BPM (Business Process Model) nemá suplovat modely případů užití Nalézání a vytváření procesního modelu (BPM) se neděje bezúčelně a netvoří se jen pro komunikaci s budoucím uživatelem (i když se nad ním samozřejmě velmi dobře konzultuje!). Jedná se podle mého názoru o nejlepší metodický postup, jak logicky správně a transparentně nalézat případy užití systému, bez logických chyb, se správnými logickými souvislostmi funkcionalit systému. Mohu z vlastní zkušenosti potvrdit, že všechny ostatní metodiky nalézání případů užití buď úplně selhávají anebo vedou v nepříjemným chybám (například nedoporučuji klasickou metodiku „hledej případy užití přes prvky typu ACTOR“). Hlavní poslání modelu BPM je nalézat adekvátní případy užití podporující chování podniku a to včetně ověření správné logiky chodu podniku spolu s logikou funkcionalit systému. Ve školení je právě tomuto postupu

strana 4


vyhledávání případů užití přes procesy podniku věnována velká pozornost. Závěrem, jaké je tedy doporučení pro Vás a pro Vaše kolegy? Problematika správné tvorby scénářů případů užití je mnohem rozsáhlejší a vyžaduje důkladné studium. Doporučuji absolvovat školení OOP a UML (viz stránka http://www.objects.cz/pobyt/pobytovaskolaUML.html). Na tomto školení je tato problematika včetně dobrých základů a názorných příkladů velmi podrobně a detailně popsána. Navíc bych doporučoval kromě tohoto školení věnovat pozornost Seminářům objektových technologií, zejména semináři, který je konkrétně věnován tvorbě modelu případů užití, viz stránka: http://www.objects.cz/seminare/seminare.html. Na tomto konkrétním semináři jsou tvorbě případů užití věnovány celé dva dny. Doufám, že vám tento mail napomohl ke správné orientaci ve složité problematice psaní případů užití. Zdravím, RNDr. Ilja Kraval. http://www.objects.cz

--- Konec článku ---

strana 5

Jak správně psát scénáře k případům užití?

Recommend Documents