Návrh aplikací v jazyce UML – Unified Modeling Language

5. listopadu 2003

•

„Kvalitní objektově orientovaný návrh aplikace je nezbytným předpokladem jeho úspěšné implementace“. Tuto floskuli pravděpodobně slyšel každý, kdo se vývojem aplikací zabývá profesionálně. I v přetechnizované IT oblasti je módní používat libozvučná magická zaklínadla, jež mají zákazníka utvrzovat v profesionalitě dodavatele, který ale často není schopen dostát nárokům kvalitního návrhu, zato se brilantně orientuje v PR frázích a zná nazpaměť aktuální slovník buzzwords. Ambicí této série článků je očistit větu o kvalitním návrhu od otravných pseudomarketingových zplodin a ukázat skutečné výhody precizně provedeného návrhu pomocí modelovacího jazyka UML.

Kvalita je ideál

Kvalitu aplikace není možné empiricky změřit či exaktně definovat postupy k jejímu dosažení ve formě receptu pro líné návrháře. Je však možné identifikovat nároky kladené na aplikaci, kterou bude považovat za kvalitní zákazník i dodavatel.

Shoda původních požadavků zadavatele s funkční specifikací vyvinuté aplikace. Ad hoc úpravy dodané aplikace na vlastní náklady a nedůstojné handrkování se zákazníkem si snad nikdo nemůže přát.
Spravovatelnost aplikace. Aplikaci je možné snadno rozšiřovat na základě nových požadavků zadavatele. Snadné rozšíření opravdu neznamená, že aplikaci pokaždé v rekordně krátké době z devadesáti procent přepíšete. Rychlé ruce „bušičů kódu“ nemohou být donekonečna adekvátní náhradou intelektu analytiků. Série strastiplných porodů zcela nových verzí aplikace vede většinou k nasazování zmetků, u nichž se odstraňují stále stejné chyby.
Opakovaná použitelnost částí aplikace. Nemá smysl psát stále dokola stejné komponenty, ale je vhodné jejich funkcionalitu zobecnit, aby je bylo možné beze změny používat v dalších aplikacích.
Spolehlivost aplikace. Spolehlivost se definuje jako schopnost aplikace reagovat na stejnou sadu podmínek stejným způsobem. Zákazník většinou nechce svůj informační systém provozovat jako vnitrofiremní loterii, ze které vypadávají náhodná data.
Robustnost aplikace. Dodaná aplikace musí být schopná zotavit se z různých výjimek, aniž by došlo ke ztrátě či úniku dat, nebo dokonce k celkovému dlouhotrvajícímu výpadku aplikace.

Výčet vlastností kvalitní aplikace jistě není úplný, ale pojem kvalita má nyní zřetelnější kontury. Dobře vytvořený návrh umožňuje do vyvíjené aplikace zmíněné vlastnosti integrovat už na počátku jejího životního cyklu.

Spasí nás UML?

Návrh aplikace může teoreticky vzniknout pouze za použití tužky, mozku a poznámkového bloku, s jejichž pomocí načrtnete jednoduchý model aplikace. Model ale bude používat jen vám známou syntaxi a sémantiku, takže budete jen těžko své záhadné omalovánky s někým sdílet. Dalším problémem je, že za těmito náčrty většinou nestojí žádný konzistentní logický metamodel ani formálně kodifikovaná sémantika jednotlivých elementů modelu, takže případná komunikace mezi návrháři připomíná situaci v IT Babylónu po zmatení jazyků a je protkána slovy „asi“, „možná“ a „jak to vlastně bylo myšleno“.

Unified Modeling Language (UML) má již ve svém názvu slovo unifikovaný, protože jedním z jeho cílů je sjednocení používaných výrazových prostředků. UML je jazykem s bohatou sémantikou a syntaxí, který usnadňuje návrh a vizualizaci různých typů aplikací. Navíc tvůrci jazyka UML nebyli natolik naivní ani sebevědomí, aby věřili, že standardními elementy jazyka UML pokryli kompletně veškeré požadavky návrhářů, a přímo do jazyka zabudovali mechanismy rozšíření, které usnadňují řízenou deklaraci a definici nových elementů jazyka.

