Lekce 5 - UML - Class diagram

Dnes si ukážeme nějaké další vazby a vytvoříme si třídní diagram.

Class diagram

Diagram tříd je diagram implementace. To je rozdíl oproti doménovému modelu, který byl spíše náčrt systému. Class diagram je již naostro, musí být úplný, když ho programátor přepíše do kódu, kód musí fungovat. Budeme zde mít tedy všechny třídy, které aplikace bude obsahovat. Třídy budou mít všechny atributy a také metody. Diagram je platformově závislý, tedy specifický pro určitý programovací jazyk. Mimo jiné to znamená, že se v identifikátorech již nevyskytuje diakritika, atributy mají datové typy specifické pro daný jazyk a podobně.

Význam diagramu

Class diagram je návod pro programátora, ten by již neměl s naším diagramem řešit žádné zásadní otázky ani problémy, jeho práce by měla být (možná bohužel ) rutinní. Návrh systému mají na starosti zkušení programátoři a analytici. Díky návrhu se potom samotné programování může předat i méně zkušeným programátorům, kteří jsou mnohdy levnější. Diagram tříd je dobré vytvořit však i v případě, že systém píšeme jen pro sebe, donutí nás to nejprve přemýšlet v kontextu celého systému a až potom programovat. Nestane se nám, že napíšeme půlku systému a potom zjistíme, že to takhle nebude fungovat. Složitější informační systémy již nelze vytvářet bez návrhu a i práce v týmu se bez kvalitního návrhu neobejde. Diagram nám do budoucnosti poslouží i jako dokumentace.

Ukažme si ještě jednou grafickou notaci třídy v UML, tentokrát již kompletní:

V první části obdélníku je opět název třídy, tentokrát již bez diakritiky.

V druhé části jsou přítomny atributy s datovými typy. Před každým atributem je uveden modifikátor přístupu. Máme 4 možnosti:

• - (mínus) - Privátní atribut (private).
• + (plus) - Veřejný atribut (public).
• # (hash kříž) - Protected atribut (protected).
• ~ (tilda) - Atribut viditelný v rámci balíku (package).

Význam prvních 3 určitě známe z objektově orientovaného programování, package atribut je atribut viditelný v rámci celého balíčku tříd (tedy jmenného prostoru).

Mezi název atributu a datový typ píšeme dvojtečku.

Metody v posledním obdélníku jsou zapisovány podobně. Je možné specifikovat ještě několik symbolů, ale to se v praxi příliš nepoužívá a proto se tím nebudeme zabývat.

Vztahy

Oproti doménovému modelu zde můžeme použít ještě další 2 vztahy.

Realizace (Realization)

Vztah realizace je mezi interface a třídou, která tento interface implementuje. Třída reprezentující interface má tzv. stereotyp. Ten se píše do dvojitých špičatých závorek, stejně jako tomu je u vazby <<include>> v Use Case diagramu. Stereotyp umožňuje změnit význam určitého prvku v diagramu, nyní měníme třídu na interface. Třída implementující interface je k interface připojena vazbou podobnou dědičnosti, pouze je čára vykreslena jako přerušovaná.

Asociační třída (Association class)

Asociační třída je třída, která zprostředkovává vztah mezi 2 entitami. Výhodou je to, že může vztahu dodat nějaké atributy. Často se uvádí příklad tříd Osoba a Zajezd, kdy asociační třída Ucast přiřazuje osobu na zájezd a dodává čas příjezdu a odjezdu. Dalším příkladem je třeba Osoba a Hotel, kdy v hotelu není pevně stanovený čas ubytování a objednává si ho konkrétní osoba. Podobná třída by mohla ještě např. být mezi zaměstnancem a firmou, kde by definovala plat zaměstnance. Dalším využitím může být možnost takto vytvořit vazbu M:N, podobně, jako to funguje u databází. Asociační třída by tedy držela kolekci referencí. Použití asociační třídy může být poněkud zavádějící a pokud si nejste jistí, tak se ji raději vyhněte.

Příklad Class diagramu

Přejděme k příkladu a vytvořme si Class diagram ITnetwork. Budeme samozřejmě vycházet z předešlého doménového modelu.

Předem upozorňuji, že příklad je velmi zjednodušený, návrh není ideální a nectí MVC architekturu, jak je u webových aplikací zvykem.

Vidíme, že oproti doménovému modelu zde máme úplně novou třídu System. Ta drží instance aktuálního článku a aktuálního uživatele. Dále drží kolekce článků, členů a sekcí. Doménový model pouze mapoval důležité entity z hlediska business zadání a tedy ani nepřemýšlel nad tím, jak systém bude uvnitř fungovat. Počet tříd se tedy prakticky vždy s přechodem od doménového modelu k Class diagramu zvýší.

Instance systému se vytváří s každým HTTP požadavkem, jak nám říká poznámka ke třídě nalevo. Za povšimnutí stojí také výčtový typ StavClanku, který je zde zakreslen jako třída a výčtový typ je z něj vytvořen pomocí stereotypu <<enumerable>>. Zbytek jsme si již popsali, takže si diagram prohlédněte. Jako je to u všech diagramů, je to jeden možný způsob, jak systém navrhnout, možností je nespočetně a i těch správných je mnoho.

V následujícím cvičení, Řešené úlohy k 4.-5. lekci UML, si procvičíme nabyté zkušenosti z předchozích lekcí.