Návrh aplikací v jazyce UML – rozšíření jazyka

24. února 2004

•

Tématem tohoto článku jsou řízená rozšíření jazyka UML, která jsou posledními obecnými pravidly (mechanismy). V praxi se při navrhování různých typů aplikací neustále potýkáme s požadavkem na vyjádření netriviálních faktů, pro jejichž sémantiku není v jazyce UML přímá podpora. Řízená rozšíření překlenují propast mezi všeobecně známými standardními elementy jazyka UML a naší snahou přiměřeným způsobem zohlednit ve vytvářeném modelu charakteristické a specifické aspekty problémové domény.

Uvážené vytváření nových elementů

Když narazíme na fakt, který nelze jednoznačně vyjádřit jedním existujícím elementem jazyka UML, máme na výběr z několika typických způsobů, jak situaci řešit. Nejdříve bychom měli zvážit, zda běžné abstrakci vzpírající se konkrétní fakt opravdu potřebujeme zachytit v diagramu. Vhodně zvolená úroveň abstrakce eliminuje nepoddajná fakta a přispívá tak k přehlednosti diagramů, protože rozmarné a vrtošivé nápady zadavatele ani po zdánlivě úspěšném pokusu o jejich zkrocení očistným ohněm racionalizace neztrácejí nic ze své brizance a schopnosti likvidovat kvalitní návrh.

Představme si, že zadavatel řekne, že v systému existují běžné objednávky, které je možné stornovat, ale uživatel může zvolit, že některé objednávky nelze nikdy stornovat. Po našem dotazu na průměrný počet objednávek, které jsou označeny jako nestornovatelné, se dovíme, že se jedná průměrně o tři objednávky ročně z několika tisíc. Je opravdu pro systém tato informace natolik podstatná, abychom ji v diagramech podchytili a zavedli pro její vyjádření nové omezující podmínky?

Jestliže zachytíme jen tuto jednu odchylku, nic se nestane a digramy budou stále dostatečně přehledné. V reálném systému je ale většinou počet takových požadavků nepříjemně vysoký a diagramy, zachycující všechny méně podstatné údaje pomocí nových elementů, by již nikdo nedokázal po skončení práce návrháře a přechodu do implementační fáze smysluplně interpretovat. První poučkou tedy je, že ani v UML diagramech se kvantita v kvalitu nikdy nepromění. Málo frekventovaná atypická fakta by měla být popsána v samostatném doprovodném dokumentu, který obsahuje podrobné implementační postupy, a také je zdůrazňujeme v alternativním toku případů užití, jak si ukážeme v dalším článku.

Ne vždy ale lze každý problémový fakt ignorovat a jeho vyjádření v diagramech se ukáže být nezbytné pro zvýšení korelace mezi modelem a problémovou doménou. Tato snaha se v literatuře také pojmenovává jako úsilí o dosažení izomorfie mezi doménou zadavatele a softwarovým systémem. Elementy s novým významem deklarujeme v UML pomocí stereotypů, omezení a označených hodnot.

Nevšední stereotypy

Stereotypy (Stereotype) jsou založeny na existujících elementech jazyka UML a upravují jejich význam. Každý stereotyp se vytváří přidáním dvojice lomených závorek s názvem stereotypu k původnímu elementu – <<Název sterotypu>>. Často používané stereotypy jsou integrální součástí jazyka UML a budu se jimi zabývat v dalších článcích. Úpravou významu elementu se rozumí zúžení významu nebo úplná redefinice jeho role v diagramech. Příkladem specializace může být stereotyp <<printer>> pro vyjádření tiskárny v diagramu nasazení.

Zajímavější jsou stereotypy měnící radikálně sémantiku elementu, na nějž jsou aplikovány. Například často používaný stereotyp <<interface>> využívá grafickou notaci tříd pro vyjádření rozhraní. Změněný význam vyjádřený stereotypem můžeme zvýraznit použitím jiné barvy nebo dokonce změnou tvaru grafického symbolu. Stereotypy se změněnými grafickými symboly jsou často využívány v diagramu nasazení, kde fyzické uzly systému místo neforemných „kvádrů“ reprezentují symboly počítačů, laptopů či tiskáren.

Hrátky s barvami či symboly mohou estetickými ohledy nezatížení návrháři pominout, ale vždy musí být přesně definován význam vyjádřený novým stereotypem. Dokumentace ke stereotypu můžete zapsat jako poznámku v diagramu nebo můžete u každého projektu založit a udržovat samostatný dokument s vysvětlivkami pro používané stereotypy. Dokumentaci stereotypů ocení každý člen realizačního týmu. Význam každého stereotypu může být také nepovinně upřesněn označenými hodnotami a omezeními.

Omezení

Omezení (Constraints) se v UML používají pro vyjádření podmínek, které musí být v daném kontextu vždy pravdivé. Představme si systém pro podporu procesu vydání občanských průkazů, v němž platí, že každá evidovaná osoba vlastnící občanský průkaz musí být nejméně patnáct let stará. Tuto podmínku mohu vyjádřit takto: {age >= 15}. Omezení se zapisují do složených závorek a jejich syntaxe by měla být srozumitelná pro všechny členy týmu. S UML verze 1.4 byl sice uveden nový formální jazyk pro zápis omezení (OCL), ale jeho použití v praxi je sporadické, a proto se mu nebudu věnovat. V praxi se většinou používá syntaxe odvozená z používaného programovacího jazyka. Složené omezení u metody {(Role == Power users) || (Role == Administrators)} pro ty, kdo znají alespoň jednoho zástupce z rodiny C jazyků, bude určitě srozumitelně vyjadřovat, že daná metoda může být volána, když je přihlášen uživatel s rolí Power users nebo Adminstrators.

Někteří vývojáři si bohužel stále myslí, že omezení v diagramech jsou roztomilou ozdobou a svědectvím o pěkné inspirativní chvilce návrháře a že je při psaní kódu zohledňovat nemusí. Všechna omezení v návrhu ale musí být v kódu transformována na explicitní předpoklady, jejichž neočekávané porušení musí být vyhodnoceno jako přechod aplikace do nestabilního stavu spojený se zapsáním chyby do aplikačního logu a okamžitým ukončením aplikace.

Označené hodnoty

Poslední mechanismus, jak upravovat elementy v jazyce UML, představují označené hodnoty (Tagged Values). Označené hodnoty se shodně s omezeními zapisují do složených závorek, ale jejich syntaxe vyžaduje použití názvu atributu s přidruženou hodnotou – {atribut=hodnota}. Pokud k elementu přidáváme více označených hodnot, musíme je oddělit čárkou. Označené hodnoty vyjadřují další podstatné informace o elementu a také mohou zavádět nové vlastnosti u stereotypu. Můžeme je například použít k zadání informace o verzi třídy {version = 1.0}.

Tímto je teoretický přehled, zaměřený na základní konstitutivní prvky jazyka UML, za námi, v dalším článku se již budeme zabývat případy užití (Use cases), kterými většinou začíná každá analýza.