Návrh aplikací v jazyce UML – základní pojmy a pravidla

13. ledna 2004

•

Předchozí článek se snažil váhajícímu i skeptickému čtenáři prezentovat výhody analýzy a návrhu softwarových systémů v jazyce UML. Nepsaným mottem článku byl apel „opusťte archaické způsoby tvorby aplikací“. Tento a následující články jsou již orientovány na čtenáře, který se rozhodl, že návrh pomocí UML se stane fundamentální součástí jeho analytické výzbroje. V tomto článku se soustředím na popis základních stavebních bloků a obecně platných pravidel v jazyce UML.

Škatulkování pojmů

V jazyce UML se rozlišují tři základní stavební bloky (Building Blocks):

Předměty (Things). Do předmětů jsou řazeny samotné elementy modelu. Oblast předmětů je dále členěna na podkategorie. Podkategorie strukturních předmětů (Structural Things) obsahuje subjekty modelu. Subjekt modelu nese statické informace o softwarovém artefaktu a je většinou vyjádřen podstatným jménem (třída, komponenta, uzel). V podkategorii pro dynamické předměty (behavioural things) se nalézají předměty, které zachycují dynamické chování systému (aktivita, stav). K sdružování sémanticky příbuzných předmětů se používají takzvané balíčky, pro něž je vytvořena samostatná kategorie předmětů vyjadřujících seskupení (Grouping Things). Ke každé části modelu je možné zadat libovolné množství poznámek. Poznámky patří do kategorie anotačních předmětů (Annotational Things).

Relace (Relations). Předměty neleží vedle sebe jako chaotické shluky nesouvisejících informací, ale jsou vzájemně propojeny komplexním předivem vztahů. Vezmeme-li analogii ze života, na světě je až neřestně velké množství krásných holek, okolo kterých bohužel jen projdete, ale k mizivému promile (manželka, milenka) si vytvoříte vztah. Tento nový vztah omezuje možnosti dalších vztahů jedné pěkné holky k jejímu indiferentnímu a mnohdy kupodivu UML vztahy nechápajícímu mužskému okolí, a navíc vám určí jednu z životních rolí. (UML diagramy mi tedy navíc daly odpověď na věčnou otázku, proč nemohu ani já, jakožto maximalista, mít jen pro sebe všechny hezké holky.) Vztahy v modelu ukazují, jak spolu jednotlivé předměty souvisí.

UML rozeznává následující typy vztahů:

Asociace (Association). Obecná souvislost předmětů. UML přesně definuje asociaci jako „měnící se populaci vztahů daných propojením objektů“. Co přesně tato věta znamená, bude vysvětleno u diagramu tříd, kde budete seznámeni i se speciálními variantami asociace, kterými jsou kompozice a agregace.
Závislost. Změna v jednom předmětu způsobí změnu v jiném předmětu nebo mu poskytne požadovanou informaci. Například když třída pro odesílání emailu v aplikaci získá šablonu emailu z třídy globálních konfiguračních parametrů, měli bychom tento vztah zachytit jako závislost. Dobře zmapované závislosti nás neustále informují o celkové míře provázanosti jednotlivých částí modelu. Pokud závislosti v modelu začnou připomínat propletené křižovatky, je na čase vztahy mezi třídami refaktorovat, protože jde o spolehlivý symptom blížícího se poločasu rozpadu implementovaného systému při prvním pokusu o jeho další rozšíření.
Generalizace (Generalisation). Jeden předmět je specializací jiného předmětu. Například třída osobní auto je specializací obecné třídy vozidlo. Vztahy generalizace a specializace jsou v objektově orientovaném modelování velmi důležité, protože jejich neadekvátní použití předznamenává většinou krizi celého návrhu i jeho implementace.
Realizace (Realization). Realizace je druh vztahu, při němž jeden předmět představuje dohodu, za jejíž plnění je odpovědný jiný předmět. Například z jazyků JAVA, C# a dalších jistě znáte rozhraní, která reprezentují dohodu, jejíž plnění je požadováno po třídách, jež rozhraní implementují.

Diagramy (Diagrams). Diagramy byly již podrobně vysvětleny v předchozím článku, zde jen připomenu, že diagramy zachycují různé aspekty modelovaného systému.

Kreativita zajatá v pravidlech

Obecná pravidla (obecné mechanismy) řídí tvorbu modelu. Tato pravidla jsou neustále přítomna při tvorbě libovolných diagramů a určují legální sdílené komunikační strategie mezi různými analytiky a návrháři. Namísto živelných nápadů a kryptických hříček vznikají díky obecným mechanismům jazyka UML všeobecně srozumitelné modely.

Specifikace (Specification). Specifikaci jsem již vysvětloval v předchozím článku, nyní pouze zdůrazním, že specifikace představuje sémantický základ modelu a bez ní jsou všechny diagramy pouhým melancholickým skladištěm významově vyprázdněných symbolů.
Podrobnosti (Adornments, též Ozdoby). Každý element modelu může být v různých diagramech reprezentován jinou výsečí z množiny všech informací, které jsou o něm známy. Při modelování složitého systému se často dostaneme do situace, kdy se jeden element vyskytne na více diagramech. Představme si systém, kde je na jednom diagramu tříd složitá třída Uživatel zachycena se všemi atributy a metodami. V jiném diagramu pro realizaci objednávek chceme pouze modelovat relaci, která vyjadřuje fakt právě jeden uživatel je zakladatelem objednávky. Na diagramu pro realizaci objednávek bude ze všech informací o třídě „Uživatel“ zobrazen z důvodu přehlednosti pouze její název, protože její atributy a metody jsou zde irelevantní.
Obecné dělení (Common Divisions, též Podskupiny). První obecné dělení, s názvem „klasifikátor a instance“, zavádí distinkci mezi typem a instancí typu. Pro ty, kdo programují v libovolném objektově orientovaném jazyce, stačí říci, že příkladem je rozlišení mezi třídou a instancí třídy (objektem). Pro návrháře nedotčené programováním uvedu jednoduchý příklad – slovo počítač označuje naši abstraktní představu o počítači (klasifikátor pro všechny počítače), konkrétní počítač, na kterém tento článek píši, je jednoznačnou instancí klasifikátoru. Aristoteles, kterému patří prvenství v rozlišování mezi typem a instancí typu, je jistě potěšen, že jeho myšlenky v 21. století zaujímají čelní místo v pravidlech UML. Druhé obecné dělení má název „rozhraní a implementace“ a týká se odlišení toho, co předmět vykonává, od toho, jak to vykonává. Rozhraní pouze říká, co se předmět, který rozhraní poskytuje, zavazuje dodržet, ale zcela pomíjí způsob, jak to udělá. Opět pro ty z vás, kteří programujete třídy a komponenty, jistě tento koncept není nový. Interní implementaci třídy můžete vždy měnit zcela nezávisle na jejím rozhraní, aniž by tím byli dotčeni existující klienti třídy. Pro ostatní uvedu zase triviální příklad – u mikrovlnné trouby mě zajímají pouze ovládací prvky (rozhraní), pomocí nichž si ohřeji jídlo, ale je mi zcela jedno, jaké procesy se po spuštění uvnitř trouby dějí (implementace).

Další rozsáhlejší skupinu pravidel představují mechanismy rozšíření, na něž se soustředí příští článek. Poté se již budu plně věnovat praktické analýze a návrhu aplikací.