Aktuální vydání

celé číslo

12

2021

Automatizace v chemickém a petrochemickém průmyslu

Průtokoměry a regulační ventily

celé číslo

Recenze: Use Cases – jak efektivně modelovat aplikace

číslo 10/2006

Recenze: Use Cases – jak efektivně modelovat aplikace

Cockburn, A.: Use Cases – jak efektivně modelovat aplikace. CP Books, a. s., Brno, 2005, 262 stran, ISBN 80-251-0721-3, náklad neuveden, cena 299 Kč. Z anglického originálu Writing Effective User Cases, Pearson Education/Alistair Cockburn, 2001, překlad CP Books, 2005.

Kniha s názvem obsahujícím sousloví Use Case jistě upoutá pozornost projektantů, analytiků i programátorů počítačových aplikací. Tento pojem znají z metodik analýzy a návrhu počítačově založených systémů intenzivně rozvíjených na základě principů objektově orientovaného (OO) programování již od poloviny 90. let dvacátého století. I studenti počítačových a automatizačních oborů a v potřebné míře i studenti ostatních technických oborů se s nimi seznamují ve výuce také již nejméně deset let. Pokládáme proto za účelné o této knize referovat v časopise Automa, a to z pohledu projektování automatizovaných informačních a řídicích systémů (IŘS).

Metoda v anglickém originále nazvaná Use Case v doslovném (podle našeho názoru nepříliš vhodném) překladu znamená případ užití. Čtenář by jistě rád věděl čeho. S přihlédnutím k obsahu původního pojmu a s ohledem na naši rodnou řeč bychom měli prosazovat název uživatelský diagram, graf nebo pohled. Uživatelské hledisko na činnost navrhovaného systému je totiž to, oč tu běží, a grafická forma nezvratně převážila nad výlučně verbální formou zápisu.

V uplynulých patnácti letech bylo u nás již mnoho řečeno a napsáno o metodikách návrhu a realizace IŘS. Víme tedy, jaký význam pro praxi má grafická podoba podpory těchto metod. Považujeme tedy za správné mluvit o uživatelském diagramu, jakožto ekvivalentu originálního „případu použití“.

Nebude jistě na škodu stručně připomenout historii uvedené metody. Předchůdci OO přístupů byly strukturované přístupy. V nich byl východiskem analytických a návrhových úvah diagram informačních toků. Nic takového v čisté formě v OO metodách nenacházíme. Sestrojit přehledný a srozumitelný diagram informačních toků při důsledné aplikaci OO přístupu je totiž obtížné. A pokud se nadměrně využívají možnosti abstrakce, které OO přístup nabízí, je to zhola nemožné. Zřejmě proto byl do metodiky UML (Unified Modelling Language), která nakonec převážila nad mnoha originálními metodami, pojat diagram „Use Case„, jehož autorem byl I. Jacobson, který metodu vytvořil počátkem 60. let minulého století. Do původní verze UML byla zahrnuta v prvotní extrémně primitivní verzi. V dalších verzích UML byla postupně rozšiřována a nyní již značně připomíná zmíněné informační toky, i když bez striktního řádu a systematičnosti, které metodě informačních toků vložil do vínku její autor De Marco také již v 60. letech.

Tolik na úvod, neboť autor recenzované knihy se vydal jinou cestou. Pojímá předkládanou metodu jako v podstatě univerzální prostředek vývoje aplikací. Proto zde musíme, alespoň zčásti, dát za pravdu překladateli, který „Use Case„ důsledně překládá jako „případ užití“. Bude tak odlišena metoda předkládaná v knize od její jmenovkyně, která v OO metodikách zastává skromnější postavení.

Autorova zkušenost s řešením úloh pro praxi (pro pojišťovny, maloobchod a systémy tzv. e-komerce), ho přivedla k názoru, že nejdokonalejším nástrojem analýzy a návrhu je verbální popis. Otevřeně odsouvá grafické metody na okraj zájmu. To činí zcela nepokrytě, ovšem svoji nechuť k ostatním metodám, natož k uceleným metodikám, poněkud zakrývá.

Tento autorův postoj se neblaze projevuje obtížemi při čtení a snaze pochopit jeho myšlenky. Používá dosti nestandardní terminologii. Například nezná, nebo jen velmi omezeně používá pojmy systém a informace, daty se zabývá jen zřídka. Nerozlišuje mezi strukturou systému a jeho chováním. Mluví sice o chování, ale nerozlišuje mezi obecným chováním a algoritmem chování. Pojem struktura v jeho klíčovém významu pro analýzu systémů nepoužívá vůbec. Zavádí pojem „úspěšný scénář„ pro hlavní část algoritmu a výjimky považuje za rozšíření tohoto hlavního (úspěšného) scénáře. Tím se jádro algoritmu, obvykle jednoduché až k triviálnosti, odděluje od zbytku algoritmu, tvářícího se jako doplňující výjimky. Přitom však právě tyto „výjimky„, dobře definované a implementované, jsou hlavním předpokladem úspěchu projektu.