UML je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe, a proto můžete výsledky své práce sdílet s ostatními návrháři. UML ale není všemocné. I když umíte UML, ovládáte pouze nástroj. Sice velmi výkonný, ale stále jen nástroj – ty, kteří si myslí, že UML je cizokrajné koření, které použijí na dokrvení svých anemických návrhů, musím zklamat. Znalcem UML se člověk stává, návrhářem či analytikem se rodí.

Stručná historie cesty k eklektickému UML

Jazyk UML nevznikl ve vzduchoprázdnu, předcházelo mu myšlenkové úsilí mnoha OOP znalců o vytvoření kvalitní metodiky. Následující stručný výčet metodik, které měly největší vliv na jazyk UML, si nečiní nárok na úplnost.

Object modeling technique (Rumbaugh, Premerlani)
Object oriented software development (G. Booch)
Object oriented software engineering (I. Jacobson)
Object oriented structured design notations (Wassermann, Pircher)

V roce 1996 pánové Jacobson, Booch a Rumbaugh, kteří již dříve významně přispěli k rozvoji OOP metodik, přešli k firmě Rational Corp., pro kterou vytvořili jazyk UML. V roce 1997 byl jazyk UML akceptován jako průmyslový standard a postupně začal vytlačovat ostatní analytické jazyky na pověstné smetiště dějin. V současné době se připravuje uvedení verze 2.0. V existujících CASE nástrojích se můžete většinou setkat s podporou UML verze 1.2, 1.3 nebo dokonce 1.4. Na klíčové rozdíly mezi jednotlivými verzemi vás vždy upozorním v příslušné tématické části o jazyce UML.

V nadpise této části článku je UML označeno jako eklektické. Autoři UML i podle vlastních slov postupovali tak, že z existujících konkurenčních jazyků vybrali nejlepší myšlenky a adoptovali je do jazyka UML, který podtrhl jejich význam integrací do nově promyšleného celku. Termín eklektismus není tedy zmiňován v souvislosti s UML nijak pejorativně, ale naopak popisuje nutnou selekci hodnotných myšlenek z mnohdy obskurních nápadů různých metodik.

UML pohledy na systém

Jaké hlavní aspekty modelované aplikace dovoluje UML zachytit? Model v UML se skládá z různých diagramů, jež představují průhledy na různé části sémantického základu navrhované aplikace. Sémantickým základem je souhrn specifikací aplikace, který vymezuje teritorium, v němž se může návrh pohybovat. Diagram ve vizuální formě vypráví právě jeden konkrétní „příběh“ o aplikaci. Žádný dvourozměrný diagram nemůže zachytit komplexní aplikaci v celku, ale soustředí se vždy právě na jeden důležitý aspekt. Jazyk UML rozeznává pět základních pohledů na systém.

Pohled případů užití. V případech užití jsou vyjádřeny základní požadavky kladené na systém. Veškeré další pohledy se pohybují v mantinelech vymezených pohledem případů užití.
Logický pohled se zabývá zejména pojmy z problémové domény zadavatele a jejich vzájemnými statickými vztahy.
Procesní pohled se soustřeďuje na chování systému, které musí splňovat požadavky a omezení z případů užití, jež jsou kladeny na průběh procesů. Pregnantně řečeno, jedná se o procesně orientovaný doplněk logického pohledu.
Implementační pohled zachycuje fyzické rozdělení aplikace na samostatné komponenty a jejich závislosti.
Pohled nasazení mapuje komponenty na množinu fyzických výpočetních uzlů v cílovém prostředí.

Pohledy jsou konkretizovány v následujících typech diagramů, jejichž detailní popis bude předmětem dalších článků.

Diagram případů užití
Diagram tříd
Diagram objektů
Diagram komponent
Diagram nasazení
Sekvenční diagram
Kolaborační diagram
Stavový diagram
Diagram aktivit

V následujícím článku se podíváme podrobně, jak je UML jazyk strukturován, jakým způsobem jej můžeme rozšiřovat a jak jsou základní pohledy na aplikaci sjednoceny v termín „architektura“.