5. diel - UML - Class diagram

V predchádzajúcom kvíze, Kvíz - Use Case diagram a doménový model v UML, sme si overili nadobudnuté skúsenosti z predchádzajúcich lekcií.

Dnes si ukážeme nejaké ďalšie väzby a vytvoríme si triedny diagram.

Class diagram

Diagram tried je diagram implementácie. To je rozdiel oproti doménovému modelu, ktorý bol skôr náčrt systému. Class diagram je už naostro, musí byť úplný, keď ho programátor prepíše do kódu, kód musí fungovať. Budeme tu mať teda všetky triedy, ktoré aplikácia bude obsahovať. Triedy budú mať všetky atribúty a tiež metódy. Diagram je platformovo závislý, teda špecifický pre určitý programovací jazyk. Okrem iného to znamená, že sa v identifikátoroch už nevyskytuje diakritika, atribúty majú dátové typy špecifické pre daný jazyk a podobne.

Význam diagramu

Class diagram je návod pre programátora, ten by už nemal s naším diagramom riešiť žiadne zásadné otázky ani problémy, jeho práca by mala byť (možno bohužiaľ ) rutinná. Návrh systému majú na starosti skúsení programátori a analytici. Vďaka návrhu sa potom samotné programovanie môže odovzdať aj menej skúseným programátorom, ktorí sú často lacnejšie. Diagram tried je dobré vytvoriť však aj v prípade, že systém píšeme len pre seba, donúti nás to najprv premýšľať v kontexte celého systému a až potom programovať. Nestane sa nám, že napíšeme polovicu systému a potom zistíme, že to takto nebude fungovať. Zložitejšie informačné systémy už nemožno vytvárať bez návrhu a aj práca v tíme sa bez kvalitného návrhu nezaobíde. Diagram nám do budúcnosti poslúži aj ako dokumentácia.

Ukážme si ešte raz grafickú notáciu triedy v UML, tentoraz už kompletnú:

V prvej časti obdĺžnika je opäť názov triedy.

V druhej časti sú prítomné atribúty s dátovými typmi. Pred každým atribútom je uvedený modifikátor prístupu. Máme 4 možnosti:

• - (mínus) - Privátny atribút (private).
• + (plus) - Verejný atribút (public).
• # (hash kríž) - Protected atribút (protected).
• ~ (tilda) - Atribút viditeľný v rámci balíka (package).

Význam prvých 3 určite poznáme z objektovo orientovaného programovania, package atribút je atribút viditeľný v rámci celého balíčka tried (teda menného priestoru).

Medzi názov atribútu a dátový typ píšeme dvojbodku.

Metódy v poslednom obdĺžniku sú zapisované podobne. Je možné špecifikovať ešte niekoľko symbolov, ale to sa v praxi príliš nepoužíva a preto sa tým nebudeme zaoberať.

Vzťahy

Oproti doménovému modelu tu môžeme použiť ešte ďalšie 2 vzťahy.

Realizácia (Realization)

Vzťah realizácie je medzi interface a triedou, ktorá tento interface implementuje. Trieda reprezentujúca interface má tzv. stereotyp. Ten sa píše do dvojitých špicatých zátvoriek, rovnako ako to je pri väzbe <<include>> v Use Case diagrame. Stereotyp umožňuje zmeniť význam určitého prvku v diagrame, teraz meníme triedu na interface. Trieda implementujúca interface je k interface pripojená väzbou podobnou dedičnosti, iba je čiara vykreslená ako prerušovaná:

Asociačná trieda (Association class)

Asociačná trieda je trieda, ktorá sprostredkováva vzťah medzi 2 entitami. Výhodou je to, že môže vzťahu dodať nejaké atribúty. Často sa uvádza príklad tried Person a Tour, kedy asociačná trieda Participation priraďuje person na tour a dodáva čas arrival a departure. Ďalším príkladom je Person a Hotel, kedy v hoteli nie je pevne stanovený čas ubytovania a objednáva si ho konkrétna osoba. Podobná trieda by mohla ešte napr. byť medzi zamestnancom a firmou, kde by definovala plat zamestnanca. Ďalším využitím môže byť možnosť takto vytvoriť väzbu M:N, podobne, ako to funguje pri databázach. Asociačná trieda by teda držala kolekciu referencií. Použitie asociačnej triedy môže byť trochu zavádzajúce a pokiaľ si nie ste istí, tak sa jej radšej vyhnite:

Príklad Class diagramu

Prejdime k príkladu a vytvorme si Class diagram ITnetwork. Budeme samozrejme vychádzať z predošlého doménového modelu.

Vopred upozorňujem, že príklad je veľmi zjednodušený, návrh nie je ideálny a nectí MVC architektúru, ako je pri webových aplikáciách zvykom:

Vidíme, že oproti doménovému modelu tu máme úplne novú triedu System. Tá drží inštancie aktuálneho článku a aktuálneho užívateľa. Ďalej drží kolekcie articles, members a sections. Doménový model iba mapoval dôležité entity z hľadiska business zadania a teda ani nepremýšľal nad tým, ako systém bude vo vnútri fungovať. Počet tried sa teda prakticky vždy s prechodom od doménového modelu k Class diagramu zvýši.

Inštancia systému sa vytvára s každou HTTP požiadavkou, ako nám hovorí poznámka k triede naľavo. Za povšimnutie stojí aj výpočtový typ ArticleState, ktorý je tu zakreslený ako trieda a výpočtový typ je z neho vytvorený pomocou stereotypu <<enumerable>>. Zvyšok sme si už popísali, takže si diagram prezrite. Ako je to pri všetkých diagramoch, je to jeden možný spôsob, ako systém navrhnúť, možností je nespočetne a aj tých správnych je mnoho.

V nasledujúcom cvičení, Riešené úlohy k 4.-5. lekciu UML, si precvičíme nadobudnuté skúsenosti z predchádzajúcich lekcií.