Vyvarujte se časté chybě při psaní scénářů případů užití

autor: RNDr. Ilja Kraval, říjen 2011

Object Consulting s.r.o.

Server objektových technologií

http://www.objects.cz

Tvorba slovních scénářů v případech užití systému se již stala v podstatě standardním postupem při vývoji informačních systémů. Již relativně málo SW firem nezavedlo tuto vcelku jednoduchou a přitom efektivní metodu zadání algoritmu pro programátory.

Tento článek pojednává o jedné z chyb, které se může firma při stanovení pravidel psaní scénářů případů užití dopustit. Díky ní se výrazně snižuje efektivita tohoto postupu.

Zmíněná chyba spočívá v nedodržení principu zohlednění úrovní abstrakce informačního systému.

Poznámka: O nutném zohlednění úrovní abstrakce je podrobně pojednáno v knize Analytické modelování pomocí UML v praxi, kapitola 2 (zdarma ke stažení).

Pokud hovoříme o systému, když jej vyvíjíme a dokumentujeme, vždy se v daném okamžiku pohybujeme na tzv. úrovni abstrakce. Každá úroveň abstrakce je dána mírou detailu implementace, která určuje, jak moc jsme implementačně podrobní a tedy do jaké míry je vyjádření (syntaxe) v dokumentech vývoje poplatné dané technologii.

Vývoj informačního systému a jeho následná dokumentace

musí (a nelze jinak) podléhat úrovním abstrakce. Prakticky se doporučuje zavést tři oddělené úrovně abstrakce, tj. tři okruhy dokumentace.

Doporučené úrovně abstrakce IS jsou následující:

·        Analytické modelování (míra detailu implementace nula),

·        Návrh designu (sice stále ještě modelování, ale je poplatné výrazově danému prostředí, například třídy jsou z daného prostředí),

·        Kódování (nejnižší úroveň abstrakce, maximální detail implementace).

Jedním z nejčastějších prohřešků tvorby dokumentace vývoje je bohužel právě „promíchávání“ úrovní abstrakce v jednom dokumentu. Vývojář vytvoří dokument, ve kterém se vyskytují odstavce a někdy dokonce i věty, ve kterých se úrovně abstrakce prolínají, tj. promíchají. Vznikají tak vysloveně paskvilné dokumenty, které nemají ani analytickou a ani technologickou povahu, protože obsahují obě úrovně abstrakce.

Právě oblast psaní scénářů případů užití bývá nejčastějším místem výskytu tohoto prohřešku proti zásadnímu pravidlu vývoje IS: „Důsledně oddělujte analytický model od technologického návrhu“.

Základní otázkou analytického modelu je dotaz „o co v systému logicky jde“. Oproti tomu základní otázkou návrhu technologie je řešení problému „jak je tato logika navržena v technologii“.

Tomuto pravidlu musí odpovídat i psaní scénářů. Znamená to, že ve scénáři by se měla objevit pouze čistá logika chodu algoritmu vyjádřená pouze pomocí chování výskytů evidovaných pojmů - a nic víc.

Již mnohokrát jsem při konzultacích mohl vidět ve firmách zavedené metodiky psaní scénářů, ve kterých se vyskytovala spousta věcí navíc a to technologického charakteru. Namísto jednoduchého logického scénáře se celý dokument „nafouknul“ o detaily technologie a stal se zbytečně složitým dokumentem.

Jako příklad takového „nafouknutí“ bych uvedl relativně jednoduchý analytický scénář přihlášení uživatele s výběrem role. Nechť je v daném IS zavedena jednoduchá agenda přístupových práv, kdy se uživatel přihlásí a vybere si jednu z povolených rolí, ve které „žije“ po dobu přihlášení. Poté se v jiných případech užití v daném okamžiku, kdy je třeba, vyhodnotí, zda tato daná role přihlášeného uživatele má právo k dané akci v daném bodě programu.

Analytický model takovéto agendy je jednoduchý:

Scénář případu užití s výběrem role pak vypadá například takto:

Všimněte si, že scénář je jednoduchý, čitelný a lze jej pochopit na první čtení.

Chyba zavlečení technologie do analytického scénáře spočívá v tom, že namísto takovéhoto jednoduchého scénáře se vytvoří jiný, mnohem složitější, ve kterém se začnou vyskytovat technologické pojmy, jako například tabulka TUSER, tabulka TROLE, primární klíč a cizí klíče, konkrétní SQL příkazy, volání funkcí resp. metod objektů, popis prvků z obrazovky a jejích konkrétních ovládacích prvků a spousta dalších technologických podrobností.

Mohu z praxe potvrdit, že původně jednoduchý scénář tímto celkovým popisem technologického postupu realizace tohoto scénáře nakonec změní na dvě hustě popsané stránky A4 a původní jednoduchý „logický scénář“ se prostě ztratí a zmizí.

Firmy, které tento postup zavádějí, jej zdůvodňují snahou zadat programátorovi relevantní zadání „se vším všudy“. Proto tvoří takovýto složitý scénář a proto obhajují tento postup.

Samozřejmě nelze nic namítat proti požadavku, aby programátor dostal „celé zadání“. Nesmí to však být na úkor dvou věcí:

