UML-LOGO UML - Diagram tříd

Diagramy tříd (class diagram) patří bezesporu k nejčastěji používanýmnástrojům UML a tvoří vůbec jakýsi základ všech prostředků objektovéanalýzy a designu . Tyto diagramy jsou většinou vytvářeny již ve fázianalýzy často jako pojmové modely, jejichž úkolem je formálnějidefinovat jednotlivé termíny používané ve studované problémové oblasti.Takové modely jsou maximálně přínosné a užitečné v okamžiku, kdy jenutno zpětně vstřebat terminologii oboru. S postupným přibližováním kfázi implementace jsou diagramy tříd poměrně zásadně přehodnocovány a videálním případě zpracovávány až do podoby grafického modeluekvivalentního zdrojovému kódu.

Diagramy tříd zobrazují statickou stránku systému, především vztahy mezitřídami. UML explicitně rozlišuje několik druhů tříd (parametrizovatelnétřídy, …), stejně jako rozličné množství vztahů, které jednotlivé třídynavzájem pojí (asociace, agregace, kompozice, specializace/generalizace,...).

Tvorba diagramů tříd patří mezi klíčové problémy a zcela vážně lzeprohlásit, že zvládnout objektový přístup často znamená správně využívatprávě tento typ diagramů používaný průběžně napříč celým životním cyklemtvorby IS. Zvláště při tvorbě těchto diagramů se doporučuje dodržovatnepsané pravidlo 7 + 2, které říká, že v jednom diagramu je vhodnézobrazit 7, maximálně až 9 tříd. Při respektování tohoto doporučení sevětšinou výraznou měrou zpřehlední výsledné modely, nicméně na druhoustranu vyvstává problém vhodného rozdělení systému na dílčí oblasti (vterminologii UML jsou jimi tzv. packages). Asi nejčastěji "páchanými"chybami při tvorbě diagramů tříd (a celkově při objektovém modelování)je zaměňování pojmů objekt a třída, čímž může dojít k zavlečení poměrnězávažných nekonzistencí do vytvářeného modelu. Ač se to zprvu nemusízdát zřejmé, hierarchie dědičnosti Automobil <- Osobní automobil <-Škoda 120 je chybná.

Značně ovlivněna svými přímými předchůdci je notace diagramu tříd v UMLvzdáleně podobná klasickým ER diagramům obohaceným o některé objektovérysy. Atributy tříd jsou zobrazeny ve střední části prvku třídy, metodypak v části spodní. Podle specifikace UML mohou být atributy pouzezákladních typů (integer, real, ...), všechny ostatní by měly býtzobrazeny jako vztahy k patřičným třídám. Je zde jasně vidětpolovičatost s jakou se UML staví k objektovému přístupu. Ve skutečnostisamozřejmě neexistuje objektivní důvod pro odlišování jednotlivýchatributů podle typu, v čistě objektových jazycích jsou i základní typyreprezentovány prostřednictvím patřičných tříd. To ovšem zdaleka nenípřípad klasického C++, jímž je UML nejvíce ovlivněn. Rozlišování způsobunotace atributů podle typu se může zezačátku zdát velice matoucí anelogické. V podobném duchu je možné určit pro jednotlivé složky(atributy, metody) tříd jejich viditelnost vzhledem k ostatním třídámatd.

Bohužel značná orientace na jedno konkrétní prostředí je jednou z méněšťastných vlastností UML. Na druhou stranu je nutné si opět uvědomit(pokolikáté už), že tyto prostředky spadají až do pozdního designu adříve než v designu o nich nemá smysl uvažovat. Možná, že se našeneustálé upozorňování na toto základní pravidlo jeví jako dosti zbytečnéa samoúčelné, ovšem věřte nám, že výsledné modely mohou být tímtozpravidla silně poznamenány. Naposledy tedy: "dřívě než v detailnímdesignu nemá diskuse o pointerech" při tvorbě IS své místo.

Vzhledem k velkému množství modelovacích prvků použitelných v tomto typudiagramu může být poměrně lehké "sklouznout" k tvorbě sice formálněpřesných, ale těžko srozumitelných modelů, což se opět negativně projevípři snaze diskutovat řešení s člověkem, který se objektovým modelovánímneživí.

Jak již bylo řečeno, objekty jsou nejčastěji "nalézány" při tvorbědynamických modelů simulujících použití systému (typicky sekvenčnídiagramy) uživatelem, obecně při realizaci jednotlivých případů užití.Na druhou stranu nic nebrání použití odlišných metod pro nalezeníobjektů, jakými mohou být například analýza chování objektů (ObjectBehavioral Analysis), případně nejjednodušší (a nejméně spolehlivá –udává se míra úspěšnosti asi 20 %) lexikální analýza.


Osobní stránky - Pavel Hrzina   e-mail: hrzinap@cs.felk.cvut.cz
Stránky jsou umístěny na servru CS     Elektrotechnické Fakulty ČVUT Praha
Autor: Pavel Hrzina