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 diagram tried.

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ý a keď ho programátor prepíše do kódu, kód musí fungovať. Budeme tu teda mať 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, ktorý 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ší. 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, teraz 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 sú v poslednom obdĺžniku 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, len čiara je 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 pridá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 byť ešte napr. 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 ku 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 z možných spôsobov, ako systém navrhnúť, možností je však nespočetne a aj tých správnych je mnoho.

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