Autor se těmito problémy příliš nezatěžuje a hlavní pozornost zaměřuje na stylizaci slovního vyjádření. Je zřejmě v zajetí svých aplikací, které ze systémového pohledu nejsou složité. Jejich složitost je v pochopení souvislostí systému, do kterého je aplikace vkládána. Průvodním znakem podobných projektů je neúplné a velmi často i chybné zadání. Autorovi tedy vlastně jde především o formulaci požadavků na navrhovaný systém. Výhradně ovšem požadavků uživatelských, tudíž vlastně o formulaci uživatelského zadání. Počítá s obtížnou komunikací se zadavatelem, který často jen zhruba tuší, oč běží, a přehlíží širší souvislosti. S takovou situací se lze jistě občas setkat v aplikacích, ze kterých autor sbíral své zkušenosti (rozhodně ale podstatně častěji, než jsme zvyklí u standardních IŘS v oboru automatizace). Ani v těch případech, autorem preferovaných, však není „případ užití“ jediným nebo zdaleka nejlepším nástrojem. Stejně jako scénáře, které jsou také autorovým oblíbeným nástrojem. Efektivní použitelnost těchto přístupů totiž končí právě u tak triviálních příkladů, jaké jsou v knize uvedeny.

Autor zřejmě netuší, že mnoho uznávaných a používaných metodik projektování zavádí po formulaci zadání uživatelem další kroky zabývající se zpracováním uživatelských požadavků do konečné formy specifikace systému, která vlastně teprve je skutečným plnohodnotným zadáním pro vlastní projektování. Existují i propracované metodické a počítačově podporované systémy specifikace a sledování požadavků na systémy.

Z uvedeného částečného výčtu podivností autorova přístupu k projektování počítačových aplikací se naskýtá otázka, zda byl překlad a vydání této knihy dobrým počinem. Rozhodně nelze knihu doporučit ani méně zkušeným projektantům automatizovaných IŘS. Byla by snad použitelná jako pomůcka při výuce češtiny na technických středních školách v roli názorné ukázky slohových cvičení pro budoucí projektanty. Rozhodně nelze souhlasit s určením pro programátory a analytiky, uváděným vydavatelem na zadní straně přebalu knihy v tabulce „Zařazení publikace„. Spíše by bylo možné ji doporučit uživatelům-začátečníkům. Ovšem s upozorněním, že je její přečtení zavede do světa pojmů, které početná obec našich programátorů analytiků nezná a nepoužívá.

Překlad knihy jistě nebyl pro překladatele lehkou záležitostí. Při podrobnějším studiu lze najít dosti nepřesností. Nejvíce prohřešků, i vážnějších, je v překladu základních termínů. Překladatel mohl knihu přeložit buď velmi volně, nebo se držet co nejblíže originálu. Zvolil druhou cestu, v daném případě vhodnější. Pak mu ovšem nelze klást za vinu, že některé výklady jsou dosti krkolomné, příměry mírně zavádějící a některé formulace obtížně srozumitelné. I z překladu lze vycítit, že ty krkolomnosti jdou na vrub autora originálu. Abychom byli konkrétní, zmiňme příklad s mořskou hlubinou, hladinou moře a nebeskými výšinami jako příměr spíše zatemňující než objasňující. Příkladem k výtce nesrozumitelnosti je následující věta: „Rozsah je výraz, který používáme pro vyjádření velikosti toho, co navrhujeme, jako vymezení rozměru návrhu.„ Autorovi zde zřejmě šlo o to, co lze vyjádřit větou: „Účel navrhovaného systému je vyjádřením souhrnu funkcí, které má systém zajistit na daném objektu.„ K nesmyslnosti věty uvedené v knize zřejmě přispěl i překladatel. Byl-li v originále, jak lze vytušit, použit výraz scope, nejde zde o rozsah, ale zcela nepochybně o cíl.

Je třeba také poznamenat, že originální název knihy – Writing Efective Use Cases – lépe vystihuje její zaměření. Rozhodně totiž nejde o efektivní modelování aplikací, rozuměj všech možných. V tom je název českého překladu zavádějící. Když vydavatel zvolil tento poněkud lákavější název, měl dodat, na jaké aplikace se zaměřuje.

Na adresu vydavatelství je namístě konstatování, že by jeho dobrému jménu prospělo, kdyby věnovalo větší péči výběru originálních publikací a zejména publikací překládaných z cizích jazyků. Kvalitativní rozdíl mezi recenzovanou knihou a např. knihou Petra Palety „Co programátory ve škole neučí…„ (viz recenze v časopise Automa č. 6/2004 – pozn. red.), uvedenou v nabídce na přebalu, je nebetyčný.

Jiří Cendelín