1.     vždy musí existovat jednoduché logické zadání oproštěné od technologie

2.     tvorba zadání technologického návrhu musí být jednoduše tvořená a nesmí vývoj zbytečně zdržovat

První požadavek je zřejmý. Uvedený scénář (u nás jako příklad přihlášení v pouze v analytickém logickém textu) musí být viditelný a zpracovatelný samostatně tak, že do něj nejsou zavlečeny postupy technologie a to dokonce ani po zadání do technologie a po realizaci (pamatujme na budoucí změnová řízení!).

Druhý požadavek je trochu zvláštní: Viděl jsem velmi bohatě technologicky popsané scénáře napsané například ve Wordu, které by se daly rychleji naprogramovat, než takto je ve Wordu napsat. Psát technologii ve Wordu je zbytečná dřina a pak vše stejně najdeme v realizaci!

Dokumentace technologie má totiž oproti analytické dokumentaci svoje zvláštnosti: Mnohdy vývojáři vynaloží obrovské úsilí na napsání toho, co je zřetelně vidět a je sebe-popisné (self-describing) samotnou realizací, která bývá mnohdy automatizována, což je postup samozřejmě rychlejší a efektivnější.

V podstatě jde o to, že nedodržení bodu 2 předešlého výčtu (tedy jednoduchosti technologického zadání) vede ke spoustě zbytečného popisu ve Wordu, kterou nakonec zvládne sama technologie.

Dodržování principů podle bodu 2 (tj. dodržet jednoduchý a nezdržující rychlý a efektivní popis zadání do technologie) vyžaduje splnění dvou požadavků:

1.     Zadání pro přechod z analytického scénáře do realizace by mělo být prováděno pomocí vzorů, tj. opakujících se řešení. Mnohdy tato opakující se řešení ani nemusí být zavedena v katalogu vzorů ve firmě, protože jsou vnitřním ustáleným „know how“ ve firmě, neboli známými potupy ve smyslu „takto to u nás děláme“. Každá firma má takovýto seznam, i když o něm ani neví, vývojáři jej nosí v hlavě. Samozřejmě ideální je tato opakující se řešení zdokumentovat ve firemním katalogu.

2.     Musí existovat zpětné jasné provázání mezi realizací a analytickým dokumentem. Znamená to, že například pomocí značek v textu (které lze zviditelnit anebo vypnout apod.) je určeno, která část realizace realizuje kterou část scénáře. Mnohdy je tato vazba z kontextu jasná, protože pokud se používá objektové programování, tak v kódu velmi dobře zjistíme, který původní analytický scénář odpovídá které realizované spolupráci objektů. Tento požadavek musí být však splněn tam, kde to jasné není.

Uvedené dva body předešlého výčtu vlastně znamenají jednoduchý poznatek:

V nejjednodušší verzi postupů pokud se „zkušený“ programátor znalý technologických postupů ve firmě podívá na předešlý jednoduchý analytický scénář přihlášení s výběrem role, tak prostě před sebou vidí ihned kód, jak by jej realizoval. Dovedu si představit (a zkušenosti analytika v projektech mi to potvrzují), že v tomto případě prostě převezme toto zadání a realizuje jej podle ustálených postupů ve firmě (nezapomeňme, že tabulky a objekty jsou navrženy přes model tříd, nikoliv přes scénáře, zde je řeč o realizaci algoritmu chodu programu!).

V této jednoduché verzi se spoléháme na to, že programátor zná dobře, jaké jsou ustálené postupy ve firmě, a že zpětná vazba z kódu na zadání bude transparentní (tj. kód je objektový a čistý).

Pokud bychom však chtěli být v dokumentaci úplně přesní, potom bychom měli tento zjednodušený postup doplnit o následující informace:

1.     Jaký vzor (ustálený postup) bude pro realizaci použit

2.     Která část kódu odpovídá které realizaci, pokud by kontext tohoto vztahu nebyl z kódu úplně zřejmý.      

·        Jedním z častých prohřešků při psaní analytických scénářů je namísto něj předložit přímo složité technologické zadání. Analyticky jednoduchý scénář se ztratí a vznikne zbytečně složitý dokument.

·        Psaní takového technologického zadání ve Wordu bývá mnohdy balastem. Zadání pro realizaci při ustálených postupech technologie ve firmě je na základě analytického scénáře zřetelné a jasné, dokument ve Wordu je zbytečně složitý a obtížně tvořen.

·        Pokud chceme zadat pro realizaci úplnou informaci, měla by obsahovat vzor realizace a následně realizace by měla obsahovat zpětnou vazbu do analytického modelu tam, kde se ztrácí kontext vztahu od realizace zpět k analytickému modelu.

Konec článku

Zajímavá nabídka pro firmy z Brna a okolí Pobytový kurz návrh IS pomocí UML a OOP jaro 2012 Kurz profesního růstu analytika AM ADVANCED, termín 12.3.2012

Poznámka pod čarou

Určitě spousta čtenářů má vlastní zkušenosti s psaním scénářů. Vracím se proto k tradici diskuse a otevírám diskusi k tomuto článku o psaní scénářů.

Jaké máte vy zkušenosti s psaním scénářů případů užití?

Diskutujte prosím zde